服务建模非常好的实践

    UML 2 建模通过过滤掉无关的细节，有助于提高我们对于系统本质的认识。虽然如此，建模并不是一剂包治百病的良方，有意义的模型图表仍然需要专门的技术来创建和理解。于是，很自然的提出支持一个非常通用的计算模型的需要，它能够被用于广泛的应用域和抽象级，并且反映若干个特定平台实现模型的语义。此外，行动的类型或者活动模型的风格可能需要被约束，从而允许那些模型到目标实现平台的有效转换。

    在这种情况下，目标平台是 WebSphere Integration Developer 所支持的 Web 服务和 IBM SOA 编程模型。这包括业务目标（XSD）、接口（WSDL）、模型组装（SCDL，SCA 的一种 IBM 原型）、过程（BPEL）、SCDL（业务状态机）和 Java? 等组成元素。为了对这个特定的 Web 服务平台提供 UML 模型的转换，我们需要遵循一些服务建模的非常好的实践。也就是说，我们需要首先个性化定制 UML 来对一个 SOA 解决方案体系结构建模，然后，我们需要使用一个特定的建模风格来生产可以被转换到 Web 服务的模型。

    UML 通过使用规范被典型的定制。规范定义了许多能够通过添加属性和关系被扩展为一个或者更多的 UML 元类的模板类。规范被应用到 UML 模型中，从而使这些扩展变得可用。这些可被应用的规范通常都支持模型驱动体系结构中的两个目的：

    首先，通常来讲，规范的使用是为了个性化定制打算被支持的抽象概念。在这种情况下，我们将 IBM Software Services 规范应用到我们的 Purchase Order Process 模型中，扩充 UML 来支持服务建模。规范中的许多模板类仅仅澄清了 UML 元类是如何被用到建模一个 SOA 解决方案，以及如何被用来限制那些能够在 UML 中被完成的模板类，从而确保 SOA 模型能够反映 SOA 原则。例如，<serviceConsumer> 模板被用来指示一个对并不实际为自己提供任何复用服务的用户进行建模的 UML 组成元素。这种组成元素可能反映一种不打算被复用的业务过程。举一个约束的例子，Software Services 规范需求所有被一个服务端口非直接控制的 <serviceProvider> 组成元素所实现和使用的接口。这样做的目的是为了通过拥有服务端口上的依赖，减少被连接用户和提供者之间的耦合性。当某些接口发生变化时，只有那个接口需要被检查来响应变化，而无需对所有被连接到该组成元素的端口都进行操作。

    模型驱动的体系结构（MDA）中规范的第二个目的就是支持特定平台的标记。这些标记包括“组成”具有将模型转换到特定平台所必须的额外的模板和属性。例如，当一个 UML 包需要被转换到一个 Web 服务容器时，它可能需要一个指定的 Uniform Resource Identifier (URI)。

    有时，规范的这两个目的被结合在一起。例如，支持相关数据建模的 UML 的扩展，由一个既为实体相关属性（ERA）数据建模扩充 UML，又提供必要的标记来将 UML 域模型转换到 IBM? Rational? Data Architect 逻辑数据模型 (LDMs) 的规范组成。IBM Software Services 规范为那些被转换到 Web 服务的模型提供了这种双重角色。

    在其他情况下，当一个规范被用来驱动转换的同时，另一个规范能够被用作建模支持。例如，SOA 建模设计将在 Java? 2 Platform, Enterprise Edition (J2EE) 中被实现。后者能够通过将 Software Services 规范和 Enterprise Java?Beans (EJB) 转换规范应用到同一个模型上得到援助。当 EJB 转换规范模板将被应用到模型元素上来指导 Rational Software Architect UML-to-EJB 转换的实现的同时，Software Services 规范模板将被应用到模型元素上来支持服务建模。当然，同一个 SOA 模型也能够通过使用 Rational Software Architect UML-to-SOA 转换工具被转换到 Web 服务。UML-to-SOA 转换将通过切断 Software Service 规范来产生 Web 服务。它将忽略用于 EJB 转换的标记。

    下一小节将描述一些 SOA 模型转换到 Web 服务的建模的非常好的实践，尤其是像在 IBM SOA 编程模型 中被实现的 Web 服务，以及被 WebSphere Integration Developer 所支持的服务。

    数据建模

    服务操作参数的类型应当或者是一个原始类型，或者是一个 <message> DataType。建模器应当既不考虑数据的位置、是值呼叫还是引用呼叫语义，也不考虑任何并发管理工具。假定服务实现工作在一个可能已经被从其最初源转移或者转换的数据的瞬时副本上。这样做确保了服务使用者和服务提供者之间最小程度的数据耦合性。
    
    服务建模

    如同 IBM Software Services 规范中所指定的那样，服务提供者组成元素必须通过服务端口，间接的实现或者使用所有接口。这样做确保了被连接到该组成元素的服务消费者和提供者之间适当的去耦合性。

    活动建模

    一个具体的服务提供者通过为每一项操作提供一个行为来对它的服务操作进行方法建模。

    注释：

    一个具体的服务提供者是一个既不抽象也不 <specification> 的组成元素。

    任何行为都可能被使用，但是如果模型目标平台是 Web 服务，那么就能够很方便的使用一个容易被转换到 WebSphere-BPEL 的活动。图11所显示的活动模型是 Order Processor 服务提供者组成元素的一个自有行为，该组成元素是 processPurchaseOrder 操作的方法。关于这个活动，有如下一些事需要进一步的解释：

    方法行为的签名必须同它的规范操作相匹配。
    行动的输入和输出插口被规定从包含行动的右下角开始，并且按照顺时针的方向进行处理。这一插口顺序符合被呼叫操作的参数的顺序：目标输入插口作为第一个插口，并且操作的类型作为最后一个输出插口。目标输入插口反映了行动要求发送的那个目标对象（例如，拥有操作的分类器）。
    输入和输出插口类型通常并不被设置，这是因为这些类型能够从相应的参数中被获得。
    这个活动并不使用对象流程来指定图表的创建。相反，行动的输入和输出插口的名称被上下文分类器（拥有该活动的类）的参数、变量或者结构特性进行标注。UML 2 对其中任何一种都提供支持。
    活动的参数节点（位于活动的左侧或右侧边缘）没有被使用。相反，活动的参数节点（必须同其规范操作的参数相一致）根据需要被直接引用到输入和输出插口上。如果对象流程被使用的话，这些活动参数节点就将被使用。
    设置活动分区来反映包含该活动的组成元素的各个服务端口或者部分。。所有请求和事件都通过这些部分被接收。在这个例子中并没有指定分区的名称，这是因为被反映的性质提供了识别分区的足够信息。
    呼叫操作行动的目标输入插口不需要被设置。活动分区反映了调用该分区中呼叫的那个服务端口。在 UML 2 中，这些被称为 <instance> 的分区具有定义良好的语义。目标输入插口也能够被定义，但是这样做是多余的。
    Accept Call 行动的 returnInformation 插口同呼叫操作行动的目标输入插口处理相同的事物。它也是有活动分区表现的端口，它表现了交互作用点，通过这个点呼叫将被接受。
    分配公式通过不透明行动被显示，在那里行动的名称包括一个反映参考变量、参数、结构特性的分配公式。分配声明中的 lvalue 和 rvalue 以 := （冒号加等号）被隔开。
    对象和控制流程的表达式是活动范围内参考变量、参数和结构特性的 Java 或者 XPath Boolean 表达式。
    对象流程中的 数据 被流程的名称所引用。
    对象流程中的 类型 被它的源所决定。

    这些约定被用来使得活动建模简单化、指定活动图表、更好的符合将要从它们中被生成的 BPEL。