32.27 A Comparison of the Ice and CORBA Run Time

The CORBA equivalent of the server-side functionality of Ice is the Portable Object Adapter (POA). The most striking difference between Ice and the POA is the simplicity of the Ice APIs: Ice is just as fully featured as the POA but achieves this functionality with much simpler interfaces and far fewer operations. Here are a few of the more notable differences:

• Ice object adapters are not hierarchical, whereas POAs are arranged into a hierarchy. It is unclear why CORBA chose to put its adapters into a hierarchy. The hierarchy complicates the POA interfaces but the feature does not provide any apparent benefit: the inheritance of object adapters has no meaning. In particular, POA policies are not inherited from the parent adapter. POA hierarchies can be used to control the order of destruction of POAs. However, it is simpler and easier to explicitly destroy adapters in the correct order, as is done in Ice.

• The POA uses a complex policy mechanism to control the behavior of object adapters. The policies can be combined in numerous ways, despite the fact that most combinations do not make sense. This not only is a frequent source of programming errors, but also complicates the API with additional exception semantics for many of its operations.

• The CORBA run time does not provide access to the ORB object (the equivalent of the Ice communicator) during method dispatch. Yet, access to the ORB object is frequently necessary inside operation implementations. As a result, programmers are forced to keep the ORB object in a global variable and, if multiple ORBs are used, there is no way to identify the correct ORB for a particular request. The Ice run time eliminates these problems by always providing access to the communicator via the adapter that is passed as part of the Current object.

• The POA attaches implementation techniques to object adapters. For example, an object adapter that uses a servant locator cannot also use an active servant map.

The POA also distinguishes between servant locators (which are similar to Ice servant locators) and servant activators (which work like the incrementally initializing servant locator in Section 32.9.1). Yet, there is no need to distinguish the two concepts: a servant activator is simply a special case of a servant locator that can be implemented trivially.

Similarly, default servants must be registered with a POA by making a special API call when, in fact, there is no need to cater for default servants as a separate concept. As shown in Section 32.9.2, with Ice, you can use a trivial servant locator to achieve the same effect.

• The POA uses separate POA manager objects to control adapter states. This not only complicates the APIs considerably, it also makes it possible to combine hierarchies of object adapters with groupings of POA managers in meaningless ways, leading to undefined behavior. Ice does not use separate objects to control adapter states and so eliminates the associated complexities without loss of functionality.

• The POA interfaces have the notion of a default Root POA that is used unless the programmer overrides it explicitly. This misfeature is a frequent source of errors, due to inappropriate policies that were chosen for the Root POA. (Users of CORBA will probably have been bitten by implicit activation of objects on the Root POA, instead of the intended POA.)

• The POA provides the concept of implicit activation as well as the notion of system-generated object identities as part of the object adapter policies. This design is a frequent source of programming errors because it leads to many implicit activities behind the scenes, some of them with surprising side effects. (It is sad to see that all this complexity was added to avoid a single line of code during object activation.) Ice does not provide a notion of implicit activation or implicit generation of object identities. Instead, servants are given an identity explicitly and are activated explicitly, which avoids the complexity and confusion.

• CORBA has no notion of datagrams, or of batched invocations, both of which can provide substantial performance gains.

• CORBA provides no standardized way to integrate ORB messages into existing logging frameworks and does not provide access to network statistics.

In summary, the Ice run time provides all the functionality of the POA (and more) with an API that is a fraction in size. By cleanly separating orthogonal concepts and by providing a minimal but sufficient API, Ice not only provides a simpler and easier-to use API, but also results in binaries that are smaller in size. This not only reduces the memory requirements of Ice binaries, but also contributes to better performance due to reduced working set size.