内容


集成 BPMN 与 SoaML,第 1 部分

动机和方法

Comments

在这个由 3 部分组成的有关 BPMN 和 SoaML 集成的文章系列中,我们将学习如何让每项标准优势互补。本系列中的文章将介绍如何:

  • 指定利用了各自的补充性功能的 BPMN 和 SoaML 集成的需求。
  • 通过从不同的视角进行审视,更好地理解 BPMN 或 SoaML 的概念。
  • 传达可用于在 BPMN 与 SoaML 之间相互转换的模型间转换,以便在受支持的工具之间交换模型。
  • 通过一种语言中的相关概念,定义另一种语言中捕获的模型元素之间的关系。例如,SoaML 参与者拥有的行为可以链接到一个描述该行为的实现的 BPMN 流程。
  • 以最佳方式使用两种建模语言。
  • 支持更有效的建模实践,以便从模型中获取更多的价值,理解复杂性,改善规划,以及享受其他收益。
  • 简化进一步改善的可重用资产的规范。
  • 在供应商工具中推广受 OSLC 规范 支持的现有集成功能。
  • 为了通过扩展当前 OSLC 规范来实现额外的链接功能而提供基础。

集成 BPMN 与 SoaML 的动机

Object Management Group (OMG) 已批准使用业务流程建模符号 (Business Process Modeling Notation, BPMN) 2.0,BPMN 2.0 是 BPMN 1.0 符号的一个重要更新,它支持流程编排、协作和筹划。OMG 还批准了 SOA Modeling Language (SoaML) 1.0,这是针对面向服务的架构 (SOA) 建模而对统一建模语言 (Unified Modeling Language,UML) 2 的进行的一次配置文件扩展。这些标准在一些区域存在重叠,但每项标准都有特定的关注点。

BPMN 专注于流程模型。它从业务流程中活动的简单编排着手,通过扩展来支持流程间的协作,并通过再次扩展来支持对流程间的交互的筹划。

SoaML 专注于服务架构,以及通过使用合约来建模服务水平协议 (SLA),对服务架构中的参与者之间的交互进行封装。因为 SoaML 是 UML 的一种扩展,所以服务模型可包含服务架构中的行为、服务合约和服务参与者,以建模服务使用者与提供者之间的交互。这些模型涵盖了服务的实现方式和使用方式。

尽管这些标准涵盖许多相同的主题,但它们从不同的角度来处理结构和行为。每种标准在其语义和符号上都有独特的特性,这些特性通常会在支持性工具和平台中反映出来。我们面临的挑战在于如何使用这两种建模语言(单独或结合使用,在相同或相关的项目上使用),如何利用独特的、补充性的特性,以及如何避免冗余。

本文是由 3 部分组成的文章系列的第一部分,该系列将介绍如何集成 BPMN 与 SoaML,以及如何最大化二者的优势的各种方式。探索集成它们有何用途,了解集成的需求,并发现分析这些建模语言之间的异同的方法。

第 2 部分将介绍每种语言如何解决:

  • 封装:对封装元素或组件的一种描述,包括它与其他原型组件的潜在交互。
  • 合约:组件之间的潜在交互的封装和规范,以及组件应遵守的协议
  • 结构:封装组件的内部结构,包括其他组件的组装
  • 行为:组件的内部行为实现或编排的表示,包括组件如何依据协商一致的合约而使用和提供服务

此分析提供了第 3 部分中提出的集成的基本信息。建模人员可以使用此信息确定将何种语言用于何种用途,以及如何有效地结合使用它们。工具供应商可以使用该信息提供支持性工具之间的链接,以便支持集成,提供额外的建模选项,实现更好的可跟踪性和影响分析。OMG 成员可以使用这些文章中的信息,指导创建针对未来标准发展的征求建议书 (RFP)。

结构和行为

结构和行为是区分 SoaML 和 BPMN 的补充性功能的一种途径。考虑一个域或问题空间的外部和内部视图。外部视图 描述了实体的外表面或规范视图。此视图包含需求端和供应端的组件,指定了目标和价值主张、需求和功能,以及预期和承诺。内部视图 描述了一个实体选择来实现其目标的信息和活动设计。它包含提供与其承诺一致的价值主张的行为。

这些视图相结合,从不同角度解决了组织、信息和行为问题:结构规范和行为实现。要了解这些不同视图的影响,需要关注关心它们的主要利益相关者。BPMN 和 SoaML 的集成必须为这些角色之间的更有效集成提供支持。

使用 BPMN 和 SoaML 的人员的角色

业务分析师可使用 BPMN 分析业务流程,以便识别新的、经过调整的或经过更新的功能和服务。它们还可以创建业务流程,以便在实现它们后筹划或编排这些功能和服务。此任务有时被称为服务使用。

业务分析师一般不会关注或者无法定义服务架构来充分解决 IT 解决方案问题,比如分发、持久性、可用性、事务范围和完整性、安全性和类似问题。BPMN 提供了足够多的建模功能来从此角度提供支持。

解决方案架构师负责开发一个有效、高效的解决方案架构,以便满足当前和预期的需求。它们可以使用通过 SoaML 配置文件进行了扩展的 UML(一种针对模型驱动的架构 (MDA) 的主要的 OMG 规范),作为一种通用的建模语言。SoaML 支持广泛的业务和解决方案分析功能,包括功能和服务的设计和构造。集成 BPMN 与 SoaML,为开发团队提供了一个完整的服务构造和使用解决方案。

这一集成在企业架构管理中尤其有用,因为它提供了一种将业务架构构建块与实现它们的信息系统构建块连接起来的途径。两组构建块都采用了 SOA 风格,以便最大程度地减少企业中的构建块之间的耦合。集成这些建模语言为探索 BPMN 和 SoaML 的具体需求提供了上下文。

BPMN 和 SoaML 集成的需求

该集成必须满足以下需求。

需求 1:业务分析师可描绘 BPMN 流程,无论是使用简单的编排,还是与其他流程参与者一起进行更全面的协作、交流或筹划。可以采用类似 UML 用例的方式采用这些流程来执行需求分析。一个泳道中的每个任务以及流程中的每个泳道或每个流程都可以表示某个业务活动的一种需求。然后,可以使用这些任务来识别将用来完成任务的候选服务。业务分析师必须能够在 BPMN 任务、泳道或流程与一个或多个 SoaML ServicesArchitecture、Capability 或 ServiceInterface 元素之间创建实现关系。

需求 2:识别 SoaML 功能后,可以使用 SoaML 指定公开这些功能的服务接口。提供可开发的服务的参与者拥有实现它们的方法。

需求 3:由 SoaML ServicesInterfaces 定义并由 SoaML 中的参与者提供的服务,然后可以使用 BPMN 流程中的 ServiceTasks 调用。此能力使得 BPMN 能够利用 SoaML 所定义的可重用的服务。

需求 4:参与者拥有的服务操作的方法(或实现)可建模为 SoaML 中的 UML 行为。行为可以是一个 Activity、Interaction、StateMachine 或 OpaqueBehavior。参与者拥有的行为是参与者所提供的服务操作的方法,而且使用该参与者需要的服务操作。您必须能够使用 BPMN 流程来描述实现服务操作的方法。

需求 5:BPMN 可以定义消息和数据对象。SoaML 可以定义类、数据类型、原语类型和消息类型。SoaML 必须能够被用作一种定义 BPMN 的信息的途径,BPMN 流程中定义的任何信息都必须能够用在 SoaML 服务接口和方法中。

需求 6:一些业务实体(比如案例管理系统中的案例)可以拥有生命周期,生命周期常常由状态机建模。SoaML 必须能够用于定义这些业务实体的生命周期模型,包括它们响应的事件、结果操作,以及它们的状态如何不断改变。这些活动的业务对象必须能够用在 BPMN 流程中,流程活动必须能够向对象发送事件和理解它们所处的状态。

总之,BPMN 与 SoaML 的集成必须通过将服务架构与定义、实现或使用它们的流程分开,为服务的构造和使用提供支持。借助此集成,建模人员能够:

  • 识别来自 BPMN 流程的 SoaML 功能(或候选服务)
  • 使用 SoaML 识别、指定和实现服务
  • 使用 BPMN 定义一种方法来实现参与者所提供的 SoaML ServiceInterface 的操作
  • 使用 BPMN 流程中的 ServiceTask,可以调用由 SoaML ServiceInterface 定义并由 SoaML 中的参与者提供的服务
  • 在 BPMN 与 SoaML 之间共享信息规范(类、数据类型和消息)
  • 使用 SoaML 定义 BPMN 中可响应业务事件的数据对象的生命周期

集成方法

一种定义补充性视图的方法是采用结构和行为。SoaML 提供了建模功能,这些功能对定义协作系统的系统结构很有用。BPMN 拥有定义动态行为的更好特性。SOA 是一种以松散耦合的实体形式理解业务和技术的方式,这些实体通过服务提供和使用彼此的功能。它是理解业务和技术的一种方法。对业务部门的最高层主管而言,用于定义组织的方法和服务的流程常常不是主要驱动因素。这些流程提供的产品和服务才是重点,随后是供应链内的协作。

从另一种角度讲,业务分析师常常会描绘必要的业务流程,以便实现特定的业务战术来帮助实现规定的业务目标。他们在这些流程中使用活动来帮助识别供应链中的其他参与者和他们的角色。经过协商之后,活动可从内部编排人员转移到不同的合作伙伴和提供商,以便确定最佳的操作战略。任务可从参与者执行的某个操作转移到其他某个参与者的请求。需要的服务和服务参与者可以根据这些业务流程逐渐确定。

如果无法为其客户提供某种价值,业务就没有存在的必要,此外,如果没有完成工作流程,那么业务将无法提供任何价值。因此,BPMN 和 SoaML 可被视为同一个硬币的两面(结构和行为),而不是执行同一个任务两种竞争性方式。SoaML 通过封装参与者的结构和参与者之间的交互,提供了实体的责任及其随其他实体的需求而变化的外部视图。BPMN 提供了实体选择来完成其目标(包括提供和使用服务)的活动的设计。以行为或结构为中心的概念和视图在业务和技术层面上都很有用。

根据具体情形和涉及的利益相关者,用户可能会首选一个视图或另一个,就像有时喜欢从数据入手,而有时喜欢从流程或服务入手一样。但最终,所有这些视图都需要组装在一起:结构、流程、信息、事件和服务。我们面临的挑战在于找到使用 OMG 标准、关联的方法和工具的途径,让建模人员可以使用最佳的符号和语义来建模其问题领域和解决方案的不同方面。您可以使用这些标准的、对您有利的互补性功能,无需在这些标准中进行选择。

选择集成方法的指导原则

以下指导原则可帮助您开发一种集成方法:

  • 识别 BPMN 或 SoaML 规范中的任何问题:
    • 提高规范的质量。
    • 加深对规范的理解。
    • 简化集成,无论采用何种实现方式。
  • 最小化规范与其支持性元模型之间不合意的耦合。
  • 确保规范能继续保持独立并单独使用,以及一起使用。
  • 最小化供应商和用户的实现成本。
  • 专注于互补性建模功能,而不是类似和重叠的功能。
  • 识别满足需求的概念和主题,而不去关注 BPMN 或 SoaML 细节:
    • 相互协作的服务使用者和提供者的结构和行为是什么?
    • 提供了哪些服务,谁是这些服务的使用者?
    • 这些服务是如何实现和使用的?
  • 使用具体的示例来探索异同。
  • 利用每种规范的优势,避免其中的不足。
  • 偏爱标准中的元素之间具有丰富语义的链接,而不是它们之间的信息转换和交换。
  • 确保对信息交换的支持。

集成必须避免在规范之间引入不合意的耦合,确保各个功能可根据需要单独或一起使用。

因为 BPMN 和 SoaML 是不同团队独立开发的(存在一定的重叠),而且因为两种标准现在都使用了规范,所以每种标准在开发时都没有设计集成功能。尽管 OMG 规范生命周期流程鼓励在规范之间进行集成,但提交团队通常被具体的 RFP 需求、有限的资源和紧张的日程所驱动。这些因素可能导致团队专注于具体 RFP 需求上的规范开发活动,有时会以牺牲与其他标准的集成为代价。

结果,BPMN 和 SoaML 集成必须在规范完成并得到批准后解决。可以通过修订流程或新 RFP 实现标准规范的有效集成,但这么做往往不切实际。工具供应商和用户已在可能限制未来灵活性的支持性产品和模型上投入了资源。这种情形留下了 3 种剩余的集成方法供用户选择。

集成方法 1:集成

此方法假设没有必要集成 BPMN 与 SoaML。每种规范已受多个工具支持,可用于解决问题。尽管集成提供了一些潜在价值,但没有这些额外价值,也可以使用每种规范有效地解决问题。此方法假设规范和工具是独立的,并存在特意的重叠部分。此方法不会尝试使用规范的互补性功能,但可以通过记录每种规范的最佳实践在一定程度上解决重叠问题。

集成方法 2:模型交换

在典型的模型或信息交换中,转换可将用户模型从一种形式转换为另一种形式。这种转换使信息可在一种工具中使用并在另一种中创建。建模人员可以使用两种规范的功能和它们的支持性工具,但不能一起使用它们。此方法对现有标准和工具的影响极小,因此入门门槛较低。请考虑此方法的以下影响:

  • 必须通过每种规范和含义,以及有关如何通过转换保留该含义的协议,充分地传达规范之间的映射关系。
  • 来源规范可支持目标中未涵盖的内容和语义。在这种情况下,会丢失额外的内容,或者必须使用结构化的备注、注释或其他扩展机制,通过一种精明的方法来管理这些内容。
  • 模型到模型的转换会产生相同模型信息的不同副本。在尝试保持相同信息的多个不同格式副本同步时,这种信息冗余性可能显著增加生命周期管理和协调问题。
  • 因为针对不同的用途,所以可能存在不同的映射,所以可能难以标准化交换的完成方式。这种标准化很重要,因为它使得兼容的工具可由多个供应商可靠地实现。
  • 对供应商和最终用户而言,开发、维护和使用转换的成本可能很高。

要最大程度地减少这些问题的影响,可以采用一些方法或最佳实践来减少对工具间交换的衍生工件进行编辑的需求。例如,BPMN 可用于指定业务的高级计算独立模型 (computation independent model, CIM)。然后,可以使用模型到模型的转换,在 SoaML 中创建一个初始的平台独立模型 (platform independent model, PIM),以便使用它为后续的特定于平台的模型 (PSM) 和代码生成来精心制作 SOA 模型。此方法对不同角色使用了不同的符号和工具,以便利用整个项目生命周期的每个不同方面的优势。此方法的细节不属于本文的讨论范围,但模型到模型的映射可能很有用。

模型交换方法专注于规范和工具之间的重叠,以及执行相同任务的不同方式,而不是利用每种规范所提供的互补性功能。而且它不适应结合使用这些功能。因此需要使用第三种集成方法。

集成方法 3:元模型集成

此方法提供了最佳的集成,但具有更高的开发成本。无需修改 BPMN 或 SoaML 规范,就可以创建一种新的、桥接式的元模型来扩展和链接这些规范。举例而言,这种桥接式元模型可以使用 UML 2 包合并、MOF 元模型、UML 配置文件或生命周期协作开放服务 (OSLC) 规范来创建。然后,可以扩展 BPMN 或 SoaML 的支持性工具为桥接式元模型提供支持,或者可以创建一个独立的工具为两种规范和集成提供支持。

集成可通过 BPMN 与 SoaML 之间的模型交换、元模型级别上的集成,或者通过桥接式元模型来实现。所有这些方法都是可行的,但模型交换倾向于关注 BPMN 与 SoaML 之间的重叠,在重叠部分,它们是同一个事物的不同表示和元模型。元模型集成更加专注于它们如何结合使用和彼此互补,以及它们如何提供更高的价值主张。每种建模语言都可得到最佳地使用,而且信息可在它们之间链接和共享。例如,元模型集成使得供应商能够创建工具,以标准方式结合使用 BPMN 和 SoaML。模型桥接类似于元模型集成,但使用一个独立的中介和桥接式元模型来完成,这会减少 BPMN 与 SoaML 之间的耦合。此方法使它们也可分开开发和使用。

结束语

BPMN 和 SoaML 是 OMG 采用的两项最新标准。尽管这些标准之间存在明显的重叠,但每种标准都有特定的关注点。BPMN 专注于流程模型,从业务流程中的活动的简单编排入手,可以通过扩展来支持流程之间的协作,然后通过再次扩展来支持流程之间的交互的筹划。SoaML 专注于服务架构,以及使用服务合约封装服务架构中的参与者之间的交互,以建模服务水平协议 (SLA)。

本文是一个由 3 部分组成的文章系列的第一部分,本系列将探讨如何在相同或相关的项目上(单独或结合)使用这两种建模语言。文中介绍了利用每种标准的优势和避免冗余的需求和方法。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=984283
ArticleTitle=集成 BPMN 与 SoaML,第 1 部分
publish-date=09262014