In his book SOA Design Principles [Erl 2008] Erl promotes the principal of Standardized Service Contracts. “Services within the same service inventory are in compliance with the same contract design standards. ... Services with Standardized contracts increase interoperability with reduced need for data transformations and provide a consistent understanding of service functionality. The service contract is standardized through application of design standards.”

There is no industry-wide service contract standard. Hence an enterprise or domain should establish a contract standard for their enterprise or domain. Most organizations will use XML and Web services standards for this purpose. There are several benefits to using these as a foundation for service contracts:

• International Standards

• Hides implementation language

• Good tooling support

• Human readable messages

• Reduce vendor dependency

However the use of XML and Web services standards requires expertise in XML Schema, WSDL, WS-Policy, etc. The biggest drawback to XML and Web services however is the slower performance due to eventual transformation to Java objects (or other language) for the implementation of the actual business logic and / or persistence operations. Customers that choose Java as the basis for their contract language however, will break loose coupling by exposing their implementation language and increase their risk of vendor lockin.

Service contracts should specify the tasks that a service can perform and the messages that a service can receive. If design standards are based on XML and Web services, this implies the use of standards such as XML Schema, SOAP, WSDL, and possibly WS-Policy and other WS* standards.

As well as the selection of particular standards, the style of the interfaces need to be agreed within an enterprise or domain. For example, one approach to the use of WSDL and XML in SOA is that service contracts are maintained and enforced in the message, not in the interface. This promotes loose-coupling and re-usability of services by making it easier to modify the service implementation logic without impacting the service interface. This has implications on how WSDL and XML Schema are used: it implies a single-operation WSDL with the bulk of the contractual information is in the XSD.

The service contract should support the specification of SLAs (e.g. performance, reliability, available, etc), using standards such as WS-Policy.

Standardized contract definition goes beyond choosing standards, it also implies standardizing on the use of these standards. For example, developing a set of standardized, “canonical” message schema's for use within a business domain or enterprise.As part of designing the message schemas, the sample messages should be reviewed and expanded based on knowledge of domain model (for an entity service) and business logic requirements (for other types of services). Examine existing message schemas to determine if they can be used as is or slightly modified to support this new service. If an existing schema cannot be used, create a new message structure (xsd file). The use of include  and import statements to put common elements in a single file and reduce redundant element definitions is also recommended as part of design standardization.

Once the message schemas have been defined, it may be necessary to modify the sample messages to use the new message structure, and re-vise / re-run scenarios and choreographies. Once validated, the message schemas should be saved in the Service Repository.

Details

Repo: Store generated service contracts and additional/enhanced message schema. Define dependencies between contracts/message schema and the service model.

Input: Service model

Output: Derived service contracts (e.g. WSDL or BPMN2 service interface) and message schema (information models).