组成元素和模型组装

    UML 服务模型中的每一个服务提供者组成元素都被转换到 WebSphere Integration Developer 模型中。目前尚没有用于集合服务使用者（消费者）和提供者的 Web 服务标准。因此，WebSphere Integration Developer Version 6.0.2 使用一个工具，服务组件体系结构 (Service Component Architecture, SCA) 的早期版本。模型组装是被捕获的 .component 文件，它们使用 Service Component Description Language (SCDL)——一种用于 SCA 的 XML 标记语言。一些公司正准备协作开发 SCA 的标准。更多信息请参见 Open SOA 网站。

    UML-to-SOA 转换为一个服务提供者元素的最大化复用创建了 WebSphere Integration Developer 模型。SCA 模型不能从其他模型中被组合。然而，它们能够从其他模型中导入服务，并且直接使用它们。因此，UML 中服务消费者和提供者之间的连接就如同 WebSphere Integration Developer 中的模型导入和导出之间的绑定一样。例如，Invoicer 服务提供者如图8所示。

    图20显示了相应的 WebSphere Integration Developer 模型组装。模型导入和导出是为每一个服务端口所创建的。SCA 不能够同时支持用于同一个交互作用点的被提供和被需求的接口，因此为提供和需求接口的服务端口分别创建导入和导出元素。invoicingExport 服务到处被提供的 Invoicing 接口；而 invoicingImport 导入被需求的 Invoicer 服务提供者的货品计价服务端口的 InvoiceProcessing 接口。

    图 20. Invoicer 模型组装
    
 
    请注意模型的名称。模型是一个 Eclipse 项目，但是由于模型是一个可复用元素，所以它必须像其它可复用元素一样对名称冲突进行管理。UML-to-SOA 装换所使用的约定，是为了创建基于服务提供者组成元素的有完全资格名称的模型项目的名称，由它所包含的包决定。这样做导致了很长的模型名称，可能会由于 URL 长度的限制引起 Windows 平台上的运行问题。这些模型名称能够很容易的被重新制作为满足其复用上下文环境管理的短长度的名称。

    Productions 组成元素导致另一个模型组装，如图21所示。这个模型没有导入，这是因为服务端口不需要任何接口。

    图 21. Productions 模型组装
    
 
    这些模型都使用 BPEL 过程来实际实现相应的服务提供者组成元素所提供的服务。详细操作细节请参见下一小节。

    查看图22中之前为 OrderProcessor 组成元素所创建的模型组装，如图10所示。

    图 22. OrderProcessor 模型组装
    
 
    OrderProcessor 服务提供者提供了购买服务，并具有对货品计价、时间表和货运服务的请求。与图10中的消费者和提供者组成元素相连接的服务信道，被作为绑定到相应的服务提供者导出的 OrderProcessor 模型中的导入来实现。这样做允许在 WebSphere Integration Developer 中有效的模块复用，并且保持 UML 服务模型独立于 SCA 的演变。当 SCA 被标准化时，UML 服务模型必须要改变；只有转换需要被更新。