Chapter 14  Portable Interceptors

• IOR Interceptors
• Request Interceptors
• The PICurrent Object

Early CORBA products were monolithic: when you bought a CORBA product you could use whatever capabilities were built into the product, but you (or third party companies) had little opportunity to extend the range of capabilities that it offered. CORBA has since matured to provide a “plug-in” architecture that allows people to add new code to a CORBA product. A first version of this plug-in architecture was made available in CORBA 2.2 and it was called interceptors. The name came about because the plug-ins could intercept some of the ORB functionality to modify the ORB’s behavior. Unfortunately, the CORBA 2.2 interceptors were under-specified and this resulted in a non-portable API for their use. CORBA 2.4 provided a more complete definition and the result is now known as portable interceptors.

There are two types of portable interceptors: IOR interceptors and request interceptors. I provide a brief overview of each in turn in the following sections. A more substantial and very readable overview of portable interceptors can be found in the Pure CORBA book [Bol01].

14.1  IOR Interceptors

An IOR interceptor is called when an IOR is being created. The IOR interceptor can find out which policies were used in the object’s POA (see Chapter 6 for a discussion of POA policies) and can use this information to decide if it wants to embed an extra TaggedComponent (Section 10.2.3) into the IOR. For example, whether or not an object can take part in distributed transactions is determined by the use of a particular POA policy. If this POA policy is used then an IOR interceptor that is bundled as part of a transactional service will add a corresponding TaggedComponent to the IOR.

14.2  Request Interceptors

There are two types of request interceptor: one that deals with the client-side mechanics of sending a request and receiving a reply, and another that deals with the server-side mechanics of receiving a request and sending a reply. Obviously, if an application is both a client and a server then it could use both a client-side and serve-side interceptor. Unsurprisingly, the APIs for both client-side and server-side request interceptors have a similar look and feel.

A request interceptor is called at various points along the transmission of request and reply/exception messages. An interceptor may do the following:

• Examine the parameters of the request/reply/exception message that is being transmitted. An interceptor that does this and uses the DynAny APIs (Section 15.3) could write diagnostic messages to a log file for all incoming/outgoing messages.
• A server-side interceptor can find out the object id (Section 5.6.1) and POA (Section 5.5) of the target object. It could use this information to keep track of when the objects have been accessed by clients and then garbage collect objects that have not been accessed in, say, the last 20 minutes.
• Add a service context (Section 11.6) to an outgoing message or extract a service context from an incoming message.
• Examine the TaggedComponents of the target object. For example, a client-side interceptor that is used as part of an transactional service may check to see if the target object can take part in a transaction and, if so, add a transactional service context to the outgoing request.

14.3  The PICurrent Object

The portable interceptors specification defines a Current object (Chapter 13), which is called PICurrent because it is accessed by passing "PICurrent" as the parameter to resolve_initial_references() (Section 3.4.1). The main purpose of the PICurrent object is to provide a way for service contexts (Section 11.6) to be communicated between a portable interceptor and application-level code.