| Architecture | OOP
Issues in the Development of Distributed Hypermedia Applications
@@obsoletes old address.
Here are the issues that are important in a system for developing distributed
hypermedia applications. They are useful for evaluating
mobile code systems and
object technologies. See also:
The Web Object Model and Type
System.
-
Concurrency
-
User interfaces need to be responsive and lively, and servers need to respond
to multiple clients concurrently. A system with explicit support for threads,
mutexes, and condition variables facilitates these and a wide variety of
other techniques.
-
Thread-Aware I/O
-
One of the major opportunities for parallelism is during I/O requests. An
I/O library that is thread-aware avoids the need for event-loops,
stupid-select()-tricks, and other fragile techniques that tend to conflict
between large libraries.
-
MS Windows GUI
-
currently, the dominant user platform. Must be supported. Developing for
Win3.1 is a pain, but Windows NT and Windows-95 remove many of the gotchas
of the Win3.1 programming model.
-
X/Motif GUI
-
deployment on this platform is pretty important -- critical, I'd say.
-
Mac GUI
-
A complete solution must support this.
-
Portable GUI API
-
A programming model that allows one body of code to be delivered on all three
platforms is very handy. Unfortunately, I've never seen one that doesn't
involve major compromises and/or major license fees.
-
Objects with inheritance
-
Programmers are more productive with APIs that exploit inheritance.
-
Protocols/Mixins/Interfaces
-
In Smalltalk (and hence objective-C) systems, a "protocol" is a collection
of methods that an object must support, regardless of where it sits in the
class hierarchy. In many cases, it obviates the need for multiple inheritance,
which can be messy.
-
POSIX API
-
Not a critical feature, especially since it conflicts with Thread-aware I/O
and exception based programming. But the ability to spawn processes, get
at files, etc. is handy. Higher level interfaces are sometimes better, but
sometimes not.
-
Module System
-
To allow independent bodies of code to be used together, we need some
technique(s) for managing the namespace. I like the way Modula-3 handles
name spaces, but partial revelations is a key to making it work, and you
won't find that outside of Modula-3. But Ada95, python, and some others give
the right feel. I like having qualified names and ways to abbreviate them
(e.g. IMPORT ... FROM ...). Separation of interfaces from modules is handy,
and noteably lacking from Python and Java. But it's evidently not critical.
-
Exceptions
-
Counting on folks to check return codes is madness. For really scalable code
bases, Modula-3's static RAISES checking is really handy.
-
Run-time Safety
-
The question here is: does the runtime system guarantee that the program
will behave according to its source code (or abort)? Languages like C/C++
do not. Languages like lisp, scheme, python, Java, etc. do. Modula-3 supports
both kinds of modules. Run-time safety generally mandates automatic storage
management (e.g. garbage collection)
-
System Safety
-
Slightly different question: can I control access to resources by a piece
of executing code? Can I prevent it from erasing my files, forging mail from
me, etc.? Much harder question, as it involves security policies. This is
critical to mobile code systems.
An
Introduction to Safety and Security in Telescript gives an excellent
discussion of run-time safety and system safety.
@@For an application to span administrative domains, there must be access
control mechanisms, usually including authentication, to maintain security
and system integrity.
-
Foreign Function Interface
-
There's a lot of code written in C etc. that we don't want to -- or cannot,
for reasons of copyright etc. -- rewrite. A cliean foriegn function interface
is probably Tcl's greatest strength. Threads, garbage collection, and exceptions
can really complicate FFI.
-
TCP/IP API
-
Gotta have access to the network.
-
Flatten/Serialize/Pickle
-
Useful for persistent object store, and for RPC marshalling.
-
Mobile Closures
-
This allows computations to span address spaces in a fairly natural, if not
transparent way. Obliq pioneered this, in a way.
Some other handy language features for programming-in-the-large:
-
Generics
-
Ala Ada and Modula-3, or C++ templates.
-
Module/Interface Separation
-
Ala the separation of .h from .c in C.
These terms are used in many ways in many places. Here are the terms and
definitions I've settled on. See also: Web
Architecture: Terminology
-
Object
-
Some data/state with associated behaviour; typically, some bits of state
and some set of methods. We won't use this one formally much.
-
Object Type
-
A set of method signatures. I think the Smalltalk community originally coined
ther term "protocol" for this use (somewhat ironic, given the current duality
between network protocols and APIs). This is akin to an class in Smalltalk,
C++ and other multiple-inheritance systems. It's similar to a class in Java
Objective C, but it's more like an interface in Java, sine we're only talking
about the interface, and not the implementation. Modula-3 has
a
crisp notion of object types, but it's single-inheritance.
ILU's
object types are similar, but without the single-inheritance restriction.
-
Namespace
-
A set of names and their (static) bindings. Has its roots in C's .h files.
In Modula-3 and ILU, this is called an inteface, as in "a module exports
an interface". In OMG IDL and python, a module (same for scheme48 and guile,
I think). In Java, a package. (I was calling this an "Interface" until recently
-- Jan 96).
-
Code Artifact
-
Some executable code. In C, a .c or .o file. In Modula-3 and python, a module.
In Java, a class. Note that in Java and python, code artifacts and namespaces
have a 1-1 relationship, wheras in C and Modula-3 (and most languages with
a notion of separate compilation), they can have a many-many relationship.
-
Resource
-
Anything that can be named with a URI. Also, the object type with no methods
(hmmm... perhaps a GET method? QueryInterface?). Hence resources are not
directly observable. There is some inclination to use the term
object here, but I'm resisting it. This is much like the concept
of ANY in OMG IDL, which is not expressible in ILU's ISL.
-
Document
-
The object type with methods GET, PUT, POST, and DELETE. A document is also
a resource; that is, it has an address or identifier. Not to be confused
with artifact.
-
Digital Artifact
-
A sequence of bytes with an associated media type. Known in the HTTP spec
as an entity. The HTML spec term "document" fits here too. Also: representation
Related Resources
-
Computing
Languages List
-
Collaborative list of programming languages on the net edited by LaLiberte@NCSA
with HyperNews.
-
Programming Language Research
-
-
Web Object Terminology
-
In a space of overloaded terms like object and document, we have to pick
some definitions.
-
Design Issues: The Web Object
Model and Type System
-
Connolly
$Date: 1999/10/13 20:34:45 $