Book Review: Service Oriented Architecture

One of the most popular terms in IT right now is SOA (Service Oriented Architectures). Most architects and engineers that I know have been building Web Services for quite a few years now and most would answer that they have been working on SOA's. However the more I worked with this type of architecture the more I began to realize it was misunderstood. Along that line of thought I decided to go into an in-depth study of what exactly is meant by SOA so I began reading Service Oriented Architecture by Thomas Erl.

This book does a good job of explaining what exactly is an SOA architecture and the difference between a solution that simply uses Web Services and one that is an SOA. An SOA is built around principles such as loose coupling, reusability, composability, and discoverability. These principles (and others) guide the architect in creating a solution that solves a particular need now and offers the possibility to be re-used in the future for new solutions. Another important point is this, an SOA doesn't just affect the code we type as engineers or architects, it affects the organization's view of IT solutions. If an organization decides they want to build an SOA then pieces such as discoverability need to be a company-wide effort, otherwise the organization will end up with 50 methods of doing the same thing. This emphasizes the fact that a true SOA needs to be an organizational effort.

Erl draws an analogy between SOA and object oriented development that I think is golden. The use of Web Services does not mean you are creating an SOA any more than the use of objects means that you are developing a true object oriented architecture. For instance, it is quite possible to build a flat object model with no polymorphism or other characteristic of OOD. You could even go so far as using all static members and never need to construct an instance of an object. If this is what you did, then could you really call your solution object oriented? Not really. The same would be true of a solution that claimed to be an SOA but really was just an N-Tiered or client-server architecture which makes use of web services.