river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Split JavaSpaces and JINI
Date Tue, 09 Dec 2008 16:35:04 GMT
----- Original Message ----

> From: Niclas Hedhman <niclas@hedhman.org>
> To: river-dev@incubator.apache.org
> Sent: Tuesday, December 9, 2008 1:35:25 AM
> Subject: Re: Split JavaSpaces and JINI
> On Tue, Dec 9, 2008 at 3:38 AM, Gregg Wonderly wrote:
> > Okay, I think there needs to be a viewpoint expressed here that comes from a
> > different direction.  Jini is not all the services in River.  Jini is the
> > foundation/API in River, which allows you to create clients and services.
> >  These utilize the Java security system, Java mobile code, and the Java
> > platform, in general, to effectively (and I'd say efficiently) create
> > distributed, scalable network centric applications.
> We hear ya; but relax a second,
> 1. Spaces as a concept is not bound to Jini.
> 2. A Spaces API can likewise be Jini-agnostic.
I would say considering its packages and classes and those used in method signatures it is.
At least now anyways. Now, if you mean not bound to everything in Jini then sure. Such an
implementation could not have everything in Jini as a whole such as services, and even some
packages. I would think more modularization would fix some of that though.

> 3. Outrigger (the Jini backed Spaces implementation) *could* implement
> the above mentioned Spaces API as well.

Sure, but why necessarily? What exactly is the proposal? Do you mean to just support POJOs
in the lookup and you mean to get rid of Entry?

> 4. A LocalSpaces implementation *could* exist for various reasons.
> 5. Other Spaces implemenations *could* exist for various reasons.
> Example; Go to www.jpos.org, which deals with Payment Gateways (VISA
> et al), and you will find several local implementations of spaces as a
> programming model. Alejandro doesn't need it to be distributed, but to
> simplify the domain. He almost included JavaSpaces as well, but for
> the reasons mentioned here (not easy to integrate seaminglessly into
> other applications), he back paddled many years ago.

Yes, but per your own argument it *seems* his reason had nothing to do necessarily with the
Jini APIs as much as it had to do with taking those things and bringing them in and complexity,
or at least perceived complexity if not just having to include bigger JARs than someone wanted.
A LocalSpaces implementation already exists, and uses the Jini APIs, just doesn't use all
the services etc according to what I have read on the lists; I haven't used it, but looking
at all the Jini APIs as they are interfaces and abstract classes at the lowest levels one
can get an idea for what can be done. Other implementations can do the same. Whether Spaces
is using Entry or some other API classes it is still an API. 

Take many Apache libraries such as NET. It has FTP, HTTPS, and others. Or for instance, take
the virtual file system. They all have this or that API, and they depend on other things,
just because you use one part of the API doesn't mean you have to use them all, but you do
get them all in a JAR file. Some other things you have in other JAR files as dependencies
which you never need because you don't call specific code.

Gregg's point is that for a Spaces implementation, the APIs provide what one needs to use
them as JavaSpaces, and to meet the specification or API level specification, and this involves
more than than simple in memory Lookup. If one just needs a simple lookup and store or object/event
bus type system they can find many other libraries such as NetBeans Lookup API which lets
one store entries by class type (SomeClass.class) locally, or, they can write their own very
fast and easy though Lookup has a lot of other things such as support for META-INF/services
lookup and creation (SPI). Either way, if that is all one needs something like Lookup may
be better, leaner, faster, and would fit such a Local need better than a JavaSpaces implementation,
though if Jini had some other implementations in the APIs it would be just as easy to include
it and use it. If they really need a Spaces implementation it is very easy to use the Jini
APIs now to do all kinds of
 custom things. Most of them are just interfaces.

For me, I would rather not try to make all Jini's libraries so broken out and decoupled that
it looses its intended meaning and becomes a nightmare with no compile time checks for the
use cases, which it seems we need a new JavaSpaces05 implementation which uses Generics. From
that perspective JavaSpaces and the core Jini libraries and interfaces are rather simple already,
and one can take any of those interfaces and abstract classes and make all kinds of custom
things. If you were to try to decouple Entry and Transaction from JavaSpaces you would end
up with something entirely different it seems, and it wouldn't be JavaSpaces technically,
it at least would not be backward compatible, but maybe that doesn't matter so much, but I
bet many of the folks with large investments in Jini will certainly think it matters.

Now, breaking things out more modular and into smaller and smaller JARs I can see. Then one
could take those core interfaces or other things and have smaller libraries which different
custom things could be done. Seems this is a more realistic goal unless you mean to change
lookup, spaces, etc all to support different templates/entries such as a POJO model or something.
Of course, other methods can be added and retain binary compatibility which just provide other
ways of looking up information or services.

I guess the real issue with the debate is more specifics are needed such as what exactly,
less breaking things out into smaller and smaller more modular units, is actually making local
spaces and custom spaces harder to implement. They are JavaSpaces implementations after all
and not an object/event bus only. The provided services and applications with Jini, we seem
to have consensus, need to have better deployment and usability capabilities, we need better
development tools, a better build system, source structure, some installers maybe, etc. So,
the specifics on what these changes would actually intail, and why those things folks are
wanting to do can't be done now seem more logical for proving the exact needs. 

I haven't seen the cohesive reason yet is the point I'm getting at here; having some extra
interfaces in a JAR which holds JavaSpaces and the rest of Jini doesn't seem at all a big
deal to me per all reasons stated above. I'm trying to understand, but as far as I can tell
now those JARs will be small and usable if we break things out like we've been talking, and
things are very customizable now though we don't have many different implementations to be
used for different purposes at the moment such as a Local spaces implementation where no lookup
of the space etc is needed, and maybe that is the real issue?


Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team
Member, and NetBeans Board Member

View raw message