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

process service port, or customer timers set off after specii c durations or
at deadlines. Finally, in the process WSDL description, the use of a listener
must be exposed as an available operation of the process, to which the
asynchronous service provider can refer in the callback. In this way, there
will be no blocking of the process whatsoever.
Apparently asynchronous interaction tackles certain issues that may be
raised by synchronous designs, nevertheless at the expense of complica-
tion in process modeling. Suppose the BPEL process in our example is
called many times, if we need to submit more jobs. Each resulting callback
message must then be directed to the correct process instance that has
initiated the asynchronous service requests in the i rst place, so that the
matching notii cation listener can close the session of listening when the
message arrives. However, this is not as straightforward as it appears.
From the point of view of the monitor service in our example, the only
information regarding callback invocations is the service endpoint refer-
ence bound in runtime to the callback port that we have exposed. It is
shared by all process instances in the same way as they were created on
service requests made at the same service port at the beginning. WSDL, of
course, does not provide any information about the process instance as it
is not designed to be aware of any extension standards like BPEL at all. On
the other hand, BPEL services are not meant to be considered any more
special than standard Web services in service interactions, so neither
should their WSDL descriptions. The asynchronous service provider, just
like any external service partner and client, is not concerned about whether
the service it is communicating with is a BPEL process or not. In a word,
the service endpoint reference available to the monitor service cannot be
used to distinguish process instances, and all callback messages will
be unfortunately sent to the same destination. There must be a way to
reassociate these messages with the initial process instances they are
intended for. The notion of correlation in BPEL allows the use of applica-
tion data delivered with SOAP messages to construct process identii ca-
tion information dynamically in runtime and, moreover, independent
of any implementation-specii c mechanisms. From a service-oriented
perspective, application data embedded in the messages exchanged with
service partners constitute the context of application signii cance that pure
implementation-level mechanisms cannot convey. The application-level
protocol is required to address such a requirement, while at the same time
avoiding competition with any possible low-level implementations.
Starting with the extension to the initial WSDL description, it is possible to
declare rules for how messages should be parsed against the creation of
identity information in XML, before labeling the process document when
and how the declared correlation should be performed; for example, when
a callback message is received by the listener. It is then up to the BPEL
engine to implement the correlations in practice: messages will be inter-
cepted and checked at arrival before they are reassociated and passed to