内容


评论专栏

为执行建模,再论

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 评论专栏

敬请期待该系列的后续内容。

此内容是该系列的一部分:评论专栏

敬请期待该系列的后续内容。

为执行建模 & BPM

在 2008 年的一篇关于 IBM® WebSphere® 业务流程管理工具的 文章 中曾讨论过为执行而建模的方法。在 2009 年的一篇 后续文章中 讨论了 IBM 的 BPM 堆栈产品 V6.2 版本的改进,这些产品简化了为执行建模的流程。现在到了 2010 年,由于我们已经在这个领域有了一些实际的实现体验,另外业务流程管理方面也出现了一些新的工业标准,因此现在是时候来再次讨论一下这个主题了。

什么是为执行建模?

为执行建模并不是一个新概念,因为这种方式已经在传统的软件和系统开发中被用了有一些时间了。它总是开始于一个用某种可视语言表达的高级平台独立模型(PIM)。这个模型然后会被以一种针对特定平台的特定的编程语言翻译或转换为一个特定于平台的模型(PSM),然后才可被编译后执行。实际上,这个方法使用了 Object Management Group (OMG) 的 Model Driven Architecture (MDA) 的原理。图 1 显示了这两个模型之间的关系。

图 1. 模型转换
图 1. 模型转换
图 1. 模型转换

这个受模型驱动的架构开始于我们熟知的并且是长期建立起来的将系统的运转与该系统如何使用其平台功能的细节分离开来的想法。MDA 的三个首要目标就是通过关注点的架构分离的可移植性互操作性可重用性

BPM 解决方案交付是一种新的受业务驱动和以流程为中心的交付应用程序的方法。它能够也应该使用在过去十几年间的软件开发和系统工程中所积累的最佳实践。MDA 原理当然也可以应用在这里,但由于 MPM 解决方案交付比较独特,因为它更强调可重复的业务设计并需要业务使用者和分析人员更多的参与,因此在采用为执行而建模技术时需要加以特别的考虑。

用 WebSphere BPM 应用为执行建模

很多公司均已经为基于 WebSphere BPM 产品套件的解决方案交付使用了为执行而建模的方法和技巧。图 2 显示了从业务模型转换为技术业务模型再到实现模型的典型转换。

图 2. 从业务模型到实现模型
图 2. 从业务模型到实现模型
图 2. 从业务模型到实现模型

图 2 显示了这三个阶段:

  • 一个业务分析员或业务流程架构师在 Basic 或 Advanced 模式下在 IBM WebSphere Business Modeler 中创建一个业务模型。这个业务模型图形化地显示了业务流程并使用了与业务分析员和主题专家相关的语义。这个业务模型也可被用于仿真。
  • 一个技术业务分析员或技术流程架构师在 IBM WebSphere Process Server 模式下优化此模型,生成一个技术业务模型来图形化地给出业务流程并开始将业务语义翻译成技术语义。技术业务分析师从 WebSphere Business Modeler 作为一个项目交换文件导出技术业务模型,这个文件的格式为 .zip,内含组成这个实现模型的所有运行时工件。
  • 一个流程架构师或集成开发人员将这个实现模型导入到 IBM WebSphere Integration Developer。 这个实现模型图形化地给出要实现的业务流程。集成开发人员可进一步完善这个模型并完成从业务语义到技术语义的翻译。

这里有一点非常重要,需要注意,即虽然是工作在 WebSphere Business Modeler 内,但底层的那些模型还是表示为一个特定于 Modeler 的 BOM(业务对象模型)流程模型。当作为一个项目交换文件导出模型时,这些 BOM 流程模型就会被转换为 BPEL 流程模型,而这正是您在 WebSphere Integration Developer 内处理的语义。

改进这个开发流程

用户在使用为执行建模的方式交付 WebSphere BPM 解决方案方面有了一些成功经验,尤其是在再面向对象和以集成为中心的流程领域。而它的实现是通过使用 BPEL 作为转换自业务流程模型的底层特定于平台的模型(PSM)获得。 BPEL 是一种开放的行业标准,也是一种经过验证的流程编排语言,并特别侧重于 Web 服务集成。现在,很多公司都具有基于 BPEL 的关键流程应用程序在生产中运行,提供了所需的事务整体性、安全性和性能。

虽然就运行时而言,目前的 WebSphere 的为执行建模提供了强壮的解决方案,但是在开发流程方面仍有改进的空间,尤其是在迭代开发的模型同步领域。

图 3 给出了在目前的工具条件下这个情况是如何处理的。

图 3. 用 WebSphere BPM 工具进行的迭代开发流程
图 3. 用 WebSphere BPM 工具进行的迭代开发流程
图 3. 用 WebSphere BPM 工具进行的迭代开发流程

如您所见,这个流程可能会相当复杂,并且会涉及几个手动步骤,而手动步骤很容易发生错误。实际的用户体验也表明这种方式对于经常需要进行更改的情况将非常有挑战性,这就是广为人知的 “roundtriping” 问题。当然,这个问题并不是 WebSphere BPM 堆栈独有的。只要您在具有不同语义的不同领域间进行模型转换,模型同步都将是一个挑战。

于是出现了为执行建模的一些最佳实践。一种是在 WebSphere Integration Developer 内减少对代表着业务模型的业务逻辑模块的更改。由于业务逻辑模块内的元素直接与 WebSphere Business Modeler 内的元素映射,所以应该在 WebSphere Business Modeler 内做更改。尤其应该减少对流程的结构性更改。

像这样的建议对于减少模型同步的需要可能会有所帮助,但是它们并不能完全消除这种需求,而这就为我们带来了另一种方式。

共享模型和 Lombardi 方式

Lombardi Software 是 BPM 软件和服务的领先提供商,该公司于今年年初被 IBM 收购,它对为执行建模有着自己独特的见解,因为它会在流程的整个生命周期都保持此模型具有相同的格式。图 4 给出了 Lombardi Teamworks BPM 套件的架构。

图 4. Lombardi Teamworks 为执行建模的方式
图 4.  Lombardi Teamworks 为执行建模的方式
图 4. Lombardi Teamworks 为执行建模的方式

如上所示,在 Teamworks 内定义的所有流程元素均存储在一个单一的 Shared Model 中,用以表示流程内的每个元素,从流程图到业务数据、用户界面和系统集成。借助 Shared Model 架构,在一个流程元素内所作的更改会(根据访问权限)立即可见并可由其他流程元素访问。这就使得流程元素之间的依赖性一目了然,也就让流程设计者能够进行更好的交流并有助于流程质量的提高。

那么,为什么这一点对于为执行建模如此重要呢?因为业务建模者和开发者(如图 4 所示)处理的是相同的共享底层流程模型 —— 只是从不同的视图和透视图 ——- 此模型永远不会不同步,并且 roundtripping 问题也没有了!这个范型会激励更为迭代和敏捷的开发,业务管理者和 IT 部门也会有更紧密的协作。

结束语

现在,对于为执行建模我们有了两种策略:

  • 转换模型以实现优化的运行时行为。
  • 跨流程生命周期共享模型。

哪个更好?答案仍要依赖于您实现的是哪种业务流程以及哪些因素对您最为重要,比如是对敏捷和迭代开发的支持,还是对 round-trip 的支持,又抑或是运行时健壮性、持续流程改善、鼓励业务/IT 协作的简单易用性,等等。

希望这些信息能够帮助您在为您特定的需求选择正确的方法和工具时扩展您的思维和决策过程。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=501528
ArticleTitle=评论专栏: 为执行建模,再论
publish-date=07222010