SCA and JBI - a match made in enterprise heaven

Some technologies are aimed at developers, some are aimed at fanboy developers, sometimes however technologies are aimed at the bigger picture, how to architect, deliver and operate enterprise systems. SCA and JBI are two such technologies and there seems to be a misunderstanding around them being competing technologies. I've said before that SCA and JBI should work together so this isn't news but I think its worth quickly explaining why the various vendors need to get the politics out of the way and start working together to make SCA and JBI work together.

This is a standard sort of SCA view. So what are the good things about SCA?

1. SCA helps you think about the business services not the technology
2. SCA helps you construct services, and their teams, around a service view
3. SCA gives you a management entity that fits with a service architecture not a technology architecture
4. SCA destroys the dreadful layer marketectures that vendors push

So simply put SCA helps you build better SOA by giving you more of a SOA view of the world. The way to build good SCA is the way to build good architectures

1. Think about your services
2. Organise your teams around those services
3. Work out the best way to build each service
4. Delivery
5. Operate

The last is a brilliant part of SCA as unlike the layer diagrams of BPEL/EJB/Fish/Database etc it makes it clear at the operational level what the Service architecture is, it also encourages you to think about the services and your delivery before getting into even the design (let alone the code).

So that is what SCA is good at. What about JBI? Well lets first be clear JBI is not for developers its for product companies. JBI is one of the few standards out there (SCA is another) that actually has a business case for its existence. The various scripting JSRs and some of the other fanboy elements out there just have a technical case. This is typical of lots of IT which aims to deliver technical flexibility to the detriment of business flexibility.

So how does JBI work with SCA? Well JBI is about Service engines communicating so its not about the services its about how the engines talk together. This means that it works underneath the services. Combining SCA and JBI therefore is pretty easy

In reality the call isn't from one code area to another its really between the service engines, i.e. the bit that JBI does. The goal of JBI therefore isn't portability of the code/service its portability of the engines.

This solves one of the big issues of SCA which is that implementations are limited to a single vendor's platform. It also doesn't really have a great upgrade story so you are again linked to what the vendor wants to do, if the BPEL engine you are happy with is upgraded and the rules engine that you don't like is upgraded and they all run on the same platform which is upgraded then you have to move everything at once, which is a bit of a pain.

So the real vision here is for SCA and JBI to work together, unfortunately at the moment the JBI group is missing Oracle, IBM and SAP which makes it unlikely that this will be done. This is to the detriment of customers as it means that SCA will remain a great single vendor platform but will not have the portability and operational flexibility that JBI could deliver.

Politics appears to be getting in the way of an SCA/JBI match up as no-one I've spoken to on either side of the divide thinks it isn't technically a good idea.

Technorati Tags: SOA, Service Architecture