Several works have addressed the management of individual Web Services. However, the specific management requirements of workflow-based web service compositions such as those specified in the BPEL have not yet been considered. In this paper, we present several management requirements in web service compositions such as discovery and selection management, SLA and policy management, middleware services management, and management of the composite service. Supporting these requirements is crucial for providing a reliable service composition with well-defined QoS properties. We also introduce web service composition management and present our vision of having dedicated tool support for it in future BPEL engines.
1 SAP Research CEC Darmstadt
Darmstadt, Germany
Web services [
In this paper, we look at several management requirements in the lifecycle of web service compositions, which are mostly not supported by current composition tools. These requirements include discovery and selection management of partners, composition-side management of the QoS and middleware properties of the interactions with and within the composition, the management of the composite web service, the management and handling of the SLAs and policies of the services, and the management of business aspects.
We also define web service composition management (WSCM) as the management of the composite web service, the composition-side management of the composed services, and the management of the interactions that take place within and with the composition including their QoS properties. The definition of WSCM is not specific to BPEL but it works also with other composition languages. We merely assume the use of a workflow-based language to compose services that are described in terms of functionality and in terms of QoS. We will focus on BPEL because it is the standard for web service composition.
It is important to note that WSCM is different from web service management
because most existing works on web service management operate at the interface level,
i.e., on top of WSDL [
The contribution of this paper is two-fold. First, it outlines management concerns that are crucial but mostly not supported in current web service composition tools. Second, it defines WSCM and explains how it differs from web service management in general. Our vision is that future orchestration engines should provide WSCM capabilities. How the WSCM requirements can be implemented is out of scope. The remainder of this paper is organized as follows. Section 2 gives some background knowledge. Section 3 outlines the management requirements in web service based workflows and defines web service composition management. In Section 4, we report on related work. Section 5 concludes the paper. 2
In this section, we provide some background knowledge that is relevant for understanding web service composition management. 2.1
In Web Service Distributed Management (WSDM) OASIS defined a specification
called Management of Web Services (MOWS) [
Web service composition provides a means to create a value-added web service by combining existing web services. It spans two important areas: the specification by means of a composition language and the execution by means of an appropriate runtime. The specification of a web service composition consists in specifying a set of interactions between the composition and the composed web services as well as the control flow and data flow around these interactions.
The Business Process Execution Language (BPEL) is a process-oriented web service
composition language, in which a composite web service is implemented using a
workflow process. BPEL is widely accepted by research and industry and it was
recently accepted as an OASIS standard [
The activities are the units of work in the process. BPEL differentiates primitive activities and structured activities. Primitive activities are atomic whereas structured activities are composite. The core of a BPEL process is the set of atomic messaging activities (e.g., receive, reply, invoke), which perform interactions between the partners. The assign activity is used to modify the content of a variable. Structured activities such as sequence and flow contain other activities, structuring the latter according to control flow patterns such as sequential execution and concurrency.
Service Level Agreements (SLAs) and policies are the most used means to describe the non-functional properties of web services.
SLAs are widely established to guarantee Quality of Service (QoS) between Internet
Service Providers (ISP) on the network layer. Service Level Agreements (SLAs) are
bilateral contracts and defined in RFC 3198 [
We assume that we are building a composite service using a workflow-based web service composition language by orchestrating existing web services that are described not only in terms of their functionality (as supported by WSDL) but also in terms of QoS (as supported by SLAs and policies). Further, we assume that we have some requirements on the composite web service in terms of the QoS properties that it will guarantee to its clients.
We grouped several management requirements that arise when creating and deploying web service compositions into the following categories:
Service composition is generally used to solve a complex problem or implement a complex business process. The complex task of the composite web service is divided into smaller tasks that can be performed by existing services.
Discovery Management is about finding appropriate web services to build the
composite web service. This activity takes place primarily at design time but can also
take place at runtime. Depending on the type of service to be used, discovery is done
in various ways. For instance in the case of business-to-business integration the
partner organizations tell each other about the services they expose. In the case of
enterprise application integration the system administrator of the enterprise knows about
the services that wrap a certain application. In other cases, partner web services are
discovered by searching internal and external UDDI registries. A prerequisite for an
appropriate discovery is a sufficient description of partner web services.
At first, the discovery management component of the web service composition tool
has to consider the functionality (business match) and find web services that match
the port type of each partner (e.g., make an offer for CPUs). The business match is
based only on the syntax and it can be improved by using some semantic web
services technology such as OWL-S [
When creating a new web service it is often the case that there are certain QoS
requirements on that new service. For instance, the creator of the composite service
may require a response time of 2 ms to be guaranteed. Inferring QoS criteria for the
individual services to be composed in terms of their SLAs and policies is a complex
task that requires tool support. Another example is that the creator of a composite
web service may have some transaction requirements that need to be translated to
requirements on the individual web services. In the case of BPEL, the programmer
may specify that a certain sequence with nested invoke activities has to be
transactional (e.g., using a deployment descriptor [
In addition to the static specifications of QoS properties, the history, i.e., the runtime behavior, of a web service is sometimes necessary for the selection. For instance, if the SLA of some service specifies an availability of 80% then selection management has to gather information about each call, i.e., it has to record the run-time behavior of web services to decide which web service should be invoked. Therefore, the history of web services executions should be stored in a database. Selection based on SLAs, policies, and history can be combined. 3.1.2
In several composition languages including BPEL, the composition is exposed as a new web service, which needs to be managed like any other web service. Typical management concerns in web services are lifecycle management, the startup and the shut down of the service, the number of instances, the ability of the service to provide information about itself, its identity, its current load, the number of messages it is currently processing, its dependencies on other services, error handling, forwarding of errors to some third party, etc. Since the composite web service is implemented using a workflow process (e.g., a BPEL process) we need to understand what does each management concern means in terms of constructs of the workflow language, e.g., what is the relationship of service instances to process instances what is the number of messages the composite service is processing at a certain point in time. As the lifecycle is rather implicit in BPEL, when we deploy a process we start the composite service but the process might have not started yet. The service can be shutdown by undeploying the process. Moreover, the current load of the composite service can be inferred from the number of process instances1.
Fault handling is another important management issue in composite web services, e.g., if an error occurs during the execution of an operation of the composite service, it is important to identify the source of that error (whether it is a process error, an error in one of the composed services, an error in the client messages, a network error, etc). Some kind of process debugger (i.e., a tool that shows the execution state of each process instance and the values of each variable) would be very helpful to identify the source of the fault so that user can fix it and then redeploy the process. To establish a reliable composition several QoS properties of the composite web service have to be addressed such as:
Availability: Availability of a composite web service means the probability that all web services involved in the composition are available when invoked by the workflow process. A web service is considered available if it is able to respond to a request within a defined time interval.
Performance: It can be measured by the throughput and the response time. Throughput means the number of requests that can be processed during a defined time slot. In the case of BPEL processes throughput depends not only on the number of process instances that can run simultaneously but also on the number of 1 Some BPEL engines already provide this information in their management module. messages that one process instance can consume2 and on whether BPEL-specific concepts such as message correlation are used. In fact, the same process instance with correlation may be able to process multiple client requests (e.g., one for logging in, one for searching for a product, one for placing an order, etc). The response time is the sum of transmission time and processing time and can be measured as the time required for processing a request. In BPEL the processing time is the time period from the point where a SOAP message with a matching a startable receive3 arrives at the engine to the point where a response SOAP message matching the same operation is sent using a reply activity.
One major challenge in composition management is performance modeling and
performance measurement of the composite service [
In addition, other QoS properties of the composite web service have to be managed such as security, reliable messaging, and transactions (cf. Section 3.1.4).
After the selection phase, we have a required policy (resp. SLA) for each partner (that was probably inferred from the non-functional requirements on the composite service) and a published policy (resp. SLA) for the selected service.
Moreover, the composite Web Service may have two different policies: one that is
published to clients (server-side policy) and another that is used for interactions with
the composed services (client-side). As the partner services may specify options in
their policies, e.g., that they support either algorithm a or b for encryption, policy
management should allow the process deployer to specify parameters that drive the
decision on which option to choose. When such a client-side composition policy
2 This can be inferred from the number of receive and onMessage activities in the process.
3 A startable receive activity is an activity that leads to the creation of a new process instance.
exists an effective policy [
Appropriate policy management should also check whether the published policy of a service has changed. In such a case, it should signal any mismatch to the user. Further, the policy management component is supposed to know about the middleware capabilities at the composition side, i.e., if a requirement of the partner after a policy update cannot be supported then policy management should throw an error. SLA and Policy management is about handling all these SLAs and policies of the partner services and the composite service. Ideally, one would like to see a list of policies (required, published, effective) and SLAs (required, published) for each composed service and each interaction.
SLA Management should also monitor the composite service to check if the originally defined SLA is supported. It may turn out that this SLA should be modified after a certain period of time (e.g., because of the performance of a partner service that cannot be replaced, e.g., when that service is a wrapper around an internal application). Further, the SLA descriptions of the selected partner web services have to be monitored from the composition side by collecting execution data for each interaction with that service to check whether the SLA has been violated.
In addition, some means are needed to define how the composition runtime should
behave in the case of SLA violation (e.g., notification of service provider and service
consumer, sending an e-mail to an administrator, selecting an alternative service and
in that case what selection strategy to follow, etc)
Based on SLAs, rankings for partner web services can be calculated for each service
category (e.g., delivery web service) [
There are several middleware requirements in web service compositions [
Several security concerns arise in a composite web service such as the authentication of the composition in front of its partner services. That is, appropriate tool support is needed to specify the data (e.g., user name and password, binary keys) that should be passed to the security middleware before interacting with a partner. The security middleware will then use that data to process the SOAP message according to the WS-* specifications for security such as WS-Security and WS-Trust. There are also confidentiality and integrity requirements for the interactions with partners that can be enforced using a WS-Security based middleware service, which encrypts, signs, and adds user credentials to the messages of messaging activities. Appropriate tool support should allow the user to see the security properties of each interaction in the composition and also to pass the necessary parameters needed by the security service for enforcing that property. As there is a relationship between the security properties of an interaction and the security policies of the involved parties, the management of middleware concerns is related to policy management. The composite web service could also have authentication requirements on its clients, i.e., it mandates incoming client requests to provide some claims; messages without appropriate user claims will be ignored. This can be the case when the client has to pay a fee for using the service. Authentication is then used to associate a contract (including a pricing model) with the client. There are further security issues such as trust, federation, secure conversations, and privacy that need to be managed and configured, e.g., if some of the partner services can be grouped into a trust domain, then the process would not have to authenticate itself separately in front of each partner (i.e., some kind of single sign-on can be introduced).
There are other middleware concerns [
Several business aspects have to be dealt with in Web Services such as enforcing legal contracts between the partners, accounting, billing, etc.
Accounting is the process of tracing information systems activities to a responsible
source [
Billing is concerned with the bills that should be given to the clients of the composite service and also the bills between the composition and the composed services. The web service composition may have to pay a fee for using a partner web service based on different pricing models, i.e., pay-per-use or volume-based rates. At the composition side, the management module should collect the necessary data and statistics about the usage of partner web services. This can be helpful to assign costs to internal business units according the cause of the costs. Additionally, the service requestor (i.e., the composition) can make use of accounting information to check the provider’s invoice. Since the composition itself is a web service, which could charge clients a fee also according to various pricing models, the management module should correlate contracts and usage statistics to produce a bill to the client.
We define Web Service Composition Management (WSCM) as the management of
the composite Web Service, the composition-side management of the composed
services, and the management of the interactions that take place within and with the
composition including their QoS properties. In a broader sense, it includes the
supporting activities that are needed to provide a reliable Web Service composition with
well-defined QoS properties such as:
the discovery and selection of appropriate services to build the composition,
the management of interactions with and within the composition in terms of
SLAs, policies, middleware properties, and business aspects,
the management of the composite web service
It is important to note that we look at the composite Web Service from the
implementation perspective, i.e., the workflow process definition is available to us and not
only the interface definition of the composite web service. This perspective is
different from the one taken by general web service management approaches [
Web services and web service compositions can be managed from the technical
perspective and also from the business perspective [
When considering BPEL, the WSCM requirements mentioned so far can be supported by a WSCM module that will be hopefully part of future BPEL design-time and runtime tools as shown in Fig. 1. The nature of the WSCM requirements and their dependency on workflow-level details make supporting them necessarily a task of a component that is part of the orchestration engine because only the engine has knowledge about the workflow constructs and their execution state. This tool should show the different partners in the composition and allow the user to define criteria for their discovery and selection as well as criteria for selecting other services if some QoS assurances are not met. The SLA and policy management view of the WSCM tool shows the SLAs and policies for each party that is involved in the composition and also the effective policy for each interaction. Further, it should provide information on the real QoS properties for each interaction via messaging activities in each process instance. The middleware concerns view shows the middleware properties of all interactions with clients and partners as well as the middleware properties of nonmessaging BPEL activities such as sequence and scope. The business aspects view shows contracts and also accounting and billing information. The most important view of that component is definitely the one concerned with the management of the composite web service. It includes the policies and SLAs of that service, shows values for each QoS parameters such as availability and performance, and several server-side measurements for its SLA.
Composite
Service Clients
Execution Engine (WfMS)
Workflow Process
Management of the composite service Discovery / Selection management SLA and Policy management Management of middleware concerns Management of business aspects
WSCM Module
Web Services
A lot of research has been done in the area of web service management (WSM) from
the application management perspective [
In [
The Web Service Offerings Language (WSOL) discussed in [
In [
In this paper, we illustrated several management requirements in web service compositions and defined web service composition management. Our definition is not specific to one composition language and BPEL was taken as an example for illustration because it is the standard. We also explained why and how managing a composite web service is different from the general web service management. Moreover, we argued that state of the art BPEL engines are lacking support for composition management but hopefully future composition tools such as BPEL orchestration engines will provide support for the WSCM requirements discussed in this paper.