Page 267 -

10 The Resource Service 263

Technically, when a task is enabled at runtime, at least two work items
are instantiated for it. One is referred to as the parent work item, the others
as its child or children. The parent is held internally within the engine, and
oversees the execution of its children. For a single instance atomic task, one
child work item is instantiated, and for a multiple instance atomic task, the
specified number of child work items are instantiated. It is these work items
that are actually executed by resources (e.g., a participant). When all of its
children have completed, the parent itself then completes, allowing the process
to progress to the next task, and so on.
It is important to understand the distinction between a task and a work item
derived from it. When we talk about tasks, we refer to design time definitions;
at runtime, we refer to work items as instantiations of tasks.

At the base of the resourcing framework are three interaction points, which are
places in the life-cycle of a work item where resourcing decisions are to be made,
up to and including the moment the work item is placed in a work queue (cf.
Chap. 2). At each interaction point, the decision may be specified to be system-
initiated (automatically performed by the system, using parameters set at design
time) or user-initiated (manually performed by a participant or administrator at
runtime). The three interaction points for each work item are:
Offer: The work item is offered to one or more participants for execution. There
is no implied obligation (from a system perspective) for the participant to accept
the offer.
Allocate: The work item is allocated to a single participant, so that the participant
is committed (willingly or not) to performing that work item at a later time. If
the work item was previously offered to several other participants, the offer is
withdrawn from them at this time.
Start: The work item is started by the allocated participant (i.e., enters executing
state).
If a work item’s offer interaction is user-initiated, it is passed to the administra-
tor’s Unoffered queue so that it can be manually offered to one or more participants.
If an offer interaction is system-initiated, the service will offer the work item to
one or more participants based on the resourcing parameters defined for it at design
time, by placing it on the participants’ Offered queue.
If a work item’s allocation interaction is user-initiated, one of the participants
who is offered the work item may manually choose to allocate the task to him/her-
self, at which point the work item is placed on the participant’s Allocated queue
and removed from the Offered work queues of all other offered participants. If
the allocation interaction is system-initiated, an allocation strategy (e.g., random
choice, round robin, shortest queue), as defined at design time, is invoked that
selects a single participant from those offered; the work item is placed on that par-
ticipant’s Allocated work queue and removed from the offered work queues of all
other Offered participants.