如何通过建模改进 SOA

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

角色	任务	工具
业务执行	表达业务目标与目的	IBM® Rational® Requirements Composer
业务分析员	分析业务需求	IBM Rational Requirements Composer
软件结构师	设计方案的结构	IBM® Rational® Software Architect
Web 服务开发员	执行方案	IBM® Rational® Application Developer

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

我们还会创建定量化“及时处理订单”目标的特定目标（或者关键性能指标）（见于图 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 包含了与传递相关的元素。

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

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

服务识别

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

依据功能识别候选服务

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

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

• 目标服务建模，它识别了需要的功能，以实现诸如战略和目标之类的业务需求；
• 域分解，它使用业务流程中的活动和业务功能中的其他描述，来识别需要的功能；
• 已存在的资源分析，它负责从已存在的程序中分析功能。

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

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

图 6. 服务功能

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

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

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

服务架构

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

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

图 8 显示了 IBM? Rational? Software Modeler 中处理购买订单的服务架构。图 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 中查看这些用例。在这个过程中会一直保持服务需求契约、业务流程、业务用例及业务目标和目的之间的联系。

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