|
实现 WSFL 中的角色
James Snell (jasnell@us.ibm.com)
软件工程师，Emerging Technologies，IBM
2001 年 7 月
Web 服务提供了创建高度动态化的、多功能的分布式应用程序的可能，这种应用程序跨越了技术和商业之间的鸿沟，允许服务提供者和服务消费者共同改进商务方式。Web 服务流语言（WSFL）通过建立一个框架来扩展这种可能，在此框架内服务提供者和消费者可以共同合作实现标准商业流程；在这个流程中“所做的事”比“做事的人”更重要。该框架允许所有正确实现了合适的 Web 服务接口的人担任商业流程中的各种角色。在 Web 服务内幕的这一部分，我们继续讨论 WSFL，并把重点放在如何成为一个服务提供者。
Web 服务内幕的前一部分（请参阅参考资料）介绍了商业流程建模和服务提供者类型的概念，它们在实现商业流程中承担各种不同的责任。在这一部分，我准备更深入地探讨如何成为一个 WSFL 服务提供者。一个好消息是，只要使用任意启用 Web 服务的平台（不管这个平台是 WSFL 还是具有 WSDL 功能的），正确实现一个或几个 WSDL 定义的 Web 服务接口即可成为一个服务提供者。换句话说，您不需要真正懂得任何关于 WSFL 的知识即可担任 WSFL 服务提供者这一角色。您必须要了解的是如何获取一个 Web 服务接口定义并真正把它转化为 Web 服务实现，这才是我要在这里阐述的过程。
流程概述
WSFL 流模型中的每个活动都以 Web 服务的形式（由 Web 服务提供者提供）实现，并履行一个流程中所定义的角色。每个服务提供者自然都期望能适当地满足实现 Web 服务或实现实际执行该活动的一套 Web 服务的要求。WSFL 流模型中的每个活动都使用 WSFL 全局模型中包含的信息链接到一个实际的 Web 服务实现中（请参阅图 1）。每个 Web 服务实现都指向该实现的一个基于 WSDL 的描述，该描述接着又链接到基于 WSDL 的接口描述 — 描述了所有可发送到 Web 服务或从 Web 服务接收的实际消息和操作。
图 1：旅游预订商业流程的流模型
清单 1 所示是与上图表现的商业流程的流模型相对应的全局模型。
清单 1：旅游预订商业流程的全局模型
<globalModel name="bookTripNTickets" serviceproviderType="agentType">
<!-- Defines the identity, location and implementation of the service
provider fulfilling the role of the travel agent -->
<serviceProvider name="travelAgent" serviceProviderType="tio:agentType">
<export>
<source portType="tio:tripHandler" operation="sendItinerary"/>
<target portType="tio:tripNTicketHandler" operation="sendItinerary"/>
</export>
<export>
<source portType="tio:tripHandler" operation="receiveTripOrder"/>
<target portType="tio:tripNTicketHandler" operation="receiveTripOrder"/>
</export>
<locator type="..." />
</serviceProvider>
<!-- Defines the identity, location and implementation of the service provider
fulfilling the role of the airline -->
<serviceProvider name="airline" serviceProviderType="tio:airlineType">
<export>
<source portType="tio:ticketDelivery" operation="sendETicket"/>
<target portType="tio:tripNTicketHandler" operation="sendETickets"/>
</export>
</serviceProvider>
<!-- A plugLink links the output of an operation of one service provider to
the input of an operation for another service provider -->
<plugLink>
<source serviceProvider="airline" portType="tio:ticketHandler"
operation="sendConfirmation"/>
<target serviceProvider="travelAgent" portType="tio:tripHandler"
operation="waitForConfirmation"/>
</plugLink>
<plugLink>
<source serviceProvider="travelAgent" portType="tio:tripHandler"
operation="requestTicketOrder"/>
<target serviceProvider="airline" portType="tio:ticketHandler"
operation="receiveTicketOrder"/>
</plugLink>
</globalModel>
|
为履行在 WSFL 定义的流程中的服务提供者这一角色，首先必须具有对 WSDL 文档的访问权，这些文档定义了实现 Web 服务必需的基本数据类型、消息和端口类型。然后您必须设计并创建应用程序代码（这些代码实现了要求的端口类型中定义的每个操作）并将这些代码部署在 Web 服务平台（如 IBM WebSphere Application Server 4.0、Apache SOAP 等）上。
成为流程中的一部分
一个好消息是，如果您想成为商业流程中的一部分，您真正要了解的只是如何创建一个 Web 服务。一旦这项工作已经完成，您只需将其插入到 WSFL 全局模型中，该模型将您的 Web 服务实现链接到一个流模型中定义的角色。该链接可以是静态的（全局模型明确指定您的 Web 服务作为给定角色的服务提供者），也可以是动态的（全局模型指定一套用于选择服务提供者的发现规则，您的有可能被选中）。
有大量的参考资料详细介绍了如何创建 Web 服务 — 我偏向于推荐我写的关于 Web 服务工具包方面的教程（请参考参考资料）— 所以关于这方面的细节我就不再赘述了。我在下面提供的是几个演示如何将 Web 服务实现插入到全局模型中的示例。
现在让我们开始吧，开发人员提供您已经实现的 Web 服务的 WSDL 描述。该描述提供了允许客户端应用程序调用您的 Web 服务所必需的所有信息。在 WSFL 工作流中，“客户端”指的是实现各种活动的其它 Web 服务。您的 Web 服务如何调用其它的服务取决于您的流模型定义数据和控制链接的方法。一旦创建了 WSDL，就需要将其部署到一些网络可访问的位置上，最好是部署到您的 Web 服务器上。然后即可任选地将 WSDL 定义的 Web 服务发布到 UDDI 注册方。
现在，假设这一步已经完成。您有了一个名为 Agent.wsdl 的 WSDL 文档，它位于 http://acme.com/services/agent.wsdl。此 WSDL 文档的目标命名空间为 urn:Agent_Service_Implementation，Web 服务的名称为 AgentService。该服务的目的是履行上面勾勒出的商业流程中旅游代理这一角色。
如 WSFL 规范定义的那样，在执行商业流程时，可用 4 种不同的方法来定位您的 Web 服务：静态方法、本地方法、通过 UDDI 的方法或动态方法。
使用静态定位非常简单，只需向 WSFL 全局模型添加一个指向您的 WSDL 服务定义的直接链接即可。这样就会告诉 WSFL 工作流引擎您的 Web 服务的确切位置，而无需作出任何判定（请参阅清单 2）。
清单 2：服务的静态定位
<serviceProvider name="travelAgent" type="tio:agentType">
<!-- the service attribute is a QName that links to
the service definition within a WSDL document -->
<locator type="static" service="abc:agent"/>
</serviceProvider>
|
“本地”服务是不必通过 Web 服务接口来提供的 Web 服务。更多情况下，它们是采用与处理请求的工作流引擎在同一台机器上的应用程序或 Java 类的形式。这些应用程序仍可使用 WSDL 文档进行描述，但描述的方法稍有不同。WSFL 规范可提供关于本地服务的更多详细信息（请参阅清单 3）。
清单 3：服务的“本地”定位
<locator type="local">
<!-- whatever information is needed to locate the local service. This is
up to the WSFL implementation -->
</locator>
|
第 3 种查找 Web 服务的方法是通过使用 UDDI 查询。本来，全局模型定义 UDDI find_service 操作是为了搜索 UDDI 注册方并检索符合条件的一系列侯选 Web 服务。全局模型使用选择策略，判定返回的搜索结果中哪个 Web 服务将被用于履行商业流程中的角色。合法的选择策略包括选择列表中的第一个服务、从列表中随机选择服务或使用一些用户定义的算法。全局模型还可能指出何时执行 UDDI 查询。可以选择在开发时运行查询，这种情况下当 WSFL 模型部署到生产环境中时，UDDI 查询将被静态定位器取代，也可以选择在运行时运行查询，这种情况下就将在首次调用流模型时执行 UDDI 查询（请参阅清单 4）。
清单 4：服务的基于 UDDI 的定位
<locator type="uddi" bindTime="startup" selectionPolicy="first">
<uddi-api:find_service businessKey="uuid_key"
generic="1.0" xmlns:uddi-api="urn:uddi-org:api">
...
</uddi-api:find_service>
</locator>
|
使用 UDDI 使 WSFL 变得更灵活、更强大，允许多个服务提供者通过竞争获取在商业流程中履行一个角色的权利。然而，为 WSFL 添加最高级灵活性的是移动定位器机制，它允许 WSFL 工作流引擎完全根据调用流程时应用的一套规则来选择服务提供者。例如，如果提交的购买订单总额超过 $10,000，那么工作流引擎所选的 Web 服务实现就可能不同于为总额不足 $10,000 的购买订单所选的 Web 服务实现。
用于调用 Web 服务的消息中包含选择实际要调用的 Web 服务实现必须满足的条件，移动定位器指定在该消息的什么地方可找到这些条件（请参阅清单 5）。
清单 5：服务的移动定位器
<locator type="mobility" activity="getFlight"
message="flightInfo" messagePart="airline" dataField="providerInfo">
<!-- rules for applying the mobility locator, these
are determined by the WSFL implementation -->
</locator>
|
总结
WSFL 最强大、最有用的功能之一是其能够允许任何 Web 服务提供者实现商业流程中定义的任何活动。根据用户定义的一套规则来动态定位并绑定到提供者的功能，为处理先前不存在的 Web 上的商务添加了一种新思维 — 动态联合并集成松散结合的应用程序组件。在本栏目的下一部分，我将向您介绍 WSFL 另一个很酷的功能：在现有的商业流程中递归嵌套成新的商业流程。
参考资料
关于作者
 James Snell 是一位撰稿人兼开发人员，他也是 IBM Web 服务开发小组的最新成员之一。他在进入 IBM 之前，已经具有关于定制企业应用开发和商家对商家集成这些方面的深厚背景，而且他对 Web 前沿技术有极大的热情。可通过 jasnell@us.ibm.com 与他联系。
|
|