I’m pleased that my recent disagreement with JP Morgenthal was noticed by Joe McKendrick, on his Service Oriented blog, and by Loraine Lawson at ITBusinessEdge. Now, having set the record straight, we can step back a little and start a more general discussion about SCA and why it’s a powerful new approach for developing applications. Loraine made a few comments in particular that got me thinking more about the value of SCA to a chief architect who is “prioritizing and rationalizing applications from an enterprise perspective.”
Once this architect has prioritized the needs of IT for the enterprise, it is critical that the architect’s development team has the right “tools” to update or create the applications that will meet those enterprise priorities. The development team also wants to improve its ability to maintain the application in the long run. I put the word “tools” in quotes in the previous sentence to emphasize the fact that I am using the word in its most general form. Your programming language is a tool. The design patterns you follow are tools. And, of course, the middleware infrastructure you use is a tool. J.P. is just wrong to assert that SCA will lock you into dependency on a vendor. There is no reason that middleware has to lock you in to a vendor any more than using a programming language locks you into a vendor, but that is only true if the middleware uses…
standards (and the right standards at that). If SCA were just some vendor’s tool that was promising great things, J.P. and everyone else would be right to be skeptical. But it isn’t proprietary, it’s a standard.
There are a few important reasons why this is important. It is always difficult to hire people who are skilled in a vendor’s proprietary technology and any application that depends on the technology is always at risk, since the vendor may choose to “improve” the technology in a direction that is retrograde for you. Or, the vendor could possibly abandon it altogether.
A good middleware standard is like a high-level language. It raises the level of abstraction that developers work in, so they can think about the actual problem being solved instead of fiddling with bits – or SOAP headers. There are three recent standards that do exactly this: BPEL, BPMN and SCA. BPEL is a language that is specifically designed around creating and using services, so it is also inherently middleware. Then there is BPMN, which standardizes the notation — the look of the business process on the design canvas — so that developers and non-developers alike can share an understanding of what is going on. And finally there is SCA, which allows developers to create, wire, package and deploy services without having to sweat the details of the numerous WS-* standards for every service that is created or used. It, like high-level languages, raises the level of abstraction without significantly constraining what a developer can accomplish.
Forcing a development team to avoid recent advances in middleware today would be like having a manager in the 1970’s forcing their developers to program in assembler due to a mistrust of languages like FORTRAN. Productivity would suffer.