river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Split JavaSpaces and JINI
Date Wed, 10 Dec 2008 09:30:32 GMT
Gregg Wonderly wrote:
> Michael McGrady wrote:
>> Thanks, Holger,
>> The idea is not to jettison but to decouple JINI from JavaSpaces. 
>> Similarly, in part, various Web frameworks (e.g., Struts) are
>> decoupled from Servlets.  Without something like JINI, JavaSpaces
>> would be useless but this is different than creating a situation where
>> JINI itself, rather than something like JINI, would be required.
>> The idea too is not to suggest that JINI is something that needs to be
>> replaced.  The idea, rather, is that it needs to be decoupled to
>> follow architectural best practices and that the lack of cohesion in
>> JIN:-JavaSpaces due to the coupling is not a good thing and can be
>> seen as the reason for a lot of the unnecessary complexity in River.
> 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.
> Javaspaces is an API in the Jini platform.  Reggie is a service
> implementing the Javaspaces API, in River, which provides a piece of,

I think you meant Reggie implements the Lookup API or Outrigger is a
service implementing the JavaSpaces API.....

> and uses the Jini platform.
> There are 3 things in the Jini platform which the outrigger
> implementation of Javaspaces uses.  It registers with service discovery
> so that you can find it. It doesn't have to use reggie, any
> implementation, which implements the spec, will work.  It uses
> transactions and thus leasing to help manage the integrity of the
> system.  It doesn't need to have mahalo, but any transaction
> implementation that implements the spec.
> The sun provided LandLord leasing implementation is something that meets
> the spec for leasing.  Other implementations of the transaction/leasing
> spec would interroperate.
> It is possible to make outrigger buildable as a single "artifact" (maven
> or otherwise) so that it's not part of the River distribution (blitz is
> a Javaspaces implementation that demonstrates this separation from the
> platform).
> Outrigger has intimate dependencies on the Jini "platform" (service
> registration as a service, and transactions and leasing etc in the APIs)
> which mean that it is not "separable" from Jini without being something
> different than Javaspaces.
> Outrigger is separable from River as an artifact, but I am not convinced
> that this separation would be good, because then all the River
> infrastructure to actually use Outrigger would be another step needed to
> get it to work.
> Gregg Wonderly

View raw message