Standardized service contract

The standardized service contract is a design principle,[1] applied within the service-orientation design paradigm, in order to guarantee that the service contracts[2] within a service inventory[3] (enterprise or domain) adhere to the same set of design standards,[4] which results in standardized service contracts across the service inventory.[5]

Purpose

The agility promised by an SOA is usually measured in terms of the reusability level of its contained services. However, this reusability is directly related to the way service capabilities have been defined within the service contract, as a service that is built upon a potentially reusable functional context[6] but whose contract does not convey this reusability in an appropriate manner is not going to achieve its reusability potential. Within service-oriented solutions, a service contract represents a fundamental artifact as this is the only medium through which the services interact with each other or with other potential consumer programs. Therefore, there exists 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[7] 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.[8]

Application

A technical service contract [9] is usually composed of a WSDL document, XML schema(s) and policy document(s). 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.

Data model standardization

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 is clearly an overhead and stands in the way of service interoperability and reuse. In order to avoid this transformation, the standardized service contract principle requires developing standardized data models, which further helps in the creation of a standardized data representation architecture that could be reused across the enterprise for defining standardized service capabilities. The objectives of data model standardization are directly supported by the Schema Centralization[10] design pattern, which further helps in the creation of centrally governed schemas.

Policy standardization

Service policies represent the terms of usage for a service. So in order for a service to be reusable, its behavioral requirements need to be expressed in a consistent manner using standardized policy expressions that are based on industry standard vocabularies. This type of standardization further promotes separation of policies from the service contracts into individual policy documents in order to allow centralized governance. In some cases, two policies, although syntactically different, might mean the same thing, therefore, design standards need to be in place that dictate the acceptable policy structure.

Considerations

The application of this design principle depends upon the existence of design standards on the service inventory level. This would require additional resources in terms of time and effort. Secondly, in order to apply this design principle effectively, the actual contract needs to be physically isolated from the service logic and implementation so that it could be based upon industry standards. This could be achieved by the application of the Decoupled Contract[11] 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 up in the transmission of redundant data between services as the actual data required by a service may only be a subset of the data as expressed by the standardized schema imposed on the service.

References

  1. ↑ Design Principle
  2. ↑ Service Contracts
  3. ↑ Service Inventory
  4. ↑ Cellary, Wojciech; Strykowski, Sergiusz. "E-Government Based on Cloud Computing and Service-Oriented Architecture". Proceedings of the 3rd international conference on Theory and practice of electronic governance. ICEGOV '09. pp. 5–10. doi:10.1145/1693042.1693045. ISBN 978-1-60558-663-2.
  5. ↑ Michael Poulin.Evolution of principles of Service Orientation: Service Contract, part 2.Date accessed: 12 April 2010.
  6. ↑ The boundary of the service i.e. the type of the functionality provided by the service
  7. ↑ Tost. et al.Guidelines for Using Web Service Contract Technologies.Date accessed: 12 April 2010.
  8. ↑ kou-Kai Lin.A preliminary study on Service-oriented migration for a small-scale migration..Date Accessed: 10 April 2010.
  9. ↑ As services are usually implemented as web services so this article focuses on the application of this design principle within the context of web services.
  10. ↑ Schema Centralization Pattern
  11. ↑ Decoupled Contract Pattern

External links