Service Oriented Architecture

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.

What Is a Service?
This is an important question—and the answer varies depending on the context of the discussion.
For example,a service is a logical term to SOA,but it has physical meaning to WCF.
I’ll focus on the former in this section.
According to the high-level definition of SOA,business functionality must be distributable and accessible in some way.
The term service in this case refers to the entry point or “window” through which business functionality can be reached.
Consider the application architecture illustrated in Figure 1-6.

Figure 1-6 Directly invoking business components

The client application represents an Agency Management System that includes many chunks of business functionality such as Certificate Issuance,General Ledger,CRM,and Reporting.
In Figure 1-6,the client application coordinates access to these features by consuming business components directly.
In this case,components are not distributable in such a way that they can be location transparent, thus they are not services.

So,what constitutes a service in SOA terms?
It could be a serviced component exposed using Enterprise Services,a .NET Remoting component,an ASMX web service,or a WCF service.
Any of these technologies can be useful in exposing the business logic in such a way that the client can reach that functionality at remote locations in a distributed environment,without communicating directly with business components. Figure 1-7 illustrates the same services beneath the Agency Management System example from Figure 1-6,but this time each feature is exposed via one of the aforementioned technologies.
Serviced components are reached using DCOM over TCP,.NET Remoting components via RPC over TCP,ASMX web services via SOAP over HTTP, and WCF services via SOAP over any protocol.
RPC stand for Remote Procedure Call Protocol远程过程调用协议

Figure 1-7 Service boundaries implemented with different technologies

Tenets of SOA

Although there is no official standard for SOA,the community seems to agree on four basic tenets as the guiding principles for achieving an SOA. They are:
• Service boundaries are explicit.
• Services are autonomous.
• Clients and services share contracts, not code.
• Compatibility is based on policy.       compatibility兼容性
Let’s look at each of these in greater detail.

Service boundaries are explicit
Services are responsible for exposing a specific set of business functionality through a well-defined contract,where the contract describes a set of concrete operations and messages supported by the service.
Services completely encapsulate the coordination of calls to business components in response to operations it exposes to clients,as Figure 1-8 illustrates.

Figure 1-8 Services encapsulate business components and data access

Implementation details behind the service are unknown to clients so that any technology platform could be invoked behind the service without impact to the client.
In addition,the location of the service isn’t important to the client as long as the client knows where to reach it.

Enterprise Services,.NET Remoting,ASMX,and WCF all support this tenet.
With Enterprise Services and .NET Remoting,the boundary and contract are defined by the public operations of the serviced component or remote component,respectively.

In the case of Enterprise Services,the contract is described as a type library,while with .NET Remoting the contract is a shared CLR interface.
As for ASMX and WCF,contracts are described in Web Services Description Language (WSDL),an interoperable standard.
All of these technologies also support location transparency in one respect or another.
That is,the contract is independent of the location of the service in all cases.

Note:Where WCF improves on earlier technologies in support of explicit boundaries is in the way contract design and deployment are handled.
With WCF,you explicitly define the contract and opt-in every operation and data element that you intend to expose publicly.
WCF also goes beyond location transparency with protocol transparency,meaning you can expose services over any number of protocols.

Services are autonomous
Services encapsulate business functionality,but they must also encapsulate other dependencies of the business tier.
In this way the entire service should be moveable or even replaceable without impact to other services or system functionality as illustrated in Figure 1-9.

Figure 1-9 Services are location transparent

As I mentioned before,a service represents a major chunk of business functionality that owns its own business components,data access components and data storage if applicable.
It should be able to perform key functions without external dependencies. This is what is meant by atomicity.

Part of atomicity also dictates the following:
• The service boundary must act as an independent unit for versioning.
Changes to business components may require versioning the service contract, for example.
• The service boundary is the deployment boundary for callers.
• The service must operate in isolation and be fault-tolerant. That is,exceptions behind the service tier should not impact other services.

Note:Atomicity is largely influenced by design,but WCF does enable atomicity by providing a clear approach to contract versioning,a flexible approach to deployment,and certainly handles fault isolation if services are hosted by the same process.

Clients and services share contracts, not code
Given the first SOA tenet,that service boundaries are explicit,it only makes sense that this boundary be the law as far as how clients interact with services.
That means that the contract must not change once published,or must at a minimum remain backward compatible to existing clients—and this requires discipline.
In theory,contracts are not tied to a particular technology or platform,but this is not actually an official requirement of SOA—only a strong tendency.
Thus,you could say that serviced components,ASMX web services,and WCF services all support this tenet since they all are capable of publishing a contract that is consumed by clients without sharing code (type libraries or WSDL,respectively).
This is where .NET Remoting falls down, since it relies on sharing CLR types, a .NET-specific construct.

Note:The beauty of WCF is that it uses interoperable contract definitions (WSDL) for all types of services—regardless of the communication protocols used to reach those services.

Compatibility is based upon policy
While contracts describe the business functionality available at a service boundary,policy describes other constraints,such as communication protocols,security requirements,and reliability requirements.
Enterprise Services and .NET Remoting don’t really have a way to publish such policy requirements,but ASMX with Web Services Enhancements (WSE) and WCF do.
Policy is actually an extension to WSDL that can describe access constraints in a way that clients can be aware of them and invoke services in a compatible manner.

Note:WCF support for policy is completely hidden from the developer—it is automatically included with the WSDL document based on how you configure WCF service for features such as security and reliability.

Big SOA, Little SOA
The problem with discussing the tenets of SOA in the strictest sense is that levels of compliance may vary based on the scenario.
On the one hand,SOA is a big business buzzword tossed into conversations at board meetings,at executive briefings,and in hallway conversations between C-level executives.
At this level,however,SOA really refers to connecting disparate systems across application,department,corporate,and even industry boundaries.
This is what I call Big SOA.
The other use for the term SOA is to describe how applications are designed as chunks of business functionality that are isolated behind explicit service boundaries.
I call this Little SOA.

Big SOA is an Enterprise Architect (EA) activity.
The EA cares about connecting heterogeneous systems that may originate from different vendors.
For example,you can connect HR,Payroll,CRM,and possibly other applications across the organization to achieve a business goal.
In some cases,it is even useful to control messaging between systems and track usage with an Enterprise Service Bus (ESB)—a term that also means many things,
but in this case I refer to the ability to pass all messaging through a common service for tracking and routing purposes.
In short,Big SOA is about connecting entire systems through their respective service boundaries.

Little SOA is a Software Architect (SA) activity.
The SA cares about designing a system that may encapsulate functionality behind service boundaries to achieve reuse,maintainability,version control,visibility,orchestration,and other benefits.
These services may never see the light of day outside the application to which they belong.
On the other hand,some internal application services may also be exposed for public access to facilitate communications and interoperability with other applications.
If applications don’t expose public services,it becomes a challenge to connect applications.

Note:Little SOA enables Big SOA.

The distinction between approaches in SOA is important because of the level of strictness in applying SOA tenets.
For example,it isn’t always possible to completely isolate business components,business entities,and data tiers between services in the same system.
Data is usually highly relational within a system,such that different areas of business functionality share common data stores and entities.
Figure 1-10 illustrates an application with three services: Accounts,Customers,and Reporting.

Figure 1-10 Sharing data between services is sometimes unavoidable

Accounts Service and Customers Service each expose operations to their respective types,but Accounts data is related to Customers in the system;
thus,there isn’t a pure separation between the tables required to support each service.
At the same time,both Accounts and Customers also provide access to business functionality and CRUD operations (Create,Read,Update,Delete)
that can be considered completely independent of one another—thus the need for separate services.
The Reporting Service, in fact, needs to access all tables to aggregate results.

In a pure SOA play,each service would have sole ownership over its data tables,and services would have to communicate with one another to access those tables,even for reporting.
This can create unnecessary overhead and complexity within a system.
Instead,Figure 1-10 illustrates a way to support sharing relational tables behind the service boundary by coordinating relational results at the database,possibly via stored procedures.
This way,the vertical assemblies associated with a service are completely owned by the service,
and if a particular service,such as Reporting,requires access to multiple relational tables that are also accessed by other services,
the data access layer coordinates this result for the service.
While serialized business entities may be shared between services,business and data access components are not.
Services can always call other downstream services to share functionality when service isolation is clear cut
and the overhead of the service call makes sense—for example when services provides core functions such as document generation or messaging.

The point is that not all four tenets of SOA can be followed to the letter when designing services within an application.
When application services are exposed to Big SOA in most cases the entire application is deployed with the service,thus the shared entities and data stores are implied parts of the atomic service.

Note:In this book,I’ll be focusing on how you deploy WCF services as part of an enterprise application. In other words, Little SOA.