Home

News: OnJava: Designing Messaging Applications with Temporary Queues

  1. OnJava has published Thakur Thribhuvan's "Designing Messaging Applications with Temporary Queues," an article explaining how to use JMS' temporary queue capability to allow applications to "efficiently scale because you can easily expand the number available at runtime."
    Temporary Destinations: An Overview Temporary destinations (temporary queues or temporary topics) are proposed as a lightweight alternative in a scalable system architecture that could be used as unique destinations for replies. Such destinations have a scope limited to the connection that created it, and are removed on the server side as soon as the connection is closed. Only a single well-known static queue is required for producers/senders to connect with consumers using temporary destinations. The JMS header field JMSReplyTo is always used in conjunction with temporary destinations. Since the identity of the temporary destination is known only by the connection or session that created it, the consumer/receiver cannot know the destination name. The solution is to have the producer/sender send the name of its temporary destination as a header field (JMSReplyTo), as part of a message, sent to a known static queue listened to by the producer/sender. Limitations of Temporary Destinations There are a few limitations that must be recognized regarding temporary destinations:
    • A temporary destination can only be consumed by the connection that created it.
    • The life span of temporary destinations is only for the duration of the connection where they are created.
    • When you close the connection that has a temporary destination, the destination is closed and its contents are lost.
    • You cannot have durable subscriptions to a TemporaryTopic.
    • Each temporary destination is unique and cannot be copied.
    • Temporary destinations cannot be routed using an enterprise messaging service.

    Threaded Messages (17)

  2. Grids?[ Go to top ]

    It looks like DataGrid solutions like GigaSpaces provide better alternative: destinations can be as temporary or as static as necessary. As additional bonus those messages can be viewed and operated with using JDBC and Map interfaces ( in GigaSpaces). Any thoughts on why pure messaging solution can be better than Data/Computing Grid?
  3. Re: Grids?[ Go to top ]

    It looks like DataGrid solutions like GigaSpaces provide better alternative: destinations can be as temporary or as static as necessary.
    As additional bonus those messages can be viewed and operated with using JDBC and Map interfaces ( in GigaSpaces).
    Any thoughts on why pure messaging solution can be better than Data/Computing Grid?
    Good point Konstantin. Even though we support JMS i have to say that Temporary queues sounds like a "hack" to me do things that JMS was not originaly ment for i.e. master/worker patterns. For those that are not familiar with JavaSpaces i would suggest that you would refer to the followoing article by Joe Ottinger - Using JavaSpaces for a reference. The space model can be used to address other messaging driven scenarios as described here Space Based Architecture (SBA) is an end to end architecture for scaling out stateful applications. It combines master/worker pattern for parallelizing and distributing business transactions and data-grid pattern for managing the state in a distributed environment. HTH Nati S www.gigaspaces.com Write Once Scale Anywhere
  4. dead horse[ Go to top ]

    i have to say that Temporary queues sounds like a "hack" to me do things that JMS was not originaly ment for i.e. master/worker patterns.
    The master/worker pattern is the raison d'etre for the LINDA / tuple spaces / JavaSpaces approach. It is a natural fit. Unfortunately, and as you know, most of the problems that programmers face are not master/worker problems. ;-) Temporary queues have nothing to do with master/worker. They simply help to more elegantly solve certain messaging-related challenges. JMS is a messaging API, and while I am not particularly fond of it, it is at least focused on messaging. To answer Konstantin's question, you can't compare a product to an API. When it comes to messaging (JMS), products such as Tibco's EMS or Rendezvous, or IBM's MQ Series, or Sonic MQ, or some of the lesser known but well regarded solutions (e.g. SwiftMQ) are pretty amazing in terms of capabilities and performance, and for messaging purposes far out-shine more general purpose state management products such as databases or data grid software. Konstantin, you should also check out QAPI: http://www.jroller.com/page/cpurdy?entry=the_q_the_simplest_distributed ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  5. Re: dead horse[ Go to top ]

    When it comes to messaging (JMS), products such as Tibco's EMS or Rendezvous, or IBM's MQ Series, or Sonic MQ, or some of the lesser known but well regarded solutions (e.g. SwiftMQ) are pretty amazing in terms of capabilities and performance, and for messaging purposes far out-shine more general purpose state management products such as databases or data grid software.
    The open source JMS providers like Apache ActiveMQ are pretty good too! Crikey Cameron, you've been at Oracle 2 minutes and you're already forgotting about open source :-) James Iona Open Source the Enterprise Way
  6. Re: dead horse[ Go to top ]

    Crikey Cameron, you've been at Oracle 2 minutes and you're already forgotting about open source :-)

    James
    I don't know if it's because he's now at Oracle. After all, his product was not an open source too. Jan
  7. Re: dead horse[ Go to top ]

    The open source JMS providers like Apache ActiveMQ are pretty good too!

    Crikey Cameron, you've been at Oracle 2 minutes and you're already forgotting about open source :-)
    Fair enough, but I didn't mention "Oracle AQ" either ;-) The problem is that I don't personally have enough experience with ActiveMQ (and the other open source JMS implementations), so I can't speak knowledgeably about them. From the reading that I've done, I do know that it (ActiveMQ) is a lot more flexible than "JMS" is being portrayed as, which is one of the reasons why I made the "impossible to compare a product and an API" comment. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  8. Re: dead horse[ Go to top ]

    From the reading that I've done, I do know that it (ActiveMQ) is a lot more flexible than "JMS" is being portrayed as, which is one of the reasons why I made the "impossible to compare a product and an API" comment.
    Yea, this is pretty key. Messaging has been around a LONG time, and used and abused in all sorts of ways over time. JMS, however is a "not quite but almost" LCD kind of specification. It's mostly designed for connecting to Messaging systems, not so much for managing them.
  9. Re: dead horse[ Go to top ]

    From the reading that I've done, I do know that it (ActiveMQ) is a lot more flexible than "JMS" is being portrayed as, which is one of the reasons why I made the "impossible to compare a product and an API" comment.
    Yea, this is pretty key. Messaging has been around a LONG time, and used and abused in all sorts of ways over time. JMS, however is a "not quite but almost" LCD kind of specification. It's mostly designed for connecting to Messaging systems, not so much for managing them.
  10. Re: dead horse[ Go to top ]

    i have to say that Temporary queues sounds like a "hack" to me do things that JMS was not originaly ment for i.e. master/worker patterns.


    The master/worker pattern is the raison d'etre for the LINDA / tuple spaces / JavaSpaces approach. It is a natural fit. Unfortunately, and as you know, most of the problems that programmers face are not master/worker problems. ;-)
    I come from a messaging background, and most of the applications I worked on included sending a JMS message for a receiver to process it. This sound very similar to a master creating a Job for a worker to process. Now, if you can actually work with Objects instead of wrapping it with JMS messages, and use the Space as the transport, wouldn't that be a nice thing? Why a nice thing, you ask? Simply because you can then use the Space also as your data grid for in memory data access. Master Worker is one of the main usage patterns (insert your french translation to show off here). We at GigaSpaces have implemented and expanded on this concepts to allow for more advance usage patterns (for example, fifo notifications), which include most of the messaging scenarios. This of course has been done since we believe that you can't take messaging as a standalone and isolated feature of your project that has no affect on other aspects of it.
    To answer Konstantin's question, you can't compare a product to an API. When it comes to messaging (JMS), products such as Tibco's EMS or Rendezvous, or IBM's MQ Series, or Sonic MQ, or some of the lesser known but well regarded solutions (e.g. SwiftMQ) are pretty amazing in terms of capabilities and performance, and for messaging purposes far out-shine more general purpose state management products such as databases or data grid software.
    Products focused only on messaging are amazing products. The problem is that most of the projects have to do more than just messaging, and the whole latency path is the one that counts. Part of this latency path is messaging, other parts include data access and parallel processing. Now wouldn't it be nice to work with a single product for it? The nice thing about a Space (or any other solution that provides this capabilities) is that there is no distinction, and there is no need to have one, between temporary and non-temporary queues. A set of Objects with similar characteristics can automatically and dynamically become a queue (or a topic).
    Konstantin, you should also check out QAPI: http://www.jroller.com/page/cpurdy?entry=the_q_the_simplest_distributed ;-)
    Well, you know what they say, if you can't compete with them, bash them. And you do bash very eloquently :)
  11. Re: dead horse[ Go to top ]

    Forgot to add my signature, Shay Banon System Architect At GigaSpaces Compass Founder and Lead Developer
  12. Re: dead horse[ Go to top ]

    .. you should also check out QAPI:

    http://www.jroller.com/page/cpurdy?entry=the_q_the_simplest_distributed

    ;-)


    Well, you know what they say, if you can't compete with them, bash them. And you do bash very eloquently :)
    We position our software in areas where we have clear competitive advantage, and we focus on those areas. That's why we have been so successful in the markets that we compete in (e.g. distributed caching, data grids). QAPI is definitely tongue-in-cheek, but if it stings, then you have to ask yourself if every problem is starting to resemble a nail. The tendency of software engineers (and particularly software vendors ;-) to focus on "one size fits all" solutions is very scary. It's like "J2EE: The Sequel", all over again. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  13. Re: dead horse[ Go to top ]

    .. you should also check out QAPI:

    http://www.jroller.com/page/cpurdy?entry=the_q_the_simplest_distributed

    ;-)


    Well, you know what they say, if you can't compete with them, bash them. And you do bash very eloquently :)


    We position our software in areas where we have clear competitive advantage, and we focus on those areas. That's why we have been so successful in the markets that we compete in (e.g. distributed caching, data grids).

    QAPI is definitely tongue-in-cheek, but if it stings, then you have to ask yourself if every problem is starting to resemble a nail.

    The tendency of software engineers (and particularly software vendors ;-) to focus on "one size fits all" solutions is very scary. It's like "J2EE: The Sequel", all over again.
    Based on my experience, and what I have seen in the field, people are looking for more than just Data Grids. Data Grids solve an important part of the problem, and our main focus is Data Grids, but it is important to understand that it is *just* part of the problem. Developers are looking for a solution that will enable them to solve most of their problems, and take other problems out of their main development path (or execution path). Take Spring for example, the core of Spring is IOC and AOP. What they did as well was either provide simpler API to popular frameworks, or go ahead and implement their own simplified version of it (transaction management and JMS container are two prime examples). They did this because the field, the users asked them for it. The same happened in GigaSpaces. We have found that in order to solve scalability issues, just adding a Data Grid is not enough. You need to have a coherent ;) view of most of the different moving parts in your app (if not all) and use them in a single unit. This include messaging and parallel processing. Personally, I am a great believer that this should be the next platform for development. It just make sense. Application Servers vendors already provide their own JMS implementation, JEE implementation, parallel processing implementation, and some of them even Data Grid solutions. The main problem is that there is no simple and performant way to integrate all of it. All have different clustering models, different API, different best practices, ... . This makes a developer life a pain. Like yourself I also believe that if a problem is found, we need to focus on the problem and solve it. We simply have a different definition of the problem. If we draw on the Spring analogy again, what do you think would have happened if the Spring guys only focused on IOC? There has to be a better way. GigaSpaces implement a nice solution, but this is not a vendor pitch. Things need to happen in order to simplify the developers experience, and I have been starting to hear a lot of people talking about event processing platforms, real time application servers, and so on. I certainly see in the future a common platform spec that solves this problems. Cheers, Shay Banon System Architect at GigaSpaces Compass Founder and Lead Developer.
  14. Re: dead horse[ Go to top ]

    Hi Shay -
    We have found that in order to solve scalability issues, just adding a Data Grid is not enough. You need to have a coherent ;) view of most of the different moving parts in your app (if not all) and use them in a single unit. This include messaging and parallel processing.
    I think the background of your company requires the product to move in a broader manner, which is what is occurring. I don't want to say anything that could be considered slagging off, since I have a great deal of respect for Nati and you and others there, even if I disagree with some of the rationale behind the product decisions.
    Personally, I am a great believer that this should be the next platform for development.
    Based on the growth in our Coherence business, I think it's safe to say that Data Grids have already been adopted as "the next platform for development." Let me know next time you're in Boston, and I'll spend some time showing you what I mean :-)
    Things need to happen in order to simplify the developers experience, and I have been starting to hear a lot of people talking about event processing platforms, real time application servers, and so on.
    That may have been me you were hearing .. ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  15. Re: Grids?[ Go to top ]

    "It looks like DataGrid solutions like GigaSpaces provide better alternative: destinations can be as temporary or as static as necessary."
    Owen just posted an interesting post describing why space based architecture is a simpler and more scalable alternative Pattern Discussion: Priority-based and FIFO-based transaction processing From his blog: "The master-worker pattern (discussed simply here is one that is commonly used with JavaSpaces. Most people think of Master/Worker as a way to parallelize compute tasks i.e. you take a given compute job, break it into a number of sub-tasks, write those tasks as entries into the space and have workers take them and execute them in parallel. The more workers available, the more work that can be done and the system scales linearly in terms of the work able to be performed. In the scientific community and other relatively narrow contexts, this is a common use of blackboard technologies such as tuple and JavaSpaces. When the space architecture is introduced into the world of extreme transaction processing however, we start to see the power of leveraging a space to execute the somewhat different work of parallel transaction processing. Instead of a single master orchestrating a single overall job, we have many "masters" that execute multiple "short lived" transactions that have no dependencies between one another. In trading applications or order processing applications there are no dependencies between the different transactions (as they commonly belong to different portfolios or accounts) however, there may still be dependencies among operations within a particular transaction. For example: in such applications you must ensure that the order in which transactions are processed is accurate in terms of the order in which the user originally executed them. (A "buy" order must be executed before a "sell" if that was the order in which the user executed those two commands.)" Nati S. GigaSpaces Write Once Scale Anywhere
  16. Scaling the number of queues.[ Go to top ]

    Temporary queues are useful if you are using a messaging system. It is espectally useful for processing replies in a request/response pattern. However if you don't use a messaging system you are not limited by the number of queues/topics which you have created nor do you have the same managability issues. Note: if you use point-to-point TCP/IP communication you are basically using temporary queues all the time. :) (With the same limitations) BTW: I prefer distributed data models in high coupled application(s) and messaging for highly decoupled applications. Each has its advantages.
  17. JMS destinations do not have to be static. If you use a decent JMS provider then destinations can be created and used at runtime without any cumbersome central static configuration. So there's a middleground between static centrally administered destinations and temporary destinations. FWIW temporary destinations are really geared towards clients; particularly for user interfaces, so that when the client dies so do the temporary destinations and messages on them. James Iona Open Source the Enterprise Way
  18. For most JMS servers handling temporary queues is expensive. There are performance degradations after creating a certain number of queues in the same MS process and then creation and deletion of queues at runtime can be an expensive operation (of course, it varies depending on JMS vendor). Temporary queues are a way to enable a request-reply (synchronous) mechanism using am intrinsically asynchronous implementation (messaging servers) and I think it should be considered with care. I would say JavaSpaces and messaging are quite complementary solutions and should be mixed to get the best of each world, I can't see them as competitors because they are useful to solve different classes of problems. Generally I see JavaSpaces-based products more suited for synchronous communication scenarios than JMS. In this terms JavaSpaces can look more "simmetric" as it handles well also asynchronous communication, but in this case JMS maybe is lighter. Regards, M.