Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

JavaSpaces Principles, Patterns and Practice 38

Posted by timothy from the everybody-needs-some-elbow-room dept.
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.

This discussion has been archived. No new comments can be posted.

JavaSpaces Principles, Patterns and Practice More

JavaSpaces Principles, Patterns and Practice

Comments Filter:
  • 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?
  • Perhaps, but a moment of careful meditation will make you realize that parallel and distributed applications are horses of a different colour, even though they may race on the same track sometimes...
  • I'm going to use this sparingly, so I don't get bitchslapped right away.

  • And of course, "good programmers will avoid those pitfalls." Uh huh. BTDT. "Good programmers don't need revision control." Heard that, too.

    Not being a masochist to your mind and being able to realize the utility of stuff IMO is what makes you a good programmer.. :)

    It makes you more effective and most people (programmers) are ONLY human so I totally agree with that statement

    Jeremy


    If you think education is expensive, try ignornace
  • 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.
  • Could it be that there just arent enough hours in the day to bother reading the really nasty books?

    (sorry if this is redundant)
  • This question gets asked about every third or fourth book review. (Check if you don't believe me.) The answer, as always, is the same: the reviewers review books they want to review, which usually means books they liked. If I read half a crappy book and then toss it back on the bookcase, am I going to take the time to write up a review? Not unless some editor forces me to... and we don't do that.

    I suppose if I read something really blatantly bad, really pustulent and horrid, I might be tempted to review it and pan it, in the spirit of "Mission to Mars". But if it were merely bad, merely not-so-good, where's the motivation?

    Note that readers are welcome to submit book reviews to slashdot for posting! If they're any good (by which I mean well-written, not necessarily favorable) we'll post them! Submit your negative reviews if that's what you want to see... For example, I haven't found any really bad O'Reilly books yet, but if there are any, I want to know, because when I want to learn about a subject I usually just find the O'Reilly book on that subject and buy it, sight unseen. Save me from buying an O'Reilly stinker! :)
    --
    Michael Sims-michael at slashdot.org
  • Actually though the first few chapters were good the last half of the book seemed a bit stretched and arbitrary. Maybe that's just a case of the API being so simple. I would have been happier with a single, much more sophisticated example than the series of lightweight ones that were given.

    I guess it just plays to my worries about the scalability of the current implementations of JavaSpaces. Does anyone know of any enterprise-class applications of JavaSpaces or tuple spaces in general.

  • 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.
  • It's nice to books of this nature come out and get good reviews. I am a huge fan of distributed.net which is a distributed application working to break crypto right now. I would love to see more distributed applications written that can be utilized in house to do big number crunches or huge image renderings. I can see lots of uses for applications of this nature in the business world where companies use lots of little boxes to do the work of a a couple big boxes.
  • I also had a lot of problems trying to setup JavaSpaces. Once it is setup, it's pretty straight forward. Apparently TSpaces is a bit more "out-of-the-box" but I prefer JavaSpace's simplicity once it is setup. The following link appeared at Sun after I had figured it out myself but should be useful for novices. http://developer.java.sun.com/developer/technicalA rticles/Programming/javaspaces/index.htm l
  • Maybe we need a section for short, "X Book Considered Harmful" style reviews that people could post. Although frankly, that would be so much extra work for the /. crew, it would probably be better suited to a smaller site with user story posting moderation, like kuro5hin.

    Walt
  • 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

  • Setting up Re:My biggest complaint with the book (Score:3)

    by tangram ( 23057 ) on Tuesday July 11, 2000 @06:39AM (#942516)
    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 [sun.com] 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 [sun.com].

    Regards,

    --tangram

  • Linda Not a Silver Bullet (Score:3)

    by nellardo ( 68657 ) on Tuesday July 11, 2000 @06:44AM (#942517) Homepage Journal

    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. [sun.com] 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.

  • 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.

  • Chapter 11 is posted on Sun's site.

    sun went chapter 11? why didnt this hit the front page! :D
  • 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.

    --

  • High performance programming is likely to be dominated by Fortran/C/C++ for quite some time. There are some well known [berkeley.edu] reasons why one needs to take any Java based numerical application with a truckload of salt.

    Moreover, the write once run anywhere myth has been debunked [stsci.edu] in many places. JIT's in general cannot achieve what a good optimizing compiler can do (PC's generally do not have good optimizing compilers, though they are starting to appear on Linux platforms). A very good way to tell if your C++ compiler is poorly optimizing, is if your Java and your C++ application (identical ones, doing identical work) run at the same speed.

    All that said, Java, should it ever become standardized, could be an interesting platform to work on such applications. It is not a computational powerhouse like Fortran, or a string processing powerhouse like Perl, but it has its uses. Once it is standardized, many of the design flaws (numerical, etc) can be fixed properly. After that it might start to get interesting as a distributed computational tool (more of a controlling tool than the tool for calculation).

  • Javaspaces still seems very vaporous and Sun really wants it tied to JINI. If you are interested in using message-passing/persistent storage mechanism like a Tuple space, check out IBM's TSpaces at alphaWorks: http://alphaworks.ibm.com/tech/tspaces

    It's real, robust and free (beer), and has a lot of active development, and they are very open to outside suggestions (in fact they ask for bugs/suggestions before releases). This is not vapor, and I can vouch that it is the core of at least one production enterprise application here.

  • More JavaSpaces links... (Score:3)

    by petersp ( 21294 ) on Tuesday July 11, 2000 @07:39AM (#942523)
    Here's a 5 part hands on tutorial on JavaSpaces:

    Part 1 [javaworld.com]
    Part 2 [javaworld.com]
    Part 3 [javaworld.com]
    Part 4 [javaworld.com]
    Part 5 [javaworld.com]

    .peter
  • I just tend to assume that any book on the shelf in a computer store sucks unless I've heard great things about it. this is probably a pretty reasonable bet, I would imagine.
  • 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.
  • If you are going to put a link saying that a myth has been debunked, the link should at least debunk the myth -- what you have linked just says that someone went to a class where the WORA myth was debunked without doing any actual debunking! Which wasted my time in following the link..
  • 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.
    >~~~~~~~~~~~~~~~~
  • Although you can compile Forte apps, running them in interpreted mode works just as well for a lot of applications.

  • TSpaces is a much simpler introduction... (Score:3)

    by makisupa ( 118663 ) on Tuesday July 11, 2000 @09:17AM (#942529) Homepage
    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 [ibm.com].

    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

  • 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.
    --
  • 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

  • Any negative reviews? (Score:5)

    by / ( 33804 ) on Tuesday July 11, 2000 @06:08AM (#942532)
    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."

  • I know this an age-old question, but is Java really fast enough for distributed applications? Or is that it's necessary to write multi-threaded applications in Java, or otherwise they will be too slow?

    It seems that parallel programming is dominated by C and Fortran, not even C++.

  • It depends on what you're doing of course, but Java can be fast enough.

    Sometimes it's not speed, but ease. It's relatively easy to send data back and forth under Java to clients from a central server. Three of my friends did a distributed fractal images program (it did more than that, but it was neat).

    You can have the one java code work under all the different platforms you're using, which could make the creation of new clients easier to deal with (this is not always true, Java is more crossplatform than many languages out there, but it's not perfect).

    Java is fast enough. Granted, it'd be much faster with c/c++, but doing networking for multiple platforms under that can be a bit more difficult and time consuming. ymmv.
  • 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.

  • Useful Sun Links (Score:3)

    by jyuter ( 48936 ) <<jyuter> <at> <gmail.com>> on Tuesday July 11, 2000 @06:10AM (#942536) Homepage Journal
    Chapter 11 [sun.com] is posted on Sun's site.

    There is also a basic overview of JavaSpaces here [sun.com] (in PDF)

    Finally. the JDC



    Being with you, it's just one epiphany after another
  • Sorry, hand slipped. Disregard last line



    Being with you, it's just one epiphany after another
  • I just wish there were some way of breaking down the submissions by category as rejected by the editorial staff. There's a big difference between having lots of reviews being submitted but rejected as and having what few reviews submitted get posted.
  • It depends on you application. For many, the faster deveopment cycle, fewer bugs, more maintainable code, and portability, more than makes up for the lack of speed. For hard core perfomance hungry applications, it doesn't.
  • This slashdot quality control issue really must be dealt with. For example, what was the point of posting this review? If I'm thinking about buying this book, I'll obviously look at amazon's page (even if I'm purchasing from fatbrain or brick-and-mortar).

    The "The Book" section is exactly the type of material that one finds in Amazon's Editorial Review sections, and as such is not only redundant but also uninformative, providing minimal information about the book itself and sounding more like a paraprasing of a JavaSpaces whitepaper.

    The "What's to consider" section of this review has the only marginally interesting content, summed up into 150 words, perfect for an Amazon.com comment. And what do you know! The amazon comments sound just like this one!

    So, why was this review posted, or more to the point, why was it written?

Slashdot Top Deals

"Trust me. I know what I'm doing." -- Sledge Hammer

Close