Abstract: This is the second article in a two-part article series. Read the first part of this article here.
In some cases, as the consumer requirements shift towards more complex functionality, they cannot be fulfilled by a simple atomic service. This shortcoming can be handled by service composition, that is the appropriate combination of certain atomic services in order to achieve a complex goal. There are several kinds of service composition. Traditionally a manual approach is used where an analyst tells the system which services should be executed in which sequence. Processes are defined using a process execution language like BPEL. This invocation plan is pretty fixed at design time although business rule engines can be used to route through the plan based on parameters only known at runtime. The problem with this approach is that it demands a major effort of the analysts and the task becomes more and more challenging with the explosion of services. Today's BPEL based solutions are not capable of fulfilling the flexibility requirements organizations have. The BPEL process is not aware of changes in its environment meaning that it will not look for a compatible service in case a specific service appears to be unavailable, except in the case where the analyst provided an alternative route which in turn is again fixed at design time. But frankly speaking today's orchestration engines are not built with the same runtime agility in mind. On the other hand these tools provide flexibility in that new orchestrations can be conceived at-design time (cfr. graphical modeling environment).
Another approach is called semi-automatic composition. This approach does not make use of a predefined process model. Instead, the consumer has a goal and a set of constraints. It is based on finding services that are able to fulfill parts of the consumer's goal and the creation of a plan that defines the service invocation sequence. In this kind of composition the system typically helps the consumer to find, filter and integrate the desired services by matching the consumer's goal with the capabilities of the advertised services. In addition, the system enables the user to intervene continuously during the composition process. At the end the composition engine comes up with a process definition that should fulfill the consumer's goal; in the other case, the system will indicate that, on the basis of the available services, no composition solution could be found.
Figure 4 – Directed acyclic graph, representing a service invocation plan
In the figure RI, RO, RE and RP are the request input, output parameters, effects and pre-conditions respectively. CO and CE are the composition outputs and effects respectively. For the composition engine only RI, R0 and RP are relevant.
A service at any stage of the composition can potentially use all the outputs from its predecessors as well as the inputs provided in the request. The services in the first stage of the composition can only use the inputs comprised in the request. The union of the outputs produced by the services in the last stage of the composition should contain all the outputs that the request requires to be produced. Also the effects of the services at any stage in the composition should imply the pre-conditions of the services in the next stage.
In other words, the engine should, based on the given consumer outputs (RO), construct an invocation plan for which the outputs of the last stage semantically match the requested inputs (RI) and the composition's effects should fulfill the required preconditions (RP) of the consumer in order to be a valid composition plan. When the number of nodes in the composition is equal to one, the composition problem is reduced to the discovery problem.
To make the composition concept more imaginative, let's consider the following example:
Suppose you are looking for a service to by a book and the service inventory contains the GetISBN, CheckStock, CheckCreditCard and the PurchaseBook service. Based on the table below, none of these services can fulfill the goal of the consumer on its own.
The first step to be performed by the composition engine is finding the set of composable services using the discovery process as discussed in the previous chapter.
The different members of the service composition are selected and composed together by applying the correct execution sequence (or any other workflow construct).
After a solution is obtained, the semantic description of the new composite service is generated using the composition language OWL-S. OWL-S establishes a framework for semantically defining composite processes or services. A composite process according to OWL-S is a set of atomic processes, combined together using a collection of control flow patterns, such as sequence, split, split + join, choice, any-order, condition, if-then-else, iterate, repeat-while and repeat-until. These constructs are used within the invocation plan in order to be able to define compositions as compact as possible, to facilitate the use of alternative message paths and to speed up the execution of the composition by allowing multiple atomic services to be invoked concurrently.
The generated semantic description of the composition service can be registered in the repository and is thus available for future searches. The composite service can now be discovered as a direct match instead of having to look through the entire repository and building the composition solution again.
For runtime service discovery and late-binding to be effective in the case of composite services, a QoS-aware discovery and composition mechanism is indispensable. This means that the services being discovered not only perform the requested functionality but also contribute to achieve the level of quality of service the consumer requested or formalized in Service Level Agreements (SLAs). There are a number of criteria (execution time, availability, cost, success rate, reputation, ...) that contribute to a service's QoS in a SLA. Service providers can publish this QoS information in SLA documents or in their service descriptions.
A composite service results from the composition of atomic services, thus it is necessary to determine the set of services so that the composite service QoS is optimized and meets the SLA. The composite service QoS can be computed according to aggregation formulae. A formulae is defined for each QoS attribute in relation to the workflow pattern(s) used within the composition. The calculation relies on estimates of service QoS criteria values and runtime monitoring information. The actual QoS values can vary from the estimated ones, meaning that the actual QoS of a composite service would not be the one agreed in the SLA. In order to avoid this the composition engine should rework the bindings between abstract and concrete services. Replanning is triggered if the SLA is violated or there is a high likelihood of violating it.
In order to enable automatic QoS-aware service selection, QoS criteria need to be modeled in the service description in a machine interpretable manner. The main goal is to allow semantic specification of these QoS constraints as part of the service profile. Integrating QoS features in the profile of the service is to the advantage of both consumers and providers. The service selection and composition that takes place, considers the consumer's non-functional requirements. On the other hand providers can get a competitive advantage in the e-business domain because QoS aware services better meet consumer requirements and thus attract more customers.
The need to develop a uniform way to represent the wealth of information concerning QoS parameters in a machine interpretable manner has appeared. Quality attributes of services are described by concepts from a QoS ontology. The most important part of such an ontology links the concept of "QoS criteria" and "service". QoS specification languages were frequently the subject of research projects, however no real standard for specifying requested and offered QoS has emerged. Such an ontology can be seen as an upper level ontology which extends OWL-S. Hereby this ontology can be enhanced by providing concrete classes to act as "ServiceParameters". The service discovery and composition process can then take these QoS ServiceParameters combined with the actual values at execution time into account in order to perform a QoS-aware service selection and ultimately leading to a self-adapting QoS-driven solution.
After having read this article, it should be clear that semantic technologies can extend the level of automation in a service oriented architecture dramatically and support the service discoverability and composability principles. As a result the runtime flexibility and adaptability is maximized.
It is mentioned multiple times that ontologies are a key component of semantically enabled service oriented architectures. Therefore, we must not forget that appropriate semantic descriptions for the available services are a pre-requisite for this kind of solutions. Although techniques supporting the creation of semantic descriptions of existing services or legacy systems are essential, this challenge only received little attention in the research community so far. In addition to this, commonly used standard ontologies do not exist or are not easy to find. All this, however, should not stop architects and designers from considering semantic technologies in their solutions so as to be prepared for future challenges in e-business.
I wish to thank my colleagues Jan De Bo and Steve Van Den Buys who reviewed and critiqued my article.