In the previous article we established the service-orientation design paradigm as currently providing us with the following eight common principles:
- services share a formal contract
- services are loosely coupled
- services abstract underlying logic
- services are reusable
- services are composable
- services are discoverable
- services are autonomous
- services are stateless
These principles are “common” in that they represent an industry-level perspective of service-orientation as determined by research conducted by SOA Systems Inc. In part 2 of our series we dive into an exploration of these principles by discussing the first two on the list: the required use of service contracts and the creation of a relationship between services known as “loosely coupled.”
The Role of Service Contracts
Services are formally defined using one or more service description documents. In the Web services world, the technical service description documents are typically the WSDL definition and the XSD schema. A third type of document that will become increasingly important is the policy.
Each of the these documents can be classified as service metadata, as each provides information about the service. Service description documents can be collectively viewed as establishing a service contract – a set of terms and conditions that must be met and accepted by a potential service requestor in order to enable successful communication and interaction. (Note that a service contract can also refer to additional non-technical documents or legal agreements, such as SLAs.)
Within SOA, service contracts provide a formal definition of:
- the service endpoint
- each service operation
- every input and output message supported by each operation
- the data representation model of each message’s contents
- rules and characteristics of the service and its operations
Service contracts therefore define a great deal of the underlying architecture of a solution environment, and may even provide semantic information that explains how services as part of this solution go about accomplishing a particular task. Either way, this information establishes the terms of engagement to which consumers of a service need to comply.
Because this contract is shared amongst services, its design is extremely important. Service requestors that agree to this contract can become dependent on its definition. Therefore, contracts need to be carefully maintained and versioned after their initial release.
Service contracts represent a cornerstone principle in service-orientation, and therefore support or even enable other principles, such as service abstraction, composability, discoverability, and, our next item of discussion, loose coupling.
What it Means to be Loosely Coupled
No one can predict how an IT environment will evolve. How automation solutions grow, integrate, or are replaced over time can never be accurately planned out because the requirements that drive these changes are almost always external to the IT environment. Being able to ultimately respond to unforeseen changes in an efficient manner is a key goal of applying service-orientation. Realizing this form of agility is directly supported by establishing a loosely coupled relationship between services.
As with traditional distributed architectural models, SOA is based on the concept that solution logic is partitioned into multiple units of logic that can be assembled to collectively automate business tasks. One of the characteristics that distinguishes SOA from its predecessors is how these units of logic are required to relate to each other.
This is where the issue of coupling comes in. Coupling between software programs can be viewed as representing a measure of dependency. The higher the dependency, the tighter the coupling. No dependencies indicates a decoupled state. It is strongly encouraged that units of logic (services) within SOA minimize their respective dependencies to whatever extent possible. This specific relationship has been termed “loosely coupled” and it is accomplished by limiting the dependencies between a service and its requestors to the information expressed in the service contract – and – designing the service contract in such a way that it is not necessarily specific to any one service requestor.
By consistently implementing this principle, newly built services establish a notable independence from each other. This allows an organization standardizing on SOA to accumulate an inventory of services that exist as relatively standalone units of logic which can be configured into new compositions, as required.
When creating multiple services in pursuit of establishing a service-oriented enterprise, these services can be categorized into specific service models. This allows them to become specialized in the type of logic they encapsulate. One increasingly important service model is the business service, which limits the logic a service represents to the accurate expression of a specific business context.
When standardizing on a set of service models, larger domains of an enterprise can be successfully abstracted. This effectively allows organizations to strategically establish loosely coupled relationships between specific areas of the enterprise by creating layers of services that represent the respective domains. In doing so, the benefits of loose coupling – most notably the increase in organizational agility it fosters – are amplified. This also demonstrates how service-orientation, as a paradigm, is not limited to the service-design level. Its principles can be broadly applied to areas throughout the enterprise.
