Discussions

News: Letter to the Unconvinced about JavaSpaces

  1. Letter to the Unconvinced about JavaSpaces (25 messages)

    Owen Taylor, an employee of Gigaspaces, has written a "letter to the unconvinced," covering what JavaSpaces can do and actually does for a given deployment: makes stateful applications go faster, creates fail-safe adaptive service-oriented applications, and enable interoperability between disparate applications, groups, and languages.
    JavaSpaces provides the following: An Object-centric architecture whereby multiple services share Objects that can possess behavior as well as data and are themselves events to those that desire them to be so. The dream of mobile code - a fantastic idea, that to me has tremendous potential, is quickly realized when using JavaSpaces because the very Objects you write to a space can act as units of work and implement quite complex workflow scenarios such as chains of command and state engines. I believe very strongly that it is a technical advantage to be able to write less code that accomplishes more. I also believe it is a strong technical advantage to have a service framework such as a JavaSpace that allows a single action such as the JavaSpace.write() call to encompass all the purposes of storing data (the state of the Object), creating events (triggering both the potential notification to multiple subscribers as well as the delivery of messages to those hungrily waiting on a queue), and moving essential logic from one place in the network to another.
    He then follows this up with a discussion of where Gigaspaces adds value to the JavaSpaces model, by adding partitioning, .NET and C++ APIs, and some other useful high-availability features.

    Threaded Messages (25)

  2. in other words it's a whole pile of buzzwords all shoved together. In what does that make it any different from a thousand other "new" "technologies" out there?
  3. Sorry... still not coninced[ Go to top ]

    after reading this article for the the unconvinced.
  4. We used a similar approach (Hub & Spoke ) in a large application (250 000 lines of code) and had a very positive experience. JavaSpaces takes Hub & Spoke to a distributed world. By the way, JavaSpaces is several years old, and by no way a new technology.
  5. Programming model[ Go to top ]

    I think the unconvinced are not convinced that they should alter their programming model just because the result is cleaner in certain cases. They figure it's not worth it.
  6. Re: Programming model[ Go to top ]

    I think the unconvinced are not convinced that they should alter their programming model just because the result is cleaner in certain cases. They figure it's not worth it.
    In many cases, they're probably right. Space programming takes some getting used to. Most of us are used to thinking in terms of sets, or rows of data (Hey, I remember CODASYL!) and spaces don't really support that very easily... but queues are almost painfully easy to support, and the architecture scales in some surprising, amazing ways. In many ways, space programming has many of the capabilities of JMS queues, without the weaknesses of JMS queues. There are other features, too: for example, as the article suggests, functional data can be part of the message, which makes implementation of a command pattern trivial. It's not a bad model at all, and is VERY powerful for some things. It's different, and there are fun and new problems to solve, but it's doable and actually very neat.
  7. Re: Programming model[ Go to top ]

    I think the unconvinced are not convinced that they should alter their programming model just because the result is cleaner in certain cases. They figure it's not worth it.
    In many cases, they're probably right. Space programming takes some getting used to. Most of us are used to thinking in terms of sets, or rows of data (Hey, I remember CODASYL!) and spaces don't really support that very easily... but queues are almost painfully easy to support, and the architecture scales in some surprising, amazing ways. In many ways, space programming has many of the capabilities of JMS queues, without the weaknesses of JMS queues. There are other features, too: for example, as the article suggests, functional data can be part of the message, which makes implementation of a command pattern trivial.

    It's not a bad model at all, and is VERY powerful for some things. It's different, and there are fun and new problems to solve, but it's doable and actually very neat.
    As I said, the programming model looks neat. Might I think convincing someone to use the model for real applications will take a lot of work. People are very careful (and they have to be) about what ends up on their resume. Another reason which I can imagine that people might resist this model is performance tuning, which they may also need learn all over again.
  8. Re: Programming model[ Go to top ]

    <I think the unconvinced are not convinced that they should alter their programming model just because the result is cleaner in certain cases. They figure it's not worth it.</blockquote>In many cases, as the article suggests, functional data can be part of the message, which makes implementation of a command pattern trivial.

    It's not a bad model at all, and is VERY powerful for some things. It's different, and there are fun and new problems to solve, but it's doable and actually very neat.
    Couldn't say it better Joseph! I think that the world is divided to those who get it and those that don't. You could clearly identify those who do. For the rest of you I would suggest to keep an open mind. There is a reason why so many first tier financial organization are betting their mission critical applications on that technology. Nati S. CTO GigaSpaces Write Once Scale Anywhere
  9. I'm convinced[ Go to top ]

    I have designed large JavaSpaces systems and put them into production as a vendor and "owned" large systems in banks as a consumer. JavaSpaces does work and it does save time and effort. It is a simple but very effective API for distributed (i.e. local or remote) programming. The relatively recent addition of a Spring wrapping has opened the API into the Spring world, Mule can use it as a container, C24 objects can be used internally for high-performance integration. JavaSpaces is the perfect model for the master-worker pattern. I don't work for GigaSpaces and never have, I admit they've bought me the "odd" beer but then most vendors have at some time. JavaSpaces is a seriously sexy architecture and GigaSpaces have a damn good implementation. I've met very few people who can really argue against a JavaSpaces architecture for large-scale distributed programming who actually understand it. Sadly it's also true that few people understand it but give it a chance, it's pretty cool stuff. -John- CTO, C24
  10. Looking forward to JavaSpaces[ Go to top ]

    From the letter we know with JavaSpaces framework we only needto write a little code ,good news. In fact, I'm very tired of OR Mapping(hibernate,CMP and JDO). I'm Looking forward to JavaSpaces. Ajax tutorial
  11. Damn Owen, do you realize what you're suggesting!?? Creating a massive, distributed system that is capable of playing Tic Tac Toe!? Last time I saw that implemented it nearly caused the end of the world. How irresponsible of you to suggest something like that! ;-)
  12. Do we give up OO-design?[ Go to top ]

    Consider the following code: class Category { Collection subcategories; Category parent; String name; } Category category = space.get(...); for (Category sibling : category.parent.subcategories) { System.out.println("sibling: " + sibling); } If the Category hierarchy is large, this can obviously not be done without lazy loading. I have not been able to find any JavaSpace advocate who can tell me if this is possible in JavaSpaces, or whether I would have to do all the lookups by id: Category category = space.get(...); Category parent = space.get(category.parentId); for (Id siblingId : parent.subcategoryIds) { Category sibling = space.get(siblingId); System.out.println("sibling " + sibling.name); } Am I being too much of a purist? Can the first example be done in JavaSpace? Are there tools people use to build richer domain models on top of object spaces?
  13. Re: Do we give up OO-design?[ Go to top ]

    Am I being too much of a purist? Can the first example be done in JavaSpace? Are there tools people use to build richer domain models on top of object spaces?
    Introduce a layer of dynamic proxies. Done. Next.
  14. Re: Do we give up OO-design?[ Go to top ]

    Am I being too much of a purist? Can the first example be done in JavaSpace? Are there tools people use to build richer domain models on top of object spaces?

    Introduce a layer of dynamic proxies.
    Are you talking about... wrappers? (Run away, run away!) What I mean: Are your domain objects the same object you store in your Space, or do you have a transformation layer between JavaSpace "DTOs" and domain objects.
  15. Re: Do we give up OO-design?[ Go to top ]

    Are you talking about... wrappers? (Run away, run away!)
    Dude, you've heard me talk about this so many times I think you already know the answer ;-)
    What I mean: Are your domain objects the same object you store in your Space, or do you have a transformation layer between JavaSpace "DTOs" and domain objects.
    Well, why not store them as-is using dynamic proxies for references between objects (yes, wrappers) and do custom serialization of the proxies to a more persistence-friendly format? Or do you see any obvious drawbacks with that approach?
  16. Re: Do we give up OO-design?[ Go to top ]

    Dude, you've heard me talk about this so many times I think you already know the answer ;-)
    Just pulling your leg, Rickard.
    Well, why not store them as-is using dynamic proxies for references between objects (yes, wrappers) and do custom serialization of the proxies to a more persistence-friendly format? Or do you see any obvious drawbacks with that approach?
    If I understand you correctly, this sounds like a good approach. Do I understand you correctly: In the case of Category, would you make Category.parentCategory transient and in the DAO (or whatever it's called in JavaSpaces) set category.parentCategory = proxyFor(category.parentCategoryId)?
  17. Re: Do we give up OO-design?[ Go to top ]

    Well, why not store them as-is using dynamic proxies for references between objects (yes, wrappers) and do custom serialization of the proxies to a more persistence-friendly format? Or do you see any obvious drawbacks with that approach?


    If I understand you correctly, this sounds like a good approach. Do I understand you correctly: In the case of Category, would you make Category.parentCategory transient and in the DAO (or whatever it's called in JavaSpaces) set category.parentCategory = proxyFor(category.parentCategoryId)? Something like that, although I would put the transient in the proxy instead so that the reference in Category is always valid, and then skip the DAO or have the proxy call something like it once invoked. It's the same basic design as EJBObjects really.
  18. Re: Do we give up OO-design?[ Go to top ]

    Something like that, although I would put the transient in the proxy instead so that the reference in Category is always valid, and then skip the DAO or have the proxy call something like it once invoked. It's the same basic design as EJBObjects really.
    Thanks for the answer. I am noticing that I don't think of the possibilities of intelligent proxies nearly enough. Sounds like a neat trick.
  19. Re: Do we give up OO-design?[ Go to top ]

    Am I being too much of a purist? Can the first example be done in JavaSpace? Are there tools people use to build richer domain models on top of object spaces?

    Introduce a layer of dynamic proxies.

    Done.

    Next.
    Can't we include a custom classloader hierarchy, some JNI, and a bunch of groovy scripts too? Unless I'm missing sarcasm, blindly suggesting dynamic proxies as a simple answer to a problem seems pretty dangerous. I mean, what could be better than a dynamic proxy layer? How about four dynamic proxy layers! You wouldn't even need a bytecode obfuscator.
  20. AOP[ Go to top ]

    I'm working with the product right now, and we have this exact issue. I am wondering if Spring/AOP can help in this regard ?
  21. Re: Do we give up OO-design?[ Go to top ]

    Can't we include a custom classloader hierarchy, some JNI, and a bunch of groovy scripts too?

    Unless I'm missing sarcasm, blindly suggesting dynamic proxies as a simple answer to a problem seems pretty dangerous. I mean, what could be better than a dynamic proxy layer? How about four dynamic proxy layers!

    You wouldn't even need a bytecode obfuscator.
    Did I suggest dynamic proxies "blindly"? No, I did so based on my experience with such solutions for the past five years. As a rule of thumb that basic approach will get you a long way when dealing with these kinds of problems, if nothing else it will get you thinking in the right direction. Of course, once you are feeling fine with such a solution the next step would be to do the same using for example AOP, which is in fact what we are doing currently. Works like a charm. And if you need four layers, then by all means have four layers. For the problem described it would seem one would suffice. If you need a bytecode obfuscator, then by all means use a bytecode obfuscator. For the problem described it would seem that none is necessary. But the devil is always in the details, so who knows.
  22. Re: Do we give up OO-design?[ Go to top ]

    Johannes. Lazy loading with JavaSpaces/GigaSpaces can be achieved in a couple of ways depending on whether you want to use the standard JavaSpaces interfaces or the enhanced GigaSpaces API. The standard way uses MatchSets (http://java.sun.com/products/jini/2.1/doc/api/net/jini/space/MatchSet.html) and the http://java.sun.com/products/jini/2.1/doc/api/net/jini/space/JavaSpace05.html#contents(java.util.Collection,%20net.jini.core.transaction.Transaction,%20long,%20long) method. This allows you to iterate through a potentially large data set pulling in objects in batches. GigaSpaces has some extensions to the spec to help with performance and caching/eviction, etc. The API is based around iterators. Coming from a background of high performance low-latency distributed applications using various technologies including J2EE I have got to say that we find the JavaSpaces architecture and API incredibly powerful and have deployed several systems with it for customers. I am not an employee of GigaSpaces but we have got to know them well over the last 18 months. I guess like all technologies it depends on the where your technology background lies and the types of problems you are trying to solve. For scalable high performance resilient applications its excellent.
  23. The simplest way to solve the parent-child problem with GigaSpaces is to use the Spring declarative Cache integration added to GigaSpaces 5.1 - https://springmodules.dev.java.net/docs/reference/0.6/html/cache.html#d0e449. This allows you to inject space operation implicitly into your existing business logic leaving the POJO domain classes intact. See fully running example at: http://www.gigaspaces.com/JForum/posts/list/139.page This example illustrates different ways to inject space operations into your existing business logic. Advanced implementations can use the Space UID based operations. The subcategories (child collection) field should include the UID of the relevant space entries. You can get all subcategories in one chunk or iterating these using sliding window approach (get these in batches into the client). This solves the huge subcategories problem using lazy loading approach. If you just need to read large set of entries from the space as John Nichol suggested you may use the MatchSet that is the GSIterator. When writing the subcategories you should write these as space entries and set their UID based on some unique object field value or let the space to generate the entry UIDs for you. You may write a batch of entries into the space in one call. You can use classes implementing the Entry interface or POJOs using annotations or xml config file for decorations. Implementing the above can be done using GigaSpaces Spring Declarative Cache integration (you may access the underlying space proxy stored as part of the CacheProviderFacade - see the GigaSpacesFacade implementation), using plain AOP , using Externalizable or manually as part of the business logic itself – pick the option that fits your exact needs. In terms of persistency we provide ability to persist the space entries to RDBMS using a built-in database schema , using Hibernate ORM for existing database schema or custom mapping using Write/Read Through interfaces. Access to the database is done in sync or reliable async modes. UID operations are available for .Net and C++ users so you may have the lazy loading approach implemented also in this case. More details on the above can be found ay GigaSpaces on-line wiki doc http://www.gigaspaces.com/wiki/display/GS/JavaSpaces http://www.gigaspaces.com/wiki/display/GS/JavaSpaces+UID+Support http://www.gigaspaces.com/wiki/display/GS/JavaSpaces+Iterator Best Regards, ---------------------------------------------------- Shay Hassidim VP Product Management, GigaSpaces Technologies shay@gigaSpaces.com
  24. Gigaspaces vs Coherence[ Go to top ]

    How does JavaSpaces (or GigaSpaces) compare to Coherence? Why would I choose one over the other?
  25. Re: Gigaspaces vs Coherence[ Go to top ]

    How does JavaSpaces (or GigaSpaces) compare to Coherence? Why would I choose one over the other?
    (Honestly not trying to be offensive at all for once .. ;-) Coherence is focused on providing a stable "single system image" of live application data across any number of servers, with the responsibility for managing that data done in a highly reliable, resilient manner. We have been very successful in defining and growing the in-memory clustered data management / distributed caching / data grid space, and have a seemingly limitless supply of feature requests just to address this space, so we choose to focus solely on it. JavaSpaces (as an API) is ideal for "master/worker" style processing. Gigaspaces (the company's implementation of JavaSpaces) added a lot of other features, including some similar to the areas that we (Tangosol) focus on, and some that we do not focus on at all. However, the architectures are fundamentally different, and you can fairly quickly determine that attempting to make one product do what the other is good at is an uncomfortable proposition. John Davies tends to explain it as scalable processing management (JINI / JavaSpaces) versus scalable / reliable state management (Coherence), and perhaps over time we will see examples of companies using these two products together. (John, who is a long-time JINI / Javaspaces proponent, certainly wants to ;-) I also have some strong (and not uncontroversial, as Dan Creswell can attest) opinions on the conceptual model behind JINI and JavaSpaces, but that's quite a different conversation. See: http://jroller.com/page/cpurdy?entry=distributed_systems_as_organisms I should add that despite the competitive nature of the market, all the various companies in this space are contributing to a major change in the way that companies are thinking about the topics of scalability, infrastructure management, etc. It's a big market, and it's growing much faster than any of the companies in the space, and the technology is definitely going "main stream". Check this out, for example: Tangosol, Atlassian Increase Reliability of Enterprise Wikis. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  26. Re: Gigaspaces vs Coherence[ Go to top ]

    How does JavaSpaces (or GigaSpaces) compare to Coherence? Why would I choose one over the other?
    I don't tend to comment about other products for the simple reason I don't feel I know them enough to speak about what they can or can't do. In any case – our space (no pun intended) is moving so fast, that whatever I say now, will already be outdated. I just want to highlight what I believe is the conceptual differences between the GigaSpaces and Coherence approaches. We both focus on the scaling of distributed stateful applications. The word stateful is key since you can't address this goal without first solving the data-bottleneck – in this we are similar. However – where we differ is that, in our opinion, addressing the data-bottleneck is a necessary, but insufficient step in achieving true linear scalability. To meet the linear scalability challenge we need to apply the same things we did for solving the data bottleneck – but to the entire application stack i.e. virtualize it, makes it efficient through better utilization of memory resources, scale it out dynamically etc. In order to make it simple we set the goal to make the entire distributed application (Middleware and Business logic), behave and look as ONE. This means that from the developer’s view writing a highly distributed application is the same as writing to a single server. Adding more of the application instances would have no impact on the code itself. Our Spring support makes it a seamless transition if you’re already writing with Spring. From a deployment perspective - using our SLA driven virtual container - deploying the application to a dynamic pool of machines is similar to deploying it to a single server running on a single machine. Client applications are able to view the entire cluster as if it was a single server. They can invoke methods through Remoting interface and they would be routed to the appropriate instance (even if it moved to a different location or simply failed). They could run queries against the entire In Memory Data Grid using standard SQL commands even if the data is partitioned in a distributed pool of machines and so forth. What enables this “dream-come-true” is the combination of the Spaces model, or what we refer to as Space-Based Architecture, and our virtual, SLA-driven container. The Spaces model makes it doable because it was developed for and therefore addresses all the distributed computing issues including messaging, data and parallel processing. See the links in this thread to our extensive Wiki documentation to get a better idea of the theory and our implementation of it. Shana tova Nati S. CTO GigaSpaces Write Once Scale Anywhere