作者 Simon Johnston,IBM Corporation 架构设计师。
本书描述了软件服务的 UML 概要文件,它是 UML 2.0 的概要文件, 用于对服务、 SOA 和面向服务的解决方案进行建模。 此概要文件旨在提供一种通用语言,用于描述涵盖整个开发生命周期内众多活动的服务,还向不同的项目干系人提供视图。 例如,此概要文件使架构设计师能够在生命周期的早期使用逻辑分区来构建服务,以描述整个企业范围内的服务组合。 负责开发服务规范(包括结构服务规范和行为服务规范)的设计人员可以对此视图进一步细化,这些规范充当服务客户与实施者之间的合同。 消息视图使设计人员能够复用公共服务数据定义的信息模型。
此概要文件已在 Rational Software Architect 中实施,并已在开发复杂客户场景的模型和使人们理解与开发面向服务的解决方案相关的事宜时成功使用。
下图是一个模型,说明了建模服务中的重要概念。 您可以发现概念的数量比较少,并且应当对面向服务的解决方案中使用的一切都相当熟悉。 但是请注意,虽然此概要文件是此模型的实现,但是许多概念在此概要文件中不是显式构造型。 例如,并不存在操作或协议的构造型,这是因为在 UML 2.0 中具有现成的概念可供此概要文件复用,无需任何歧义或进一步的约束。
下表列出了 UML 2.0 元模型的元素,这些元素在 UML 概要文件中被用作构造型的元类。
UML 2.0 元类 | 构造型 |
---|---|
类 | 消息,服务分区,服务提供者 |
分类器 | 服务使用者 |
协作 | 服务协作 |
接口 | 服务通道 |
接口 | 服务规范 |
端口 | 服务,服务网关 |
属性 | 消息附件 |
下图(可单击)是一个 UML 2.0 概要文件图,它使用扩展表示法(实心箭头)展示了此概要文件中每个构造型及其元类的实际详细信息。您还能够看到模型中的某些约束,尤其是概要文件元素之间的那些共同约束。
以下几部分概述了 UML 2.0 概要文件的元素,因为当前已对它进行了定义。 每部分概述了一个单独的构造型;每个构造型的详细信息指定了其元类、属性以及使用此概要文件时应当应用的所有约束。
类
消息代表 WSDL 规范中所定义的概念,即用于存放对服务和服务使用者有意义的实际数据的容器。
消息中不能含有操作,只能含有属性以及与其他类的关联(假定为某些领域模型的类)。
消息构造型具有一个指示其编码格式(即 SOAP-literal
、SOAP-rpc
和 ASN.1
等)的属性。
由于两个原因,可以在工具中选用此元素。第一个原因,建模者希望将领域模型中的元素直接用作操作的参数,而不是指定消息。 第二个原因,建模者希望使用为某个操作指定一组输入输出消息的约定,在这种情况下,当在 WSDL 中生成服务描述时,建模工具必须构造一个与参数匹配的输入输出消息。
种类 | 名称 | 类型 | 描述 |
---|---|---|---|
属性 | 编码 | 字符串 | 指示在为消息生成模式时要使用的平台编码机制,例如 SOAP-RPC、Doc-Literal、ASN.1 等。
|
属性
此构造型用于指示消息的某个组成部分是其附件(而不是消息本身的一部分)。通常来说,这不可能在高级设计活动中大量使用,但是这对于将许多进程附带的数据与内嵌的消息数据相区分,则是很重要的。例如,目录服务可以将一般产品详细信息作为结构化消息的一部分来返回,而将图像作为消息的附件来返回;这也使我们能够指定图像的编码为二进制(而不是消息主体的文本编码方式)。
种类 | 名称 | 类型 | 描述 |
---|---|---|---|
属性 | 编码 | 字符串 | 指示在为消息生成模式时要使用的平台编码机制,例如 SOAP-RPC、Doc-Literal、ASN.1 等。
|
端口
此服务模型元素为服务交互(在 Web Service 术语中)提供了端点,而这些交互的定义则是服务规范的一部分。
在模型中,服务不仅能够确定已提供的接口,还能确定所需的接口(例如回调接口)。
服务还有一个属性用于指示要使用的绑定,例如 SOAP-HTTP
、SOAP-JMS
等。
无。
接口
通道代表两个服务之间的通信路径。需要注意的是:通道上可能发生交互,但是该通道不代表任何特定的交互。在 Web Service 环境中,每个服务都指定了与其关联的绑定(因此客户可以访问它)。在建模概要文件中,您既可以对服务之间的通信指示绑定,也可以对服务与服务使用者之间的通信指示绑定。通过此方法,您在了解绑定需求时就具有很大的灵活性。
种类 | 名称 | 类型 | 描述 |
---|---|---|---|
属性 | 绑定(binding) | 字符串 | 指示在 WSDL 中生成服务绑定时要使用的平台绑定机制,例如 SOAP-RPC 、SOAP-Doc 、HTTP-Get 等。
|
协作
服务协作是一种将服务之实施指定为其他服务之协作的方法。从 Web service 的角度,这对应于指定服务实施时使用 BPEL4WS。 因此,这意味着服务协作被用作服务行为,并且如果是为了生成一种语言(例如 BPEL),则它可以具有其他特定于实施的约束。
种类 | 名称 | 类型 | 描述 |
---|---|---|---|
属性 | 绑定 | 字符串 | 指示在生成作为流程编排的协作时要使用的平台绑定机制,例如“BPEL”、“WSFL”等。 |
分类器
任何分类器(类、组件...)都可以充当服务的使用者,而且包括另一个服务。当此构造型完全可选时,在将模型的元素(不是服务本身)确定为服务的客户时,它可能有用。否则它可能是一笔开销,因而可以不使用它。
无。
无。
端口
服务网关和服务类似,但是它只能用于分区,而不能用于服务提供者。网关充当代理服务,可用于对协议进行协调或指示可供分区使用的接口。 例如,尽管我们可以指示在一个分区中实施许多服务,但只有其中的一部分服务可供该分区之外使用,因此网关是专为这些服务提供的。 它不允许其他服务或分区与未通过网关显现的服务进行通信。
无。
类
分区代表系统的一些逻辑或物理边界。对于模型分区而言,它是可选的,但是很有用。例如,分区可用于代表传统多层应用程序中的 Web 层、业务层和数据层。 分区还可以用于指示更多物理边界(例如我的主数据中心、辅助站点、客户站点、合作者等),在这种情况下,出于安全性考虑,分区的交叉在允许的协议、带宽等方面可能具有特定的约束。
分区中只能含有代表内嵌部分的属性,它们应当是服务或其他分区。 请注意,这是一个约束 - 目前没有其他元素可出现在分区中。
分区还具有一个“严格”的概念,如果某个分区指示它与其他分区之间的所有通信都必须通过有类型的网关进行,则将该分区称为严格分区。
种类 | 名称 | 类型 | 描述 |
---|---|---|---|
属性 | 分类器 | 字符串 | 一个分类名称,用于指示此分区的名称空间范围。 |
类
服务提供者是提供一项或多项服务的软件元素。从建模角度,最期望看到此处是一个 UML 组件,但是此限制似乎过于苛刻,因此为了获取更大的灵活性,元类被称为“类”。服务提供者具有一个属性,该属性用于捕获与服务提供者的位置有关的信息,尽管其意义与实施相关。充当服务提供者的类不可以直接显现任何属性或操作,而只能提供公用端口(构造型为服务),而它们的类型是由服务规范确定的。
在位置属性中,特定于实施/平台的信息在生成服务端点名称时有用。
例如,在 WSDL 中,位置可以是 http://svc.myco.com/
,而服务的名称可以是 CustInfo
,在此情况下,该服务的端点名称可生成为 http://svc.myco.com/CustInfo
。
种类 | 名称 | 类型 | 描述 |
---|---|---|---|
属性 | allowedBindings | 字符串 | 指示通道在与服务连接时可使用的平台绑定机制,例如 SOAP-RPC 、SOAP-Doc 、HTTP-Get 等。 |
属性 | 位置 | 字符串 | 提供者的位置,这可供生成器创建端点名称。 |
接口
接口的用途是指示由某个服务提供的一组操作。请注意,一个服务可以实施多个接口。按照约定,可以将协议状态机或 UML 2.0 协作附加至此类规范中,以指示操作在服务规范中的调用顺序。 使用这样的行为规范,不仅可以参照实施服务的结构和行为的静态规范对任何实施服务进行验证,还可以参照其动态规范进行验证。 请注意,服务规范只能提供公用操作。
种类 | 名称 | 类型 | 描述 |
---|---|---|---|
属性 | 已发布 | 布尔 | 此属性指示服务是否假定为发布到服务存储库中;这是与 UML 提供的公用/专用属性不同的表示法。 |