Occasional Thoughts

People can talk. People can hear. But that does not mean that people do understand each other. If a French guy is talking to an British guy, the British guy can hear what the French guy is talking. But he does not understand it, when he doesn't know French (well, maybe he wouldn't understand the French guy even if he would have known French). Sounds logical, right? But apparently it was not logical for the designers of the JBI specification.
Enterprise Integration Using an Enterprise Service Bus

Our team was recently facing some integration issues and we didn't want to be tied to a single ESB implementation. An ESB (Enterprise Service Bus) is perfect for an n:m integration of SOA compliant services, i.e. you have several data sources that should be integrated with several data sinks at the same time. An integration is done, by configuring a data flow through different components that are deployed within that ESB. Each component has one or multiple input sources and an output source.. By chaining the components in a process flow, you can use standard components (e.g. EIP pattern components) as well as custom components that exchange messages to build a modular integration like Web Service Call -> XSLT Transformation -> Filtering -> Web Service Call.

However there is a big market of ESBs beginning from OpenSource implementations like ServiceMix or Mule to various big global players that cost big money. Almost each single implementation has its own components. Wouldn't it be nice, if you could simply implement an integration and deploy it on an ESB just like you would deploy a WAR file on a J2EE application server? Simply develop on JBoss Application Server and deploy it on an IBM WebSphere server with only minimal required changes? Luckily - we thought - there is a specification that unifies components of an ESB: JBI - Java Business Integration (JSR-208).

ServiceMix

As ServiceMix has been developed with JBI from the ground up, we started using it. ServiceMix does its Job pretty nice. It's OpenSource and is currently developed in the incubator of the Apache Foundation. You can't expect a nice and fancy graphical drag'n'drop UI (although there is an plugin for Eclipse available, which however is pretty limited) like it is provided by ESBs like the Oracle ESB or Sonic from Progress Software. But real developers are able to configure an application using XML files. And since it is released under the terms of the ASF you can deploy ServiceMix on a customers system with no extra costs.

JBI Talks Through Messages...

But the customer might already have paid for a high performance ESB solution. So using JBI we could simply deploy it on that commercial ESB...? Uhm... wait. Let's have a closer look on an very essential interface from the JBI spec: NormalizedMessage.

This interface describes the most important part of an ESB component: The message that contains the data, which is interchanged within two components (remember the French and the British guy talking with each other). You get that data by calling getContent(), which returns an object that implements the interface standard J2SE interface Source. So this instance of Source represents our data. Let's have a look on the interface Source. It implements just two methods: getSystemId() and setSystemId(String) that handle a unqiue system ID. There are just these two methods. Is someone missing something here? This object, we got using getContent() on the NormalizedMessage returns an implementation of Source which describes our data payload. But what do we have? We have a record set, that just describes the ID of an record, but no data at all.

...But JBI does not Understand

So ServiceMix provides it's own Source implementations and there are numerous of them, but every single implementation provides different methods for accessing its data payload. The ServiceMix Core component provides:

• ByteArrayDataSource - OutputStream getOutputStream()
• BytesSource - Byte[] getData()
• JavaSource - Object getObject()
• LazyDOMSource - Node getNode()
• ResourceSource - Reader getReader()
• StaxSource - numerous access methods.
• StringSource - String getText()
• XStreamSource - Object getObject()

Besides that it also uses other implementations like SAXSource or DOMSource from the W3C XML packages - of course with different data again. So what would you have to do, if you want to write a standard compliant component that accepts most of the sources? You have to check the implementation of Source using instanceOf and cast the data to its concrete implementation to be able to access the data. Loose coupling? Forget it!

Transforming Source Implementations Prevents Loose Coupling

ServiceMix provides the class SourceTransformer that is able to translate a StringSource, a SAXSource, a LazyDomSource and a StreamSource to a DOMSource for XML processing, but again we are limited to just a few implementations. And we are still only talking about ServiceMix. When you deploy the JBI component on a different ESB, there may be other implementations of Source as well. It's impossible to cover all kinds of sources in a component.

So, you might think that you could simply cast to a specific implementation, when you know, what type of normalized message comes in. E.g. you'll expect the XSLT Transformator component to always give you an DOMSource?

I did that and it worked until suddenly I got a ClassCastException at that point. Nothing changed in the code. Ouch! What happened? We migrated to a new version of ServiceMix and we had the message flow to be logged on a verbose level. All messages were logged into the log file, which is a good thing for development. However after each component ServiceMix took the output message of the previous component transformed it to an StringSource to write the string into the log file and passed the StringSource on to the my component. So I no longer got a DOMSource, but a StringSource. No changes in the implementation or the workflow, just a reconfiguration of the ESB.

Conclusion

So we have a French Component that knows how to communicate (using a NormalizedMessage) and the British component can hear it using getContent(). But then it has an unknown implementation of a message and is not able to extract the data from the message content.

Long story - short conclusion: JBI is useless.

As I've heard the guys at JBoss have noticed that and that's why they are ignoring JBI for the implementation of their own ESB. Especially because (as it was told to a colleague of mine at the JBoss World in Berlin) that a JBI 2 specification is on its way, which will be incompatible with JBI 1.0. I don't say that ServiceMix is a bad product just because of its JBI focus. But do yourself a favour and implement a lightweight component. These components provides wrappers for JBI and you just have to subclass an appropriate abstract implementation. Still you will have to face the problem with incompatible Source implementations though, but as long as you stay with XML data (which should be the most common case with an ESB in a SOA environment) you can use the SourceTransformator class to transform the Source implementation.

That said I must finally say that I love the Sonic ESB. A simple and elegant API to create custom components and well defined data structures - but expensive and proprietary. I can't wait until the JBoss ESB matures and becomes a solid product.