Grid Services Orchestration with OMII-BPEL - Grid Computing: Infrastructure, Service, and Applications - page 189

based on a peer-to-peer model that involves exactly the process itself and
one of its partner services. Complex interactions are built with more of
these basic activities. Given the important fact that a BPEL process becomes
a Web service as soon as it has been deployed, these interactions will
appear with no difference from those between standard Web services.
Thus we infer that the primitive interaction patterns that BPEL supports
are consistent with the interfacing models implied by WSDL, since a WSDL
description is the only contract of communication of a Web service.
Depending on the availability of an output message of a service operation
dei nition in a WSDL description, two invocation patterns can be derived
accordingly: the request-response pattern, in which a reply is always expli-
citly sent by a service in response to a request; and the one-way pattern,
where a reply is not expected. By further applying these patterns to all two
peers in an interaction, we have four combinations that, from a process
prospective and considering the role the process plays as either a service
provider or a service consumer, we can quickly summarize as the follow-
ing: (1) process receives a request, and replies with the processed result
(requestor blocks until the reply is received); (2) process receives a request
but does not reply (requestor does not expect one either); (3) process initi-
ates an invocation to a partner service and waits for a reply; and (4) process
initiates an (e.g., a notii cation) invocation without waiting for any reply.
The four are considered the minimal conversation patterns a BPEL pro-
cess needs to implement, and upon which complex patterns can be built.
To enable the modeling, BPEL introduces the corresponding language
notations that directly map to these interaction activities, namely invoke ,
receive , and reply . Invoke denotes an initiative invocation to a partner service.
Receive denotes a receipt of service request. Reply denotes an explicit reply
to a matching request. Then, for example, to model a request-response
style of interaction, a receive and a reply can be placed at both the begin-
ning and the end of a process respectively; an invoke without an output
variable can be used to simulate a one-way invocation:
<bpws:invoke inputVariable=”SubmitJobRequest”
name=”jobmanager” operation=”submitjob”
outputVariable=”GetJobStatusResponse” partnerLink=
”jobmanagerPartner” portType=”jman:jobmanager”/>
<bpws:receive createInstance=”yes” operation=”submitjob”
partnerLink=”jobmanagerPartner” portType=
”tns:jobmanager” variable=”SubmitJobRequest”/>
<bpws:reply operation=”submitjob” partnerLink=
”jobmanagerPartner” portType=”tns:jobmanager”
variable=”GetJobStatusResponse”/>
In the snippets above, a partner link is an abstraction of a communication
link between a process and its partner, whose roles in the target interaction
are dei ned. A partner service must be imported through a partner link