On Fri, Aug 21, 2009 at 5:17 PM, gonzus<gonzalo.dieth...@diethelm.org> wrote: > > 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?
Request/reply is a versatile style of messaging, but there are no guarantees about the timeliness of the reply. This is where a multi-phased approach would work best when using JMS with HTTP similar to what you describe below. > 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? This is a much better approach because it incorporates the use of the the multi-phased approach I mention above. That is, one phase for the HTTP request/reply, another phase for the back end system to handle JMS request/reply and another phase for HTTP request/reply. Ajax could be used for this type of thing and can work very well and provide extremely nice functionality for the user, but it's not a requirement. > 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. These are common dilemmas that developers face when developing in an environment that contains both synchronous and asynchronous technologies. My best recommendation is to take a look at the Enterprise Integration Patterns (EIP) book: http://enterpriseintegrationpatterns.com/ This book provides an excellent collection of messaging-based patterns for use when designing applications that make use of messaging/JMS. The website provides a good amount of content but the book contains even more. On a side note, Apache Camel provides a framework for integration that makes implementing the EIP patterns a breeze. Check it out if you're interested: http://camel.apache.org/ Bruce -- perl -e 'print unpack("u30","D0G)u8...@4vyy9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' ActiveMQ in Action: http://bit.ly/2je6cQ Blog: http://bruceblog.org/ Twitter: http://twitter.com/brucesnyder
