In computing, service composability is a design principle, applied within the service-orientation design paradigm, that encourages the design of services that can be reused in multiple solutions that are themselves made up of composed services. The ability to recompose the service is ideally independent of the size and complexity of the service composition. [1]
This principle is directly responsible for the agility promised by SOA as it promotes composing new solutions by reusing existing services. [2]
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 to provide the agility promised by the SOA. As a result of this emphasis, some guidelines are required 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 provided 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 the service composability principle requires designing services 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. [2]
For the service to provide this dual functionality, the service contract [3] must be designed 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 must 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 makes the services interoperable with others, and helps to keep the composition design simpler by avoiding the need to perform runtime data model transformation. [4] 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 [5] 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.
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 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. [6] This way the service can evolve while providing backward compatibility.
Some of the factors that determine the composability potential of a service include: [7]
In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.
Service-orientation is a design paradigm for computer software in the form of services. The principles of service-oriented design stress the separation of concerns in the software. Applying service-orientation results in units of software partitioned into discrete, autonomous, and network-accessible units, each designed to solve an individual concern. These units qualify as services.
Service-orientation design principles are proposed principles for developing the solution logic of services within service-oriented architectures (SOA).
In the domain of the service-orientation design paradigm, the Enterprise Inventory is a design pattern by Thomas Erl that answers the question, "How can services be delivered to maximize recomposition?"; the application of this pattern results in a standardized enterprise-wide service inventory that fosters repeated service composition.
Within the service-orientation design paradigm, Service Refactoring is a design pattern, which is applied to an existing service so that either the service logic or its implementation can be changed without affecting the service consumers.
The event-driven messaging is a design pattern, applied within the service-orientation design paradigm to enable the service consumers, which are interested in events that occur within the periphery of a service provider, to get notifications about these events as and when they occur without resorting to the traditional inefficient polling based mechanism.
The standardized service contract is a software design principle applied within the service-orientation design paradigm to guarantee that service contracts within a service inventory adhere to the same set of design standards. This facilitates standardized service contracts across the service inventory.
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 The service contract should not contain any superfluous information that is not required for its invocation. Also that the information should be limited to the serviced contract only, no other document or medium should be made available to the service consumers other than the service contract that contains additional service related information.
The service reusability principle is a design principle, applied within the service-orientation design paradigm, to create services that can be reused across a business. These reusable services are designed so that their solution logic is independent of any particular business process or technology.
Service autonomy is a design principle that is applied within the service-orientation design paradigm, to provide services with improved independence from their execution environments. This results in greater reliability, since services can operate with less dependence on resources over which there is little or no control.
Service statelessness is a design principle that is applied within the service-orientation design paradigm, in order to design scalable services by separating them from their state data whenever possible. This results in reduction of the resources consumed by a service as the actual state data management is delegated to an external component or to an architectural extension. By reducing resource consumption, the service can handle more requests in a reliable manner.
Discoverability is the degree to which something, especially a piece of content or information, can be found in a search of a file, database, or other information system. Discoverability is a concern in library and information science, many aspects of digital media, software and web development, and in marketing, since products and services cannot be used if people cannot find it or do not understand what it can be used for.
Domain Inventory is a design pattern, applied within the service-orientation design paradigm, whose application enables creating pools of services, which correspond to different segments of the enterprise, instead of creating a single enterprise-wide pool of services. This design pattern is usually applied when it is not possible to create a single inventory of services for whole of the enterprise by following the same design standards across the different segments of the enterprise. The Domain Inventory Design pattern by Thomas Erl asks, "How can services be delivered to maximize recomposition when enterprise-wide standardization is not possible?" and is discussed as part of this podcast.
Service normalization is a design pattern, applied within the service-orientation design paradigm, whose application ensures that services that are part of the same service inventory do not contain any redundant functionality. This design pattern emphasizes on creating normalized services, much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.
Logic Centralization is a design pattern, applied within the service-orientation design paradigm, whose application aims to increase the reusability potential of agnostic logic by ensuring that services do not contain redundant agnostic logic and that any reusable logic should only be represented by a service that has the most suitable functional context.
Service layer is an architectural pattern, applied within the service-orientation design paradigm, which aims to organize the services, within a service inventory, into a set of logical layers. Services that are categorized into a particular layer share functionality. This helps to reduce the conceptual overhead related to managing the service inventory, as the services belonging to the same layer address a smaller set of activities.
Canonical Protocol is a design pattern, applied within the service-orientation design paradigm, which attempts to make services, within a service inventory, interoperable with each other by standardizing the communication protocols used by the services. This eliminates the need for bridging communication protocols when services use different communication protocols.
In software engineering, Canonical Schema is a design pattern, applied within the service-orientation design paradigm, which aims to reduce the need for performing data model transformation when services exchange messages that reference the same data model.
Entity abstraction is a design pattern, applied within the service-orientation design paradigm which provides guidelines for designing reusable services whose functional contexts are based on business entities.
In the context of software engineering and software architecture, service granularity is a key design concern when applying the paradigm of service-orientation for instance during service-oriented modeling. Service granularity specifies the scope of business functionality and the structure of the message payload in a service operation that is provided within a service-oriented architecture (SOA).