Re: Understanding JavaSpaces: Problems of distributed applications lost in Space?

Dear Christian,

I work for arguably the the most successful JavaSpaces-related company in
the world (AKA GigaSpaces) and I am in many ways responsible for educating
our users and the world at large as to the positive effect a Space-Based
achitecture can have on their applications.

Therefore, please let me express my opinions regarding the questions you
raised in your recent posting to this forum:

You ask: "Do I really get any technical advantages(performance, QoS,
features, ..) just by using JavaSpaces(or any other kind of space)?"

I answer:

No.  Unless you take advantage of the programming model that accompanies a
JavaSpace and unless the implementation of the space offers you some
advantages that go beyond the basic JavaSpace specification.

With GigaSpaces people do three main things:

1) make stateful applications go faster
2) create fail-safe adaptive service-oriented applications
3) enable interoperability between disparate applications, groups, and languages

That said, it should be noted up-front that GigaSpaces is more than just an
implementation of the bare JavaSpaces standard.

Let me begin by offering what I believe are some of the benefits of the
JavaSpaces standard and then add to that list the further benefits of the
GigaSpaces implementation.

JavaSpaces provides the following:

An Object-centric architecture whereby multiple services share Objects that
can possess behavior as well as data and are themselves events to those that
desire them to be so.

The dream of mobile code - a fantastic idea, that to me has tremendous
potential, is quickly realized when using JavaSpaces because the very
Objects you write to a space can act as units of work and implement quite
complex workflow scenarios such as chains of command and state engines.

While these patterns are not unique to JavaSpaces and can be shoe-horned
into a variety of other technologies, they quite natuarally align themselves
with JavaSpaces where the main currency is Objects.  (See my blog: when
Objects take a central role: <a
href="http://jroller.com/page/owentaylor/20060629">here</a>)

I believe very strongly that it is a technical advantage to be able to write
less code that accomplishes more.  I also believe it is a strong technical
advantage to have a service framework such as a JavaSpace that allows a
single action such as the JavaSpace.write() call to encompass all the
purposes of storing data (the state of the Object), creating events
(triggering both the potential notification to multiple subscribers as well
as the delivery of messages to those hungrily waiting on a queue), and
moving essential logic from one place in the network to another.

It is simply wonderful to me to know that my services do not have to
maintain state.

Likewise, it is wonderful to me to know that at any point I can add
additional services that will not necessarily interfere with the running
system, but can participate in the viewing of the current state of the
system and potentially add to the usefulness of the system while remaining
highly decoupled from that which they join.

If I call space.write(myObject) and pass an Object to the JavaSpace, I
accomplish multiple things that may change in value to me depending on my
current focus and the problems I seek to solve right now or in the future:

space.write(myObject) ensures that my local address space and process are

A: not the only ones capable of seeing myObject
B: not exhausted by retaining local ownership ie: run out of memory or
processing power in retaining myObject
C: not tightly coupled to the lifecycle of myObject as once it is written,
it can take on a life of its own
D: not dependent on the services that may or may not entertain myObject in
the future in any technology-specific way - ie: the space is the hub to as
many service spokes as my business needs and architecture warrant and these
spokes can be added and removed as desired with only the effect their
business purpose demands being felt.

The simplicity of the core JavaSpaces API is also in my mind a clear
advantage to someone in our profession:

write - serves to store state, propogate events, and move code

read - serves to allow synchronous snapshots of the current state to be
taken in a non-disruptive way by multiple services regardless of their
knowedge of each other

take - serves to isolate the motion of objects as events and or work from
one part of the network to another and when writes and takes happen in rapid
succession, a massively efficient parallel-processing engine can result

notify - serves to enable an asynchronous subscription to be filled

These four methods can solve a huge array of computing problems:

An auction site:
write items for sale
read catalogue of items
register for notifications of additional bids on items
write bids
take bids and items when X criteria is met

Any matching engine whether it be for gaming, switches, stock trades etc is
easily built using JavaSpaces (especially GigaSpaces).

The fact that JavaSpaces is a memory-based technology means that all
accesses to the Objects that pass through a space are very fast.  This speed
is an advantage to many systems - reducing the overall latency of the system
and even reducing the amount of batch work to be executed as more and more
operations occur in real-time.

This fact also leads into the areas where GigaSpaces adds tremendous value.
 The speed of memory as a shared resource is normally coupled with the
volatility of memory: resulting in valid concerns regarding reliability of
JavaSpaces implementations.

GigaSpaces provides clustering of the in-memory Objects so that there can be
transparent fail-over between remote nodes on a network and GigaSpaces has
made this happen in a way that both scales in terms of maximum size of bytes
held in such a reliable fashion and behaves extremely well in satisfying
low-latency requirements such as sub-millisecond transaction times while
maintaining throughput of business transactions in the range of several
thousand tx per CPU on commodity blade hardware.

GigaSpaces also adds the option to partition the Objects and thereby the
related work performed with/on them by allowing the JavaSpace to be realized
accross multiple physical boxes while appearing as one logical resource to
the services interacting with it.  This partitioning is a key component of
our success in achieving low latency, high-throughput solutions.

I do not want to suggest that you cannot solve the same problems using other
technologies, I do want to suggest that solving the same problems with
JavaSpaces can very often lead to a smaller, more efficient software
application that outperforms the alternatives in terms of latency and
throughput while allowing for increased system refactoring and add-on
functionality with minimal pain/impact over time.

GigaSpaces does three major additional things beyond what I have spoken of
thus far:  These all have distinct advantages to the architect and
programmer when used properly. . .

GigaSpaces:

1) co-locates the application logic with the events and state by allowing
the space to run embedded in an aplication service
2) manages the deployment and run-time behavior of a service-based
application - ensuring high-availability and compliance with declared SLAs
3) exposes the complete GigaSpaces and (of course)JavaSpaces API to .NET and
C++ applications allowing for tremendous ease in ineroperability between
such Object-aware technologies.

GigaSpaces also provides conveniences such as a SQL API and regular
expression syntax for resolving rich queries against the space and the
ability to refer to the space as a MAP or even  JMS Queue or topic.

I hope that I have begun to shed some light on the details of how we at
GigaSpaces at least justify the grand claims that using JavaSpaces as a
central component in your architecture will provide huge and unique benefits.

I recommend that you build a system or two using traditional client-server
technologies and then satisfy the same requirments using GigaSpaces - please
 use experts to guide you in both efforts - then, when the dust settles,
examine the work involved, the complexity and overall value
(speed/scalability/expandability) of the relative solutions and I think you
will be forced to agree with our claims.

Might I suggest a distributed Tic, Tac, Toe Game as a starting point perhaps
followed by an auction application or perhaps order-processing system. . .

Sincerely,

Owen Taylor
Senior Director Worldwide Technical Communications
GigaSpaces Technology Inc
http://jroller.com/page/owentaylor/

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html