变形的类型

    要使用前面显示的服务提供者设计，我们需要理解消费者和提供者之间的关系：它们是如何被连接的，如何在连接器的终端指定端口的类型，以及如何决定那些类型是否兼容并且导致有效的连接。

    SOA 就是将提供者的功能同消费者的需要相匹配。消费者一方拥有通过请求满足的需要，提供者一方拥有通过服务提供的功能。通过将请求和服务相连接，消费者的需要就被映射到提供者的功能上面。消费者使用服务的方法和提供者提供服务的方法，必须同服务和请求规范中的定义的协议相一致。

    当一个服务消费者端口（一个请求）被连接到一个提供者的服务端口时，连接器终端的端口必须一致。这意味着消费者的请求必须要求提供的端口接口，而且消费者必须提供被要求的端口。进一步，消费者和提供者必须依照服务接口中定义的协议进行相互作用。

    请求端口能够使用任何类来定义它的类型。它能够提供或者要求（或者两者皆是）任何接口，只要它们同与其相连接的任何服务端口都兼容即可。也就是说，消费者和提供者直到它们被连接之前都是分开的，并且并不要求它们拥有一个同被提供的服务规范相一致的特定的服务规范。

    然而，在许多情况下，消费者请求的类型正是它所连接的服务端口的补足物或者变形。结果是我们可以方便的定义一个约定，从而易于指定和指明一个能够被用作消费请求端口类型的服务规范的变形。这一类型就是服务规范的变形。服务规范同它的变形之间的唯一区别在于，被提供（实现）和被要求（使用）的接口是相反的。类中的其它所有事情都是一样的，包括对服务协议进行建模的行为。

    例如，请考虑 InvoicingService 服务接口。图12显示 InvoicingService 的变形，被称作 ~InvoicingService。

    图12. ~InvoicingService，即 InvoicingService 的变形
 
    这里所使用的会话是为了将变形命名为同服务规范一致的名字，除了以符号 ~ 开头之外。任何命名协定都可以被使用，但是应当前后一致，以便我们识别这些类型之间的关系。~InvoicingService 同 InvoidingService 具有相同的内在结构和行为。它仅仅是使用了 InvoidingService 所提供的接口，并且实现了被要求的接口。

    用于 UML 的 IBM Software Service Profile 的一个进一步扩充，可能介绍从功能中区别需要的请求端口的概念。然后，请求端口能够使用同样的类型作为服务端口，由此就不再需要定义变形的类型。请求端口将指示出即将被适用的服务的性能，而服务端口将指示出它们将要被提供。