One of the non standard features (API) provided by CAROL is the possibility to instantiate, for a Java server, an implicit context propagation. This API is very useful for security and transaction behavior. This API is a simplification of CORBA portable interceptor concept. Therefore, this feature use a server and client interceptor with an initializer registering mechanism. This mechanism is pure Java without any CORBA classes connection (only the rt.jar classes is needed). This mechanism works with 1.1 and 1.2 RMI version. This section explain the way to build, register and use server and client interceptor through RMI JRMP.
Implementing JRMP interceptors is very easy. A server interceptor only
need to implements the
JServerRequestInterceptor
interface and use the
JServerRequestInfo
interface to propagate a
JServiceContext
. On the client side this is the
same concept with JClientRequestInterceptor
interface and JClientRequestInfo
interface. For
propagation, a CAROL propagation context need only to be a
Serializable (or Externalizable) object and to implements the
interface JServiceContext
.
A JRMP client interceptor is a class implements the
JClientRequestInterceptor
. All the methods in
this class are executed in the same Thread than the client remote
call. All JServiceContext registered in the JClientRequestInfo (in the
send_* methods) are send to the Server. All JServiceContext send by
the server can be found in the JClientRequestInfo (in the receive_*
methods).
A JRMP server interceptor is a class implements the
JServerRequestInterceptor
. All the methods in
this class are executed in the same Thread than the server remote
call. All JServiceContext registered in the JServerRequestInfo (in the
send_* methods) are send to the Client. All JServiceContext send by
the client can be found in the JServerRequestInfo (in the receive_*
methods).
For each call,A CAROL JServiceContext can be find with is context_id. A JServiceContext is just a Serializable Object. For performance reason, it can be interesting to decrease the Context size by using a Externalizable mechanism. Carol provide a tool (org.objectweb.carol .util.perfs .CarolJRMPPerfomanceHelper) with static methods to calculate the Serializable size of a Serializable object.
To register interceptor in CAROL is very easy. A server/client
initializer implements the JInitializer
and use
the pre_init and post_init methods for registering server and client
interceptors through JInitInfo
interface. For
JVM CAROL JRMP initialization, use the
org.objectweb.PortableInterceptor.JRMPInitializerClass.XXX
property where XXX is the JInitializer full classname (for example
pass
-Dorg.objectweb.PortableInterceptor.JRMPInitializerClass
.org.objectweb.carol.rmi.jrmp.interceptor.ProtocolInterceptorInitializer
register into CAROL the
ProtocolInterceptorInitializer
class). Register
more than one JInitializer is possible with CAROL (The
ProtocolInterceptorInitializer
is mandatory for
CAROL multi protocol management).
The second non standard CAROL features is a way to register Referenceable/Reference and Serializable objects in a CosNaming through JNDI. The IIOP InitialContext delivered for IIOP wrap the Referenceable/Reference or Serializable object into a standard remote object. This remote object is exported into the JNDI context bind(or rebind) method and unexported into the JNDI context unbind method. CAROL use automatically, on the server side, this mechanism with a standard CAROL IIOP configuration (you need to call the IIOP protocol 'iiop' in the carol.properties file see the CAROL configuration chapter).
For a JNDI java RMI IIOP client you can use the
IIOPContextWrapperFactory
by setting the
-Djava.naming.factory.initial jvm properties (with
the full name of the factory). This factory builds a JNDI Context based
on you jndi.properties uses the wrapping
mechanism. For other client (Non JNDI), you can re-build manually the
Referenceable or Serializable object for the CosNaming wrapper remote
object (see inside the IIOPContextWrapper
class
for a detailed mechanism. A CAROL server can be also an IIOP CAROL
client without any extra configuration than in a classical IIOP CAROL
server.
The third non standard CAROL features is a way to start and stop
automatically RMI Name Services. This mechanism is based on a API/SPI
system. The API is represented by the
org.objectweb.carol.jndi.ns.NameServiceManager
. This
class provide static methods for start and stop configured name services
for each protocol. A CAROL configuration property can be set inside the
carol.properties for automatically start all non started and configured
Name Services (see the configuration chapter). Carol provide also three
Name Service SPI implementation for RMI Registry, Jeremie Registry and
CosNaming management. This mechanism start those Name Services on the
port defined by the jndi url property.