Differences between CORBA and ICE

Hi Alberto,

albertods wrote: »

1)What do you mean when you say that object identities and proxies in Ice are not opaque like CORBA?

2)the chapter 2.5.1 - paragraph "Object Identity" is not very clear the comparison between the object identity in the Ice model and the CORBA one. If the Ice object model is universally unique, how about CORBA?

CORBA mandates that object identities are opaque. This means that there is no way for the ORB to ever look at an object identity other than as a blob of binary bits, and that there is no way for the client to get at the identity of an object (unless the object itself provides an operation that returns the object identity).

Similarly, in contrast to Ice, a CORBA client cannot simply construct an object reference from a string by specifying object identity, host, port, protocol, and so on. CORBA provides string_to_object(), but the string that you pass to this call is just a binary blob expressed as hex digits.

Some time around 2000, an update to CORBA added corbaloc, which does provide the ability to create an object reference from a string. However, that mechanism does not allow you create arbitrary object references. For example, there is no way to control what goes into the profiles inside an IOR, and corbaloc is not a general way to create object references. corbaloc was a late attempt at allowing object references to be more like URLs, but it back-fired. For one, it is sub-functional. And, second, CORBA is still lumped with many APIs that are more complex than necessary, due to the need to treat object references as opaque entities. (The interceptor API is one example.)

The fact that references are opaque has a surprising number of consequences. For starters, there is no reliable way to compare object references to see whether they point at the same object. You can call is_equivalent() to see whether two references denote the same object. If the answer is "yes", you indeed know that the two references denote the same object. But if the answer is "no", you know nothing--the references may or may not denote the same object.

Moreover, the CORBA object model does not specify that each CORBA object must have exactly one unique identity. For example, an application can create two references to the same CORBA object, but with different identities embedded into the references. (I have seen applications that actually do this--they embed extra metadata-like information in the identity.)

In contrast, the Ice object model simply stipulates that identies are globally unique, and that each Ice object has exactly one identity. This allows applications to easily create proxies out of thin air by simply specifying them as a string (and, with Ice, you can control all aspects of a proxy that way).

Moreover, non-opaque identities allow services such as distributed transaction service to be implemented more efficiently. With distributed transactions, to provide isolation, the transaction manager has to look at the identities of the objects in a transaction in order to decide whether to allow another object to join that transaction. In CORBA, this is possible only by making remote call on each object in the transaction whenever another object wants to join the transaction. This is hopelessly inefficient. (With Ice, this can be done without making any remote calls.)

Opaque identities (and opaque object references in general) also complicate many aspects of the CORBA API, and make marshaling of object references quite inefficient: with all ORBs I have seen, object references marshal far slower than any other data type (possibly with the exception of type Any, which is also very slow to marshal).

3)in chapter 2.5.2: when you talk about the important features of the Ice protocol, what do you mean when you say that messages and data are fully encapsulated on the wire? How can they be otherwise?

With IIOP/CDR, requests and certain parameters are not encapsulated. For example, it is impossible in CORBA to just pick up an incoming request off the wire and forward that request to another object. (The requisite APIs do not exist.) In turn, that makes it impossible to implement things such as request routers.

CORBA also makes it impossible to efficiently implement event services, due to the broken marshaling of type Any. A value of type Any is marshaled as a type code, which describes the type information of the value, followed by the value as a string of binary bits. However, the Any as a whole is not enclosed by an encapsulation, and the value following the type code is also not enclosed by an encapsulation. This means that, in order to read an Any value off the wire, the unmarshaling end has to first parse through the entire type code because only after it has done that can it know at what byte offset the value part starts. And, to get to the end of the Any on the wire, it has marshal through all of the value data item by data item, because that is the only way to find out where the value ends, and at what byte offset the next value that follows it on the wire starts.

There are many other flaws in IIOP and CDR. Overall, it's a horribly botched protocol and encoding.

4) Does CORBA have a J2ME embedded version, like ICE-EJ ?

Yes, we have an embedded version of Ice for both C++ and Java. See here for more info.

Cheers,

Michi.

Yes, there are embedded CORBA products for at least C, C++ and Java. I don't know how up to date these products are with the current specifications, however.