Let's say I have a pure JMS-based application, that implements business logic by integrating decoupled components through messaging, with all the advantages this entails. These applications are triggered by incoming payloads (say, files that get dropped into specific folders).
I would also like to have web apps as front-ends for this system. These apps would mostly be used for querying "state" for the system, but might also trigger functionality, whether by creating a file in the proper directory or by crafting messages in the appropriate queues or topics. I wish to avoid the usage of J2EE (EJBs, etc.) and use pure web apps in a web container. There seems to be a big disconnect between the JMS-based system (asynchronous) and the web apps (synchronous), which I assume is nothing new for anyone in the trade. My question is: are there practices, patterns, tricks of the trade or suggestions for bridging these two worlds? I can think of a couple: 1. Use the Request / Reply pattern: a user's click on a web app triggers a request from the web container and the reply becomes an answer to be displayed back in the browser. But what happens if the reply takes a long time and you don't want the user's interaction to timeout? 2. Model the web apps with a "workflow" philosophy, where any action requested by the user only triggers a request that is assigned the initial status of "pending"; then, all these request are shown to the user in a list, which is updated somehow (asynchronously) in order to alert the user when a given request is finished. But would this require some form of AJAX? These are just ideas. I am trying to get suggestions or pointers for how other people have approached this use case. Thanks in advance and best regards. -- View this message in context: http://www.nabble.com/Mixing-JMS-and-web-apps-tp25088779p25088779.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
