Service Autonomy Principle
Encyclopedia
Service Autonomy is a design principle that is applied within the service-orientation
design paradigm
, in order to services that have maximum control over their execution environment. This increases the reliability of the service as it can execute its functionality without relying on resources over which it has little or no control.
Service-orientation design paradigm emphasizes a lot on service reuse as dictated by the Service Reusability
design principle. This means that a service, which is being heavily reused, needs to guarantee its reliability as only a reliable service stands a chance of being reusable. However, in order to provide reliability, the service needs to have maximum control over the way it performs its functionality. This requires exclusive service logic and underlying implementation resources so that the service is not dependent upon external resources over which it has no control i.e. such external resources, whether shared service logic or a shared database, may not be available when required by the service.
Although the traditional component-based software development also faces the same autonomy requirement, however, the provisioning of autonomy and reliability, in such circumstances, is left to the actual runtime environment e.g. by providing failover support or by deploying a solution on dedicated servers. On the other hand, within service-orientation, the stakes are even higher as a service-oriented solution can be composed of services that exist outside of the organizational boundary. So in this case, it’s the design of the service itself that matters and the service needs to be designed in a way that it exercises maximum control over how it fulfills its functionality. The Service Autonomy principle attempts to provide guidelines for designing autonomous services so that the resulting services are more predictable and reliable.
The application of this design principle requires looking into two different types of autonomy in order to increase the overall autonomy of the service.
This type of autonomy refers to the independence with which the services could be evolved without impacting their service consumers. This type of autonomy is required as the service’s underlying legacy resources might need an overhaul or the service’s logic might need refactoring in order to make it more efficient.
The application of the Service Loose Coupling
and the Service Abstraction
principles helps in attaining design-time autonomy as their application results in services whose contracts are shielded from their logic and implementation and hence, the services could be redesigned without affecting their service consumers.
This type of autonomy refers to the extent of the control that a service has over the way its solution logic is processed by the runtime environment. The more control a service has over its runtime environment, the more predictable its behavior is. This type of autonomy is achievable by providing dedicated processing resources to the service. For example, if the service logic performs memory intensive tasks then the service could be deployed to a server that is not heavily shared by other services. Similarly, by providing locally cached copies of data, where applicable, the service’s dependency on a remote shared database can be removed. As a result the overall autonomy of the service is increased.
There exists a direct relationship between the runtime autonomy and the design-time autonomy. By increasing the design-time autonomy, the ability to evolve service’s implementation environment is automatically increased and hence more runtime autonomy.
Although increasing service autonomy to the maximum extent is always desirable, however, in reality it may not be possible to design each and every service with maximum design-time and runtime autonomy. As a result, the services need to be prioritized so that their autonomy could be addressed according to their value for business. This could be done by having a look at the type of the functional context contained by a service. Services whose functional contexts are independent of any particular business process i.e. entity and utility services, are good candidates for increasing their autonomy. This is because they contain functionality that is of interest to different types of consumers. On the other hand, business process specific services i.e. task and orchestrated task services, are less reusable and are dependent upon the individual autonomy of their composed services.
The provisioning of service autonomy may require additional infrastructure and hence it needs to be applied on as per need basis by prioritizing the services. On some occasions, services may need to be isolated and deployed in a customized and dedicated environment. This puts a lot of emphasis on making sure that the service is designed with the correct functional context as making fundamental changes to such a service might not be easy.
The autonomy of the services that encapsulate legacy resources can be hard to predict and increase. This may require additional analysis on part of the utility services as the achieved level of autonomy would depend upon the type of the functionality provided by the utility service.
Service-orientation
Service-orientation is a design paradigm to build computer software in the form of services. Like other design paradigms , service-orientation provides a governing approach to automate business logic as distributed systems...
design paradigm
Design paradigm
The term Design paradigm derives from the rather ambiguous idea of paradigm originating in Sociology of Science, which carries at least two main meanings:...
, in order to services that have maximum control over their execution environment. This increases the reliability of the service as it can execute its functionality without relying on resources over which it has little or no control.
Purpose
Service-orientation design paradigm emphasizes a lot on service reuse as dictated by the Service Reusability
Service Reusability Principle
Service Reusability Principle is a design principle that is applied within the service-orientation design paradigm, in order to create services that have the potential to be reused across the enterprise...
design principle. This means that a service, which is being heavily reused, needs to guarantee its reliability as only a reliable service stands a chance of being reusable. However, in order to provide reliability, the service needs to have maximum control over the way it performs its functionality. This requires exclusive service logic and underlying implementation resources so that the service is not dependent upon external resources over which it has no control i.e. such external resources, whether shared service logic or a shared database, may not be available when required by the service.
Although the traditional component-based software development also faces the same autonomy requirement, however, the provisioning of autonomy and reliability, in such circumstances, is left to the actual runtime environment e.g. by providing failover support or by deploying a solution on dedicated servers. On the other hand, within service-orientation, the stakes are even higher as a service-oriented solution can be composed of services that exist outside of the organizational boundary. So in this case, it’s the design of the service itself that matters and the service needs to be designed in a way that it exercises maximum control over how it fulfills its functionality. The Service Autonomy principle attempts to provide guidelines for designing autonomous services so that the resulting services are more predictable and reliable.
Application
The application of this design principle requires looking into two different types of autonomy in order to increase the overall autonomy of the service.
Design-Time Autonomy
This type of autonomy refers to the independence with which the services could be evolved without impacting their service consumers. This type of autonomy is required as the service’s underlying legacy resources might need an overhaul or the service’s logic might need refactoring in order to make it more efficient.
The application of the Service Loose Coupling
Service Loose Coupling
Within the service-orientation design paradigm, Service Loose Coupling is a design principle that is applied to the services in order to ensure that the service contract is not tightly coupled to the service consumers and to the underlying service logic and implementation...
and the Service Abstraction
Service Abstraction
Service Abstraction is a design principle that is applied within the service-orientation design paradigm so that the information published in a service contract is limited to what is required to effectively utilize the service i.e. the service contract should not contain any superfluous information...
principles helps in attaining design-time autonomy as their application results in services whose contracts are shielded from their logic and implementation and hence, the services could be redesigned without affecting their service consumers.
Runtime Autonomy
This type of autonomy refers to the extent of the control that a service has over the way its solution logic is processed by the runtime environment. The more control a service has over its runtime environment, the more predictable its behavior is. This type of autonomy is achievable by providing dedicated processing resources to the service. For example, if the service logic performs memory intensive tasks then the service could be deployed to a server that is not heavily shared by other services. Similarly, by providing locally cached copies of data, where applicable, the service’s dependency on a remote shared database can be removed. As a result the overall autonomy of the service is increased.
There exists a direct relationship between the runtime autonomy and the design-time autonomy. By increasing the design-time autonomy, the ability to evolve service’s implementation environment is automatically increased and hence more runtime autonomy.
Service Autonomy and Service Types
Although increasing service autonomy to the maximum extent is always desirable, however, in reality it may not be possible to design each and every service with maximum design-time and runtime autonomy. As a result, the services need to be prioritized so that their autonomy could be addressed according to their value for business. This could be done by having a look at the type of the functional context contained by a service. Services whose functional contexts are independent of any particular business process i.e. entity and utility services, are good candidates for increasing their autonomy. This is because they contain functionality that is of interest to different types of consumers. On the other hand, business process specific services i.e. task and orchestrated task services, are less reusable and are dependent upon the individual autonomy of their composed services.
Considerations
The provisioning of service autonomy may require additional infrastructure and hence it needs to be applied on as per need basis by prioritizing the services. On some occasions, services may need to be isolated and deployed in a customized and dedicated environment. This puts a lot of emphasis on making sure that the service is designed with the correct functional context as making fundamental changes to such a service might not be easy.
The autonomy of the services that encapsulate legacy resources can be hard to predict and increase. This may require additional analysis on part of the utility services as the achieved level of autonomy would depend upon the type of the functionality provided by the utility service.