How is contract-based SOA more flexible than defined (remote-acess) API?

Question

I am reading a strategy for future IT development which stresses the use of SOA. I know have gathered that SOA is a fallen buzzword from a few articles about it on the web.

As programmer, I would like to understand why is SOA supposed to be more flexible than other distributed-computing architectures?

• SOA is based around services being published on a bus. However, every service consumer must be aware of significance/semantics of a service to make any use of it. Hence, client must be modified in order to make any use of new service.

  For instance, if google maps publishes traffic information, my app would know that there is something published, in what format etc, but it does not make my route planner magically gain functions which make use of those data.

• SOA is based on contracts. Is contract something more than well-defined (pre-, post-) conditions, which can be chechecked by the computer automatically?

  (Just like a function checking its inputs, and documenting what it expects in user docs, only moving the verification outside of the function.)

  How does that improve flexibility, if both side must again fulfill the contract? Data don't fulfill it automatically just because it is published. If the contract changes, clients must be modified as well.

Answer 1

I disagree with lots of ideas expressed in your question.

I don't think SOA is a fallen buzzword. There was a time when lots of people were taken in by vendors and sold a bill of goods. That time is over. If that's what you mean, then I'll accept it. But SOA is alive and well.

I don't agree that a bus is necessary for SOA. It's the decomposition of the business problem into services that matters, not the bus.

Your statement about customers having to be aware of service semantics in order to use them is true of all distributed components.

Every distributed component is based on a contract. An interface, no matter how expressed, is a contract: "Pass me these parameters and I promise I'll return you this value or perform this function." If the contract changes, so must clients. That's true in your own code and distributed components.

I think SOA is a winner because it's based on distributed components that use HTTP, the wire protocol of the Internet. It's simple and open, which is a huge advantage over other technologies like CORBA or RMI or COM.

It represents a higher level of abstraction, which is always a good thing for developers. They're freed from concerns about complexity if the API is well defined and stable. They can focus on choosing from a menu of services that map well to their business problem and orchestrating them to craft new solutions.

But there's no magic to it. API design is hard. Choosing SOA and using contracts doesn't guarantee that you'll do it well.

The one advantage that "contract first" has over other approaches for developing SOAP services is that it makes "duck typing" possible. If you generate the WSDL from a schema you decouple users from changes to the object model used by the service behind the scenes. The two are tightly coupled if you generate the schema and WSDL from the object model. The Spring web service site has a good discusion on the topic.