Hello Indigo - 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.

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. 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.

Figure 1-8.  Services encapulate business components and data access

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. 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.

Figure 1-9.  Services are location transparent

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.

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.

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.

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.

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.

Please check back next week for the continuation of this article.

Comments On: Hello Indigo

· This article is an excerpt from the book "Learning WCF A Hands-on Guide," published...   >>> Post your comment now!

Buy this book...

This article is excerpted from chapter 1 of the book Learning WCF A Hands-on Guide, written by Michele Leroux Bustamante (O'Reilly, 2007; ISBN: 0596101627). Check it out today at your favorite bookstore. Buy this book now.