Slashdot Mirror


JavaSpaces Principles, Patterns and Practice

The growth of processor power notwithstanding, for tasks which can be parallelized, relying on a single processor can be counterproductive. Instead, efforts to distribute computing resources are becoming ever more important. Jayakrishnan brings us this review of JavaSpaces Principles, Patterns and Practices, proof that the tools to accomplish that are steadily becoming accessible to non-PhDs.

JavaSpaces Principles, Patterns and Practice author Eric Freeman, Susanne Hupfer and Ken Arnold pages 344 publisher Addison-Wesley rating 8 reviewer Jayakrishnan http://varnam.org ISBN 0-201-30955-6 summary A comprehensive resource for anyone developing distributed applications using JavaSpaces.

The Book JavaSpaces technology is a high-level coordination tool for gluing processes together into a distributed application. For a technology that has to handle latency, synchronization, and partial failure the API is very simple and easy to use. JavaSpaces is based on the "Linda" coordination language developed at Yale University. Two of the authors, Dr. Freeman and Hupfer have spent a decade in designing and implementing space based applications as part of the Linda research group and the third Ken Arnold was in charge of the JavaSpaces project at Sun Microsystems.

The book teaches the principles, patterns and practice of JavaSpaces technology.

The principles are very simple. The API is very minimal with just seven methods and that is all you need to write distributed applications using JavaSpaces. There is a tutorial introduction to the API and by the end of chapter two, you will be able to write your own distributed applications. The building blocks for space based programming is distributed data structures. The distributed version of arrays, shared variables, and unordered data structures are described in the chapter "Building Blocks". The concepts of leases, distributed events and transactions are covered in detail in separate chapters.

The patterns in distributed programming are those of synchronization, communication and application. One of the main concerns in distributed programming is synchronization. But this task is simplified in JavaSpaces as synchronization is built into the space operations. The synchronization chapter covers implementing semaphores, using multiple semaphores, using various synchronization techniques like round robin and barrier, and finally the readers/writers problem. In the loosely coupled communication style of space based programming the senders and receivers can remain anonymous. The communication patterns are variants of the distributed data structure---channels. The chapter on Application Patterns presents the frameworks for solving compute-intensive problems like ray tracing or generating computer animations and frameworks for producers and consumers of resources.

All these concepts are put together to develop two real world applications to show the practice of JavaSpaces. The first one is a collaborative application---an interactive messenger service and the other is a parallel application for breaking password encryption. These examples cover everything from the basics, to useful distributed data structures to advanced topics like distributed events, transactions and leasing.

The final chapter of the book provides a list of resources for further reading both for JavaSpaces and its foundation the Jini technology. The appendix includes the official specs of JavaSpaces from Sun Microsystems.

What's to consider?

For people new to JavaSpaces this book is a good tutorial introduction. If you write distributed applications in some other language, you will find the patterns section of the book very useful, where you can learn how to implement the common patterns using JavaSpaces. The individual methods of the API are covered in detail and finally the broad picture is presented where the different pieces fit to solve a problem.

Even if you are not in the field of distributed application development, you can read through the book to get an understanding of this new programming paradigm. The narrative is smooth and all the concepts are illustrated with code samples and interesting examples. Each chapter of the book has an associated set of exercises. These exercises prompts the reader to explore his understanding of the topic by enhancing the examples described in the chapter.

Summary

This book serves both a tutorial as well as a reference. If you are new to JavaSpaces or are an experienced distributed application developer, this book will be a valuable resource.

16 of 38 comments (clear)

  1. Linda is cool by eries · · Score: 2

    I've worked in Linda (on which JS is based) when I took a class from Prof. Gelernter himself. It's definitely the most elegant parallel API I've come accross, and it is extremely elegant and simple. Best of all, much of the work of moving data around between machines is hidden by the environment, which does this in a very efficient way. In fact, I'm convinced that there is a way to get a Linda/JS system running on top of Freenet, which would give you instant access to a huge pool of system resources, and an internet-wide distribution mechanism. What do you think about that?

  2. Re:Fast enough? by SimonK · · Score: 2

    High performance != numerics. The authors of the paper you linked are interested in highly accurate floating point processing, something which is pretty rare. I'm unaware of anyone ever arguing that this was an appropriate use of the Java environment.

    Similarly the paper you linked that "debunked" the WORA "myth" didn't. It just said it had been debunked. Server-side Java's WORA promise holds good (from wide personal experience, and industrial usage), client-side it is much easier to break *but* can still work.

    JIT compilers can at times optimise better than ordinary compilers. For instance, they can perform data-dependent optimisations based on the data arriving during this particular run. OTOH (at least in Java) they can't perform optimisations that need lots of static type information as most of this has been lost. I don't consider the case proven either way.

    Oh, and Java is "standardised" by Sun. While I agree that a language controlled by a commercial entity is unusual and potentially harmful its plain silly to make arguments about what "might happen when Java is standardised" as noone with clout has any incentive to push for this to happen.

  3. Java startups... by LinuxParanoid · · Score: 2

    If you're interested in JavaSpaces and distributed.net-type computing, you might check out http://www.popularpower.com/. It's hard to tell from the webpages whether it uses JavaSpaces per se, but it clearly uses Java virtual machines as the sandbox for distributing parallel computations across thousands of nodes on the Internet, and they do have Windows and Linux clients.

    The current workload appears to be a pure volunteer effort aimed at helping develop better flu vaccines, but once installed, obviously other (for-pay) algorithms implemented in Java could be run on the client, with Java's sandbox preventing you from virus-type problems. Interesting stuff.

    --LP

  4. Setting up Re:My biggest complaint with the book by tangram · · Score: 3
    The authors have posted a guide on Sun for how to set up JavaSpaces.

    See:
    The Nuts and Bolts of Compiling and Running JavaSpacesTM Programs by Susanne Hupfer.

    Their instructions worked, but it wasn't always clear what had to be named exactly as in the examples.

    They've also posted errata at the book's site.

    Regards,

    --tangram

  5. Linda Not a Silver Bullet by nellardo · · Score: 3

    Having both worked with Linda variants before and critiqued their designs, I have a couple of comments I'd make before rushing out to learn JavaSpaces.

    While some classes of distributed programming problems are trivial to implement in Linda-likes, others are at best no easier and may even be harder. Some examples of things that are easier:

    • A work queue or a distributed server farm. Spawn a bunch of processes, and have them all take tasks off of one common queue. So long as tasks are sufficiently complex that network isn't the bounding factor, you can add and drop processes willy nilly and everything still works. You can even do some load balancing - if a process looks at its task and says "Ugh, too big" and can split it into two tasks, it can keep one and enqueue the other.
    • A semaphore controlling access to a shared resource. Simply use one slot with a dummy value. Any process that wants the shared resource must first remove the dummy value. When done with the resource, it must put it back. Because of the way slots work, any other process that wants the resource waits until the dummy value gets put back.

    However, both of these are fraught with the usual perils of distributed programming. Deadlocking a Linda-like system is trivial:

    • Make processes A and B and slots a and b.
    • Proc A uses slot a to send stuff to proc B.
    • Proc B uses slot b to send stuff to proc A.
    • Proc A reads from slot b (blocking until B puts something there).
    • Proc B reads from slot a (blocking similarly).
    "So don't make those kinds of loops! Duh!" But cycles are difficult to avoid (unless you're using a pure (and I mean pure) functional language). Consider a real-world system and think about how easy it might be for such a cycle to accidently spring up among a network of a dozen processes, each with their own complex flow control. Consider the following simple mistakes for the work queue and semaphore above:
    • If tasks depend on results from other tasks, then you lose parallelism.
    • Forget to put the value back, or forget to take it in the first place.
    And of course, "good programmers will avoid those pitfalls." Uh huh. BTDT. "Good programmers don't need revision control." Heard that, too.

    Programming in Linda-likes is a lot like programming in Self. If Self slots were queues (and Self is so flexible, you can make them queues if you want), it would be a Linda-like. Self makes some things really easy, but it's the old flexibility problem - get enough rope, hang yourself six ways til Sunday.

    --
    -----
    Klactovedestene!
    1. Re:Linda Not a Silver Bullet by Hard_Code · · Score: 2

      Exactly. But how do these problems differ from general programming problems? E.g., if I have a multithreaded application, I still have to consider deadlocking. Of course a shared space doesn't magically solve these problems. You will just have to create new semantics with the space implementation of a "shared" resource to prevent deadlocking, just as you would in a normal program.

      --

      It's 10 PM. Do you know if you're un-American?
  6. Re:And the point of this review was... ? by substrate · · Score: 2

    It's slashdot's right to post whatever they want. It's your right to go elsewhere as I did for a long while. I voted with my feet. Their reason for posting it could only be because somebody made the editorial decision that perhaps people would be interested in reading it.

    They were obviously correct, a number of people, including yourself, read it.

    In the context of comparing the post to amazon.com it may well be redundant but not everybody browses book reviews at amazon.com. All of the postings on slashdot are redundant, all slashdot does is (attempt to) distill down information that its readers may find interesting.

    Why was it written? It may have been because somebody thought they were doing a favour. It could have been because they get off in seeing their name in lights or it could be for additional positive karma.

  7. Re:Fast enough? by Overt+Coward · · Score: 2
    but is Java really fast enough for distributed applications?

    The speed bottleneck in a distributed systems is generally the communications overhead (including marshalling of messages), and not the implementation language. Use the language that you are most comfortable with and best suits your needs. Java can be a good choice if multithreading and platform-independence (and Java is very good at platform-independence on the server side) are key considerations. C-family languages would be better if you need to rely on linking to existing object libraries. Et cetera.

    --

  8. More JavaSpaces links... by petersp · · Score: 3

    Here's a 5 part hands on tutorial on JavaSpaces:

    Part 1
    Part 2
    Part 3
    Part 4
    Part 5

    .peter

  9. Re:And the point of this review was... ? by Pilchie · · Score: 2

    I like /. book reviews, because I like to see what other books people have found. I don't spend much time browsing bookstores, either online, or IRL, so it is nice to have a place where I can go, and have someone say, this is a good book. I realize that this means I am allowing /. to act as an advertiser of sorts, but I am more comfortable with the idea of trusting a /. review than I am about trusting the jacket cover. So in conclusion, if you were thinking of buying this book, then the review is probably redundant. OTOH, if you didn't know that the book existed, then it could be very useful.
    >~~~~~~~~~~~~~~~~

    --
    >~~~~~~~~~~~~~~~~
    Pilchie
  10. TSpaces is a much simpler introduction... by makisupa · · Score: 3
    JavaSpaces Principles, Patterns and Practice does cover its 3 p's, but it definately does not address the involved setup of Jini/RMI/JavaSpaces.

    Which, as it turns out, is just fine, the same p's can be applied with comparitive ease to IBM's TSpaces.

    Setting up Jini/JavaSpaces is pretty involved if you're just looking to take it for at test drive.

    In fact, after a detailed (i.e. reading 3-4 books) look at JavaSpaces and Jini as candidates for my current project at work I decided that the overhead was just too much for my small team of 2-3 developers to mess with.

    On top of that, I found JavaSpaces querying abilities lacking. It is only capable of comparing objects in serialized form using bitwise comparison.

    The consequence? If you're looking for an object with a timestamp within a certain range you're pretty much SOL in JavaSpaces.

    Luckily enough though, I discovered TSpaces shortly there after. It's similar to JavaSpaces in that it uses the same general space-based api of read/write/take.

    But its advantages are that (1) the server is a single, easy-to-start, java process (2) you can do range queries based upon the actual compare() methods of objects and (3) the guys who are working on it are accessible for questions and feature requests via the tspaces mailing list.

    Granted, it doesn't address discovery and some of the nicer features of Jini, but it is incredibly simple to set up in comparison to JavaSpaces and 6 months later I'm still glad I chose it.

    So for those of you who want to take the principles, patterns, and practice of space programming for a test drive, go grab the TSpaces jar and you'll have a server up and be coding in 5 minutes.

    Jackson Gibbs gibbs@roguewave.com

    --
    "A matter of internal security, the age old cry of the oppressor" - Jean Luc Picard
  11. My biggest complaint with the book by ry4an · · Score: 4

    My biggest complaint with the book was its lack of detail about the setup of an actual Java Spaces environment. I understand that even with the (sorta) WORO Java that steup of a Space differs between platforms, but there's enough similarities between installations that some directions would've been helpful -- especially things like property setups.

    Furthermore, I understand that the book is more about the API in general than in Sun's first implementation of said API, but what good is making the source for your examples available online if you're not going to provide sufficient information to get a space up.

    Maybe I'd be less bitchy if I hadn't spent 10 hours pawing through java spaces mailing list archives to find the arcane properties necessary for setup, but a little help from the author (who udoubtably knew the sad state of Sun's installation instructions) would've been a huge help.

    That said I found the notion of space based distributed systems very interesting and have since gone on to look at T-spaces and other predecessors as well.
    --

  12. Re:Any negative reviews? by jyuter · · Score: 2

    I would find it more useful to have reviews that also say "This book, while it may look like a winner on the shelf, is really a steaming pile of crap and should be avoided."

    Slashdot is a resource for many people and is not a site purely for book reviews. I think it's more useful to tell people what's good to sort of "moderate" if you will the book's quality. There are plenty of bad books out there, more than /. can cover. Personally, I think I'm better off being told "buy this book - it's good" than "avoid this like the plague."

    I would agree that if there is a popular book or series which many people own or will purchase eventually that /. do a critical review and "tell it like it is."





    Being with you, it's just one epiphany after another

  13. Any negative reviews? by / · · Score: 5

    I'm hard pressed to remember the last time there was a book review on slashdot that had a negative opinion of the book reviewed. Is this because of self-selection by reviewers, either to bother writing reviews about only books that matter or to promote books that reviewers prefer? I would find it more useful to have reviews that also say "This book, while it may look like a winner on the shelf, is really a steaming pile of crap and should be avoided."

    --
    "If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
  14. Java in Space by Pac · · Score: 2

    Java license says that:
    The Software is not designed or intended for use in on-line control of aircraft,air traffic, aircraft navigation or aircraft communications; or in the design, construction, operation or maintenance of any nuclear facility

    So, as any minimally interesting space operation obviously require some kind of "aircraft navigation or aircraft communications", and the reviwer clearly states that "But this task is simplified in JavaSpaces as synchronization is built into the space operations", this technology is obviously breaking Sun's license.

    I think Slashdot should not allow this kind of criminal activity in its pages.

  15. Useful Sun Links by jyuter · · Score: 3

    Chapter 11 is posted on Sun's site.

    There is also a basic overview of JavaSpaces here (in PDF)

    Finally. the JDC



    Being with you, it's just one epiphany after another