Principles of Service Oriented Design

Principles of Service Oriented Design

Connected Services Framework 3.0 SP1

Service-oriented development is based on four fundamental tenets that were originally derived by the Windows Communication Foundation (WCF) (previously code named "Indigo") team at Microsoft. They developed the tenets to describe how to use the WCF programming model to build services. However, these tenets apply at the business architecture level as well as the technology level. Services should be based on the well defined service oriented principles and the following four tenets of service oriented development:

  • Boundaries are explicit.

Service orientation is based on a model of explicit message passing, and crossing a boundary is considered an explicit act. At the technology level, services interact by passing messages and this tenet demands service interfaces that are externally consumable.

From a business perspective, it is equally important that you understand and define organizational boundaries and function boundaries within your own organization to identify clearly demarcated capabilities.

  • Services are autonomous.

Changes made to one service must not affect another service. Each service in a system is deployed, managed, and versioned independently of each other. Encapsulation is a key element of this tenet. A service should be able to be rewritten without negatively affecting the consumers of the service. Autonomy at the service level requires interchangeable and loosely coupled services. Autonomy at the technology level requires implementation independence.

Collectively, this means that the topology of a system can evolve over time and is not dictated by a single authority. Services should be treated as if they are "running in the wild", which means you must ensure security and validation of all inputs and outputs.

  • Services share schema and contract, not class.

Services should not expose their internals. As an example, consider Java EE and .NET Framework interoperability. If you try to interchange platform-specific types, an intermediate meta-model or schema is required.

The contracts for what to pass in and what to send out have to be clearly defined by schemas and contracts for behavior. Schemas and contracts are expected to remain stable over time because any change in the contracts affects consumers who are using the previous schema and contract.

  • Service compatibility is determined based on policy.

Policy defined at the meta level describes the semantic capability of a service and is based on a set of explicit statements of capabilities and constraints. Examples include security related constraints, such as encryption, signing, and the use of appropriate token types. Policies are expressed publicly in terms of policy assertion. This enables the service consumer to access the policy information and then abide by that policy when interacting with the service. Policy assertions are identified by stable and globally unique names.

A service can be as simple as providing a single function, for example, a request/response-based mechanism that provides a series of random numbers, or can be an aggregation of complex elements, such as the Web service API that is implemented by amazon.com.

The level of semantics that is exposed by a service does not define the complexity of the implementation of the service. The semantics that are to be exposed are generally determined by a business decision. For example, amazon.com may embed a billing operation within the service but not expose that capability as an accessible API. A service consumer sees only the service that is described by the set of APIs that represent the consumable interface of the service. Also the granularity of the exposed API should be broad enough to achieve appropriate performance and business requirements.