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

declaration that extends the original WSDL description before it can be ref-
erenced in a BPEL process. Accordingly, PortType and operation correspond
to those in the WSDL interface exposed by the partner service. A variable is
an instance of a WSDL message used in an interaction.
In grid computing, asynchronous interaction is often found to be advan-
tageous for system optimization that better meets scalability requirements
that push the system to its limits. Negligible concerns in system design
and coni guration that are based on synchronous communication could be
well magnii ed or even turned into bottlenecks in systems when massive
processes are spawned onto the grid. For instance, keep-alive signaling for
long-running invocations generates unnecessary network trafi c; blocked
process accumulating memory footprints and acquiring extra CPU cycles
complicate the process and system maintenance; services end up building
long-lived dependencies that tend to be less tolerant to failures with
resulting chained effects. Asynchronous interaction addresses partly the
problem by further decoupling the services in interaction; that is, the ser-
vice requestor will no longer stay in the communication with the service
provider as soon as the request has been successfully submitted; the ser-
vice provider calls back at a later time only when it is ready with the
response data.
To illustrate in BPEL in detail, we will look at an example of job submis-
sion. At some point in a process, a job needs to be submitted to the grid via
a dedicated job submission service. The process then queries a monitor
service for the i nal job status and decides whether a resubmission is nec-
essary or not. Suppose the submission service always replies with a unique
job ID as soon as a job is received, synchronous invocation is simply ade-
quate to describe such behavior. However, as it is unknown in advance
how long it takes for a job to complete, are thus how long a job status
report will take, it is more appropriate for the query with the monitor ser-
vice in this case to be asynchronous, especially if the job is meant to be
long-running. In order to model this in BPEL, we can i rst use an invoke
activity to send the job description to the submission service and in return
to obtain the job ID. Then we use another invoke activity but this time with-
out specifying the output variable to perform the one-way invocation with
the job ID to the monitor service, which will be calling back with the i nal
job status in, preferably, another one-way invocation. The callback mes-
sage will then be captured by an event listener that must be dei ned sub-
sequently in the process. There are a couple of ways to set this up in BPEL.
For example, receive is good enough for a simple case like this; pick is a
selective event listener, which selects exactly one event out of all those
having been dei ned; for more complex situations, event handler s can be
used as a container of event-triggered routines alongside the normal pro-
cess logic; as long as they are in an active state, events will be continuously
picked up by the corresponding handlers. Event s supported in BPEL can
be inbound messages; for example, our job status notii cation, from the