JXTASpaces: A Distributed Shared Memory Service for JXTA


News: JXTASpaces: A Distributed Shared Memory Service for JXTA

  1. We are having a lot of Spaces talk. James Strachan announced ActiveSpaces recently, and now the JXTA gang are getting in the action with JXTASpaces.

    Project Description and Overview
    jxtaSpaces is an experimental project to design and implement a distributed shared memory service on the JXTA peer-to-peer computing platform.

    Generative Communication Model

    Distributed shared memory is a model for inter-process communication that provides the illusion of a shared memory on top of a message passing system. Programming distributed applications using a shared memory abstraction is less complex than explicitly using message passing. In addition, the DSM model allows communicating processes to be uncoupled logically, temporally, and spatially.

    A well-known software implementation of distributed shared memory is the generative communication model, best represented by the Linda coordination language for parallel computing. In this model, processes share a virtual memory space called a tuplespace. The fundamental data unit, a tuple, is an ordered vector of typed values. Processes communicate by reading, writing, and consuming these tuples. Another distinguishing feature of tuplespaces is that tuples are accessed associatively, that is, by their contents rather than by their addresses. A simple set of familiar operations allows highly complex communication and synchronization schemes to be constructed using this model.

    The tuplespace model for distributed programming has recently seen an increase in popularity, with commercial systems in Java available from Sun (JavaSpaces), IBM (TSpaces), and others. These products differ from (and improve upon) the original Linda system in various ways, most notably by being object-oriented and not requiring language extensions or a special compiler.

    Distributed Tuplespaces

    Most tuplespace systems assume one or more spaces running on one or more processors; however, the notion of distributing a single space over multiple processors is less common. Suns JavaSpaces, for example, supports multiple local and remote shared spaces, but does not explicitly support distributed spaces. IBMs TSpaces has similar limitations.

    True distributed spaces offer many advantages, in particular scalability and availability. jxtaSpaces intends to provide scalable shared memory services for networks of heterogeneous peers. In large peer-to-peer networks, a global shared memory can be used in many ways to simplify the building of complex distributed applications.
    See the new JXTASpaces project.
  2. I not agree with the quote that only JXTASPaces will provide a true DSM among heterogeneous nodes. One of the basic features that we at GigaSpaces provide is a p2p replication between JavaSpaces. This leads to a single virtual space between as many nodes as connected into the cluster. For more info please visit our web site www.gigaspaces.com

    Anyway, being a big fan of spaces and p2p technologies (including JXTA) I think that this project can contribute a lot for the mind share.

    Yura Kupitman
    VP R&D
    GigaSpaces Technologies
  3. I must agree with Yura. We at IntaMission have had a single system image (SSI) capability for some time. This approach, described in more detail on our website, provides very high availability and scalability by federating nodes to create a large, dynamic, logical space. Nodes can be added or removed at any time without impact to users of the space. Components and services that use the space are insulated from knowledge of whether the space is a single instance or a federation, allowing that decision to be made at runtime.

    That being clarified, the interest being shown in space-related technologies is a good sign that this approach to building distributed systems is gaining the mindshare it deserves.

    Patrick May
    IntaMission, Ltd.
  4. It's a shame that reference is made to Sun's JavaSpace implementation, unlike many other reference implementations it's a long way short of the industrial versions from the two vendors above (see previous comments).

    Being the JavaSpaces part of "James Strachan's" ActiveSpaces and a big fan of grid-like technologies (like the others, this includes JXTA) I must point out that distributes spaces, space replication, partial replication, load balancing and replication matrices are all common features of GigaSpaces, we use it regularly. Read a little more here --> http://www.gigaspaces.com/product_2.html

    We have designed and implemented some seriously sexy architectures for major banks using these technologies. We have seen an exciting move towards JavaSpace architectures, they are light-weight, scalable and incredibly high performance. I obviously can name the bank other than it's one of the largest in the world but they are currently implemented a number of high performance projects using JavaSpaces while dropping the existing .NET implementations. When you start to get to 10-20,000 messages (quotes) per second being sent to 10-15 international exchanges where you need to sort the messages in real time based on the exchange's criteria first there's not a lot of choice other than something like JavaSpaces.

    JXTASpaces is good news, it just goes to show the increasing interest in this area.

    -John Davies-
    CTO, C24
    London, UK
  5. I'm glad that the interest in TupleSpaces is growing.

    We've been sitting on this technology for almost 8 years, wondering
    if we're goofy for for liking this style of Message oriented middleware,
    or if the rest of the world is just slow in catching up.

    I think the world is slowly catching up.

    More and more, I'm seeing folks talking about asynchronous middleware
    with data persistence. We've been doing this for so long, it just
    seems to us like a very natural way to go. We've spent almost three
    years using TSpaces in the OptimalGrid project, and we're just amazed
    at how many things are made easy by using a TupleSpace, whereas they
    would appear to be much harder and more complex using other methods.

    It will be interesting to see just how the whole field of distributed
    communication unfolds. I can't wait.

    Toby Lehman

    Office: (408) 927-1781 (IBM tieline 8-457-1781)
    ARC Fax: (408) 927-2100 (IBM tieline 8-457-2100)
    Home Page: http://www.almaden.ibm.com/cs/people/toby
    Project Page: http://www.almaden.ibm.com/cs/TSpaces
  6. Seems the subject is sensible : take a look at the previous comments; much should be considered as spam ...

    Perhaps should it be necessary to "moderate" the comments before publishing...
  7. Tspaces[ Go to top ]


     How do Tspaces differ from Jini using javaspaces ?
  8. Tspaces[ Go to top ]

    Toby, How do Tspaces differ from Jini using javaspaces ?
    TSpaces is closer to the original TupleSpace concept than JavaSpaces in that it is properly tuple/list-oriented whilst JavaSpaces is a little more "OO" in that each thing you store in the 'space is an instance of some class which implements the Entry interface.

    TSpaces also has a collection of additional operations to provide advanced querying and some operations to allow "scanning" of groups of tuples. The JavaSpaces specification doesn't have such features *yet* but there's work being done on specification modifications which will cover iteration/scanning and bulk operations (to make certain usage scenario's easier to program). I suspect that JavaSpaces will never feature "advanced querying" but there's some talk currently about adding an "Executor" which would allow one to move custom code to the JavaSpace for execution which has some interesting possibilities (TSpaces has something similar though I don't know how security issues are addressed).

    TSpaces has an event notification mechanism as does JavaSpaces and, again, TSpaces has a broader API. Again, there's work going on in the JavaSpaces community to develop some similar features probably designed to work in co-operation with the iterator.

    That's by no means a complete breakdown, I'm sure Toby can add more but hopefully it's reasonably helpful.

  9. Did this go anywhere? Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid