Antipattern: Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) is an architectural style for bulding enterprise level systems.

The wikipedia article on SOA [] states the following:

Service Oriented Architecture (SOA) is a computer systems architectural style for creating and using business processes, packaged as services, throughout their lifecycle. SOA also defines and provisions the IT infrastructure to allow different applications to exchange data and participate in business processes. SOA separates functions into distinct units (services), which can be distributed over a network and can be combined and reused to create business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. Architecture is not tied to a specific technology. It may be implemented using a wide range of technologies, including SOAP, RPC, DCOM, CORBA, Web Services or WCF. SOA can be implemented using one or more of these protocols and, for example, might use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.

Evidently the emphasis is on decomposing a large system into smaller pieces that exhibit behaviour that interoperate by the exchange of messages, predominately synchronous messages. The references to "coordinating an activity" or the word "service" make it clear that this is an OO analogy extended to the enterprise level. Furthermore the claim of independence (from "how the service actually performs its tasks") is analogous to the OO concept of encapsulation.

This point of view is in conflict with the data-centric principle. In fact it would appear that when people think about SOA they tend to have something like the following picture in mind:

Anyone familiar with OO will immediately see the close parallel. Objects encapsulate state and only interact by messages that invoke behaviours.

Worse still they will probably be thinking in terms of

• exposing objects in the manner of location transparency
• synchronous messages
• distributed transactions
• information hiding - the antithesis of (application independent) shared data over the enterprise.

Given that applications do not compose (only data can logically compose), this approach is far less effective for data integration than the data-centric principle.