[Up: Reference Implementation]
[Previous: Other Implementations] [Next: Conclusions]
The reference implementation of the POA in MICO has in most areas verified the validity of the POA specification. The description of the POA's methods and their behavior is precise with little margin for error or misinterpretation, and in this respect, server-side interoperability is achieved.
Porting server-side code between ORB implementations is still not fully possible, though. Some ORBs like TAO continue to support old environments by using an alternate C++ mapping, but even if the same mapping is used, as in the case of ORBacus, the names of IDL-generated files differ, so that the include directives at the beginning of each source file need modification. If the names of generated files could be agreed on, client-side and server-side source code could indeed be transported between ORBs without any modification.
However, the required source file modifications are trivial compared with the porting of BOA-based code. The POA not only provides the programmer with a consistent interface, but also with consistent design, whereas the proprietary extensions that existed for the BOA as often as not required a complete redesign and rewriting of server code from scratch when being ported to a different ORB.
It is interesting and somewhat ironic that the one missing piece of the POA specification, the Implementation Repository, was removed with the BOA specification, so vendor-specific extensions are again required to support persistency.
But a distinction must be made between vendor-specific source-level extensions like additional methods to the ORB or POA, and vendor-specific administrative action. The latter can be deemed acceptable - each vendor should be able to define a custom set of commands and options, as long as the source code is portable.
It has been demonstrated that persistency and the synchronization of active servers with the Implementation Repository is possible without any source-level changes, but with administrative action only: The MICO daemon must be run, the implementation must be registered with the IMR, and the -POAImplName option must be added to a persistent server's command line.
The Interoperable Naming Service and its requirement of short and legible object keys is bound to cause more trouble. While the MICO POA takes care to use acceptable object keys by default, again without any ORB modifications as in TAO, the MICO solution relies on cooperation with the developer, who must choose the ``right'' POA names and Object Ids. The developer must rely on the MICO POA to construct the object key in a foreseeable manner. In this respect, the solution is just as unportable as TAO's added ORB method.
It is to be expected that each vendor's solution for constructing object keys will be different, so that service implementations that wish to publish an URI-style IOR are again non-portable.
Since both solutions, the generation of object keys or a new ORB method to keep an object key mapping table, are unlikely to be standardized, one idea would be the introduction of a new standard ``trivial'' object adapter. It could use Object Ids directly as the object key, with the sole purpose of forwarding incoming requests to the proper POA-based object.
[Previous: Other Implementations] [Next: Conclusions]
[Up: Reference Implementation]