Advertisement

Bill Venners: Here's another quote from your book: "Uncoupling senders and receivers lends to protocols that are simple, flexible, and reliable." How does decoupling senders and receivers help you build simple, flexible, and reliable systems?

Ken Arnold: Decoupling leads to that; it doesn't guarantee it. Nothing prevents people from doing bad things, except straight jackets and rubber balls—no sharp edges. If something is useful, it can be abused. But JavaSpaces leads in that direction. Programmers of the various actors in a system need not understand, nor rely upon, the way other actors in the system are structured. Is it one actor or three that performs this particular operation? Are there one or multiple actors of the same kind in the system? Might writing one entry actually result in a cascade of 37 other entries written in by other actors? Those things are out of the requester's sight, as long as the result comes back.

I mentioned idempotency in regard to distributed system design (see Part III of this interview). It is useful here as well. You want to make your algorithms for using JavaSpaces idempotent as well. You want to be able to write the same entry and, as a general rule, have it be harmless. Because if you don't receive an answer in some humanly defined reasonable amount of time, you might decide: Hey, somebody dropped the ball. Better write another one in.

You can think about it this way: If you design a traditional system using RPCs, or whatever you want to use, in the end you design an architecture of actors and determine how they communicate with each other. You decide what messages they can send to each other, what the error states are, and what the responses are. When you design a system using a JavaSpace, you essentially do the same amount of work, except you replace messages with entries.

The JavaSpace provides you with this robustness mechanism. You write entries into it. You can replicate the space. There is at least one commercial implementation of a replicated JavaSpace. The space can be fault tolerant. It can survive crashes. You can have transactions so things don't get dropped on the floor. If I remove something to compute your results and then I crash, the transaction will timeout, abort, and then entries will appear for somebody else to take.

There is a great story about a group building a project called Viper. The project basically uses a JavaSpace as a compute model. You write a task into the space that represents a large complicated simulation. Then there are compute servers that will take out the tasks, whatever they are, and invoke their run method. The servers don't know what the run method does, they just invoke it. Whatever the run method returns, the servers write back in the space. Then they retrieve something else. Essentially they just donate cycles to run these jobs. The servers download the code associated with the job and they execute it.

When the system is in beta, a guy puts in a large fluid dynamics calculation, and he realizes he put in the wrong one. Rather than wait two hours to get the wrong answer back, he finds the compute server executing his entry, and he kills it. He kills off the virtual machine. So the transaction times out, and the request returns to the space. It is now visible for someone else to take, because the transaction has aborted. So someone else takes it and starts executing it. And he goes and he kills that one. He follows this thing around the network, and he cannot kill the job. This is not the typical problem people have in a distributed system, right?

You asked how JavaSpaces help you make reliable systems. It can do it like that. If those servers were failing because the hardware was flaky, it would also work. You don't have to have some guy going around shooting things. The project Viper people learned they have to have a Cancel button. You can cancel jobs in several ways. I don't know how they did it, but they solved it. I can imagine five designs to solve it. But the main point is, using exactly the technology they have now, they could have built a system with 100 compute services where each one is down 50 percent of the time. And they would still be able to get work done. The client wouldn't know that only half of the compute servers were working. It might be too slow. They might decide that 50 percent is a bad down time. If they start replacing the systems, the performance would get better. But it would be robust.

People talk about five nines, six nines reliability. (Five nines is 99.999 percent reliability.) They usually try to reach the desired number of nines by making each component more reliable. But if you design a system like Viper, you can make it reliable with unreliable components that are much cheaper, more plentiful, and easier to come by. At some point, every component is unreliable. I would much rather build a system on that principle than try to build a system that never goes down. 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.

Talk Back!

Have an opinion about JavaSpaces, public fields, or reliability? Discuss this article in the Cool Stuff Forum topic, Sway with JavaSpaces

Resources

Perfection and Simplicity, A Conversation with Ken Arnold, Part I:
http://www.artima.com/intv/perfect.html

Taste and Aesthetics, A Conversation with Ken Arnold, Part II:
http://www.artima.com/intv/taste.html

Designing Distributed Systems, A Conversation with Ken Arnold, Part III:
http://www.artima.com/intv/distrib.html

You can obtain information about Linda from here:
http://www.cs.yale.edu/Linda/linda.html

Ken Arnold first mentioned idempotency in Part III of this interview:
http://www.artima.com/intv/distrib.html

JavaSpaces: Principles, Patterns, and Practice by Eric Freeman, Susanne Hupfer, and Ken Arnold, the book from which Bill Venners reads quotes in this article, is at Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0201309556/

The Jini Community, the central site for signers of the Jini Sun Community Source License to interact:
http://www.jini.org

Download JavaSpaces from:
http://java.sun.com/products/javaspaces/

Design objects for people, not for computers:
http://www.artima.com/apidesign/object.html

Make Room for JavaSpaces, Part I - An introduction to JavaSpaces, a simple and powerful distributed programming tool:
http://www.artima.com/jini/jiniology/js1.html

Make Room for JavaSpaces, Part II - Build a compute server with JavaSpaces, Jini's coordination service:
http://www.artima.com/jini/jiniology/js2.html

Make Room for JavaSpaces, Part III - Coordinate your Jini applications with JavaSpaces:
http://www.artima.com/jini/jiniology/js3.html

Make Room for JavaSpaces, Part IV - Explore Jini transactions with JavaSpaces:
http://www.artima.com/jini/jiniology/js4.html

Make Room for JavaSpaces, Part V - Make your compute server robust and scalable with Jini and JavaSpaces:
http://www.artima.com/jini/jiniology/js5.html

Make Room for JavaSpaces, Part VI - Build and use distributed data structures in your JavaSpaces programs:
http://www.artima.com/jini/jiniology/js6.html