Recently I'm attending workgroups in which prevails the concept that SOA is nothing more than another way of writing WebServices, in fact making confusion between a methodological approach and an implementing technology. Prevails also the untruth impression that, thanks to the help of tools and common standards, SOA comes together with the development of the business logic.
Reality instead is more articulated and only really analyzing what SOA means we can understand it.
The definition of SOA (as far as I know) was introduced by Gartner in 1996:
"SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners."
Now I try to do an exegesis of the overall definition, that I think is really effective, starting from the first sentence:
"SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents."
That is to say that SOA must be seen as a first class citizen in modern system architectures. I want to stress the sentence at its maximum level and say that "SOA is a new channel for modern multichannel architectures".
Doing a similitude, when we build the Web layer for our applications we use frameworks that allow us (with MVC pattern) to decouple the Web layer from the Business layer. When we use them we concentrate on the UI and so we read HTTP parameters, we invoke the business logic and then we build the result page. The business layer is completely ignorant about the existence of the UI and the way we use it.
Thus, analyzing the third sentence:
"Both provider and consumer are roles played by software agents on behalf of their owners."
we can say that when we build the SOA channel:
"We must think at WebServices that implement our SOA like a new user interface, not for humans but for software agents. As we would never couple our business logic to the Web interface, this must be enforced also for our WS."
The previous sentence has an important practical impact, because in fact it says that modern tools that come with IDE/Frameworks can easily deceive us, because they have the power to publish directly our application logic as external service, really coupling definitively implementation aspect to clients that make use of them. I think that the big misunderstanding on this side is due to the evangelization opera done by big tools and frameworks vendors, who have always told that their instruments "are" SOA and not only a medium that can aid developers in implementing it.
The most typical example comes from the Enterprise specification of J2EE and .NET. With JAX-RPC, Sun gives us an infrastructure that "magically", with techniques that who has used RMI knows well, convert our objects in SOA enabled WS.
Better does Microsoft that with his "Contract" annotations into the code publish .NET objects as WebServices (with JavaEE 5 the same goal is achieved with Java annotations).
Are they joking ? They are pushing in the wrong direction ! Both are only remoting technologies that use SOAP as transport protocol, which can expose our business logic internals using XML serialization to convert objects in a suitable format for the protocol itself. This is not only a way to negate the SOA definition ifself, but also a straight road (an highway !!!) to write WS highly coupled to the programming language itself.
We call the concept now described "contract-last" anti-pattern, that is to say that we start from the business implementation to define our WebServices. Is called instead "contract-first" pattern when we start defining a priori our services with their input/output messages. But how can we describe "platform agnostic" such messages ? Using WSDL, of course.
I have to write something also on WSDL usage. WSDL is so powerful and expressive that at the end can be difficult and so tends to scare who is not an XML Schema and WDSL guru. And this is one of the main reasons because people tend to use tools blindly, generating WSDL a posteriori from Java/.NET code. There is also an intermediate possibility that again come from tools, where usually we start from a formally correct analisys of services (contract-first), usually described in UML, from this the code is generated and from code WSDL is generated. This approach is theoretically correct, but must be used carefully because can lend to interoperability problems discovered only at runtime, and so in an advanced phase of the project.
I think that tools shouldn't drive our work, specially during analysis phase. Why risk using a classical approach to services design, when using WSDL/XML Schema we can have the same expressivity, being sure of the final result ? It's not either a matter of technical resources, because at such level who does the analysis is not a developer but an architect with high experience on WebServices.
To summarize "SOA is a syncretic approach to software architecture that can only be achieved by highly skilled SOA architects"
In a word, SOA is CULTURE
, but seems that companies want to invest in tools and not in people.
Now let's analize the second sentence of the definition:
"A service is a unit of work done by a service provider to achieve desired end results for a service consumer"
Everytime I read this I can't stop thinking at CICS Transaction and at services that these make available to the overall system. From a technical point of view we are far from Web Services (transport on a COMMAREA, usually via an ECI call, I/O messages defined using Copy-Cobol), but practically they are the only real declension of an architecture that work in a service oriented way, and we should inspire from this when we define our SOA architecture.
I try to explain in other terms. We have allready said about dangers that come from a poor understanding of the technology and from the automated implementation of WebServices thanks to modern tools at our disposition. We must do another step and say that a "contract-first" analysis phase that "develop" a WSDL document which define a service is not enough to say that we are implementing SOA, but we always should have in mind, defining the service, the holistic nature of SOA, that is to say that a service is a set of component that works in concert to supply business functions that the service want to represent.
To summarize "SOA is yet here, learn from past experiences and change only the technology".
In few words, don't reinvent the wheel.
1. Gartner's Service Oriented Architecture Part 1-Part2
2. The fantastic approach of the Spring Web Services
3. Arjen Poutsma's Blog
4 A whitepaper about document oriented WebServices Rethinking the Java SOAP stack