第 1 部分: 服务识别

本文是五篇系列文章中的第一篇，本系列介绍关于如何基于面向服务体系架构（SOA）进行开发软件。本文介绍了怎样使用通过基于 OMG SoaML 标准扩展的 UML 模型，以设计一个与业务需求相关联，但同时独立于方案具体技术实现的 SOA 解决方案。作者描述了业务目标与目的，以及可以实现满足这些目标的业务过程，并解释了怎样使用这个过程来识别满足相应需求所必需的业务相关服务。

如何通过建模改进 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. 开发过程角色、任务和工具

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

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 Requirements Composer 中获得的需求：注意要使 Process Purchase Order 业务用例能够满足所有的业务目标。

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

Artifacts 项视图

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

图 2. 目的定量目标

及时订单处理需求描述接口

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

业务组织性过程

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

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

Purchase Order Process 的 BPMN 图表

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. 包附件图

UML 包附件的图表

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

服务识别

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

依据功能识别候选服务

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

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

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 中查看这些用例。在这个过程中会一直保持服务需求契约、业务流程、业务用例及业务目标和目的之间的联系。

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

接下来的内容

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

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

在本系列五篇文章中的第二篇，我们将会通过详细对每一项服务建模，来继续定义 SOA 解决方案。这些规范将会定义服务消费者与提供者之间的服务接口。这些服务接口包括了被提供的和所需要的接口、这些接口在服务规范中所扮演的角色，以及这些角色之间如何交流的规则或协议。

第 2 部分: 服务规范

在本系列五篇文章中的第二篇，我们将会通过详细对每一项服务建模，来继续定义 SOA 解决方案。这些规范将会定义服务消费者与提供者之间的服务接口。这些服务接口包括了被提供的和所需要的接口、这些接口在服务规范中所扮演的角色，以及这些角色之间如何交流的规则或协议。

本文的写作背景

“SOA 建模”系列文章的第一篇，“SOA 建模，第 1 部分：服务识别”中概括了一种方法以识别链接到业务需求的服务的方法。我们通过达到实现业务任务目的及目标来开始。接下来，我们对满足目的和目标所需的业务操作和过程建模。然后我们使用业务需求与过程，来识别需要的功能和它们之间的关系。它为识别与业务相关的功能提供了一个规范化的结构，这些功能与他们想要实现的业务目的与目标联系在一起 。

在本系列前面的第一篇，“第 1 部分：服务识别”中，我们也曾经查看过怎样识别与业务相关的服务，来最大化面向服务体系架构（SOA）方案的潜力。我们通过将它们当做候选的服务对待，来检查每一种功能。通过服务界限测试的功能，用于识别需要的服务接口。这就将服务接口与业务需要联系到了一起。

在第二篇文章中，我们通过对每一项服务的规范详细地建模，来继续定义 SOA 方案。这些规范会定义服务消费者与提供商之间的接口。这些协议包括了提供的和需要的接口，这些接口在服务规范中所扮演的角色，以及这些角色之间如何交流的规则或者协议。

服务规范的概述

我们现在就可以开始对服务接口的具体内容建模了。服务接口必须指定服务的潜在消费者需要知道的每一件事情，以决定他们是否对使用服务感兴趣，以及怎样使用这些服务了如指掌。它还必须指定服务提供商所须知道的每一件事情，以成功地执行服务。在 SOA 的核心地区，是服务价值链的构造，该价值链将用户需要与配套的提供商功能联系起来。服务接口定义了用户参与者的目标、需要以及期望，以及提供商参与者的价值预期、功能与承诺。因此，它们提供了需要的信息，以决定配套的需要与功能。

理想条件 下，这些信息会集中到一个地方提供。这就使得搜索可再用服务的资源储存库变得更加容易，并得到所有需要的信息，而不用导航许多不同文件或者搜索相关的元素。服务接口至少包括了以下这些信息：

服务的名字，就暗含了它存在的目的。

提供的和需要的节目，因此定义了服务所提供的以及用户所需要的功能性性能。

注意：这不仅仅包括服务是怎样执行的，还有该项服务消费者与提供商之间的交流。

指定功能性性能如何使用或者以何种顺序使用规则的协议。

反映服务的成功使用将要完成的目标以及它们将要得到的评价的限制因素。

服务消费者预期的与提供商预期提供的质量情况，例如成本、实用性、性能、印记、对任务的适用性、竞争信息以及等等之类的信息。

使用服务的政策，例如维护安全性及整体性的安全和交易范围，或者从瘫痪状态回复到成功执行服务或者所有需要的服务。

在本系列所有的文章之中，我们将会使用已存在的 IBM? Rational? 工具，以构建方案工件，并将它们联系到一起，这样我们就可以确认需求之下的方案，并更有效地管理变更。另外，我们通过向 IBM? Rational? Software Architect 中的 UML 模型添加面向对象管理组（OMB）服务的结构建模语言（SoaML），来扩展了统一建模语言（UML）的使用以对服务建模。表 1 提供了全体进程的概述，我们使用这些进程来开发范例以及用于构建工件的工具。

表 1. 开发进程角色、任务以及工具

服务识别评审

让我们通过评审服务接口开始，该评审接口揭示了满足业务目标与战略所需要的业务功能，我们在本系列第一篇文章中详细介绍了这些目标与战略。图 1 显示了服务接口，该服务接口揭示了处理购买订单所需的功能。

图 1. 处理购买订单的功能

显示功能的图表

文章的剩余部分解释了怎样对服务接口的具体内容进行建模。这些服务接口是图 1 中所示接口的精化。它们在概览中提供了列出的许多具体内容。

在接口完成之后，您仍然不会知道哪些服务参与者提供或者需要接口所描述的服务，以及怎样使用其他的服务来执行服务功能。这些信息会在接下来的文章中提供，那时我们将会涉及到了服务实现性的问题。

服务规范的类型

提供这些信息所需的服务接口：

服务的名字，指示了它是关于什么的或者它是干什么的。

提供的和需要的接口，描述了服务的功能性性能。每一项功能性性能包括：

它的名字，它通常是指示它是干什么的动词形态

所有需要的或者可选的服务数据输入以及输出

消费者在使用功能之前预期满足的所有前状况

任意消费者可以预期的任意后状况以及必须能够成功使用功能的提供商

如果功能出于某种原因不能提供，那么例外情况或者错误的状况也可能会产生，就算预状况得到满足也是这样

任意的交流协议或者规则，决定什么时候可以使用功能，以及以何种顺序来使用它们。

消费者预期提供能够使用或者与服务相交流的任意功能。

在提供服务时执行必须满足的需求。

反映服务的成功使用将要完成的目标以及它们将要得到的评价的限制因素。

服务消费者预期的与提供商预期提供的质量情况，例如成本、实用性、性能、印记、对任务的适用性、竞争信息以及等等之类的信息。

使用服务的政策，例如维护安全性及整体性的安全和交易范围，或者从瘫痪状态回复到成功执行服务或者所有需要的服务。

很明显的是，有大量的信息在本文中并不没有提到。需要特别指出的是，我们在这里并不关注政策或者服务的质量问题。在单独的文章中分别论述会非常地复杂。而且，对于服务的特定提供商可能有不同的地方，而特定服务自身的接口却没有什么分别。所以，我们在这里只关注基本性的需要以定义和使用一种服务。

图 1中显示了每一个服务规范的部分精华。演示的顺序是从一个非常简单没有任何协议的服务接口，到一个非常复杂涉及到多个协议，而且用户与提供商之间发生频繁交流的服务接口。

日常安排服务

图 2 中显示的日常服务接口是非常简单的。服务提供了两种操作：响应一个产品日程请求的能力，以及创建传递日程安排的能力。这些操作是通过检查服务接口的功能得以创建的。据我们所知，在这种情况下，使用这些操作没有任何协议。每一个都可以以任意一种方式使用。

图 2. 日程安排服务接口

Scheduling ServiceInterface 的类图

日程安排服务接口是在产品包中定义的简单 UML 接口。它提供了两种操作。每一种操作都可以有预状况与后状况，于是就会产生一些例外的情况。无论是服务数据（DataType 或者 MessageType）还是原始类型都需要服务操作的参数。这就确保参数没有作出“通过引用访问”或者“通过值访问”，服务数据的位置，服务用户或者提供商是操作数据的拷贝还是一些永久性的数据源等等之类的假设。所有这些都需要，以确保服务不受它可以部署到位置以与其他数据相联系的限制。服务数据会在本文接下来的服务数据模型段落中进行介绍。

传递服务

传递服务接口有一点点的复杂。想要传递产品的一个用户需要传递服务。但是，传递者需要时间去决定产品的位置，它们是否是可用的清单中或者是否需要生成，以及传递产品性价比最高的方式。因此，在传递日程安排就绪之前可能需要一点时间。在日程安排完成之前用户通常不太想要等待，因为这个等待的过程可能会使用户无法同时完成其他的工作，同时还长时间地占用系统资源。

因此，IT 结构决定使用一种简化的查询响应或者用户与提供商之间的 回叫 协议。用户请求得到传递，并且在稍后会响应来自传递者的请求以处理完成之后的日程安排。为了给这个协议进行建模，我们需要指定生产者及用户角色，他们的责任，以及交流的协议或者规则。最后一点是最重要的，因为如果传递者从来没有收到过传递请求的话，那么他就不能发一个日程安排了。

服务接口会告诉您关于一项服务您所需要了解的所有事情。这包括您必须满足的需求以使用服务（有时叫做 Use 或者 Usage contract （参见“SOA 建模，第 2 部分：服务规范”一文参考资源中所列出的 Daniels 及 Cheesman 文章），以及服务的执行者所必须满足的需求（有时也叫做 实现协议 ）。这与获取业务需要所需的信息是同一种类的，除了项目区域与具体内容的层次是不同的之外。这在意料之中，因为您为用户与提供商怎样就服务进行交流，在服务接口中定义了规范。

在这种情况下，我们使用一个抽象的类，来定义服务接口以及预期功能的操作，如图 3 所示。

图 3. 定位服务接口

ShippingService ServiceInterface 的图

ShippingService ServiceInterface 涉及到两种角色。

shipper 角色是一种提供商的角色。它对满足传递功能负责，该责任由它的类型指定。

orderer 角色对处理传递日程表负责。这是通过它的 ScheduleProcessing类型表现的。

您并不需要将这些角色设计为提供商和用户。在一个潜在条件下长期运行的会话中，有一些显著的不同点，可能会涉及到许多的团队。根据 Service 规范实现了提供的传递接口并使用所需的 ScheduleProcessing 接口，可以很容易就看到谁是用户谁是提供商。

在传递者与定序者之间有一个联系。这意味着协议涉及到了这些角色之间的一些联系。shippingService 交流由显示交流是什么的 ShippingService 类所有。

shippingService 交流指定了定序者和传递者之间的行为性或者动态性方面。它显示了定序者会首先发送一条 requestShipping 信息（或者涉及到定序者的 requestShipping 操作），然后，有时必须由传递者响应一条 processSchedule 信息。这种交流涉及到了两个生命线：一个为定序者一个为传递者。这些对象实例是 ServiceInterface 中的定序者和传递者的属性。这是一种简单的、异步请求/响应或者回馈模式，它们是众多服务协议的一个典型 。

shippingService 协议可以使用任意的 UML 2 行为来进行指定：一个行动、交流、状态机器、协议状态机器或者不透明行为（代码）。使用其中哪一个的选择取决于建模者，他们偏好的样式，或者对问题领域的适用性。

结账服务

结账功能显示了需要计算全部账目的两种操作。计算一个账目的初始价值和最终价值，涉及到了定序者和结账者之间一个稍微更加复杂的协议。更加明显地是，initiatePriceCalculation 必须在 completePriceCalculation 之前被调用。然后，定序者必须为处理结果的账目做好准备。

我们可以通过使用指定结账者和定序者角色、他们的责任以及他们之间相交流的协议（会话或者规则）的 ServiceInterface 来获取这个协议。这就像 ShippingService 规范一样，除了交流只是一种比较简单的请求-响应操作以外。服务的有效使用，在调用服务功能性性能时必须要有一个顺序。

图 4 中的 InvoicingService 服务规范获取了这个协议。注意服务接口同样执行了结账用例。一个用例可能用于代表特定服务的请求。服务接口由两个角色组成：结账者和定序者。这些角色的类型分别是 结账 实现的接口以及使用的 InvoiceProcessing 接口。这些接口蕴含了角色的责任。服务规范中的 InvoicingService 活动指定了使用服务操作的协议，在定序者和结账角色之间可以发生的实际交流。

图 4. InvoicingService 接口

InvoicingService ServiceInterface 的图

InvoicingService 是一种指定定序者和结账者之间会话、交流协议或者交流规则的 ServiceInterface。协议的细节信息表现在类的 UML ownedBehavior（使用圆圈加号标示的图案表示），它用于指定使用该种服务的有效交流模式。在这种情况下，协议是使用 UML 活动来进行表达的 。

协议指示了一个定序者必须在得到完整的价值估算之前，就已经开始初步的价值估算操作了。然后定序者必须会回应一条请求（在这里是一次回叫）做好准备，以处理最终的账目。有一些请求结账服务的消费者可以做一些比这更多的事情，但是这些特定操作的顺序由协议所限制。注意 InvoicingService 活动中的 UML ActivityPartitions 代表了调用属于代表分区的角色（操作的目标输入插脚是活动分区代表的操作） 。

在这种情况下，在定序者和结账服务之间只有一种交流，这样服务规范类就只会有一种 ownedBehavor 了。在另外一种情况中，用户和提供商之间可能有不止一种交流，他们使用不太的交流协议。服务规范可能会有一个 ownedBehavior，以指定每一种会话的交流模式。

此时您并不知道什么服务提供商执行了 InvoicingService。您也不知道将会有哪些消费者会使用它。您只是知道有些用户将会使用服务，以及提供商在执行服务时必须使用它。

购买服务

最终，处理购买顺序有一个服务接口（见于图 5）。

图 5. 购买服务接口

Purchasing ServiceInterface 的图

就像日程服务接口一样，购买是一种简单的接口，它只是为消费者处理购买单提供了一种功能，这些消费者正在返回一个完整的账目。作为一个边界效应，购买单项目得到了购买（如果需要的话）并传递给客户。

这种服务接口代表了在初始的 Process Purchase Order 业务过程中指定的功能性性能。它代表了识别的服务，并从业务过程中进行设计。

服务数据模型

package org::crm 中定义的客户关系管理（CRM）数据模型定义了服务接口中所有服务操作使用的数据。CRM 包代表了客户关系管理服务数据模型的设计，该模型在一系列的服务中可以得到重复使用，以及不太组织提供的服务。这些服务数据是如何被发现的、怎样得到规范化的，以及怎样与永久性的实体或者物理性数据源相联系的，已经超出了本文的讨论范围。我们在这里所讨论的，是服务数据的样式以及模型获取的方式。

图 6. CRM 服务数据模型

CFM 服务数据模型的类图

图 6 中所示的每一个数据类型都代表了服务数据。服务数据就是服务消费者和提供商之间的交流的数据。服务操作参数的数据类型是由 DataType、PrimitiveType 或者 MessageType 输入的。

注意：

服务数据信息与 Web 服务描述语言（WSDL）并不相同。一个服务操作可以有各种类型信息或者原始类型的输入和输出。服务操作可以设计成使用单个输入、输出以及出错信息，但是这并不是必要的，并且可能会导致意料之外的标志数据耦合。

服务数据引用了数据转移对象（DTOs），DTOs 可以在分布式环境的处理空间之间得到轻松的交流。服务消费者与提供商没有作出数据实际位置的假设，因为，他们假设实际的永久性域数据拥有一个拷贝。UML DataTypes 没有特征。它们是价值对象，其中它们的平等性基于它们内容的价值，而不是它们的特征。

服务数据代表了分布式环境中服务消费者与提供商之间交换的数据。服务提供商通常还需要访问执行设计时所需要使用的永久性数据。服务执行设计中使用的服务数据与永久性域数据之间的关系，是服务提供商与服务功能性性能执行的责任。通常来说，服务数据是域数据的选择和投影（或者视图）。尽管如此，服务数据来源的方式或者更新域数据取决于服务执行。服务数据对象（SOD）对于服务数据信息来说是一种非常有用的执行机理。它们还有管理变更集的功能，并自动应用对永久性存储库的变更。服务参与者的操作可能会使用这些功能，但是它们不需要在模型中进行处理。

数据模型使用一个 <<id>> 模板来识别所含类的属性。整个服务模型中会不断凸显一个主题，因为 Web 服务与 Web 服务的业务过程执行语言（BPEL），特别依赖于实例相关业务数据或者基于价值对象特征。

以文件为中心和 RPC 服务数据的比较

在普通的使用，包括文件中心信息、远程程序调用（RPC）以及发布订购中，有一些 SOA 交流形势图。讨论每一种形势图或者交流形式的不同特征，已经超出了本文的讨论范围。准确来说，考虑的因素有连贯性及耦合度，状态管理，分布式交易，性能，组成，同步化，开发和维护的难易程度以及最佳实践等等

SoaML 同时支持以文件为中心的信息以及 RPC 形式的服务数据。图 7 显示了与这些操作的细节相联系的 Purchasing 和 Invoicing 服务接口。Purchasing 服务接口使用文件信息样式服务数据。它的操作参数都是由 SoaML MessageTypes POMessage 和 InvoiceMessage 输入的。相反，Invoicing 服务接口使用在 图 6 中定义的数据类。

两种之间的不同在于，操作的数据是如何包裹的。对于通过 MessageTypes 输入的参数的操作，至少可以拥有 in 或者 out 参数。使用 DataType 参数的参数可以拥有多个 in，out 以及 return 参数。这就允许 SoaML 以一种满足选中结构性指导原则的基础上，对在服务消费者与提供商之间交流的数据进行建模。

图 7. 信息中心式和 RPC 形式的服务数据

文件与 RPC 形式参数的图

后续的内容

在本文中，我们对每一种服务接口的具体内容进行了建模。这些接口指示了提供的和需要的接口，这些接口在服务接口中所扮演的角色，以及这些角色交流以提供服务的规则或者协议。服务接口定义了用户请求与提供商服务之间的契约。

本系列五篇文章中接下来的一篇，“第 3 部分：服务的实现”，解释了服务实际上是如何执行的。服务执行从决定哪些参与者将会提供服务开始。该决定在服务可用性、分布、安全性、交易范围以及耦合方面拥有巨大的意义。在这些决定作出之后，我们就可以对每一种服务功能性性能是如何执行的进行建模，因此，进而对需要的服务实际上是如何使用的进行建模。然后我们将会使用 IBM Rational Software Architect 中含有的 UML 到 SOA 的转变特性，去创造一种可以在 IBM Rational Application Developer 或者 IBM WebSphere Integration Developer 中直接使用的 Web 服务方案，以执行、测试和部署完成的方案。

下篇：使用面向服务体系架构建模语言建模(下)