赵翔鹏的Blog Xiangpeng's Thinkpad

WS-CDL跟BPEL相比有什么价值？

问题：既然有BPEL标准,为什么又出了个WS-CDL? BPEL不够用的么?WS-CDL自身有什么优势?WS-CDL解决了bpel解决不了的问题么?

CDL描述问题的角度跟BPEL不同。与BPEL相比，BPEL强调的是以“我”为中心，描述我跟别人的交互；而CDL是从一个“导演”的层次来描述“他跟她交互，她再跟他交互”，导演要考虑各方如何协调演戏，但BPEL只考虑自己。总之，CDL从需求层面上描述不同 participant之间的交互过程，描述的是business protocol，或者说商业合同。

注意这里的一个前提是要存在多个不同的participant，这意味着我们描述的对象是跨组织的business process，此时CDL才能派得上用场。想象一个含有buyer、seller、bank、shipper等多方的场景，你可以写四个bpel流程，并把它们的并行作为这整个场景的描述，也可以写一个CDL流程作为这整个场景的描述。

既然用4个流程或1个流程都可以描述，那么CDL的好处是什么呢？在引入CDL之前，标准的开发流程是各方先定义自己的BPEL程序，然后把它们放在一起并行执行；这种bottom-up的方法可能会产生死锁等并行程序开发中固有的一些难题。

引入CDL后的开发模型是top-down的，先定义全局的CDL交互模型，然后用一个“编译器”从CDL自动或半自动地生成各方的BPEL描述；这样自动产生的BPEL代码一定不会死锁，一定跟全局模型一致（如果你的CDL到BPEL的“编译器”够强的话）。

必须客观承认的是，CDL还远远达不到工业应用的程度，目前的支持者只有Oracle，Adobe等“非主流”公司，上面所说的“编译器”还没有一个完美的实现。它还是比较新的一个东西，有很多地方人们还不清楚（但是正因为它不清楚，所以学术研究对它反而比较感兴趣）。而且，CDL是对需求的描述——在实际开发中，“需求”未必有人花太多功夫描述——这就是说，就算不引入CDL，还是照样可以开发；它不像BPEL是实现语言，必须采用。但这不代表CDL就没有用；打个比方，尽管严格进行需求分析的人不多，我们能说需求分析没有用么？

WS-CDL规范中文版

我们研究组最近把WS-CDL规范翻译成了中文。这里是中文版CDL规范的链接，希望对大家有所帮助。

update：
上面的链接若不能用，就到这一页。

BPEL4People, HumanTask和BPEL2.0之间的关系

作为对BPEL的扩展，BPEL4People本来打算做一份规范，但是做到后面做成了两份，即BPEL4People和HumanTask，这两个规范要一起使用。下面我们用一个简单的例子说明它们之间的关系。

WS-BPEL2里定义了"extensionActivity"，支持对标准BPEL进行扩展。BPEL4People则定义了一种特殊的extensionActivity，叫做peopleActivity，如下所示：
<sequence>
<extensionActivity>
<b4p:peopleActivity name="electEmployeeOfTheMonth"
inputVariable="candidates"
outputVariable="vote"
isSkipable="yes">
<htd:task name="votingTask">
...
</htd:task>
<b4p:scheduledActions>...</b4p:scheduledActions>
</b4p:peopleActivity>
</extensionActivity>
<assign>
<copy>
<from>$vote</from>
<to>$electionResult/votes[i]</to>
</copy>
</assign>
</sequence>
这个sequence先执行了一个peopleActivity，然后做了个赋值。注意peopleActivity是放在extensionActivity里面的，好让BPEL2.0引擎知道它是一个扩充活动。

BPEL4People仅仅定义了peopleActivity的接口，比如输入/输出变量，跟<invoke>的功能差不多，当然还定义了一些API函数用于取得一个peopleActivity的参数，比如可以通过getActualOwner得知，已经执行完毕的某个peopleActivity究竟是由哪个人做的。

而一个peopleActivity的主要细节，是通过WS-HumanTask来定义的，见上面例子中的<htd:task>部分。换句话说，BPEL4People规范的作用仅仅是连接WS-BPEL2.0和WS-HumanTask。下面是该HumanTask的具体内容：
<htd:task name="votingTask">
<htd:interface operation="vote"    portType="el:votingPT"/>
<htd:peopleAssignments>
<htd:potentialOwners>
<htd:from>$voters/users/user[i]</htd:from>
</htd:potentialOwners>
</htd:peopleAssignments>
<htd:presentationElements/>
</htd:task>
这里只定义了该任务的potentialOwner，即哪些人有权限执行该任务；在<htd:task>里还可以定义很多细节，比如过多久之后会超时，超时后要执行什么动作（Escalation），等等。

可以说凡是跟“人”有关的东西，都定义在WS-HumanTask中。每个business process中可能需要定义一些角色，和一些人；这些"角色"和"人"也是由WS-HumanTask定义的，此外还预定义了几种角色，比如Administrator, Task initiator等。

总结一下，WS-HumanTask专注于“人”，与BPEL规范没有一点关系，甚至连名字都不一样——在BPEL中叫做Activity的东西到了这儿就变成了Task；而BPEL4People就是BPEL 2.0和HumanTask之间的桥梁。

要学习这两个规范，我建议先看WS-BPEL4People规范中的Appendix - D，这里给了个完整的例子。看过例子再读规范，就清楚得多了。

相关链接：BPEL4People规范阅读笔记

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.)

* 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"

* 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)

* 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)

* 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.

BPEL4People v1.0规范发布了

前两天我在我看BPEL4People这篇blog里，提到一些对BPEL4People的批评，包括它的规范拖了又拖不知道什么时候推出。经过了white paper发布后漫长的等待，BPEL4People终于发布了1.0版的正式规范，可以从IBM developer works下载：WS-BPEL Extension for People

制定者包括Active Endpoints, Adobe, BEA, IBM, Oracle, SAP AG。显然，微软是自己玩他的Windows workflow foundation去了。

开始读这份52页的规范吧～估计过几天就会看到一些评论了。

我看BPEL4People

近来比较关注BPEL4People。这是IBM和SAP提出的一个white paper，目标是给BPEL加上human workflow的功能。一共不到20页，很短很好读。

我觉得BPEL human workflow还是很必要的。在工作流的角度来看，BPEL太像一个编程语言，只是做了service composition，却没有考虑task list等问题；毕竟，多数工作流是要牵涉到人的，比如任何一个公文流转的流程。事实上大多数BPEL厂商都自行扩展了human workflow的支持。引述Bruce Silver的一段话：

The world of BPMS is divided into BPEL-lovers and BPEL-haters, and the thing that BPEL-haters seem to hate most is that even the not-yet-final 2.0 version of the OASIS standard "excludes" human tasks. How can you have a "business process" execution language that cannot accommodate human-performed activities? "Out of scope"?! Are you kidding?

不过，这份white paper迄今还没有变成一份规范；而且有些人批评说它多余，比如这篇Do We Need This Animal Called 'BPEL4People'?，这标题起的几乎有点刻薄了。Bruce Silver在他的文章中也表示BPEL4People有点“overly ambitious”，因为其中提出的5个interaction patterns的构想不太容易实现。

不管怎样，扩展BPEL使之支持human workflow的基本想法还是很好的，这一点Bruce Silver也同意。只是从具体的技术细节来看，BPEL4People可能还有一些不尽人意之处。上个月OASIS的BPEL Webinar上有人提问“BPEL4People什么时候出规范？“回答是”快了“。

6月1日的更新：

仿佛是回应我这篇blog一样，ActiveBPEL昨天推出了ActiveBPEL for People，支持BPEL4People的大部分功能：
Key capabilities of ActiveBPEL for People include:

-- Extensions to ActiveBPEL Designer, the SOA community's leading BPELauthoring environment, that support the design, testing and deploymentof human-centric BPEL processes

-- New human interaction operations that are wrapped in Web services andinvoked as BPEL activities

-- Task Editor and Task Inbox controls that can be directly embedded intoSOA applications or used as templates for creating custom userinterfaces

-- An ActiveBPEL Task Services subsystem that creates and manages thecomplete lifecycle of human tasks

-- Alarm, escalation and notification services that allow human-centric
applications to be easily integrated with enterprise monitoring and
management infrastructures

-- An identity services infrastructure that integrates with popular enterprise directories to support roles and rights configurations - such as owners, users and administrators - of human tasks

-- Supports common workflow patterns:
-- Four eyes
-- Nomination

6月28日更新：
分类: BPEL和CDL 没有评论