Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Service-context propagation over RMI: Implementation follow-up

A protocol-independent lightweight framework for providing service-context propagation and interceptor support over RMI

By Wenbo Zhu, JavaWorld.com, 04/04/05

My article "Service-Context Propagation over RMI" (JavaWorld, January 2005) introduces service-context and interceptor concepts common in CORBA-based solutions. The article also defines a generic design approach for supporting such concepts in Java Remote Method Invocation.

As a follow-up, this article describes a concrete implementation of a lightweight and protocol-independent framework for providing generic interceptor support and service-context propagation over RMI. The goal of this article is to highlight important design approaches and answer questions that readers may have after having read the previous article. More importantly, the implementation illustrates what makes a framework and demonstrates the value for having a protocol-independent solution. The source code for the implementation is available on SourceForge.net. The SourceForge project is an ongoing effort. The first release serves as this article's main reference.

The design layout

The most important part of this article's framework is the support of an interceptor, which is required on both the client and server. On the client-side, the interceptor is invoked by a client-side RMI stub proxy, which is a dynamic proxy that I will discuss later. Figure 1 gives an architectural view of the target RMI interceptor design.

Figure 1. RMI interceptor architecture

As shown in Figure 1, upon each RMI invocation, interceptors control the flow of each request and reply between the client stub and server skeleton. In general, the interceptor is stateless and reentrant. It is deployed per JVM (classloader) and reused by every stub and skeleton, which are simply logical components here and may or may not be visible to application code.

Figure 1 ignores the exception flow, and the actual interception flow is in fact more complicated, as illustrated in Figures 2 and 3, which describe what occurs on the client and server, respectively.

Figure 2. Client-side interceptor control flow

 

Figure 3. Server-side interceptor control flow

For each RMI invocation, multiple interceptors are invoked in a determined order. On the client, the interception point sendRequest() serves as a starting point and receiveReply() serves as an end point. An end point is invoked only if the corresponding starting point of the same interceptor has run to completion. An exception may be injected from both the wire and the interceptor itself. The same rule applies to the server: the starting point is receiveRequestServiceContexts instead. For all server-side interceptors, receiveRequestServiceContexts interception points run first.

An interceptor's design and API follow the latest CORBA Portable Interceptors specification wherever applicable to Java RMI. Figure 4 defines the interface RMIInterceptor.

Figure 4. RMIInterceptor class diagram

In this extended RMI framework, interceptors are managed as a stack flow. The relative order of interceptors is insignificant, and interceptors should be designed so they don't depend on each other and can function in isolation. However, once deployed, the invocation order of multiple deployed interceptors is determined. Between the client and the server, the order may differ. Also, some interceptors may apply only to the client or only to the server.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.