Every now and again I get into a discussions about why I decided not to adopt JBI for Mule. Admittedly, the topic has cropped up less and less over the past 2 years since people realize that just because something is called a standard doesn’t make it the best solution. However, now and again there is a die-hard fan that is there to push JBI as the only way. It’s been a few years since I read the JBI specification, but here goes.
When JBI (Java Business Integration a.k.a. JSR-208) first started cropping up it generated some interest since it was an attempt to standardize an area of application development where there were a lot of moving parts and complex problems to solve. Of course I looked at the spec early on since Mule was a platform that operating in the integration/ESB space.
My initial reaction was mixed since I felt there was scope for standardization in integration but the scope of JBI seemed to intrude into the problem space much further than was required. Integration problems are varied, complex and different for every organization because the technologies, infrastructure and custom applications in organizations are always different. Furthermore, they are immutable. This is a key point since many proprietary integration solutions (EAI brokers, ESBs, SOA suites) assume that an organization is either creating a green-field application or can rip-and-replace pieces of their infrastructure to make way for the Vendor X way of doing things.
Mule was designed around the philosophy of “Adaptive Integration”. What this means for Mule users is that they can build best-of-bread integration solutions because they can choose which technologies to plug together with Mule. It also means that they can leverage existing technology investment by utilizing middleware that was purchased in the past from other vendors. When talking about integration or SOA I think the piece with the most value is the glue between systems. With that said it is vitally important that this glue is as flexible as possible in order to be useful for a wide range of integration and SOA scenarios. This is one area I think JBI went wrong.
JBI attempts to standardize the container that hosts services, the binding between services, the interactions between services, and how services and bindings are loaded. It sounds like a great idea, right? 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. These assumptions manifest themselves as restrictions, which as we know is very bad for integration. These assumptions include –
- Xml messages will be used for moving data around. For some systems this is true, but for most legacy systems, Xml didn’t exist when they were built and they use a variety of message types such as Cobol CopyBook, CSV, binary records, custom flat files, etc.
- Data Transformation is always XML-based. Transformation is hugely important for integration, so to assume all transforms will be XML and use the standard javax.xml.Transform library was a huge limitation.
- Service contracts will be WSDL. This might seem like a fair assumption, but again it’s very XML-centric and WS-centric too. We know that back and middle office integration is no place for Web Services. What about other ways of defining service contracts such as Java Annotations, WADL or Java interfaces?
- No need for message streaming. There is no easy way to stream messages in JBI. It just wasn’t a consideration. Some vendors have worked around the API to support streaming, but that defeats the purpose of having an API.
- You need to implement a pretty heavy API to implement a service. This means the guys writing your services need to understand more about JBI than is necessary. Mule has always believed that services can be any object such as a POJO, EJB Session bean or proxy to another component. This means it does not force developers to know anything about Mule logic, only write logic relevant to the business problem at hand. It’s worth noting that vendors have also found workarounds in JBI to allow developers to deploy POJO services, but it quickly starts looking like JBI is working against them.
- It’s not actually that clear what a service engine is in JBI. JBI seems like a container of containers, but what about services? Do I need to host an EJB container inside JBI and then have an EJB Session bean as my service? Do I write a service engine per service? It seems both may be valid, but I never thought either were optimal.
There are other issues as well. The JBI specification is obfuscated with lots of new jargon. For a new developer they sheer amount of knowledge required to get started with JBI is a little overwhelming. This could be said for any middleware but I think JBI is one of the worst for new developers to grasp.
The JBI specification does talk about roles of the different types of users that will interact with a JBI system. This is a good approach, but in reality it was difficult to understand primarily because it seems JBI was designed without really thinking about how the developer would work with it. Why? Well, when you get a load of vendors (though not Oracle or BEA) to sit around and design an integration system, they will design a system around the way they see the world. This is exactly what vendors did before JBI too, and we were often not happy with the products we were given. JBI seems to be a “standard” written by middleware vendors for middleware vendors.
This “vendor view” of the world is one of the main reasons Open source has done so well. Traditionally, Open Source has been written by developers much closer to the problem being tackled. These developers can deliver a better way of solving the problem using their domain knowledge, experience and the need for something better. This was the ultimate goal Mule and given the success of the project I believe that goal has been realized with the caveat that things can always be improved (which we continue to do).
Also I think the far-reaching scope of JBI affects its re-usability across vendors. By their nature, vendors need to differentiate themselves in order to compete. Because JBI attempts to define how everything should work vendors have to build in features and workarounds that go beyond the specification to differentiate their service container. 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.
This leads me to my final point, which is that one of the big selling points of JBI and standards in general is to promote re-use. But I don’t think we’ve seen much re-use from JBI. Where is the library of Service Engines and Binding Components? I know Sun have started porting their J-Way connectors to JBI, but nobody supports them. 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.
One thing that concerns me about the JCP is that when something is released through this process people label the resulting work a standard. This is a little strange to me since I think of a standard as something that is defined when the problem domain being addressed is fully understood. For example, TCP/IP is a real standard because it states a well-defined protocol for exchanging information over a network. Its scope is very clear, the protocol is precise and it deals with a single problem. JMS on the other hand is not really a standard, it’s a standard API defined ultimately by two vendors (IBM and TIBCO) who made sure that the standard suited their needs. Not necessarily the needs of Java messaging. This is why JMS seems to have some quirks to it and the API is heavy (though improved in JMS 1.1).
The fact that JCR-312 is called JBI 2.0 not JBI 1.1 means that the forces behind JBI 1.0 realize the flaws and are looking to make amends. To all those that badgered me in the past about adopting JBI in Mule may now retract some of their overzealous statements since JBI 1.0 already looking obsolete. I am glad I did not pollute Mule with JBI.
I had some good conversations with Peter Walker (co-lead) about joining the expert group for JSR-312. I appreciated the community spirit of Peter reaching out but I felt the direction wasn’t compelling enough. It seemed to be going in a similar direction. We talked about OSGi and SCA support and that these may be weaved into the specification. While I think this is a good idea I don’t think it’s up to a standards committee to define how to build a server. Again, the scope seemed too broad.
So, should we just give up? No, of course not. But I think we should re-align our sights to target the particular areas that make sense to be standardized. From my experience there are two areas that would make sense to standardize; configuration and connectors. This is because these are the pieces that either the user or other systems need to interact with.
Service Component Architecture (SCA) addresses the XML configuration piece and I do think this is a step in the right direction (I’d like to see the same done for programmatic configuration). The issue with SCA right now is people still think it’s a bit Web Services centric and the configuration is quite verbose. Another major issue is that SCA hasn’t received the adoption required to be a front-runner.
On the Connectors front we do have , but anyone who’s read the JCA spec may wonder how on earth a bunch of smart people could come up with such a recalcitrant API.
I’d like to see a compelling connector architecture come out of the JCP process. Focusing on this specific area may promote middleware vendors and other independent software houses to build re-usable connectors that we could all use.