| 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.

Web Object Terminology

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