river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: Split JavaSpaces and JINI
Date Wed, 10 Dec 2008 16:03:37 GMT
Niclas Hedhman wrote:
> On Tue, Dec 9, 2008 at 11:53 PM, Gregg Wonderly <gregg@wonderly.org> wrote:
> 
>> JavaSpace is an interface.  That is the definition of a JavaSpace, plain and
>> simple.
> 
> No, that is incorrect. It is a semantic contract involving interfaces,
> the now infamous entry classes, exceptions, remoteability, and
> workflow (including an optional transactional workflow).

JavaSpace is an interface, and thus it can be implemented, stubbed off and done 
with as you please, including the argument types, which can be replaced in your 
classpath, taken from the jsk-platform.jar or whatever meets your needs.  You 
can create mirror copies in your own package, and use common techniques for just 
changing the import to your package etc.

All of the things that the "spec" say, can be made to exist without the network 
implications etc.

>> If you want to take outrigger and augment it with other APIs so that it can
>> provide access to the space through other means, that's something to debate
>> here.
> 
> Right now, JavaSpaces API(!) is bound to Jini Entry API and Jini
> Transaction API. To create a more generic Spaces API, both Entry and
> Transaction should abstracted into two bits, the generic semantic
> contract and the Jini-specific part (Entry may only be generic as it
> is fairly simple).
> 
> I don't see the above as neither complicated nor undesirable.

Then create a new interface/class hierarchy and do it.  The existing namespace 
does not keep you from doing this.  Does outrigger work this way?  No, it's a 
Jini service, not an in memory map.

> For instance; Assume for a second that we have these implementations
> in place, and that they are runtime swappable. In my code, I can now
> have a much leaner Test setup, which are likely to execute a lot
> faster and have less dependencies on the actual OS and network it is
> running on.

I fail to see how you can't implement JavaSpace as a test stub, please explain 
how it's not possible today.  I've done it before, and implemented alternative 
versions for various reasons...

> Opening up Spaces as a programming model (at local VM level) is
> another benefit, and I disagree with those that "Well, you can whip
> that up in a few hours on your own", and point out that "Yes, you can
> do that with most things, such as String, HashMap, Logging and a
> Inversion Of Control framework such as Spring." But we don't, because
> it takes longer than a few hours in reality, and we have better things
> to do if those things are 'just available for use' when I need them.
> Look at Apache. How many utilities can you find here that are useful,
> yet the basic implementation (when all the flexibility stuff has been
> stripped off) can be done in a seemingly short (hours) time frame? My
> guess is hundreds. This discussion is revolving around adding to that
> tradition.

I use java.util.concurrent.ConcurrentHashMap<<? extends Class>,Object> all the

time to do things locally.  As Wade described, this is at the core of Netbeans 
modularity.  The functions that are defined in the JavaSpace interface are 
similar to the typical Map design, but they include the remoteness aspect that 
makes it possible to use them in either way.  The java.util.Map interface can 
not be used in a remote application without augmentation for remoteness.

>> Jini, needs to have a JavaSpace in the distribution, and adding more
>> interfaces and complicating it, in that way, is what we should be under
>> discussion, not "taking javaspaces out of jini".
> 
> I agree that JavaSpaces in its current form (the distributed one
> backed by Jini) 

which is not JavaSpaces, but outrigger...an implementation of the API...
Really, we have both blitz and gigaspaces which can be substituted on the 
network for outrigger with zero changes to the application needed.  It's all 
interfaces...

> is and should be a central and integral part of River.
> I would even like to see that it is expanded from the current 'single
> node' to a full 'cluster' without single-point of failure, but that is
> a different discussion. (In ASF terms; Spaces/JavaSpaces subproject
> will stay in River until its mission and community is clear and
> different enough to be its own project.)

 From a practicle perspective, you will always find pushback on making outrigger 
do clustering.  There are things that clustering provides, but in the end, a 
clustered system is much more complex, much harder to manage and typically 
doesn't actually solve the problem that most people want in that having a 
seamless fail over and redundant copy of data will inject latency that is not 
always tolerable, especially in applications where the continued existence of 
the data is the key.

Instead, the Jini lookup mechanism, and particularly the ServiceDiscoveryManager 
class are the trivial way to get failover without any added complexity to the 
system design.  This is why Javaspaces scales infinitely in the master-worker 
pattern.  The works just use discovery to find a javaspace.  If there is work 
there, they do it.

Gregg Wonderly

Mime
View raw message