今天，由 IBM、Adobe、SAP、Oracle、BEA systems 和 Active Endpoints 所组成的厂商，发布了有关新提议的WS-* 规范的最终草案，它有个有趣的名字——“WS-BPEL4People”。相比于处理业务过程自动化的WS-BPEL，WS-BPEL4People 规范（它已被秘密制定了近两年），旨在给SOA 增加一般的人类工作流能力，尤其是对最近被批准的 WS-BPEL 2.0 规范。
WS-BPEL4People 包含 2 个补充性规范。第一个是 WS-BPEL extension for people ，它定义了在 WS-BPEL 上处理人类交互和任务的层级，或者如规范的摘要所说的：
Web 服务业务过程执行语言，版本 2（WS-BPEL 2.0，或简称 BPEL）引入了基于 Web 服务的业务过程模型。
一条 BPEL 过程编制（orchestrates）不同 Web 服务间的交互。该语言包含描述复杂控制流程所需要的特性，包括错误处理和补偿行为。然而，在实践中，很多业务过程场景都需要人类交互。一个过程定义应该将人类合并为另一类参与者，因为人类也可能参与业务过程并影响过程执行。
该规范引入一个 BPEL 扩展来解决 BPEL 中的人类交互，并将它的作为一等公民。它定义了一种新的基本活动类型，它使用人工任务作为实现，允许任务可以在本地的过程中，也可在过程定义之外。这个扩展基于 WS-HumanTask 规范。
第二个引入的规范则是 WS-Human 任务，它定义了允许将人类任务作为服务引入 SOA 的接口，这些接口独立于 WS-BPEL。它的想法是使非人类服务有一种一致、标准的与人类交互的方式。规范定义目标如下：
人类任务，或简称任务，能将人类集成到面向服务应用中。本文档提供了用于人类任务的符号、状态图和 API，以及一个协作协议，它允许与人工任务以更面向服务的风格交互并且同时控制任务的自治。该文档被称为 Web 服务人类任务（在本文档的其余部分简称为 WS-HumanTask）。
人类任务是由人类"实现的"服务。它们将人类集成到面向服务应用中。一个人类任务有 2 个接口。一个接口暴露任务提供的服务，如翻译服务或批准服务。第二个接口允许人类处理任务，如查询等待他们的人类任务，以及从事这些任务。人类任务有被分配给的人类。这些分配定义了任务上的某个角色应该由谁扮演。人类任务也可能指定任务元数据在不同设备或应用上应该被如何呈现，使之在不同类型的软件间可移植和互操作。人工任务可以被定义成超时反应，触发一个合适的增加动作。
这同样适合于通知。通知是一类特殊的人类任务，它允许给人类发送值得注意的业务事件新息。通知总是单向的，它们以一种发射即忘记（fire-and-forget）的方式被传递：发送者给人们推出通知，并不等待人们确认已接收它们。
厂商们计划将两个规范都提交给 Oasis ，并且将它们批准成为另一个 WS-* 标准。
微软的 John Evdemon，他曾是核准 WS-BPEL 2.0 的 Oasis 委员会主席之一，希望在这些规范被批准成为标准之前：
…他们可以修正一些问题（如 people resolution），并拿出一个听起来不太搞笑（punchline）的名字。:)
另一方面，SAP 的 Alan Rickayzen 对新标准感到非常激动。在他的博客中，你可以看到一幅这两个标准的组件图，以及一个简短解释它们的pod-cast 。
你的想法是什么呢？–我们需要另一个WS-* 标准吗？新标准会受到 http://blog.jonudell.net/2007/06/05/ws-justright-revisited/ "Jon Udell 所说的"只有 WS 才是对的（WS-Justright）“的影响吗”">Jon Udell 所说的“只有 WS 才是对的（WS-Justright）”的影响吗 ?
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论