使用面向服务体系架构建模语言（SoaML）建模，第 1 部分: 服务识别

如何通过建模改进 SOA

面向服务体系架构（SOA）的强大之处，在于它能支持业务集成和再使用过程中的业务能力。SOA通过两种方式来达到这个目的：通过鼓励围绕可再用服务组织的方案，这些可再用服务集成了与它们的执行相隔离的功能性性能；通过为管理功能性性能之间的耦合提供必要的手段。建模可以用于消除业务需求与部署的基于服务的方案之间的鸿沟。SoaML 模型提高了抽象的层次以允许你关注于业务服务。在支持业务能力的同时，使用能够满足业务功能性和非功能性目标的 RESTful Web 服务，模型驱动的开发方法可以为 Java™Platform、Enterprise Edition（JEE）、IBM® CICS® 或者 Web-OrientedArchitectures（WOA），用于生成设计的执行方案。

术语面向服务体系架构（SOA）拥有一些内在的涵义。实践者一般使用SOA 来定义一个结构性的形式，和描述一个普通的IT 基础，该基础能够支持使用结构性形式构建的 IT 结构。这些都是非常有用的关注于技术的视角，但是，它们自身并不是足够的。

为了实现它的潜力，一个基于 SOA 的 IT 基础（以后都简化称为 SOA）需要是与业务相关的，因此由业务驱动和执行以支持业务。我们需要有一种方式去设计 SOA 方案，这些方案与它们满足的业务需要相联系。如果业务需求是作为需求项的简单列表给出，而且 SOA 的抽象层次是在描述一系列 Web 服务的一些 XML 文件中获取的话，那么就很难实现上述这种构想。

我们所需要的是规划化业务需求，并提高抽象的层次，这样 SOA 就可以更加紧密地收集业务服务，以及这些服务是怎样满足业务目的和目标的。这就可以讲部署的方案与它预定的商业价值联系在了一起。同时，我们需要一种方法，去将商业上的关注点与发展支持它们的 SOA 平台隔离开来。

建模和模型驱动的开发（MDD）可以帮助实现这些目标。模型允许我们从执行的具体过程中抽象出来，并关注于驱动业务和结构性决定的问题。在一定的程度，我们将要描述的方法，对业务和方案开发应用了一种基本性的原则：关注点的隔离和耦合的解离。在这里，我们可以清晰地将任务和业务分析员的责任与那些 IT 员工隔离起来。

对于一个业务难题创建敏捷、及时和可再用的 IT 方案可以是非常困难的。它需要对结构的关注，这种结构隔离了关注，并降低了部件之间的耦合，特别是在方案构件是由不同组织所有时更是这样。能够快速响应不断更改的充满革命性集成业务方案，实现起来是更加困难的。集成和交互性需要不同的公司在不同的时间开发的构件的标准，最终集成到一个整体的构件之中。SoaML（面向服务体系架构建模语言）是一种对象管理组（OMG），它用于消除这个隔阂，并帮助实现 SOA 的潜力。SoaML 是对 UML 的小型扩展，以支持 SOA 建模。它提供了 SOA 的抽象，以关注描述参与者的需要和功能，并将他们联系在服务价值链中。

SoaML 提供了一些便利之处。

• 支持模型层次上的交互性与集成性

• 提供了隔离于平台多样性及低层次 Web 服务 XML 文件标准之外的高层次抽象性

• 通过使用结构作为业务需求与自动化 IT 方案之间的桥梁，来处理业务集成与服务交流的关注点

• 通过模型驱动的结构（MDA）来支持已存在平台之上或者之间的 SOA

• 支持灵活的平台选择

• 解去方案结构平台执行的耦合，以阻止已存在的方案对平台发展造出不良影响

• 为末端到末端生命周期开发与管理平衡和集成已存在的 OMG 标准

 

这一关于 SOA 建模的系列文章

本系列的文章向你展示了怎样使用通过基于 OMG SoaML 描述文件（Profile）扩展的 UML 模型，来设计一个与业务需求相关联，但同时独立于方案具体技术实现的SOA 解决方案。按照一个具体的典型的和完整的例子来理解概念，要更加容易一点。而这正是我们在这里采取的方法。我们不会花很多时间去处理 SoaML 细节问题，而是关注怎样使用 SoaML 以帮助你进行设计和开发。

尽管本系列的文章是关于来自 SoaML 模型的 Web 服务方案，但是我们仍然从关注想要完成的业务目标与目的开始。然后我们会探讨一个业务过程，在这个过程中我们需要做什么业务以达到这些目标和目的。这就提供了方案需要满足的业务功能性需求。然后我们使用该业务过程来识别需要的业务功能，这些功能可以作为设计方案中能够满足业务需求的服务实现。

在本系列文章接下来的部分中，我们将会创建能够满足这些需求的服务规格和执行，能够满足的需求支持未来的重复使用和业务敏捷性。最终，我们讲会使用 MDD 来生成一个可以被部署和执行的 Web 服务。

为了让例子变得更加真实，我们将会使用已经存在的 IBM® Rational® 工具，来构建方案工件，并将它们联系在一起，这样我们就可以确认需求之下的方案，并且更加有效地管理变更了。另外，我们通过向 IBM® Rational® Software Architect 中的UML 模型添加 OMG SoaML Profile，从而为服务建模扩展了统一建模语言（UML）。表 1 提供了总体进程的概述，我们将会在开发例子的过程中使用这些进程，同时提供的还有用于构建工件的工具。

表 1. 开发过程角色、任务和工具

本系列的文章关注于怎样获取业务需求，构建能够满足这些需求的服务模型，创建和部署能够实现这些设计的方案。我们还能够强调显示支持性工具，以演示表 1 中列出 IBM 工具当前所提供的服务建模功能。这些文章并不十分关注于所有的方法或者发现需求的技术、分析和评价服务方案的方法，或者将服务分割成不同的结构性层。如果你想得到关于这些重要问题的更多信息，你可以查看“面向 SOMA 的 IBM® 统一过程”[Rational UnifiedProcess® for SOMA，RUP® for SOMA]。这些 IBM® Rational® MethodComposer 插件提供了开发过程，指南、工具指导，以及介绍使用工具开发完整服务模型及方案的文章。

 

Purchase Order Process 范例

本例基于 BPEL 1.1 规格中来自 OMG SoaML 标准的 Purchase Order Process 范例。BPEL 1.1 只含有一个部分性的方案，因为相关集合并没有得到定义，而业务数据也不是完整的，而且也没有错误的处理方案和赔偿措施。范例的这个版本包含了特定意义上完整性的—一些组合数据，以及相关性所需要的数据。

例子的开始，是使用 IBM Rational Requirements Composer 来描述将要达到的业务目的和目标的动机。接下来是一个使用 Rational Requirements Composer 获取的高层次业务过程，它粗略的描述了达到目的和目标所需要的业务组织性和操作性需求。这些动机和过程模型为识别与业务需求相联系的服务创建了一个背景。

在我们理解业务需求之后，我们就可以继续满足这些需求的服务的开发过程。SOA 方案中的第一步就是识别服务。为了完成这一步，我们将会把业务过程当作一个 Service Requirements 契约。然后服务规格和服务提供商会以一种统一的方式设计和联系在一起，这种方式就是在处理软件结构性关注的同时满足业务需求。

从业务模型识别候选服务的过程也可以看做域分解。IBM Rational Unified Process (RUP) for SOMA 描述了域分解和一些其他的方法，该方法用于集中保证，识别业务所需要的所有功能和服务。

业务需求

通常来说，业务分析员会非常关注所需的组织性和操作性需求，以满足将要满足的商业目标和目的。而他们常常不太关注 IT 问题，例如再利用、内聚度和耦合性、分布、安全性、持久性、数据完整性、并发性及故障恢复能力能力。而且，业务流程建模工具通常拥有需要的功能以处理人们关注的地方，如果这些工具存在的话，它们可能还不是业务分析员手下的有效工具。在本段中，我们使用业务流程模型的草图，以识别需要的业务功能以满足一些业务目标。

场景：一个集团的公司已经决定进行合作，以为处理购买订单产生一个可再用的服务。该项目拥有一些目标：

• 创建处理购买订单的普通手段

• 确保订单得到及时的处理并交付了需求的货物

• 帮助降低库存的积压情况和清单维护成本

• 最小化产品与运输成本

图 1 显示了 Rational RequirementsComposer 中获得的需求：注意要使 Process Purchase Order 业务用例能够满足所有的业务目标。

图 1. Rational RequirementsComposer 中显示的业务需求

我们还会创建定量化“及时处理订单”目标的特定目标（或者关键性能指标）（见于图 2）。

图 2. 目的定量目标

该目的就是我们想要在实现业务用例的业务流程中观察到，它将会成为我们 SOA 方案的一个限制性因素，而且将会在我们部署的Web 服务中观察到。这就使得服务得到更好的监视和管理，以确保业务目的和目标确实达到了。

业务组织性过程

来自成员团队的业务分析员分析了需求，并决定接下来的 Rational Requirements Composer 中的BPMN 业务流程满足了业务目的，以及业务操作性限制因素。该进程已经足够完整和详细，足以用作团队之间规范服务契约的基础。因此，我们能够满足这些业务需求的 SOA 方案，应该坚定地坚持这些业务需求（图3）。

图 3. Purchase Order Process 业务过程模型

Purchase Order Process 启动了三个并发的活动：一个是管理产品和传递日程安排，另一个是价值估计和结账，第三个是传递和订购产品。这个过程从基于订购产品来启动一个价值估计活动。但是，这种价值现在并不是完整的，因为全部的价值取决于产品是在哪里生产的以及传递过程中的成本。同时，产品的订单会发出，以决定产品发出的位置和时间。同时，过程请求会得到传递，然后等待传递的日程安排从产品安排提供商那里发出。在得到产品日程安排之后，账目就可以完成，并返回至客户手中。我们还会将 Purchase Order Process 与 Purchase Order Process 业务用例联系起来，以指示过程实现了用例（图 4）。所谓的实现是用例建模中的一个规范化术语，它指示了规格与各种执行之间的关系。

图 4. 将执行的业务用例与业务流程联系起来

你可以使用这种联系，以在业务流程和它所实现的业务用例之间进行切换。

接下来的章节将业务流程当作业务需求的规格，并显示了满足业务操作性需求所需要的功能和服务。

服务项目组织

现在我们已经做好准备，去创建一个模型以满足这些需求。我们的方案通过识别功能，将合适的功能当作服务，然后定义为服务交流的结构来满足这些需求。当我们在设计方案时，我们需要指定服务，设计接口，并决定如何将它们执行（由哪一个提供商提供服务，提供什么服务，怎样提供）。这就创建了服务参与者之间的附属关系，并创建了系统中的耦合关系。管理这种耦合是设计基于 SOA 服务的主要部分。通过将业务需求与服务隔离开来，我们就有了充分的灵活性去设计 SOA，以满足业务与 IT 系统的需求。这就使得业务需求会一直限制 SOA 方案，这可能会导致再使用性变差，业务灵活性也降低。

首先，我们会创建一个称为 PurchaseOrderProcess的 Rational Software Architect 的服务建模项目。该项目包含了一个称为 PurchaseOrderProcess的服务项目。该模型由服务、服务数据、提供的及需求的接口的规格以及提供需要的服务的构件的信息组成。但是，现在，我们会主要关注于服务的识别。

如图5 所示，在 urchaseOrderProcess 模型中有五个主要的包：

• org::ordermanagement包含了与订单管理相关的元素。

• org::crm包含了一些客户关系管理标准的数据模型与普通接口、服务消费者和服务提供商就该管理标准达成共识，以开发共同服务。

• com::acme::credit包含了与结账与信用管理相关的元素。

• com::acme::productions包含了与产品与日程安排相关的元素。

• com::acme::shipping包含了与传递相关的元素。

这些包将问题域分割成不太的功能性区域。这有助于管理复杂性，创建需要的名字区域，促进重复利用，并对不太的包保持不太的关注程度（见于图7）。

图 5. 包附件图

该组织可以叫做服务模型的控制性组织。可以使用视角包来记录组织相同模型元素的其他方式，例如使用 SOMA 方法。

服务识别

有一些业务过程可以直接在诸如 IBM® WebSphere® Process Server 之类的平台上运行。但是还有一些情况，业务过程不能有效地处理 IT 问题，并且有可能得到重组以处理非功能的需求，例如性能、可评价性以及安全性。在这种情况下，业务过程可能会被当作一个 IT 方案必须指定的需求。

依据功能识别候选服务

我们从识别处理购买单中的功能中开始服务模型。此时，我们并不关注服务具体是做什么的，以及服务之间是如何交流的。我们只想创建一个草图，以表明需要的功能，以及它们之间可能的交流方式，以识别任意附加的功能。

这些功能是如何被识别的具体细节，已经超出了本文的讨论范围。IBM RUP for SOMA为怎样从商业动机和战略、业务功能性区域及已存在的资源来识别需要的功能，提供了一个过程、方法以及指南。IBM SOMA 总共描述了三种技术：

• 目标服务建模，它识别了需要的功能，以实现诸如战略和目标之类的业务需求；

• 域分解，它使用业务流程中的活动和业务功能中的其他描述，来识别需要的功能；

• 已存在的资源分析，它负责从已存在的程序中分析功能。

通过使用目标服务建模与域分解技术，我们就可以识别需要的功能，来处理购买订单。接下来的图 6 是 Rational SoftwareArchitect 中的一个简单的类图，它显示了识别的功能。关于功能给出的唯一信息就是它的名字。通过检查业务流程，并找出识别进程中每一个通道操作的任务。

图表中的使用附件显示了这些功能相互之间是如何联系的。在这里，我们并不知道有哪些功能可能作为服务处理，我们并没有完整的规格描述，也不知道服务参与者将会提供什么或者需要什么服务。而且我们还没有对这些服务的执行建模。因此，这些使用附件指示功能之间预期关系的一个简单指示符，当我们完成规格的服务和执行的时候，这些功能可能是真的，也可能是假的。但是，这些附件在高层次上都是有价值的，因为它们开始识别需要细心管理的系统之间的使用和耦合。

图 6. 服务功能

我们已经有了从 Rational Requirements Composer 业务需求和过程获得PurchaseOrder Process 的功能。服务认证由哪些功能变成服务的决定组成。IBMSOMA 方法提供了一个 Service Litmus Test，可以应用该功能以决定哪一个功能作为服务。在本文中我们并没有讨论这一点，但是你可以查看 RUP for SOMA 以得到更多的信息。

Service Litmus Test 将会检查每一项功能，并应用不太可配置的工具，以决定其中的哪一项功能应该被当作服务。图 7 显示了被识别成功能的服务。例如，InvoicingService 服务接口将会揭示出 Invoicing 功能。这意味着所有提供该项服务的参与者都将提供该项功能，而所有请求该功能的参与者都可以使用它。

图 7. 识别成处理购买订单的服务

服务架构

SoaML 提供了一些方法来识别服务。来自业务过程的需求可以被当作一个服务架构，因此指示业务过程中的参与者，指定他们之间如何交流的契约，以及服务和请求的安排。

一个服务架构是业务需求的一种规划化规格，它是通过相互之间交流的参与者得以执行的，而不需处理 IT 结构性或者执行性方面的关注。在这种情况下，服务架构包含了与原始业务过程相似的信息，并且可以当作如何实现业务过程的规格来处理。

图 8 显示了 IBM® Rational® SoftwareModeler 中处理购买订单的服务架构。图 8 中引用的 ServiceContracts 具体内容，在本文中并没有有所涉及，但是在本系列后续的文章中会详细介绍。现在，这些 ServiceContracts 简单地指示了服务架构中扮演指示性角色的参与者之间达成的协议。

图 8. 处理购买订单的服务架构

它有助于花些时间理解这些图表，因为我们将会看到与开发的 SoaML 方案相似的图表。

«ServicesArchitecture»Manufacturer Architecture 响应 Process Purchase Order 业务过程。

注意：

服务架构是使用标识符（一个分隔的矩形）显示的，而不是通常所用的 UML 协作省略号。UML 2 支持两种形式。该例使用矩形符号，因为对于角色它拥有更多的空间。

至于建模服务需求或者来自业务过程的服务需求，一个服务架构会回答这些问题：

• 需求想要达到什么样的目的？这就是与业务需求相对应的服务架构名。这些名字通常是动词形式，以指示协作角色想要完成的目的。

• 谁将会参与进来？服务架构角色指定了交流以获取想要得到结果的参与者。

• 角色要对什么负责？角色的类型代表了服务的参与者。参与者的责任是通过联系他们的服务契约所指定的。我们的服务方案扮演了一种必须执行这些责任的角色。这就是说，它们必须执行服务契约指定的操作。

• 什么角色将会进行交流？这就是说，哪些角色将会与其他的角色相交流？于是就在角色之间创建了一个附属。这种交流是通过定义参与者之间交流的服务契约引用的。

• 角色之间相互交流的规则是什么？这就是服务架构所有的行为。这种行为可以是一个活动，一个交流，一个声明机或者不透明的行为（例如，代码）。当角色的服务得到请求时，这种行为可能会发生，并指示他们之间交流的信息。

• 我们怎样评价是否满足了需求？一个服务架构可以拥有一些限制因素，该因素指定了对于满足需求必须为真的状况。

Purchase Order Process 是一个带有四个角色的服务架构，包括进程自身。通过检查分配给业务流程通道中角色的任务，可以从业务流程中得到这些角色。Rational Requirements Composer 使用业务需求的Business Process Modeling Notation（BPMN）进程中心视图；这使得消除进程需求与服务型方案的结构之间的鸿沟变得更加容易。服务架构还可以设计成实现从业务需求与进程中识别的功能。实际上，一个服务架构实际上可能是 BPMN 业务流程的不同视图。

服务架构可以来自于业务目标的限制因素。这些限制因素指示了服务架构需要达到什么样的效果，以及怎样评价成功的程度。

服务架构还可以实现用例，该用例获取了从关键性外部涉众的视角来看，关于高层次功能性及非功能性需求的信息。可以在 Rational Requirements Composer 或者Rational Software Architect 中查看这些用例。在这个过程中会一直保持服务需求契约、业务流程、业务用例及业务目标和目的之间的联系。

你是否使用业务功能或者服务架构，或者两者同时使用，以识别候选的服务取决于你个人的偏好。业务功能建模是一种比较直接的方法，将一项业务分解成识别业务功能及操作的部件，以及满足业务目标所需要的功能。服务架构建模提供了一种更加规范的方法，以指定管理人们之间交流的参与者与契约。两种方法可以同时使用。你可以选择一种你觉得舒服的方法来使用。

 

接下来的内容

在本文中，我们概括了一种技术以识别满足业务需求所需的功能。开始时我们会获取业务目标与目的，然后为业务操作及满足目标和目的所需的过程建模。随后我们使用业务流程来识别所需的功能。这就提供了一种规范化的方式，来识别与业务相关的功能，该功能与将要完成的业务目标与目的相关联。

接下来本系列文章的第二篇，“服务规范”检查了功能，并确定其中哪些功能应该曝露为服务。随后我们将会深入讨论如何精化服务接口问题。这些接口将指示已提供的和所需要的接口、服务消费者与提供商参与者在服务接口中所扮演的角色，以及使用这些服务操作的规则或者协议。