Thursday, February 21, 2008

Confused with JBI exchanges? Use the spec, Luke.

In a previous entry I mentioned my new found love of JBI. After my initial flirtations, my love has grown deeper: I believe that JBI and I are now something of an item. Hurrah!

I'd like to share something about my new relationship. At first, I had admired JBI from afar, and had hoped that I would be able to master JBI without having to go off and read the specification. In some respects this is true - you can build a Fuse ESB JBI-compliant solution entirely through configuration without any code, or without having to dig deep into JBI. This is good: after all, that Fuse ESB uses JBI internally should not be a concern to most users.

However, if you want to code up your own POJO then you need to get an understanding of how your code should interact with JBI's Normalised Message Router (NMR) for different message exchange paradigms (e.g. in-only, on-only-robust, in-out). Implementing an in-only provider? Your code should set the status of the exchange to DONE, and then send the exchange back to the NMR. Doing in-out? Your code should set a response, leave the status alone, send the exchange back to the NMR, and then expect to receive a DONE exchange later on.

For new users accustomed to simple RPC approaches this feels a little strange, confusing, and perhaps a little frustrating. I empathise: if it's an "in-only" message exchange, then why does my code have to send back the exchange? If it's an "in-out" message exchange, and my code has returned a response, then why should I subsequently receive a notification that the exchange is done?

I urge you though to resolve the awkward silence by looking to the JBI 1.0 specification - it's remarkably readable, and the sections on the NMR provide some real insight on what the JBI container expects of you. With these insights in place you can do some great stuff. The answers, by the way to the questions above concern the decoupling in time of the consumer from the provider, and providing support for reliability in the underlying message exchange.

Thursday, February 14, 2008

Fuse ESB and JBI, my new-found loves...

I've having the pleasure of working with Ashwin Karpe on producing some training material on JBI, in particular the Fuse ESB implementation of JBI based on Apache ServiceMix. I first looked into JBI a few years ago back when Apache CXF was Celtix and we were all a lot younger. Back then, I just couldn't see the point of JBI: whenever someone would try and explain it to me they would attempt to explain something I didn't know (JBI) in terms of something I still didn't know (Binding Components (BCs), Service Engines (SEs), Normalized Message Router (NMR) etc.). My eyes would gloss over, and I'd go back to what I was doing previously.

My eyes where opened when I got a play with the great set of JBI components in FUSE ESB. Using FUSE, I can create listeners (for example HTTP, JMS, FTP, FILE) and wire them using enterprise integration patterns (like filters, transformers and content-based routers) into some sweet integration flows, sending data on to other systems (again using transport components like HTTP, JMS, FTP and FILE). Now, that's something tangible that I know I can use when I'm out on the road. Just recently, a guy I know asked me about creating an FTP plugin for CXF to accept CSV (comma separated value) payload: maybe a year or two ago I would have tried to find a way to do that, now, I'd just do it using Fuse ESB.

Most of what you do with FUSE ESB/ServiceMix can be done by simply customising (via configuration) the transport components and patterns that are provided in the box. Occasionally though you may want to write a POJO that sits in your integration flow: I'm currently looking into writing a chapter in our training material on how to wire POJO's (i.e. JBI's MessageExchangeListeners) into a flow.

In the meantime, for anyone interested in playing with JBI, take a look at the documentation on and Tom Purcell's blog, which has some interesting entries on JBI from a beginner's perspective.