This principle advocates the standardization of service contracts that exist within a given service inventory boundary (Figure 1).
Within this context, standardization can refer to the usage of industry
standards (such as WSDL and XML Schema), but primarily the focus is on
custom design standards that are pre-defined and regulated (such as
canonical data models).
Contract-First
To ensure that
contracts are consistently standardized requires that we seize
programmatic control over how contracts are created, which is the basis
of the contract-first approach that is predominantly used when applying this principle.
There
are various ways of going about contract-first development with .NET.
The primary consideration is in determining in what sequence to define
the various parts of a service contract.
For example, here is a common three-step process:
1. Create or Reuse Data Contract
A WCF data contract most
commonly exists as an XML schema that defines the data structure and
data types (as part of the overall data model) for a given set of data
that is exchanged by a service capability.
Following patterns, such as Canonical Schema and Schema Centralization,
this step may involve creating a new data contract to be used by one or
more services or it may involve reusing an already existing (and
standardized) data contract. The latter circumstance may be due to a
data contract that was previously customized or there may be a
requirement to use a data contract that exists as an industry standard
XML Schema (such as HR-XML or LegalML).
2. Create Message Contract
The body content of a given
message transmitted or received by a service capability is primarily
pre-defined by the data contract. The message contract encompasses the
data contract and further defines metadata in the message header, as per
Messaging Metadata . Message contracts within WCF are primarily built using the SOAP Body and Header constructs. Part of this step may also involve pre-defining fault contracts for exception conditions.
|
Prior to applying
any contract-first development approach, it is generally assumed that
some extent of service modeling has already been completed. The service
modeling process is part of the service-oriented analysis stage within a
service’s overall delivery cycle. Service modeling produces conceptual
services called service candidates
that form the basis of service contracts. Often significant up-front
analysis is carried out in order to define several service candidates
for a specific service inventory before physically building any one
service contract. This effectively creates a service inventory blueprint
that allows the basic parts of service contracts to be well-defined and
further refined through iteration, prior to entering the design and
development phases.
|
3. Create Interface Contract
The
interface contract is commonly equated to the abstract description of a
WSDL document wherein operation contracts are defined. When working
with REST services, the interface contract can be considered the subset
of HTTP methods that are supported as part of the overall uniform
contract for a given service.
The interface contract and
its operations or methods express the externally invokable functionality
offered by a service. An interface contract pulls together the data and
message contracts and associates them with appropriate operations or
methods.
Standardized Service Contract and Patterns
Beyond carrying out a
contract-first approach to service design, there are many more facets to
applying the Standardized Service Contract
principle. Several of these additional aspects will come up in the
subsequent sections exploring SOA design patterns related to service
interoperability.
