Re: [HACKERS] CORBA STATUS

> The same issue is true for the RPM's -- which ORB? If I'm on RedHat Linux, the
> choice of ORB is going to depend upon the choice of desktops -- KDE or GNOME.
> ORBit is packaged standard for GNOME -- KDE 2 is going to use something else --
> now, my understanding of CORBA is quite limited -- Thomas, you have far more
> experience, as you are actively developing CORBA stuff. If I choose to install
> just KDE, KDE's ORB is going to be installed -- if I install GNOME, ORBit is
> going to be installed. If I install both (the default), both ORB's will be
> resident.

Right.

> I can force the installation of a particular ORB through dependencies, but
> that seems messy to me.

Not so bad, but I understand your point.

> I CAN produce multiple sets of packages -- but that's going to cause all
> manner of confusion for users.

Right. Not worth the effort.

> Is it possible in the CORBA context to do what Oliver mentioned with a 'pg_orb'
> abstraction layer to a generic CORBA-enabled postgreSQL??

Maybe, as a second step. The first step (which we are a *long* ways
away from; getting a consensus on how to proceed will take a miracle)
will be to get an implementation using one Orb with the feature set we
want.

> It may seem like Oliver and I are getting the cart before the horse, but
> the strategic decision of how to integrate CORBA into the system is going to
> have wide-ranging repercussions for integrators.

This may not be what people want to hear, and may not be what turns
out, but imho and imle ("little experience" ;)...

Corba is really intended to allow clients and servers implemented with
different Orb products to interoperate transparently. It has very
carefully stayed away from over-specifying exactly *how* a particular
client or server would be implemented for a particular Orb.

The header file conventions, or lack thereof, is a good example of
this. I'm familiar with a couple of the C++ Orbs. Mico produces a
single header file per interface, while TAO produces two. Hmm, it just
dawned on me that I might be able to jigger the output file names from
TAO's IDL compiler to make the names line up with Mico. Will get back
to you on this detail :)

Anyway, if Corba is in our future, I would think that we would work
with a single Orb for the server-side implementation, at least at
first. Once we are up and running, then we talk about how to slip in
someone's favorite other Orb.

For clients, we will have to pick and choose depending on the language
and features required. For example, TAO has portability and some
realtime features and optimizations that make it the *only* choice for
our realtime systems at work. But Mico has a nice TCL binding, so we
are using that to implement some TCL GUIs for commanding and telemetry
interfaces.

Not a big deal, and we quickly got over the *flap arms all over* "Oh
no! This Orb doesn't support language X!!!!".

btw, the Orb which has more language bindings than any other is ILU.
ILU predates Corba by several years, but it has evolved to support the
Corba standard in many areas.

Corba was primarily intended to decouple clients from servers.
Inter-orb transportability at the source code level was a secondary
concern, though the Corba standard, or at least some of the
conventions used in the open-source implementations, may be converging
a bit to help with the source portability. And the biggest
source-level portability concern, the call-level interfaces, is not a
problem.

As we are introducing Corba to new users at work (we've got O(20)
programmers who will be using it on our testbeds and ground
implementations for optical interferometers), I emphasize the
following:

1) Corba makes distributed computing easy, in that clients (the
calling programs) call servers (the subroutines) as though they were
local to the client. But in fact they could reside anywhere.

2) Specifying interfaces through IDL is a *great* way to design
systems. If you have the interface, then you know what you need to
implement. From then on, clients and servers, or callers and call-ees,
can be implemented independently. If we end up with Corba in our
server, then we could/should start specifying our internal interfaces
with IDL also.

3) Since clients and servers are decoupled through well-defined
interfaces, and since these interfaces can be decoupled "on the wire",
you have great flexibility in how you mix and match Orb products to
implement clients and servers. But afaik all of the Orbs have a "short
circuit" which will allow you to build Corba-enabled routines written
with that Orb into the same image, without taking a hit at runtime to
marshall/unmarshall/network/etc.

One in an occasional series... ;)

- Thomas

btw, I'm guessing that the way to get Corba going is to have a code
freeze/fork, and have a few people work on demonstrating Corba using
that frozen version. Then we re-merge later if the Corba demo was a
success *and* if Corba is what we want in the main-line product. That
could happen during our 7.x series of releases, and if the world wants
Corba, we could mainstream it for v8.0.

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California