As I mentioned in the Part 1, the description of the principle defining service contract has changed from 'services share a formal contract' to 'Standardized Service Contracts'. The book SOA: Principles of Service Design (by T. Erl) states: 'Services within the same service inventory are in compliance with the same contract design standards' while explanation words have not changed much from 2006 and 'When a service is implemented as a Web service, the service contract can be comprised of a WSDL definition and multiple XML schema and policy definitions, as well as supplementary documents, such as an SLA.' Following description does not clarify more what the principle is about but rather how it might be used.
I think you have caught significant difference in the formulations. The initial requirement of sharing formal contract did not sustain presence of an intermediary like ESB, I guess. Also, it is not clear why services have to share the contract among them instead of sharing it with consumers whatever these entities are (i.e. another service or just a consumer). In this context, sharing contract means understanding of and agreement on the contract. The only thing is not defined here is what the contract is.
Rather than defining service contract, we have an immediate reference onto the implementation technology like Web Service, which cannot replace formal definition of the conceptual thing but only illustrate it. What the contract is if Web Service is not used? Even if we use Web Service, I see two problems in such example.
Firstly, 'supplementary documents' are unknown. Since etymology of the word 'contract' assumes 'agreement', presence of undefined documents prevents us from formalising and standardising the contract. The only one thing we can do in this situation is what OASIS SOA standards do: define the types of information that may be placed in to the service contract. Secondary, I do not think there are many people who would disagree with me if I say that WSDL defines a type of interface called Web Service. If so, how should we understand the statement such as 'When a service is implemented as a Web service '? How a service may be implemented as an interface? An interface is a means of connectivity to something, which is faced; an interface can provide neither business functionality nor Real World Effect (RWE) - the only two things that any consumer is interested in from a service. Buy the way, these two major things are, probably, have to be provided by the 'supplementary documents'. This means that service contract semantics and related ontologies have to be shared between the service and consumer but an attempt to standardise semantics and ontologies is a utopia similar to standardisation of people minds.
Talking about service contract, I cannot miss the notion of service description. An agreement between service provider and consumer has to be based on something, the service has to be announced and found to be used. This is the sphere of the principle of Service Discoverability, which we will look at later, but OASIS SOA has specified a natural dependency between service description and service contract in the SOA RM standard.
In particular, service description is a document, which expresses the offer of the service made by the service provider. If you want, service description contains meta-data about the service. This meta-data may be announced via service registries or other means. This is the meta-data that has to be discovered by the service consumer to decide whether the service capabilities can satisfy consumer's needs. If such match is found, the consumer should be able to find all necessary information in the service description to set the service contract and to physically invoke the service.
So, the most part of the service contract's content is derived from the service description. However, since the service contract is a mutual agreement, consumers have an opportunity to negotiate their own requirements to be preserved by the service. These requirements appear in the form of consumer's policies, which may be included into the contract. For example, such policy may state that only certain type of information should be exchanged with the service via SSL while the service description offered 'clear' and encrypted communication channels but did not mention a capability to mix them on the content basis.
Mentioned explanation of the 'Standardized Service Contracts' via reference to the 'service inventory' confuses me a bit. This explanation drifts from service-consumer interactions into the service registration (inventory) sphere. Certainly, it would be a paradise for the registry management if all submitted services were compliant with 'the same contract design standards' but how much service orientation in this requirement? Is this a principle of Service Orientation or a pre-requisite of the service inventory (even if it is not a registry but an arbitrary composition of the services)? Do we really care what design standards were used for particular service contract if we can understand what is it about? Moreover, service contracts are derivatives negotiated by the consumers or by the developers of the service inventory. That is, standardisation of the service contract is really subjective matter and works for the convenience of the service inventory (registration) management, e.g., another service inventory may require different standards to be used for the same service contract.
Thus, a contract between service (service provider) and service consumer may be standardised only at the level of content types and mechanisms that can help to share understanding of what the service provider meant when formulated offered business functionality, RWE, policy statements and semantics of exchange messages. This line of logic leads me to the conclusion: the principle of Service Orientation regarded to the service contract has to
1) talk about relationship between contract participants, i.e. service provider/service and service consumer;
2) require formalisation and standardisation of the contract parts or types of contained information;
3) require or define a mechanism allowing comprehension of the contract by the contract participants.
On this basis, we, maybe, better call this principle 'Standardized Definition of Service Contracts' meaning, first of all, the shared comprehension of the contract between service provider and consumer regardless to any service inventories or, more general, any SOA infrastructure and run-time environment. The principle definition in this case may be formulated as follows: 'Service contracts are in compliance with the standardised definitions of the contract content types and represent mutual agreements between service provider/own/steward and service consumers '.
Leave a comment