Upthrust

Web Service orchestration and composition can be consider as the main use cases of WS-BPEL. In both cases Web services from external parties or from different systems of same organisation are involved and interact with each other to provide the service(here I am considering process as a service we offer) described by WS-BPEL process. So there should be a way to model this relationship between BPEL process and partner services.

Figure 1

WSDL already provided the requirements which needs to describe service provided by a partner via port types. Partner link type concept in WS-BPEL extends the WSDL to define this relationship between partners and processes. In typical scenarios process it-self can be a service provider for some partners(clients of the process) or service consumer in other partner relationships. And partner link type binds  two port types; port type process offeres(myRole) to a partner and port type partner offeres(partnerRole) to a process. Figure 1, shows several partner links and their relationship with port types. If you consider ‘invoicing’ partner link, the process offer invoicingCallbackPT to it’s partner invoicing service while the partner(in this case invoicing service) offer computePricePT to the process. This partner link describes a asynchronous interaction among process and invoicing service.

Figure 2

Partner link can be think of as a instance of partner link type and partner interactions are modeled using partner links in WS-BPEL process. Above diagram Figure 2 describes the relationship between ‘Partner link type’ and a ‘partner link’. Partner link type is different for synchronous and asynchronous interactions, where we have only one role for synchronous interactions due to their uni-directional nature and two roles for asynchronous interactions. You can find more information from WS-BPEl specification and section 2 of BPEL Light paper. This partner link concept is the main concept which allows asynchronous communication between partners take part in business process.