ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 评论专栏: Peter Xu:为执行而建模

评论专栏: Peter Xu:为执行而建模

原创 Linux操作系统 作者:CloudSpace 时间:2009-06-03 13:50:50 0 删除 编辑

什么是为执行而建模?

IBM® WebSphere® Business Modeler(以下称为 Modeler)提供了功能强大的业务流程建模、模拟、分析和报告功能,可帮助优化您的业务流程的性能。Modeler 可以帮助完成三个主要任务:

  • 为文档和遵从性而建模:有些公司希望仅为了文档的目的而捕获业务流程,如果流程没有以其他方式进行很好的文档说明,并且只有企业中的少数人才理解该流程,那么情况尤其是如此。

  • 为重新设计而建模:有些公司希望采用当前状态(原有)的流程并改进它们。为此,Modeler 提供了功能强大的模拟引擎以提供帮助,同时提供了同于定义将来状态(预期)的流程的动态和静态报告。

  • 为执行而建模:其他公司希望实现业务驱动的开发周期,其中业务分析人员可以构建用于为 IT 创建有用构件的模型。

传统上,Modeler 最广泛地用于上面的前两个任务。随着 Modeler V6.1 的发布及其在与 IBM WebSphere Integration Developer(以下称为 Integration Developer)不相上下的可跟踪性和建模方面的改进,我们正在看到越来越多的用户探索第三个、最困难的任务——同时也是回报最丰厚的使用模式,因为为执行而建模可以支持更快的开发周期,并确保所实现的流程满足业务需求。

为什么为执行而建模是如此困难?

Modeler 具有不同的建模模式。当您执行为文档或分析和重新设计而建模时,您通常是在基本、中级或高级模式下操作。这些模式与产品无关。当您执行为执行而建模时,您是在针对特定的运行时环境。例如,如果您执行为 IBM WebSphere Process Server 执行而建模,那么您必须在 WebSphere Process Server 模式下(图 1)。


图 1. Modeler 模式
图 1. Modeler 模式

这将为您带来某些挑战:如果您是在针对特定的运行时进行为执行而建模,您必须拥有关于该运行时环境的功能和限制的深入技术知识。下面详述一下其中一些挑战:

  • Modeler 中的有些构件无法导出

    Modeler 提供了广泛的建模构件,这些构件在 BPEL 标准中不受支持,因此无法导出到 Integration Developer。例如,其中一个无法导入 Integration Developer 的流构件是环回。其原因在于,环回在 WS-BPEL 标准中不受支持,而 WebSphere Process Server 基于 WS-BPEL 标准。在此情况下,您将需要非常详细的 Integration Developer 技术知识才能找到解决方法。

  • 有些 BPEL 构件无法在 Modeler 中进行建模

    类似地,您也无法在 Modeler 中对某些特定于运行时的构件建模。例如,如果您有一个流程,该流程需要在某个活动之后停止两小时,然后才继续到下一个任务,您可以容易地在 Integration Developer 中对此行为建模,但是您不容易在 Modeler 中做到这一点。

  • 指定运行时模式的技术属性

    当处于 WebSphere Process Server 建模模式时,每个流程关系图在流程编辑器中有一个 Technical Specifications 选项卡。此选项卡为 Modeler 提供了一种为实现和部署所需的技术规范定义值的途径。这里指定的选项将影响代码生成。这需要特定运行时环境的深入知识,从而会给一般根本不太关心运行时的业务分析人员带来挑战。

  • 需要遵循建模和设计最佳实践

    最重要的是,在为 WebSphere Process Server 执行而建模时,围绕 BPEL 设计、SOA 面向服务、业务对象和接口设计,存在必须遵循的附加最佳实践。肯定存在某些超出业务分析人员技能集的东西。认为业务分析人员在 Modeler 中创建的一个逻辑业务流程将确切映射到 WebSphere Process Server 运行时中的一个可执行 BPEL 流程是错误的,因此您可能需要重组该逻辑业务流程,并根据 BPEL 设计最佳实践将其转换为多个模块化的流程。

    为执行而建模中的建议角色

    为执行而建模是相当技术性的工作。虽然有些业务分析人员可能随着时间推移而学到了这些技能中的一部分,但是在实践中,培训他们以使其足够熟悉所有的必需技术性细微差别是极其困难的。已确定为执行而建模的过程中涉及到以下三个角色:


    表 1. 为执行而建模中的建议角色

    角色 工具 技能集
    业务流程分析人员 基本模式的 Modeler
    • 原有和预期流程的专家。
    • Modeler 和标准建模功能。
    • Modeler 模拟和分析功能。
    流程技术架构师 WebSphere Process Server 模式的 Modeler
    • 熟悉业务流程和需求。
    • Modeler 及其技术建模功能。
    • BPEL 设计最佳实践。
    • 面向服务的体系结构(Service-oriented architecture,SOA)最佳实践。
    • 服务组件体系结构(Service Component Architecture,SCA)编程模型和实现类型。
    • 了解 WebSphere Integration Developer 和 WebSphere Process Server 的限制和解决方法。
    集成开发人员 WebSphere Integration Developer
    • BPEL、SCA 和 SOA 设计及实现方面的专家。

    方法

    在确定为执行而建模过程中涉及到的角色和人员之后,您可以进一步将流程细分为三个带关联活动的阶段。

    阶段 I:创建逻辑业务流程模型并建立契约


    表 2. 阶段 I

    角色: 业务分析人员、流程技术架构师
    工具: 基本模式的 Modeler
    输入: 各种业务流程需求文档
    输出: 逻辑业务流程分析模型

    在此阶段中,业务分析人员在 Modeler 中创建纯抽象的逻辑业务流程模型,不做出关于技术实现的任何假设,并且不更改任何语义,以便于移交给 IT。此模型应该足够有效以支持可选的模拟。

    在业务分析人员创建初始的逻辑流程模型之后,来自 IT 部门的流程技术架构师将审核该模型。架构师和分析人员就该流程达成一致。此时,该流程称为业务契约,这意味着 IT 将使用该流程模型作为他们将交付的结果的基础。如果 IT 部门更改流程的功能,则他们将破坏与业务部门签订的契约。然而,IT 可以更改逻辑模型的结构。

    从理论上讲,可以在任何工具中创建逻辑业务流程模型,但是在 Modeler 中创建模型对于阶段 II 大有助益,因为业务分析人员和技术架构师都使用相同的工具、相同的符号和相同的建模语言——从而帮助更容易地进行有关业务契约的交流。

    阶段 II:从逻辑模型中得出物理业务逻辑设计模型


    表 3. 阶段 II

    角色: 业务流程架构师
    工具: WebSphere Process Server 模式的 Modeler
    输入: 逻辑业务流程分析模型
    输出: 物理业务流程设计模型

    建立业务契约以后,流程技术架构师可以开始重组和增强逻辑业务模型。

    架构师在此时有机会基于某些 BPEL 设计最佳实践,将单个较大的逻辑业务流程分解为若干个较小的物理流程(并最终成为单独的运行时 BPEL 流程)。这将是最终的物理流程设计模型。在此阶段,流程架构师将需要设计和定义公共资源;也就是流程所使用的企业范围的公共服务的接口 (WSDL) 和数据类型 (XSD)。

    在此阶段,您知道该业务流程将在 WebSphere Process Server 运行时环境中运行。您应该从一开始就监督物理业务流程设计模型的开发,以使其可按原样导出到 WebSphere Integration Developer:

    1. 去掉任何特定于 Modeler 的构件。例如,如果业务模型中存在已知会导致技术实现挑战的映射节点,则应该将它们更改为任务。
    2. 对任何已知的限制应用解决方法,例如上面提到的环回实例。这还包括 WebSphere Integration Developer 中无法(或不应该)在 Modeler 进行建模的所有注意事项。

    最后,流程技术架构师将使用技术详细信息对流程进行标注。在将流程导出为 WS-BPEL 时,该重要技术信息将在代码生成中加以使用。

    阶段 III:将物理业务流程设计模型增强为实现模型


    表 4. 阶段 III

    角色: 集成开发人员、流程技术架构师
    工具: WebSphere Integration Developer
    输入: 物理业务流程设计模型
    输出: 物理业务流程实现模型

    在导入流程技术架构师创建的流程设计模型以后,集成开发人员需要将该模型增强为完整的实现模型。例如,如果您希望包括诸如错误处理程序、补偿处理程序、QoS 元素等功能,则仍然需要对生成的 WS-BPEL 做更多的工作。在生成的 SCA 组件准备好可供使用之前,需要对它们做附加的工作,但是它们在生成时具有正确的接口和结构,因此简化了开发,并确保满足业务的需要。集成开发人员还将添加无法容易地在 Modeler 中建模的必需构件。

    交互式开发

    使用此方法,还可以实现交互式开发。物理设计模型位于中间,并尽量满足上述逻辑分析模型中隐含的所有业务流程需求;与此同时,它遵循 WebSphere Process Server 的最佳设计实践(BPEL、SCA、SOA),从而简化了物理实现模型的具体实现(图 2)。


    图 2. 物理实现模型
    图 2. 物理实现模型 

    总结

    业务分析人员、流程技术架构师和集成开发人员全都参与为执行而建模的过程,主要是因为在大多数情况下,该活动的极端技术性质使得典型的业务分析人员极难独自完成该任务。在此场景中发挥中心作用的是流程技术架构师,他们桥接逻辑业务模型和最终的实现模型,并确保逻辑模型是可实现的,同时还确保实现模型执行其应有的功能。如果我们要使完整的业务流程管理生命周期成为现实,流程技术架构师是必须得到积极晋升的角色。

  • 作者:Peter Xu, 高级管理顾问, IBM

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14789789/viewspace-604980/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-07-08

  • 博文量
    355
  • 访问量
    855811