TSS Article on JMS Application Architectures

Discussions

News: TSS Article on JMS Application Architectures

  1. TSS Article on JMS Application Architectures (13 messages)

    'JMS Application Architectures', by Roland Barcia, discusses some of the architectural issues in applications that use messaging and JMS in general. It examines state vs application decoupling, synchronous vs asynchronous use cases, and discusses the consequences of certain JMS topologies with respect to transactional requirements.

    Read JMS Application Architectures
  2. Good article . but missed a few points.

    would have been nice if talked about Application State Intigrity and Error Handling Scenarios in an Async Architecture . Example I have a Policy System and a Billing System that talk asynchronously.
    <br>
    case 1 : Policy System sends a renew policy to Billing assuming fire and forget. What happends if Billing is not able to Renew Policy due to some Business Rule(Exception)
    <br>
    case 2 : Even worse . after case 1(lets say after 5 hours) Policy systems sends a Payment MEssage to Billing. and as the Previous Renew Failed . Billing would be processing a Payment on an inconsistent State. (The Effect of Renew has not yet taken place on the Data Model and we are proceesing a payment )
  3. Thanks for the comment.

    I probably could have added some error handling techniques. With pure fire and forget, I mention that the producer would have to do some type of validation of the message (this may include business validation). If the producer cannot, then there probably has to be some reply later.

    With reply, I mention you need to probably create an additional state into your model indicating that the request is process or something. Then if the reply can have information about the error and the state can be updated to error or reset.

    There are tons of combinations to consider and wasn't sure where to draw the line for an article.

    Thanks again.
  4. There are tons of combinations to consider and wasn't sure where to draw the

    > line for an article.

    I think you could have been more specific rather than trying to stay general. It would have been easier to follow.

    I was hoping to find learn some good JMS architectures that bad architectures. The bad architectures seem pretty obviously bad - are people really
    using these them? Maybe they do so because they are told to use a messaging product and they really need synchronous request/response.

    In the application I'm involved with, all the events/messages go in one direction. There's really no point sending a reply if there is an error (in validation such as database constraint error) as manual intervention is likely required (and the producers are "dumb"). I'm wondering if it's best practise to redirect those message to "error queues" with perhaps a user-defined property to say what the error was (and perhaps how many times it's been retried). Somehow those messages need to be replayed once some manual intervention has happened. I get the feeling that it's bad to use DMQs for this purpose as DMQs are not treated with the same care as normal queues.

    Also, all my events are produced on remote hosts and need to find there way to the main/db host. In order to deal with failures and down-time, I'm thinking that the remote hosts each need a local queue to post to. However, there seems to be no standard magic for getting those events from the remote queue to a queue on the main host. I could consume the messages directly from the remote host (but is that best practise?). There could be thousands of messages which could be moved up quickly to a local queue on the main host and processed at leisure.

    Steve.
  5. A very good site for design patterns concerned with messaging systems can be found at http://www.eaipatterns.com (by Gregor Hohpe and others).

    -Stefan
  6. eaipatterns.com[ Go to top ]

    Absolutely. EAI patterns is a fabulous site. Top notch material. Would recommend it to any software architect.

    Sandeep.
  7. I think the intro blurb and title used for this article was rather misleading (and so is the article to some extent). While they seem to talk about general usage of JMS from an architectural perspective, in reality the article is limited to a subset of common JMS usage.

    I generally see async messaging used in two very broad (and very different!) sorts of scenarios:

       1) Applications aimed at loosely coupled integration of large systems
       2) Applications aimed at performance, performance, performance!

    The article almost exclusively focuses on the first scenario, where big systems are tied together using either a small number of queues or pub/sub involving a small number of listeners. Often the intent is to hide the producers from the consumers (and vice-versa), transactions weigh in heavily, and the author is entirely correct in pointing out the significant downsides in attempting what he calls "pseudo-synchronous".

    However, there is an entirely seperate domain which also uses async messaging systems like JMS in an entirely different manner. This is epitomized by financial trading applications. Here, the goals and environment are rather different:

       a) Attempts to minimize resource usage
       b) Distributing many small bits of information to a very large number of consumers.
       c) Highly efficient servers and clients

    For example - think of the quintessential finance application - the stock ticker. A small number of "servers" are pumping out pricing updates on stocks to a huge number of consumers. Here, messaging is used to get small messages out to many consumers in very high volume, and messaging is being used primarily because it's the only way to get the info to many consumers quickly.

    Likewise, alternatives like clients polling a server or RDBMS or what have you often overload limited resources and vastly increase latency.

    In other uses - think of a web browser pulling up a web page, consisting of various frames and images. Imagine a "synchronous" browser that pulled up each piece individually in serial fashion (get frame 1, get frame 2, get image 1, get image 2, get image 3...). Now imagine browsers are they actually are - fire off multiple requests in parallel, and then gather in the results as they come in.

    My point isn't to denigrate the article - it makes excellent points. But at the same time, many applications go directly against some of the article's advice because async messaging is proven to be the lowest latency/highest throughput solution to many problems, and people are willing to take the complexity hit to get the performance.

    In the past couple of years, alot of people have tried to focus JMS strictly in the integration space, and have sort of forgotten that messaging came into its own as a high-throughput solution in the financial arena (and some other specialized uses). And they've forgotten (or don't realize) that messaging have many constraints that were learned decades ago by brokerage houses et al which are largely ignored by integration-oriented JMS users. And so we see people on the one hand carefully architecting JMS-oriented solutions from an integration perspective, and then blowing the solution out by doing silly things like trying to publish 2MB objects to a gaggle of subscribers.

    In all I'd like to see JMS articles that try to consider the topic from somewhat wider perspective, and shows the true broad array of usage scenarios that async messaging is routinely used for.

         -Mike
  8. Your are right, I am leaning toward the integration space. JMS applications can be used for performacne boosters in certain areas. They generally follow the fire and forget pattern, which I state is Ideal for messaging.

    One example is Distributed Asynchronous logging. I worte an article on WebSphere Developer Domain on using JMS for logging last year.

    http://www7b.software.ibm.com/wsdd/library/techarticles/0207_barcia/barcia.html

    I probably could have put the word integration in the title to give some better indications. My goal was to pint out what really point out the problems I see customers making over and over again and how to improve it.

    I can see where fire and forget (even with reply later) may perform better than other means and buy great benefits. I do not see how true Pseudo-synchronous (from the client perspective) will buy you performance and you are still left up to the server program to process a request and send a reply. Plus messaging is an extra layer in this aspect.

    Thanks for the comments.
  9. \Barcia\
    I can see where fire and forget (even with reply later) may perform better than other means and buy great benefits. I do not see how true Pseudo-synchronous (from the client perspective) will buy you performance and you are still left up to the server program to process a request and send a reply. Plus messaging is an extra layer in this aspect.
    \Barcia\

    The pay off on the client side is when you need to perform multiple requests that are independent of each other. This comes up more often than you might believe in complex applications. The performance gain comes because you fire all your requests off at once, and then reap the replies as they come in, resulting in your total request time more or less equalling the time it takes to get the longest running request back. This goes back to my web browser example - you don't serially retrieve each image in turn, instead you fire off multiple HTTP requests and then process the results as they come back in.

    This sort of thing can be done with multiple threads blocked on various synchronous requests, but it's often more efficient and involves less overhead overall to use a messaging system instead (the message system in effect multiplexes/threads for you).

         -Mike
  10. I have seen this for inquires usually or independent updates that do not depend on each other to be domain correct, or have to be done transactionally together. This is still Request with reply later because you do other things before you wait for the reply. But code ususally becomes difficult to maintain, especially with updates with late replies. The Pseudo-sync event pattern I described can still be used for this.

    Once update have to be consistent for the state of the domain, messaging could become complicated. If one of the replies reports a failure, you may need to fire off some type of compensation transaction to undo the changes since the message has to committed before replies come back. Not that it is wrong, just complicated, usually workflow systems come into play in these architectures.

    My publish and subscribe sample in the doc is an example where I feel messaging can increase performance as well, different scenario, but performant minded.

    WebSphere 5 Enterprise Edition has Asynchronous Beans that give the ability to create safe threads inside an EJB Container. I believe that there is a JSR out to address adding this type of functionality to the spec. This is an alternative to messaging for the type of multi-plexing requests you speak about.


    Thanks again,



    Thanks,
  11. \Roland Barcia\
    I have seen this for inquires usually or independent updates that do not depend on each other to be domain correct, or have to be done transactionally together. This is still Request with reply later because you do other things before you wait for the reply. But code ususally becomes difficult to maintain, especially with updates with late replies. The Pseudo-sync event pattern I described can still be used for this.
    \Roland Barcia\

    Update operations can definitely make things much more complex. However - there's a surprising number of operations that are completely read-only in nature. It's these types of operations which can be parallelized and result in much zippier clients.

    Think of a typical "listing" page consisting of multiple parts. Synchronous GUI clients often either get these "parts" individually, or have them shipped as the result of one monster request.

    You could use messaging to fire off "requests" for all pieces independently, and receive them independently as well.

    Admittedly, you could also do this with multiple threads waiting individually on synchronous requests, but as I mentioned this puts a heavy multithreading burden on the client.

    \Roland Barcia\
    Once update have to be consistent for the state of the domain, messaging could become complicated. If one of the replies reports a failure, you may need to fire off some type of compensation transaction to undo the changes since the message has to committed before replies come back. Not that it is wrong, just complicated, usually workflow systems come into play in these architectures.
    \Roland Barcia\

    As I said, it's understood that updates greatly complicate the picture. However - it seems common for alot of developers to look at the update cases, make an exclamation of dismay, and then abandon the approach altogether. Meanwhile, they may have a glacially slow app with many read-only "panes" that could benefit from this sort of approach.

    Intelligent partitioning of your logic, and analyzing your flows, goes a long way towards solving problems. Focusing on the difficult cases does a disservice to the vast number of simple cases that don't have the problems you describe.

    \Roland Barcia\
    My publish and subscribe sample in the doc is an example where I feel messaging can increase performance as well, different scenario, but performant minded.
    \Roland Barcia\

    Understood. But please also understand that business needs can sometimes push you up against architectural performance limits, and when that happens it may be time to examine aggressive use of asynchronous techniques. The way I see it, the KISS principal is extremely valuable, but in part it means "avoid unnecessary complications", not "avoid complications". Sometimes, complexity is necessary to get what the customer needs.

    \Roland Barcia\
    WebSphere 5 Enterprise Edition has Asynchronous Beans that give the ability to create safe threads inside an EJB Container. I believe that there is a JSR out to address adding this type of functionality to the spec. This is an alternative to messaging for the type of multi-plexing requests you speak about.
    \Roland Barcia\

    Yes, Billy Newport mentioned this in another thread, and I'm very excited about it. I think its entirely proper that J2EE tries to take threading minutiae out of day to day enterprise development, but it's been unacceptable (to put it mildly) for the spec to ban it altogether. I hope IBM is pushing to get their Async Bean concept into J2EE at some point, because it's one of those areas where pure J2EE solutions still lag nastily behind other techniques. And as promising as Websphere 5 looks in general (compared to older Websphere versions and to the competition), it'd be really nice to have this feature generally available and not get locked into Websphere.

        -Mike
  12. Software Development
    July 2003
    An Asynchronous World By Gregor Hohpe

    <href>http://www.sdmagazine.com/documents/s=8269/sdm0307a/sdm0703a.html?temp=jAHfetQ3XA>

    Abstract:

    Online, you can get all the documentation you want on the Java Messaging Service API. But when it comes to drafting messaging architectures for distributed logic and data, it's often more interesting to look at what sits between the applications.
  13. Concurrent Handling Using MDB[ Go to top ]

    Hi,

    I saw your article published on TheServerSide.com about JMS Application Architectures. It is really good. But, I was expecting possible options of implementing synchronous request hitting multiple datasource(s) asynchronously and waiting for the response in one queue.

    My Approach:
    The possible approaches to get the response data are as follows in case of a synchronous request:

    a. we call the receive() method, which is a high CPU intensive process, since JMS server internally is pooling.

    b. To avoid this continuous polling at the listener, we can allow the listener to check for messages at pre-defined periodic intervals. This could be achieved by giving receive(1000).

    Regards,
    -C R Baradwaj
  14. I have seen JMS used for this and it can lead to some hairy scenarios. I am one for reducing the amount of polling done in my application code. The real need for this is the lack of being able to spawn off threads within the container. WebSphere Application Server 5 Enterprise Edition provides Async Beans that alow spawning off safe threads within a container and have the J2EE context propagate (Minus transactions). I think the spec is hard on this requirment. I think that they should allow applications to spawn threads much like Async beans if the EJB methods are marked as Never or Not Supports. Many of the problems arise with transactions. They should do it in such a way that the J2EE context gets propagated. I recomend using messaging to spawn the requests and storing the reply somewhere in some Hash and use the observer pattern to listen for whn the reply is complete. You still have to worry about clean up routines for timeouts.