What is Service Oriented Architecture (SOA)?
There have been so many interpretations of this throughout the years that it seems important to establish a common understanding before I discuss WCF as an SOA platform.
The Organization for the Advancement of Structured Information Standards,better known as OASIS (http://www.oasis-open.org),provides this official definition in its Reference Model for Service Oriented Architecture:
Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.
You might add to this definition by stating that SOA relies on the ability to access chunks of business functionality,potentially owned by different applications,departments,companies,or industries.
Notice that this description does not specify the mechanism through which those chunks of functionality are accessed.
In fact,the term “service” isn’t even mentioned, although it is implied.
From OOP to SOA
The road to SOA has been a progressive one—driven by the need to improve how developers build complex enterprise systems.
The principals behind enterprise system design are far-reaching: from object-oriented programming to component-oriented programming to service-orientation.
All three approaches share the common goal of encapsulation and reuse.
With object-oriented programming, classes encapsulate functionality and provide code-reuse.
To share classes between distinct applications or binaries, however, you have to copy the code, as shown in Figure 1-2.
Figure 1-2 Duplicating types between components
Component-oriented programming has many limitations,but the most obvious is tight coupling to a specific technology.
How can a Java client call a COM component?
How can a .NET assembly invoke an EJB?
It all boils down to protocols and messaging formats.
Invoking a remote component of any kind requires serializing a message and passing it across applicable process or machine boundaries (see Figure 1-3).
Figure 1-3 Shared component containing shared types
Bridge technologies and adapters exist to transform messages from one technology into another,so that when the message arrives it can be understood and processed.
The reverse happens as responses are fed back to the caller.
This approach is cumbersome,however,sometimes introducing multiple transformations between clients and components—and sometimes not even possible.
Instead of exposing components directly,components can be accessed through service boundaries to alleviate some of this pain (see Figure 1-4).
Figure 1-4 Exposing functionality through a service boundary
So,does service-orientation solve the problems inherent to component-orientedprogramming?
It depends on where you sit on the meaning of service-orientation.
Iwould definitely agree that in its purest form, service-orientation delivers a solution to these problems by introducing (via web services) the concept of contracts,policies,and interoperability.
In that respect,applications can communicate with one another’s services,as shown in Figure 1-5,without concern over the technology each employs.
Figure 1-5 Consuming interoperable services
But you could also argue that service-orientation is an approach to development that implies the encapsulation of business components,data access,
and data storage such that access is controlled through a top-level entry point.
The package is a service,accessible over whatever protocols are supported,even if it lacks interoperability.