Bridging CORBA and Ice?

Re: Bridging CORBA and Ice

This is a big topic, so this reply might end up being a bit lengthy...

There is plenty of precedence for this sort of thing. CORBA-COM bridges, CORBA-DCE bridges, CORBA-GDMO bridges, CORBA-SNMP bridges.
Historically, none of these have been very successful. (The one exception might be the CORBA-COM bridge from IONA. That one is actually used by a number of customers.) Here are some of the reasons:

* Ideally, a bridge will be totally transparent, so a client could not tell whether a request it sends goes to a CORBA server or an Ice server behind a bridge. Similarly, a server couldn't not tell whether a request that arrives comes from a CORBA client or an Ice client. In practice, this is rarely possible. For example, as far as request invocation is concerned, a CORBA server can indeed not tell whether the invoking client really is a COM client behind a bridge. However, that doesn't really solve the problem. For example, in COM, the way to get rid of an object is for the client to simply drop the handle to the object. DCOM extends this model with remote garbage collection so, when a client drops a handle to an object, the object is deallocated in the server. (Incidentally, this scheme totally wrecks scalability, which one of the major reasons for DCOM having been abandoned -- I said many years ago that this was a brain-dead idea that would never work, but I digress... ;-) )

So, if we have a DCOM client behind a bridge talking to a CORBA server, the client will simply drop its handle to an object and expect the object in the server to go away. But, of course, that isn't going to happen because, in CORBA, you have to invoke a method in the server to get rid of an object.

Semantic mismatches such as this are one big problem for all kinds of bridging. When you look closely, you will usually find subtle semantic differences in the two object models that end up complicating things in surprising ways, and end up destroying transparency to some degree.

* The object models usually differ in more than subtle semantics. For example, Ice has a number of types that you don't find in CORBA, and vice-versa. (For example, Ice has dictionaries, and CORBA has type Any and unions.) For such types that don't exist in one of the object models, we need to come up with translation algorithms. For example, a CORBA union could be represented as an Ice class that provides the same functionality, and an Ice dictionary could be represented as a CORBA sequence of pairs.

Unfortunately, once you have done a number of such translations, the resulting APIs tend to get surprisingly messy. The data types application programmers end up having to deal with are contrived and not at all like a corresponding built-in facility, making programming with such models a less than thrilling experience.

* Usually, problems exist not only at the object model semantic and type level, but also at the linguistic level. For example, Ice does not permit underscores in identifiers (and for good reasons), but CORBA does. So, we end up having to mangle IDL identifiers somehow into something that's acceptable to Ice. Another issue has to do with naming scopes. Ice and CORBA are fairly close matches as far as their scoping rules are concerned, so it's not too bad in that case (although there are some issues that would need to be dealt with). A better example is the CORBA-GDMO translation algorithm. The problem is that GDMO uses case-sensitive identifiers and that leading upper case denotes a type whereas leading lower case denotes a field. This makes a big mess of the corresponding IDL because the IDL identifiers all end up mangled (and the whole thing looks like a dog's breakfast, really). Worse, the scoping rules of GDMO are completely different from those of IDL, requiring yet more mangling and, worse, the mangling algorithm is sensitive to ordering of the GDMO definitions, meaning that different (but semantically identical) GDMO definitions generate totally different (and semantically different) IDL definitions. (The CORBA Java-to-IDL reverse mapping suffers from a lot of these problems too.)

Having worked on all this some years ago, I decided that the pain wasn't worth the gain: whatever you gained by having automatic bridging was completely wiped out by the total mess of APIs you ended up having to deal with.

* Bridges typically cannot operate without type information. For example, it is not possible to bridge from CORBA to Ice or vice-versa without precise knowledge of the types that are involved because neither CDR nor the Ice encoding carry type information on the wire. So, the bridge has to be configured with type information, which can be an administrative nightmare. Moreover, by using a bridge, we end up squeezing all the invocations through a server process, which isn't all that scalable (well, not scalable at all, to be honest).

So, the recommendation I have for people who ask me about bridging is that it is usually cheaper and more effective to build an application-specific bridge by hand than to use an automatic translation gizmo of some kind. You take the, say, IDL definitions and hand-translate them into corresponding Ice definitions. That way, you can make an object model that looks good in CORBA and looks good in Ice and does the right thing by either side. Then you build a simple server that bridges between the two models by forwarding requests in both directions. Usually, this is not all that difficult because the server logic is mostly trivial. Putting both Ice and CORBA run times together in the same server is no problem. The namespaces are properly separated so you won't get clashes, and you simply link against both CORBA and Ice libraries. Unless you have a large number of different applications with vast amounts of IDL or Slice definitions, this is the best way to go, in my opinion.

So, having said all that, it is definitely possible for at least a subset of CORBA and Ice to be bridged cleanly. I probably would still not go for a fully-automated approach, but for something that uses user-defined mapping tables instead of automatic translation. That way, you don't suffer a lot of the interface uglyness that results from completely automatic translation.

Depending on how much demand we get, we may end up building such a thing. It really depends on customer demand. Depending on whether the bridge is static or dynamic, we also might add a DII/DSI type of mechanism. (This wouldn't be too hard to do because all the hooks for it are in the run time already.)

So, for the moment, no bridge. But, if you seriously are thinking about bridging between CORBA and Ice, I'd suggest to give it a go just to see how it pans out. Take a subset of the IDL, and make a server that can bridge in just one direction to start with. In essence, if the bridge allows CORBA clients to talk to Ice servers, you end up building a CORBA server whose servant implementations act as Ice clients to the real Ice server.
As a proof of concept, that's all you need to do. And you might be pleasantly surprised at how easy it is. (In fact, maybe we should build a demo that does this, just to show people the insanity of the CORBA C++ mapping side-by-side with the elegance of the Ice C++ mapping ;-) )

Cheers,

Michi.