"It is the difference between trying to survive an earthquake by building a sturdy structure that is hard to break and building a structure that sways with the movement. You can survive much bigger earthquakes by swaying with the movement, even though your instinct is to build a sturdy structure. People are now following the instinct to build a sturdier structure. When building with JavaSpaces and Jini, you sway with the earthquake, and you can do much better," says Ken Arnold in this Artima.com interview:

http://www.artima.com/intv/sway.html

JavaSpaces are a very useful tool for building workfarm systems. However, they do introduce a single point of failure and a potential bottleneck. What if your JavaSpace server is too slow? What if it crashes?

JavaSpaces loosen coupling between participants, just like an abstract interface does between a client and a server. However, all you've done is couple both the client and the server more strongly to the JavaSpace instead. You can't remove dependencies; you can just choose which way they go.

Regarding Scott McNealy's quest for the BFWS (Big Friggin' WebTone Switch) - we nearly have it, we may not know it.

My thought for Scott's BFWS is a pre-installed, pre-configured, highly available implementation of a Space running in a small, medium and large (memory, disk, net connections, etc.) system configuration that is taken out of the box and plugged into a company's network.

> JavaSpaces are a very useful tool for building
> workfarm systems. However, they do introduce a
> single point of failure and a potential bottleneck.
> What if your JavaSpace server is too slow? What if
> it crashes?
>
One thing Ken mentions is that a JavaSpace can be replicated. Replication of a JavaSpace is a hard problem, but apparently there is at least one commercial JavaSpace implementation that can do it.

Ken talks about replication on this page:

http://www.artima.com/intv/sway4.html

As with J2EE high availability issues and scalability issues are left to the implementations of JavaSpaces.
JavaSpaces as a technology has a potential of addressing the scalability and high availability issues of distributed applications however i agree that in order that it will be able to do that the implementations of the space needs to be highly available and scalable.

Our implementations (GigaSpaces) addresses that issue through a combination of replication , load balancing and fail-over policies which together provide a highly flexible manner for addressing those issues.

For more information i would recommend that you to read the following white paper http://www.gigaspaces.com/whitepaper.htm

> JavaSpaces are a very useful tool for building workfarm
> systems. However, they do introduce a single point of
> failure and a potential bottleneck. What if your
> JavaSpace server is too slow? What if it crashes?

JavaSpaces just provides an API to represent functionality; it's possible for the implementation to be resilient to server failure. Regarding bottlenecking, you'll have to partition the workload yourself. The approach we took in Coherence -- http://www.tangosol.com/coherence.jsp -- is to automatically partition the load (both data and processing) over the entire cluster, so there's never a bottleneck unless all the transactions are updating some single piece of data.

> JavaSpaces loosen coupling between participants, just like
> an abstract interface does between a client and a server.
> However, all you've done is couple both the client and
> d the server more strongly to the JavaSpace instead. You
> can't remove dependencies; you can just choose which way
> they go.

That is true.

Peace,

Cameron Purdy
Tangosol, Inc.