Is JBI so bad?
Ross Mason, the CTO of MuleSource, recently started a discussion about JBI.
His first point is that JBI is no TCP/IP, meaning somehow that JBI is targeted at vendors and not at developers. Well, I'm not sure about the TCP/IP thingy, but he's a bit right about JBI being targeted at vendors and not developers. Why? If you have some knowledge about JBI, you know that there are multiple JBI components (bindings that handle a particular protocol such as HTML, JMS, etc... and engines that provides business logic such as a rules engine, a BPEL engine and so on). The developer will mostly see those components, not the JBI APIs: if you work with a BPEL engine and write a process, you won't see the JBI APIs surface in the BPEL at all. If you write a WSDL to define a SOAP/HTTP service, you won't really see JBI there either. So, yes, at some point, he is right that JBI 1.0 hasn't focused on the developer, or I should say, the user. Because if you need a custom component for your JBI container, you, as a developer, will need to dive into JBI and fully understand it. At this point, if you don't use JBI, you'd have to dive into a proprietary set of APIs to write your component. JBI aims to be mostly hidden for the users.
His second point is about some of the restrictions in JBI 1.0, mainly the use of XML, WSDL and no support for streaming. About XML, JBI has ways to convey binary data in non XML formats using attachments (don't you use attachments in your emails?). About WSDL, this point seems a bit weird since MuleSource has a product named Galaxy which is a registry of services described by WSDLs. Everyone knows WSDL is the standard for describing services. Anyway, the JBI specification says each endpoint has to be described by a WSDL, however, since the early days of ServiceMix, WSDL has not been a requirement and you can deploy your endpoints without any WSDL at all. With respect to data streaming, I'm not sure to understand the supposed flaw of JBI here: in the JBI world, a message contains an XML payload (which can be a stream, a DOM document or any kind of XML representation) and a set of attachments (which can also be streams). Just leveraging these APIs, JBI components are able to transfer very large amount of data using streams only.
His third point is about component reuse in JBI. We have users using ServiceMix components inside OpenESB and others using OpenESB components inside ServiceMix. It's true that most of the JBI vendors offer their own set of components. Let me ask the question: doesn't Mule come with its own set of transports? It would not make sense at all to distribute an ESB without any support for the most commonly used transports. It does not mean that these components can not work together.
Last comes some points about the existing standards. Since a long time, I don't think SCA should be viewed as a competitor to JBI. For some reasons exposed above, JBI does not really target the end users, while SCA does. However, SCA does not allow components to interoperate together. Hence, those two standards are complementary, not competitors.
All in all, I think JBI is a good specification. It does not address all the possible use cases in the best way (I'm thinking about handling non XML data) and sometimes goes beyong what should have been required (on the packaging and deployment side), but the core messaging APIs are well defined, and given the success of ServiceMix, I'm far from thinking that JBI should be dismissed.
His first point is that JBI is no TCP/IP, meaning somehow that JBI is targeted at vendors and not at developers. Well, I'm not sure about the TCP/IP thingy, but he's a bit right about JBI being targeted at vendors and not developers. Why? If you have some knowledge about JBI, you know that there are multiple JBI components (bindings that handle a particular protocol such as HTML, JMS, etc... and engines that provides business logic such as a rules engine, a BPEL engine and so on). The developer will mostly see those components, not the JBI APIs: if you work with a BPEL engine and write a process, you won't see the JBI APIs surface in the BPEL at all. If you write a WSDL to define a SOAP/HTTP service, you won't really see JBI there either. So, yes, at some point, he is right that JBI 1.0 hasn't focused on the developer, or I should say, the user. Because if you need a custom component for your JBI container, you, as a developer, will need to dive into JBI and fully understand it. At this point, if you don't use JBI, you'd have to dive into a proprietary set of APIs to write your component. JBI aims to be mostly hidden for the users.
His second point is about some of the restrictions in JBI 1.0, mainly the use of XML, WSDL and no support for streaming. About XML, JBI has ways to convey binary data in non XML formats using attachments (don't you use attachments in your emails?). About WSDL, this point seems a bit weird since MuleSource has a product named Galaxy which is a registry of services described by WSDLs. Everyone knows WSDL is the standard for describing services. Anyway, the JBI specification says each endpoint has to be described by a WSDL, however, since the early days of ServiceMix, WSDL has not been a requirement and you can deploy your endpoints without any WSDL at all. With respect to data streaming, I'm not sure to understand the supposed flaw of JBI here: in the JBI world, a message contains an XML payload (which can be a stream, a DOM document or any kind of XML representation) and a set of attachments (which can also be streams). Just leveraging these APIs, JBI components are able to transfer very large amount of data using streams only.
His third point is about component reuse in JBI. We have users using ServiceMix components inside OpenESB and others using OpenESB components inside ServiceMix. It's true that most of the JBI vendors offer their own set of components. Let me ask the question: doesn't Mule come with its own set of transports? It would not make sense at all to distribute an ESB without any support for the most commonly used transports. It does not mean that these components can not work together.
Last comes some points about the existing standards. Since a long time, I don't think SCA should be viewed as a competitor to JBI. For some reasons exposed above, JBI does not really target the end users, while SCA does. However, SCA does not allow components to interoperate together. Hence, those two standards are complementary, not competitors.
All in all, I think JBI is a good specification. It does not address all the possible use cases in the best way (I'm thinking about handling non XML data) and sometimes goes beyong what should have been required (on the packaging and deployment side), but the core messaging APIs are well defined, and given the success of ServiceMix, I'm far from thinking that JBI should be dismissed.
Comments
I think your remarks on Ross's article are very solid. JBI components can be exchanged between different JBI containers (I used a PEtALS and Open ESB JBI component in ServiceMix). That's shows the potential of the JBI specification.
I really find both approaches, the JBI and the Mule architecture, viable for solving integration problems. I think Mule does a great job in solving integration problems where messages can be POJOs and where there's a need for custom logic in Javabeans. ServiceMix or JBI in general does a great job in environments where you predominantly use XML messages and you need hotdeploy functionality and an open standard implementation. So I see implementations for both approaches :-).
Best regards,
Tijs Rademakers
Author of Open Source ESBs in Action