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