赵翔鹏的Blog Xiangpeng's Thinkpad

BPEL4People规范阅读笔记

下面是我前几天读WS-HumanTask和WS-BPEL4People规范时作的笔记，因为有太多术语，所以就直接用英文写了。不保证笔记的完全正确性，只是用于日后参考。
关于bpel4people的更多资料，请参考http://del.icio.us/tags/bpel4people上搜集的各个页面。

RBAC related basic concepts (Sec. 3, WS-HumanTask):

• organization
  entity (a person or a group of persons. Must be linked to outer RBAC/LDAP user
  database)

• logical group (roles of the process, i.e. "voters", "approvers".
  Must be linked to outer RBAC/LDAP user database)

• generic roles (task
  initiator, stakeholder, potential owner, excluded owner, admin, notification
  receipient)

• • process initiator/stakeholder/admin are defined in BPEL4People
    spec.
  • person assignments (use an expression (literal, logical group, etc.)
    to assign some people to some generic role)
  • e.g. we can assign logical
    group "voters" as the potential owner of task "vote", or assign the "previous
    approver" as the excluded owner of task "approve_2")
  • In other words, we
    can define the potential owners of a task dynamically; thus we can do SoD and
    BoD.)

---

From a task's view: (Sec. 4, WS-HumanTask)

* A
task includes (page 23-36):

• service signature (input/output parameter,
  operation name, etc)
• people assignments, indicating who can do the task,
  and who cannot, etc.
  • When a task is executed, it will have an "actual
    owner".

• deadline requirements
  •  two kinds of deadline:
    start/complete
  • can define multiple deadlines on different times with
    different behaviors
  • If timeout, then calculate each escalation's condition,
    and execute the corresponding behavior (behavior can only be either notification or reassign)
  • e.g. 1
    hours after start -> notify manager, 2 days after start -> notify
    director, 1 day after complete -> reassign task owner
• delegation requirement
  (to whom can we delegate the task? nobody/anybody/...)
• attachment requirement, priority,
  comment, represetation info., etc.

* A task's lifeline (page
37-38):

• created (by business process)
• ready (created, but no one
  claims it yet)
• researved (some potential owner claims it) [Note: delegate,
  revoke(release) can be done in this state]
• inprogress (some one starts it)
  [Note: revoke, stop, delegate can be done in this state]
• completed
• failed
  (divide by zero, or the performer thinks it is a bad task)
• obsolete (owner
  skips it, e.g. the receiver discards a notification, or gives up the right to vote)
• terminated (outer
  scope terminates, or timeout)
• a task can also be suspended and resumed
  (I'm not clear about this yet)

* Notification (Sec. 5, WS-HumanTask)

• is a one-way, asynchronous human task
• can only assign "receipients" to a
  notification, rather than "potential owners"

---

From a user's
view (page 42-54):

* Normal User

• claim, start, release, complete,
  fail, delegate ... a task
  • use "remove" for notifications
• query
  tasks (similar to a SQL select. can specify many parameters, e.g.
  "Task.Priority=1 AND maxTasks=10")

* Administrator

• activate (set
  status to Ready)
• nominate (set potential owner to a specific person, and
  set task status to
• set role (change people assignment
  dynamically)

---

From business process's view:
(WS-BPEL4People)

* A process includes:

• some logical group definition
  (roles in the process, i.e. "voters", "approvers". Must be linked to outer
  RBAC/LDAP user database)
• person assignments of process generic roles
  (process initiator, process admin, etc.)
• human task definitions
• process definition, where each "human task" is wrapped in a "people activity",
  whose syntax follows the spec of BPEL.
  • task definitions can be given
    inside a people activity, at the beginning of the process, or elsewhere. (see
    "constellations" on page 16)
  • a globally defined task's people assignment
    or priority can be overidden in local people activity.
  • people activity's
    state diagram is at page 27. (running, completed, obsolete, failed, terminated,
    closed)

---

First Impressions

* The idea

• Task owners can be
  specified in a fine-grained way in the task definition, and can change
  dynamically.
• Many states for a task, many possible operations for a user
  (which states/operations are important, which are not?)
• Fine-grained
  deadline support
  • to read: what if several escalation conditions have
    overlap?
• Two spec instead of one
  • aims at the separation of
    TaskEngine, TaskList, BPEngine, so that we can combine different products
    together (see the official podcast)
• Question: how to link logical group to actual
  users? Can this link be changed dynamically by process admin?

* The spec
text

• Quite long, but quite easy to read (compared with the BPEL spec)
• Read the examples for a quick start!!! (The final sections of the specifications)
• Still some small errors in the spec
  • e.g. page 54 has a typo
    "assigment".
  • In the task state transition figure, the word "revoke" is used.
    However it is called "release" in the text.