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.

ANY: IDL has an ANY type, but ISL does not. I need to figure out the
technical issues here.

OPTIONAL: actually, I don't think this is a problem: ILU's support for
OPTIONAL subsumes CORBA's expressive capability. (@@need to check this)

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.

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