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

general, is to allow the dei nition of error-handling procedures along with
the normal process dei nition to be activated in case of process failures.
Error-handling logic, as critical as the main process logic in a fault-tolerant
workl ow design, should be explicitly dei ned by a process modeler. BPEL
pursues ACID transactions at the application level to ensure integrity
of process executions. This means, in case of errors, that any committed
operations that have caused changes of system status, including both logic
and data, must be undone to reverse the effects of having been passed on
to not only the process itself but also the partner services that have been
interacted within the same transaction that has failed and must be aban-
doned. In an example of database service, committed submission of
persistent data can be deliberately deleted from the database through a
normal service invocation but at a different, dedicated reversing operation
port; a snapshot of the process state at the point of failure in the transac-
tion will be captured and used for assembling reversing invocation
messages. In BPEL, such a reverse of committed enactment is called
compensation . The container of compensation logic is called a compensation
handler . A compensation handler can be attached to the same scope in
which compensatable forward-working logic resides. Since scope is usually
used to demarcate a sublogic unit in BPEL, it is sensible to allow various
extension handlers of complementary logic that have only constrained
inl uences to the companion main process in scope to be associated with
it. Including compensation handler , there is message exchange handler , event
handler , termination handler , and fault handler . Fault handler can capture
explicit faults, for example during a service invocation, and then activate
corresponding fault-handling logic in reaction. Therefore, an explicit call
of compensation is usually incorporated as part of the fault-handling rou-
tine to enable compensation in time. BPEL supports both WSDL faults
associated with service operations, and customer-dei ned faults. A class of
implicit faults has also been dei ned in the specii cation.

8.7
A service-oriented architecture is an open and extensible platform ready
to accommodate dynamic and agile developments of modern information
systems. All Web service standards, including BPEL, support extensibility
to some extent. BPEL allows user-dei ned activities to be implemented and
works side by side with standard constructs. In a way, user extensions like
the macro process, embedding of programming codes or scripts, and so
on can be integrated to a BPEL implementation seamlessly. More likely,
vendor extensions implemented on customer requests will appear com-
monly in commercial BPEL products.

Extensibility