Summary
Ken Arnold, the original lead architect of JavaSpaces, talks
with Bill Venners
the data-driven nature of JavaSpaces, how JavaSpaces facilitates
decoupling,
and why iteration isn't
supported in the JavaSpace interface.

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 Part IV, 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.
In this fifth installment, Arnold talks about
the data-driven nature of JavaSpaces, how JavaSpaces lets you "throw in
a grain and watch it grow,"
and why iteration isn't
supported in the JavaSpace interface.

Type versus State

Bill Venners:In both the Jini lookup service and in
JavaSpaces, you can look up objects by both type and state. For Jini lookups, you can
specify the types of service you want plus the types and values of attribute entries. In
JavaSpace reads and takes, you specify an entry type and field values. How do the kinds of
questions you ask in your query differ when you look up objects by type versus by
state?

Ken Arnold: The difference is function. If you are writing code that talks
to some data source, you can ask it questions. Method calls let you ask the data source for
the information you want, and get the answer back. You can view a particular set of
method calls as a particular socket shape. So you've written code that translates when you
compile it into these method invocations. If those method invocations are all resolved
locally, you would have another class to plug into that socket. With a Jini lookup service,
you actually go on a network and ask: Is there anything on the network that plugs into this
socket? Data is not the point there. It is only methods that matter in that part of the query.

JavaSpaces tries to accomplish something rather different. Yes, JavaSpaces is data-driven. It is object-oriented in the sense that the entries have type and you can match
subtypes, and that entry fields can be object types. But at some point, you get past objects
in any system. At some point, you call a method with an integer value. In some languages
that integer is still logically an object, but it doesn't contain other objects. At some point,
you hit the bottom. JavaSpaces is a bottom point in the sense that it is a way to make an
asynchronous method call. You can consider that the entry fields are like the parameters to
the method call. The fact that those are data shouldn't bother you, because that is when
you hit bottom.