river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Split JavaSpaces and JINI
Date Mon, 22 Dec 2008 21:59:23 GMT
Michael McGrady wrote:
> JINI, in your world, wants Entry, Transaction, etc interfaces in JINI 
> that multiple services employ so these services are JINI services.

Well, Entry, Transaction and Lease, are core concepts to the distributed 
computing model that the name Jini is tied into.  These are "facilities" that 
allow clients/services to have advanced notice of how they will interact with 
others.  This includes a number of concepts from a number of different 
perspectives.  There are the API signatures, which spell out what values and 
types are understood by both ends.  There is the Jini spec, which details what 
each "operation" needs to make happen for the things that the API represents 
from the Jini spec.  There are failure mechanisms that you have to support in 
your client so that you can take advantage of knowing that something is not 
working.  It's important to understand that with Jini, you have a platform for 
remote, distributed computing that doesn't leave you wondering about how you 
will interact with other clients and services that use Jini.

There is the expansion point provided by JERI which allows the invocation layer 
and transport layer to be non-java centric.  This is where WINI, XINI, YINI and 
ZINI need to be interfaced.  Why?  Because the spec has semantics in it too, and 
those semantics (like RMI call-by-value) need to be supported at the Java 
interface level for a Java written Jini bit of software to be compatible with 
other Jini bits of software.

In the world of SOA, there are all these concepts, but they are described 
independent of a technology, and they are honestly more akin to "best practices" 
than they are as "architecture."   With the Jini spec, came the codification of 
so many important and related concepts which are all about making distributed 
systems be resilient and robust.

> JavaSpaces, in my world, wants its Entry, Transaction, etc interfaces in 
> JavaSpaces so that JINI must compete with WINI, XINI, YINI and ZINI in 
> using the JavaSpaces.

Make sure you are staring at what is presented as the JavaSpace spec, and not 
what outrigger is doing in exporting a JERI endpoint which uses 
BasicILFactory...  Any external entity can use JavaSpace if it has access to an 
invocation environment that allows it to.  JERI allows plugability so that 
others can get in, without being Java even.

The services in River are implementations of the spec.  They are not the only 
way to do that and they have a particular orientation toward working together 
and utilizing each other for a combined system that presents all the concepts of 
the Jini specs as a unified distributed systems toolkit.

The original name for what is in River now, was the Jini Technology Starter Kit 
or JTSK.  There is no mention of "reference" or "definitive" or "only" in that 
name, for good reason.

> What to do?

Realize that your world has a non-zero intersection with other peoples worlds in 
terms of what "features" you want your distributed application to have.  The 
features that the intersection encompass have to live somewhere where we can all 
enjoy and use them.  When there is distinct value in a change, people tend to 
agree or gravitate toward that change.  When there is a lot of discomfort in a 
change people tend to push back.  Discomfort comes from more than "that's the 
name it's had for years" in this case.

Gregg Wonderly

Mime
View raw message