Thursday, March 26, 2009

The new JMS flow in ServiceMix 4

I wandered down to the hotel bar last night and bumped into Guillaume Nodet; we got chatting about the new support for JMS flows in ServiceMix 4. I've written about JMS / JCA flows in a previous blog entry, arguing that, if not correctly configured, they can lead to far too much distribution and a consequent impact on performance. Back then, I argued that using explicit JMS queues - through ActiveMQ or whatever JMS broker you want - can provide just as effective a mechanism for distribution, message persistence, reliability and location transparency.

The latest stuff in SMX4 introduces some new stuff that makes me feel a lot happier about the concept of implementing the NMR with a JMS flow. First, if you want a JBI endpoint to be clustered, you have to explicitly mark it as clustered. This I like, as it gives the developer/designer back control of where the distribution points are in a flow. Second, the JBI flow now uses a single distributed queue for clustering. Previously in ServiceMix 3 a seperate queue was created for each JBI endpoint using the JMS flow; the new approach means less queues and less threads required to support the JMS flow. Different JBI endpoints will listen off the "NMR" queue using optimized message selectors to ensure that messages get consumed by the correct target services. Third, you can now optimize the JBI messaging layer to omit the use of JBI DONE messages: so, if you're implementing a one-way interaction over the JMS flow, you don't end up having to deal with an DONE that you simply don't need. Finally, Guillaume has made a cleaner separation between the JMS flow and the underlying JMS transport. So, you can use ActiveMQ if you want, or, alternatively, plug in another JMS broker to handle your JBI traffic.

I'm looking forward to playing with this, and perhaps documenting these new features. One clear point is that if you've made use of JMS flows in your architecture for ServiceMix 3, then you'll have that same support in ServiceMix 4, with just a little tweaking of configuration.

Good work, Guillaume! And, thanks again for the sandwich!

8 comments:

Ashwin Karpe said...

Nice article Ade...

It gives a good insight into the reasons for the design choice and how the new implementation of JMS flow will work.

Kudos to Guillaume for a stellar solution. Very nice indeed.

nedpepper said...

Yes ... great article and a really an essential feature in Servicemix 4. However, if you look at the Servicemix or FUSE forums, it appears that no one has been able to get it working.

Rather than continue to spew out the hype, I challenge anyone of the Servicemix 4.x commiters to post a complete, working example of this.

Ade said...

Hi Nedpepper,

Thanks for the feedback! However, please don't accuse me of hype; I hate that. In fact, I've spoken *against* JBI and JBI clustering on this blog in the past. And, if you check out the article at http://trenaman.blogspot.com/2010/04/four-things-you-need-to-know-about-new.html, you'll see that I have indeed got the clustering working; there are however some tricky and non-obvious things you need to do to make it work.

nedpepper said...

Ade,

By 'hype' I simply mean ' ... here is how this feature should work' vs. proof (show me the code). Servicemix 4 has a huge amount of potential. But for guys who don't have alot of hours to burn trying to deliver a solution, useful examples are everything. I

Would you consider posting the complete code and configuration of your working example to go along with your article? That would be a tremendous help. Does your example demonstrate networked Servicemix instances (not simply in-VM clustering)?

Thanks!

Ade said...

Here ya go! Have posted the code up at the FUSESource FUSE ESB forum http://fusesource.com/forums/thread.jspa?threadID=1933. I haven't added configuration, but the tips at http://trenaman.blogspot.com/2010/04/four-things-you-need-to-know-about-new.html should be enough. Let me know how you get on!

Cheers,
Ade.

vinod said...

Hi Ade,
I am a follower of your blog articles, and I have benefited many times out of your articles. Recently I read abt the overhead of JMS and JCA flow and you recommended SEDA flow. I find it tough to convince others for SEDA flow, as we loose the HA and fail over capability. Also we are finding tough time making JMS flow alone to work. It gives some "Content not allowed in prolog" error. we are using servicemix 3. Pls advise

vinod said...

Hi Ade,
I am a follower of your blog articles, and I have benefited many times out of your articles. Recently I read abt the overhead of JMS and JCA flow and you recommended SEDA flow. I find it tough to convince others for SEDA flow, as we loose the HA and fail over capability. Also we are finding tough time making JMS flow alone to work. It gives some "Content not allowed in prolog" error. we are using servicemix 3. Pls advise

Ade said...

Hi Vinod! I still believe that you can get HA and Load Balancing in your system without the need for the classic NMR JMS and JCA flows. I recommend using Camel routes for the integration, and putting JMS queues between each route to ensure that messages are either processed successfully or replayed.

As for your XML content not allowed in prolog error, I've seen this kind of thing before: it's usually that the payload in the JBI message isn't valid XML. Can you send a reproducible test case to the servicemix users list? Alternatively, you could post a message on the forums at fusesource.com.