Databases Reference
In-Depth Information
As we will be using BPEL to implement our Task Based Business Services, it makes
sense to use the Web Service API (in the same way that any BPEL process containing
a human task does).
If you compare this to our architecture outlined in
Chapter 10, oBay
Introduction
, you will notice that we've decided not to wrap a virtual
service layer around the workflow service; there are two key reasons
for this.
First, if you look at the service description for the workflow services,
they already provide a very well defined abstract definition of the
service. Hence if you were to redesign the interface, they probably
wouldn't look very different.
Secondly, whenever we include a human workflow task within our
composite, JDeveloper automatically generates a lot of code which
directly uses these services. Thus, if we wanted to put a virtual layer
over these services, we would need to ensure that all our human
workflow tasks also went via this layer, which is not a trivial activity.
So the reality is that adding a virtual services layer would gain us
very little, but would take a lot of effort and we would lose a lot of
the advantages provided by the development environment.
Defining the order fulfillment human task
For our
OrderFulfillment
process, we are taking the approach of combining all six
workflow steps into a single human task (the
OrderFulfillmentTask.task
). Now
this isn't a perfect fit for some of the reasons we've already touched on, so we will
look at how we address each of these issues as we encounter them.
Within our task definition, we've defined two possible
Outcomes
for the task, either
COMPLETED
or
ABORTED
(where for some reason, the sale fails to proceed). In addition,
in the
BPEL Human Task Configuration
window, we have configured the
Task
Title
to be set to the item title and set the
Initiator
to be the seller of the item.
Specifying task parameters
A key design consideration is to decide on what parameter(s) we are going to pass
to the task, taking into account that we need to pass in the superset of parameters
required by each step in the workflow.
For our task, we will have a single parameter of type
order
, which contains all the
data required for our task. The definition for this is shown as follows:
<xsd:elementname="order"type="act:tOrder"/>