Standardized service contract
The standardized service contract is a software design principle[1] applied within the service-orientation design paradigm to guarantee that service contracts[2] within a service inventory[3] (enterprise or domain) adhere to the same set of design standards.[4] This facilitates standardized service contracts across the service inventory.[5]
Purpose
The agility promised by a service-oriented architecture (SOA) 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[6] 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[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 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[10] 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[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 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.
References
- ↑ Design Principle
- ↑ Service Contracts
- ↑ Service Inventory
- ↑ Cellary, Wojciech; Strykowski, Sergiusz. "E-Government Based on Cloud Computing and Service-Oriented Architecture". ICEGOV '09. pp. 5–10. doi:10.1145/1693042.1693045. ISBN 978-1-60558-663-2.
- ↑ Michael Poulin.Evolution of principles of Service Orientation: Service Contract, part 2.Date accessed: 12 April 2010.
- ↑ The boundary of the service, i.e., the type of functions the service provides
- ↑ Tost. et al.Guidelines for Using Web Service Contract Technologies.Date accessed: 12 April 2010.
- ↑ kou-Kai Lin.A preliminary study on Service-oriented migration for a small-scale migration..Date Accessed: 10 April 2010.
- ↑ 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.
- ↑ Schema Centralization Pattern
- ↑ Decoupled Contract Pattern
- Mauro. et al. Service Oriented Device Integration - An Analysis of SOA Design Patterns., pp. 1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 8 April 2010.
- Erl, Thomas (2008). SOA Principles of Service Design. Prentice Hall. ISBN 978-0-13-234482-1.
- Paul-Alexandru Istoan.Software Product Lines and Service Oriented Architectures:can they be connected.Date Accessed: 10 April 2010.
- Youssef Achbany.A Multi-Agent Framework for Developing Adaptable and Open Service Systems.Date Accessed: 10 April 2010.
- Kjell-Sverre Jerijærvi.SOA Contract Maturity Model.Date accessed: 12 April 2010.
External links
 |  |
