Niclas Hedhman wrote:
On Tue, Dec 9, 2008 at 11:53 PM, Gregg Wonderly <[EMAIL PROTECTED]> 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
