TABLE OF CONTENTS In many cases, an invoked object and its caller do reside in different processes, often executed on different computers connected by a network. In order to enable such invocations across process boundaries and over the network, appropriate meachanisms and protocols are needed to support interoperability of these processes.
In earlier CORBA specifications (before version 2.0), these issues were left to the vendors of CORBA products. Indeed, different CORBA products contained different, incompatible protocols for invoking methods accross process boundaries. However, in many practical settings it is desireable to use different CORBA implementations for the client(s) and object implementation(s) (e.g., supporting different programming languages). In order to enable interoperability between different CORBA implementations by different vendors, CORBA 2.0 introduced a general interoperability architecture that supports interoper-ability between different CORBA ORBs.
We start this chapter by looking at the model that serves as the basis for interoperability in CORBA and at the corresponding protocols specified by CORBA. We then describe how this framework has been adopted by Mico based on the microkernel ORB described in Chapter 5.
Objects as basic units With respect to interoperability, objects are considered an indivisible whole. Consequently, for example, all methods of an object can be invoked through the same access mechanism. Nevertheless, objects can vary considerably in terms of their interoperability characteristics. Following are some examples of such characteristics:
Interoperability characteristics of objects Middleware platform in which an object exists
CORBA implementation in which an object exists
Protocol used to access an object
Security...
