02/24/08 :: [SOA] SCA and JBI bring nothing to the SOA table [permalink]
Somebody brought to my attention Jason Bloomberg's opinion about these technologies (CIRCA May 2007) and asked me what's the big fuss about SCA? Jason argues:
JBI, [...] is essentially a Java plug-in architecture that you could use to build a Java-based ESB.
[SCA is] a component architecture for building service components, which are pieces of software that could consume or provide services
He continues:
SCA is more about building components that consume services. So its for doing traditional development where you consume services, if that's part of what you want to do, but it's not about building services
Jason thinks:
it more difficult to come up with a truly service-oriented approach. Because on the one hand JBI is saying build all your services in Java so we can plug them into this Java infrastructure. The SCA world is saying well let's think of services as components, so we can do traditional component development. It's not a service-oriented approach either.
He then bring OO in the picture:
It is object-oriented development. We're going to build objects. Objects are going to have interfaces. Sometimes the interfaces are service interfaces, sometimes they're other kinds of interfaces. We're working in the object-oriented paradigm where we are not able to support services in the OO paradigm as opposed to saying let's work in the service-oriented paradigm and think about how we are going to deal with objects in the service-oriented world.
It is quite unfortunate for someone who runs a "SOA Analyst Firm" to be so ignorant about SOA and how to position underlying technologies in a Service Oriented Architecture including OO.
I am going to try to make it short and sweet. I have advocated the concept of using BPEL and Service Interactions since July 2002, well before anybody started to work on SCA. in 2003 and 2004, our working group at OASIS delivered the first assembly concept in the OASIS ebXML Business Process v2.0.4 specification, with support for both ebXML and Web Services.
So here are my comments. His first statement above is correct. Yes, JBI was thought to be a modular architecture for Java based ESBs. It fits very well one of the possible topologies of loose coupling that I described here. Sun actually complemented JBI with an assembly paradigm which proves how important this concept has become since 2002.
Then Jason starts diverging when he says "So its for doing traditional development where you consume services, if that's part of what you want to do, but it's not about building services". What he has in mind is "Web Services". He has looked at the prototypical SCA assembly pictures and he has seen a "Web Service" hanging at the back of an SCA assembly and concluded erroneously that you would do "traditional" development and from time to time you would invoke a "Web Service". Jason could not be more wrong.
He continues to be completely wrong by saying: "JBI is saying build all your services in Java". JBI's binding components can connect to "anything". Sure enough the ESB itself is implemented in Java, but the binding component can reach anywhere. This is the point of an ESB. Jason again thinks in terms of "Service Engines" and see them implemented in Java, but they are really for the Loose Coupling (LC) code, not for the service implementation itself.
Jason sees it as "It is object-oriented development". LoL, "Sometimes the interfaces are service interfaces, sometimes they're other kinds of interfaces." And what could be the other kinds of interfaces? "We're working in the object-oriented paradigm where we are not able to support services", Really?
I have said it and I'll say it again, there are several core differences between SO and OO:
a) the interface in SO is bi-directional, in OO the "references" are not explicit, hence Spring, OSGi...
b) activation: in OO, there is no "activation" framework. All method invocations are serialized, Bertrand Meyer has written enough articles about Object and Concurrency to make it clear
c) in OO there is a "one-to-one" relationship between method and implementation. in SO, several operations can be tied onto the same implementation (BPEL is the best example).
SCA, finally, digs us out of the pre-historic "CRUD-Oriented Architecture" that has been the bread and butter of an old generation of architects for the last 30 years. SCA IS-THE technology that is bringing "peer-to-peer asynchronous inter-actions" at the core of the application model. SCA is one of the most elegant and most important technologies I have ever seen because it is changing radically the application model from OO to SO without disrupting existing technologies. This is not about replacing Java, this is not about adding orchestration concepts to every language under the Sun, it is about enabling the definition of inter-action based interfaces and enabling older technologies to leverage orchestration concept today without any disruption. How smart is that? Mike Edwards and a few others who have invented SCA are some of the most important thinkers of the last 30 years. SCA enables SOA, SCA is SOA, SCA brings SOA to everybody.
Finally we can move on from the antiquated, Synchronous, CRUD-oriented, Client/Server application model that has brought IT to its knees and leverage an Asynchronous Service Oriented Peer-to-Peer model to create the information systems of the 21st century.
Yes, SCA is changing a lot of things, but not in a revolutionary way, it is not about replacing skills but augmenting them. It is not about killing Java (politically), it is about augmenting it.
As Mike points it out in his response to Jason, SCA is the technology that enables composition. It is also the technology that finally gives us the correct foundation for BPM.
If I were a member of this core team that created SCA from scratch, I'd be quite proud of these accomplishments.