eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
As Java Business Integration 1.0 failed to become the success its supporters hoped for, Sun Microsystems and some partners are working to try again.
Sun has proposed a new spec, Java Specification Request (JSR) 312, Java Business Integration 2.0 (JBI 2.0). In addition to Sun, which is the project lead, other organizations supporting JBI 2.0 include Borland Software Corp., Red Hat, webMethods, Pramati Technologies, TIBCO Software, the Apache Software Foundation, Adobe and Ionas LogicBlaze division, among others.
Sun instituted JBI 1.0 in 2005 and it ran into obstacles early on. IBM Corp. and BEA Systems Inc. initially pledged support, but then backed off.
Java Business Integration extends Java EE and Java SE with business integration SPIs (service provider interfaces). These SPIs enable the creation of a Java business integration environment for the creation of Composite Applications involving such technologies as BPEL (Business Process Execution Language), Rules, XSLT (Extensible Stylesheet Language Transformations) and existing Java implementations.
However, said one observer, who asked not to be identified: “JBI 1.0 was not ready for prime time; it focused on vendor needs and not the user, and has been a miserable failure. This is why you saw BEA and IBM, for instance, walk away and do SCA [Service Component Architecture]. If someone wants to write an ESB app today, it will not be portable to other ESBs. We think this is a horrible situation to put customers in, when SOA is about reusability, interoperability and flexibility.”
Mark Little, director of Standards and JBoss ESB (Enterprise Service Bus) Project Lead in Red Hats JBoss Division, said JBoss is interested in seeing JBI succeed because its customers are demanding it. So JBoss is involved in JBI 2.0, he said.
“The SCA shadow has fallen over JBI and Java EE as well, but hopefully we can bring it back to the forefront,” Little said. Little said JBI 1.0 suffered from bad timing. “It was a bit too early,” he said. “It got caught up in the Web services hype of 2005 when Web services was a big selling point of J2EE.”
Yet, JBI 2.0 will feature mechanisms to enable interoperability between vendors ESBs. “Its like EJB3 [Enterprise JavaBeans 3] for ESBs,” Little said.
Moreover, JBI 2.0 will feature attempts to build new bridges between JBI and SCA, Little said. “Its not a JBI versus SCA war at all,” Little said.
Projected new features in JBI 2 include enhancements to facilitate the use of JBI in clustered or distributed environments; enhancements to clarify and enhance the use of JBI in a SOA (service-oriented architecture) based approach to the creation, deployment and runtime support of Composite Applications; enhanced support for WS-Policy; enhancements to support Web 2.0 technologies and usage models; enhancements to facilitate performance optimizations by component and container implementers; improved alignment with Java EE, in particular the use of transactions; improved readability of the specification to clarify the needs of container, component and application developers; alignment with the SCA (Service Component Architecture) specifications with the goal of making JBI 2.0 a standard Java runtime for SCA; and enhancements to support full compatibility with OSGi (Open Services Gateway initiative), without necessarily requiring OSGi.
Little said Red Hat has an ESB and wants to bring its experience to others.
Moreover, “we dont have a JBI implementation at the moment, but its on our road map,” Little said. “Customers are asking us about it; theyre also asking us about SCA.”
“We have joined JBI V2, actually via the LogicBlaze guys, who already ship a JBI container that weve been using in Celtix,” said Eric Newcomer, chief technology officer at Iona Technologies, in Waltham, Mass. “We are also incorporating JBI into the Eclipse SOA Tools. I am expecting, or I should probably say we will be pushing for, a convergence between SCA and JBI such that services assembled using SCA metadata can be deployed into a JBI container.”
Ronald Ten-Hove, co-specification lead of JSR 312, said, “JSR 312 has been approved, and is now officially in the expert group formation stage of its life cycle. Well likely have the first meeting of the new expert group later this month, after JavaOne.” Meanwhile, BEA Systems, which rejected JBI early on, continues to buck the technology.
Ed Cobb, vice president of architecture & standards at BEA, in San Jose, Calif., said: “We remain unconvinced of the value of a Java-only solution for SOA. While JBI 1.0 targeted the integration of middleware components, it was marketed as an application-level solution, causing some confusion with our customers. Now that we have a real application-level solution on the horizon with SCA, a new JBI can only be viewed as a competitive alternative, especially after reading the list of objectives. BEA believes that the Java community will be better served with a multi-platform, multi-language SOA standard like SCA than anything that can be developed solely for Java. As such, we would prefer that a new JBI expert group not be formed.”
Steven Harris, vice president, Java Platform Group, Oracle Corp., in Redwood Shores, Calif., said Oracle is more firmly behind the SCA specification, but that he would like to see more common ground between SCA and JBI, and hopefully JBI 2 can deliver that.