Sponsored Link •
Ken Arnold, the original lead architect of JavaSpaces, talks with Bill Venners about loose coupling in JavaSpace-based systems, why fields in entries are public, RPCs to nowhere, and building systems that sway with failure.
Ken Arnold has done a lot of design in his day. While at Sun Microsystems, Arnold was one of the original architects of Jini technology and was the original lead architect of JavaSpaces. Prior to joining Sun, Arnold participated in the original Hewlett-Packard architectural team that designed CORBA. While at UC Berkeley, he created the Curses library for terminal-independent screen-oriented programs. In Part I of this interview, which is being published in six weekly installments, Arnold explains why there's no such thing as a perfect design, suggests questions you should ask yourself when you design, and proposes the radical notion that programmers are people. In Part II, Arnold discusses the role of taste and arrogance in design, the value of other people's problems, and the virtue of simplicity. In Part III, Arnold discusses the concerns of distributed systems design, including the need to expect failure, avoid state, and plan for recovery. In this fourth installment, Arnold describes the basic idea of a JavaSpace, explains why fields in entries are public, why entries are passive, and how decoupling leads to reliability.
Bill Venners: What is a JavaSpace?
Ken Arnold: The basic idea of a JavaSpace is to introduce loose coupling between actors in a protocol. For example, you have a question. If you find a server that can answer your question and you send it a message, you are tied directly to that server and have to deal with its failure modes. With a JavaSpace, you instead write an object, called an entry, into the space. Somebody who can answer the request that entry represents then extracts it and writes back the response.
The kind of loose coupling JavaSpaces enables has several advantages, as loose coupling always does. The simple, direct advantage is scalability. Say you have one server and many clients. The clients write requests, and the server extracts them and writes the responses back. Now let's say the server gets overburdened; in that case, you need to accelerate it. With a directly coupled system, you have to make "the place people talk to" faster. Or you have to change people's logic so that something in the system knows how to distribute the load. Distributing the load is an interesting problem: Who is busy? Who is not? It's sometimes hard to tell.
In the JavaSpaces model, you just start up a second server. Now you have two things retrieving requests from the space and writing results back, so performance increases roughly twice as fast. In fact, it is distressingly close to linear when you do this, for a long period. Because you decouple requesters from request handlers and how requests are handled, you can just have multiple request handlers. You can break the request down into two parts; then something that can complete one part efficiently will retrieve it and write back an intermediate result that somebody else knows how to finish. You can partition the result in different ways. The customer only cares that the results come back.
JavaSpaces has essentially three primary operations:
write, which puts an entry into the space;
read, which reads an entry from the space; and
take, which is equivalent to reading except it removes the
entry as well as reads it. The entry is a simple kind of object. It has a
set of public fields that all have an object type, with no primitive
types. Writing an entry into the space is as simple as creating one of
these entry objects and writing it. To do a read or a take, you create an
entry of a preferred type, you fill in the fields whose values you care
about, and you pass it to a
method. A filled-in field has to match exactly. A field that is not filled
in—a field left
null—is ignored. If I ask for one type, I
can get a subtype. JavaSpaces provides a simple way for me to ask
you to do something, for you to do things you know how to do, and
then for me to look for the results. You can design protocols on top of
this basic set of operations.
JavaSpaces is sometimes called a kissing cousin to Linda, the work on which it is based. Whereas Linda was structural, JavaSpaces has added objects to the system. JavaSpaces is a distributed, object-based system. JavaSpaces has transactions like some Linda systems, but it has distributed transactions. So JavaSpaces clearly is an inspired work. We took the insights David Gelernter and his crew used to create Linda, and applied them to a new domain, with differences that make sense to that domain.