SO principle of Service Loose Coupling is one of the most powerful ones. According to SOA: Principles of Service Design (by T. Erl) book 'Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment'. The first and the most obvious consequence of this principle is that all Web Services (somehow called 'services' by many developers) that are automatically generated out of programming classes in Java, or C#, or C++, etc. do violate this principle and may not be considered as services in SOA.
The more tricky part is about 'themselves decoupled from their surrounding environment'. Matter is in that service contracts, derived from service description, inherit some parts of the service Execution Context. The latter comprises interaction, i.e. communication and execution, policies that, actually, are the part of 'surrounding environment'. We can talk about decoupling in this case only in the sense of separating policies from the service implementation. However, behaviour of the service, its results, i.e. business functionality and RWE, depend directly on those policies.
The role and influence assigned to the service Execution Context demand refining the definition of the Service Loose Coupling principle. Particularly, it may be formulated as follows: 'Service contracts impose low consumer coupling requirements and are themselves loosely decoupled with their surrounding environment via execution contexts'.
This leads us to another SO principle - principle of Service Abstraction. As stated by principle of Service Loose Coupling, 'Service contracts impose low consumer coupling requirements', i.e. consumer should not be tied to the service in other way than via sharing the comprehension of the service description and service contract. The principle of Service Abstraction describes what kind of information the service contract might contain: 'Service contracts only contain essential information and information about services is limited to what is published in service contracts'.
Based on contemporary knowledge about SOA and, especially, about existing and emerging SO standards, I can say that there are regular cases where service consumer knows and has to know more about the service than the information included into the service contract. This statement relates to the standardised definition of service description, which represents the document telling the consumer about the service. By using the information in the service description, the consumer is supposed to make a decision whether offered business functionality and service results (RWE) - service capabilities - can satisfy the consumer's needs. If decision is positive, then the consumer communicates with the service provider to define an agreement about the service use, i.e. the service contract. The content of the service contract may incorporate either entire service description or a subset of it. For example, a service description may contain five different interfaces for different communication media and different audiences while the contract derives and contains only two interfaces. This does not necessary mean that other interfaces become unavailable to the consumer. However, if this consumer tries to contact the service via non-agreed interfaces, the service is not obliged to respond.
As you can see, a service consumer may know more about the service than is written in the service contract. This means that the definition of the principle of Service Abstraction has to be modified and, for example, formulated such as: 'Service contract only contains essential service information that is agreed between service provider/owner/steward and service consumer. The information has to be sufficient for interacting with the service, utilizing agreed service functionality and reaching agreed Real World Effect'. I say 'reaching ' instead of getting, or obtaining, or returning because service result - Real World Effect - may be not necessary returned to the consumer but may become available via different information access means.
Thus, service contract abstracts service implementation and defines the scope of the agreement between service consumer and service provider/owner/steward on the service usage in particular service Execution Context.
I think there is a need for new principle about service Execution Context. It its absence, I can only say that the service functionality and RWE offered by the service provider may be guaranteed only in particular Execution Contexts. If a consumer wants to use the service in new Execution Contexts or if changes in the environment cause changes in the previously known Execution Contexts, the service has to be, at least, re-tested in this new Execution Context before the consumer can rely on the service functionality and RWE. This affects service reusability, service management, relationship management between service provider and consumers as well as the service development/delivery process.
Leave a comment