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 open.iona.com and Tom Purcell's blog, which has some interesting entries on JBI from a beginner's perspective.
Thursday, February 14, 2008
Subscribe to:
Post Comments (Atom)
2 comments:
Is JBI all still about XML? I have no problem with XML at consumer or provider endpoint, if they want it, but is really necessary to have the normalise message in XML? This gives up a load of performance in the micro-Orchestration for the sake of the macro-Orchestration which just helps the intergration tool builders. Even hardware acceleration will be pushed to process a 5K XML message, at the same speed as 0.5K binary message, through multiple processing steps. Or maybe there is a performance cap or more complex multi-channel architecture we have to accept in a completely XML world towards which we are heading.
Is JBI all still about XML?
XML is fundamentally at the heart of JBI; everything on the NMR is an XML message. Of course, you can transmit non XML payload (e.g. binary, or plain text) as MIME attachments to the message, so you don't take on an XML hit there; only on the format of the message itself.
Post a Comment