In this recipe, we will explore how to dynamically call web services from the BPEL process. Such an approach can be useful in an early stage of the SOA adoption or when we don't have the middleware infrastructure set up yet and we have, for example, a set of redundant web services. In such a scenario, we need to provide ourselves with the functionality for the BPEL process to dynamically select the web service's endpoint.
We start this recipe by deploying the same web service to multiple instances of the servers. We decided to use the hotel reservation service from the Implementing web services with Axis2 recipe. We deployed the web service to the three instances of the server. The interface of web service remains the same; however, the address on which the web services reside do change as follows:
Server 1: <soap:address location = "http://192.168.1.101:7777/axis2/services/BookHotelService/"/> Server 2: <soap:address location = "http://192.168.1.101:8888/axis2/services/BookHotelService/"/> Server 3: <soap:address location = "http://192.168.1.101:9999/axis2/services/BookHotelService/"/>
In the following steps, we will describe the actions to be performed in order to configure the BPEL process to dynamically select the web services endpoint:
- First we create the BPEL process. The BPEL process can either be synchronous or asynchronous. As an input parameter we take two dates, presenting the
fromandtoreservation dates as follows:<element name = "process"> <complexType> <sequence> <element minOccurs = "0" name = "from" nillable = "true" type = "dateTime"/> <element minOccurs = "0" name = "to" nillable = "true" type = "dateTime"/> </sequence> </complexType> </element>We introduce the decision element. The criteria we took is the year of the
fromparameter as shown in the following figure:
- Based on the decision criteria, we set the endpoint parameters for the web service. We created the
EndpointReferencevariable and initialize it with the following literal:<copy> <from><EndpointReference xmlns = "http://schemas.xmlsoap.org/ws/2003/03/addressing"> <Address/> </EndpointReference></from> <to variable = "EndpointReference"/> </copy> - Based on the decision criteria, we set the web service endpoint address as follows:
<bpelx:append> <bpelx:from variable = "address"/> <bpelx:to variable = "EndpointReference" query = "/ns2:EndpointReference/ns2:Address"/> </bpelx:append> - Finally, we copy the endpoint reference variable to the
partnerLinkelement as follows:<copy> <from variable = "EndpointReference"/> <to partnerLink = "BookHotelSvc"/> </copy> </assign> - We model the BPEL process so that the parameters are set to the web service variable, the web service is invoked, and after the web service invocation the results are picked up as shown in the following screenshot:
One of the advantages of the BPEL processes is that it is possible to invoke a web service with the dynamic partner links. If we have redundant web services, it is the easiest way of using the dynamic partner links. That way we simply change the address of the web service endpoint, and we can immediately consume the web service.
The dynamic partner links take advantage of the WSA mechanism. In WSA, the various data about the web service endpoint can be found. The only two parameters that can be changed are as follows:
<wsa:Adress>: This defines the location of the web service endpoint<wsa:ServiceName>: This defines the name of the service and the port used
It is also possible to extend our BPEL process to include the partner links of all three web services. Then, we model the BPEL process same way as we have in this recipe. The only difference is in the assign activity, where we now set the endpoint address data. Instead of dynamically assigning data to the invoke activity, we could use three separate invoke activities and set one partner link to each of them.
Actually , the dynamic selection of the web service is highly dependent on the infrastructure we have at our disposal. This recipe explained the dynamic selection of web services with no external help of other technologies. We could, however, use the service registry for web service discovery along with late binding through a mediator.