Previous Up Next

Chapter 14  Portable Interceptors

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:

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.

Previous Up Next