The industry has witnessed the evolution of a wide range of solutions addressing the problem space of B2B and enterprise application integration (EAI). These solutions varied from proprietary message oriented middleware to standard JMS based solutions and web services. This article provides a brief introduction to the upcoming JBI (Java Business Integration) standard in relation to SOA (Service Oriented Architecture) principles and the ESB (Enterprise Service Bus) infrastructure.

Read JBI - A Standard-based approach for SOA in Java

How does Sun's JBI relate to the IBM/BEA/etc. SCA stack?

How does Sun's JBI relate to the IBM/BEA/etc. SCA stack?

SCA is one type resource which JBI can use. Better question is: "What is difference between SCA and JCA (JSR 112)?". Do we have some SOA guru here?

SOA reduces complexity by moving into infrastructure things which have formerly been developed (over and over again). SCA codifies this process -- allows infrastructures to be built which allow you the service developer to just specify the infrastrcture you need, e.g., fine-grained policy, txns, etc. Exactly analgous to EJBs and Java code segments.

The bigger question to me is does JBI not exist as a redundant standard for message intermediation, i.e., why do we need JBI if we have SOAP and WS-* standards?

The bigger question to me is does JBI not exist as a redundant standard for message intermediation, i.e., why do we need JBI if we have SOAP and WS-* standards?

I think this is a good point. If restricted to Java alone, SOA loses quite a bit of steam. Recall one of the main failings of CORBA was that it didn't interoperate with Microsoft very well.

The bigger question to me is does JBI not exist as a redundant standard for message intermediation, i.e., why do we need JBI if we have SOAP and WS-* standards?

I think this is a good point. If restricted to Java alone, SOA loses quite a bit of steam. Recall one of the main failings of CORBA was that it didn't interoperate with Microsoft very well.

http://servicemix.org/Is+JBI+relevant+in+a+heterogeneous+environment

James
LogicBlaze

It's not a question of whether JBI can work in a heterogeneous environment. The issue at hand is that since there are a large number of disparate "standards", SOA should be defined by the community at large not just individual players or groups. Otherwise we again are left with Java providing its container and component model, Microsoft providing its container and component model, Ruby providing ..., etc.

SOA reduces complexity by moving into infrastructure things which have formerly been developed (over and over again). SCA codifies this process -- allows infrastructures to be built which allow you the service developer to just specify the infrastrcture you need, e.g., fine-grained policy, txns, etc. Exactly analgous to EJBs and Java code segments.The bigger question to me is does JBI not exist as a redundant standard for message intermediation, i.e., why do we need JBI if we have SOAP and WS-* standards?

There's much more to SOA & ESBs than just WS-*. Its also worth noting you need an ESB to keep pace with the different versions of SOAP and WS-*: SOAP 1.0, 1.1, or 1.2; WSDL 1.1, 2.0, lots of WS-Addressing versions and thats just the absolute basics - we've barely even touched the WS-RM / WS-RX, WS-Eventing, WS-Notification, WS-BaseNotification/BrokeredNotification, WS-DM, WS-Management - most of which are still moving targets.

Even if you adopt a bunch of WS-* specifications you'll still need to mediate, transform, orchestrate, govern etc.

In the Web, thankfully, HTTP has been stable for a long time, yet we still need things like Servlets and web frameworks. The WS-* is a huge area, new specifications are coming along all the time - so the ESB is a way of keeping pace and adapting to all the new WS-* that keeps coming along.

James
LogicBlaze

that when you dial in the Java API that you'll wind up with non-WS-* standards, e.g., JAAS instead of WS-Security and XACML. But after reading the spec more closely I can see it makes no such prescription. And as a framework for addressing intermediation it seems like a winner.

How does Sun's JBI relate to the IBM/BEA/etc. SCA stack?

SCA is one type resource which JBI can use. Better question is: "What is difference between SCA and JCA (JSR 112)?". Do we have some SOA guru here?

The Java part of SCA (as SCA also has C++ bindings too) focusses on a POJO programming model with annotations and dependency injection. So its very much focussed on the application developer such that the middleware is injected - and to a large degree the middleware is separate and invisible. SCA can then support different runtimes.

JCA is a connection management & pooling framework used in J2EE to create MDBs, Message Driven POJOs or XA JDBC pooling etc. So you could use JCA to implement an SCA runtime.

Similarly JBI is an API to providing integration components such as to integrate SOAP stacks, transformation engines, smart routing services and orchestration services etc. Again SCA POJOs can fairly easily be deployed in a JBI runtime to provide the best of both worlds - an easy POJO programming model for application developers and a standards based container and runtime for integration components.

FWIW the Apache ServiceMix is working with the Apache Tuscany project to ensure SCA and JBI works nicely together and ServiceMix has already got great JCA integration.

James
LogicBlaze

It is another attempt from guys like Oracle, BEA, IBM to turn SOA into something proprietary so that can make more money off the app server. It's funny - they are telling us you need a way to standardize on SOA so write your java interface and implementation class - and tell us about it in XML and then setup a services directory and stick in a module "jar" and boom we sell you stuff you have already been implementing for another $100k. All they are doing is taking that file exposing it through Apache AXIS and they have a "new" product.

Short summary:
JBI - standard defining containter environment for plug-ining engines. JBI care about QoS (Transactions, Monitoring, Management, Clustering, Load-balancing, ...).
JCA - One of possible JBI service plugins. Very abstract way speaking is similar to Java reflection but for heterogenous, distributed services.
SCA - Another container (plugable to JBI) which help developers focus on ther job.

Am I right?

Hello,

Estonia has very general method, called X-Road, of integrating different national wide information systems - http://x-tee.riik.ee/Talk6.ppt.

Regards,
Ago

For SCA, yes, partly. The language-specific SCA specifications (e.g. Java, C++) focus on how to author/build/write a service so that could be implemented as a container with JBI support.

There is also another wider aspect to SCA, which we term "service assembly". This involves wiring services together to form service networks with qualities of service, policies, etc. applied over particular bindings (e.g. WS-*, RMI, JMS, etc.). James' postings referenced above touch on some of this.

SCA defines two levels of assembly, roughly analogous to the distinction between "programming in the large" and "programming in the small". The former for SCA is the ability to connect coarse-grained services that communicate across remote boundaries (web services, RMI, etc) while the latter is the ability to connect services (e.g. local POJOs) that exist in shared memory. It's basically IoC/DI for the local and remote parts of an application. We believe this distinction is important since different architectural styles are at play when dealing with the two levels.

Jim Marino
BEA Systems

Together with your (read BEA) support for Spring I expect that part of assembling will be done via Spring. That mean in reality, SCA is trying to replace JBI and JCA. Of course this two should cooperate as two independed SOA implementations via common messaging. Can you explain please better what you see as possible areas where SCA can cooperate with JBI?
Is QoS (TX, load-balancing, ...) part of SCA spec?

Spring will be one of the ways (and a really good way :-) ) assembly "in the small" can be done. Part of the goal of SCA is to allow multiple ways to do assembly at this level so a key consideration will be the extension model for intergating these types of containers. JBI may be one possible way to do this.

I'm not sure JBI would have much to say about transactions or load-balancing (it is currently tied to a single VM) but the notion of a normalized message and routing (as mentioned by James) are important parts need to integrate multiple assembly containers.

Jim

I'm not sure JBI would have much to say about transactions or load-balancing (it is currently tied to a single VM) but the notion of a normalized message and routing (as mentioned by James) are important parts need to integrate multiple assembly containers.Jim

ServiceMix has full support for xa transactions, clustering and load-blancing, using ActiveMQ as its underlying MOM.

Guillaume Nodet

Basically, JBI is about standardizing a mechanism for integrating service containers into a middleware platform. With the currently released SCA specifications, we have focused on how one authors services and assembles service networks.

Mike Rowley (one of the other SCA authors) has written a blog on this at:

http://dev2dev.bea.com/blog/mrowley/archive/2005/08/jbi_doesnt_host.html

As part of the ongoing specification process and the Apache Tuscany project (Java and C++ open source SCA runtimes), we intend to define extensibility mechanisms for SCA. We are considering JBI as one possible technology for achieving this (there will likely be others, particularly since JBI is Java-focused).

Jim Marino
BEA Systems

How does Sun's JBI relate to the IBM/BEA/etc. SCA stack?

http://servicemix.org/How+does+ServiceMix+compare+to+Tuscany+or+SCA

James
LogicBlaze

I know that there is already a sea of acronyms out there and that developers get increasingly skeptical when they see a new one. But there are interesting stuff in SCA, stuff that will make the development of applications based on services much simpler.

Here is a
quick post on:
what is SCA?
how is it different from JBI?
what are the cools things in SCA?
what you can expect next?

http://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html

Edwin
BPEL Radio

I have posted a response to your question in my blog:
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2824

Jean-Jacques Dubray
SAP Labs

The industry has witnessed the evolution of a wide range of solutions addressing the problem space of B2B and enterprise application integration (EAI). These solutions varied from proprietary message oriented middleware to standard JMS based solutions and web services. This article provides a brief introduction to the upcoming JBI (Java Business Integration) standard in relation to SOA (Service Oriented Architecture) principles and the ESB (Enterprise Service Bus) infrastructure.Read JBI - A Standard-based approach for SOA in Java

If i rightly understands, IS JBI standardizes the way of communication in ESB, like a spec for all ESB vendors.

In a nutshell, JBI defines a standard for a service-based runtime environment that enables the installation, management, monitoring and interaction of pluggable components. For example, ServiceMix is a JBI-based ESB and uses the PXE WS-BPEL engine, whicj provides a JBI compliant SE component.

If i rightly understands, IS JBI standardizes the way of communication in ESB, like a spec for all ESB vendors.

Indeed; it's funny that JBI catches so much attention in the development world given this targeted audience.

OTOH, SCA, which is a component model that aim easing composition of services, looks something most SOA developers will have to care one day or another, along with BPEL (like Indigo, sorry, WCF cares for the same population in another technology).

Cheers,

    Bruno.

Forthcoming title by PACKT (ISBN 1847194400) has got following features: * Enterprise Service Bus (ESB) for integrating loosely coupled, pluggable services. * See Enterprise Integration Patterns (EIP) in action, in code. * ESB integration solutions using Apache open source tools * JBI features explained with the help of real world examples Title: Service Oriented Java Business Integration (http://www.packtpub.com/service-oriented-java-business-integration/book) Article on Service Aggregation: http://www.packtpub.com/article/aggregate-services-in-servicemix-jbi-esb