【IT168 技术文章】

    本文的内容

    在本文中，我们将第 3 篇文章中创建的服务提供者集合在一起，以另一个服务提供者的方法来使用它们的功能。也就是说，我们将从其他服务的合成要素中创建一个新的服务。这一技术能够被递归使用任意次，越过任何一个关注集和任何一个抽象层。然而，有可能存在许多体系结构的约束，对服务操作的粒度、安全性和执行关注、数据交换量、以及有可能约束什么服务是由什么合成要素提供的写级通讯协议和绑定问题。这些问题决定解决方案的体系结构，并且不在本系列这些文章的讨论范围之内。请参见 Design an SOA solution using a reference architecture 获得关于这一重要课题的更多细节。

    如同本系列中的所有文章一样，我们将使用现有的 IBM? Rational? 和 IBM? WebSphere? 工具来建造解决方案，并且将它们链接到一起，从而我们能够检验该解决方案是否符合需求和更加有效的管理变化。表1总结了我们开发例子将使用的全部过程，以及我们所使用的工具。

    表1. 开发过程角色、任务和工具
　    角色                              任务                              工具
  业务执行官                        传达业务目标                  IBM? Rational? RequisitePro? 
  业务分析师                        分析业务需求                  IBM? WebSphere? Business Modeler
  软件架构师                        设计解决方案的架构            IBM Rational Software Architect
  Web 服务开发人员                  执行该解决方案                IBM? Rational? Application Developer 和 WebSphere Integration Developer

    服务实现回顾

    我们首先回顾在前面的文章中被执行的服务提供者。图1显示了 Invoicer 服务提供者。

    
    图 1. Invoicer 服务提供者
 
    Invoicer 服务提供者为计算定购单的最初成本提供了 InvoicingProtocol，然后当运送信息得知以后重新定义这一价格。定购单的总价取决于产品是在哪里生产的，以及它们是从哪里运送的。最初成本的计算可能被用来检验消费者有足够的信用或者仍然想要定购产品。在实现定购之前完成这一检验操作是最好的。

    图2显示了 Productions 服务提供者。

    
    图 2. Production 服务拓扑结构