The Artima Developer Community
Sponsored Link

Jini Extensible Remote Invocation
A Conversation with Bob Scheifler, Part VI
by Bill Venners
August 12, 2002

<<  Page 3 of 8  >>

Advertisement

Customizing the Layers

JERI allows customization of two of those three layers. The object identification layer is thin enough right now that it's not worth customizing. One place where we focused on customization is the transport layer. Now that is similar to what you can already do in JRMP today. In JRMP, you can customize with an RMI socket factory. So JERI is similar to JRMP there, although the JERI transport layer has been abstracted more so that it is not socket specific. We upleveled the transport layer so that if you want to implement non-socket, non-TCP transports, you can do that.

At the marshaling layer, we allow customization so you can pass implicit parameters, pass extra data, code the method differently, code the arguments differently, put in access control checks, or whatever you need to do. Basically, that whole area is being exposed. Now the simplest way to approach it is that we provide JERI a standard invocation handler.

To step back, one of the design aspects of JERI is that if we don't have precompiled stubs anymore. There is no RMIC equivalent for JERI. We've switched over totally to using dynamic java.lang.reflect proxies. And a generated java.language.reflect proxy class is roughly equivalent to a stub class. A dynamically generated proxy implements all the interfaces and delegates to this object called an invocation handler. The invocation handler essentially has one method called invoke that takes the method object and all the arguments. In JERI, there is a standard unicast invocation handler that has all the standard marshaling semantics, but all the various stages are exposed as protected methods. If you want to subclass an invocation handler to either override or augment the semantics of each of those steps, you can do so via subclassing.

And, similarly, on the server side for JERI there is a dispatcher that is the analog to the invocation handler. The dispatcher gets the invocation and is responsible for unmarshaling and then making the upcall to the actual remote object. There is a standard dispatcher that has all of the steps exposed as protected methods. On the server side if you want to augment or replace semantics you can subclass the standard dispatcher. If you want to completely replace it, you can implement your invocation handler and your own dispatcher.

It is a little funny to describe JERI as a protocol because it has pieces of protocol, but you can plug in your own pieces. You can completely replace pieces of the protocol if you want. It is more of an architectural protocol stack, if you will, and it has default implementations to give you a complete stack. But one aspect of it is to make it highly customizable.

<<  Page 3 of 8  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us