Java One 2005 had a very heavy emphasis on JSR-208, Java Business Integration. However, he says, "there seemed to be some folks with confused looks on their faces in some JBI talks." As a response, he's written a blog entry on what JBI actually is.

My brief take on JBI is that its a simple API to a Normalized Message Service and Router along with a component and management model for deploying integration services such as routing engines, BPEL engines, rule systems, transformation engines etc.

JBI provides a logical XML messaging network which maps well to HTTP, email and JMS/MOM while easily adapting to legacy systems, binary transports and RPC systems like EJB and CORBA. Think of it as the next logical abstraction above JMS, with support for different message exchanges (one way, request response etc).

James works on ServiceMix, a JBI implementation, so it's safe to say he has some idea of what he's talking about. However, despite the vendor emphasis, it's worth asking what JBI means to the average developer. James addresses that question with this:

Sure most application developers will still end up writing POJO services and dropping them into their container and exposing them as web services - so often they won't need to use the JBI APIs directly; but for integration companies like ourselves, it provides a way for middleware and integration vendors and OSS projects to work together at the ESB level.

What do you think? Don Box, in "Looking for a Clue" and other posts, has wondered how a JBI container differs from an EJB container. (He was answered by Eric Newcomer, in "JBI Debate." It's a pity that Mr. Box's blog doesn't support trackback well, or at least that it wasn't used in this case.)

It's clear that JBI is getting a lot of attention and causing a good amount of confusion as well. Do you think the JBI standard is a good one? Is it a necessary one? What does it mean to you?

JBI is as bad as it was the first release of entity EJB.

It seems many people do not get/buy it
which tells me "maybe" there is something wrong with it.
Webservice technology is little different...everybody gets it but nobody knows why they should use it.. :)
yet another "mate" (MArketable TEchnology) to help sell more..

"It seems many people do not get/buy it
which tells me "maybe" there is something wrong with it."

On the contrary, enterprise and distributed technologies are beyond comprehension of the masses; just discuss JBI as a JSP tag and everyone will get it!

Perhaps, someone will create a drag and drop JBI component soon and make it an Eclipse plug-in...

JBI is as bad as it was the first release of entity EJB.It seems many people do not get/buy it which tells me "maybe" there is something wrong with it.Webservice technology is little different...everybody gets it but nobody knows why they should use it.. :)yet another "mate" (MArketable TEchnology) to help sell more..

Hmm... I'm not sure where the confusion comes in, although there were some obviously confused questions being asked after the JBI session I attended... I found JBI to be refreshingly straightforward and well thought out. I love the separation between Service Engines and Bindings. Any of you who've had to write FTP utilities for passing files back and forth for integration know what I mean... I'd much rather use someone else's FTP/EDI/etc. code.

I was a bit confused about the difference between the routing in the JBI normalized message bus and the orchestration going on with BPEL, but it was only a 50 minute session...

I was a bit confused about the difference between the routing in the JBI normalized message bus and the orchestration going on with BPEL, but it was only a 50 minute session...

The ESB, in addition to providing transformations from a schema perspective, abstracts discrete services from both a location and transport/technology perspective (MOM, WS, SSB, etc). A BPEL implementation could then be used to orchestrate/aggregate/choreogrraph such services into a business process. This process can, in turn, be exposed as a service as well.

JBI looks like an attempt to create yet another standard for helping integrate standards.
 
Can someone explain why

1) JBI choose to define yet another standard for
   Component development when JCA has most of the
   design principals - both from invocation standpoint
   and deployment model standpoint.

   Shouldn't we have extended JCA for JBI (to include
   Normalized messaging concept) - rather than defining
   yet another standard with 80% overlap and a few
   extensions?

   This would have allowed direct integration of all the
   100's of JCA connectors already available (and well
   tested) in market. And direct access to Tons of IDE
   features built to accelerate JCA component development.

2) JBI choose to define a Container and instantiation
   model (and will end up with transaction context,
   resource sharing, securit context handling API's)
   Isn't this awful lot of repeatition of what a JCA
   container do?

   Note that JCA container is NOT same as complete
   J2EE container and has no relation to EJBs whatsoever.

Thanks,
Amit Gupta

I came across some high level thoughts on that from members of the expert group.

http://www.iona.com/blogs/newcomer/archives/000182.html

1) JBI choose to define yet another standard for    Component development when JCA has most of the   design principals - both from invocation standpoint   and deployment model standpoint.   Shouldn't we have extended JCA for JBI (to include   Normalized messaging concept) - rather than defining   yet another standard with 80% overlap and a few    extensions?

That would had probably required IBM and BEA to participate ;)

2) JBI choose to define a Container and instantiation   model (and will end up with transaction context,   resource sharing, securit context handling API's)   Isn't this awful lot of repeatition of what a JCA   container do?   Note that JCA container is NOT same as complete   J2EE container and has no relation to EJBs whatsoever.

I believe JCA connectors require an EJB container for servicing inbound calls. Vendors have implemented proprietary extensions for such connectors to work outside the scope of an EJB container though.

It would make sense to simplify connectivity!

I believe JCA connectors require an EJB container for servicing inbound calls. Vendors have implemented proprietary extensions for such connectors to work outside the scope of an EJB container though.It would make sense to simplify connectivity!

I don't think so. JCA 1.5 components are "most commonly" deployed to invoke MDB, but there is nothing in the specific which limits it to this. One can easily take the JMS events generated by JCA 1.5 components and tie them to other Components - without introducing ANY NEW proprietry (or even Standard :-) ) interface.

Thanks,
Amit Gupta

I believe JCA connectors require an EJB container for servicing inbound calls. Vendors have implemented proprietary extensions for such connectors to work outside the scope of an EJB container though.It would make sense to simplify connectivity!

I don't think so. JCA 1.5 components are "most commonly" deployed to invoke MDB, but there is nothing in the specific which limits it to this. One can easily take the JMS events generated by JCA 1.5 components and tie them to other Components - without introducing ANY NEW proprietry (or even Standard :-) ) interface.Thanks,Amit Gupta

I quite agree that JCA rocks. Though I think for various reasons (mostly political rather than technical), it was good to get JBI 1.0 out without being dependent on J2EE/JCA. The JBI <-> JCA integration specification can come next - either in JBI 1.1 or a new JSR. I also hope it comes out soon !:)

James
LogicBlaze

1) JBI choose to define yet another standard for
   Component development when JCA has most of the
   design principals - both from invocation standpoint
   and deployment model standpoint.

EXACTLY...thank you Amit. I was looking for someplace to ask this question or make the point and you've made it for me. ESB was interesting, but it seems that sun has taken something seemingly simple and easy to grasp and clobbed it into J2EE. Then as you've pointed out, it seems familiar, like something we've seen before...JCA.

Taylor

Nothing against SOAP or WS, but in attending the JBI presentations, I became very aware of the differences between agreeing and accomodating.

Seems like a spec for the sake of having a spec to me, I fail to see the endgame other than shelling out money. When you start abstracting something that's already an abstraction (like JMS), it's gone too far and you are simply adding complexity. The last thing the java community needs is more container/deployment complexity. JBI simply adds more nodes and configuration files to the overall architecture, something we should be moving away from.

I know, I've got a new spec that will even one up this, it's the JAA - The java abstraction abstraction. Abstract any Java API through the JAA container and a handy set of 32 Interfaces, which by the way, my company will be the first to market with in hopes that IBM buys me. Hip-hip horray, that's progress!

my company will be the first to market with in hopes that IBM buys me. Hip-hip horray, that's progress!

Hehehe...

I'd like to contribute to JAA

Seems like a spec for the sake of having a spec to me, I fail to see the endgame other than shelling out money. When you start abstracting something that's already an abstraction (like JMS), it's gone too far and you are simply adding complexity.

There's the rub. JMS doesn't map too well to things like CORBA, EJB, HTTP or talking to web service endpoints over HTTP.

JMS rocks for what its designed for, a standard Java API to messaging systems. However something more abstract and with an XML/WS feel and richer message exchange patterns is required for integration type solutions where you're talking to MOM, HTTP, email, EJB, CORBA and legacy stuff. e.g. take a look at the stuff Iona have been doing, mapping tons of legacy systems to JBI. The problem of trying it with JMS would be leaky abstractions. JBI is trying to integrate many different systems together; whether MOM or Java or C or COBOL.

The last thing the java community needs is more container/deployment complexity.

Relax, you don't have to use it :). As an application developer stick to Spring or EJB3. JBI is mostly for folks in the integration / EAI / SOA space to help wire stuff together with BPEL, content based routers, rules engines, transformation engines and protocol adaptors etc.

JBI simply adds more nodes and configuration files to the overall architecture, something we should be moving away from.I know, I've got a new spec that will even one up this, it's the JAA - The java abstraction abstraction. Abstract any Java API through the JAA container and a handy set of 32 Interfaces,

If its a Java API, then try reflection or just Spring remoting :)

which by the way, my company will be the first to market with in hopes that IBM buys me. Hip-hip horray, that's progress!

Shh don't tell anyone, you might start a bidding war :)

James
LogicBlaze

Relax, you don't have to use it :). As an application developer stick to Spring or EJB3. JBI is mostly for folks in the integration / EAI / SOA space to help wire stuff together with BPEL, content based routers, rules engines, transformation engines and protocol adaptors etc.

If we're talking EAI & SOA why not go with a more generic standards approach such as this one:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

There's the rub. JMS doesn't map too well to things like CORBA, EJB, HTTP or talking to web service endpoints over HTTP. JMS rocks for what its designed for, a standard Java API to messaging systems. However something more abstract and with an XML/WS feel and richer message exchange patterns is required for integration type solutions where you're talking to MOM, HTTP, email, EJB, CORBA and legacy stuff. e.g. take a look at the stuff Iona have been doing, mapping tons of legacy systems to JBI. The problem of trying it with JMS would be leaky abstractions. JBI is trying to integrate many different systems together; whether MOM or Java or C or COBOL.

On the contrary, the messaging system *is* the abstraction. Most JMS providers allow direct publishing of HTTP messages and things like CORBA clients and EJBs can push messages to an abstract, declarative JMS end-point. They don't really care how the message is digested or by who, they simply care that the message was reliably published nor do they require an awareness of delivery channels, message exchange factories, etc. This can be easily implemented in JMS without a new deployment format or container leveraging existing investment. ESBs play nicely in this niche without the need for additional standards or containers and provide the same exchange patterns of JBI by leveraging the capabilities of the existing messaging bus.

IBMs abstention sums it up well "the JBI specification doesn't represent a sufficient step forward in terms of what we believe our customers need, and above what they can already do."

Relax, you don't have to use it :). As an application developer stick to Spring or EJB3. JBI is mostly for folks in the integration / EAI / SOA space to help wire stuff together with BPEL, content based routers, rules engines, transformation engines and protocol adaptors etc.

This is exactly the space I play in, not sure why you made the application developer reference. I advise my clients to simplify their architectures whenever possible, complexity is cost for an enterprise and JBI is complexity. It inserts yet another app server into the mix and in the case of legacy systems, forces them to be exposed through that app server as SEs (sorry, I don't really see a way to make my email server comply with the interface contracts required by a BC).

I also find it funny that you throw BPEL in there. IMHO JBI is repeating many of the mistakes of workflow architectures/engines namely instituting additional (often single) points of failure by centralizing the service coordination and endpoints in a single container at the same time adding verbosity where simple configuration is sufficient.

Earlier, you reference Steve Vinoski's blog that has a similar disconnect. He says that some of the mistakes of late 90s' EAI were overhead of translation to canonical formats and the misunderstanding that Java can't "solve it all". Yet, the JBI spec is heavily dependent on WS and WSDL which are by nature verbose and canonical and at the same time forces services to communicate through a Java-heavy standard.

Whew, rant done. One round of XML-RPC for everyone, I'm buying!

There's the rub. JMS doesn't map too well to things like CORBA, EJB, HTTP or talking to web service endpoints over HTTP. JMS rocks for what its designed for, a standard Java API to messaging systems. However something more abstract and with an XML/WS feel and richer message exchange patterns is required for integration type solutions where you're talking to MOM, HTTP, email, EJB, CORBA and legacy stuff. e.g. take a look at the stuff Iona have been doing, mapping tons of legacy systems to JBI. The problem of trying it with JMS would be leaky abstractions. JBI is trying to integrate many different systems together; whether MOM or Java or C or COBOL.

On the contrary, the messaging system *is* the abstraction. Most JMS providers allow direct publishing of HTTP messages and things like CORBA clients and EJBs can push messages to an abstract, declarative JMS end-point. They don't really care how the message is digested or by who, they simply care that the message was reliably published nor do they require an awareness of delivery channels, message exchange factories, etc. This can be easily implemented in JMS without a new deployment format or container leveraging existing investment. ESBs play nicely in this niche without the need for additional standards or containers and provide the same exchange patterns of JBI by leveraging the capabilities of the existing messaging bus.

I absolutely agree that JMS is very useful - folks have been using JMS and MOM for years to build SOAs and loosely coupled architectures. JBI does not replace JMS at all but work with it. With JBI glasses on, imagine JBI as the glue between your JMS provider, your encoding protocol (SOAP 1.1 in a BytesMessage? or REST in a TextMessage?) and your integration services (content based routing, orchestration, rules, transformations etc).

JBI is intended as an API for ESB container developers and ESB component developers to use which is similar in many ways to JMS but its more abstract and higher level and suitable to many other communication protocols other than just JMS.

JMS is quite complex in comparison to JBI's simpler normalised messaging model. JMS can be quite a tricky to implement correctly and pass the TCK tests (tell me about it, we work on ActiveMQ :) - whereas the JBI model is pretty simple from the NMS side of things; its easy to bind to email or HTTP or whatever.

So while JBI's messaging model is very similar to JMS, its much simpler and handles one way and request-response exchanges more easily.

Relax, you don't have to use it :). As an application developer stick to Spring or EJB3. JBI is mostly for folks in the integration / EAI / SOA space to help wire stuff together with BPEL, content based routers, rules engines, transformation engines and protocol adaptors etc.

This is exactly the space I play in, not sure why you made the application developer reference. I advise my clients to simplify their architectures whenever possible, complexity is cost for an enterprise and JBI is complexity.

Thats good advice

 It inserts yet another app server into the mix and in the case of legacy systems, forces them to be exposed through that app server as SEs (sorry, I don't really see a way to make my email server comply with the interface contracts required by a BC).

Most legacy systems would be exposed as a web service I'd have thought. No need to write an SE or BC per se. Though some integration developer might wrap up the legacy system as a BC if there was no web service adaptor, to make the service easier to use inside an ESB - but its not a requirement.

It shouldn't matter how you expose a legacy system; as a CORBA, EJB, XML-over-HTTP, POJO or Web Service, a JBI container should be able to work with it. Its just JBI provides a standard API to allow folks to develop other bindings too.

Indeed I'd say its the ESB's responsibility to figure out how to connect with your legacy system, with whatever APIs and protocols available, rather than that of you or your customer. Though if you want, JBI provides a plugin you can write for your ESB. Maybe another way to think about it is - its a bit like WSIF, but a bit more pluggable and more useful on the server side (like in an ESB).

 I also find it funny that you throw BPEL in there.

Orchestration is just one aspect of the integration problem space. There are many others; load balancing, content based routing, transformation services, rules engines, BAM etc. Its just one example of an integration service that you'd want your ESB to work with.

IMHO JBI is repeating many of the mistakes of workflow architectures/engines namely instituting additional (often single) points of failure by centralizing the service coordination and endpoints in a single container at the same time adding verbosity where simple configuration is sufficient.

How can an API dictate deployment architectures? There's no reason why a JBI container couldn't be deployed inside a SOAP stack on the client or server side to handle mediation with external transports and protocols. e.g. ServiceMix is lightweight and pretty easy to embed.

Earlier, you reference Steve Vinoski's blog that has a similar disconnect. He says that some of the mistakes of late 90s' EAI were overhead of translation to canonical formats and the misunderstanding that Java can't "solve it all". Yet, the JBI spec is heavily dependent on WS and WSDL

JBI assumes an XML service bus and follows the logical model of WSDL. So JBI is designed to work well with WS and WSDL stuff, but equally well with XML over HTTP or XML over JMS or even text & binary data formats over proprietary transport protocols & file polling etc.

which are by nature verbose and canonical and at the same time forces services to communicate through a Java-heavy standard.Whew, rant done. One round of XML-RPC for everyone, I'm buying!

LOL :)

James
LogicBlaze

As much as I’d like to see a spec for ESBs, this ain’t it IMHO.

James I actually surprised you are all hemped up on this thing. I am a big fan of ActiveMQ – you guys are doing a great job on that. You must see something I don’t.

I tried to look further past the spec and take a gander at ServiceMix, but if anything that just made me have more of a dislike for JBI. I then figured I’d join the mailing list to get re-educated – but there isn’t one?

When I read the spec. and look at your website, nothing leads me to believe that this is not a coupled mess that will lead to anything but angst, misery, and madness for the poor saps that have to use it.

The spec says and I’ve heard a couple of the folks that are pimping this thing that this spec isn’t for developers that its for vendors – as if its somehow beneath mere developers:

“The primary audience for this specification is system level software engineers who will develop the following:
…
This specification is not appropriate for application developers or business analysts. It is hoped that this specification will facilitate the development of standard service composition tools and services targeted specifically at this group.”

If that isn’t the telltale sign for a failed spec, I don’t know what is. If “mere” developers look at the spec and get gag reflex, why would they get excited about using it?

I don’t know, maybe the impls and some soon to materialize ground swell of support will prove me wrong, but I’m taking it upon myself to set the over under on this thing dying a horrible death at 1 year. Its demise will be worse then EJB.

I think that some people (including me) are reacting negatively to it because we all have suffered through years of the mistakes in EJB and when we see something that looks like it might lead to future pain at work we react negatively.

I don’t think that wonderful things like Spring can save this thing. Sure Spring is great, but that doesn’t do jack for those lovely SOAP errors you are going to get. Or how about a little fun with WSDL? Or a couple dozen javax.jbi.JBIExceptions with a “Not normal enough champ, try again!” errors.

James, you said:
“How can an API dictate deployment architectures?”
I think that is where I am struggling the most. How is this deployed? How does it scale? The first thing I thought I’d see in the spec is this wonderful physical diagram with a million nodes sitting around all over the network. Instead I see this frightening Normalized Message Router in what appears to be 1 JVM. After that I see 4 different RPC styles:

In-Only, Robust In-Only, In-Out, In Optional-Out

Is this a spec or a Ron Jeremy film!!?? I mean, I know that Sun is on the ropes and I wish them the best, but this is sick sick sick.

James, you then go on to say:
“JBI assumes an XML service bus and follows the logical model of WSDL. So JBI is designed to work well with WS and WSDL stuff, but equally well with XML over HTTP or XML over JMS or even text & binary data formats over proprietary transport protocols & file polling etc.”

Maybe you can set my mind at ease and explain how this works? Let me guess SOAP attachments? Or wait! I get a choice SOAP attachments or Base64 encoding in a CDATA field ?!

Anyway, sorry to spaz out, good luck – perhaps you’ll prove me wrong.

As much as I’d like to see a spec for ESBs, this ain’t it IMHO. James I actually surprised you are all hemped up on this thing. I am a big fan of ActiveMQ – you guys are doing a great job on that.

Thanks!

You must see something I don’t.I

Maybe I do - we've all got different mental models of this stuff. I guess I've worked on these kinds of problems a fair amount & tried many different ways of solving the problem. e.g. many years ago I helped to develop a product called SpiritBroker at a company called SpiritSoft which tried to tackle some of these kinds of issues - then Ross (another ex-SpiritSoftie) built Mule with a fairly similar kind of model & API. I just see JBI as a better model of what we need to create integration solutions - based on a logical XML messaging service bus abstraction using the NMS.

tried to look further past the spec and take a gander at ServiceMix, but if anything that just made me have more of a dislike for JBI.

Part of the problem I think is that JBI is a big spec with a lot of it only relevent to people who make JBI containers or JBI deployment units - which are necessary - but not exactly interesting for developers. So its a little hard to see the wood for the trees.

My best tip is, ignore the container/component stuff & deployment & management. Just focus on the Normalized Message Router APIs. They are fairly straight forward - much simpler than JMS and they handle various different message exchange patterns rather than just one ways like JMS. (The JavaDoc for this package looks much bigger than it might since there are typesafe interfaces for the different types of MessageExchange).

Basically there's DeliveryChannel, MessageExchange and NormalizedMessage and those are the core APIs of NMR / JBI.

I then figured I’d join the mailing list to get re-educated – but there isn’t one?

Here you go...
http://servicemix.org/Mailing+Lists

When I read the spec. and look at your website, nothing leads me to believe that this is not a coupled mess that will lead to anything but angst, misery, and madness for the poor saps that have to use it.The spec says and I’ve heard a couple of the folks that are pimping this thing that this spec isn’t for developers that its for vendors – as if its somehow beneath mere developers:“The primary audience for this specification is system level software engineers who will develop the following: …This specification is not appropriate for application developers or business analysts. It is hoped that this specification will facilitate the development of standard service composition tools and services targeted specifically at this group.�If that isn’t the telltale sign for a failed spec, I don’t know what is.

The first JBI specification is aimed at getting the JBI container and JBI component developers going. I think & hope future JBI specifications (or JSRs maybe) will address ways of plugging in POJOs into JBI in similar ways to Spring and EJB3 happened after the EJB 1 specification.

In ServiceMix we've gone down the road of supporting POJOs using Spring. I'm sure we can standardize this approach in future JBI specifications.

If “mere� developers look at the spec and get gag reflex, why would they get excited about using it?I don’t know, maybe the impls and some soon to materialize ground swell of support will prove me wrong, but I’m taking it upon myself to set the over under on this thing dying a horrible death at 1 year. Its demise will be worse then EJB.I think that some people (including me) are reacting negatively to it because we all have suffered through years of the mistakes in EJB and when we see something that looks like it might lead to future pain at work we react negatively.

I totally hear you. I've been a long time anti-EJB person myself. Even with the latest EJB3 drafts I still prefer the Spring approach to tell you the truth.

The difference though is, with EJB the hype was all - "this is how you write your business logic" - which caused lots of push back. With JBI folks are saying, application developers keep doing what you're doing - JBI is for those integration companies & tool vendors & EAI type folks to write integration components & containers with. The application developer model will come later if at all (and I'd expect it to be POJO based) - but you can just develop services using Spring / EJB3 and expose them as web services endpoints to join the JBI party.

I don’t think that wonderful things like Spring can save this thing. Sure Spring is great, but that doesn’t do jack for those lovely SOAP errors you are going to get. Or how about a little fun with WSDL? Or a couple dozen javax.jbi.JBIExceptions with a “Not normal enough champ, try again!� errors.James, you said:“How can an API dictate deployment architectures?�I think that is where I am struggling the most. How is this deployed? How does it scale?

However you like :). Put ServiceMix in your WS client and use it like you might use WSIF. Ditto on the server. Or deploy clusters of ServiceMix with ActiveMQ as your load balancing federated network - or use any other communication protocol you like; HTTP with an IP load balancer or another JMS provider (if you really must :) etc.

The first thing I thought I’d see in the spec is this wonderful physical diagram with a million nodes sitting around all over the network. Instead I see this frightening Normalized Message Router in what appears to be 1 JVM.

Rather like with JMS - an NMR could be embedded in a single JVM or it could be a cluster of remote processes on a network. Note that JBI components can be embedded in the JVM or the container can communicate with remote endpoints over different transports.

After that I see 4 different RPC styles:In-Only, Robust In-Only, In-Out, In Optional-OutIs this a spec or a Ron Jeremy film!!??

:)

Its really just modelling the different message interactions you often need to do (and which folks do in JMS already today). e.g. fire and forget one way, one way with acknowledgement, request response etc. JBI's just using the naming conventions in the WSDL 2.0 spec - the concepts have all been around for an extremely long time.

I mean, I know that Sun is on the ropes and I wish them the best, but this is sick sick sick.James, you then go on to say:“JBI assumes an XML service bus and follows the logical model of WSDL. So JBI is designed to work well with WS and WSDL stuff, but equally well with XML over HTTP or XML over JMS or even text &amp; binary data formats over proprietary transport protocols &amp; file polling etc.�Maybe you can set my mind at ease and explain how this works? Let me guess SOAP attachments? Or wait! I get a choice SOAP attachments or Base64 encoding in a CDATA field ?!

:)

The basic idea is a binding component does whatever it needs to do talking to some binary goo - then adapting it to look like a NormalizedMessage in some exchange. A NormalizedMessage is just a bunch of properties (key-value pairs where the value is a POJO) and a blob of XML for the body of the request and optional attachments. How those are physically encoded on a wire or bound to an API is completely up to the binding component to decide.

Then once inside the JBI service bus, you can forget about all that encoding/protocol stuff and work on the normalized message. i.e. JBI uses this API to mediate stuff to binary/SOAP/REST/CORBA/legacy stuff.

Anyway, sorry to spaz out, good luck – perhaps you’ll prove me wrong.

:) Thanks for a great post Mike!

James
LogicBlaze

There's the rub. JMS doesn't map too well to things like CORBA, EJB, HTTP or talking to web service endpoints over HTTP. JMS rocks for what its designed for, a standard Java API to messaging systems. However something more abstract and with an XML/WS feel and richer message exchange patterns is required for integration type solutions where you're talking to MOM, HTTP, email, EJB, CORBA and legacy stuff. e.g. take a look at the stuff Iona have been doing, mapping tons of legacy systems to JBI. The problem of trying it with JMS would be leaky abstractions. JBI is trying to integrate many different systems together; whether MOM or Java or C or COBOL.

On the contrary, the messaging system *is* the abstraction. Most JMS providers allow direct publishing of HTTP messages and things like CORBA clients and EJBs can push messages to an abstract, declarative JMS end-point. They don't really care how the message is digested or by who, they simply care that the message was reliably published nor do they require an awareness of delivery channels, message exchange factories, etc. This can be easily implemented in JMS without a new deployment format or container leveraging existing investment. ESBs play nicely in this niche without the need for additional standards or containers and provide the same exchange patterns of JBI by leveraging the capabilities of the existing messaging bus.IBMs abstention sums it up well "the JBI specification doesn't represent a sufficient step forward in terms of what we believe our customers need, and above what they can already do."

Relax, you don't have to use it :). As an application developer stick to Spring or EJB3. JBI is mostly for folks in the integration / EAI / SOA space to help wire stuff together with BPEL, content based routers, rules engines, transformation engines and protocol adaptors etc.

This is exactly the space I play in, not sure why you made the application developer reference. I advise my clients to simplify their architectures whenever possible, complexity is cost for an enterprise and JBI is complexity. It inserts yet another app server into the mix and in the case of legacy systems, forces them to be exposed through that app server as SEs (sorry, I don't really see a way to make my email server comply with the interface contracts required by a BC).I also find it funny that you throw BPEL in there. IMHO JBI is repeating many of the mistakes of workflow architectures/engines namely instituting additional (often single) points of failure by centralizing the service coordination and endpoints in a single container at the same time adding verbosity where simple configuration is sufficient. Earlier, you reference Steve Vinoski's blog that has a similar disconnect. He says that some of the mistakes of late 90s' EAI were overhead of translation to canonical formats and the misunderstanding that Java can't "solve it all". Yet, the JBI spec is heavily dependent on WS and WSDL which are by nature verbose and canonical and at the same time forces services to communicate through a Java-heavy standard.Whew, rant done. One round of XML-RPC for everyone, I'm buying!

+1

Erik :

I've got a new spec that will even one up this, it's the JAA - The java abstraction abstraction. Abstract any Java API through the JAA container

Maybe you could start a new Apache Jakarta Commons project, "Commons Abstracting"...

geir

Commons-Object and Commons-Commons, anyone?

(Of course, that begs for the obvious "commons-commons-commons" as well...)

To me, JBI seems to be mainly a service providers' programming interface, rather than an application developers' programming interface. Unfortunately, most discussions of JBI fail to point this out clearly, with some of the JavaOne sessions being no exception.

JBI technology will likely become relevant to many of us (I'm an application developer) when we start deploying business logic in JBI Service Engines and exposing this logic through JBI Binding Components. In other words: application developers (or should I say service developers?) will deploy business logic in a service engine, but they will not write a specialized service engine for every piece of business logic.

JBI APIs will be relevant to those people who implement these Service Engines (e.g. BPEL engines) and Binding Components (e.g. for your-most-favorite-and-utterly-obscure-communication-protocol-here).

The main difference to EJB containers is that an important EJB aspect is its application developers' programming interface.

A commonality between both specs is the fact that both define a standardized deployment model. (This does not mean the same deployment model, though.)

The JBI spec follows the principle of separation of concerns (separating service engines from binding components from intra-container message passing) and thereby gives people the opportunity to create specialized JBI components (e.g. a specific service engine) without having to worry about the remaining parts of the puzzle (binding components and the normalized message service in this example). With a bit of luck this will allow a market for JBI components to emerge as you should be able to use components from different vendors/projects in the same JBI container.

With a bit of luck this will allow a market for JBI components to emerge as you should be able to use components from different vendors/projects in the same JBI container.

Well said, Oliver. That's one of two things that I like about JBI. (We have a JBI SE wrapper for PXE, for example.)

JBI is like JCA (at least as of 1.5) in that it provides a lot of freedom and flexibility in comparison to EJB2. Also like JCA, SPI versus API means that things won't be as directly interoperable, but it also means that things are not tightly bound together.

The other thing that I like about JBI is the high-level architecture -- normalized messaging service, endpoints isolated from engines. We can talk about whether or not JBI, currently at 1.0 status, represents the platonic form of such an architecture and walk off in a huff if we don't think so, or we can make sure that lessons learned are poured back into JBI 1.5, 2.0, etc. so that the spec and implementations move in the right direction.

(Sorry for quoting you out of context in the title.)

Interesting--I have been thinking about the JCA analogy, too. Although I'm not quite sure what you mean with

SPI versus API means that things won't be as directly interoperable

The key here is that the JBI components will be interoperable. Obviously, as an app developer I shouldn't expect to be able to drop my BPEL service implementation into a non-BPEL service engine; but then I don't drop my SessionBean into a Servlet Container and expect it to work...

With a bit of luck this will allow a market for JBI components to emerge as you should be able to use components from different vendors/projects in the same JBI container.

You mean like the market that was supposedly going to emerge around selling reusable EJB components? Or JavaBeans before that?...

With a bit of luck this will allow a market for JBI components to emerge as you should be able to use components from different vendors/projects in the same JBI container.

You mean like the market that was supposedly going to emerge around selling reusable EJB components? Or JavaBeans before that?...

I see--at least to some degree--where you are coming from. However, I do believe that there are differences between JBI and EJB/JavaBeans technologies. This again is possibly due to the fact that the former is mainly an SPI, while the latter are mainly APIs (at least for the sake of this discussion, I'm aware that the EJB spec also defines contracts for container implementers etc.).

I can certainly see people competing on implementations for standardized service engines and binding components. For example, I can see people competing on the implementation of something like a BPEL engine or an EDIFACT binding. Moreover, I can see people develop highly specialized bindings that are of interest in specific industries or even only niche markets: clearly it would be beneficial if they only had to worry about the communication issues in order to make an entire JBI container (including all the deployed service) available through such a specialized protocol. Similar things are true for specialized service engines.

Interestingly enough people actually sell applications implemented as EJB and/or exposing application interfaces through EJB. There are even some JSRs for this (check out the JAIN and OSS/J specific stuff at the JCP website or http://www.ossj.org). There are other industries where such standards do not exist but individual companies still do similar things. Now I grant you that these products are not the re-usable components that were envisaged when EJB was invented, but there's a market nonetheless.

But then there is also an emerging market for JSF components.

Now I don't know what your background is or what kind of applications you develop. But chances are that there are people out there who try to solve problems that are different from yours. For some of these, JBI might be interesting and might seem like a step into the right direction.

Now I don't know what your background is or what kind of applications you develop. But chances are that there are people out there who try to solve problems that are different from yours.

I mostly work with integration, a mix of both middleware development as well as more hands-on integration for clients.
This means I am probably at least partially in the target demographics of JBI, and I was quite excited about JBI at first.
But having read the spec a few times quickly took that away.
Maybe that will change once I see some actual use of JBI, but so far I haven't been terribly impressed.

As someone earlier mentioned, there seems to be whole lot of overlap with JCA, and I don't see a whole lot being wrong with JCA to begin with.

It is emphasized all over that JBI is not for application developers. But what if the developer wants to write his/her application in SOA style. Meaning that the biz logic is separated from the rest as the services and the biz processes orchestrating the service executions. Then a piece of biz logic is written as a component providing the biz logic as a service via various access methods, e.g. direct call or remote call (WS, JMS, RMI, EJB, you name it). The best alternative is that the developer focuses on the component itself without care on the access methods. The specific access method(s) are defined during the deployment phase.

This way we can call the ‘application specific’ (as known today) logic directly and thus achieving the best performance and re-use the ‘service specific’ logic via remote calls. Later on when today’s ‘application specific’ turns into ‘service specific’ (e.g. need for an address book from other apps) then the system admin changes the component deployment descriptors from local-only to remotely accessible (you pick the technology :).

My questions are: Can I write such components using JBI? Do I use the JBI API or not? Am I app developer or a service provider?

It is emphasized all over that JBI is not for application developers. But what if the developer wants to write his/her application in SOA style. Meaning that the biz logic is separated from the rest as the services and the biz processes orchestrating the service executions. Then a piece of biz logic is written as a component providing the biz logic as a service via various access methods, e.g. direct call or remote call (WS, JMS, RMI, EJB, you name it). The best alternative is that the developer focuses on the component itself without care on the access methods. The specific access method(s) are defined during the deployment phase.This way we can call the ‘application specific’ (as known today) logic directly and thus achieving the best performance and re-use the ‘service specific’ logic via remote calls. Later on when today’s ‘application specific’ turns into ‘service specific’ (e.g. need for an address book from other apps) then the system admin changes the component deployment descriptors from local-only to remotely accessible (you pick the technology :).My questions are: Can I write such components using JBI? Do I use the JBI API or not? Am I app developer or a service provider?

Sure you can, if you want to. Typically I'd expect folks to write application services these days using POJOs and Spring or maybe EJB3 then expose those as endpoints in some container (Spring/Tomcat/Geronimo/JBoss) using either JMS or WebServices. Then a JBI container could perform orchestration, routing, rules etc.

But if you want, you could write your application service as a JBI component or JBI POJO just like folks write JMS specific application services - though I think the trend is gonna be for application developers to write POJO stuff and for there to be some binding between the POJO and the messaging system (JMS / WS / JBI) rather like Indigo in the microsoft world works.

James
LogicBlaze

BTW there's a good description of JBI in Steve Vinoski's article along with some background into the issues

James
LogicBlaze

BTW there's a good description of JBI in Steve Vinoski's article along with some background into the issuesJamesLogicBlaze

Did not learn anything from James' blog entry, except that it was an ad for CodeHaus ServiceMix project.

BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones. Is it the beauty of open source, the lack of information or an acute form of the NIH syndrom ;-)???

BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones.

I understand it. James is getting old and it's time for him to make money. But it's too late, James. ;-)

BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones.

I understand it. James is getting old and it's time for him to make money. But it's too late, James. ;-)

Sure, I'm getting old, you got me there. But I'm sorry to break it to you Andreas but I've been making money for quite some time now, I'm still making money today and its looking like I'll be making money for quite some time yet.

James
LogicBlaze

BTW there's a good description of JBI in Steve Vinoski's article along with some background into the issuesJamesLogicBlaze

Did not learn anything from James' blog entry, except that it was an ad for CodeHaus ServiceMix project.

I'm sorry my blog post did nothing for you then - at least I tried.

BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones. Is it the beauty of open source, the lack of information or an acute form of the NIH syndrom ;-)???

Erm - when ServiceMix started there were precisely zero open source JBI projects so there was no possibility of reuse. Sometime after ServiceMix was started, there was an ObjectWeb/Iona announcement of Celtix, an open source JBI project (which still has zero source files in it) - though I'm sure the ServiceMix and Celtix communities can work together somehow.

Also Sun announced their open source ESB at JavaOne - when ServiceMix was almost completed (despite me pestering Sun many times to work together on this).

So in summary, ServiceMix started because there was nothing else available to reuse - otherwise we'd have reused it :) Still today ServiceMix is the only Apache licensed JBI/ESB project available.

Projects at Codehaus do reuse code when it makes sense to do so and there is not a license conflict. I find your statement surprising Francois - given we're both part of the Apache and ObjectWeb communities which do reuse and work together when technologies and licenses allow it (and remember most of the folks at Codehaus are also members of the Apache or ObjectWeb communities too).

James
LogicBlaze

BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones. Is it the beauty of open source, the lack of information or an acute form of the NIH syndrom ;-)???

Erm - when ServiceMix started there were precisely zero open source JBI projects so there was no possibility of reuse. Sometime after ServiceMix was started, there was an ObjectWeb/Iona announcement of Celtix, an open source JBI project (which still has zero source files in it) - though I'm sure the ServiceMix and Celtix communities can work together somehow. Also Sun announced their open source ESB at JavaOne - when ServiceMix was almost completed (despite me pestering Sun many times to work together on this).So in summary, ServiceMix started because there was nothing else available to reuse - otherwise we'd have reused it :) Still today ServiceMix is the only Apache licensed JBI/ESB project available.Projects at Codehaus do reuse code when it makes sense to do so and there is not a license conflict. I find your statement surprising Francois - given we're both part of the Apache and ObjectWeb communities which do reuse and work together when technologies and licenses allow it (and remember most of the folks at Codehaus are also members of the Apache or ObjectWeb communities too).James

Hint: there was a smiley and 3 question marks at the end of my comment...

Kidding not, we end up with at least 3 open source projects targeting the implementation of JBI. My question here is (no smiley, no q mark): does it really make the world a better place to have 3+ OS implementations of JBI, or is is a waste of energy?

BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones. Is it the beauty of open source, the lack of information or an acute form of the NIH syndrom ;-)???

Erm - when ServiceMix started there were precisely zero open source JBI projects so there was no possibility of reuse. Sometime after ServiceMix was started, there was an ObjectWeb/Iona announcement of Celtix, an open source JBI project (which still has zero source files in it) - though I'm sure the ServiceMix and Celtix communities can work together somehow. Also Sun announced their open source ESB at JavaOne - when ServiceMix was almost completed (despite me pestering Sun many times to work together on this).So in summary, ServiceMix started because there was nothing else available to reuse - otherwise we'd have reused it :) Still today ServiceMix is the only Apache licensed JBI/ESB project available.Projects at Codehaus do reuse code when it makes sense to do so and there is not a license conflict. I find your statement surprising Francois - given we're both part of the Apache and ObjectWeb communities which do reuse and work together when technologies and licenses allow it (and remember most of the folks at Codehaus are also members of the Apache or ObjectWeb communities too).James

Hint: there was a smiley and 3 question marks at the end of my comment...Kidding not, we end up with at least 3 open source projects targeting the implementation of JBI. My question here is (no smiley, no q mark): does it really make the world a better place to have 3+ OS implementations of JBI, or is is a waste of energy?

OK :)

I completely agree 100%. I've been working hard to try consolidate the space for a while - I can't say anything yet but expect an announcement soon that you might like :)

James
LogicBlaze

I like the implication of using the JBI to implement
an ESB, which I think is definitely useful for integration

The "bus" allows one to address the combinatorial
explosion that one sees in complex integration
projects - by allowing canonical ("normalized")
models to be used.

I have played around with the open source Mule ESB product
(which I like) and it does a fairly good job, IMO

I dont know about combining orchestration (BPEL) etc
with integration - prefer to separate out orchestration
concerns from Integration solutions and have it focus
on connectivity, routing, transformations, security etc

--Arun

Arun Rao
EDS Corp

So, can someone explain why IBM and BEA abstained from the JSR 208 voting with some rather harsh words about the specification? http://www.jcp.org/en/jsr/results?id=3226

Here's a quote from IBM's keynote at JavaOne )(https://www.theserverside.com/articles/article.tss?l=JavaOne_Day3):

"IBM yesterday announced a partnership with 60 companies to work together on an open architecture SOA subsystem to easily integrate their offerings."

Are IBM and BEA taking the community in a different direction?

So, can someone explain why IBM and BEA abstained from the JSR 208 voting with some rather harsh words about the specification? http://www.jcp.org/en/jsr/results?id=3226Here's a quote from IBM's keynote at JavaOne )(https://www.theserverside.com/articles/article.tss?l=JavaOne_Day3):"IBM yesterday announced a partnership with 60 companies to work together on an open architecture SOA subsystem to easily integrate their offerings."Are IBM and BEA taking the community in a different direction?

As was mentioned on the previous JBI thread, Carlos has a good analysis of the BEA and IBM reaction to JBI.

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

James
LogicBlaze

I don't quite get the purpose of "normalized messages" as an XML format in the first place. Why bother with WSDL/XML if we can use good ol' plain java objects to the same avail. Of course there would be those that argue that this can not be achieved, but I fail to see why not.

I don't quite get the purpose of "normalized messages" as an XML format in the first place. Why bother with WSDL/XML if we can use good ol' plain java objects to the same avail. Of course there would be those that argue that this can not be achieved, but I fail to see why not.

When you are integrating in an SOA you typically do not have a 100% Java environment. Even in a 100% Java SOA, which is very rare, you typically have version and classpath hell, so serializing Java objects around an SOA is not a great idea - even inside the same JVM with multiple WAR deployments you can have issues.

However you can easily bridge from the JBI normalized message bus to a POJO model so application developers can work at a POJO level using some marshalling or SOAP tool like JAX-WS, JAXB, XStream, XFire, ActiveSOAP or Axis etc.

Also note that the NormalizedMessage uses a TrAX Source for the message content and tools like JAXB support a JAXBSource wrapping a POJO. ServiceMix has a similar XStreamSource for marshalling POJOs with XStream.

A JBI binding can also attach POJOs to a NormalizedMessage as named properties.

James
LogicBlaze

When you are integrating in an SOA you typically do not have a 100% Java environment. Even in a 100% Java SOA, which is very rare, you typically have version and classpath hell, so serializing Java objects around an SOA is not a great idea - even inside the same JVM with multiple WAR deployments you can have issues.

In my humble opinion, this argument shows a lot of the deficits that technologies like JBI bring into the picture. The normalized messages (as far as I could possibly understand) live _inside_ the JBI environment. I would expect that to be as pure java as it gets. The statements "All JBI containers must support the same WSDL schemas and SOAP version" is more or less equivalend to "all JBI containers must share the same java library for data objects and service interfaces". The one is "simpler" or more "loosely coupled" than the other is nothing but wishful thinking. In other words "If your abstraction layer does not abstract anything the best abstraction is not to abstract"!

Don't you think that something is wrong about a standard that needs somebody to blog about it to get it clarified, in even more obscure terms? Certainly, nothing can beat "SOA is not a technology" (c), but "a simple API to a Normalized Message Service and Router along with a component and management model for deploying integration services such as routing engines, BPEL engines, rule systems, transformation engines etc" is also good, IMHO.

Regards,

Slava Imeshev
http://www.viewtier.com