[Up: Reference Implementation]
[Previous: Reference Implementation] [Next: Design]

MICO

The MICO ORB [21] was used as platform for the reference implementation. MICO is an Open Source [46] CORBA implementation from the University of Frankfurt, originally designed and implemented by Arno Puder and Kay Römer. Version 2.2.7 was recently certified for CORBA 2.1 compliance by the Open Group [45] and therefore provided a solid and stable basis.

One design goal of MICO was to be easily extensible, as detailed in Kay Römer's thesis [55]. With its microkernel approach, the MICO core provides abstractions for object adapters, transports and schedulers. By derivation from abstract base classes, new components can be plugged in at runtime.

Figure 5.1: The MICO microkernel ORB

The microkernel ORB itself is reduced to the ``broking'' of requests. After a request is passed to the ORB from an invocation adapter (like the DII or SII), it simply tries all object adapters and asks whether they feel responsible for the request (see figure 5.1).

Figure 5.2: Remote invocation with a microkernel ORB

An object adapter is not restricted to adapting local objects: sending a request to a remote server satisfies the object adapter concept - the location of an appropriate servant - just as well. Consequently, MICO uses IIOP Proxy object adapters to address remote objects on the client side, and an IIOP Server invocation adapter on the server side (figure 5.2). With this innovative design, the ORB is not aware of an object's remoteness - a remote invocation is merely a side effect of passing the request to the right object adapter.

While IIOP Proxy and IIOP Server implement IIOP, they do not transfer data by themselves, but use GIOP Connection objects to perform GIOP encoding, and finally use instances of Transport and TransportServer for unidirectional^5.1 data transfer.

With this modular approach, the ORB is indeed easily extensible, as each component can be replaced. A new transport, for example one that compresses GIOP data before sending, can be added just by subclassing the Transport class and providing methods for reading and writing data.

The interface for object adapters is of particular interest here, as it will be used to add the Portable Object Adapter. To the MICO core, an object adapter must provide a small interface of three methods:

• Location: on the basis of an object reference, an object adapter must decide whether it can or cannot serve that object, i.e. if its servant is registered with that object adapter. Since MICO allows many object adapters to coexist, the ORB needs this location mechanism to choose the right object adapter in order to dispatch an invocation.
• Invocation: once an object has been located, the ORB asynchronously passes the request to the object adapter. Once request processing has finished, the object adapter notifies the ORB and returns the result.
• Cancellation: to cancel a request during execution.

MICO already fully implemented the Basic Object Adapter with all its activation policies, while taking its own liberties with the specification. A special BOA Daemon was used to contain the Implementation Repository and to activate implementations on demand. To allow object persistence, object implementations could overload the method ``_save_object()'' and later install special restoration objects.

Like other CORBA implementations, MICO decided to make the BOA as invisible as possible; the BOA was not so much programmed as simply ``there somewhere.'' As only user-callable methods, impl_is_ready and friends remained, but more or less stripped of their original meaning, as they were usually called without any parameters. Server programming with the MICO BOA is described extensively in its manual [50]. Optionally, MICO allows to bypass the BOA Daemon and the Implementation Repository, and to connect clients directly to their servers.

Also realized as object adapters are the OAMediator and POAMediator objects from the BOA Daemon, which receive requests for persistent objects and forward them to a running server. More on this appears in section 5.4.

Implementing the Portable Object Adapter consisted of four different parts:

• Providing the framework, such as type definitions and base classes for static and dynamic skeletons.
• Implementing the POA itself, and registering it through the generic object adapter interface.
• Modifying the IDL code generator to reflect the changes in server-side skeleton classes.
• Support for persistent objects and the on-demand starting of servers.

[Previous: Reference Implementation] [Next: Design]
[Up: Reference Implementation]