On Sat, Aug 22, 2009 at 10:51 AM, gonzus<gonzalo.dieth...@diethelm.org> wrote: > > > bsnyder wrote: >> >> 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 >> [the workflow approach] you describe below. >> >> [snip] >> >> This [workflow approach] is a much better approach because it incorporates >> the use of 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. >> > > Ok, so I am not totally misguided here. Do you know of any frameworks or > examples exploring this workflow approach?
Unfortunately there are no pre-built solutions for such an approach. Every one I've seen or worked on was built from the ground up and was specific for the business. > bsnyder wrote: >> >> 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 its way from Amazon as we speak... > > > bsnyder wrote: >> >> 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/ >> > > What is exactly the relationship between ActiveMQ and Camel? I see the > ActiveMQ distribution includes Camel. Is is a required or optional part? When Camel was created it was a subproject of ActiveMQ. Since that time, it was grown far beyond just ActiveMQ so it is now it's own project at the ASF. Camel is completely optional in ActiveMQ, it is not required. > Can you point me to a good set of examples, or a real life application, > showing how to use Camel for this (workflow thing) and other requirements? There are examples that come with Camel and some docs on the website, but none of them explore the type of thing that you're seeking to build because it's typically a complex solution whose requirements are commonly very specific to a given business. FWIW, there's also a book being written about Camel right now, too. It just got started at Manning. > Wait a minute... I have just realized you are one of the authors of the > (upcoming) ActiveMQ in Action book. Delighted to meet you. I am not going to > badger you with any questions, but please do feel free to share any > information you have about its final availability... ;-) Yep, that's me. We're not planning to have the book out until probably January. Unfortunately our work schedules have prohibited a dedicated effort to the book. But we're still very actively working on it and making MEAP releases available as we go. 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
