The agility promised by a service-oriented architecture is usually measured in terms of the reusability level of its contained services. However, this reusability relates directly to the way the service contract defines service capabilities. A service built on a potentially reusable functional context but with a contract that does not convey this reusability correctly does not achieve its reusability potential. Within service-oriented solutions, a service contract represents a fundamental artifact, as this is the only medium through which services interact with each other or other consumer programs. This creates a strong need to standardize the service contracts in order to make services reusable and recomposable as much as possible. In order to achieve this, the standardized service contract design principle needs to be applied as its application results in standardized service contracts that are based on design standards as set within a service inventory. One of its goals is to reduce the need for data transformations as two services interact with each other, which can be achieved if the service contracts use standardized data models e.g. XML schemas if the services have been implemented as web services. This also helps in making services more interoperable. Another important goal of this design pattern is to use a standardized way of expressing service capabilities so that their purpose and ability can be easily understood at design time.
Application
A technical service contract is usually composed of a WSDL document, XML schema and policy document. Consequently, this principle needs to be applied across three areas of a service contract as described below:
Functional expression standardization
The service's operations need to be defined using standardized naming conventions. This would also apply to the constituent input and out message names and their corresponding type names. This helps to increase the service contract's correct interpretation, which in turn increases service’s reuse and interoperability. When service contracts clearly express their capabilities, the chance of service duplication is also reduced.
Two services exchanging messages based on the same type of data—e.g., a purchase order—might model that data according to different schemas, which requires data model transformation. This clearly adds overhead, and stands in the way of service interoperability and reuse. To avoid this transformation, the standardized service contract principle requires standardized data models, which further helps create a standardized data representation architecture that can be reused across the enterprise to define standardized service capabilities. Schema centralization directly supports the objectives of data model standardization design pattern, which further supports creation of centrally governed schemas.
Policy standardization
Service policies represent terms of use for a service. So, for a service to be reusable, its behavioral requirements must be expressed consistently using standardized policy expressions based on industry standard vocabularies. This type of standardization further promotes separation of policies from service contracts into individual policy documents, which facilitates centralized governance. In some cases, two policies, though syntactically different, might mean the same thing—therefore, design standards must dictate acceptable policy structure.
Considerations
Application of this design principle depends on design standards at the service inventory level. This requires additional resources, in terms of time and effort. Secondly, to apply this design principle effectively, the actual contract must be physically isolated from the service logic and implementation so that it can be based on industry standards. This can be achieved by the application of a decoupled contract design pattern. Also that the ‘contract first’ approach needs to be followed so that the underlying logic only makes use of standardized data models. Furthermore, the requirement for centralized data models may end in transmission of redundant data between services, as the actual data a service needs may be only a subset of the data defined in the standardized schema imposed on the service.
