W3C | OOP

Why ILU?

ILU is a very promising technology for tying the web to object oriented programming. The more I see, the more I am convinced it will work. Here's why.

ISL Balances Formalism with Extensibility

The heart of ILU is ISL, the Interface Specification Language. Application protocols are specified in this language. Once specified, they can be checked and implemented to a large extent by machine. (Combined with Larch, they could be further specified and checked.)

We have to be careful with an interface specification to be sure things don't get too rigid. Loosely structured message formats like RFC822 allow tremendous extensibility. But ILU has a number of extensibility pivot points:

Implementation Language
bindings for C, C++, python, Modula-3, and CommonLisp are done. Tcl and Java are in the works. I expect to see Smalltalk, perl5, OREXX, and all the others over time, since the ILU code is clean and free.
Message format
SunRPC XDR and Courier have been released. DCE is feasible. CORBA IIOP is done, I think. I expect to see an HTTP 1.x (i.e. RFC822) message format developed RSN.
Transport
A TCP transport with connection re-use and management has been release, as well as a hacked UDP transport for SunRPC interoperability. I hear CORBA IIOP is in the upcoming 2.0 release. The design allows for transports within the same address space or accross address spaces, and within the same implementation language or across implementation languages. So ILU can be a universal foreign function interface as well as a network objects system.

Not only is the interface specification language independent of transport, message format and implementation language, but the runtime architecture explictly provides an API to slot them in.

The clean, modular architecture and the unrestricted copyright mean that development resources from all over the net can be applied to the system.

CORBA Interoperability

Much of the work on enterprise object systems is done in the context of the CORBA architecture. The vertical markets (e.g. manufacuring, medicine, ...) seem to be hammering out their specs in the OMG forum. This makes CORBA support very valuable.

Specification Interoperability

CORBA's IDL can be translated to ILU's ISL with a few exceptions:

It's straightforward to write specs in CORBA IDL that translate nicely to ILU IDL. But it's not clear how problematic it is to translate specifications written without ILU in mind. I'd like to know whether existing IDL-based specs like OpenDoc and Fresco can be tranlated to ISL, or whether they violate some of the above constraints. (CORBA security uses ANY.)

On-The-Wire Interoperability

ILU 2.0 will be one of the first IIOP implementations -- almost certainly the first free one. I don't expect IIOP to be used over the public Internet on a large scale -- I hear it doesn't address high latency, low bandwidth conditions very well. But I do expect lots of LAN and enterprise object systems to support IIOP, and interoperability there will be critical.

Firewall Security

Administrators of large firewall systems generally require publicly reviewed source code. ILU has it. These admins actually need source to implement their local access control and accounting policies. Access control support is already in ILU, and I expect to see a lot of effort on instrumenting the ILU runtime for auditing (logging). There will be standard policies supported, and the possibility of hacking local policies will be there.

High Latency and Low Bandwidth Operation

ILU makes all sorts of gateways and interoperability mechanisms nearly trivial. You want a gateway that translates between SunRPC and CORBA IIOP? Just link both transports and message formats into your server, and you're done. Eventually, I expect the same will be true of DCE, HTTP 1.x, IBM's DSOM, Microsoft's DCOM, etc.

This will be critical when you want to run HTTP-NG from your palm-top, across a serial link to your PC, across the LAN, through the firewall, and over the Internet, then back through a similar set of twisty passages to the server. No single message format and transport will be suitable for the whole route.

And ILU's explicit support for asynchronous calls makes streaming and batching (and generally minimizing round-trips) straightforward.

A Strategy

If an ILU-based HTTP-NG addresses even a few of HTTP 1.x's limitations, the market demand will be sufficient to drive the development and administrative efforts.

Then, the distributed OOP community will have its foot in the door: the ILU runtime will be widely deployed. Since any number of application protocols (interfaces) can share the same TCP connection, deploying new APIs over the same transport will be simple and straightforward. They can probably even be bootstrapped at runtime, when combined with mobile code technologies like Java (firewall policies might cause restrictions, but...)


W3C
Connolly
$Date: 1995/12/21 09:34:42 $