508 DISTRIBUTED OBJECT-BASED SYSTEMS CHAP. 9
implementations and were given minimal support in the form of a basic object adapter. Unfortunately, this minimal support also led to portability problems, which by now have been solved by giving a more complete and better specification of what an object adapter should offer. Below, we take a closer look at client-side and server-side software in CORBA.
Clients
As previously mentioned, CORBA’ s client-side software is kept to a minimum. The IDL specifications of an object are simply compiled into a proxy that marshals invocation requests into, for example, IIOP Request messages, and unmarshals the corresponding Reply messages into results that can are handed back to the invoking client.
Proxies in CORBA have no other task than to connect a client application to the underlying ORB. Instead of generating an object-specific proxy, a client can also dynamically invoke objects through the DII.
The consequence of this approach is that if an object requires a specific client-side implementation of its interfaces, it will have to either instruct the developer to use an IDL compiler that generates that software, or provide the client’ s proxy itself. For example, an object implementation could be accompanied by a set of proxies that implement an object-specific client-side caching strategy. Of course, the latter approach is totally out of line with CORBA’ s objective of portability and distribution transparency.
Another approach is to forget about object-specific matters and to rely on a client-side ORB that provides the necessary support. For example, instead of providing a cache contained in the client’ s proxy, an object implementation could assume that caching is handled in a general way by the client’ s ORB. Again, it should be clear that such an approach has inherent limitations.
What is needed is a mechanism to use the proxies as generated by an IDL compiler in combination with an existing client-side ORB, but nevertheless be able to adapt the client-side software when needed. CORBA’ s solution to this problem is to use interceptors. As its name suggests, an interceptor is a mechanism by which an invocation can be intercepted on its way from client to server, and adapted as necessary before letting it continue. In essence, an interceptor is a piece of code that modifies an invocation request on its way from client to server, and accordingly adapts the associated response. There may be various interceptors added to an ORB. Which one is actually activated depends on the object or server that is referenced in an invocation request.
An interceptor in CORBA can be placed at either one of two different logical levels, as shown in Fig. 9-10. A request-level interceptor is logically placed between a client’ s proxy and the ORB. Before an invocation request is passed to the ORB, it first passes through an interceptor, which may modify the request. On the server side, a request-level interceptor is placed between the ORB and the