Business Ecology Initiative & Service-Oriented Solution

The principle of Service Autonomy is a relatively complex matter. It requires deep understanding of the service nature.

Let us start with the history. Initially this principle was defined as 'services are autonomous'. This is a quite straightforward definition. However, if we try to apply it to the most of existing services, we immediately find that there are three categories of autonomy:

1) pure autonomy, where the service owns and controls all used components and resources (a rare case in practice);
2) service-level autonomy, where the service does not own and control some of its resources;
3) contractual autonomy, where service autonomy is based on service contracts with others

That is, in reality, we have very few pure autonomous services. Moreover, the power of SO is not in autonomy but in the service combinations and compositions, i.e. in the contractual autonomy, which hardly may be called 'autonomy'. Modern definition of the principle says: 'Services exercise a high level of control over their underlying runtime execution environment'; but how 'high' this 'high level of control' is, what is the measure and who is the judge?

Certainly, the principle of Service Autonomy is exceptionally important for SO; this is why it should not be that subjective as the formula of 'high level of control' allows. In the absence of the measure, some developers went with an extreme: I saw rephrasing of this principle definitions in the form like this 'Services control over their underlying runtime execution environment', which is totally mistaken if we hope on having compositions of the services and represent them as composite services. Another explanation of the principle such as 'The more control a service has over its underlying runtime implementation, the more predictable its runtime behavior will be' does not help much as well because it misses the role and effect of service Execution Context (EC). Even a purely autonomous service should change their behaviour if related run-time policies/EC change.

One of the most dangerous things we have to avoid when dealing with service autonomy is the absence of control over the used resources. For example, if we use the service-level autonomy where the service, e.g., consumes data from a shared data-store, the mandatory element of such service design is the contract with the data-store. The contract has to define minimal but guaranteed number of concurrent connections available to the service on-demand, a range of acceptable response time values, schedule of data-store availability and a like. If the service design, on the contrary, assumes usage of the data-store silently, without a contract, it risks sporadic failures caused by potential mismatch between the service needs and data-store capabilities.

This short observation leads me to the following conclusion: promoting flexibility of SO solutions and their adaptability to the modern fast changing environment, we need to modify the name and the definition of the principle under discussion. Particularly, we can formulate a principle of Service Relative Autonomy as 'Services exercise a relative level of control over their underlying runtime execution environment; if the service does not own or control used entities such as resources or other utilised services, the service must posses contractual control over the use of those entities'. The principle is named 'Relative Autonomy' because there is no such thing as absolute autonomy for the services and we have to highlight this fact right in the name (assuming that some people will not have enough time for reading the explanations). The definition of the principle refers to the relative level of control over the underlying runtime environment to outline that each service controls only the functionality it implements explicitly while the service execution context - run-time policies - may be controlled by other entities as well as the other services and resources utilised or engaged by the service. Also, the definition points onto the 'must have' contractual relationships with the service's elements that are not under the direct control of the service.

This principle prevents SOA services from the tendency known in the process-oriented environment - each process tends to own all its business logic, activity providers with their products and all used resources. This ownership assures the process owner that the process execution may be controlled in full to prevent any possible disturbances that can threat the stability of the process. SOA service welcomes multiple dependencies on the contractual basis because it provides for more flexibility (than in the modern understanding of the process) to engage needed service help on demand and on the SLA; if an engaged service is not adequate to the consumer needs, the service may be (should be) replaced at once.

As T. Erl says, 'The autonomy of individual services is especially important to the effectiveness of service compositions'. If we head toward pure autonomy, all our compositions will head to the two-layered structures where a composition layer situates on the top of purely autonomous services. Such structure is oversimplified and incapable of modelling real business world. If we intend to model real business, we have to stress a hierarchy of service compositions where the pure autonomous services position at the very bottom and all service layers above use only contractual-based autonomy.

(to be continued)