A BindInterceptor object is a global Interceptor which is called on the client side before and after binds.
A ClientRequestInterceptor object may be registered during a
bind_succeeded call of a
BindInterceptor object, and it remains active for the duration of the connection. Two of its methods are called before the invocation on the client object, one (
preinvoke_premarshal) before the parameters are marshaled and the other (
preinvoke_postmarshal) after they are. The third method (
postinvoke) is called after the request has completed.
A POALifeCycleInterceptor object is a global Interceptor which is called every time a POA is created (using the
create method) or destroyed (using the
destroy method).
An ActiveObjectLifeCycleInterceptor object is called whenever an object is added to the Active Object Map (using the
create method) or after an object has been deactivated and etherealized (using the
destroy method). The Interceptor may be registered by a
POALifeCycleInterceptor on a per-POA basis at POA creation time. This Interceptor may only be registered if the POA has the
RETAIN policy.
A ServerRequestInterceptor object is called at various stages in the invocation of a server implementation of a remote object before the invocation (using the preinvoke method) and after the invocation both before and after the marshaling of the reply (using the
postinvoke_premarshal and
postinvoke_premarshal methods respectively). This Interceptor may be registered by a
POALifeCycleInterceptor object at POA creation time on a per-POA basis.
If an org.omg.CORBA.SystemException or any sub-classes (for example
org.omg.CORBA.NO_PERMISSION) is raised on the server side, the exception should not be encrypted. This is because the ORB uses some of these exceptions internally (for example
TRANSIENT for doing automatic rebind).
An IORCreationInterceptor object is called whenever a POA creates an object reference (using the
create method). This Interceptor may be registered by a
POALifeCycleInterceptor at POA creation time on a per-POA basis.
When you call resolve_initial_references, the resolve on all installed services gets called. The resolve then can return the appropriate object.
To write service initializers, you must obtain a ServiceResolver after getting an
InterceptorManagerControl to be able to add your services.
To load your Interceptor, you must set the vbroker.orb.dynamicLibs property. This property can be set either in the properties file (see
“Using VisiBroker Interceptors”) or be passed into the VisiBroker ORB using the
-D option.
In “Code listings”, each of the Interceptor API methods is simply implemented to print informational messages to the standard output.
The ServiceInit class used in VisiBroker 3.x is replaced by implementing two interfaces:
ServiceLoader and
ServiceResolverInterceptor. For an example of how to do this, see
“ServiceResolverInterceptor example”.
Since the OAD is not running, the bind call fails and the server proceeds. The client binds to the account object, and then calls the
balance method. This request is received by the server, processed, and results are returned to the client. The client prints the results.
The SampleServerLoader object is responsible for loading the
POALifeCycleInterceptor class and instantiating an object. This class is linked to the VisiBroker ORB dynamically by
vbroker.orb.dynamicLibs. The
SampleServerLoader class contains the
init method which is called by the VisiBroker ORB during initialization. Its sole purpose is to install a
POALifeCycleInterceptor object by creating it and registering it with the
InterceptorManager.
The SamplePOALifeCycleInterceptor object is invoked every time a POA is created or destroyed. Because we have two POAs in the
client_server example, this Interceptor is invoked twice, first during
rootPoa creation and then at the creation of
myPOA. We install the
SampleServerInterceptor only at the creation of
myPOA.
The SampleServerInterceptor object is invoked every time a request is received at or a reply is made by the server.
The SampleClientInterceptor is invoked every time a request is made by or a reply is received at the client.
The SampleClientLoader is responsible for loading
BindInterceptor objects. This class is linked to the VisiBroker ORB dynamically by
vbroker.orb.dynamicLibs. The
SampleClientLoader class contains the
bind and
bind_succeeded methods. These methods are called by the ORB during object binding. When the bind succeeds,
bind_succeeded will be called by the ORB and a
BindInterceptor object is installed by creating it and registering it the
InterceptorManager.
The SampleBindInterceptor is invoked when the client attempts to bind to an object. The first step on the client side after ORB initialization is to bind to an
AccountManager object. This bind invokes the
SampleBindInterceptor and a
SampleClientInterceptor is installed when the bind succeeds.
Closure objects are created by the ORB at the beginning of certain sequences of Interceptor calls. The same
Closure object is used for all calls in that particular sequence. The
Closure object contains a single public data field
object of type
java.lang.Object which may be set by the Interceptor to keep state information. The sequences for which
Closure objects are created vary depending on the Interceptor type. In the
ClientRequestInterceptor, a new
Closure is created before calling
preinvoke_premarshal and the same
Closure is used for that request until the request completes, successfully or not. Likewise, in the
ServerInterceptor, a new
Closure is created before calling
preinvoke, and that
Closure is used for all Interceptor calls related to processing that particular request.
For an example of how Closure is used, see the examples in the following directory: