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.