Article: Using JavaSpaces

Home

News: Article: Using JavaSpaces

  1. Article: Using JavaSpaces (87 messages)

    JavaSpaces has been a bit of an unknown technology for a long time. It's one of those technologies that programmers know is out there, but haven't actually used enough to say they understand what it's for or what it can do for them. JavaSpaces is, in very simple terms, a kind of client/server map, a grid in which data lives. This article walks through the creation of a simple computation server, explaining the Spaces model along the way.
    JavaSpaces is, in very simple terms, a kind of client/server map, a grid in which data lives. This map doesn't have a distinct key, using a sort of query-by-example to retrieve data. It also has notification capabilities. In concept, that's really it. If you can wrap your head around the idea that it's a map in which an entry's data determines how that entry is accessed, you've mastered most of JavaSpaces already – the rest is simple implementation. JavaSpaces has a number of uses, especially in massive parallel applications. One example is that of a job producer, e.g. “calculate this” applications where the calculations vary widely in complexity; JavaSpaces allows a high-powered CPU to grab certain computations while letting lower-powered CPUs select others. Also, if more computing power is needed, adding more power is only a matter of running more clients to select tasks from the JavaSpace. Another example is that of queueing updates to a datastore; storing data into a JavaSpace is not only very fast (subject to network throughput, of course, which would also affect direct data storage), but provides easy audit capabilities (through notification events) and also means that the persistence engine's speed can't impact the application. (This is a common requirement for financial applications, where milliseconds count.)

    Threaded Messages (87)

  2. No links?[ Go to top ]

    I am missing the link to the actual article.
  3. Re: No links?[ Go to top ]

    I am missing the link to the actual article.
    Ouch - fair enough. It's been added. (At the time the comment was written, though, the article was the top article on the right-hand sidebar. :)
  4. Re: No links?[ Go to top ]

    Hi Joseph, how can I download the source code to your article? Thanks
  5. A very good summary of the situation re: Java Spaces
    It's one of those technologies that programmers know is out there, but haven't actually used.
    I think part of the problem is What can I use it for?. This article is one of the first practical examples of what can be done. On the other hand , other technologies that could solve the problem (e.g. Messaging) have evolved and have greater mainstream 'mind share'. Paul , Technology in Plain English
  6. A very good summary of the situation re: Java Spaces


    It's one of those technologies that programmers know is out there, but haven't actually used.


    I think part of the problem is What can I use it for?. This article is one of the first practical examples of what can be done.

    On the other hand , other technologies that could solve the problem (e.g. Messaging) have evolved and have greater mainstream 'mind share'.


    Paul , Technology in Plain English
    I think you can treat it as advanced job router. Normally you can use JMS to execute your jobs but to optimize the CPU power, you simply have to go for cluster. With JavaSpace, companies can utilize many old machines to make it as a CPU-grid. For example, if you need to execute a large amount of data during night using 5 hours with 8x 4U 16 cores servers, now you can use all company desktops to help run probably under one hour for all jobs. Of course, you might not be able to split one job into pieces to run on different machines, this would be very helpful still because there are many non-critical jobs that run probably an hour now can offload to many other machines. It is also like client/server graphics rendering.
  7. Javaspaces[ Go to top ]

    This article is one of the first practical examples of what can be done.

    On the other hand , other technologies that could solve the problem (e.g. Messaging) have evolved and have greater mainstream 'mind share'.
    OK. I guess so. If you think of Javaspaces as a way to register interest in a certain message queue, with the ability to select specific messages for processing from the queue based on some criteria, and give that processing the ability to alter the messages (instead of just removing the messages and processing them), then you're pretty much there. There are [arguably] some weaknesses in the APIs. The public fields thing was mentioned. The selection criteria is similar to the public fields thing. The "message queue" isn't necessarily a queue (it's a bag, which Javaspaces calls a space). OTOH, I can see places to use it e.g. within our own Coherence software. Like anything else, the key is to use the APIs for what they are good for, and not push them out to all areas as a panacea. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  8. JavaSpaces vs. Event Driven[ Go to top ]

    I have been looking at JavaSpaces a bit lately (last 2 months) and am fairly enamored with it. Here is a comparison of JavaSpaces and some lessons learned from a Message-Centric Event Driven system: http://fuzzypanic.blogspot.com/2006/12/sba-eda-lessons-learned.html Of course it is not a cure all, but it solves a lot of the problems I encountered with excessive mapping issues etc. that come with many EDA/SOA implementations. Between JavaSpaces and distributed caching (e.g. Tangosol), the distributed computing world is finally fundamentally changing and it is starting to go mainstream - yay finally.
  9. Re: JavaSpaces vs. Event Driven[ Go to top ]

    Between JavaSpaces and distributed caching (e.g. Tangosol), the distributed computing world is finally fundamentally changing and it is starting to go mainstream - yay finally.
    The only thing that I would add is that we have encountered very few obstacles to market adoption. I would argue that scale-out architectures (e.g. our Coherence software) have been mainstream now for a couple years. We already have thousands of deployments, including in almost every major bank and telco. The stuff that is "just starting to go mainstream" ... well, that is what you'll see us opening up _this_ year ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  10. Re: JavaSpaces vs. Event Driven[ Go to top ]

    I have been looking at JavaSpaces a bit lately (last 2 months) and am fairly enamored with it.

    Here is a comparison of JavaSpaces and some lessons learned from a Message-Centric Event Driven system:

    http://fuzzypanic.blogspot.com/2006/12/sba-eda-lessons-learned.html

    Of course it is not a cure all, but it solves a lot of the problems I encountered with excessive mapping issues etc. that come with many EDA/SOA implementations.

    Between JavaSpaces and distributed caching (e.g. Tangosol), the distributed computing world is finally fundamentally changing and it is starting to go mainstream - yay finally.
    I looked at this and what confuses me is that a lot of the problems have to do with XML. It seems to imply that messaging (JMS or otherwise) requires XML which isn't the case.
  11. XML and State[ Go to top ]

    Hi James, You are correct. The problems I discussed have to do with excessive mapping (XML) and the difference between the various flavors of transient state and long lived storage. Some of these were just mistakes, but I think that some of them are fundamental to the XML SOA/ESB architectural style. Some things that I thought were insane 2 years ago like JMSObject message seem completely sane to me today if you are using JMS. I by no means think that JavaSpaces are for everyone, I'm just saying that after spending the last 5 years working on ESB/SOA based systems that JavaSpaces and or distributed caching bring some compelling simplicity to the table. Another thing that I will not is that what I am talking about is large systems not an SOA integration strategy. I like components/services and I think there are various flavors of them. Within a large system that uses services you need service orchestration. An ESB is not necessarily the best approach for this - it might be a good approach for your SOA strategy where XML might make sense. What I want is technology that gives me good service orchestration capabilities, but avoids mapping. This can be accomplished many ways - JMSObject messages and JavaSpaces are two ways.
  12. Re: XML and State[ Go to top ]

    Hi James,

    You are correct. The problems I discussed have to do with excessive mapping (XML) and the difference between the various flavors of transient state and long lived storage. Some of these were just mistakes, but I think that some of them are fundamental to the XML SOA/ESB architectural style.

    Some things that I thought were insane 2 years ago like JMSObject message seem completely sane to me today if you are using JMS.

    I by no means think that JavaSpaces are for everyone, I'm just saying that after spending the last 5 years working on ESB/SOA based systems that JavaSpaces and or distributed caching bring some compelling simplicity to the table.
    I'm just trying to determine what, if any, value JavaSpaces has vs. messaging, which is what I am working with now. I'm seeing a lot of comparisons which is what piqued my interest. I'm not using XML right now nor any sort of document -> JavaBean approach so I guess I was looking more for things specific to messaging alone. I'm pretty comfortable with the messaging paradigm and I guess I'm trying to understand if JavaSpaces solves the same problems and has similar capabilities but more what is different between the two paradigms. Is JavaSpaces an implementation of a general concept as messaging is? Is so, what is the general concept called?
  13. JavaSpaces vs. Messaging[ Go to top ]

    Hi James, Well for one, there are no destinations in JavaSpaces so you don't have to map your domain model / conversational state to things like hierarchical topics. For example: FOO.BAR.QUOTE.VALIDATE.SUCCESS or FOO.BAR.QUOTE.VALIDATE.FAILURE In a large systems you will have hundreds if not thousands of topics. You have to keep track of what follows which route, secure them, etc. This type of information is instead included in your objects themselves with JavaSpace Entry interface implementations. You can set up workflows just by changing the state of an object. When you do this, there is another worker configured to take the object and do the next step and so on. This is the Master/Worker pattern which is similar, yet more flexible than pub/sub workflows. Also, messaging is clearly for reliable message delivery. You have things like queues and durable subscriptions. Messaging itself is reliable, but you don't store state in it explicitly. A JavaSpace, on the other hand can be used to store state (e.g., conversational state, long lived transaction state etc.). A JavaSpace can be configured to be reliable (i.e., survive a crash). IMHO this is nice because you don't have to store this type of stuff in a database (more mapping). JavaSpaces in short is extremely malleable. It is appealing because it is just objects. So basically if you understand messaging well, you will quickly understand JavaSpaces. One thing that surprised me about JavaSpaces is the eventing model - an event doesn't push the value to you it just tells you that the type of object you are looking for has arrived to the space. You have to go read or take it if you want the value. GigaSpaces apparently allows you to override this behavior and Jini comes with a more messaging-centric event mechanism. In my estimation, JavaSpaces is messaging plus a lot more. I still thing messaging is great though and don't think that JavaSpaces replaces it.
  14. Re: JavaSpaces vs. Messaging[ Go to top ]

    Hi James,

    Well for one, there are no destinations in JavaSpaces so you don't have to map your domain model / conversational state to things like hierarchical topics. For example:
    FOO.BAR.QUOTE.VALIDATE.SUCCESS or
    FOO.BAR.QUOTE.VALIDATE.FAILURE
    I've never really needed topics for transactional work. A distributed queue allows any ready CPU to process the next message in isolation which is what we've always needed. Of course, now that I write this I just realized that I might have a good use for topics. Also, in JMS at least, you can set properties on the messages and filter a listener to only receive those that match your selection criteria. Is the difference here that JavaSpaces lets you filter on any data element in the Object and not just things you explicitly set as properties? What I mean is in JMS I generally wouldn't use a .success and a .failure queue, I would use one and set a success property on the item (normally.)
    ...A JavaSpace, on the other hand can be used to store state (e.g., conversational state, long lived transaction state etc.). A JavaSpace can be configured to be reliable (i.e., survive a crash). IMHO this is nice because you don't have to store this type of stuff in a database (more mapping)...
    So you don't need any database at all with JavaSpaces? It guarantees persistent storage? That's provocative. Unfortunately, our environment is very database centric and that's not going to be changing anytime soon. I also tend to avoid mapping. I agree that mapping can be painful (I've been through a JAXB generated nightmare) and avoid it by not using JavaBeans and using interfaces that allow me to represent data dynamically (eliminates code generation, other extraneous stuff that's considered 'normal' in Java these days). Perhaps there's a place where this might fit in but only very specific scenarios would allow for it. This persistent stuff sounds like Cameron's baby. How does Coherence relate to this. I see parallels but it's clear from the posts here that there's some distinction that I'm missing. Can Coherence be used to support this mechanism? Does that make sense?
  15. JavaSpaces vs. Database[ Go to top ]

    So you don't need any database at all with JavaSpaces?
    If someone is considering using JavaSpaces instead of a database, then one of two things has probably occurred: 1. They are using (or considering) using a database when a database makes absolutely no sense, or 2. They are considering using JavaSpaces where it makes absolutely no sense. JavaSpaces is an API that allows you to coordinate access (including remote access, e.g. via TCP/IP) to recoverable data managed inside a JVM. A couple points to explain this: 1. JavaSpaces is designed to manage rapid, short-lived state transitions that can be lost without harm to the overall system. In other words, if the state is long-lived, then the data is assumed to exist in a data management system, such as a database, from which it can be recovered. As a result, losing that data (e.g. a space that crashes or a server that dies) is not a problem, even if information in it had not been committed to the database. In general, you would not use JavaSpaces to manage data that you do not want to lose. Note that this does not mean that a JavaSpaces implementation could not be persistent or otherwise durable (providing its own reliable storage), but from a reading of the literature on the topic, and from an analysis of the API, that was never a goal of the API designers, and it is a poor application of the technology. 2. JavaSpaces provides a certain amount of location transparency to access that information. For example, it can be in-process, on the same machine or on a separate machine, all through the same API.
    Unfortunately, our environment is very database centric and that's not going to be changing anytime soon.
    That's OK. You're in the "small minority" composed of roughly 99% of the businesses in the world. ;-)
    I also tend to avoid mapping. I agree that mapping can be painful (I've been through a JAXB generated nightmare) and avoid it by not using JavaBeans and using interfaces that allow me to represent data dynamically (eliminates code generation, other extraneous stuff that's considered 'normal' in Java these days).
    I think it really depends on the application. If you are referring to mapping database information and/or messaging schemas (e.g. XML) into objects, then the mapping can be quite valuable if it sufficiently reduces the "surface area" of the underlying system (XML documents, relational schema) to an OO schema, does so at a reasonable performance and implementation cost, and is used (and re-used) a sufficient number of times to warrant that investment. Applications that use that OO schema in thousands of places will benefit from mapping. If it's only used a few times, then it may be easier to skip the mapping altogether. If it's only used once, then the mapping is (in almost all cases) overkill.
    This persistent stuff sounds like Cameron's baby. How does Coherence relate to this. I see parallels but it's clear from the posts here that there's some distinction that I'm missing. Can Coherence be used to support this mechanism? Does that make sense?
    No, no .. we do not replace the database for persistence. What we do is allow those mapped objects from the database to be kept in memory, shared transactionally across all the servers that need them. Basically, the objects that are managed by Coherence are the "live data" of the application, and may be even more up-to-date than the information in the database (at least in applications that have high rates of data change). In those cases, Coherence will "write behind" the data changes, asynchronously updating the database(s) to catch them up to the state of the system. We can do this safely because Coherence doesn't lose any data or any transactions when a server dies. As a result, Coherence can handle phenomenal rates of data changes, even hundreds of thousands of micro transactions per second. (In a large scale data grid, we can easily scale into the millions of µTPS, but we don't have any customers in production today that need transaction rates that high.) Since these transactions are "cluster durable", the loss of a server has no impact on application availability, or the correctness of the data. Our reason for considering the introduction of JavaSpaces into Coherence is to allow programmers to use the spaces model and the JavaSpaces API to code parts of those transactions. While JavaSpaces is not an effective data management API (i.e. it's not good for replacing a database), it is an effective data processing API (i.e. it can easily be used for computational processing in a grid). So Coherence can certainly bring those two concepts together (data managed by a database and processed using a spaces approach). Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  16. Re: JavaSpaces vs. Database[ Go to top ]

    Cameron et-al As you know many of the arguments that you make about JavaSpaces can be easily applied to HashMap based implementations or any other type of implementation for that matter. Those who are really familiar with Spaces, know that Spaces are a model more then just an API. Spaces can be implemented in a variety of ways that provide different degrees of reliability, integration with data bases etc. For the sake of this discussion let me clarify few things: "In general, you would not use JavaSpaces to manage data that you do not want to lose. " For a start i would recommend to the readers of this post to look at the following blog posts: Will the use of the In Memory Data Grid (IMDG) replace the use of Databases? Persistency and the reliability myth As with HashMap based implementations, the answer is - it depends on the implementation. A good implementation of JavaSpaces can be used to build highly mission-critical systems that were traditionally built on databases just for the sake of reliability. This means that in order to ensure data is not lost, we persist every transaction to the database and pay the price in performance as a result. I argue that persistency can be achieved with a pure memory cluster. The fact that the same data can reside in more then one memory instance and can recovered at any time is basically a new form of "persistency" that is much more aligned with high performance applications. As I mentioned in the above link there are scenarios, such as "hot fail-over", where this form of persistency will provide even a higher degree of reliability then DataBases. In this world a Space would normally hold the in-flight transactions and not necessarily the long lived transactions. This is why it makes perfect sense to combine the two technologies together. Use the space as the means to handle the high performance transactions and the database as the persistent store that will enable reporting systems and other parts of the application to continue and use that data at later stages. For that purpose we at GigaSpaces invested a lot in our database integration layer which supports the following options: Blackbox persistencey - a space can be made durable through variety of underlying persistent storage such as RDBMS, ODBMS. Integration with External Data Sources - This enables you to synchronize the space with external data sources. The space would load the data from an external database into memory when the data is required and update it back to the persistent store upon update. You can choose whether this update will be synchronous or asynchronous. Using a mirror-service you can even delegate all the operations related to the database to an external server, and not overburden the Spaces. You can find more details about that on our online-doc Unfortunatly - it is beyond the scope of this post to cover all the details of these options. The bottom line is that unlike HashMap, the JavaSpaces model was designed primarily to support transaction semantics, query semantics, and deal with partial failure semantics. With the HashMap semantics you have to use proprietary extensions just to deliver these basic requirements. But the *really* nice thing about the JavaSpaces model is that it can be used to deliver functionality even beyond pure data management. You can use the same space API to parallelize your business logic, coordinate workflow and handle complex message distribution. These were the primary reasons that led GigaSpaces to choose the JavaSpaces model as the underlying semantics of our product, and to enable developers to leverage its power through variety of additional APIs - such as APIs for data management (JDBC, SQL), messaging(JMS) and even the limited HashMap model. The strength of the Spaces model is in bringing together under one concept what most developers see as different paradigms such as messaging, data caching and parallel processing. As a consequence, everyone has his own view on what Javaspaces is, and where it fits best. I represent a view that believes it is a best fit when one requires exactly this intersection of paradigms. What we refer to as Space-Based Architecture. With what we have seen in the marketplace at GigaSpaces, This view has already proven itself in mission-critical deployments, and is certainly gaining momentum. I would encourage all of us to keep an open mind and judge for yourselves without relying too much on what people, especially vendors (and I'm including myself in this category), are saying in this space (no pun intended). Nati S. GigaSpaces Write Once Scale Anywhere
  17. Re: JavaSpaces vs. Database[ Go to top ]

    1. JavaSpaces is designed to manage rapid, short-lived state transitions that can be lost without harm to the overall system.
    Cameron, can you prove this? Which spec or documentation says that?
    In general, you would not use JavaSpaces to manage data that you do not want to lose.
    I know companies (including financials) using JavaSpaces to manage data that they don't want to lose and in the spec there is nothing against that. I think your statement is misleading. JavaSpace API is just very simple write/read/take interface that its implementation might support in-memory, persistent or hybrid, or even 'cluster durable' just like implementation of a Map or Queue might be. You might say 'you would not use JavaSpaces to manage data that is in your database', even this one is questionable. if JavaSpaces implementation supports you can definetely use JavaSpaces to manage data that you don't want to lose.
  18. Re: JavaSpaces vs. Database[ Go to top ]

    Talip may be right, but I should point additionally that, although JavaSpaces may be persisted and there is no imminent loss of data, it is not a data storing (long term) or data processing tool. That is not the idea. William Martinez Pomares
  19. Re: JavaSpaces vs. Database[ Go to top ]

    Talip may be right, but I should point additionally that, although JavaSpaces may be persisted and there is no imminent loss of data, it is not a data storing (long term) or data processing tool. That is not the idea.

    William Martinez Pomares
    Yeah, we have databases for long term storing data in relational, object, xml friendly formats and I am sure people are effectively using them for that purpose.
  20. Re: JavaSpaces vs. Database[ Go to top ]

    1. JavaSpaces is designed to manage rapid, short-lived state transitions that can be lost without harm to the overall system.

    Cameron, can you prove this? Which spec or documentation says that?
    I did not realize that this was a topic of any controversy. A two-second Google search turned up a slew of examples, such as:
    Linda is a high level paradigm for expressing parallel computation that provides an abstraction of communication, coordination and task creation through use of a globally accessible object level store. Linda is not a language, but consists of a number of parallel operators that are used to augment an existing sequential language.
    Javaspaces is one of several Java mappings of the LINDA language extensions. I have spent a lot of hours over the past ten years reading Gelernter, papers on LINDA and papers by various JINI/Javaspaces developers, etc. The LINDA language extensions were designed to support parallelism for SMP systems, not as a means to create a database or any other form of durable storage.
    I know companies (including financials) using JavaSpaces to manage data that they don't want to lose and in the spec there is nothing against that.
    I did not attempt to suggest otherwise. I do suggest using the best tool for the job. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  21. Re: JavaSpaces vs. Database[ Go to top ]

    The LINDA language extensions were designed to support parallelism for SMP systems, not as a means to create a database or any other form of durable storage.
    Hi Cameron et al, I've been reading the Linda paper too. And it is true that the inspiration behind Linda was inter-process communication. The differentation of the spaces approach is that it allows communication to be seperated in both space (distributed) and time (temporary storage): http://cocasoft.cs.tamu.edu/~lidu/courses/mccp02s/papers/GenerativeCommLinda-gelernter85toplas.pdf In the paper he goes one to say that at that time (1985) no solid implementation existed, but that the language semantics and concepts were interesting in themselves. The discussion here seems to have focused on what is percieved as a suitable temporary storage time for a space. I accept that long term storage was not the focus of the original paper, but it seems to me that how good the space is at storing data, short or long term, is an implementation issue, not a conceptual one. Implementations therefore are free to focus on whatever aspects of the concept they deem useful. I guess my view is that these are just ideas, and as Nati as rightly said, we should all keep and open mind. It says as much in the paper:
    The Linda design ecompases a model of computation with implications beyond distribution and communication as such. In this paper we are concered however, with communication exclusively... A final point: We attempt in the following to place Linda in context by comparing it to other distributed languages, as noted. But there are a very large number of designs that are relevant to this work in one way or another, and not all can be discussed here...
    Paul.
  22. Re: JavaSpaces vs. Database[ Go to top ]

    A two-second Google search turned up a slew of examples, such as:

    Javaspaces is one of several Java mappings of the LINDA language extensions. I have spent a lot of hours over the past ten years reading Gelernter, papers on LINDA and papers by various JINI/Javaspaces developers, etc.

    The LINDA language extensions were designed to support parallelism for SMP systems, not as a means to create a database or any other form of durable storage.
    These are all ok, and you don't even have to spent a lot of hours over the past ten years to say this; a two-second Google search will be enough, as you did. The concept is not that complicated. But I don't think this can be an answer to your statement that I asked prof for. Here is what you said:
    1. JavaSpaces is designed to manage rapid, short-lived state transitions that can be lost without harm to the overall system.
    I agree with the part that says 'JavaSpaces is designed to manage rapid, short-lived state transitions'. I had a chance to meet Ken Arnold (the JavaSpaces spec guy) at one of the Jini Community meetings and said. 'You can store things in JavaSpaces but it is not a database, you can pass messages among applications but it is not a MessageQueue, you might twick to use it as a cache but it is not a Cache. what was the real intention when designed?', Ken's answer was very similar to what Dan said:
    What JavaSpaces are really good at is the kind of transient information exchange Cameron refers to e.g. messages, protocols, master/worker, MapReduce and other similar patterns. The results of such information exchanges are typically stored elsewhere than the space ultimately.
    Ken also added: 'if you need database go use database, JavaSpaces is not a database, neither a cache'. So that part is just fine to me. But the rest of your statement ['that can be lost without harm to the overall system' part] needs to be explained. there is no controversy, you just need to explain or show me a document, that is all. It could very well be a misunderstanding.
  23. Re: JavaSpaces vs. Database[ Go to top ]

    [..] the rest of your statement ['that can be lost without harm to the overall system' part] needs to be explained.
    Sure. Tuple spaces were meant to be thread-safe general-purpose registers for high speed parallel computations. If a program crashed while computing, those registers could go with it, because the program could always be re-run from the original inputs or from the most recent check point. That is the concept of recoverable computing. What Gelerter envisioned was a relatively small trade-off of theoretical peak efficiency in order to provide a programming model capable of scaling effectively on an SMP (and subsequently distributed) architecture by introducing a simple coordination metaphor. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  24. Hmmmmm[ Go to top ]

    There must be something to TupleSpaces - apparently enough for the Unabomber to try to kill David Gelernter. http://en.wikipedia.org/wiki/Drawing_Life:_Surviving_the_Unabomber ;) I guess that isn't that funny. Joking asside, more than a few people from a traditional distributed computing background have become enamored with TupleSpaces since its inception. There is obviously something there. With Tangosol, it is a great distributed cache, but I still have service orchestration to deal with so (for me) this leaves JavaSpaces or JMS + perhaps Tangosol. What is really missing from JavaSpaces and distributed caching (ala Tangosol) IMHO is a cohesive description of how to use caching, messaging, JavaSpaces, Relational Databases in an architecture appropriately. Both products are superbly documented in Confulence, but neither shows you how it all fits together. There need to be some "in practice" books on this topic. I don't think Nati, Cameron, or Dan would disagree with this. After spending some time looking into this area, I remain attracted to both distributed caching and JavaSpaces, but when you get into the details it isn't that clear how to put it all together into the most cohesive architecture. I am coming to this technology from a heavy SOA/ESB background and 2 specific pain points (i.e., tremendously high defect rate) were excessive mapping (Object -> XML, XML -> Object, XML shredding, Object to Relational) and the clear separation of the various types of active state/transient state and steady state/long-lived storage. If this model doesn't help with that, then I'm better off with the devil that I know. Perhaps I'm naive, but I don't see why a JavaSpace or perhaps a combination of a JavaSpace and a distributed cache can't be the one and only persistence state for all active state/transient state including long-lived transactions (e.g., 5 days waiting for some third party to reply to a request). All you are really doing with a persistent JavaSpace is persisting Entry classes to some form of reliable storage (reliable file system, a database, etc.). This certainly is as reliable as any relational database sans the mapping from your object model to a relational store. This is appealing to me because if I can do it this way I don't have to map from my object model to some relational representation of the long lived transaction (and my defect rate should go down). Do I have this wrong? Thanks!
  25. Re: Hmmmmm[ Go to top ]

    Perhaps I'm naive, but I don't see why a JavaSpace or perhaps a combination of a JavaSpace and a distributed cache can't be the one and only persistence state for all active state/transient state including long-lived transactions (e.g., 5 days waiting for some third party to reply to a request). All you are really doing with a persistent JavaSpace is persisting Entry classes to some form of reliable storage (reliable file system, a database, etc.). This certainly is as reliable as any relational database sans the mapping from your object model to a relational store. This is appealing to me because if I can do it this way I don't have to map from my object model to some relational representation of the long lived transaction (and my defect rate should go down). Do I have this wrong?
    This is my question too. The Croquet "Teatime" architecture is very similar to what you describe here. So what Croquet calls a "Worldbase", is in effect one large universal and durable object space. http://en.wikipedia.org/wiki/Croquet_project#TeaTime I'm no so hung up on "labels", my main interest is utility. Perhaps we should be using a new name (like "Teatime"), for such Architectures - but to me they seem related to/an extension of the "tuple space" idea. BTW. Here is a link to the paper that fully describes the Croquet architecure for those with the time and inclination: http://www.opencroquet.org/Site%20PDFs/2004%20Design%20for%20MUVLE.pdf Paul.
  26. Re: Hmmmmm[ Go to top ]

    Perhaps I'm naive, but I don't see why a JavaSpace or perhaps a combination of a JavaSpace and a distributed cache can't be the one and only persistence state for all active state/transient state including long-lived transactions (e.g., 5 days waiting for some third party to reply to a request). All you are really doing with a persistent JavaSpace is persisting Entry classes to some form of reliable storage (reliable file system, a database, etc.). This certainly is as reliable as any relational database sans the mapping from your object model to a relational store. This is appealing to me because if I can do it this way I don't have to map from my object model to some relational representation of the long lived transaction (and my defect rate should go down).

    Do I have this wrong?



    This is my question too. The Croquet "Teatime" architecture is very similar to what you describe here. So what Croquet calls a "Worldbase", is in effect one large universal and durable object space.

    http://en.wikipedia.org/wiki/Croquet_project#TeaTime

    I'm no so hung up on "labels", my main interest is utility. Perhaps we should be using a new name (like "Teatime"), for such Architectures - but to me they seem related to/an extension of the "tuple space" idea.

    BTW. Here is a link to the paper that fully describes the Croquet architecure for those with the time and inclination:

    http://www.opencroquet.org/Site%20PDFs/2004%20Design%20for%20MUVLE.pdf

    Paul.
    Thinking about it, Teatime itself has more to do with synchronising replicated client spaces to create a shared virtual space. It is the "world base" that is akin to a universal, durable tuple space. If you are interested in how the "world base" works, read the pdf paper. Paul.
  27. Re: Hmmmmm[ Go to top ]

    Hi Mike,
    Perhaps I'm naive, but I don't see why a JavaSpace or perhaps a combination of a JavaSpace and a distributed cache can't be the one and only persistence state for all active state/transient state including long-lived transactions (e.g., 5 days waiting for some third party to reply to a request). All you are really doing with a persistent JavaSpace is persisting Entry classes to some form of reliable storage (reliable file system, a database, etc.). This certainly is as reliable as any relational database sans the mapping from your object model to a relational store. This is appealing to me because if I can do it this way I don't have to map from my object model to some relational representation of the long lived transaction (and my defect rate should go down).

    Do I have this wrong?

    Thanks!
    No contention with the statement just a finesse: There may be a need in such systems for certain kinds of complex query that are best handled by a conventional database. It's probably a subset of the entire dataset rather than all of it...... In essence we're getting back to an earlier part of the discussion: "Use the right tool for the right (part of the) job"
  28. Re: Hmmmmm[ Go to top ]

    With Tangosol, it is a great distributed cache, but I still have service orchestration to deal with so (for me) this leaves JavaSpaces or JMS + perhaps Tangosol.
    Great question ! What do you use for your service platform ! You could look at Spring, J2EE, mule, or some ESB for that purpose with tangosol. But this adds lot's of layers, and increases latency. You could look at using using GigaSpaces for the whole thing, caching, messaging and service platform. If you talk to the GigaSpaces guys, they will tell you that this is the exact problem they solve.
    Perhaps I'm naive, but I don't see why a JavaSpace or perhaps a combination of a JavaSpace and a distributed cache can't be the one and only persistence state for all active state/transient state including long-lived transactions (e.g., 5 days waiting for some third party to reply to a request).
    Good question ! Here are some possible reasons why people are reluctant to do that : 1) Nervousness about IMDG and the reliability. 2) A need to access this same data by other entites in the company which are not java based (and more than likely stored procedure/trigger based ). 3) In the financial sector, you must keep copies of certain types of End of day data for SEC purposes for many months. Each of these requirement may be better served by a database.
  29. Re: Hmmmmm[ Go to top ]


    With Tangosol, it is a great distributed cache, but I still have service orchestration to deal with so (for me) this leaves JavaSpaces or JMS + perhaps Tangosol.


    Great question ! What do you use for your service platform ! You could look at Spring, J2EE, mule, or some ESB for that purpose with tangosol. But this adds lot's of layers, and increases latency.

    You could look at using using GigaSpaces for the whole thing, caching, messaging and service platform.
    If you talk to the GigaSpaces guys, they will tell you that this is the exact problem they solve.
    And indeed they do but for the sake of balanced perspective, I feel compelled to point out the flip-side which is that by selecting a single product to fulfill all these needs you are betting that: (1) The vendor is the most knowledgeable in all these areas. (2) The vendor can build the best of breed product across all these areas and make it all work together. This "all-in-one" approach has been done before with app servers and to some extent has lead to the backlash that drove the adoption of individual offerings such as Spring, Mule etc. Microsoft have also played this game from time to time and been caught out. Basically we are talking about "Do we buy best of breed and integrate or buy one thing which solves all the integration issues but might not be best of breed?" Note also that the "all-in-one" approach doesn't solve all integration problems ultimately because it's unlikely to ever supply everything you ever need in one box nor is it likely to supply every single adapter you ever need in one box. That said, it may however be good enough.




    Perhaps I'm naive, but I don't see why a JavaSpace or perhaps a combination of a JavaSpace and a distributed cache can't be the one and only persistence state for all active state/transient state including long-lived transactions (e.g., 5 days waiting for some third party to reply to a request).


    Good question ! Here are some possible reasons why people are reluctant to do that :

    1) Nervousness about IMDG and the reliability.

    2) A need to access this same data by other entites in the company which are not java based (and more than likely stored procedure/trigger based ).

    3) In the financial sector, you must keep copies of certain types of End of day data for SEC purposes for many months.

    Each of these requirement may be better served by a database.
  30. Re: Hmmmmm[ Go to top ]

    Dan Creswell wrote:
    “And indeed they do but for the sake of balanced perspective, I feel compelled to point out the flip-side which is that by selecting a single product to fulfill all these needs you are betting that: (1) The vendor is the most knowledgeable in all these areas. (2) The vendor can build the best of breed product across all these areas and make it all work together. This "all-in-one" approach has been done before with app servers and to some extent has lead to the backlash that drove the adoption of individual offerings such as Spring, Mule etc. Microsoft have also played this game from time to time and been caught out. Basically we are talking about "Do we buy best of breed and integrate or buy one thing which solves all the integration issues but might not be best of breed?" Note also that the "all-in-one" approach doesn't solve all integration problems ultimately because it's unlikely to ever supply everything you ever need in one box nor is it likely to supply every single adapter you ever need in one box. That said, it may however be good enough. “
    Dan I think your “best of breed” vs “all in one” view with regards to Jini/JavaSpaces and GigaSpaces specifically is misleading not just with regards to the “all-in-one”, but also with regards to your obvious preference to the “best-of-breed”: a. “all-in-one” - The whole point that we at GigaSpaces are trying to make about JavaSpaces is that the power of this concept is that it allows to implement in one technology the various paradigms we have traditionally associated with different products and APIs, namely messaging, parallel-processing and data-caching (or space-distributed and time-distributed computing respectively as Gelernter’s original Linda paper calls it). Therefore the “all-in-one” that you refer to, is not an integration of different products done by the “know-it-alls” at GigaSpaces. Rather it is in fact a leveraging of a single technology that can facilitate all of these paradigms using one, common runtime that’s based on the Space model. In our minds – looking at JavaSpaces in the very narrow sense that you suggest (not that I’m exactly sure what you’re suggesting is the proper use of it) misses the whole point about the strength of this model and its possible impact on the everyday challenges faced by developers. b. by “best-of-breed” you mean that the onus of achieving similar benefits will fall on architects and developers of applications who will have a better time integrating themselves the different technologies, of the more traditional kind, like ESB+Caching+Container (that’s at a minimum). They will also have to be the ones developing a common high-availability model for these different products, not to mention having to solve the problem of how they will scale-out in conjunction with one another. In short – a recipe for a lot of middleware wiring of the “not-so-pretty” kind that’s left for the developers to figure out. You seem to prefer for the sake of principle (“best-of-breed”) an alternative which is obviously much more challenging and risky for developers while ignoring the very essence of the stuff that makes JavaSpaces so powerful to begin with. We at GigaSpaces do not claim to be a “jack-of-all-trades” (with your obvious “master-of-none” thrown in implicitly). Rather – we claim to have developed a specific implementation that brings out the best benefits inherent in the Spaces model, and how to leverage it to solve everyday distributed computing challenges in an elegant way. Nati S. Write Once Scale Anywhere
  31. Re: Hmmmmm[ Go to top ]

    Hi Nati,
    Dan Creswell wrote:



    “And indeed they do but for the sake of balanced perspective, I feel compelled to point out the flip-side which is that by selecting a single product to fulfill all these needs you are betting that:

    (1) The vendor is the most knowledgeable in all these areas.

    (2) The vendor can build the best of breed product across all these areas and make it all work together.

    This "all-in-one" approach has been done before with app servers and to some extent has lead to the backlash that drove the adoption of individual offerings such as Spring, Mule etc. Microsoft have also played this game from time to time and been caught out.

    Basically we are talking about "Do we buy best of breed and integrate or buy one thing which solves all the integration issues but might not be best of breed?"

    Note also that the "all-in-one" approach doesn't solve all integration problems ultimately because it's unlikely to ever supply everything you ever need in one box nor is it likely to supply every single adapter you ever need in one box. That said, it may however be good enough. “





    Dan

    I think your “best of breed” vs “all in one” view with regards to Jini/JavaSpaces and GigaSpaces specifically is misleading not just with regards to the “all-in-one”, but also with regards to your obvious preference to the “best-of-breed”:

    You can consider it misleading if you wish I wasn't intending it to be read that way I was simply pointing out some counterpoints to the suggested benefits because my real belief is that people should make informed decisions. And because that is a core belief of mine I don't have a bias either way. Rather I use what seems like the right thing at the right time based on analysis of both pluses and minuses. That's it and all about it, no offence intended or implied. You seem to have made a judgement about my intentions rather than asked me straight out to clarify myself and then responded on the basis that all your assumptions about my intentions were correct. In respect of your claims, I'm fully aware of them as I'm sure is everyone else who reads TSS. However, this is a public forum and when you make claims you have to accept you will be questioned and you will have to defend them. Especially if you choose to make statements like:
    ....we claim to have developed a specific implementation that brings out the best benefits inherent in the Spaces model, and how to leverage it to solve everyday distributed computing challenges in an elegant way.
    which is a pretty big claim!
  32. Re: JavaSpaces vs. Database[ Go to top ]

    Hi Talip,
    I had a chance to meet Ken Arnold (the JavaSpaces spec guy) at one of the Jini Community meetings and said. 'You can store things in JavaSpaces but it is not a database, you can pass messages among applications but it is not a MessageQueue, you might twick to use it as a cache but it is not a Cache. what was the real intention when designed?', Ken's answer was very similar to what Dan said:

    What JavaSpaces are really good at is the kind of transient information exchange Cameron refers to e.g. messages, protocols, master/worker, MapReduce and other similar patterns. The results of such information exchanges are typically stored elsewhere than the space ultimately.

    Ken also added: 'if you need database go use database, JavaSpaces is not a database, neither a cache'. So that part is just fine to me.

    But the rest of your statement ['that can be lost without harm to the overall system' part] needs to be explained. there is no controversy, you just need to explain or show me a document, that is all. It could very well be a misunderstanding.
    Here's how I think about this stuff - consider TCP/IP or UDP usage. The network I run these protocols across can lose packets without harm to the overall system (to paraphrase you). Why? Because in the case of TCP/IP the sender's network stack will resend the necessary information. In the case of UDP, the client itself (not the stack) is responsible for resend. Thus the network (or JavaSpace) can afford to lose data because it's regenerated from elsewhere. Why does this work? Because the space is simply a transient holder for state generated elsewhere. In a system where we remove the constraint that clients will do retry (regenerate state) we have to make sure the space doesn't lose messages or have some other entity take on the responsibility for state maintenance. Does that help? Dan.
  33. Re: JavaSpaces vs. Database[ Go to top ]

    Here's how I think about this stuff - consider TCP/IP or UDP usage. The network I run these protocols across can lose packets without harm to the overall system (to paraphrase you). Why? Because in the case of TCP/IP the sender's network stack will resend the necessary information. In the case of UDP, the client itself (not the stack) is responsible for resend. Thus the network (or JavaSpace) can afford to lose data because it's regenerated from elsewhere.

    Why does this work? Because the space is simply a transient holder for state generated elsewhere. In a system where we remove the constraint that clients will do retry (regenerate state) we have to make sure the space doesn't lose messages or have some other entity take on the responsibility for state maintenance.

    Does that help?

    Dan.
    Thanks Dan, the answer shows that you definetely understand my question. I also think that your example is very good to explain your point. I just have couple of things to say about it. Making UDP reliable is based on a contract between the two end which basicly says 'I will send you the packets that you didn't receive and you will tell me (or imply in someway) which packets you didn't receive'. So there has to a contract (protocol) between the client and the space implementation to not worry about the data that is 'lost without harm'. If I am client to a space, and write data to be processed, I should not have to re-send the data in case of a lost. At least there is no such contract defined in the spec as far as I know. So my point is that space implementation should provide (at least) as much durability as its underlying storage (memory, file, db, cluster etc.). there is no design spec/or general use-case that says "use JavaSpaces in a way that your data can get lost without harm to your overall system and/or make sure that your space clients can deal with lost data". This could be one's personal design and use of space concept but I don't think it can be generalized.
  34. Re: JavaSpaces vs. Database[ Go to top ]

    Hi All, Are we talking about Tuple Spaces, JavSpaces, Blitz, GigaSpaces or Tangosol? I'm confused. I thought the discussion was about the Tuple Space Architectural pattern - i.e. not implementation specific. Forgetting the current crop of (Java) implementations, then durablity is an implementation choice. Granted there are use cases that do not require this feature, but equally there will be use cases that do. Here is what the Linda paper has to say about persistence:
    2.7 Time Uncoupling, Tuple Persistence, and File Systems Space-distributed computing is an innovation, and its investigation has barely begun. Time-distributed programming languages in Linda’s sense are likewise unfamiliar, but time-distributed computing itself is nothing new. Communication between time-disjoint programs has long been provided for by file systems. There is also a linguistic model for time-distributed communication in any routine that retains state between time-disjoint invocations-coroutines, generators, procedures with Algol own variables, monitor routines with access to permanent monitor variables, and so on. In Linda, extension of a linguistic model into fully space-distributed computing results in its extension into time-distributed computing as well; the linguistic aegis now covers certain filing functions that are traditionally extra-linguistic. Generative communication logically encompasses a tuple-structured, contentaddressable file system. But the extent to which it is desirable or practical to incorporate filing functions in Linda is not yet clear. At present, we assume that when all processes of a distributed program have completed, whatever tuples generated by that program remain in TS will be deleted, with two exceptions: tuples whose first names are in the system’s name space and tuples whose first names appear on a “save” list specified by the programmer.
    That sounds pretty clear to me. Paul.
  35. Re: JavaSpaces vs. Database[ Go to top ]

    Here's how I think about this stuff - consider TCP/IP or UDP usage. The network I run these protocols across can lose packets without harm to the overall system (to paraphrase you). Why? Because in the case of TCP/IP the sender's network stack will resend the necessary information. In the case of UDP, the client itself (not the stack) is responsible for resend. Thus the network (or JavaSpace) can afford to lose data because it's regenerated from elsewhere.

    Why does this work? Because the space is simply a transient holder for state generated elsewhere. In a system where we remove the constraint that clients will do retry (regenerate state) we have to make sure the space doesn't lose messages or have some other entity take on the responsibility for state maintenance.

    Does that help?

    Dan.


    Thanks Dan, the answer shows that you definetely understand my question. I also think that your example is very good to explain your point. I just have couple of things to say about it.

    Making UDP reliable is based on a contract between the two end which basicly says 'I will send you the packets that you didn't receive and you will tell me (or imply in someway) which packets you didn't receive'.

    So there has to a contract (protocol) between the client and the space implementation to not worry about the data that is 'lost without harm'. If I am client to a space, and write data to be processed, I should not have to re-send the data in case of a lost. At least there is no such contract defined in the spec as far as I know.

    So my point is that space implementation should provide (at least) as much durability as its underlying storage (memory, file, db, cluster etc.).
    You're misunderstanding me - I'm not talking about between client and space I'm talking about between sending client and receiving client. The space, if you will is the internet, simply a (lossy) conduit. So just as when you use UDP across the internet it's up to sender and recipient so it is the same when programming against a space. It's up to client and recipient (writer and taker) to implement this aspect of their protocol (with their protocol being application dependent).
    there is no design spec/or general use-case that says "use JavaSpaces in a way that your data can get lost without harm to your overall system and/or make sure that your space clients can deal with lost data". This could be one's personal design and use of space concept but I don't think it can be generalized.
  36. Re: JavaSpaces vs. Database[ Go to top ]

    I wanted to jump into the discussion since it is kind of related to the topic of an article I'm planning to write. Database is a misleading name. From the early years at university you are someway driven to think of a data-database relation that is natural and as a golden rule, if you have data you ought to have a database, and the standard is relational (other ones are just geek experiments, not for business). The naked truth is data has lots of variables the designer and architect have to take into account to actually choose the method and tools to work with it. Do you want to persist the data (between states)? Do you want to Store the data? Do you want to share the data? Do you want to process the data? Do you want to convert the data? Do you want to "cook" the data? I bet most applications answer affirmatively to several of those questions. But all use the same tool, a database. So, other questions arise: I'm using an OO language, do I need the data as objects? I'm using XML, should I convert XML to a table to store it, and then the table to object to work with it in Java? Mapping, mapping... to bring the problem to a technology I know how to use, not the one that is appropriate to the problem. An example: I see applications that map records from a relational database to a list of objects, one object per record. Then in Java you iterate over the list to perform some calculations. That mapping makes no sense, if those calculations can be done in the database data processor. So, as Cameron correctly points out, first step is actually forget about the data-database union. Second is to evaluate what data is we are talking about, its format (records, XML, objects) an what are we going to do with it and for how long. Third is to determine what do I need (features in a tool) to achieved correctly my tasks. Lastly, choose from the solutions the appropriate technology. You may end up using RDBMS to store record-like data and to process it, generating messages (SOAP?) or documents in XML that are stored and processed in an XDBMS and possibly expanding them with some values calculated in your OO environment using objects, by several agents that share the objects instances using a blackboard pattern. Technology shouldn't drive our designs. The problem space should. William Martinez Pomares.
  37. Re: JavaSpaces vs. Database[ Go to top ]

    If someone is considering using JavaSpaces instead of a database, then one of two things has probably occurred: 1. They are using (or considering) using a database when a database makes absolutely no sense, or 2. They are considering using JavaSpaces where it makes absolutely no sense.
    Indeed - whilst there is crossover in terms of some functionality, the further you exploit one or other technology, the less the other is applicable.
    1. JavaSpaces is designed to manage rapid, short-lived state transitions that can be lost without harm to the overall system. In other words, if the state is long-lived, then the data is assumed to exist in a data management system, such as a database, from which it can be recovered. As a result, losing that data (e.g. a space that crashes or a server that dies) is not a problem, even if information in it had not been committed to the database. In general, you would not use JavaSpaces to manage data that you do not want to lose. Note that this does not mean that a JavaSpaces implementation could not be persistent or otherwise durable (providing its own reliable storage), but from a reading of the literature on the topic, and from an analysis of the API, that was never a goal of the API designers, and it is a poor application of the technology.
    Some bits of clarification may help others here: It's important to realize that Cameron has been reading (and asking me questions about) the JavaSpaces specs (JavaSpace and JavaSpace05) as originated by the Jini community. These specs do not reflect what vendors may have chosen to do in terms of evolving their space implementation further. Whilst it is possible to store data long-term in a JavaSpace, it's a lightweight solution in that the API is not really designed for that but can be bent to the task relatively easily for simple schemas. What JavaSpaces are really good at is the kind of transient information exchange Cameron refers to e.g. messages, protocols, master/worker, MapReduce and other similar patterns. The results of such information exchanges are typically stored elsewhere than the space ultimately. Now, some JavaSpaces are indeed persistent and that can save on recovery of in-progress work but many JavaSpace systems rely on the clients to implement appropriate recovery behaviours such as resends etc.
    2. JavaSpaces provides a certain amount of location transparency to access that information. For example, it can be in-process, on the same machine or on a separate machine, all through the same API.
    Indeed they do, this is a very useful side-effect of the Jini architecture (note, I'm not saying you can't achieve it otherwise, just that Jini makes it natural). Back to Cameron to summarize:
    Our reason for considering the introduction of JavaSpaces into Coherence is to allow programmers to use the spaces model and the JavaSpaces API to code parts of those transactions. While JavaSpaces is not an effective data management API (i.e. it's not good for replacing a database), it is an effective data processing API (i.e. it can easily be used for computational processing in a grid). So Coherence can certainly bring those two concepts together (data managed by a database and processed using a spaces approach).
  38. Re: JavaSpaces vs. Database[ Go to top ]

    Dan I'm happy to see that you and Cameron think the same. I'd like to re-emphasise what i said before about the different views that individuals have about the space model.
    The strength of the Spaces model is in bringing together under one concept what most developers see as different paradigms such as messaging, data caching and parallel processing. As a consequence, everyone has his own view on what Javaspaces is, and where it fits best. I represent a view that believes it is a best fit when one requires exactly this intersection of paradigms. What we refer to as Space-Based Architecture. With what we have seen in the marketplace at GigaSpaces, This view has already proven itself in mission-critical deployments, and is certainly gaining momentum.
    But instead of feeding back hashed (no pun intended) arguments I would encourage the readers to read and judge for themselves. You're welcome to leverage the various links provided in the original article as a starting point for learning how the space model has been successfully applied in it's various manifestations. (e.g. see here ) Have a nice weekend Nati S.
  39. Re: JavaSpaces vs. Database[ Go to top ]

    I'm happy to see that you and Cameron think the same.
    Fortunately, Dan and I disagree on quite a few things related to this topic. Otherwise, it would be pretty boring to talk with him about it. Through our disagreements, I have learned quite a bit. There are things in Javaspaces that I would have otherwise missed. (Ever since that Ken Arnold interview, I have had a hard time just getting past the whole "only public fields allowed" and "no booleans, ints or doubles" issues.)
    The strength of the Spaces model is in bringing together under one concept what most developers see as different paradigms such as messaging, data caching and parallel processing.
    Yes, and the strength of the byte array is that it can be used to represent any data structure. Nonetheless, I'm still planning to use classes occasionally ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  40. Re: JavaSpaces vs. Database[ Go to top ]

    Hi Nati,
    Dan

    I'm happy to see that you and Cameron think the same.
    I'd like to re-emphasise what i said before about the different views that individuals have about the space model.

    To clarify, Cameron and I don't think the same but we have some common ground after sharing beer and a large number of online discussions.

    The strength of the Spaces model is in bringing together under one concept what most developers see as different paradigms such as messaging, data caching and parallel processing. As a consequence, everyone has his own view on what Javaspaces is, and where it fits best.

    I represent a view that believes it is a best fit when one requires exactly this intersection of paradigms. What we refer to as Space-Based Architecture. With what we have seen in the marketplace at GigaSpaces, This view has already proven itself in mission-critical deployments, and is certainly gaining momentum.


    But instead of feeding back hashed (no pun intended) arguments I would encourage the readers to read and judge for themselves. You're welcome to leverage the various links provided in the original article as a starting point for learning how the space model has been successfully applied in it's various manifestations. (e.g. see here )


    Have a nice weekend
    Nati S.
    I am more than happy for you to re-emphasize your view! :) However, I believe that whilst the spaces model can certainly be bent to all of these things, at least in the case of JavaSpaces the targeted area of use was for tasks which could be modelled as flows of objects. This is clearly stated in several areas of the JavaSpaces spec: "JavaSpaces services are tools for building distributed protocols. They are designed to work with applications that can model themselves as flows of objects through one or more servers. If your application can be modeled this way, JavaSpaces technology will provide many benefits." In contrast, I believe stands space-based architecture which is a GigaSpaces invention and indeed is about the intersection of a set of paradigms. You have of course, built this upon the original spaces architecture. And you have indeed had success in the market with your approach and I applaud you for that. Thus I do not see any conflict of views over the spaces model itself given that what you are talking about is one practical application of spaces which has a model of it's own which you call "space-based architecture".
  41. JavaSpaces Theory or Pratice ?[ Go to top ]

    So you don't need any database at all with JavaSpaces?
    James, the space is not a database. Instead you place data into the space that is used as INPUT to space operations. Gigaspaces has implmented a distributed, fault tolerant cache as apart of their product. This allows reliable storage of the data that is placed into the space. This close coupling of the cache, and the Spaces API allows you to implement applications that utilize the cached data as if it were local to the operation even though the data may reside on a remote machine. On the flip side, GigaSpaces also allows you to code Agents that are aware of the location of the data. This means that when the agents (services) execute, they can be forced to execute local to the data. So what does this means IN REAL TERMs. Imagine the following use case. You have large amounts of data to process. You can 1) Load it into the Space ( from the database or directly from your data stream and then persist it into the database ) 2) So, there is the JavaSpaces Spec... and there are JavaSpaces implementations. If you are trying to decide if you want to use JavaSpaces for a production application, I suggest you look at the GigaSpaces implementation and see how it relates to specifc Use Cases. GigaSpaces has features FAR beyond the basic spec. I think if you have a need for developing services that are not well served by the typical J2EE solution ( alot of the Financial Services uses cases are not well served by J2EE model ) you should take a look at GigaSpaces.
  42. Re: JavaSpaces Theory or Pratice ?[ Go to top ]

    So you don't need any database at all with JavaSpaces?


    James, the space is not a database. Instead you place data into the space that is used as INPUT to space operations. Gigaspaces has implmented a distributed, fault tolerant cache as apart of their product. This allows reliable storage of the data that is placed into the space. This close coupling of the cache, and the Spaces API allows you to implement applications that utilize the cached data as if it were local to the operation even though the data may reside on a remote machine. On the flip side, GigaSpaces also allows you to code Agents that are aware of the location of the data. This means that when the agents (services) execute, they can be forced to execute local to the data.

    So what does this means IN REAL TERMs. Imagine the following use case. You have large amounts of data to process. You can

    1) Load it into the Space ( from the database or directly from your data stream and then persist it into the database )

    2)

    So, there is the JavaSpaces Spec... and there are JavaSpaces implementations.
    You are a JavaSpace if you implement the spec, if you implement stuff beyond that you are still a JavaSpace implementation but might not be following JavaSpaces design philosophy necessarily. Why am I making such an "obvious" statement? Because I believe what you say below could be misunderstood. I'd like to make sure we encourage people to create use cases, start on design and _then_ consider appropriate technologies. Note, I'm not saying "don't look at GigaSpaces" rather I'm saying be pragmatic and look before you leap. The fact of the matter is that there are plenty of Jini/JavaSpaces-based solutions out there (including those demanding high-throughput and high-availability) which don't use GigaSpaces at all for various reasons.
    If you are trying to decide if you want to use JavaSpaces for a production application, I suggest you look at the GigaSpaces implementation and see how it relates to specifc Use Cases. GigaSpaces has features FAR beyond the basic spec. I think if you have a need for developing services that are not well served by the typical J2EE solution ( alot of the Financial Services uses cases are not well served by J2EE model ) you should take a look at GigaSpaces.
    Finally, as I'm sure the Gigaspaces team will be reading, I'd like to ask a quick question - have you guys fully implemented JavaSpace05 (for those not aware, this is the spec for bulk operations, an iterator and additional events)? I had a quick scan of your site and all I can see is GSIterator?
  43. Re: JavaSpaces Theory or Pratice ?[ Go to top ]

    Note, I'm not saying "don't look at GigaSpaces" rather I'm saying be pragmatic and look before you leap. The fact of the matter is that there are plenty of Jini/JavaSpaces-based solutions out there (including those demanding high-throughput and high-availability) which don't use GigaSpaces at all for various reasons.
    I agree one hundred percent. The only reason why I mentioned a specific product is that the original messge had the sounds of someone who need to solve a current problem.
  44. All of the Above[ Go to top ]

    I'm looking at all of the above - (Jini + Blitz, GigaSpaces, Tangosol + JMS, + several other things). I certainly don't think that any of these combinations cover all the needs of enterprise integration. You are still going to need traditional messaging or at least REST to connect to different domains (e.g., a billing). This isn't to say that you couldn't just use this stack - you certainly could. Obviously, most large IT environments have years and years of legacy systems that make anything that radical a non-starter anyway. I'm looking at these technologies right now for a large system application architecture - not an enterprise integration layer. After building several large applications based on an ESB style for large systems, I don't think that it is the best choice - certainly better than J2EE, but as I have mentioned, the mapping and state management can be a killer. If I do build another system this way obviously it will go better as I won't let the same mistakes occur. In terms of the discussion around best of breed vs. single-stop-shopping (ala GigaSpaces) I have a range of excitement and fear just like any free thinking / experienced technical person would. I have experienced first hand the complexities of layering middleware. I have also worked with technologies that were promising, but turned out to be too clever. I have the same feelings about Tangosol, albeit, to a lesser extent because it is one layer (for now). In general, these feelings are what make me very pro Open Source when it comes to middleware. Hey this is a great thread - thanks.
  45. Re: All of the Above[ Go to top ]

    I'm looking at all of the above - (Jini + Blitz, GigaSpaces, Tangosol + JMS, + several other things).

    I certainly don't think that any of these combinations cover all the needs of enterprise integration. You are still going to need traditional messaging or at least REST to connect to different domains (e.g., a billing).

    This isn't to say that you couldn't just use this stack - you certainly could. Obviously, most large IT environments have years and years of legacy systems that make anything that radical a non-starter anyway.

    I'm looking at these technologies right now for a large system application architecture - not an enterprise integration layer.

    After building several large applications based on an ESB style for large systems, I don't think that it is the best choice - certainly better than J2EE, but as I have mentioned, the mapping and state management can be a killer. If I do build another system this way obviously it will go better as I won't let the same mistakes occur.

    In terms of the discussion around best of breed vs. single-stop-shopping (ala GigaSpaces) I have a range of excitement and fear just like any free thinking / experienced technical person would. I have experienced first hand the complexities of layering middleware. I have also worked with technologies that were promising, but turned out to be too clever. I have the same feelings about Tangosol, albeit, to a lesser extent because it is one layer (for now). In general, these feelings are what make me very pro Open Source when it comes to middleware.

    Hey this is a great thread - thanks.
    Okay, I'm curious and stumped (and none too smart), can you explain your thinking on how opensource helps with this predicament?
  46. I'm looking at all of the above - (Jini + Blitz, GigaSpaces, Tangosol + JMS, + several other things).

    I certainly don't think that any of these combinations cover all the needs of enterprise integration. You are still going to need traditional messaging or at least REST to connect to different domains (e.g., a billing).

    This isn't to say that you couldn't just use this stack - you certainly could. Obviously, most large IT environments have years and years of legacy systems that make anything that radical a non-starter anyway.

    I'm looking at these technologies right now for a large system application architecture - not an enterprise integration layer.

    After building several large applications based on an ESB style for large systems, I don't think that it is the best choice - certainly better than J2EE, but as I have mentioned, the mapping and state management can be a killer. If I do build another system this way obviously it will go better as I won't let the same mistakes occur.

    In terms of the discussion around best of breed vs. single-stop-shopping (ala GigaSpaces) I have a range of excitement and fear just like any free thinking / experienced technical person would. I have experienced first hand the complexities of layering middleware. I have also worked with technologies that were promising, but turned out to be too clever. I have the same feelings about Tangosol, albeit, to a lesser extent because it is one layer (for now). In general, these feelings are what make me very pro Open Source when it comes to middleware.

    Hey this is a great thread - thanks.


    Okay, I'm curious and stumped (and none too smart), can you explain your thinking on how opensource helps with this predicament? To quote Matt Asay: http://asay.blogspot.com/2007/01/proprietary-software-serves-vendor-not.html
    Let us be clear. Whatever the merits of proprietary software, they are purely vendor-favoring. There is no customer reason to make software proprietary. None. There is no customer benefit that attaches to proprietary software. There is only a vendor's ability to temporarily monopolize a piece of software and thereby profit from it.
    These days I'm a customer. Both Tangosol and GigaSpaces have some compelling technology as does Blitz. I looked at the Blitz source code - I like that. Someday I might contribute to Blitz or fix a defect or help with documentation - I like that I can do that. I like that I could fork Blitz if I wanted to (not that I ever think I will). But the freedom to fork is a great thing. I like that I can pay you support or not based on the value you provide. I like this because it encourages good behavior (not that I think Tangosol or GigaSpaces act badly). I like all things that encourage software companies to compete on business value rather than proprietary vendor lock-in. And this is not to say that I want to be a free loader - I support paying for OSS support and do. Back to GigaSpaces and Tangosol. They both have compelling technology, but both are small vendors. Where will this technology go? Will someone buy it to kill it? Will they buy it to grow it? Will they remain independent? Who knows. If it were open, well it doesn't quite matter. I can happily pay them now and perhaps someone else later - or no one if I can support it myself. Does this mean I won't consider using either? Obviously not, but it is certainly a big downside for me.
  47. Hi Mike
    In terms of the discussion around best of breed vs. single-stop-shopping (ala GigaSpaces)
    One minor correction with GigaSpaces you have the choice to use best of breed or single-stop-shop when appropriate i.e. we give you an option not to be dependent on other products/technologies in the critical path of your application when you don't necessarily need them and gain the benefit out of it. You can always choose not to use that and pay the potential price as a result of that.
    In general, these feelings are what make me very pro Open Source when it comes to middleware
    I'm curious to understand why opensource is considered a "risk-free" alternative or even a smaller risk? Do you think that having the source of multiple millions line of codes would reduce your risk? If the questions is purely risk wouldn't having the source code even of a commercial product as a source-license address the same risk? Comming back to risk - again IMO there are various ways to address risk. OSS could be one on them but at the same time it introduces similar risk especially in cases where the specific project is not backed up properly by a real company. I think that you already know my thoughts on that matter. I personally believe that separation of concerns through the right (Spring) abstraction can be more effective to address the risk issue as it gives you more freedom of choices between one implementation and the other. A combination of OSS and abstractions at the right places can get you very far on that regard. Nati S.
  48. Source license[ Go to top ]

    Hi Mike


    In terms of the discussion around best of breed vs. single-stop-shopping (ala GigaSpaces)


    One minor correction with GigaSpaces you have the choice to use best of breed or single-stop-shop when appropriate i.e. we give you an option not to be dependent on other products/technologies in the critical path of your application when you don't necessarily need them and gain the benefit out of it. You can always choose not to use that and pay the potential price as a result of that.



    In general, these feelings are what make me very pro Open Source when it comes to middleware


    I'm curious to understand why opensource is considered a "risk-free" alternative or even a smaller risk?
    Do you think that having the source of multiple millions line of codes would reduce your risk?

    If the questions is purely risk wouldn't having the source code even of a commercial product as a source-license address the same risk?

    Comming back to risk - again IMO there are various ways to address risk. OSS could be one on them but at the same time it introduces similar risk especially in cases where the specific project is not backed up properly by a real company.

    I think that you already know my thoughts on that matter. I personally believe that separation of concerns through the right (Spring) abstraction can be more effective to address the risk issue as it gives you more freedom of choices between one implementation and the other. A combination of OSS and abstractions at the right places can get you very far on that regard.

    Nati S.
    Hi Nati, Yeah I should have been more clear, sorry. I didn't know that you offered a source-license. I am of the mind that business models around OSS are still emerging. As you know, Confluence (the wiki) gives you the source when you buy it. Now this isn't true OSS obviously (more like shared source), but it is much better then 100% proprietary code. The best IMHO is a true OSS model for example JBoss. RedHat/JBoss will let you run it for free if you want. Guess what, Fortune 500 companies pay for it anyway - because they want support. JBoss let's you get any version you want. Other OSS companies make you pay for patches. Dan's situation (from what I know of it) is pretty unique in the OSS world. He single handedly runs an OSS JavaSpace implementation. Now while I have heaps of respect for Dan, that doesn't make me free of risk if I use Blitz. They have big buses in London - what if a bus hits Dan? I don't think that Dan's current situation will last if JavaSpaces takes off into the main stream. If something like Mule can go commercial OSS why can't Dan with Blitz? Having worked on an ESB product and an OSS one (failed sadly) I can say that a JavaSpace impl. is heaps more difficult. Also, who knows what will happen if Apache River (until recently was the Sun Jini/JavaSpaces implementation) will go. Again to be clear, my favorite model is pure OSS and even better yet commercial OSS like JBoss, Alfresco, RedHat, etc. Certainly not all things need commercial support (e.g., simple libraries like Struts, etc.). But I'd say that a JavaSpaces impl. is something that you would want commercial support for. With my biased view, I do think that one way to combat the "one stop shop" / too clever to do all tiers in one argument is to open up GigaSpaces. Opening it up certainly does not mean losing control of the code. What you are doing with Spring could be good as a level of indirection between (perhaps) me and GigaSpaces so that I have some level of freedom to leave you and replace you with another impl. And as you said we have discussed this a bit and I think that your position is defensible. It certainly is far better than building a proprietary service orchestration framework on top of GigaSpaces - but then again if you did, I just wouldn't use it. But you are right, OSS is definitely not risk free. It just comes with a very important risk mitigation - the freedom to fork. I will point at Matt Asay again on how to spot a successful OSS project: http://asay.blogspot.com/2007/02/how-to-spot-successful-open-source.html Today, neither Blitz or Apache River qualify as successful under this checklist (obviously debatable), but I'd expect this will change a year from now. You know your market much better than I do. If GigaSpaces future is niche very high end computing then whether it is proprietary or open does not matter - these people will not care if you can deliver the goods (at least for a few years). If you want to take the technology to the masses, however, I think opening it up under a commercial OSS model would be the best path. I think that what you are talking about with collapsing the tiers into compute nodes is great - it is also fairly radical. Without the code open, the masses will be scared of lock-in. I think that Tangosol might get an easier ride on this right now because (at least for now) they are focused on one thing - caching. People who feel serious pain around caching probably don't care about some proprietary bits. And as Cameron markets it, it is very mainstream (i.e., his statement that 99% of people use databases - just keep doing that and add a cache to help). Anyway, sorry to blather on. Mike
  49. Back to GigaSpaces and Tangosol. They both have compelling technology, but both are small vendors.
    I can't speak for the both of them, but one of them has more than doubled revenue every year (7!!!) since inception. (Yes, I'm talking about Tangosol.) And is 100% employee owned (no VCs).
    Where will this technology go? Will someone buy it to kill it?
    Since the ownership is controlled by the company itself, it is highly unlikely that it will be bought for slaughter.
    Will they buy it to grow it? Will they remain independent? Who knows.
    Doubling every year can't go on forever, but it certainly is an exciting market to be in! Did I mention the 20 straight quarters of profitability? ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  50. JavaSpaces Theory or Pratice ?[ Go to top ]

    So you don't need any database at all with JavaSpaces?
    James, the space is not a database. Instead you place data into the space that is used as INPUT to space operations. Gigaspaces has implemented a distributed, fault tolerant cache as apart of their product. This allows reliable storage of the data that is placed into the space. This close coupling of the cache, and the Spaces API allows you to implement applications that utilize the cached data as if it were local to the operation even though the data may reside on a remote machine. On the flip side, GigaSpaces also allows you to code Agents that are aware of the location of the data. This means that when the agents (services) execute, they can be forced to execute local to the data. So what does this means IN REAL TERMs. Imagine the following use case. You have large amounts of data to process. You can 1) Load it into the Space ( from the database or directly from your data stream and then persist it into the database ) 2) Have agents that asynch. process the data depending on the state. The agent are dynamically scaled (locally e.g. more threads on the same box, or globally e.g. more threads on a remote box) depending on the number of data items in the space. 3) Write the results to the space and then have the space asynch. store it to the data base. So, there is the JavaSpaces Spec... and there are JavaSpaces implementations. If you are trying to decide if you want to use JavaSpaces for a production application, I suggest you look at the GigaSpaces implementation and see how it relates to specifc Use Cases. GigaSpaces has features FAR beyond the basic spec. I think if you have a need for developing services that are not well served by the typical J2EE solution stack ( alot of the Financial Services uses cases are not well served by J2EE model ) you should take a look at GigaSpaces.
  51. Re: JavaSpaces vs. Messaging[ Go to top ]

    Hi James,

    Well for one, there are no destinations in JavaSpaces so you don't have to map your domain model / conversational state to things like hierarchical topics. For example:
    FOO.BAR.QUOTE.VALIDATE.SUCCESS or
    FOO.BAR.QUOTE.VALIDATE.FAILURE

    In a large systems you will have hundreds if not thousands of topics. You have to keep track of what follows which route, secure them, etc.

    This type of information is instead included in your objects themselves with JavaSpace Entry interface implementations. You can set up workflows just by changing the state of an object. When you do this, there is another worker configured to take the object and do the next step and so on. This is the Master/Worker pattern which is similar, yet more flexible than pub/sub workflows.

    Also, messaging is clearly for reliable message delivery. You have things like queues and durable subscriptions. Messaging itself is reliable, but you don't store state in it explicitly.

    A JavaSpace, on the other hand can be used to store state (e.g., conversational state, long lived transaction state etc.). A JavaSpace can be configured to be reliable (i.e., survive a crash). IMHO this is nice because you don't have to store this type of stuff in a database (more mapping). JavaSpaces in short is extremely malleable. It is appealing because it is just objects.

    So basically if you understand messaging well, you will quickly understand JavaSpaces.

    One thing that surprised me about JavaSpaces is the eventing model - an event doesn't push the value to you it just tells you that the type of object you are looking for has arrived to the space. You have to go read or take it if you want the value. GigaSpaces apparently allows you to override this behavior and Jini comes with a more messaging-centric event mechanism.

    In my estimation, JavaSpaces is messaging plus a lot more. I still thing messaging is great though and don't think that JavaSpaces replaces it.
    Two small additions: Most messaging systems best support uni-directional communication. Back and forth can be done but it can get messy whilst JavaSpaces tend to make that smoother. Second of all, there's an extension interface to JavaSpaces known as JavaSpaces05 that does delivery a copy of the value to you. Note the original will still be in the space so one either takes it or arranges for it to expire or .....
  52. Re: XML and State[ Go to top ]

    Personally I haven't had problems using XML for messaging. It has a number of advantages in terms of middleware and COTS support. However, I do see a tendency for some folks who are relatively new to SOA to overuse web services or services in general. The foundation of SOA is component-based architecture. The building blocks are components, not services. Services are implemented as facades for component (one or more) orchestrations that realize use cases. It’s the components that do the work. One mistake I see some folks making is creating services on speculation (no use case) and making everything a service, in other words using services as the building blocks. That certainly will clog your ESB and slow everything down. I’m seeing this a lot unfortunately. It’s very naïve. Perhaps some of the problem is that they do not understand the appropriate level to implement processes as service orchestrations. I see folks wanting to use this technique at too low a level. I blame a lot of this on vendors selling things and consultants and authors who’ve either never developed a system or haven’t programmed in 20 or 30 years. SOA is great but this kind of thing will put SOA in Gartner’s trough of disillusionment (or was that disappointment?) very soon. Another mistake I see being made is the equating of services and SOA to web services technologies. SOA isn’t just services, web services are not required for SOA and SOA does not mean web services. You have to use some common sense and understand that there are always trade-offs. The nice thing about components (think a role, an interface and a contract – usually a large object or collection of classes - Ambler’s example - not specific technologies) is that you can always expose it or a subset of its operation when a use case presents itself. In any case, that is why I am not dismissing Java Spaces out of hand though I’ve not used it, know little about it and generally depend on my middleware and data-dependent routing to do similar things. Of course, I always in transition and have some legacy systems to contend with so a Java only solution is rarely an option for me.
  53. Re: XML and State[ Go to top ]

    I see folks wanting to use this technique at too low a level. I blame a lot of this on vendors selling things and consultants and authors who’ve either never developed a system or haven’t programmed in 20 or 30 years.
    I think that vendors tend to push this is because it's what a lot management wants to hear. The general idea is that 'custom code' is scary and bad. If you sell your product as eliminating the need for custom [pick a language] then it's much more desirable than a more realistic pitch about how the tool can improve productivity of developers. A team of 'orchestrators' sounds so much nicer than a team of developers. In the end this is all crap and you end up with code at another level and often a lot of problems stemming from not being prepared to customize the (inevitable) 80% solution to fit.
    SOA is great but this kind of thing will put SOA in Gartner’s trough of disillusionment (or was that disappointment?) very soon.
    The thing about SOA is that it's not really a new idea per se but as soon as you slap an acronym on it, everyone's product does it, especially when it's as vague as SOA.
  54. Re: Javaspaces[ Go to top ]

    OK. I guess so. If you think of Javaspaces as a way to register interest in a certain message queue, with the ability to select specific messages for processing from the queue based on some criteria, and give that processing the ability to alter the messages (instead of just removing the messages and processing them), then you're pretty much there.
    Isn't removing a message from the queue, changing it and putting it back in the queue (technically as a new message) basically equivalent to 'altering' the message? I'm assuming that when you are altering something in a space, there's some sort of locking on it.
  55. Javaspaces vis-a-vis messaging[ Go to top ]

    Isn't removing a message from the queue, changing it and putting it back in the queue (technically as a new message) basically equivalent to 'altering' the message?
    No, although the difference may be minor: A new message does not have the same identity as the old message. Also, the "replace" style operation can be much more efficient than the "delete followed by insert".
    I'm assuming that when you are altering something in a space, there's some sort of locking on it.
    An implementation can choose to do anything it wishes, so long as the guarantees of the API are upheld. For example, it could be optimistic (10 clients could take the same tuple) or it could be pessimistic (excusion at the client level) or a hybrid approach. The operations are conducted within a transaction, so the clients are completely ignorant of the governing approach. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  56. Re: Javaspaces vis-a-vis messaging[ Go to top ]

    Isn't removing a message from the queue, changing it and putting it back in the queue (technically as a new message) basically equivalent to 'altering' the message?


    No, although the difference may be minor: A new message does not have the same identity as the old message.
    That depends on how you determine the identity of the message.
    Also, the "replace" style operation can be much more efficient than the "delete followed by insert".
    Of course, I can see that would often be the case. I'm more concerned about semantics as I'm generally working in environments with excess capacity.
  57. Re: Article: Using JavaSpaces[ Go to top ]

    Interesting article. JavaSpaces has always been one of those techs that I bump into every few months, go "Woah, thats pretty cool", and mostly forget all about. Once in a while, someone suggests it in a software architecture meetings, and all eyes hit the floor. I supose because it is fairly unconventional. I have noticed the exact same reaction when someone suggests an object database. I will make a point to look at it though, but the public field thing really puts me off. Reading that, brings back too many EJB 1 memories and also suggests a lack of progress that could indicate problems in the platform. I would think that if JavaSpaces had any serious industry/developer support the public field requirements would have been replaced with get/set properties some time back.
  58. Re: Article: Using JavaSpaces[ Go to top ]

    Once in a while, someone suggests it in a software architecture meetings...
    I know what you mean. I think part of the problem is that people already have the solution to the problem before they have the problem defined. ie "We need a web page and a table to ... ). While tools like Javaspaces are not a fit for a lot of projects, it does take a different mindset to know when and how they can be used.
  59. Re: Article: Using JavaSpaces[ Go to top ]

    Once in a while, someone suggests it in a software architecture meetings...

    I know what you mean. I think part of the problem is that people already have the solution to the problem before they have the problem defined. ie "We need a web page and a table to ... ). While tools like Javaspaces are not a fit for a lot of projects, it does take a different mindset to know when and how they can be used.
    Yeah, this is my view too. I believe the general architectural pattern that javaSpaces is an example of is called "the blackboard architecture". I've come across papers that describe this architecture, but I've yet to come across working examples in the field. I guess people tend to stick to what they know. Paul.
  60. Re: Article: Using JavaSpaces[ Go to top ]

    I think part of the problem is that people already have the solution to the problem before they have the problem defined.
    I believe the general architectural pattern that javaSpaces is an example of is called "the blackboard architecture". I've come across papers that describe this architecture, but I've yet to come across working examples in the field. I guess people tend to stick to what they know. Paul.
    Both right on the money. I've instigated two major commercial implementations in the field, so have seen JavaSpaces from those initial conceptual meetings through to production. It works best when the problem is clearly defined as a 'data-centric' one (which is why the blackboard analogy works so well) as opposed to a 'process-centric'. Financial institutions use it for things like price-curve simulations, where lots of bits of predicted prices need to be chucked at a horizontally scalable engine. Here the data changes a lot but the business logic doesn't. The last big implementation I worked on was using a space as an order processing pool. Web site orders are placed in a space and then processed safely through a number of distinct steps. Changes to the data merely trigger a different set of steps (workers), or the same steps in a different order. Of course you could build both these quite sufficiently using a traditional app server, but where JavaSpaces comes alive is how it scales, meets data changes, and (for me the most important aspect of it) how it changes communications to the business - because it works a lot like business owners think with space entries looking for all the world like order chits and workers looking like, well, workers performing roles. Doesn't sound that important until changes are required and everyone starts on the same page. It demystifies some of the good-design vs. business-speed confusion, and fits neatly with agile because, except for maybe the data model, design changes can fit into small iterations. I think once you seen it really work, the whole sense that it's a bit unconventional goes away and it becomes just another part of your arsenal.
  61. Re: Article: Using JavaSpaces[ Go to top ]

    I think part of the problem is that people already have the solution to the problem before they have the problem defined.

    I believe the general architectural pattern that javaSpaces is an example of is called "the blackboard architecture".
    I've come across papers that describe this architecture, but I've yet to come across working examples in the field.
    I guess people tend to stick to what they know.
    Paul.

    Both right on the money. I've instigated two major commercial implementations in the field, so have seen JavaSpaces from those initial conceptual meetings through to production.
    It works best when the problem is clearly defined as a 'data-centric' one (which is why the blackboard analogy works so well) as opposed to a 'process-centric'.
    Financial institutions use it for things like price-curve simulations, where lots of bits of predicted prices need to be chucked at a horizontally scalable engine. Here the data changes a lot but the business logic doesn't.
    The last big implementation I worked on was using a space as an order processing pool. Web site orders are placed in a space and then processed safely through a number of distinct steps. Changes to the data merely trigger a different set of steps (workers), or the same steps in a different order.
    Of course you could build both these quite sufficiently using a traditional app server, but where JavaSpaces comes alive is how it scales, meets data changes, and (for me the most important aspect of it) how it changes communications to the business - because it works a lot like business owners think with space entries looking for all the world like order chits and workers looking like, well, workers performing roles. Doesn't sound that important until changes are required and everyone starts on the same page. It demystifies some of the good-design vs. business-speed confusion, and fits neatly with agile because, except for maybe the data model, design changes can fit into small iterations.
    I think once you seen it really work, the whole sense that it's a bit unconventional goes away and it becomes just another part of your arsenal.
    Hi Julian, Thanks for your imformative response, it made a lot of sense. Was the data in the blackboard persisted in anyway? What do you think about my speculation that in some instances a blackboard could be seen as an alternative to a database? In your explanation, a blackboard sounds like an ideal workflow solution to me. Please expand. Thanks, Paul.
  62. Re: Article: Using JavaSpaces[ Go to top ]

    Was the data in the blackboard persisted in anyway?
    Yes - in many circumstances it needs to be. For statistical price curve simulations if you lose the grid you can just pick up where you left off and resubmit, but for an order processing scenario, you are dealing with a real customer's real order (i.e. revenue) so we persisted the space to an Oracle database.
    What do you think about my speculation that in some instances a blackboard could be seen as an alternative to a database?
    If you mean a real-time, memory-resident, highly scalable database then yes. Although to appease the purists, it's more of a datapool than a database per se (although you can query it in much the same way). Oracle RAC gives you much of what you get in a grid, so I'd want to think carefully about requirements before making a space seem a like-for-like swap - it's as much about how workers operate around the pool as the pool itself.
    In your explanation, a blackboard sounds like an ideal workflow solution to me.
    It certainly can be. But if there are *lots* of workflow-type requirements then you won't get the slick UI etc that a pure workflow tool can provide. I think, as you originally implied, that JavaSpaces should be considered, but I am always wary of sounding like it's the answer to everything. When the behaviour and implementation match it's a real joy to work with, but distributed spaces have a few infrastructural requirements that need to be worked through first.
  63. Re: Article: Using JavaSpaces[ Go to top ]

    Hello. Just to clarify what I understand: Javaspaces is one specific implementation that reassembles Blackboard /Tupple space patterns. Actually, these patterns are general, and are aimed to an architecture's solution where there is an space where data lives and process (expert) units that can work with the data in a complete free way. Note that it is not a way to share memory, nor a way to store data. The blackboard (space) is not by itself the pattern, but also the way the units process the data and how the solution is created. Another difference is that JavaSpaces' entries are objects. That is, we enter again the concept of an object as data. But objects are far more, even working units, and then the blackboard pattern is not accurately implemented since the working units may now live in the space! Thus, we can use JavaSpaces to implement the blackboard pattern, or even other tweaks of it. May be thought as a small object database (not relational, that is completely different story) or as a object pool, or as a shared memory that only support objects. Now, the pure blackboard is not a database, nor a workflow solution, and JavaSpaces is not an implementation of the pattern but a tool that allows to implement it (with the object restriction). I think that clarifies the concepts. You are right, as long as blackboard is replaced by Javaspaces and the database is actually an object oriented one. Think of replacing Hibernate with this! No mapping. William Martinez Pomares
  64. Re: Article: Using JavaSpaces[ Go to top ]

    Hello.
    Just to clarify what I understand: Javaspaces is one specific implementation that reassembles Blackboard /Tupple space patterns. Actually, these patterns are general, and are aimed to an architecture's solution where there is an space where data lives and process (expert) units that can work with the data in a complete free way.

    Note that it is not a way to share memory, nor a way to store data. The blackboard (space) is not by itself the pattern, but also the way the units process the data and how the solution is created.

    Another difference is that JavaSpaces' entries are objects. That is, we enter again the concept of an object as data. But objects are far more, even working units, and then the blackboard pattern is not accurately implemented since the working units may now live in the space!

    Thus, we can use JavaSpaces to implement the blackboard pattern, or even other tweaks of it. May be thought as a small object database (not relational, that is completely different story) or as a object pool, or as a shared memory that only support objects.

    Now, the pure blackboard is not a database, nor a workflow solution, and JavaSpaces is not an implementation of the pattern but a tool that allows to implement it (with the object restriction).

    I think that clarifies the concepts. You are right, as long as blackboard is replaced by Javaspaces and the database is actually an object oriented one. Think of replacing Hibernate with this! No mapping.

    William Martinez Pomares
    Hi William, Thanks for clarifying the volcabulary. I think you've confirmed what I've suspected for a long while - which is from a marketing perspective JavaSpaces sounded too similar to a data persistence solution, hence Suns decision to put their weight behind J2EE instead which targetted the relational model, and incumbent databases like Oracle and Sybase. Granted, a tuple space or blackboard is not a relational database, but then again how many relational databases follow all the Coad-Date rules? Often they are just used as a convienient place to share/persist data. Sun chose the conservative route, and tuple spaces and blackboards remain rare beasts along with OODBMS systems. Like so much in IT, we tend to end up with what we deserve. Paul.
  65. Blackboard versus Workflow[ Go to top ]

    Hi Julian -
    It works best when the problem is clearly defined as a 'data-centric' one (which is why the blackboard analogy works so well) as opposed to a 'process-centric'. Financial institutions use it for things like price-curve simulations, where lots of bits of predicted prices need to be chucked at a horizontally scalable engine. Here the data changes a lot but the business logic doesn't.
    This is something that I strongly (although respectfully) disagree with. The Javaspaces API is a good model for building software that automatically reacts to data changes. I've spent a lot of time looking at use cases in which customers of ours have used Javaspaces for this type of purpose, and I am convinced that it can play a critical role for this type of processing. However, from my own personal experience with large-scale risk engines (including replacing space-based implementations), Javaspaces it is a poor model for building large-scale consumers of data, such as non-holistic data-intensive compute work-loads. (For holistic calculations, it really doesn't matter what you use. You'd be fine reading from a file and performing a single-threaded batch process. Ask the telcos.) Just to give you some idea of the order of magnitude differences that we've seen, we dropped an overnight process to sub-minute, and a two-month process to sub-hour. In both cases, these were existing compute grid risk calculations that we helped to re-architect to be data-centric. In other words, we didn't have to increase the hardware resources in order to achieve those results. For this particular type of calculation, the master-worker or black-board approach is very sub-optimal. I'm not religious about APIs or models, and each type of problem has its own most optimal solution, which will often align the solution with a particular class of API. Right tool for the job and all. Your other point is very important to me:
    .. (for me the most important aspect of it) how it changes communications to the business ..
    This is an area that I have spent a great deal of time working with customers on over the past nine months. Technology is only as applicable as it is easy to use. If a business cannot alter its use of technology to match the changes in the business, and do so predictably and cost-effectively, then the technology becomes more burdensome than it is useful. Workflow-style processing, which the blackboard model can be used for, is a good example of processing that often requires a substantial amount of flexibility over time. Where JEE has fallen short (in general) is in its inability to be run-time flexible at the component level, e.g. to plug in new individual components, change components, and pull components out without having to "redploy an application". In this regard, I have been very excited by the advances in technologies such as OSGi, and the related work by the Spring framework. What I'd like to see, and what we're working with our partners on, is the ability to combine these benefits. This isn't a "product thing", since our customers require these benefits regardless of the product mix that they are using for any particular project. This is something that we need to demand of all vendors, products and frameworks. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  66. Re: Blackboard versus Workflow[ Go to top ]

    Cameron Well just to really freak you out. I strongly and respectfully agree with what you say. I appreciate you're not sneaking in a product versus product argument. And it's true the implementations I am referring to were based on Gigaspaces :) And yes, these *are* features to demand of all vendors etc. There's just not enough dang room to cover all the nuances of whether A or B is the right way to go in these threads. The approach we chose was certainly right for us, and has been borne out by the resulting platform. All I wanted to support is something a bit more open-minded than the unfortunately common oh-we-do-that-this-way mentality.
  67. Hi Wesley, GigaSpaces supports the use of POJOs in the free comunity edition as well as the Commercial Editions with all the bells and whistles (multi-language support, clustering, service management etc. . .) so using the free community edition you can write the following code: package gslabs; public class Account{ private int accountID; public int getAccountID(){ return accountID; } public void setAccountID(int val){ this.accountID = val; } } and then do this: package gslabs; import com.j_spaces.core.IJSpace; import com.j_spaces.core.client.SpaceFinder; public class HelloWorld { static IJSpace space = null; public static void main(String[] args) { if ( args.length != 1 ){ System.out.println("Usage: "); System.out.println("jini://lookup host/container name/JavaSpaces"); System.exit(1); } try{ space = (IJSpace)SpaceFinder.find( args[0] ); if ( space == null ){ System.out.println("Space not found: " + args[0]); System.exit(-1); } Account a = new Account(); a.setAccountID(12); space.write(a, null, 60*60*1000*24); System.exit(0); }catch (Exception e){ e.printStackTrace(); } } } to add it to the space. For more ideas on what a space is look at our getting started guide "The system explained" - it won a 2nd place award for being excellent documentation. Also: I have written several blogs about what using spaces means to me -- look for my note on "four verbs". Owen Taylor GigaSpaces http://jroller.com/page/owentaylor
  68. Owen, I think the issue speaks more to the idea that the SPECIFICATION doesn't support POJOs - your product does a fine job of managing a number of issues in the spec, but that doesn't mean that JavaSpaces in general doesn't have the problems.
  69. re re POJO use with GigaSpaces[ Go to top ]

    Hey Joseph, (do you prefer Joe?) Agreed. My expectation (Hope) is that the spec will mature over time due to the input of various implementors. As an example: Weblogic has continuously influenced the J2EE/JEE Spec and I see no reason why the same pattern cannot be expected with JavaSpaces. When an implementation detail from a vendor works well and is proven in battle, the spec should be enhanced to include that detail. -at least that is my opinion. ; ) Owen.
  70. Re: re re POJO use with GigaSpaces[ Go to top ]

    Hey Joseph, (do you prefer Joe?)

    Agreed.

    My expectation (Hope) is that the spec will mature over time due to the input of various implementors.

    As an example: Weblogic has continuously influenced the J2EE/JEE Spec and I see no reason why the same pattern cannot be expected with JavaSpaces.

    When an implementation detail from a vendor works well and is proven in battle, the spec should be enhanced to include that detail.

    -at least that is my opinion.

    ; )

    Owen.
    Hmmm, big can of worms this one. Off the top of my head..... I don't think we want vendors/implementors influencing specs, I think we want that to happen as the result of user feedback. There are too many examples at the JCP of vendor influenced specs which clearly serve the vendor more than the user, not good and often complained about in Java-land. A feature added by a vendor might well be "proven in battle" but it could be deemed to be "not within the spirit" of the spec - that is to say the feature may be philosophically wrong from some perspectives and perhaps ought to go elsewhere. I'm not saying we shouldn't learn lessons from the real-world just that putting those lessons into specs is no simple task.
  71. Just curious. Are there other implementations of 'Blackboard' pattern or some equivalents in the other technologies, which could be compared with JavaSpaces/SBA. This may fuel new ideas/patterns for usage of JavaSpaces. [ A newbie at TSS - my first post :) ]
  72. Just curious. Are there other implementations of 'Blackboard' pattern or some equivalents in the other technologies, which could be compared with JavaSpaces/SBA. This may fuel new ideas/patterns for usage of JavaSpaces.

    [ A newbie at TSS - my first post :) ]
    Hi Sarang, and Welcome :^) Good question. I've always been intrigued by java spaces too. I found this page on wikipedia that refers to "blackboard systems": http://en.wikipedia.org/wiki/Blackboard_system It seems that the blackboard approach is popular in AI. What I like about it is the loose coupling between software agents/components and the simplicity of the API. How do you apply this architectual pattern to bog standard IT systems though? Both Jini and JavaSpaces sounded great back in the 90's, but Sun didn't develop/market them well IMO. They seemed to get dropped once J2EE took off. For example, blue prints on how to apply Jini/JavaSpaces to typical IT problems would have been useful. Something along the lines of the J2EE Blue prints would have been great. Does such a thing exist? Is there anyone out there who can point us to a real world concrete example of their use? Paul.
  73. I
    It seems that the blackboard approach is popular in AI. What I like about it is the loose coupling between software agents/components and the simplicity of the API. How do you apply this architectual pattern to bog standard IT systems though? Both Jini and JavaSpaces sounded great back in the 90's, but Sun didn't develop/market them well IMO. They seemed to get dropped once J2EE took off.
    I shouldn't respond to my own posts, but I've just had a thought. A blackboard is effectively a central data repository, much like a database. It seems to me that bloackboard systems along with OODBMS have been overlooked infavour of the dominant relational model. So we've evolved from flat files to pure relational systems, to stored procedures to ORMs. Maybe pure OODBMS are next and then eventually blackboards? Gemstone had a pure OODBMS system in the 90's built using Smalltalk, which on all accounts proved very successful. I guess most IT departments are very conservative, hence the use of relational databases for everything! Paul.
  74. I guess most IT departments are very conservative
    I guess that is one way, a nice way, to put it. But I believe (and have seen) that it has little to do with being conservative. :( And oddly enough, traditionally conservative IT "industries" (ie banking, insurance) are taking the lead in embracing technologies like Jini, Javaspaces, Coherence, etc.
  75. I
    It seems that the blackboard approach is popular in AI. What I like about it is the loose coupling between software agents/components and the simplicity of the API.

    How do you apply this architectual pattern to bog standard IT systems though?

    Both Jini and JavaSpaces sounded great back in the 90's, but Sun didn't develop/market them well IMO. They seemed to get dropped once J2EE took off.



    I shouldn't respond to my own posts, but I've just had a thought. A blackboard is effectively a central data repository, much like a database. It seems to me that bloackboard systems along with OODBMS have been overlooked infavour of the dominant relational model.

    So we've evolved from flat files to pure relational systems, to stored procedures to ORMs. Maybe pure OODBMS are next and then eventually blackboards?

    Gemstone had a pure OODBMS system in the 90's built using Smalltalk, which on all accounts proved very successful. I guess most IT departments are very conservative, hence the use of relational databases for everything!

    Paul.
    Blackboard systems are nothing like databases. You can view them that way if you wish but it'd be a mistake.
  76. Blackboard systems are nothing like databases. You can view them that way if you wish but it'd be a mistake.
    I agree, but I have worked on many projects where the relational database was nothing like a relational database. My point is that equally using a relational database for a problem that does not map well to the relational model is a "mistake", or should I say will result in a sub-optimal solution. So why are relational databases so dominant? And why are other models, like tuple spaces, blackboards and OODBs so under-represented? My gut tells me that lots of "mistakes" are being made on a daily basis! Paul.
  77. My gut tells me that lots of "mistakes" are being made on a daily basis!

    Paul.
    I'd agree with that. :)
  78. My gut tells me that lots of "mistakes" are being made on a daily basis!

    Paul.

    I'd agree with that. :)
    Me two. ;-)
  79. So why are relational databases so dominant? And why are other models, like tuple spaces, blackboards and OODBs so under-represented?
    Economics, mostly. RDBs provide reasonably cheap, reasonably performant, ubiquitous transactional storage. Combined with network effect of essentially universal adoption of SQL (by both industry as well as developers and users) plus this rise of glue systems like JDBC and ODBC, RDBs are the Go To technology when you want to stuff things someplace other than a file system. By choosing an RDB, you also get a whole slew of interesting "free" tools along with it (like sucking data in to Excel, or leveraging an ETL tool, etc.) Simply put, it's not that RDBs are the end all be all, but for a VAST majority of cases, they're more than sufficient. There would basically have to be a very compelling long term performance (and I'm talking 500-1000% better performance here, seat of the pants "HOLY MIPS, that's fast" difference), or platform constraint (like an embedded system), to consider something other than an RDB for an application, IMHO.
  80. There would basically have to be a very compelling long term performance (and I'm talking 500-1000% better performance here, seat of the pants "HOLY MIPS, that's fast" difference), or platform constraint (like an embedded system), to consider something other than an RDB for an application, IMHO
    There are applications where other models, such as OODBMS can give that kind of performance boost. Of course most of that advantage comes when using an OO language supported by the OODBMS. Unfortunately OO languages did not become dominant in new development until after RDBMS was well established. (Oracle shipped in 1980, Gemstone in 1985) Using an OODBMS without the supported OO language would make no sense. Another problem with OODBMS is that they are not flexible. They are basically network model data bases so they can be extremely fast when the schema is aligned with what you need to do, but they perform poorly when you try to do something not accounted for in the schema. The CODASYL (network model) databases that RDBMS's knocked off were all faster (for what they were designed to do) than the RDBMS's that replaced them, but their lack of flexibility was unacceptable. RDBMS also had "standards" of sorts like SQL (which preceded the relation model and was foisted on Codd by his employer, IBM) which made them easier to learn to use. CODASYL had standard query and DML languages too, but they were more specific to the physical schema (pointers, etc.) than SQL is. And, of course, they were not flexible. OODBMS didn't seem to have any standards until JDO showed up and we saw OQL, etc. So these other DBMS models still exist and OODBMS is found in many niches - especially middle tier caches and network oriented applications (GIS, utilities), but RDBMS dominates the mainstream. You won’t find many “system of record” databases being developed on something other than an RDBMS.
  81. I may have a couple of things to explain the Relational majority. Architecture-wise, the selection of the solution structure may drive the designer to think of a non-relational data management system, but schedules, budget constrains and learning curves will drive him back to select the already owned RDBMS, using the latest "features" it has to perform the job that is unnatural to it. Example: how many solutions do persist data using Hibernate? Note that they are working with objects that are mapped to tables underneath. Would all those solutions be more likely suitable for an OODBMS? Now think on all those new features in old names like Oracle and now DB2 (Viper) that are offering XML storage in the system, and are just storing large string chunks or pre-shredding the XML into tables (more non-natural mapping). Flexibility. But then, back to the architecture, the solution and the problem are usually mismatched, being the solution more personal to the designer, ending in a tweak of the problem to fit the solution. If so, I would guess a big part of those "system of record" solutions may had a problem that was possibly solved by a document centric solution, or an object centric one. Who knows? I'm completely sure that 100% of the engineers I know do know about RDBMS, and I'm 100% sure that not all of them know about XDBMS or OODBMS. In fact, I can count them with my fingers. So I wouldn't expect solutions that use those technologies, but tweaked problems that fit the "natural" recipe of OO+RDBMS (because everybody does that, so they sure are not wrong". William Martinez Pomares
  82. There would basically have to be a very compelling long term performance (and I'm talking 500-1000% better performance here, seat of the pants "HOLY MIPS, that's fast" difference), or platform constraint (like an embedded system), to consider something other than an RDB for an application, IMHO.
    That's surprisingly easy to do, actually. I took a team down to Sun Labs and using several of the technologies people on this thread either support or represent, demonstrated just that. We decreased latency by at least 3 orders of magnitude (we did all of our measurements in microseconds, increased tps rates by 30-40 times and subjected the instances to 30 times our normal concurrent user load. In fact, we didn't have enough client hardware to make the db fall over. For one of our systems, I estimate we can replace 20 sql licences and 10 boxes with either a single oodbms plus 1 box or one sql license and 2 cache licenses plus 3 boxes (double it up for fault-tolerance of course). To paraphrase one of our ops engineers, "our current footprint is almost tantamount to fraud."
  83. Hi Bill -
    I took a team down to Sun Labs and using several of the technologies people on this thread either support or represent, demonstrated just that.

    We decreased latency by at least 3 orders of magnitude (we did all of our measurements in microseconds, increased tps rates by 30-40 times and subjected the instances to 30 times our normal concurrent user load. In fact, we didn't have enough client hardware to make the db fall over.

    For one of our systems, I estimate we can replace 20 sql licences and 10 boxes with either a single oodbms plus 1 box or one sql license and 2 cache licenses plus 3 boxes (double it up for fault-tolerance of course).

    To paraphrase one of our ops engineers, "our current footprint is almost tantamount to fraud."
    Awesome results! While we see similar results elsewhere, what seems to end up happening over time is that the application will "grow" (i.e. morph, lots of stuff tacked onto it) and those initial efficiencies will get burried under piles of logic. The iterative algorithms subsequently introduced (long after you perfect the architecture) will take the efficiencies down a big-O notch, and then the iterative algorithms introduced on top of _those_ will take it down to the second exponent, and so on. We've seen this in another application (similar market) that does well over one thousand cache queries per transaction in order to feed its complicated rules engine (a dynamic pricing system). Their "under heavy load" transaction time is up close to a second, and [to compare] it would be _many minutes_ if they hadn't built it on top of an parallelized in-memory architecture. Anyway, it's food for thought. I'd be curious how you see the long term process of preventing "performance creep" once you do have the architecture locked and loaded. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  84. Some time ago I blogged about my experience using Blitz, attached source and all, and it gets downloaded quite frequently. I think it is because it lists exactly what you need to do get up and running. The description is 1.5 years old, so things may have changed a bit. http://www.jroller.com/page/matsh?entry=intreagued_by_javaspaces_try_blitz Mats
  85. Something else from the article[ Go to top ]

    One small thing that is missing, is that if the client (machine that is going to execute the task entry) doesn't actually know how to execute the entry, the code will be dynamically downloaded to the client and then executed. Thus the client does not require to have all the classes for all possible Task Entries to be on the classpath when the client is started Cheers --Calum
  86. Patrick Logan Summary[ Go to top ]

    FYI http://patricklogan.blogspot.com/index.html TSS registration is broken so he linked to it.
  87. Try this link instead[ Go to top ]

    http://patricklogan.blogspot.com/2007/02/tss-using-javaspaces.html
  88. Hi, a lot has been said already in this thread. I want to add with my 5 cents what has already been said in a similar way. But there is a point, I think it has not been mentioned so far. It is not a major issue, but it seems to me that it is also a problem. What I mean is that event notification being based on an Entry added to a space is too crude, too little abstract. Let's say some object wants to be notified when a traffic light changes from red to green. Then it has to listen to some Entry being added to the "green-traffic-light" category, figure out whether an Entry with the same id was removed from the "red-traffic-light" category. This is really to low-level and too little abstract. I think the space concept works well for distributed processing. For distributed event notification and shared data something like Tangosol Coherence is a much better solution where you are back to OO-style abstraction such as messages being exchanged between objects. Anyway, I fear that a fully distributed system is simply not required to persistent dumb EJBs. A simple conventional client/server architecture does the job. So why take something much more complicated like a truly distributed system? Distributed systems are mega-cool and very fascinating to me. But applications are more in the academic world where people get money from some University to make distributed agent systems, smart networks and that kind of stuff. Unhappily, what creates 95% of the jobs is persisting dumb EJBs I fear ... Regards, Oliver