IBM User Guide for Java V7 on Windows > IBM SDK for Java > The ORB > Additional features of the ORB



Portable interceptors

You can include "interceptor" code in the ORB processing flow. The CORBA 2.4.2 specification standardizes this code mechanism under the name "portable interceptor".

CORBA implementations have mechanisms for users to insert their own code into the ORB processing flow. The code is inserted into the flow at "interception points". The result is that the code, known as an interceptor, is called at particular stages during the processing of requests. It can directly inspect and even manipulate requests. Because this message filtering mechanism is flexible and powerful, the OMG standardized interceptors in the CORBA 2.4.2 specification under the name "portable interceptors".

The idea of a portable interceptor is to define a standard interface. The interface enables you to register and run application-independent code that, among other things, takes care of passing service contexts. These interfaces are stored in the package org.omg.PortableInterceptor.*. The implementation classes are in the com.ibm.rmi.pi.* package of the IBM ORB. All the interceptors implement the Interceptor interface.

Two classes of interceptors are defined:

Request interceptors

The ORB calls request interceptors on the client and the server side, during request mediation. Request interceptors manipulate service context information.

Interoperable Object Reference (IOR) interceptors

IOR interceptors are called when new object references are created. The reason is that service-specific data, in the form of tagged components, can be added to the newly created IOR.

Interceptors must register with the ORB for the interception points where they are to run.

Five interception points are available on the client side:

Five interception points are available on the server side:

The only interception point for IOR interceptors is establish_component(). The ORB calls this interception point on all its registered IOR interceptors when it is assembling the set of components that is to be included in the IOP profiles for a new object reference.

A simple interceptor is shown in the following example: 

public class MyInterceptor extends org.omg.CORBA.LocalObject
	implements ClientRequestInterceptor, ServerRequestInterceptor
{
	public String name() {
		return "MyInterceptor";
	}

	public void destroy() {}

	// ClientRequestInterceptor operations 
	public void send_request(ClientRequestInfo ri) {
		logger(ri, "send_request");
	}

	public void send_poll(ClientRequestInfo ri) {
		logger(ri, "send_poll");
	}

	public void receive_reply(ClientRequestInfo ri) {
		logger(ri, "receive_reply");
	}

	public void receive_exception(ClientRequestInfo ri) {
		logger(ri, "receive_exception");
	}

	public void receive_other(ClientRequestInfo ri) {
		logger(ri, "receive_other");
	}

	// Server interceptor methods 
	public void receive_request_service_contexts(ServerRequestInfo ri) {
		logger(ri, "receive_request_service_contexts");
	}

	public void receive_request(ServerRequestInfo ri) {
		logger(ri, "receive_request");
	}

	public void send_reply(ServerRequestInfo ri) {
		logger(ri, "send_reply");
	}

	public void send_exception(ServerRequestInfo ri) {
		logger(ri, "send_exception");
	}

	public void send_other(ServerRequestInfo ri) {
		logger(ri, "send_other");
	}

	// Trivial Logger 
	public void logger(RequestInfo ri, String point) {
		System.out.println("Request ID:" + ri.request_id()
			+ " at " + name() + "." + point);
	}}

The interceptor class extends org.omg.CORBA.LocalObject. The extension ensures that an instance of this class does not get marshaled, because an interceptor instance is tied to the ORB with which it is registered. This example interceptor prints out a message at every interception point.

You cannot register an interceptor with an ORB instance after it has been created. The reason is that interceptors are a means for ORB services to interact with ORB processing. Therefore, by the time the init() method call on the ORB class returns an ORB instance, the interceptors must already be registered. Otherwise, the interceptors are not part of the ORB processing flow.

You register an interceptor by using an ORB initializer. First, you create a class that implements the ORBInitializer interface. This class is called by the ORB during its initialization. 

public class MyInterceptorORBInitializer extends LocalObject
	implements ORBInitializer
{
	public static MyInterceptor interceptor;

	public String name() {
		return "";
	}

	public void pre_init(ORBInitInfo info) {
		try {
			interceptor = new MyInterceptor();
			info.add_client_request_interceptor(interceptor);
			info.add_server_request_interceptor(interceptor);
		} catch (Exception ex) {}
	}

	public void post_init(ORBInitInfo info) {}}

Then, in the server implementation, add the following code: 

	Properties p = new Properties();
	p.put("org.omg.PortableInterceptor.ORBInitializerClass.pi.
																	MyInterceptorORBInitializer", "");
	...
	orb = ORB.init((String[])null, p);

During the ORB initialization, the ORB run time code obtains the ORB properties with names that begin with org.omg.PortableInterceptor.ORBInitializerClass. The remaining portion of the name is extracted, and the corresponding class is instantiated. Then, the pre_init() and post_init() methods are called on the initializer object.


Parent: Additional features of the ORB








Error 404 - Not Found

Error 404 - Not Found

The document you are looking for may have been removed or re-named. Please contact the web site owner for further assistance.