Dynamic Selection of Best Service Providers

In a web services environment a workflow specifies a control flow among services.

These services may be provided by different providers—in-house and by different partners. By looking at our order management example of Section 4.2 and its BPEL representation in Section 4.3 it becomes evident that all these services are bound

statically. This means that each service is called from a fixed provider. There is no dynamic selection of the best provider. However, there may be the desire to bind the services or at least some of them to the best provider. In our example, we assume that all the services provided in-house, i.e., the services of the different departments of the seller, remain fixed. However, there may be different partners providing the transport. In the example, the booking of transport is defined as shown in Figure 4.4 and the following BPEL code:

Fig. 4.4 Static binding of the transport service

R T t Reserve Transport

C C

Seller Carrier

Reserve Transport

Confirm Transport

Reserve Transport

Confirm Transport

Ss S_s

098 <bpws:invoke inputVariable="transportRequest"

operation="reserveTransport" partnerLink="Ss2C" portType="ns:C" />

099 <bpws:receive name="confirmTransport" partnerLink="Ss2C"

portType="ns:Ss" variable="transportConfirmation" />

One option to overcome the current limitations in BPEL is to indirectly call the dynamic services by a special dynamic invocation service. As a result, all activities that are currently static bound must be replaced by a call to the dynamic invoca-tion service. This dynamic invocainvoca-tion service acts as a search and selecinvoca-tion agent, as described in Section 4.4. This means, the dynamic selection service dynamically discovers potential providers of the service and selects the best one. Furthermore, the dynamic invocation service has to bind to the selected service, issue the correspond-ing call, and receive a potential result. The result received from the dynamically invoked service is then returned to the main workflow. Figure 4.5 presents this sce-nario for dynamically selecting the transport in our order management example. In this case we assume that a dynamic invocation service offers an operation dynam-ically invoke transport on its port typeD. Note, another option would be that the dynamic invocation service offers just one general operation and the kind of service to be dynamically invoked is semantically described in the parameters. Once the dynamic invocation service has received the call ofdynamically invoke transport, it searches the registry for potential providers. In our case it finds services of carrier 1 and carrier 2. From these services it selects the best one—lets say the one of car-rier 2. Next, it calls the synchronous operationenquire transportfrom carrier 2 that returns aconfirmation of booking. Having received this confirmation the dynamic invocation service is able toconfirm the transport to the seller.

Kuestner et al. [19] propose the Diane middleware to dynamically bind ser-vices to BPEL activities. The Diane middleware uses predefined templates to

is-D i ll Dynamically

Ss Ss Enquire Transport

C Dynamically

discovered &

bound

Fig. 4.5 Dynamic binding of the transport service

sue semantic requests to the middleware. A similar approach is described by [23].

This paper proposes a dynamic service discovery and its binding into BPEL pro-cess. The discovery and matchmaking is performed by querying a knowledge base of DAML-S service profiles with requests expressed in DAML Query Language. In the METEOR-S project [1] developers create abstract processes that contain service templates as semantic requests. At runtime a configuration module binds these to concrete services using semantic discovery. Furthermore, an execution environment is introduced that handles their invocation. Lemcke and Drumm [20] create a single business process for each of a set of alternative service providers. At runtime they use semantic technology to pick and instantiate the most appropriate process.

All the above mentioned approaches take BPEL as it is. They just bind some BPEL activities to some kind of dynamic invocation service. Karastoyanova et al.

present an approach [18] to extend BPEL by concepts allowing dynamic invoca-tions. They suggest so-called parameterized BPEL processes which eliminate the dependency of invocations of operation names, port types, and partner links. The idea is that processes are executable if all partner endpoints are known at runtime.

However, this information is not necessarily needed at design time, if it can be cal-culated. Since this information is required in BPEL at design time, it is proposed to add another element to BPEL that allows substituting the port types and operations.

This element is calledevaluate. Its syntax is defined as follows:

<invoke name=" " ...>

<evaluate activated="yes|no" changeType =

"static|prompt|query|fromVariable" substitute="value"/>

</invoke>

Theevaluateelement is nested into aninvokeelement, if the operations and port types of this invoke statement are subject to substitution. The Boolean activated attribute is used to turn on/off the substitution. The change type attribute allows for four different kinds of substitution: (1) static: substitution by another static service, (2) prompt: substitution according to user input, (3) query: substitution by a result of an issued query, and (4) from variable: substitution by information stored in a

variable. The input for the parameter evaluation strategy is a proper value of the substitute attribute. The solution proposed by the evaluate element is independent of any semantic web services technology.