Java Business Integration JSR 208 recently passed the JCP public review ballot, with all companies voting yes, except for IBM and BEA who abstained.

JBI is not an interface for developers; rather, it’s an architecture and set of interfaces for providers of integration products to integrate with each other within a JBI container. As a result, people will be able to assemble an integration solution they need assembling all the parts they need. For example, you could (in theory) assemble an infrastructure from a BPEL engine, an EJB Container or a data transformation product and know that they will all integrate properly. It also standardizes the packaging and deployment unit for an application built on top of these products. Interestingly, JBI's spec looks a lot like a specification of an ESB, or a loosely coupled micro-kernel, effectively making a JBI container into a SOA container. Spec lead Ron Ten-Hove was recently interviewed about what JBI is and what it means for J2EE developers.

JBI could mean great things for the integration market. In a press release, Mark Bauhaus, vice president of Java, Web Services explained:

The goal of the Java Business Integration initiative is to do for the integration space what J2EE did for the field of Java application development and deployment; namely, deliver the benefits of choice, flexibility, interoperability, code reuse, reduced complexity, and lower cost.

However, BEA and IBM both abstained from the public ballot, with IBM commenting that "we are not yet convinced that this specification will deliver compelling value to the marketplace."

TSS interviewed a number of players for their perspectives. Original JBI specification lead Mark Hapner and Chief Web Services Strategist at Sun said:

BEA and IBM abstained for more or less the same reasons they left the EG. They don't have any strong objections to what the EG has produced they just have their individual reasons for not being interested in it.

It was good that JBI has passed this milestone. The spec is quickly maturing and with that the community is finally starting to get their arms around what JBI is actually delivering. It is becoming clearer that industry requires better support for composite services as the unit of deployment to ESBs. I think that JBI is in the right place at the right time to offer industry a standard for the packaging, deployment and operation of composite services. While JBI is mainly focused on the Java Platform it is useful to note that its core concept of composite services is platform independent.

Principal J2EE Appserver Director at Oracle Dennis MacNeil said:

The JBI specification provides a Java based integration environment based on open industry standards. This gives Java developers the ability to build services that are truly interoperable and will foster growth in the ecosystem of third party integration providers.

JBoss' lead on jBPM and expert group on JSR 208 Tom Baeyens said:

The spec is very similar to JBoss' microkernel architecture, but positioned on the integration/SOA level. That is why we see potential synergies. It is still too early to see if the outcome of JBI will have an added value over the individual building blocks such as webservices, messaging and other containers.

IBM and BEA would not respond for comment. What do you think? Will JBI really do for the integration market what J2EE did for the enterprise development market?

I would love to have a business integration standard. In my work on building and testing services it would be great if I could look at an XML document that identifies the workflow from one service to the next. I could transform that workflow definition into a unit test. I could then run the unit test multiple times concurrently as a load and scalability test. I could even run the test periodically as a quality of service monitor. I could even put the workflow definition out for bid to a service provider.

We're so close! BPEL, BPEL4WS, BPEL4J, JBI... We've even seen implementations like Collaxa that were sooo close!

Yet, here we are with only Sun promoting JBI. What hope is there when IBM and BEA abstain.

-Frank "The Frustrated One" Cohen
http://www.pushtotest.com

A little off topic, but as long as we're stitching technologies together. Does anyone have a good Java based data transformation engine that they like? Specifically I'm looking to go from a number of text formats to XML.

Free is nice, but not a requirement.

Thanks,
Jim

A little off topic, but as long as we're stitching technologies together. Does anyone have a good Java based data transformation engine that they like? Specifically I'm looking to go from a number of text formats to XML.

Free is nice, but not a requirement.

Thanks,
Jim

Hey Jim,
Plug for the software we write: Symphonia. It can transform EDI, HL7, EDIFACT, X12 and so forth to and from each other and XML.

http://support.symphonia3.com

You can create your own message format definitions for CSV or other custom message formats.

Jim,
   Try CapeClear 6 - it provides dev tools for defining tranformations (XML<->XML|Text|Excel etc.) and a Web Services container that will execute them for you.

Oh, and since this thread is talking about JBI, it fully supports BPEL too.

I'm currently evaluating Itemfield (http://www.itemfield.com) as a transformation engine to go from MS Word, PowerPoint, Acrobat and others to XML. I'm impressed with their sales team, their solution is expensive, and thorough.

-Frank

Frank,

The fact that IBM and BEA are abstaining does not make us so far. That the heart of it, JBI is a WSDL binding framework, a kind of WSIF on steroids. It is something a server needs to be able to publish the same service using multiple bindings: SOAP but also JCA, JMS, etc.

The fact that IBM and BEA do not support JBI means that services deployed to those containers have less flexibility as to what binding they expose (although to be fair, IBM uses extensively WSIF delivery the value of WSIF for request-reply message exchange patterns).

Conclusion: JBI is great because is make WSDL messaging with pluggeable binding a first class citizen of J2EE. The fact that IBM and BEA are abstaining means that there customer loose a little bit of flexibility but it does not mean that services can not interoperate.

Note: for your specific business, it means unfortunately that you will need in the short term to support 2 binding frameworks: WSIF and JBI. It should however be rather easy to create a common abstraction on top of those framework for basis request-response message exchange patterns.

Cheers,

Edwin

Note: The new home of the Collaxa BPEL server:
http://otn.oracle.com/bpel

Hi Edwin: Thanks for the reply post. I'm looking for the Web Services stack to grow up. It's got to be more than a simple RPC mechanism. I'd like to see the industry take some positive steps like coming together on new standards. This move seems to show fracturing. I suspect the result will be even more integration work for Java engineers - and while that may make some boat payments for some of us is doesn't make the world any more efficient at handling its information.

To your comment about supporting 2 binding frameworks... how do you define "short"?

-Frank

We're so close! BPEL, BPEL4WS, BPEL4J, JBI...

I agree. We're so close, I can taste it.

I haven't had a detailed look at the spec but one question beered in my mind
once having a brief overview, JBI plug-in components interact to the JBI core through WSDL,
Thats's good to provide an abstract and technology-netural model, but In case of a
java plug-in that if we want to interact directly to JBI core through a binary protocol
for getting more perfomance , does JBI provide this kind of interaction?

Alireza

JBI doesn't provide this kind of interaction. The point is that JBI not only defines a new standard, it is also based on standards like WSDL, XML, JMX etc. The choice of XML as the interface between JBI components seems natural and binary (or even proprietary) protocol access to the JBI core doesn't look like the right idea. This is key if JBI is to counteract the "vendor lock-in" problem in current integration projects.

(Of course it is possible to build a binding component that transforms a given binary wire format to XML and then hands it to the JBI NMR for further routing and processing)

Armin

I'm not surprised IBM & BEA abstained, they are both in the process of releasing their own Service Oriented Architectures.

I just went to a small seminar called WebSphere for Financial Services in the London - they had Marc-Thomas Schmidt (their MQ/Workflow architect) plugging IBM's SOA. IBM were pushing SOA's hard at corporate CEO's, and wanted CEO's to be asking CTO's for SOA's (even though CEO's might not know what they were).

Despite IBM saying they followed standards IBM only mentioned BPEL as a conformant standard. Perhaps a vote for the standard would mean their products were instantly non-compliant.

The last economic cycle saw persistent/ORM standards developing and (now) converging. IBM (et.al) see Enterprise Intergration Architectures / Enterprise Message Buses to be the next technical battle ground over the next economic cycle.

IBM were also pushing their 'Accelerator' toolsets for different aspects of development, (i.e. Human=Portlet, Process=Workflow, Information=ORM), eventually based on Eclipse. The basic premise was these aspects formed the basis of Model Driven Architectures and that MDA's would shut the gap between business and technology. IBM strongly believe that MDA tools and standards will reduce programmer head count and increase productivity. And that's interesting because IBM's strategy is to move into the same solution space as IT outsourcing; though when I put that to a few IBM 'ers after the seminar they hadn't realised it.

Despite IBM saying they followed standards IBM only mentioned BPEL as a conformant standard. Perhaps a vote for the standard would mean their products were instantly non-compliant. The last economic cycle saw persistent/ORM standards developing and (now) converging. IBM (et.al) see Enterprise Intergration Architectures / Enterprise Message Buses to be the next technical battle ground over the next economic cycle.

Robin,

BPEL and JBI have nothing in common - they are orthogonal to each other. Looks like people are somewhat confused about that. JBI will perfectly work with BPEL engines plugged in as Service Engines.

To me it appears that this confusion on the one hand results from statements made by IBM earlier (see http://www.adtmag.com/article.asp?id=10168) and on the other hand by the name:

Java Business Integration isn't a very good name for JSR-208. JBI has nothing to do with business nor does it solve a single business problem. Instead JBI is specifying and standardizing a common infrastructure for integration (and for SOA of course). I understand the spec in the way that it provides a standardization of ESB technology.

Armin

Best read this article. It appears the 'heavyweights' (IBM,BEA,MS,TIBCO) have produced their own standard (WS-RM) for Web Services. This kind of ties in the BPEL which MS is also pushing.

http://www.informationweek.com/story/showArticle.jhtml?articleID=160911590&tid=5979

P.S. I realise BPEL is orthogonal - that was just the only standard they mentioned.

I just skimmed through the spec. I know the spec is still 1.0, however, it explicitly doesn't address the following -

- Distributed Transactions (2PC)
- Security
- Distributed architecture - to support geographically distributed deployments
- Lack of support for Work Manager ( a key feature in tuning product environments)

In other words, any implementation based on 1.0 - will not necessary be enterprise-class? Perhaps, this is common, but spec seems to lag significantly compared to several commercial products in this space.

With Tibco & IBM products being out there for years, it seems integration applications in most of the companies have become legacy applications. I have worked with so many companies and every big company has succesful working integartion setup in place. Products from companies like Tibco, IBM, WebMethods etc. seems to have satisfied the needs of industry starting late nineties. In fact, JMS & Webservices products have taken up the space which could not be filled up by big integration product suppliers in last few years. Compared to other Sun initiatives, JBI seems to be quite late and as there is no pressing need in industry to have one or more products based on new specifications.
Offcourse, by having Tibco, Sonic, WebMethods on board give little assurance that this specs may take integration in standardization direction, absence of IBM shows higher probability of its failure.

Very Good analysis. Do you think other integration players like Tibco, Sonic, WebMethods,etc. are trying to catch up with IBM and BEA SOA momentum through JBI. Because IBM has put so much money into SOA how can you really compete without doing that really? e.g have you seen their WebSphere Process Server, Websphere Integration Developer? it's really something.

Trying to figure out the scope of JBI. There is not much information related to how components are wired together (to composite service out of components) in the spec, or did I missed something.

Say if I need to insert/plug a transformer component in between an service consumer and a service provider, how do I do that? Is ESB suppose to do that? Or the NMR referred to in the spec is actually an ESB.