, which
may not be enough for hard real-time applications.
[Up: Reference Implementation]
[Previous: Collocation] [Next: Evaluation]
At the time of writing, more than a year after the release of the CORBA 2.2 specification, the Portable Object Adapter is still not widely available. IONA Technologies, the market leader according to number of sales, has just released the new major version 3.0 of their Orbix product, still without a POA. So far, the only two commercial ORBs that claim to come with a POA are ObjectBroker from BEA Systems and DAIS from PeerLogic. Both are not freely available, and information about them is scarce.
However, two other Open Source ORBs, ORBit from Redhat Labs and TAO from Washington University, have evolved a POA implementation in parallel to the one in MICO. Both can be downloaded and distributed in source under liberal licenses, so their implementation of the POA could be examined.
A third candidate for comparison is ORBacus from Object Oriented Concepts, a commercial ORB that can be downloaded in source for private use.
The goal of this comparison was not to search and expose minor bugs, but rather to make a structural comparison of the different design strategies and to see how other ORBs handle the topics of object key handling, persistence and collocation.
The development of all three ORBs is not finished. While ORBit has not changed over the last three months, new versions of TAO appear almost weekly, and ORBacus is still in the alpha stage. The most recent versions as of mid-June 1999 have been downloaded and checked, but the information presented here could be outdated soon.
This ORB from Redhat Labs [43] was available in version 0.4, and it is interesting to look at its history. ORBit was developed as a basis for the distribution of components in the GNOME desktop project [12], using some of the same basic ideas as in the KDE project [19]. The KDE project has used MICO from the beginning, and so did GNOME. However, their developers have been unimpressed with the performance of MICO and so decided to start writing an ORB of their own.
Being very concerned with performance, the GNOME project does not use C++ but plain C, and consequently, ORBit provides a C language mapping only.5.5
ORBit is still a work in progress, and while it has reached maturity in that it can be used to implement clients and servers, many advanced features are not yet implemented. In the POA implementation, some of the identity mapping operations are missing, as is support for virtual objects, adapter activators or the POACurrent interface.
The ORBit POA does not encode the full POA name into the object key, but rather a numerical identifier. A global map then translates this POA Id back to the POA instance. While making for shorter Object Ids, this will require ORBit to keep state information for old POAs - once adapter activators are implemented. In the unlikely situation that an implementation routinely creates and deletes POAs, the internal tables in ORBit will grow, while MICO keeps all information in the clients, should they decide to keep an object reference.
The lifespan policy is wholly unimplemented, and the way object keys are generated (again using a numerical identifier that points into an array of Object Ids) does not satisfy either persistency or transiency.
On the other hand, ORBit does include collocation optimizations, albeit using the BOA-based approach as shown in figure 5.10. Invocations on a collocated object bypass both ORB and POA.
A striking feature of ORBit is its size of just 10.000 lines of code5.6 for the ORB core and its components, including the POA. For users who can live with the C language mapping and without advanced CORBA features, ORBit is a lean and efficient ORB.
The tested version of The ACE ORB [61] from Washington University was 0.3.23 from May 22, 1999 and comes with a full-featured POA.
TAO already supports persistent objects, but does not yet allow for on-demand startup of new servers. The distribution includes a design paper for an Implementation Repository and some preliminary code.
A problem of relying on ORB extensions has already been mentioned in section 5.3, where a new methods was introduced in order to support short and legible object keys for the Interoperable Naming Service.
The focus of TAO development is its applicability in real-time systems, and
TAO's developers are spending much thought on algorithms to provide runtime
guarantees [51]. The POA does have to maintain its own
data structures like the Active Object Map, which needs to be traversed upon
invocation. As mentioned in section 5.2, the MICO POA
uses an STL map to provide an average case behavior of , which
may not be enough for hard real-time applications.
The idea used by TAO is that servers are commonly static, i.e. the number of POAs and active servants is known beforehand, at design time. TAO uses this knowledge to compute a perfect hashing function on the expected set of Object Ids to guarantee constant-time lookup in the Active Object Map. In the skeleton code, again perfect hashing is used in the dispatching of a request to an object implementation's method.
Like ORBit, TAO keeps the names of active POA instances in a global map and stores an index into that table in the object key, but avoids ORBit's pitfall with adapter activators by additionally adding the full POA name, in case the POA is inactive.
TAO also implements collocation optimizations using a collocation proxy. However, unlike in MICO, TAO's collocation proxies are separate from the normal stub and only forward the method invocation to the servant [51], and do not determine the servant's readiness to receive requests. Again, the ORB and the POA are bypassed. In order to provide correct behavior, the -ORBcollocation command-line switch can be used to disable collocation optimization altogether - but TAO defaults to potentially unsafe direct calls.
Unfortunately, TAO uses an alternative C++ mapping, because it still supports old C++ compilers without exception support.5.7 In an object implementation, methods take an additional parameter to carry an exception. While client code could be exchanged between MICO and TAO, the first interoperability test with server-side source code failed.
With the necessary changes made, - adding a default parameter to each method in the object implementation - server code could indeed be ported and ran on the other ORB with the expected results.
In the evolution of commercial software, some design decisions cannot be reversed for the sake of backwards compatibility. Over time, it becomes ever more complicated to add new features that would have been straightforward to implement if old designs could be replaced.
For similar reasons, ORBacus is being largely rewritten to get rid of historic restrictions like an alternative mapping for C++ compilers without namespaces and the tight integration of the BOA into the ORB. The latest available version was the 4.0a2 alpha release; the final version 4.0 is promised to comply to CORBA 2.3.
Already, the POA support seems reasonably complete, no omissions could be found. Missing is an Implementation Repository; while persistent objects are supported and properly implemented, their servers must be started manually.
Like ORBit and TAO, ORBacus bypasses ORB and POA in its implementation of collocation optimizations, with the slight improvement that at least the POACurrent interface reflects the invocation in progress.
No provisions for legible object keys for use with the Interoperable Naming Service exist.
Unlike TAO, ORBacus uses the normal C++ mapping, and so it was possible to exchange both client and server source code between MICO and ORBacus. The one item that still needed changing in both client and server source code were the names of IDL-generated include files, which are not prescribed by the specification and can therefore vary between ORBs.
The comparison of ORBit, TAO and ORBacus demonstrates that despite the apparent standardization of the CORBA platform, each ORB is individual with its own ideas and intentions.
|
Table 5.1 shows the POA-related features highlighted in this chapter and whether they are realized in the other ORBs. A (yes) in parenthesis means that the feature exists but has not been fully implemented or requires vendor-specific extensions.
For fairness, it should be added that the table does not list other ORB features like real-time support or multithreading which are available in other ORBs but not in MICO - but such features are beyond the scope of this thesis.
[Previous: Collocation] [Next: Evaluation]
[Up: Reference Implementation]