引言

这一系列文章基于真实的按需转换项目 Oneida-2。正如本系列文章的概述篇“按需业务流程的生命周期，第 1 部分”中描述的一样（参阅 参考资料）。本系列中这篇特殊的文章集中在生命周期的一个方面：Business Process（BP）模型的设计。在 Business Process 建模的元素（即将到来）中，我们介绍了使用 WebSphere Business Integration Modeler 进行流程建模的基本概念。本文中，我们描述了使用该系列概述篇中描述的 Order to Manufacturing Processing System（OTMPS）场景进行建模的细节。

我们遵循 OTMPS 建模的一系列步骤。需要注意的是为了使模型对于开发更加有用，需要做一些迭代。

回页首

搜集 BP 需求

在这一部分中，业务需要利用 IBM® WebSphere® Business Integration Server Foundation's Process Choreographer 的优点来自动化订购流程。这就让您在所需环境中可以更快的修改自动化的流程。通过在 WebSphere Business Integration Modeler 中创建流程的模型，业务分析捕获的关于流程如何工作的信息可以被导出，以供工作流开发人员在 Websphere Studio Application Developer Integration Edition 中使用。在这部分中，业务分析确定了下面这几个核心的活动：

• 接收订单
• 用外部验证服务来验证订单
• 记录无效订单并且通知操作人员
• 将合法的订单发送给合适的生产厂商。

接下来的步骤是确定数据元素并且为其建模，比如到来的订单，生产数据和验证数据。这些数据项可以被输入或者输出到活动、存储库、流程或者服务。

为业务条目建模

我们一步步地来看一下如何创建业务条目、业务条目模板和业务条目实例。

图 1 显示了一个名为 manufacturing 的数据目录，来组织所有与生产相关的数据模型，诸如订单和订单状态。数据目录的创建是可选的；另外，您可以在 WebSphere Business Integration 提供的默认的 Business items 数据目录中创建数据模型。

业务条目被创建并添加到现有的数据目录。例如， 图 1 显示了一个“Orders”业务条目和它的属性，比如“orderItems，” “mfgNum，” 和“valid”。这些属性可以是简单类型（例如，String，Integer 和 Boolean）或者是来自相同或不同的数据目录中的业务条目。“Orders”业务条目包含来自相同数据目录中类型为“OrderItem”的“orderItems”属性。

如果不创建业务条目，也可以在为流程建模以前将现有的 XSD schemas 导入到 WebSphere Business Integration Modeler 中去。对于每个 XML schema，创建了一个数据目录，并且该 schema 的内容被映射到数据目录的元素中去，比如业务条目和模板。

为服务建模

在 WebSphere Business Integration Modeler 中，服务定义为外部实体（在被建模的流程的外面），可以在组织的流程里面使用。在 OTMPS 场景中，我们与外部服务相互交互，比如 Validate &Generate Topology 服务和 Manufacturing 服务。

图 2 显示了 WebSphere Business Integration Modeler 向导，用来定义外部服务的输入和输出。该图片显示了使用类型为“Validate In”类型输入的 Validate & Generate Topology 服务。在 WebSphere Business Integration Modeler 中，您可以将一系列输入分组，名为输入标准。因为我们要导出到 Business Process Execution Language（BPEL）中，所以您被限制每个元素只能有一个输入标准。在 Web Services Description Language（WSDL）接口模型（portType 定义）中，这个输入标准和输出标准分别映射到操作的输入和输出消息。

在为流程建模的后面几个步骤中，您将看到如何在 BP 模型中创建服务调用任务。

为业务策略建模

系统分析师可能用自然语言指定计划中的策略作为注释。在这个示例的场景中，您为生产厂商的选择定义了一个策略。这个策略使业务拥有者能决定对于特定的订单选择哪个生产厂商。例如，一种策略可能指定超过一百万美元的订单应该参照一些优先级策略由特定的生产厂商来进行，比如回转时间。另一个策略可能指定当首选的厂商不能生产时该如何处理订单。

分析师将这些策略记录在每个任务的注释区域。开发人员负责将策略转换为规则。分析师可以添加到模型服务元素，这些元素表示提供实施点的已存在服务。为了执行策略的代码来呈现占位符，他们也可能添加任务。开发人员添加所需的代码来实现这个任务，例如，执行正确的规则。（在即将到来的本系列第六部分中将提供细节，“定制：策略与规则”--参阅 参考资料）。

回页首

进行模型开发

这部分描述了如何定义如下的流程元素：

• 控制流
• 子流程
• 策略
• 度量

我们从下面这些来开始描述建模方法：

• 标识和列出任务
• 任务排序
• 任务之间控制流的创建
• 流程里面数据的引入
• 流程模型内部服务的集成

创建流程

通过在 Eclipse 种选择 Business Process modeling 透视图，您可以访问 WebSphere Business Integration Modeler 特性。可以创建流程目录或者文件夹，帮助您组织流程、任务、服务和存储库模型元素。

一旦创建了一个流程目录，下面的步骤就是打开“Create a new process”对话框，如 图 3 所示。该图显示了两个流程目录，“流程”和“服务”。在这个例子中，您在“Processes”目录中创建了一个名为 OrderProcessSystem 的 BP，然后，您可以在 WebSphere Business Integration Modeler 流程编辑器中打开这个流程，来完成流程图（参阅 什么是流程图？）。

图 4 显示了空流程编辑器。在流程图中有两种类型的视图可用： Swimlane 视图和 Free-Form 布局（参阅 流程图观察获取更多细节）。这里您使用一个 free-form 布局图。

图 5 图示了在 WebSphere Business Integration Modeler V5.1 中对于 Order Process Subsystem的一个完整的流程段。这个简单的模型图示了订单从验证但执照的流程。该模型集成了一个验证服务伙伴，通过 Validate & Generate Topology 服务调用步骤。 图 5 显示了一个决策点，“验证成功？“，两个数据格式转换任务，以供流程后来使用的本地数据仓库来存储客户订单，以及一个流程环来选择并且将订单提交给正确的生产厂商。

图 6 显示了 while 循环的内容（Manufacturing Loop）。这个模型使用 Apply manufacturing Plant Selection 任务和生产厂商服务调用步骤，图示了流程流中的一个策略执行点。

在下面的章节中我们解释了如何完成模型，如 图 5 和 图 6 所示。

创建任务

在流程建模中，任务是最低级的活动。比如，在 图 5 中， Data Format Conversion 是一项任务，负责将订购单消息转换为验证服务消息。一项任务不能再进一步分解。每项任务说明包含输入、输出和完成该任务所需的资源。 Data Format Conversion 任务接收”Orders“业务条目作为输入，并且输出”Validate In“业务条目。接下来开发人员添加这个任务的业务逻辑实现。例如，当上面的任务转换为 BPEL 时，该任务变成 BPEL 流程中的一个调用方法。为 Order Process Subsystem 生成的 WSDL 文件包含一个 portType，其包含的操作如清单 清单 1 所示。

                
    <portType name="DataFormatConversionPT">
        <operation name="sendDataFormatConversion_InputCriteria">
            <input message="tns:InputCriteriaMessage" 
name="InputCriteriaMessage3"/>
            <output message="tns:OutputCriteriaMessage3" 
name="OutputCriteriaMessage3"/>
        </operation>
    </portType>
      

接下来开发人员为上面的 portType 生成服务实现代码，并且添加必须的实现代码。这方面的细节将在本系列文章的第五部分中涉及到，“工作流开发、部署和测试“（参阅 参考资料）。

创建循环

一个循环描述了一个流程内部一系列循环的活动。 图 6 显示了一个 while 循环（Manufacturing Loop），迭代每个订单，选择正确的生产厂家并且将每个订单提交给所选的生产厂商。一个 while 循环在满足一些条件的情况下，将重复所包含的活动。这个条件是通过一个用 Expression Builder（参阅 Expression Builder）创建的正规表达式来指定。

如 图 7 中所示，值为”Processes.OrderProcessSystem.Control Data.Order Count“的 Modeling artifact 被选为第一个条件。接下来选择运算符”is greater than“，最后类型”Number“值为 0.0 的被选择为最后一个条件。这就产生了如下的表达式：”Processes.OrderProcessSystem.Control Data.OrderCount' is greater than 0.0“，其可以输出为 BPEL 文件。 清单 2 显示了这个 while 循环和相应的条件。

                
<while condition="DefinedByJavaCode"            name="ManufacturingLoopInputCriteria" 
wpc:displayName="Manufacturing Loop">
   <wpc:condition>
                <wpc:javaCode>
<![CDATA[return 
((getControlDataVariable().getControlDataPart().getOrderCount()) > (0.0));
]]>
                </wpc:javaCode>
   </wpc:condition>
. . .
      

添加决策点

基于成功地将条件测定为“true”，一个决策将输入发送到几个可选的外出路径之一。简单的决策有一个包含一个输入的引入分支和两个各包含一个输出的外出分支。在运行时，如果一个特定的条件是 true，流程流将采用一个外出分支，如果相同的条件是 false，将采用另外一个分支。 图 5 显示了一个简单的决策点，“Validation Successful？”，其采用“service output”业务条目，检查是否校验成功，并且这时选择一个途径来继续订单处理或者退出执行流程。这个条件使用 Expression Builder 通过一个正规的表达式来指定。

排序

连接器被添加到元素之间，使他们能够在恰当的时候启动。具有多个连接器的元素的逻辑通过他们的 Input Criteria 来控制。分析师使用业务规则和数据优先权需求来决定序列中元素的顺序。

回页首

创建存储库

流程可能存储数据并且随后在处理时使用这些数据。在 WebSphere Business Integration Modeler 中，这种数据存储机制叫做存储库。这个概念同编程语言中变量类似。每个存储库有一个名称和一个相关的业务条目类型。两种类型的存储库是局部的和全局的。局部存储库为一个流程所有，并且仅能被该流程中的元素使用。这些数据元素直道流程结束时都是可用的。全局存储库是在项目的级别上创建的，对于多个流程都是可以访问的。我们的讨论仅仅集中在局部存储库上，因为 BPEL 执行并不支持全局存储库。

图 5 显示了三个局部 OTMPS 存储库：

• Orders Repository，其保存“order”业务条目。
• Subprocess Execution Control Data，其保存流程执行“control”数据。
• Manufacture Data Input Repository，其保存“manufacturing input”数据。

在我们的例子中，我们使用存储库来存储业务条目（订单、控制数据、生产数据），其可以在 while 循环（Manufacturing Loop）内部访问，因为他们不能被传递给连接器。 清单 3 显示了一个转换局部存储库到 BPEL 变量的例子。

                
Repository "Orders Repository" becomes a Java snippet and repository content 
becomes a BPEL variable:
<variable messageType="wsdl:OrdersRepositoryMessage" 
name="OrdersRepositoryVariable"/>
and could be accessed from the workflow using the expression: 
getOrdersRepositoryVariable(true).
      

将业务条目与连接以及局部存储库相联系

在一个流程模型中，数据在任务之间流动。业务条目或者实例在任务之间可以同连接联合起来。 图 8 显示了 OTMPS 模型的一部分。

图 8 显示了从任务 Order Process Subsystem 到任务 Data Format Conversion 的控制流，接下来是到任务 Validate & Generate Topology。另外，该模型显示了到局部存储库的数据流。所有的连接都用面板中的连接工具连接起来（参阅 排序）。这时，您可以将业务条目同连接联合起来。例如， Data Format Conversion 同 Validate & Generate Topology 任务之间的连接显示了一个关联业务条目“Validate In。”联合业务条目同局部存储库的过程是通过同样的方式。

一旦创建了局部存储库，并且使用连接工具连接到一项任务，该业务条目通常就会于连接结合起来。例如， 图 8 显示了任务 Order Process Subsystem 同两个局部存储库之间的连接。第一个连接将“Orders”数据同 Orders Repository 存储库关联起来，然而另一个将 Controller Control Data 同存储库 Subprocess Execution Control Data 连接起来。

注意，当在 WebSphere Business Integration 'Basic' 模式时，如果被连接的元素的输入输出已经被分配了业务条目，那么在元素之间描绘连接时将显示一个对话框（参阅 图 9）。该对话框提供了选择现有输入输出的选项，或者创建新的输入输出。

回页首

将服务和子流程集成到流程模型

服务以及子流程元素通过与其他元素同样的方式被添加到流程中。服务不是在面板上选择，而是被创建（如同 为服务建模中描述的一样）并从项目树中拖进来，因为它们是 可重用的元素。服务以像任务那样的方式导出到 BPEL，除非每个服务都有它自己的 WSDL 文件。

作为最佳实践，关于被建模的现有服务的任何知道的信息都应该被添加到服务描述字段中。该信息可能包含服务描述、绑定选择、发现机制和部署选项。这些描述指导开发人员去创建所需的发现、绑定、部署和集成代码。

子流程用来隐藏模型的细节，并且作为 scopes 同流结构的活动一起导出到 BPEL。在BPEL 中，范围允许定义拥有自己的关联变量、错误处理和补偿处理的嵌套活动。

回页首

映射元素

映射元素用来在不同的结构之间转换数据格式，例如，无论什么时候，在连续的元素之间数据格式都是不相容的。在可执行的 BPEL 工作流中，他们看起来就像是 Java 片断。如 图 5 所示，映射元素被添加到流程的末端，将业务条目“Service Output”转换为“OrderProcessResponse”。

回页首

KPI 以及度量

BP 监视能力允许流程所有者和管理者实时监控 BP Key Performance Indicators（KPIs）。在 OTMPS 场景中，分析师可能定义一个 KPI，然后向相应的任务或者流程添加观测点。

例如， 图 10 显示了一个名为“Number of orders received each hour”的 KPI 和相应的观测点。在图片中，我们选择了 Input Criteria 和 Output Criteria 作为观测点。在流程模型中该 KPI 与 Order Process Subsystem 任务关联在一起。关于这些 KPI 定义和观测点如何实现的细节在本系列文章的第七部分，“使用 CET 对业务流程进行监测”（参阅 参考资料）。

回页首

流程模型验证和导出

将 modeler 置于 BPEL 模式就开启了 BPEL 验证检验器。任何错误或者警告都会出现在 Error View 中。该模型可以同错误一起导出，但是最后这些都应该确定下来，将来在导出的时候就不用再做重复的工作。一旦流程模型准备完毕，分析师为 WebSphere Studio Application Developer Integration Edition 导出所需的 BPEL、XSD 和 WSDL 文件，或者导出到现有的服务项目，或者是一个文件夹，用来以后导入到一个服务项目中。关于生成的文件和流程模型元素之间的关系，以及生成文件中相应的构件，请注意即将到来的文章，“业务流程建模的元素”。

回页首

结束语

按需业务流程通过自顶向下的途径来建模，并且遵从 Service-Oriented Architecture（SOA）来实现。由业务分析师进行的自顶向下的建模是按需业务流程生命周期方法论的一个关键元素。BP 模型定义了技术框架来将业务规范和 IT 开发联系起来。一个共享的模型在业务流程整个生命周期被预留，来帮助保持业务和 IT 观点同步。这篇文章描述了一些技术和指导，分析师可以用来使用 WebSphere Business Integration Modeler V5.1 定义按需业务流程。

回页首

致谢

作者希望感谢 Samantha Shurety 对本文的草稿的检查。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 阅读 按需业务流程生命周期的所有部分，并且时刻注意我们新添的部分。
  
  
• 阅读规范 用于 Web 服务的业务流程执行语言，1.1 版，2003 年 5 月。
  
  
• 在文章 BPELJ：用于 Java 技术的 BPEL 中，学习如何使用 BPEL 和 Java 编程语言，一起构建业务流程应用程序。
  
  
• 在 WebSphere Business Integration Modeler 5.1 FAQ 中查找您存在问题的答案。
  
  
• 浏览 WebSphere Business Integration Library，查找执行摘要、红皮书以及产品文档。
  
  
• 文章 业务流程建模的元素（即将到来），由 Ken Beck、Joshy Joseph 和 German Goldszmidt 编写，提供了关于分析师用来定义业务流程的建模概念的有价值的信息，以及 WebSphere Business Modeler 所支持的一些特性。
  
  
• 可以从下列文章中获取按需操作环境的相关信息：
  • 按需操作环境（ developerWorks，2004 年 8 月）
  • 实现随需应变的操作环境要素（ developerWorks，2004 年 8 月）
  • 按需解决方案的架构设计：利用 IBM 按需操作环境 13 种特性的最佳实践 （ developerWorks系列文章）
  
  
  
• 访问 Developer Bookstore 以获取综合性的技术图书列表，其中包括数以百计的 Web 服务主题。
  
  
• 想获取更多信息吗？developerWorks 的 SOA 与 Web 服务专区拥有许多提供信息的文章和关于如何开发 Web 服务应用程序的入门级、中级的和高级教程。
  
  

作者简介

为本文评分

评论

回页首

内容

• 引言
• 搜集 BP 需求
• 进行模型开发
• 创建存储库
• 将服务和子流程集成到流程模型
• 映射元素
• KPI 以及度量
• 流程模型验证和导出
• 结束语
• 致谢
• 参考资料
• 作者简介
• 建议