Re: newbie: javaspace implementation protocols used
Gregg Wonderly <[email protected]>
| Newsgroups | gmane.comp.java.sun.javaspaces |
|---|---|
| Message-ID | <[email protected]> |
xaea alvein wrote:
> from what i read at artima website, it seems that if i am to create a
> javaspace implementation that is reachable by clients using RMI, RPC, or
> CORBA, then it is my responsibility to create an implementation of
> javaspace
> that uses those protocols. it depends on me and my implementation, not how
> the clients try to connect to my javaspace implementation. is it true?
Javaspaces is a Jini Service which can utilize all of the features of the JERI
stack to provide a way for external applications to connect to it via a JERI
based solution. You can create a proxy service for the Javaspace as well, but
that becomes more specific to just Javaspaces.
> then another questions that bother me, is outrigger using jeri as its
> protocol? and i want to know what kind of protocol used for another
> implementation, like gigaspace, or tspace. is there any javaspace
> implementation using RPC or CORBA or another well-known protocols? is it
> possible to create an implementation that can be reached by multiple
> protocols, say, RPC, RMI, and CORBA altogether?
The JERI stack provides the ability for you to replace the endpoint and
invocation layer with something else that can provide an inteface from the
world, into the 'RMI' environment that a Jini service is designed around. Have
a look at the net.jini.jeri package in Jini 2.1, and take note of the following
classes in particular.
net.jini.jeri.BasicJeriExporter
net.jini.jeri.BasicILFactory
net.jini.jeri.AbstractILFactory
net.jini.jeri.BasicInvocationHandler
These classes provide an insight into the mechanisms that a Jini service relies
on for inbound calls to reach into its JVM. The other piece of the puzzle is
the endpoint. Look at the following packages
net.jini.jeri.tcp
net.jini.jeri.ssl
net.jini.jeri.http
and see how they all provide a transport endpoint using a different protocol,
but which can be plugged into the stack such that the data comming in can be
handed to the invocation layer for its use.
It is trivial to write a proxy service to do protocol translations in most
cases. It is more work to provide the interworking in the JERI stack. But,
that is what it is there for. If people will use it, and contribute back their
work, we'll have support for more transports and more invocation layers that
will make it much more trivial to use Jini in a wide range of environments.
Gregg Wonderly
===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS". For general help, send email to
[email protected] and include in the body of the message "help".
To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html