JBI VS SCA
Posted 2006. 11. 22. 17:51http://www.chwlund.com/?p=60
After the release of the Service Component Architecture (SCA) specification last month there have been a lot of discussion related to how SCA relates to Java Business Integration (JBI) (JSR-208). I will try to clear thinks up, all in all (if you dont have time to read more): SCA is a specification to make developers make services (in a SOA) in a standard, consistent and technology-independent way and JBI is a specification that defines how integration products should look like and how vendors could actually choose to design an integration product or component (standardization between integration technology vendors)
I have written about Java Business Integration in another post. Read this to learn more about JBI. To sum it up, JBI is all about the standardization of integration products (mainly ESBs). JBI specifies an architecture and an API that should be used when developing integration products. So, in our everyday consultant lifes, we do not have to care so much about this standard, but I think its a really important standard for the integration market, because it opens up integration solutions and makes it possible for different vendors to collaborate. I have written a lot more about this in my older post.
SCA, on the other hand, will maybe influence our everyday life much more than JBI. SCA is a specification that defines how we as developers should write services in a service -oriented architecture. Its like a general WSDL, but also much more. It defines how a service should be described and how it relates to other services. In this way we can define services independent of the technology used to implement it.
A white paper from IBM shows a specific example of how SCA will change how we develop services:
A EJB represents a reservation service for a airline-company and the service is loaded by the application like this:
// Get the initial context as shown in a previous example
...
// Look up the home interface using the JNDI name
try {
java.lang.Object ejbHome =
initialContext.lookup(
"java:comp/env/com/ejb/CarReservation");
carHome =
(CarReservationHome)javax.rmi.PortableRemoteObject.narrow(
(org.omg.CORBA.Object) ejbHome, CarReservationHome.class);
}
catch (NamingException e) { // Error getting the home interface
...
This is fine if you only use EJBs and your future services only will be EJBs. But what if you have to implement the reservation service using a different kind of java component or even another technology platform (like .Net). Then its better to refer to your services in a more neutral and transparent way, like this:
ModuleContext moduleContext=CurrentModuleContext.getContext();
AirReservation airReservation= (AirReservation)moduleContext.locateService(“AirReservation?);
airReservation.bookFlight(flight);
Dave Schaffer says this about the relation between JBI and SCA:
One of the beauty of SCA is that it is focusing only on things that a SOA developer sees and touches. SCA does not care about how the runtime that is going to execute a SCA module is architected.
SCA defines services and a way to create them, but it does not say anything about how the runtime enviroments should be like. A SCA service could be executed by an integration product like an ESB. And this ESB could be designed according to JBI. So, summed up, there may not be any relation between SCA and JBI, but they are two very important standard that may function complementary in a service-oriented architecture and you may end up running your SCA services in a JBI-compatible integraton suite. Please correct me if I am wrong, because I havent got a deep understanding of SCA yet…
Links:
Dave Schaffer: SCA, JBI and more..
The serverside: Discussion
Servicemix.org: How does ServiceMix compare to Tuscany or SCA”
Entry Filed under: Uncategorized
- Filed under : SOA
