引言

本文章系列是以真实的随需应变转化项目，Oneida-2 为基础的。本文使用了一个特定的 Order to Manufacturing Processing System（OTMPS）场景，其在本文章系列（参阅参考资料）中的第一篇文章中已经介绍过，来描述如何实现可执行的随需应变应用程序。

在本文章系列的第 4 部分中（参阅参考资料），我们描述了如何将 WebSphere Business Integration Modeler 和 Rational® XDE 中导出的构件导入到 IBM® WebSphere® Studio Application Developer Integration Edition（Application Developer）中。现在我们向这些构件中添加一些特定的扩展，包括：

• 捕获系统级异常的故障处理程序
• 执行数据转换/事件生成的 Java 片断
• 利用规则引擎实现业务规则
• 生成到服务端点的绑定

回页首

Application Developer 工作流部署流程

通过如下这些步骤，我们描述了开发、测试和部署随需应变业务流程应用程序的方法：

1. 将工作流活动作为服务来实现。
2. 为远程合作伙伴创建封装器。
3. 向工作流中添加规则服务。
4. 添加故障处理程序。
5. 使事件生成可用。
6. 生成部署代码。
7. 开发测试部署。
8. 产品部署。

回页首

步骤 1：将工作流活动作为服务来实现

流程调用工作流活动来实现特定的功能。例如，OrderProcessSystem 调用 Data Format Conversion 活动进行数据格式转化（有关 OrderProcessSystem 中的活动的详细信息，请参阅本系列的第 4 部分）。这个模型中的每个活动都有一个相应的 portType，包含在流程 Web 服务描述语言 （Web Services Description Language，WSDL）接口文件中。业务流程执行语言（Business Process Execution Language，BPEL）流程通过一些操作连接这些活动，这些操作 portType 使用 invoke 活动和合作伙伴链接来实现。例如，WebSphere Business Integration Modeler 导出的流程 WSDL 接口 OrderProcessSystemInterface.wsdl 包含活动 portTypes，如清单 1 所示。

				
<?xml version="1.0" encoding="UTF-8"?> 
<definitions
    targetNamespace="http://Processes/OrderProcessSystem/interface"
	......................
    <portType name="OrderProcessSystemPT"> 
        <operation name="sendOrderProcessSystem_InputCriteria"> 
	.................................
        </operation> 
    </portType> 
    <portType name="DataFormatConversionPT"> 
        <operation name="sendDataFormatConversion_InputCriteria"> 
            <input message="tns:InputCriteriaMessage" name=
            "InputCriteriaMessage3"/> 
            <output message="tns:OutputCriteriaMessage3" name=
            "OutputCriteriaMessage3"/> 
        </operation> 
    </portType> 
    <portType name="DataFormatConversion2PT"> 
                   ………………….
    </portType> 
    <portType name="ManufacturingLoopApplyManufacturingPlantSelectionPolicyPT "> 
                   ………………….
    </portType>
    <portType name="ManufacturingLoopDecrementOrderCountPT"> 
                   ………………….
    </portType>
                    ..............
</definitions>
			

这些 portTypes 需要作为服务来实现。首先，基于流程定义文件 OrderProcessSystem.wsdl 中的 portType，使用 Application Developer 工具来生成服务、绑定和 Java 服务框架类。然后需要在生成的 Java 服务框架类中提供服务的具体实现。

要生成 Java 服务框架，需要完成下列步骤：

1. 在 Application Developer 的 Services 导航栏中，选择服务接口 WSDL 文件 (OrderProcessSystemInterface.wsdl)，如图 1 中所示。
2. 通过选项 Java Service Skeleton 和 Creating new port and binding，创建一个新的 Build from Service。
   图 1. 创建 Build from Service
   
   
3. 从下拉列表中选择适当的 Port type name，如图 2 所示。
   图 2. 创建服务框架
   
   
4. 指定生成的 Java 类的名称和位置，如图 3 所示。

对于 WSDL 文件中列出的所有 portType（活动）重复上面的四个步骤。本实例中共有五个活动（参阅清单 1）：

• OrderProcessSubsystemPT
• DataFormatConversionPT
• DataFormatConversion2PT
• ManufacturingLoopApplyManufacturingPlantSelectionPolicyPT
• ManufacturingLoopDecrementOrderCountPT

除了 Java 类，还生成了绑定和服务 WSDL 文件。绑定文件基于创建新的 Build from Service 时所做的选择生成的。在这种情况下我们选择 Java 服务选项（其他可用选项是 Enterprise JavaBean（EJB）服务），因此绑定 WSDL 包含与生成的 Java 类有关的 Java 绑定信息。服务 WSDL 包含关于如何调用服务的具体端点信息。例如，清单 2 利用 java:address 元素显示了带有服务端点的用于数据格式转换服务的服务文件。

				
	<service name="DataFormatConversion2PTJavaService">
		<port binding="binding1:DataFormatConversion2PTJavaBinding" name=
"DataFormatConversion2PTJavaPort">
			<java:address className=
			"Processes.OrderProcessSystem.DataFormatConversion2PT"/>
		</port>
	</service>
			

图 4 显示了生成 Java 类、绑定和服务 WSDL 文件后的目录结构。

因为只生成了框架代码，接下来必须为每个类提供具体的实现代码。在 user code begin 和 user code end 之间插入您的代码，为特定的活动添加业务逻辑，如清单 3 所示。

				
Package Process.OrderProcessSystem;
/**
 * DataFormatConversion2PT
* Generated code. Only edit user code sections.
* @generated
*/
public class DataFormatConversion2PT {
	/**
	  * @generated
	  */
	public DataFormatConversion2PT() {
		// user code begin {constructor_content}
		// user code end
	}
	/**
 	  * sendDataFormatConversion2_InputCriteria
	  * @generated
	  */
	public Services.ManufactureIn sendDataFormatConversion2_InputCriteria(
		Services.ServiceOutput argInputPart4,
		Manufacturing.Orders argInput2Part2) {
		// user code begin {method_content}
		return null;
		// user code end
	}
}
			

回页首

步骤 2：为远程合作伙伴创建封装器

流程与远程合作伙伴服务交互以执行特定的操作。如果远程服务的绑定可用，我们将在部署的时候绑定服务（详见第七步：生成部署代码）。我们将这么做，例如，如果已经部署了服务并且在 WSDL 文件中其绑定可用。

然而，如果远程合作伙伴服务或者其绑定不可用，这时，需要为远程合作伙伴创建一个服务封装器。该封装器提供实际的服务实现，或充当远程服务的代理。为了使用这个封装器与以前的系统相连，需要添加特定的传输和数据转换机制。在我们的 OTMPS 实例中，我们必须访问远程遗留合作伙伴，该合作伙伴提供了订单校验功能。在这种情况下，通过 WebSphere MQ 协议来访问校验功能。我们创建一个服务封装器，其使用 WebSphere MQ 协议与以前的应用程序相连。

我们使用合作伙伴服务来访问 Validation 和 Manufacturing 服务。每个服务都有一个相应的 WSDL 文件，该文件带有一个 portType 和一个操作。利用合作伙伴链接可以将它们集成到 BPEL invoke 活动中，例如，ManufacturingPlant 服务接口 WSDL 文件（ManufacturePlant1Interface.wsdl），如清单 4 所示。

				
<?xml version="1.0" encoding="UTF-8"?>
<definitions
    targetNamespace="http://Services/ManufacturePlant1/interface"
    .............
    <portType name="ManufacturePlant1PT">
        <operation name="sendManufacturePlant1_InputCriteria">
            <input message="tns:InputCriteriaMessage" name="InputCriteriaMessage"/>
            <output message="tns:OutputCriteriaMessage" name="OutputCriteriaMessage"/>
        </operation>
    </portType>
    ............
</definitions>
			

在 OTMPS 场景中，分别用 FTP 和 MQ 来访问 Validation 和 Manufacturing 服务。在这种情况下，需要为每个服务都生成封装器。生成这种外部封装器的步骤同步骤 3 中描述的用于内部服务的步骤类似。在这些封装器的 Java 类实现中，需要编写执行程序，利用适当的协议来访问远程服务。

回页首

步骤 3：向工作流中添加规则服务

有许多方法可以向业务流程中添加规则。一种方法是在您的流程中添加 Java 片断，并且在片断中使用 BRBeans API（参阅参考资料）编写 Java 代码，来访问使用用 WebSphere Business Integration Server Foundation 中的 Business Rule Beans（BRBeans）框架实现的业务规则。另一种方法是将业务规则封装为服务，使用流程中合作伙伴的链接来访问服务。将所有的规则封装在服务 faÇade 接口中，每个规则作为一个方法公开。第二种方法向流程程序员屏蔽了规则实现细节。程序员可以将业务规则作为服务来调用。

回页首

步骤 4：添加故障处理程序

流程内出现故障，不可能再正常执行时，可以使用故障处理程序试图寻找其他方法完成流程。在 Process 编辑器中，流程及其内部的每个活动都可以有一个与其有关的故障处理程序。首先，在本实例中，用户需要在选择的 BPEL 活动中添加故障处理程序，来捕捉其抛出的异常。捕获如 BPEL 规范中定义的特定故障（例如，invalidReply、runtimeFailure、selectionFailure）或者所有的故障。在本实例中（参阅图 5），我们在 Validate 和 Generate Topology 活动上添加了故障处理程序以捕捉这个活动中产生的所有错误。

接下来需要在故障处理程序中添加必要的活动，如下所示：

• 创建 Java 片断来处理错误。
• 使用 Terminate 活动来立即结束流程。
• 将错误发送到另一个宏流以进行进一步处理。
• 包括用于解决问题的员工。

我们创建了一个长期运行的流程（ExceptionHandler 流程），它包含员工活动并将故障发送到该进程进行进一步的评估和解决。为了使用 ExceptionHandler 流程来有效的处理异常，需要添加一个合作伙伴链接，指向那个流程，然后在故障处理程序中添加一个调用活动，其链接到合作伙伴链接，如图 5 所示。

回页首

步骤 5：使事件生成可用

随需应变业务流程测量需要收集事件，稍后用来计算行量标准和监视 Key Performance Indicators（KPI）。Application Developer 提供的 State Observer Plugin（SOP）自动发送与流程、活动、变量等相应的适当事件（例如 Common Base Events），这些事件在 BPEL 拓展中被标记为 BusinessRelevant 。为了创建事件，选择合适的 BPEL 元素（例如流程、活动、变量），并检查服务器选项卡上的 business relevant 标记。例如，如果已经选择了 OrderProcessSystem 流程并且检查了 business relevant 标记，那么 SOP 生成两个流程实例事件 -- 一个用于开始流程，另一个用于停止流程。

回页首

步骤 6：生成部署代码

除了要对活动进行排序，流程的 BPEL 描述包含服务端口类型、操作和通过合作伙伴链接引用的消息类型。这个流程部署步骤为通过合作伙伴链接使用的真实服务和流程本身创建绑定。

可以利用下列任意一种机制来演示这个服务运行时绑定：

• 运行时生成静态绑定（通过 WSDL 服务绑定信息）
• 通过端点引用的动态绑定（例如，使用 WS-Addressing -- 参阅参考资料）
• 通过 UDDI 引用的动态绑定

由于在部署过程中我们已经有了所有的服务绑定信息，所以在 OTMPS 实例中使用静态绑定。为了在运行时计算端点引用，必须将服务选项卡中 resolutionScope 标记的值为设为 computed。然后您应该在运行时计算端点引用，并且在运行时将这些分配给合作伙伴链接引用（本系列的下一篇文章将包含更多这方面的详细信息）。

流程部署包含分配 WSDL 端口和服务到流程中合作伙伴的端口类型。利用运行时创建的绑定流程与它的合作伙伴相连。

要为流程生成部署代码，右键单击流程 BPEL 文件，然后从菜单中选择 Enterprise Services 和 Generate Deploy Code。如图 6 所示，确定您的流程使用哪种绑定（EJB（默认）、SOAP、JMS）。为了测试，您选择的部署代码无关紧要，因为使用 Business Process Web Client 来初始化流程。

现在需要为每个引用的合作伙伴服务分配端点。高亮显示合作伙伴，点击 Browse，然后查找合作伙伴的 WSDL 服务文件。确保为合作伙伴服务选择了正确的端口，因为在一个 WSDL 服务文件中对于一个服务可能有多个端口。图 7 显示了合作伙伴绑定选择屏幕。

在部署的时候，创建执行所需的构件并打包到一个企业应用程序归档 (EAR) 文件中。通过生成的部署代码，可以通过不同的协议和绑定来访问流程，例如简单对象访问协议 (Simple Object Access Protocol，SOAP)，EJB 组件或 Java 消息服务 (Java Message ServiceJMS)。流程部署完成后，会创建一个包含 EJB 项目和 Web 项目的 J2EE 应用程序项目。

回页首

步骤 7：开发测试部署

工作流应用程序的运行时环境是 WebSphere Business Iintegration Server Foundation。用流安装 J2EE 应用程序与在 WebSphere 服务器上安装任何其他 J2EE 应用程序没有什么差别。图 8 显示了如何用 BPEL 流程部署 J2EE 应用程序。

要测试您的流程，需要完成下列步骤：

1. 创建一个测试服务器。在服务器透视图中，创建一个新的 WebSphere version 5.1 和 Integration Test Environment 类型的服务器行业一个新的服务器配置。
2. 在服务器上安装 J2EE 应用程序。在 Add and Remove Projects 窗口中，将您的项目添加到服务器中。现在，展开您的服务器，您将看到服务器上的项目，如图 9所示。
   图 9. 服务器上安装的应用程序
   
   
3. 创建表和数据源。右键单击服务器然后选择 Create tables and data sources。如果所有部署的流程都是长时间运行的，那么必须执行这一步骤。
4. 启动服务器。加载流程 Web 客户端并测试流程。右键单击测试服务器，然后选择 Launch Business Process Web Client 启动 Web 客户端浏览器窗口（图 10）。
5. 在 Process Template Lists 部分中，选择 My Templates。选中模板名旁边的复选框，然后选择 Start the instance。通过填写所有的字段来初始化 Process Input Message。再次单击 Start instance。图 10 显示了 Web 客户端屏幕。

您没必要使用 Process Web Client 来管理流程。这里有一些流程引擎 API，可以用来控制流程生命周期（例如，开始，停止），并且来为员工活动处理工作条目。

将工作流流程部署为一个服务。在部署代码生成过程中（步骤 7）为启用访问流程的客户端，选择一个或多个内置绑定类型。为了访问工作流流程，客户端需要代理和其他遵循流程绑定类型的辅助构件。例如，对于使用 IBM Web 服务绑定部署的流程，可能使用流程 WSDL 文件来生成 JAX-RPC-type 服务代理。或者，可能使用 IIOP 来访问用 EJB 绑定部署的流程。

回页首

步骤 8：生产部署

测试完成后，可以将生成的 J2EE 应用程序项目作为一个 EAR 文件导出到生产部署目录中。这个 EAR 文件包含运行时执行所需的所有文件。安装带工作流流程的 EAR 文件同任何其他 J2EE 应用程序的安装是一样的。但是在工作流流程部署到生产环境中之前，正确安装和配置 WebSphere Business Integration Server Foundation 十分重要的。为运行工作流流程，需要设置流程容器。有关如何安装和配置 WebSphere Business Integration Server Foundation 的详细信息，请参阅参考资料部分中的 WebSphere Application Server 信息中心。

回页首

结束语

可执行工作流的开发是随需应变业务流程生命周期中的一个关键步骤。作者描述了如何将工作流活动实现为服务，以及如何为远程合作伙伴生成服务封装器，如何生成部署代码以及各种绑定和部署方法。最后，他们描述了使用流程 Web 客户端进行流程测试以及如何通过服务代理访问流程。在本系列接下来的文章中，作者将讨论业务流程监控、定制、员工活动、性能和调整。

致谢

作者希望向 Martin Keen、Naveen Sachdeva 和 Catherine Rivi 表示感谢，感谢他们对本文内容的贡献、建议和辅助。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 阅读随需应变业务流程的生命周期的所有部分，并且随时注意我们新的文章。
  
  
• 从使用 WebSphere Process Choreographer 进行动态服务绑定这篇 developerWorks 文章中学习更多东西（2004 年 6 月）。
  
  
• 阅读 IBM 红皮书 BPEL4WS 关于 WebSphere 业务集成的业务流程：理解，建模，移植（2004 年 12 月）。
  
  
• 在白皮书BPELJ：针对 Java 技术的 BPEL 中查找关于 BPELJ 的更多信息（developerWorks，2004 年 3 月）。
  
  
• 从 developerWorks 上获取 Web 服务的业务流程执行语言，版本 1.1 规范。
  
  
• 访问 BRBeans API。
  
  
• 阅读 WebSphere 中的业务流程编排器：联合 BPEL 和 J2EE 学习更多内容。
  
  
• 在 WebSphere Application Server 信息中心查找更多资源。
  
  
• 从 developerWorks 上下载 Web 服务寻址 规范
  
  
• 访问 Developer Bookstore，上面有关于技术书籍的全面列表，包含数百篇 Web 服务标题的文章。
  
  
• 想获取更多信息吗？developerWorks SOA and Web services 专区有成百上千篇信息文章，以及关于如何开发 Web 服务应用程序的入门级、中级和高级教程。
  
  
• IBM developerWorks 小组有成百上千篇各种技术简报可以免费索取。
  
  

作者简介

为本文评分

评论

回页首

内容

• 引言
• Application Developer 工作流部署流程
• 步骤 1：将工作流活动作为服务来实现
• 步骤 2：为远程合作伙伴创建封装器
• 步骤 3：向工作流中添加规则服务
• 步骤 4：添加故障处理程序
• 步骤 5：使事件生成可用
• 步骤 6：生成部署代码
• 步骤 7：开发测试部署
• 步骤 8：生产部署
• 结束语
• 参考资料
• 作者简介
• 建议