4Application of object-oriented technology is motivated by the desire to have re-usable software components that interact through well-defined interfaces[YD96]. A step towards such a software communication bus is the Object Management Architecture (OMA)[Vin97] that is standardised by the Object Management Group (OMG). This independent organisation produced a reference architecture for transparent communication between application objects, called Common Object Request Broker Architecture (CORBA)[Gro98b]. Its structure is depicted in figure 20. This communication model serves as the basis of the OMA, which incorporates four components in total: (i) Object Request Broker, (ii) Object Services, (iii) Common Facilities and (iv) Application Objects. The Object Request Broker acts as the backbone for the latter three parts. Messages between ORBs are exchanged using a generic protocol, The General Inter ORB Protocol(GIOP). It has to be mapped to a concrete transport layer. Up to now the only existing mapping is the Internet Inter ORB Protocol (IIOP), which is based on communication using the socket interface to the TCP/IP transport protocol suite. Object Services define additional functions such as naming or concurrency control. Facilities represent guidelines for building blocks targeted to special environments. They are split horizontally into different concerns, e.g. user interface or data exchange issues. Vertical slices represent sets of components for the environments such as oil industry or workflow management. Those facilities are not complete. With new upcoming user requirements, proposals for new facilities are submitted. The application objects have to be provided by CORBA users. In order to be independent of platform and implementation language, objects that shall communicate using a CORBA compliant ORB are declared using an interface definition language (IDL). Mappings to several programming languages exist, so that the application programmer can provide an implementation for the object. Controlling the definition of interfaces in a platform independent way remains the key to interoperability. Data structures are no longer machine data type specific. From the IDL specification of an object interface, a stub can be produced for an implementation language. An example of an object invocation trace can be seen in figure 21. Before the client stub can be called by the user application, the servant representing the object implementation has to publish a reference to itself to the client. How this is done is not specified. Possibilities include naming services, URL like addressing or object identifiers stored in files. On top of these, higher level mechanisms as specified in the CORBA Services can be used to obtain references to the object implementation. Examples are the Trader or the Event Service (a publisher-subscriber scheme). Once a valid object reference is obtained, the stub can be invoked by the client application and will take care of forwarding the upcall to the object implementation. This implementation is enclosed in a skeleton that has been produced from the IDL specification as well. Thus the language in which the object is implemented need not necessarily be the same as the one from which the object is called. Such procedure resembles the Proxy pattern. The stub serves as a placeholder, a proxy for the object implementation. The difference is that in the CORBA world an instance of the proxy class does not truly reflect an specific instance of the servant class. A proxy object is bound dynamically to a servant. The proxy accepts method invocation requests for it and delegates them to the bound server through the object request broker. The process of associating the proxy instance with its servant, called binding[Hen98] is done at run-time by obtaining a reference for the object that has to be invoked. Once the binding exists the call is routed to the destination. Due to the dynamic nature of the binding procedure, the object implementations are triggered by a single multiplexor on the destination side, the Object Adapter. It determines to which object the request belongs and activates it. The new Portable Object Adapter definition allows several policies, such as activation on demand or object identifiers with a lifetime longer than the server process[PS98]. Furthermore it allows the restriction of a single servant to be overcome by having user-supplied server side activation managers[SV98]. It is worth noting that the interface of CORBA components are themselves specified in IDL. By this means, a higher degree of portability is achieved.
