Sponsored Link •
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.