使用面向服务体系架构建模语言（SoaML）建模，第 2 部分: 服务规范

2010-04-29 作者：Jim Amsden 来源：IBM

服务规范的概述

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

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

服务的名字，就暗含了它存在的目的。
提供的和需要的节目，因此定义了服务所提供的以及用户所需要的功能性性能。
注意：这不仅仅包括服务是怎样执行的，还有该项服务消费者与提供商之间的交流。
指定功能性性能如何使用或者以何种顺序使用规则的协议。
反映服务的成功使用将要完成的目标以及它们将要得到的评价的限制因素。
服务消费者预期的与提供商预期提供的质量情况，例如成本、实用性、性能、印记、对任务的适用性、竞争信息以及等等之类的信息。
使用服务的政策，例如维护安全性及整体性的安全和交易范围，或者从瘫痪状态回复到成功执行服务或者所有需要的服务。

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

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

角色任务工具

业务执行表达业务目标与目的 IBM® Rational® Requirements Composer

业务分析员分析业务需求去 IBM Rational Requirements Composer

软件结构师设计方案的结构 IBM® Rational® Software Architect

Web 服务开发员执行方案 IBM® Rational® 程序开发员

服务识别评审

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

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

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

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

服务规范的类型

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

服务的名字，指示了它是关于什么的或者它是干什么的。
提供的和需要的接口，描述了服务的功能性性能。每一项功能性性能包括：
- 它的名字，它通常是指示它是干什么的动词形态
- 所有需要的或者可选的服务数据输入以及输出
- 消费者在使用功能之前预期满足的所有前状况
- 任意消费者可以预期的任意后状况以及必须能够成功使用功能的提供商
- 如果功能出于某种原因不能提供，那么例外情况或者错误的状况也可能会产生，就算预状况得到满足也是这样
任意的交流协议或者规则，决定什么时候可以使用功能，以及以何种顺序来使用它们。
消费者预期提供能够使用或者与服务相交流的任意功能。
在提供服务时执行必须满足的需求。
反映服务的成功使用将要完成的目标以及它们将要得到的评价的限制因素。
服务消费者预期的与提供商预期提供的质量情况，例如成本、实用性、性能、印记、对任务的适用性、竞争信息以及等等之类的信息。
使用服务的政策，例如维护安全性及整体性的安全和交易范围，或者从瘫痪状态回复到成功执行服务或者所有需要的服务。

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

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

日常安排服务

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

图 2. 日程安排服务接口

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

传递服务

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

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

服务接口会告诉您关于一项服务您所需要了解的所有事情。这包括您必须满足的需求以使用服务（有时叫做 Use 或者 Usage contract 。这与获取业务需要所需的信息是同一种类的，除了项目区域与具体内容的层次是不同的之外。这在意料之中，因为您为用户与提供商怎样就服务进行交流，在服务接口中定义了规范。

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

图 3. 定位服务接口

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。协议的细节信息表现在类的 UML ownedBehavior（使用圆圈加号标示的图案表示），它用于指定使用该种服务的有效交流模式。在这种情况下，协议是使用 UML 活动来进行表达的 。
                        
协议指示了一个定序者必须在得到完整的价值估算之前，就已经开始初步的价值估算操作了。然后定序者必须会回应一条请求（在这里是一次回叫）做好准备，以处理最终的账目。有一些请求结账服务的消费者可以做一些比这更多的事情，但是这些特定操作的顺序由协议所限制。注意 InvoicingService 活动中的 UML ActivityPartitions 代表了调用属于代表分区的角色（操作的目标输入插脚是活动分区代表的操作） 。
                        在这种情况下，在定序者和结账服务之间只有一种交流，这样服务规范类就只会有一种 ownedBehavor 了。在另外一种情况中，用户和提供商之间可能有不止一种交流，他们使用不太的交流协议。服务规范可能会有一个 ownedBehavior，以指定每一种会话的交流模式。

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

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

                        
                        
就像日程服务接口一样，购买是一种简单的接口，它只是为消费者处理购买单提供了一种功能，这些消费者正在返回一个完整的账目。作为一个边界效应，购买单项目得到了购买（如果需要的话）并传递给客户。
                        
                        
这种服务接口代表了在初始的 Process Purchase Order 业务过程中指定的功能性性能。它代表了识别的服务，并从业务过程中进行设计。
                        服务数据模型
                         package org::crm 中定义的客户关系管理（CRM）数据模型定义了服务接口中所有服务操作使用的数据。CRM 包代表了客户关系管理服务数据模型的设计，该模型在一系列的服务中可以得到重复使用，以及不太组织提供的服务。这些服务数据是如何被发现的、怎样得到规范化的，以及怎样与永久性的实体或者物理性数据源相联系的，已经超出了本文的讨论范围。我们在这里所讨论的，是服务数据的样式以及模型获取的方式。
                        
                          图 6.  CRM 服务数据模型
                         
                        
                        
图 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 形式的服务数据
                        

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