Alexander Johannesen wrote:
>
>
> On 12/17/06, Gregg Wonderly <[EMAIL PROTECTED] <mailto:gergg%40cox.net>>
> wrote:
> > I think it depends on what you are doing.
>
> Of course. But isn't JERI Java specific? And isn't part of the SOA
> dream (and not the general reality) to be decoupled from specific
> platform technologies?
Okay, I'll say this again, but with more detail, to hopefully make it
plainfully
clear what JERI really is/means in a conversation about using it with Jini. In
the JERI design there are 4 key interfaces at the network/wire protocol point
(points of variation in implementation of remote communications).
Endpoint - Represents a remote communication endpoint to send requests to.
ServerEndpoint - Represents one or more communication endpoints on the
current (local) host to listen for and receive requests on and a
template for producing an Endpoint instance to send requests to
those communication endpoints.
OutboundRequest - Represents a request that is being sent and the
corresponding response received in reply.
InboundRequest - Represents a request that is being received and
the corresponding response to be sent in reply.
One layer above these, if you have Java code that could benefit from an
invocation layer abstraction, is the invocation layer where there is:
InvocationDispatcher - An abstraction used to handle incoming call
requests for a remote object.
InvocationHandler - The java.lang.reflect.InvocationHandler used
on clients to make outbound calls using a java.lang.reflect.Proxy
Object that is the service's remote implementation.
Above that basic layer of call abstration are the concrete implementations that
most Jini 2.0 and later services would use out of the box. The majority of the
details are hidden/abstracted away by the use of the Exporter mechanism. A
deployer would configure an Exporter that would specify the invocation layer
factory and the endpoint implementation so that the code just reads as.
// get the configured exporter
Exporter exp = (Exporter)config.getEntry(getClass().getName(),
"exporter", Exporter.class );
// export this object as the service
ServiceIntefaces remobj = (ServiceInterfaces)exp.export( this );
and remobj would be the remote implementation object that I'd send to clients
for them to use. If the remote client was not a Java client capable of
downloading code, then that exported object might be something different.
When I say I am using JERI. I have implemented the use of the Jini
Configuration facilities to allow my service and client to use any
implementation of these interfaces. By default, I might use one that provides
Java object serialization because I don't have to do anything to make that work
out of the box.
By doing this, I maintain the Java based programming paradigm and the RMI model
for remote method invocation (all methods throw RemoteException and all
parameters are passed as values, not references unless exported to be remote
reference values).
If I wanted to, I could plug in a ServerEndpoint implementation which provided
my service implementation as a WS-* endpoint, or a RESTful endpoint.
> > So, http plays an extremely small, and not necessary part of all of
> my systems.
>
> But you're strange, so that doesn't count. :) Actually, the Jeni/JERI
> stack is certainly interesting, and on my todo list, as soon as I
> think a marrige to Java is Ok.
You have to implement services in Java to make easy use of Jini. But Jini
services can talk to arbitrary clients because of the abstractions that can be
provided by variations in endpoint and invocation layer implementation.
Gregg Wonderly
