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
