Service Composability Principle
Encyclopedia
Service Composability is a design principle, applied within the service-orientation
design paradigm
, which encourages the design of services in a manner so that they can be reused in multiple solutions that are themselves made up of composed services. The ability of the service to be recomposed should be independent of the size and complexity of the service composition.
This principle is directly related to the agility promised by SOA as it promotes composing new solutions by reusing existing services.
The concept of developing software out of independently existing components encourages the concept of composition. This is the underlying concept within object-orientation where the end product is composed of several interlinked objects that have the ability to become part of multiple software solutions, no matter how complex the solution is. The same composition concept is inherited by service-orientation, whereby a business process is automated by combining multiple services. However, within service-orientation there is even greater focus on building services that can be composed and recomposed within multiple solutions in order to provide the agility
promised by the SOA. As a result of this emphasis, some guidelines are required in order to develop services that can be effectively aggregated into multiple solutions.
The Service Composability principle provides design considerations that help towards designing composable services with a view to encourage service reuse as much as possible. The guidelines provides by this principle prepare the service so that it is ready to participate in service compositions without requiring any further design changes.
The application of this design principle requires designing services in a manner so that they can be used in a service composition either as a service that controls other services i.e. a controller service, or as a service that provides functionality to other services in the composition without further composing other services i.e. a composition member.
In order for the service to provide this dual functionality, the service contract needs to be designed in a manner so that it presents functionality based on varying levels of input and output data. In case if it is required to participate as a composition member, then usually the input parameters to the service would be more fine grained as compared to the situation when it is required to participate as a composition controller. A heavily reused service needs to be as stateless as possible (Service Statelessness principle
) so that it can provide optimum performance when composed within multiple service compositions.
The effectiveness of this principle depends upon the extent to which rest of the design principles
have been applied successfully. The application of the Standardized Service Contract
principle enables the services to be interoperable with other and helps to keep the composition design rather simpler by avoiding the need to perform runtime data model transformation. By applying the Service Loose Coupling
principle, a service could be recomposed with the confidence that it would not create any form of negative coupling with the other service in the composition. The application of the Service Autonomy
and the Service Statelessness
principles increase the reliability and availability of the service so that it be reused in multiple service compositions with increased confidence.
In order for the service to be an efficient service controller as well as a service member, the underlying technology architecture needs to provide a runtime environment that is scalable and can support the statelessness required by the service. Similarly as the service compositions increase in size, the storage and retrieval of the context data, related to the runtime interaction of the services, may need to be delegated to the runtime environment instead of the services managing this context data in order to make the service composition more efficient.
As more and more service compositions are built, there is a tendency of getting dependent on a service that is highly reused. This requires careful analysis during the design of the service compositions and considering alternate standby services for critical functionality. On the other hand, it may become difficult to evolve a service that is now become a part of multiple service compositions. This could be addressed by the application of the Concurrent Contracts design pattern that advocates maintaining multiple concurrent contracts for a service. This way the service can evolve while providing backward compatibility.
Some of the factors that determine the composability potential of a service include:
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:...
, which encourages the design of services in a manner so that they can be reused in multiple solutions that are themselves made up of composed services. The ability of the service to be recomposed should be independent of the size and complexity of the service composition.
This principle is directly related to the agility promised by SOA as it promotes composing new solutions by reusing existing services.
Purpose
The concept of developing software out of independently existing components encourages the concept of composition. This is the underlying concept within object-orientation where the end product is composed of several interlinked objects that have the ability to become part of multiple software solutions, no matter how complex the solution is. The same composition concept is inherited by service-orientation, whereby a business process is automated by combining multiple services. However, within service-orientation there is even greater focus on building services that can be composed and recomposed within multiple solutions in order to provide the agility
Agility
* Agility is a physical trait of an animal or person, and a component of physical fitness. It is the ability to change the body's position and direction with speed and precision.Agility may also refer to:In Sport:...
promised by the SOA. As a result of this emphasis, some guidelines are required in order to develop services that can be effectively aggregated into multiple solutions.
The Service Composability principle provides design considerations that help towards designing composable services with a view to encourage service reuse as much as possible. The guidelines provides by this principle prepare the service so that it is ready to participate in service compositions without requiring any further design changes.
Application
The application of this design principle requires designing services in a manner so that they can be used in a service composition either as a service that controls other services i.e. a controller service, or as a service that provides functionality to other services in the composition without further composing other services i.e. a composition member.
In order for the service to provide this dual functionality, the service contract needs to be designed in a manner so that it presents functionality based on varying levels of input and output data. In case if it is required to participate as a composition member, then usually the input parameters to the service would be more fine grained as compared to the situation when it is required to participate as a composition controller. A heavily reused service needs to be as stateless as possible (Service Statelessness principle
Service Statelessness Principle
Service Statelessness is a design principle that is applied within the service-orientation design paradigm, in order to design scalable services by freeing up the services from managing their state data whenever possible...
) so that it can provide optimum performance when composed within multiple service compositions.
The effectiveness of this principle depends upon the extent to which rest of the design principles
Service-Orientation Design Principles
The concept of service-orientation revolves around a set of principlesthat shape the development of the solution logic encompassed by a service. These principles are known as the service-orientation design principles....
have been applied successfully. The application of the Standardized Service Contract
Standardized Service Contract
The Standardized Service Contract is a design principle, applied within the service-orientation design paradigm, in order to guarantee that the service contracts within a service inventory adhere to the same set of design standards, which results in standardized service contracts across the...
principle enables the services to be interoperable with other and helps to keep the composition design rather simpler by avoiding the need to perform runtime data model transformation. By applying 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...
principle, a service could be recomposed with the confidence that it would not create any form of negative coupling with the other service in the composition. The application of the Service Autonomy
Service Autonomy Principle
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...
and the Service Statelessness
Service Statelessness Principle
Service Statelessness is a design principle that is applied within the service-orientation design paradigm, in order to design scalable services by freeing up the services from managing their state data whenever possible...
principles increase the reliability and availability of the service so that it be reused in multiple service compositions with increased confidence.
Considerations
In order for the service to be an efficient service controller as well as a service member, the underlying technology architecture needs to provide a runtime environment that is scalable and can support the statelessness required by the service. Similarly as the service compositions increase in size, the storage and retrieval of the context data, related to the runtime interaction of the services, may need to be delegated to the runtime environment instead of the services managing this context data in order to make the service composition more efficient.
As more and more service compositions are built, there is a tendency of getting dependent on a service that is highly reused. This requires careful analysis during the design of the service compositions and considering alternate standby services for critical functionality. On the other hand, it may become difficult to evolve a service that is now become a part of multiple service compositions. This could be addressed by the application of the Concurrent Contracts design pattern that advocates maintaining multiple concurrent contracts for a service. This way the service can evolve while providing backward compatibility.
Some of the factors that determine the composability potential of a service include:
- Ability to provide functionality at different levels within a business process.
- Message Exchange pattern
- Whether the service supports transactions and rollback/compensation features.
- Support for exception handling.
- The availability of meta-data about service capabilities and behavior.