The session “The Best Of Both Worlds with Java Business Integration and Service Component Architecture” was presented by Jos Dirksen and Tijs Rademakers, Software Engineers from Atos Origin. They discussed how Java Business Integration (JBI) should not be viewed as a competitor to Service Component Architecture (SCA). The two are actually quite compatible.

JBI is a specification that defines how to create and Enterprise Service Bus (ESB). The JBI container has binding components, service engines, and a normalized message router. A developer creates service units and service assemblies and deploys them to the JBI container.

SCA is a model for describing a service component’s assemblage and deployment. Services are built with SOA, and are vendor neutral, language neutral, and technology neutral (can use different protocols). SCA has an implementation language (Java, Ruby, etc.), and it can be defined using the Service Component Descriptor Language (SCDL) or with Java annotations. SCA components can be combined or “wired” to make SCA composites. SCA composites can be used in other SCA components and composites.

When combining JBI and SCA, all JBI service engines can be used in SCA components, SCA components can be called from JBI, SCA applications can be deployed as service units in a JBI container.

Although it is possible to deploy JBI applications within an SCA component. It seemed to me to be somewhat clumsy. A developer would need to use Apache Camel to integrate the JBI application within an SCA component, whereas deploying an SCA component inside of a JBI container was straightforward. SCA seemed like a good choice for defining an SOA service and JBI seemed like it was a good at managing requests from a variety of sources (MQ, HTTP, etc.).