Distributed operating systems and distributed computing face
significant challenges: not only must they communicate and synchronize
across heterogeneous networks, they also face the problems of
dealing with latency, partial failure, and language incompatibilities.
(source: "Summary of JavaSpaces™ Specification,"
http://www.ee.ualberta.ca/~yip/summaries/javaspaces.htm)
Over the years, several solutions to the problems of distributed
computing have been proposed and implemented: Remote Procedure
Calls (RPCs), the message-passing interface (MPI), parallel virtual
machine (PVM), DCOM, Common Object Request Broker Architecture
(CORBA), message brokers, Remote Method Invocation (RMI), enterprise
architecture integration (EAI).
Many problems and inefficiencies exist with these technologies.
For example, the general problem with RPC-type solutions is that
client and server programs must know a great deal about each other
in order to work. In other words, they are tightly coupled. If
there is a change in a client, a change must be made in the server.
A great deal of coordination is required and any single change
in one program can require multiple rewrites in the same program
and other dependent programs. (source: "JavaSpaces™
Promises Distributed Computing Breakthrough," Cameron Laird,
http://www.byte.com/feature/BYT19990921S0001)
In contrast, JavaSpaces™ is designed to provide a simple
unified mechanism for dynamic communication, coordination, and
data- and object-sharing. In a distributed application, JavaSpaces™
technology acts as a virtual space between providers and requesters
of network resources or objects. This allows participants in a
distributed solution to easily exchange tasks, requests and information,
and gives developers the ability to create and store objects with
persistence. (source: JavaSpaces and the Jini, Mark Kuharich,
http://www.it-analysis.com/article.asp?id=893
)
How do JavaSpaces™ and other existing distributed computing
solutions compare? It is helpful to conjure up an image of a cloud
and a set of wires. In the traditional solutions to distributed
computing, a set of "wires" are used to connect the
various remote components in the system. These "wires"
must know the specific names and locations of the components they
connect, must have specifications for what and how much they can
transport, etc. If a wire "breaks," unless another redundant
back-up wire exists, the whole system fails. Whenever the system
grows or shrinks, new "wires" must be added or removed.
In contrast, JavaSpaces™ is like a cloud that fills up all
the space between the remote components in the distributed system.
The cloud expands as necessary to connect system components, or
shrinks when needed as components leave the system - the "cloud"
takes responsibility for keeping the system viable. The remote
components don't need to know the names, locations or anything
else about other remote components; they transport and communicate
simply by putting "things" in the cloud and taking other
"things" out of the cloud as desired. The cloud takes
care of holding onto the "things" until other components
ask for them.
This is a broad conceptual picture of JavaSpaces™. Now let
us get more specific.
Just what specifically is a JavaSpace? The JavaSpace is best illustrated
by the figure below:
While this figure is helpful, an explanation in words is still necessary. The simplest explanation is that JavaSpaces™ are a way to create distributed applications and operating systems without worrying about the typical problems of distributed applications and operating systems. A JavaSpace is a particular collection of "computing resources, somewhere outside any particular host or application." Each JavaSpace takes care of the details of data transfer, persistence, communication, synchronization, security, etc. For example, instead of focusing on the details and challenges of distributed computing data transfer between components A and B, a programmer can simply place A in a JavaSpace, and the JavaSpace will take care of that object until B asks for it. (source: JavaSpaces™: Making Distributed Computing Easier, By Cameron Laird, http://www.byte.com/feature/BYT19990915S0001 )
Where does Java fit in the "real world" of computing?
"JavaSpaces™ provides a simplified approach to dynamic
communication, coordination and sharing of objects between network
resources. JavaSpaces™ acts as a virtual space between providers
and requesters of network services. This allows participants in
a distributed solution to exchange tasks, requests, and information
in the form of Java objects." (source: Jini™ and JavaSpaces™:
the B2B Dark Horse?, Robert Flenner, http://www.oreillynet.com/pub/a/onjava/2001/02/01/jini.html
)
To be clear, JavaSpaces™ runs in a Jini™ Service environment,
which runs in a Java Virtual Machine (JVM) environment. Jini™
is a standard, something like a "Plug-and-Play" for
networked devices. But JavaSpaces™ is not limited to applications
in small devices.
(source: JavaSpaces™ Promises Distributed Computing Breakthrough,
by Cameron Laird, http://www.byte.com/feature/BYT19990921S0001
)
Now let's discuss specific features of the "Space" in
JavaSpaces™:
Spaces are shared. Multiple processes can interact with
a space at the same time - the JavaSpace handles the details of
concurrent access.
Spaces are persistent. You can reliably store an object
in a JavaSpace. If you store something in a JavaSpace, it will
remain there indefinitely until it is removed. You can also request
a lease - a duration of storage for the object. When the lease
expires, the object will disappear.
Spaces are associative. You don't need to know the name
or the location of an object in a JavaSpace in order to find it.
Instead, you can look for an object which matches the type of
content you're seeking. You create a template object made up of
values/properties you're seeking, and you get objects that match
the template from the JavaSpace. This type of associative lookup
gives the programmer great flexibility and true "loose coupling."
You can program without knowing names or locations of other components
of your application.
Spaces allow transactions. JavaSpaces™ uses the Jini™
transaction service to guarantee that operations are atomic (that
is, either all of the operation is applied, or none of it is applied).
Transactions are not only important to many business applications,
they are a way to handle partial failure.
Spaces allow you to exchange executable content. Objects
in a JavaSpace are passive data - they can't be modified or invoked
inside the JavaSpace. However, you can easily take the object
from the JavaSpace, creating a local copy, and modify its public
fields and invoke its methods.
(source: Freeman, Hupfer, Arnold, JavaSpaces™ Principles,
Patterns and Practice, pp.6-7, Addison-Wesley, 1999)
JavaSpaces™ is based on work done nearly two decades ago.
In the 1980s, David Gelernter of Yale University began work on
a tool called "Linda", an extension of C that uses "tuple-spaces."
A tuple-space was defined as a small number of methods combined
with a persistent store. Linda was designed to focus on coordination.
The results of the research showed that a large number of parallel
and distributed problems could be solved by Linda while avoiding
many of the usual pitfalls of building networked systems.
JavaSpaces™ is essentially a Java-optimized version of the
original C-based tuple-spaces,. The major advantage of JavaSpaces™
over Linda is the Java Virtual Machine (JVM). Where Linda had
many cross-platform obstacles, JavaSpaces™ runs in a JVM
which can operate the same way on many platforms.
(source: JavaSpaces™ Promises Distributed Computing Breakthrough,
by Cameron Laird, http://www.byte.com/feature/BYT19990921S0001
) (source: Make Room for JavaSpaces™, Part I, http://www.javaworld.com/javaworld/jw-11-1999/jw-11-jiniology.html,
by Eric Freeman and Susan Hupfer)
Every object stored in a JavaSpace must conform to the following
conventions: First of all, every object must implement the entry
interface. (This is simply a marker interface, without methods
or variables, and is an extension of the serializable class.)
Fields in the object must also be public, so that other entries
can perform associative lookup and matching.
Any object that implements the JavaSpaces™ interface can
use these key methods:
write: This method places one copy of an entry object into the JavaSpace. If called multiple times on the same entry, it will place multiple entries into the JavaSpace.
read: This method takes a template entry and attempts to match it with an entry in the JavaSpace. If successful, it returns a local copy of that entry object to the calling method.
take: This method is like read, except that if a matching entry is found in the JavaSpace, it is removed from the JavaSpace.
notify: This method takes a template entry and asks the JavaSpace to notify the entry whenever matching entries are placed in the JavaSpace.
These are the main methods in a JavaSpace! But with these simple
methods, a great deal can be accomplished. Interactive chat systems,
Client/Server applications, message-passing, broker (bidding)
systems and other tradiaional programming architectures can be
created using JavaSpaces™. (from Make Room for JavaSpaces™,
Part I, http://www.javaworld.com/javaworld/jw-11-1999/jw-11-jiniology.html,
by Eric Freeman and Susan Hupfer)
Even more interesting are the new programming possibilities that
open up with JavaSpaces™. For instance, it is easy to build
a "compute server" where jobs are deposited in a JavaSpace,
and the programs that perform the computation take those jobs
from the JavaSpace, do their work, and return them. Since these
"worker" programs can be on different computers, in
different locations there is a natural load-balancing effect.
Each computer only takes as many jobs as it can handle, and when
they can take more "jobs," they do.
It is helpful to look at a real JavaSpaces™ program. The
code is disarmingly simple:
import net.jini.core.lease.Lease;
import net.jini.space.JavaSpace;
import com.sun.jini.example.spaceApplet.SpaceApplet;
public class HelloWorld extends SpaceApplet {
private JavaSpace space;
public void init() {
super.init();
space = (JavaSpace)space();
try {
Message msg = new Message();
msg.content = "Hello World";
space.write(msg, null, Lease.FOREVER);
Message template = new Message();
Message result =
(Message)space.take(template, null, Long.MAX_VALUE);
msg(result.content);
} catch (Exception e) {
e.printStackTrace();
}
}
public void msg(String str) {
System.out.println(str);
}
}
This example creates a JavaSpace and the Message entry "Hello World", places the Message into the JavaSpace using the write method, creates a template of a Message entry, and then attempts to find and take the Message entry from the JavaSpace.
In this example, the same program writes to and takes from the
JavaSpace. But it would be just as easy to create a program on
one computer that writes the Message entry into the JavaSpace,
then create another program on an entirely different computer
that looks for and takes the Message entry from the JavaSpace.
These two computers could be separated by vast distances. The
first program could execute and disconnect itself from the JavaSpace,
and then an arbitrarily long time later (provided the JavaSpace
was still running on a server somewhere), the second program could
execute and take the Message. Neither program would need to know
where the other program was located. The programs need only know
the name of the JavaSpace and the name and format of the entry
(Message) type. (source: Make Room for JavaSpaces™, Part
I, http://www.javaworld.com/javaworld/jw-11-1999/jw-11-jiniology.html,
by Eric Freeman and Susan Hupfer)
This example reveals the simplicity of code in JavaSpaces™
programs. The "Hello World" program doesn't have code
to handle data transfer, persistence, or communication. All that
is hidden "under the hood" of JavaSpaces™. Most
of the complex details of distributed computing are shielded from
the programmer (a glimpse of these complexities will be shown
later.). This means the programmer can concentrate on getting
the "real" work of the application done.
· JavaSpaces™ can overcome language incompatibilities.
By the simple fact that it is written in Java, JavaSpaces™
can span numerous platforms and heterogeneous computing environments.
This is because JavaSpaces™ run in the Java Virtual Machine(JVM)
which can run on "top" of those different platforms.
(However, this binding to Java can be both an advantage and a
disadvantage, as we shall see later.) Since JVM's exist for many,
many platforms, this means that JavaSpaces™ can be used by
all those platforms, too.
· JavaSpaces™ are simple. There are only a
handful of additional methods to learn. "Different processes
don't need to know about each other, and coders don't need to
know low-level details of race conditions, locking persistence
semantics, or much else." (source: JavaSpaces™: Making
Distributed Computing Easier, By Cameron Laird, http://www.byte.com/feature/BYT19990921S0001
) The JavaSpaces™ programmer doesn't have to worry about
multiple clients, synchronization, data transfer, persistence,
transactions, etc., because those details are handled by the JavaSpace
itself.
· JavaSpaces™ supports loosely coupled protocols.
"By uncoupling senders and receivers, spaces support protocols
that are simple, flexible, and reliable. Uncoupling facilitates
the composition of large applications (we can easily add components
without redesigning the entire application), supports global analysis
(we can examine local computation and remote coordination separately),
and enhances software reuse (we can replace any component with
another, as long as they abide by the same protocol)."
(source: Freeman, Hupfer, Arnold, JavaSpaces™ Principles,
Patterns and Practice, pp.6-7, Addison-Wesley, 1999)
· JavaSpaces™ can support asynchronous operation.
A program can put an entry into the JavaSpace and then terminate.
If the machine on which that program resides is shut off, or fails,
cutting it off from the JavaSpace, that does not delete the entry
or the JavaSpace. The entry object in the JavaSpace can still
be accessed at a later time by another program on a different
machine. The JavaSpace can also be arbitrarily large, spanning
multiple servers - which means if one server fails, the JavaSpace
can transfer the entries to another server and continue operation.
Thus, JavaSpaces™ can overcome some of the latency and partial
failure problems that face distributed computing. (from Make Room
for JavaSpaces™, Part I, http://www.javaworld.com/javaworld/jw-11-1999/jw-11-jiniology.html,
by Eric Freeman and Susan Hupfer)
In the many articles and essays about JavaSpaces™, there
is a sense of giddiness about the possibilities, as if JavaSpaces™
are the greatest invention since sliced bread. Even if half of
the hype around JavaSpaces™ is true, why aren't we seeing
them used extensively in the "real world"? In this section
of the paper, we will examine some of the problems with JavaSpaces,
and offer some recommendations for improvement.
While the concept of a JavaSpaces™ is relatively easy to
understand, and there is only a small, easily mastered set of
methods, it takes a good deal of effort to set up the infrastructure
on which a JavaSpace runs. Here is an example of all the code
needed to set up a JavaSpace and run the "Hello World"
application:
1. Start an http server:
java -jar C:\jini1_0_1\lib\tools.jar
-port 8081
-dir C:\jini1_0_1\lib
-verbose
2. Start an Remote Method Invocation (RMI) Activation Daemon:
rmid [-port port-number] [-log dir]
3. Start a Lookup Service:
java -Djava.security.policy=C:\jini1_0_1\example\lookup\policy.all
-jar C:\jini1_0_1\lib\reggie.jar
http://hostname:8081/reggie-dl.jar
C:\jini1_0_1\example\lookup\policy.all
C:\tmp\reggie_log
public
4. Start a Transaction Manager:
java -Djava.security.policy=C:\jini1_0_1\example\txn\policy.all
-jar C:\jini1_0_1\lib\mahalo.jar
http://hostname:8081/mahalo-dl.jar
C:\jini1_0_1\example\txn\policy.all
C:\tmp\txn_log
public
5. Start a persistent JavaSpace:
java -Djava.security.policy=C:\jini1_0_1\example\books\policy.all
-jar C:\jini1_0_1\lib\outrigger.jar
http://hostname:8081/outrigger-dl.jar
-Dcom.sun.jini.outrigger.spaceName=JavaSpaces
C:\jini1_0_1\example\books\policy.all
C:\tmp\js_log
public
6. Compile the JavaSpace program:
javac -d . -classpath
C:\jini1_0_1\lib\jini-core.jar;
C:\jini1_0_1\lib\jini-ext.jar;
C:\jini1_0_1\lib\sun-util.jar;
C:\jini1_0_1\lib\space-examples.jar;.;
HelloWorldjava
7. (Finally) Run the JavaSpaces™ program:
java -Djava.security.policy=C:\jini1_0_1\example\books\policy.all
-Doutrigger.spacename=JavaSpaces
-Dcom.sun.jini.lookup.groups=public
-cp C:\jini1_0_1\lib\space-examples.jar;
C:\jini1_0_1\lib\jini-core.jar;
C:\jini1_0_1\lib\jini-ext.jar;
-Djava.rmi.server.codebase=http://hostname:8081/space-examples-dl.jar
HelloWorld
(Source: "The Nuts and Bolts of Compiling and Running JavaSpaces™ Programs" by Susanne Hupfer, http://developer.java.sun.com/developer/technicalArticles/jini/javaspaces/ )
To explain all of the different commands, parameters, and settings in this example would take up more than a 20 page paper! The commands are only displayed here to make a point: all of this complicated set-up is required just to run the simple "Hello World" application. A further disadvantage is that many of these components of the infrastructure must be downloaded separately. There is no unified, all-in-one JavaSpaces™ package: one must download the JVM, the Jini™ Technology Starter Kit, and the JavaSpaces™ Technology Kit, then do a healthy amount of tweaking and configuration to get the various parts synchronized.
JavaSpaces™ is hostage to Java's - and in particular, Jini™'s
- fortune. For all the attractiveness of the JavaSpaces™
implementation of distributed computing, JavaSpaces™ depends
on the Java Virtual Machine (JVM) and the Jini™ services
on top of the JVM. JavaSpaces™ is perched on top of a tall
stack of different software layers. Should any one of those layers
fail or shift, JavaSpaces™ is affected. Whether or not JavaSpaces™
is a good technology may be an irrelevant question; if any of
the supporting Java technologies fail, it won't matter.
Let us examine the Jini™ issue briefly. Jini™ is Sun Microsystem's attempt to allow all devices, from toasters to computers to heart monitors, to network and communicate with one another. Although Jini™ has been around for several years, the wave of Jini™-enabled consumer electronic devices has failed to materialize. Jini™ requires the JVM environment, which, it turns out, is currently too resource-hungry and cumbersome to fit into most small devices. Sun recently recognized this fact by creating a "surrogate architecture" so that Jini™ will no longer require a JVM in order to operate. In addition, Sun plans to release Jini™ version 1.1 with "helper utilities" to alleviate some of the common problem Jini™ programmers face.
Jini™ competes directly against Microsoft's Universal Plug-and-Play (UPnP) strategy. In a nutshell, UPnP makes a similar promise to link together all variety devices through existing Web technologies, including HTTP, XML, and IP addresses. Microsoft's Windows Millenium Edition (Me) operating system is already shipping with UPnP. Vendors chasing the market may soon find that the UPnP is already in place on PCs, while the Jini™ platform is not. UPnP is a Microsoft-centric technology, and it will shut out the possibility of JavaSpaces™. (source: Sun dreams of slimmer Jini™, Stephen Shankland, CNET News.com 10/2/00, http://news.cnet.com/news/0-1003-200-2897486.html?tag=pmtfr )
What does UPnP have to do with JavaSpaces™? Nothing directly.
UPnP doesn't include a competing distributed environment to match
JavaSpaces™. But if Jini™ fails to gain a foothold in
the device market, UPnP will dominate, and JavaSpaces™ will
simply wither away.
Nearly every week it seems Sun announces a new technology that
begins with the prefix "Java-". Despite the fact that
JavaSpaces™ have been around for over three years (a long
time in Internet years), if you mention the term "JavaSpaces"
to programmers, most respond with a "Huh?". With Sun's
deluge of Java technologies, it is easy to get confused about
how they are related
The Java 2 Enterprise Edition (J2EE) technology includes Enterprise
JavaBeans (EJB), Java Servlets, JavaServer Pages, JavaMail, Java
Message Service, Java Database Connectivity (JDBC), CORBA, etc.
These technologies are focused on connecting the existing and
legacy (old) systems. JavaSpaces™ can be part of an enterprise
solution (see below), but will not replace many of these Java
technologies. JavaSpaces™ is future-oriented, not legacy-oriented.
The point here is that, as yet another Java-technology, JavaSpaces™
can easily get lost in the shuffle.
The main paradigm for e-commerce and enterprise solutions is the 3-Tier model, where the first tier is the user interface, the second is the business logic, and the third is the database, sometimes called the persistence layer. Developers are used to rigid definitions of this programming model and may be unsure where JavaSpaces™ fits in.
JavaSpaces™ can provide a flexible second-tier of "middleware."
Since it provides high scalability, concurrency, and dynamic networking
through loose coupling, JavaSpaces™ actually makes an ideal
middle tier. It can easily scale up, expanding to accept new connections
and shrinking as disconnections occur and other partial failures,
without the whole enterprise failing.
However, one perceived drawback is that JavaSpaces™ is not
database-centric. Traditional second tier components are focused
on creating or executing SQL queries, but JavaSpace entries are
not capable of performing those functions. An SQL query can be
passed through a JavaSpace, but no execution can occur within
the space itself, since all entries must remain passive data objects.
For programmers obsessed with database interactions, JavaSpaces
may appear irrelevant. (Introducing JavaSpaces™, http://www.sys-con.com/java/archives/0509/mahapatra/index_h.html)
Perhaps the most exciting element of the JavaSpaces™ technology
is the fact that commercial products are coming to market this
year. New developments are happening right now. Here are some
of them
IBM has created its own version of tuple-spaces, called TSpaces.
Like JavaSpaces™, it is written in Java, and offers a small
set of methods as well as an object store. But TSpaces offers
different capabilities: it has a built-in database with transaction
and indexing support as well as a simplified query language. (source:
Sun's JavaSpaces™ and IBM's TSpaces, http://www.computer.org/internet/v2n5/w5tech.htm
)
IBM describes TSpaces as
"a network communication buffer with database capabilities.
It enables communication between applications and devices in a
network of heterogeneous computers and operating systems. TSpaces
provides group communication services, database services, URL-based
file transfer services, and event notification services….In
a sense, it is a database system for the common everyday computing
device - one that doesn't generate complex SQL queries, but one
that needs reliable storage that is network accessible."
(source: http://www.almaden.ibm.com/cs/TSpaces/intro.html
)
Beginning in 2001, TSpaces became available for licensing, either for use within an enterprise solution, or for embedding in a third-party product. TSpaces is already embedded in some IBM products. (source: http://www.almaden.ibm.com/cs/TSpaces/licensing.html )
It is clear that TSpaces, unlike Jini™, are not directed
at small networked devices, but at the greater business network
environment. The addition of database services is a significant
feature and advantage over JavaSpaces™. TSpaces still faces
the same problems as JavaSpaces™ in terms of the complexity
of its underlying architecture, and it may be further hampered
by the fact that JavaSpaces™ will benefit earlier from any
Sun modifications to the Java language and Jini™ standard.
J-Spaces boasts that it is the first commercial application of JavaSpaces™. Offering software in both standard and enterprise editions, they promise their software provides an "intelligent connectivity network service…. an elegant and practical approach to solving common real-world scenarios in today's increasingly networked world." (source: http://www.j-spaces.com/product.html )
J-Spaces adds a layer of utilities and management tools to JavaSpaces™,
illustrated here:
J-Spaces claims these extra applications optimize the entry storage, associate lookup, security, scalability, and other features. Basically, J-Spaces hopes to make JavaSpaces™ easy to use, overcoming the infrastructure complexities we detailed earlier. NOTE: As of April 2001, the J-Spaces software has only reached beta testing. (source: http://www.j-spaces.com/faq_tech.html )
In the areas of business-to-business(B2B), application servers,
and e-commerce - all of which are distributed computing solutions
of one sort or another - Enterprise JavaBeans (EJB) and Common
Object Request Broker Architecture (CORBA) solutions are "traditional"
and common. However, with EJB and any Object Request Broker (ORB),
there is a great deal of expense involved: you must invest in
specialized application servers, EJB frameworks, on-going license
fees, and expensive machines for development and testing. An additional
problem with CORBA is the fact the ORBs are not tightly controlled
at the source - this means that each ORB is a little different
and proprietary, making it difficult to guarantee the seamless
operation of the enterprise. (source: "Jini™ as an Enterprise
Solution," Dave Sag, 1/4/2001, http://oreillynet.com/pub/a/onjava/2001/01/04/Jini_enterprise.html)
In contrast, JavaSpaces™ can be part of an open-source enterprise
solution, using Java, Jini™, Apache, Tomcat, and any one
of the many free JDBC compliant SQL databases (such as MySQL),
which can run on relatively inexpensive machines during development.
In January and February of 2001, Crudlets were introduced to the
public. A CRUDLET is possibly one of the worst acronyms ever created,
and it stands for Creation, Retrieval, Updating, Deletion, scheduling
of Life cycle activity, Existence checking, and generic Templating
of various objects in the context of business rules. These represent
a group of activities that "all good application servers
need to do." (source: Crudlet [draft 1.0] http://www.crudlet.org)
In the Crudlet context, JavaSpaces™ works in concert with XML, Linux, Apache, JavaBeans and Java Servlets, to provide a cheap, reliable open-source application server which can provide enterprise solutions. Here is an illustration of JavaSpaces™ in the context of one enterprise solution, a dynamic B2B trading exchange:
The advantages of using the Crudlet technologies to create an enterprise solution are manifold: (1) no expensive servers required for development or testing; (2) no expensive licenses required; (3) Jini™, JavaBeans, and JavaSpaces™ make development simpler, and handle the inevitable last-minute design modifications easier. (source: "Jini™ as an Enterprise Solution," Dave Sag, 1/4/2001, http://oreillynet.com/pub/a/onjava/2001/01/04/Jini_enterprise.html)
Jini™ and JavaSpaces™ have more advantages that other
enterprise solutions can't offer: they can be multi-threaded (unlike
EJBs), the source code is essentially free and they consistently
and reliably work across unstable heterogeneous networks. (source:
Crudlets: Making Peace between Extreme Jini™ and XML Viewpoints,
Dave Sag, http://www.oreillynet.com/pub/a/onjava/2001/02/08/jini_xml.html
2/8/2001 )
History has shown that betting against Microsoft in a head-to-head
race is not wise. Jini™ is not likely to beat UPnP, but Jini™
and JavaSpaces™ are not restricted to applications in consumer
electronic devices. Jini™, like Java itself, may have been
developed with the idea that it would be imbedded in a smart refrigerator
or toaster, but the software technology may find that it's actually
more useful in a traditional computing environment. As we've seen,
Jini™ and JavaSpaces™ are already turning up in traditional
PC software services software.
The first idea behind "tuple-spaces" and JavaSpaces™
was that by networking computers together, all of their spare
cycles could be used to create a temporary supercomputer, one
that would have enough power to solve large computing problems.
This idea is now fading as a goal of JavaSpaces™, however.
Now the main attractiveness of JavaSpaces™ is the easy connectivity
and flexibility that the spaces provide.
The most exciting possibility for JavaSpaces™ comes from
the Crudlet concept. An part of an open-source, low cost enterprise
solution, JavaSpaces™ may find a unique, lucrative niche.
The possibilities can not be underestimated: if Crudlets allow
cheap ("free") entry into the enterprise market, there
will be companies that take advantage of it. Since Crudlets were
described only three months ago, and the first application only
went "live" in February 2001, the market is reacting
this development literally right now. If Crudlets take off like
similar open source software (Apache, Linux, Tomcat, Cocoon, MySQL,
etc.), JavaSpaces™ has a bright future ahead of it.
In the end, even if JavaSpaces™ itself does not survive, the "tuple-space" concepts behind it will endure. Space-based operations offer a genuine advance in distributed computing. Perhaps JavaSpaces™ will live on in TSpaces, J-Spaces, or an entirely new implementation will emerge.