ILU, OSA, SOM/DSOM, CORBA [acronynm party time!](was: Embedding of Mime parts)

Steven D. Majewski (sdm7g@virginia.edu)
Sat, 21 Jan 1995 06:46:57 +0100


On Fri, 20 Jan 1995, Adam T. McClure wrote:

> Ok first I just wanted to ask if someone could provide a URL to "IUL"
> or whatever the DSOM/OpenDoc alternative is these days.

[ Snipping the link out of my SafePython page: ]

<a href="ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html">
ILU: Inter-Language Unification </a>


> Now, to respond to Steve's comments I just wanted to mention that I'm
> currently involved in a graduate seminar in distributed clien-server
> computing and one of the things that has come out of our studies so far
> (it's early in the semester) is that none of the available standards
> is really complete or robust unto itself. The new CORBA2 spec is going
> to be a large improvement on the original and fixes a lot of the problems
> that the original CORBA spec created, but overall it will be a learning
> process just as the transition to an object model in general has been
> in the software engineering industry.

Both ILU and SOM/DSOM are (IMHO) significantly <i>more</i> than CORBA.
Both predate CORBA and were not trying to solve only the *distributed*
object problem, but linking and inheritance of objects from different
compilers and languages.
Both, though, are going to be retrofitted to be CORBA 2 compliant.
( There seems to be little disagreement that CORBA is going to define
the interoperable standard. )

Bill Janssen at Xerox PARC, one of the authors of ILU has posted a number
of comparisons and critiques of CORBA to comp.objects.

> As part of this course I have taken on the responsibility for writing
> a dynamic language interface for a CORBA-comliant ORB called ORBeline.
> The interface will be for Perl so that perl scalars , arrays, and possibly
> even "blessed" objects will be translated into CORBA::object formats and
> back out. The net result will be that you can use Perl scripts to perform
> queries of CORBA-compliant brokers through a fairly standardized interface.
> The actual implementation that will come out of the project will be specific
> for ORBeline, but I don't anticipate a whole lot of major changes necessary
> for another ORB and would be willing to make a port to really popular ORB
> types if persuaded ($$) or cajoled by the net community in general (free).

ILU is free and has bindings to C, C++, Lisp, Modula-3 and Python.
(list from memory - I hope I got that right!)
You might consider adding Perl bindings to ILU.
( Not knowing much about the internals of ILU or ORBeline, I have no
idea how difficult it would be to convert. )

| The mailing list ILU.parc@xerox.com is for discussion of ILU, questions, etc.
| Please send mail to ILU-request.parc@xerox.com to be added or deleted, not to
| the list itself.

And you can reach Bill Janssen at: <janssen@parc.xerox.com>

---

SOM is *not* free, however CI-Labs are committed to seeing that it is "freely or cheaply available". I don't know exactly what that will work out to be - I believe IBM still owns the technology, but even when it is transferred to CI-Labs, I don't know if they can afford to give it away. But even if it has to be licensed, it will be (I believe) royalty free, so with their sliding scale membership, it's probably not impossible for someone to join CI-Labs and port it to Linux, for example, and redistribute it as part of that "product".

> I'm still in the process of exploring what exactly the ORB can capably do, > but as far as I know at this point, one potential bonus will be accessing > DBMS's in all shapes and flavors that have a CORBA-compliant interface. > If anyone is interested in seeing particular functionality come out of the > project please mail me directly and we can discuss how your needs might be > accomplished.

Yeah! I'm still trying to figure out how to *use* all this stuff! :-)

One thing I forgot to mention in my previous post was that all this jazzy new capabilities comes with a lot of added complexity. One of the things that drew me to using Web protocols for in-house applications was it's simplicity. I hope there is a way to preserve the (relative I agree with Dan's gripes) user-level simplicity.

One reason to look at OSA is the "value added" Application Level standardization of the various event suites. CORBA itself does not organize the distributed object space in any meaningful way. ( Although, I believe that's what Common Facilities and other OMG standards will be trying to do - However, the last C-F draft I looked at was mostly blank empty space templates - i.e. "insert appropriate technology here!" ) OSA objects can be things like paragraphs. Look at the paper :

Willam R. Cook and Warren H Harris The Open Scripting Architecture: Automating, Integrating, and Customizing Applications

<http://minsky.med.virginia.edu/sdm7g/Projects/Python/OSA/OSA.ps.gz>

---| Steven D. Majewski (804-982-0831) <sdm7g@Virginia.EDU> |--- ---| Computer Systems Engineer University of Virginia |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| Box 449 Health Science Center Charlottesville,VA 22908 |---