Reply: JBI Misses the Mark by Ross Mason
I would like to reply to Ross Mason's article titled JBI Misses the Mark. It was too hard to include this in a comment, so I decided to post my reply here.
Ross,
As a JBI Component Developer and user of ServiceMix and OpenESB I am going to try my best to give some answers to your points with the goal of discussion and not persuasion. I am not a "die-hard" fan trying to push JBI adoption. So hopefully I will come off as unbiased and honest as possible.
"It’s been a few years since I read the JBI specification, but here goes."
As evidence by the different ways JBI was implemented by Apache and Sun, just reading the spec alone I think is not sufficient to disregard JBI. For example, I remember when I first read the spec and looked at ServiceMix, I was totally confused. I was asking myself, where are all the WSDLs? Most of the comments I have read from JBI opponents have usually just read the spec or heard from co-workers and have actually never used or seen JBI used. Now I am not saying this person is you Ross; you have obviously done your homework. I believe the biggest failure of JBI has been communicating clearly what JBI is and how to use it. It took me many months until I felt like I actually "understood" JBI. And before that moment happened I thought I knew what JBI was only to find out something new and that I never actually did.
"Adaptive Integration"
Unless I misunderstood it, your definition of Adaptive Integration fits well with my experience with JBI. Using JBI I can build "best-of-breed" integration solutions using any number of the JBI components available with ServiceMix (SM) or OpenESB (OESB). If I need to integrate with JDBC I can do that; or RSS, XMPP, SIP, Corba, and CICS. Perhaps my lack of knowledge of Mule capabilities is making me naive here, but to me I can use JBI to bridge multiple systems together.
"JBI attempts to standardize the container that hosts services, the binding between services, the interactions between services, and how services and bindings are loaded. The problem occurs when the APIs around all these things makes assumptions about how data is passed around, how a service will expose its interface contract and how people will write services."
In a nutshell the only thing I think JBI standardizes on is the interactions between components or put another way the format of a message that goes over the NMR. Beyond that its up to the component developers to do what they wish. For example, with the RSS BC, there are no assumptions that need to be made about incoming requests from the NMR; it's a standard JBI message. Doesn't matter if it came from a SIP, HTTP, Corba. To me that is the beauty of JBI. Once I create my JBI layer in my component anybody in the container can call me.
"Xml messages will be used for moving data around"
As stated above, JBI doesn't say if your legacy system doesn't know XML, then you can't use JBI. The exact opposite is true. To me this is the perfect fit for JBI and Binding Components. My definition of a Binding Component is a translator. It's sole job is to translate protocol X to JBI and translate JBI to protocol X. Perhaps what you are suggesting is that some message types don't "convert" easily to XML since that is what essentially messages over the NMR are. So in your example, a Cobol CopyBook message can't be or shouldn't be attempted to be converted to XML. Not sure I would agree since I would think, given a schema, anything could be represented in predictable XML.
"Data Transformation is always XML-based"
Since everything is converted to XML to be passed over the NMR, the only transformation needed for that is XML. So what you is true, but to a JBI user I guess it doesn't matter. I guess on the other side, if the NMR allowed for other message types, then yes I guess you would need more transformers, but I guess with JBI the transformers are the Binding Components.
"Service contracts will be WSDL"
This is a very true statement and I am not exactly a WSDL/XML lover; unless I don't have to deal with it. I think the original intent was there would be a lot of tooling support for JBI to alleviate that burden from the JBI user. To me Sun has done a better job of this than SM, but this is definitely a drawback to JBI. However SM has all but eliminated WSDL's in JBI so users of SM don't need tooling support since they don't actually require WSDLs.
"No need for message streaming"
Another very true statement of there not being an "easy way to stream messages in JBI". With XML being so verbose I believe SM or OESB would probably dislike a 3 MB XML file getting pumped through it. Especially if that gets copied over and over again from one component to the next. This is where JBI might have difficulties scaling. As a colleague pointed out, the content of a JBI message is XML. And that XML has to be marshalled and unmarshalled. And that process is very heavy and even more so if there are reliability/durability constraints on the Message.
However, I think its a current tradeoff in order for all components on the NMR to communicate in a predictable fashion. Since that is the main concept of JBI: the ability for all the JBI components communicate. They have to communicate some how. One component can't decide that he expects format A and another decides he requires format B. Then nothing would work. So it sounds like to me XML was that language to guarantee interoperability between components.
On a side note, JBI components have the ability to set the content of a JBI message that goes on the NMR as anything implementing the interface javax.xml.transform.Source. Meaning that they can use streaming XML with the SAX and Streaming implementations. However, once consumed, that stream is gone and is probably represented as DOM (ouch) somewhere in the process. Our components use the Streaming impl when creating JBI Messages, but that doesn't mean the others do.
Either way, I have to think that smart people like Peter Walker, yourself, and other spec leaders can't come up with something to resolve this and get the best of both worlds.
"You need to implement a pretty heavy API to implement a service"
I disagree that JBI users have to know more about JBI than is necessary, but then again its hard for me to play that person since I am also a component developer. But most of the people that I have taught how to use JBI have been successful in using it without having to know as much as me. I know in SM you can expose a POJO pretty easily. In OESB you can use the Scripting Engine or create an EJB Service to be used in JBI. From what it sounds like though, its much easier with Mule.
Again I have not had a hard time teaching non JBI users about JBI. However I skip the spec and jump straight to a demonstration of how you can use JBI. This seems to help. I remember the first video I watched when the light bulb finally went off. It was a video on how to use the Sun SMTP BC and creating a Service Assembly with Netbeans. After I watched that video everything just came together for me and my co-workers. This is basically how I start off explaining JBI: It's best explained with an example rather than a bulleted powerpoint.
"It’s not actually that clear what a service engine is in JBI."
Touche. I hear this a lot, even from me. Again, as I stated earlier, the JBI community has done a poor job of training and communicating to its users and developers. My first definition of a Service Engine was basically a Service. I still don't have a good definition of an SE; usually I will just talk about what existing SEs are out there like the BPEL and XSLT SE. To me Binding Components are easy to define so an SE is just everything else (granted not exactly the best definition).
"The JBI specification is obfuscated with lots of new jargon"
Yes, yes, and yes. Again poor job of communicating. However, the JBI user should not be concerned with most of this jargon; only the JBI developer. For example, the JBI user shouldn't need to know about what the NMR is or what it does; but it's important for JBI developers to know.
"This breaks the re-use story since, if I use a JBI Binding Component in one container doesn’t mean it will behave the same way in another container."
Ideally JBI was suppose to be this loving community of predictable containers and components. Unfortunately that hasn't exactly happened. I will say this though, from my personal experience of using different components on different containers, for the most part most components and Service Assemblies work in a predictable way on other containers. For example, I have successfully used many SM components in OESB and and I have heard of Sun components working in SM. However the failure is you can't intermix Sun and SM components (or at least from what I know). For example, you can't use the SM HTTP BC with the Sun BPEL SE. To me this wasn't a failure of JBI; only how the JBI container was implemented. In a perfect world this would have happened but it hasn't.
Ironically it actually doesn't take that much to get your components to work on both SM and OESB. Of the four components we have written (RSS, SIP, XMPP, and UDDI), XMPP has been modified to work on both. We haven't had a chance to ensure the other 3 can, but hopefully we can get to that or the open source community could help. At the time of development we didn't actually understand JBI that well and consequently when we had our components originally working in SM and tried to port them over to OESB, they worked but only with other SM components. In order for our components to work with Sun components we had to basically rewrite the JBI layer. Unfortunately, due to time constraints it was not our current goal to keep backwards compatibility with SM. It wasn't until after we finished all this that we actually understood JBI and what it meant to create a portable component.
"If you look at every JBI implementation each has written their own JMS, FILE, HTTP, FTP etc Binding components… not exactly what I’d call re-use."
You are exactly right. Each container has implemented their own components for File, JMS, HTTP. Most likely because of the issues I mentioned above. However I don't think this doesn't mean JBI can get there. If these projects wanted to make them portable than we wouldn't have this problem. Instead they focus their efforts on other things.
As a side note, since my group was using OESB, when I joined a new group, we needed to get OESB working on JBoss. This currently was not supported and my previous group was able to work with Sun to get this working and its currently being incorporated in OESB.
Summary
IMHO I think a lot of assumptions where made about JBI, but you also addressed some of the issues with JBI. One reason I think JBI has not been adopted is the fact that it didn't have the backing early on of IBM and Bea. From what I recall they dropped out pretty early once they realized it was going to be a competing product. Another reason for a lack of adoption is I think again the lack of communicating what JBI really is.
I hope I didn't reiterate responses you have heard in the past. I wasn't around when JBI was originally approved, so I don't know a lot of the history. These are just my opinions I have collected through developing components and using SM and OESB.
I hope it helps and I look forward to your response.
