JSR-208, Java Business Integration (or JBI), has passed the final ballot, with two abstentions from BEA and IBM. JBI is a specification that addresses standardization integration of services, with a preview available hosted on http://java.sun.com/.

All members of the executive committee voted "Yes," with the exceptions of BEA and IBM. BEA's comment on the abstention was:

BEA believes that the JBI specification is an incomplete attempt to standardize the interfaces between multi-vendor infrastructure and contributes little to the usefulness of the Java platform for business application integration, one of the real pain point for our customers. It's unfortunate that it's name alone will result in significant confusion in the marketplace.

IBM also believed the spec was "not a sufficient step forward."

However, companies such as TIBCO are banking on JSR-208 for the integration of service-oriented architectures for their "Hermes" project (due in 2006), for example. This product was described as follows: "Hermes reduces the cost and complexity of implementing and administering an enterprise-class SOA by giving developers a consistent but extensible way of deploying and managing home-grown and third-party services both independently and as part of composite applications."

This capability seemed directly tied to the use of JSR-208, which implies that JBI is a workable definition of a standardized SOA for Java.

What do you think? With IBM and BEA abstaining on many JSRs lately, often for the similar reasons as expressed in this JSR, is their abstention meaningful? Do you think you might be leveraging something like JSR-208?

Carlos has a good analysis of IBM and BEA's comments here...

http://www.manageability.org/blog/stuff/jbi-containers

I think JBI (JSR 208) is going to be a very important standard in the integration, ESB and EAI space and we are busy implementing an open source, Spring based JBI container and component suite called ServiceMix.

So far we've support for JMS, HTTP, SAAJ, WSIF, XSLT, Groovy/JSR 223 and Mule with much more to come...

James
LogicBlaze

Iona joined ObjectWeb and announced the Celtix project on June 21, 2005 (the news is stuck somewhere in TSS, for some reason...)

"Part of that core functionality in Celtix will be support for the recently introduced Java Business Integration (JBI) specification developed within the Java Community Process (JCP)."

"IONA anticipates that the community will deliver an initial release of Celtix by the end of 2005, providing the industry with an open source Java ESB that can help drive adoption of Service Oriented Architecture (SOA)-based projects and promote the incremental adoption of this computing methodology in the enterprise.

See: http://os3g.blogspot.com/2005/06/esb-initiative-welcomes-new-member.html
http://www.objectweb.org/phorum/read.php?f=25&i=199&t=199

I read the spec in May. I was pretty excited about it until I saw things like:

“WSDL-based Messaging Model”.

Honestly, can someone please just shoot WSDL and SOAP and get it over with? I mean it's hell. Shoot all of the WS-* specs. Just stop it – stop the madness. Its evil! Its wrong!

Also, the “Service Invocation and Message Exchange Patterns” are:
One-Way
Reliable One-Way
Request-Response
Request Optional-Response

What about pub/sub? Just how flipn' hard can we make RPC?

I also saw this in the “Future Directions” section:
•Distributed JBI. JBI, as currently defined, is not distributed. Distributed implementations may require support in the JBI specification to address issues that arise only in distributed systems.

Seems to me this should be the whole point? I mean how to tie these things together. Like JBI .. Java Business INTEGRATION ... Like distributed computing and stuff?

Perhaps I'm just a moron and don't get it. But, it just didn't smell right. Just seemed all coupled and weird to me.

I know its easy to say IBM and BEA just don't want to play, but neither of them has an ESB that is much of anything so I fail to see why they wouldn't jump on board. I think that they might just be right!

I have to agree with them.

I read the spec in May. I was pretty excited about it until I saw things like:“WSDL-based Messaging Model”.Honestly, can someone please just shoot WSDL and SOAP and get it over with? I mean it's hell. Shoot all of the WS-* specs. Just stop it – stop the madness. Its evil! Its wrong!

Relax :). The logical WSDL model is fine - that of services, interfaces, operations and bindings/endpoints. Seriously, there's nothing wrong with that. JBI just uses the logical model, its not bound to the pointy bracket stuff. e.g. JBI can work well with pure HTTP / JMS without all the SOAP/WSDL XML stuff. In ServiceMix we use JBI to route JMS messages across providers/destinations with message transformations etc. There's no reason that the JBI API and model can't work well for pure REST stuff too.

Also, the “Service Invocation and Message Exchange Patterns” are:One-WayReliable One-WayRequest-ResponseRequest Optional-ResponseWhat about pub/sub?

The JBI MEPs work just fine for JMS support and WS-Notification (the WS equivalent of pub-sub) which we use just fine in ServiceMix. So pub/sub works well in JBI.

Just how flipn' hard can we make RPC?

With bindings for reflection, WSIF, Axis and ActiveSOAP - RPC works just fine with JBI. I don't really grok your problem?

I also saw this in the “Future Directions” section:•Distributed JBI. JBI, as currently defined, is not distributed. Distributed implementations may require support in the JBI specification to address issues that arise only in distributed systems. Seems to me this should be the whole point? I mean how to tie these things together. Like JBI .. Java Business INTEGRATION ... Like distributed computing and stuff?Perhaps I'm just a moron and don't get it. But, it just didn't smell right. Just seemed all coupled and weird to me. I know its easy to say IBM and BEA just don't want to play, but neither of them has an ESB that is much of anything so I fail to see why they wouldn't jump on board. I think that they might just be right!I have to agree with them.

I wonder if taking a look at ServiceMix might help you grok JBI?

James
LogicBlaze

This entire discussion is focused on the need for the spec and how it seems not ready for prime time/is a rehash of other painful implementations. The whole point of having a spec like this should be to make life easier, not harder.

Bob brought up several points regarding what he saw as deficiencies in the spec and it seems the best answer given is, "Hey, look at my product." It's nice that you have a product, but that doesn't change the fact that the spec still has issues.

This entire discussion is focused on the need for the spec and how it seems not ready for prime time/is a rehash of other painful implementations. The whole point of having a spec like this should be to make life easier, not harder.Bob brought up several points regarding what he saw as deficiencies in the spec and it seems the best answer given is, "Hey, look at my product." It's nice that you have a product, but that doesn't change the fact that the spec still has issues.

Bob thinks the spec has issues (e.g. for pub/sub and RPC) which I don't think really are issues - its just a misunderstanding of the spec & how it maps to those technologies.

Sometimes seeing some code is the easiest way to explain how an API is meant to be used - so my point, which I obviously didn't explain too well - was that by looking at the source code of ServiceMix you can see how pub/sub, JMS and RPC can be used with the JBI specification.

i.e. I don't think the JBI specification has any problems working with JMS, pub/sub or RPC - if you don't believe me there's plenty of source code to read to see how it all fits together.

James
LogicBlaze

An important and necessary spec, but..

1. It requires components to implement standard interfaces

2. It requires xml deployment descriptors

3. It uses a special format jar archive as the unit of deployment.

Sounds familiar?

While the EJB world appears to have learnt from its mistakes and is moving away from imposing excessive constraints on EJB code, JBI appears not to have noticed.

Business logic/entities should be POJOs. Funny how the best open source projects realise this (eg ServiceMix), while as soon as you have a JSR, they straightaway want to tie developers hands.

Still, as I say it is important. May it flourish.

Kit

An important and necessary spec, but..1. It requires components to implement standard interfaces2. It requires xml deployment descriptors3. It uses a special format jar archive as the unit of deployment.Sounds familiar?While the EJB world appears to have learnt from its mistakes and is moving away from imposing excessive constraints on EJB code, JBI appears not to have noticed.Business logic/entities should be POJOs. Funny how the best open source projects realise this (eg ServiceMix), while as soon as you have a JSR, they straightaway want to tie developers hands.Still, as I say it is important. May it flourish.Kit

I totally agree - though I do think those 3 things are necessary for now. There does definitely need to be a deployment unit so folks can drop components inside a container - e.g. so a BPEL component can just drop right into any JBI container, just like a JMS provider's RARs can drop into any J2EE app server.

However I can also imagine JBI being used in regular Tomcat/Spring style deployments where the JBI components are wired together as part of a regular Spring configuration to avoid the need for a JBI specific deployment unit. e.g. see ServiceMix's Spring support

I'm sure in future versions of JBI we can further simplify the developers life using annotations and a more POJO approach like Spring/EJB3. In ServiceMix we support POJOs - though we currently expect developers to implement the ComponentLifecycle interface from JBI (which is a pretty simple interface - even simpler than servlets - it just provides the necessary hook to the POJO to be able to interact with the container and its lifecycle).

Considering how bad EJB 1 was (it took 3 versions to get anywhere near a good spec :) I think JBI is a great piece of work for a 1.0 - but for sure we can make it better in future versions.

James
LogicBlaze

I totally agree - though I do think those 3 things are necessary for now.

Possibly, though it might be seen as inviting developers to go down a route that could end up as a dead-end.

There does definitely need to be a deployment unit so folks can drop components inside a container - e.g. so a BPEL component can just drop right into any JBI container, just like a JMS provider's RARs can drop into any J2EE app server.

I would argue that RARs from a JMS provider have a very different role from business logic developed for internal consumption. The latter is more likely to be regularly revised. But in truth the deployment unit isn't my major gripe. It's the standard interfaces v POJOs thing.
  

However I can also imagine JBI being used in regular Tomcat/Spring style deployments where the JBI components are wired together as part of a regular Spring configuration to avoid the need for a JBI specific deployment unit. e.g. see ServiceMix's Spring supportI'm sure in future versions of JBI we can further simplify the developers life using annotations and a more POJO approach like Spring/EJB3. In ServiceMix we support POJOs - though we currently expect developers to implement the ComponentLifecycle interface from JBI (which is a pretty simple interface - even simpler than servlets - it just provides the necessary hook to the POJO to be able to interact with the container and its lifecycle).

Sounds great! even nicer (IMVHO) the ComponentLifecycle interface could be layered on top of my latest killer POJO using Springs aspects :)

Considering how bad EJB 1 was (it took 3 versions to get anywhere near a good spec :) I think JBI is a great piece of work for a 1.0 - but for sure we can make it better in future versions.JamesLogicBlaze

With my "Hypocrites-R-Us" hat on, I certainly doubt I could have done any better :) Good luck.

Kit

An important and necessary spec, but..1. It requires components to implement standard interfaces2. It requires xml deployment descriptors3. It uses a special format jar archive as the unit of deployment.Sounds familiar?While the EJB world appears to have learnt from its mistakes and is moving away from imposing excessive constraints on EJB code, JBI appears not to have noticed.

Ditto, I got extreme EJB flashbacks reading the spec (which I have done over a couple of times over the last few weeks).
Personally I think going down the route of mandatory implementation of specific interfaces etc is a step back from a lot of frameworks that allow components to be simple POJO's.

I don't quite see how anything can be "less standard" than just using POJO's..
However, that being said, I think JBI does have a lot of good concepts going for it to standardize how a service-container should be built.
If only the rough edges around creating and deploying Services can be shaved down it might be really great in the future (take away the interface-dependencies!!).

One clarification: the JBI spec/API/SPI is not targeted at application developers but instead container developers.

If you take the BPEL example, software vendors implementing a BPEL engine would implement the SPI under the cover. The application developer does NOT need to know about the JBI API. He only implements his BPEL process. As the BPEL engine interprets the BPEL process and calls out to the services defined in the BPEL process definition, the BPEL engine calls to JBI and delegates binding to the service to the JBI layer.

The same thing is would be true for transformation engines, rule engines or any other engine that you would plug into your environment.

Summary: if you are an application developer you should never see the JBI API. The only API you are exposed to is the WSDL of the service you are invoking or waiting a notification from and there again you should only care about the abstract definition (port and message type), NOT the binding.

Hope this helps,

Edwin Khodabakchian
Oracle
http://otn.oracle.com/bpel

Summary: if you are an application developer you should never see the JBI API. The only API you are exposed to is the WSDL of the service you are invoking or waiting a notification from and there again you should only care about the abstract definition (port and message type), NOT the binding.

And we all know how likely that is going to be.. :)

So what really is the benefit of JBI besides "vendor-independence" in an enterprise SOA scenario?
If application developers are not supposed to see the JBI API, it's not very likely JBI is supposed to be the Service Container of an organizations specific Services is it?

What is the purpose of JBI beyond "vendor-independence" from the viewpoint of an end-user organization? And what is the benefit of a JBI Service over a Service that drops in nicely into a J2EE container, has a clean WSDL interface and is exposed in a location transparent way?

The more I read up on this spec and the more I hear people talk about it, the more it sounds to me like useless bloat. Unless of course you call ticking the "JSR 208 compliant product/framework" box a "benefit" (a box which many, probably including myself will try to tick just to appease the "standards" hungry out there).

Ok, maybe overly tough words, JBI does have some really good and useful concepts that are worth looking into and keeping an eye on with that being said.
I am just trying to get a feel for the justification and benefit of it beyond "vendor independence" for BPEL engines etc..

Just as thinking aloud - I am wondering if the logical progression will be to have splintered applications connected via JBI that perform today's app server tasks.
JBI allows vendors to host their software as a service (one of the benifits). Would there be an opportunity for future application servers that are hosted on remote ASP locations to integrate millions of client web applications using JBI. Borrowing the Walmart store concept, can we envision a business model with few portals hosting zillions of web sites (think of products in Walmart Store), all connected via JBI to their parent applications. Does this model help BEA and IBM or the IT folks who want move their applications off to a third party ASP and have just the business processing modules hosted on their local systems? Isn't a third party ASP better suited to solve high availability/upgrade issues for all IT folks?
Disclaimer: I am not planning to start ASP business

Just been to a JavaOne talk about that stuff. If it is anything near the presentation, I'll stay away from it. After all, after about an hour, it was not clear what it is, what it has to do with Java, what it is good for, and why it is good.... Instead I now know that it requires WSDL (wonder why) and that it supports four trivial interaction formats. Whew. As Maggie Thatcher said: I want my money back!