activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <>
Subject Re: Mixing JMS and web apps
Date Sat, 22 Aug 2009 16:28:12 GMT
On Fri, Aug 21, 2009 at 5:17 PM, gonzus<> 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

> 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:

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

perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"

ActiveMQ in Action:

View raw message