The Road to JBI: Paved with Good Intentions

Java Development News:

The Road to JBI: Paved with Good Intentions

By Ross Mason

01 Jul 2008 |

The increasing adoption of SOA principles and integration/ESB technologies also encompasses efforts to create standards around various aspects of SOA (e.g., JMS for messaging and transport, WS-* for communication via Web Services, etc.). While standards are good for IT in general, not all standards are created equal. The standards creation process can often fall victim to competing vendor factions, or can result in a Frankenstein of compromises. Good or bad, it is ultimately user adoption that proves to be the final arbiter of the standard’s success.

JBI (aka Java Business Integration or JSR-208) was developed as a standardized way to implement an enterprise service bus (ESB). Released in August of 2005, there were many positive intentions around the creation of JBI, including:

  • Attempting to standardize an area of application development where there is a lot of moving parts and complex problems to solve
  • Delineating roles of different users that interact with a JBI system
  • Promoting the reuse of non-core components to save overall development and maintenance costs

However, since then, the standard has created some controversy in the industry, with somewhat lackluster vendor adoption. Why hasn’t there been a more definitive move in the industry towards adopting the JBI standard? What are some of the areas where JBI falls short?

JBI is no TCP/IP

A standard is 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.

The fact is, integration problems are different for every organization because the technologies, infrastructure and custom applications in organizations are always different. Furthermore, they are almost always immutable to some degree. This is a key point, since many proprietary integration solutions (EAI brokers, ESBs, SOA suites) incorrectly 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 particular vendor’s way of doing things.

JBI seems to be a paper tiger of sorts – a “standard” written by middleware vendors for middleware vendors. In general, JBI intrudes into the problem space much further than was required. It meets vendor needs at the expense of developers. This “vendor view” to integration is one of the main reasons open source alternatives have flourished (more on that later) and JBI has floundered.

While there is scope for standardization in integration, JBI misses the mark - JBI is no TCP/IP.

Restrictions are Bad for Integration

When talking about integration, 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 where 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. On the surface, all of this sounds like a great idea. The problem occurs when the APIs around all these elements make 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 most legacy systems built before the arrival of XML 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. The JBI specification assumes that all transformations will be performed using the Java XML transformation framework. This is a huge limitation.
  • Service contracts will be WSDL. A fair assumption at first, but this XML-centric and WS-centric view is troublesome. As an example, enterprise back- and middle-office integration is no place for Web Services, given the typical performance and scalability demands. In addition this assumption neglects other ways of defining service contracts, such as Java Annotations, WADL and Java interfaces.
  • No need for message streaming. There is no easy way to stream messages in JBI – the requirement was simply not built into the standard. Some vendors have worked around the API to support streaming, but this approach defeats the purpose of having an API.

The Myth of Component Re-use

One of the big selling points of JBI is lowered development costs through standardized component re-use. However, there has been very limited re-use yielded from JBI efforts to date. For example, there is currently no common library of Service Engines and Binding Components for this standard. Sun has started porting their J-Way connectors to JBI, but no vendors support them yet. Each vendor adopting the JBI specification has written their own JMS, FILE, HTTP, FTP, etc. Binding Components.

The far-reaching scope of JBI affects its re-usability across vendors. By nature, vendors need to differentiate themselves in order to compete. Because JBI attempts to prescriptively define how everything should work, vendors are forced to build in features and workarounds that go beyond the specification to differentiate their service container. This behavior breaks the re-use value proposition, since using a JBI Binding Component in one container doesn’t mean it will behave the same way, or even work in another container.

Is Standardization Futile?

Although JBI may have missed the standardization mark, it does not mean that there is no room for standardization in integration and SOA. Rather than the JBI “catch all” approach to integration, the industry should re-align its sights to target the particular areas that make sense to be standardized: configuration and connectors. Why? These are the pieces at the edge that either the user or other systems need to interact with.

Addressing the XML configuration piece, Service Component Architecture (SCA) seems to be a step in the right direction. However, the standard may still not be ready for prime-time, as some people deem it to be a bit too Web Services-centric, and the configuration is overly verbose. Moreover, SCA has not yet received the adoption required for it to be a front-runner.

A compelling connector architecture has yet to come out of the Java Community Process (JCP). Focusing on this specific area may promote middleware vendors and other independent software houses to build re-usable connectors that everyone could use.

Savvy developers understand that standards mandating rigid approaches to problems with infinite variables – like integration - can introduce even worse complexity and lock-in than proprietary vendor architectures. That outcome is contrary to the overall spirit of standardization – which should be maximum freedom of choice for end users.

About the Author

Ross Mason is Co-founder and CTO of MuleSource, Inc., the creators of the open source Mule integration platform. Ross founded the Mule project in 2003 and strived to make it the leading Java-based ESB and integration platform. Mule is used by top-tier financial institutions such as CitiGroup, JP Morgan and Deutsche Bank, as well as many other high profile enterprises, including American Airlines, Adobe and Scripps Networks. Prior to founding MuleSource, he was Chief Executive Officer of SymphonySoft Limited, an EU-based company providing services and support for large-scale integration projects.