We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Evolution of principles of Service Orientation: Service Autonomy, part 5

Vote 0 Votes

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)

Thumbnail image for Speaking_Qcon_London_03.jpg


| Leave a comment

I find this treatment of autonomy to be helpful in nuancing the (arguably) over-simplified treatments one finds elsewhere. However, I cannot unpack the sense of this part:

"The definition of the principle refers to the relative level of control over the underlying runtime environment to outline the principle of separation of concerns; the latter, e.g., requires separation between business functionality from the physical storing of the business data and assumes different ownership realms for them."

Is someone who believes they understand this able to render it in different words. I believe I understand what it means to separate the concerns of business functionality from "the physical storing...". However, I do not "get" the connection between separation of concerns and autonomy that is clearly at issue here.



Thank you, Andrew, I have changed the wording

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives