Databases Reference
In-Depth Information
We can see that an
OnAlarm
branch is configured in a similar fashion to a
<wait>
activity, in that we can specify that the
<pick>
waits for a specified duration of time
or until a specified deadline. In either case, we can specify a fixed value or specify an
XPath expression to calculate the value at runtime.
For our purposes, we have pre-calculated the finish time for the auction, based
on its start time and duration, and have configured the
<pick>
activity to wait
until this time.
When triggered, the process will execute the activities contained in the
OnAlarm
branch and then move onto the activity following the
<pick>
. In the case of our
auction process the branch contains just a single activity, which sets the flag
auctionComplete
to
true
, causing the process to exit the while loop containing
the
<pick>
activity. Upon exiting the loop, the process calculates and returns the
auction result before completing.
Scheduling services
A common requirement is to schedule a process or service to run at regular intervals.
For example, the oBay
Billing
composite is required to be run once every night.
One approach would be to use a scheduling tool. There are a number of tools
available for this, including:
•
Quartz:
This is an open source Java-based scheduler; the advantage of Quartz
is that it's already used internally by the BPEL engine for scheduling, so it's
available for use as part of the SOA Suite platform. However, this approach
requires knowledge of the API as well as Java.
Oracle Database Job Scheduler
: This is provided as part of the Oracle
Database, and like Quartz it's available regardless of which platform you are
running the SOA Suite on (assuming you are using Oracle as the backend
database). However, it requires knowledge of PL/SQL.
•
While these are all perfectly valid approaches, they all require knowledge of
components outside the SOA Suite. An alternate approach is to use BPEL to
implement the scheduler.
One approach is to implement a BPEL process that continuously loops with the sole
purpose of launching other scheduled BPEL process. However, as the process never
dies, this will result in an ever-increasing audit trail, causing the objects persisted in
the database as well as the in-memory size of the process to grow over time, which
eventually will have a negative impact on the performance of the engine.
