soa建模之服务合成

《soa建模之服务合成》由会员分享，可在线阅读，更多相关《soa建模之服务合成（17页珍藏版）》请在金锄头文库上搜索。

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

2、ce architecture 获得关于这一重要课题的更多细节。如同本系列中的所有文章一样，我们将使用现有的 IBM? Rational? 和 IBM? WebSphere? 工具来建造解决方案，并且将它们链接到一起，从而我们能够检验该解决方案是否符合需求和更加有效的管理变化。表 1 总结了我们开发例子将使用的全部过程，以及我们所使用的工具。表 1. 开发过程角色、任务和工具角色 任务 工具 业务执行官 传达业务目标 IBM? Rational? RequisitePro?业务分析师 分析业务需求 IBM? WebSphere? Business Modeler 软件架构师 设计解决方案的架构

3、 IBM Rational Software Architect Web 服务开发人员 执行该解决方案 IBM? Rational? Application Developer 和 WebSphere Integration Developer1 服务实现回顾服务实现回顾服务实现回顾我们首先回顾在前面的文章中被执行的服务提供者。图 1 显示了 Invoicer 服务提供者。图 1. Invoicer 服务提供者Invoicer 服务提供者为计算定购单的最初成本提供了 InvoicingProtocol，然后当运送信息得知以后重新定义这一价格。定购单的总价 取决于产品是在哪里生产的，以及它们是从

4、哪里运送的。最初成本的计算可能 被用来检验消费者有足够的信用或者仍然想要定购产品。在实现定购之前完成这一检验操作是最好的。图 2 显示了 Productions 服务提供者。图 2. Production 服务拓扑结构2 服务合成服务合成 Productions 服务提供者提供 Scheduling 服务，决定产品在哪里被生产， 以及如何何时被生产。这一信息能够被用来创建运送时间表，这个表在处理定 购单时使用。图 3 显示了 Shipper 服务提供者。图 3. Shipper 服务提供者Shipper 服务提供者提供 ShippingService 服务，将产品运送到消费者 来完成定购。该服

5、务需要 ScheduleProcessing 接口来请求消费者处理完成的时 间表。服务合成现在，服务已全部由一些提供者提供，我们已经准备好将这些提供者 集合起来使用，实现最初的业务需求。这种集合根据业务需求来合成和设计服 务，为 Purchasing 服务提供一种方法。我们将创建一个 OrderProcessor 合成 要素，为处理定购单提供一个购买服务。这个服务提供者要求服务被 InvoicingService、Scheduling 和 ShippingService 服务规范定义。我们将创建一 个 OrderProcessing 合成要素，它集合了 Invoicer、Productions

6、 和 Shipper 合 成要素的实例，以及 OrderProcessor 合成要素，从而执行处理定购单的操作。Order Processor 服务提供者定购单处理服务由 Purchasing 服务规范指定（请参见图 4） ，该规范 包括如下功能（或者操作）：+ processPurchaseOrder (customerInfor : Customer, purchaseOrder : PurchaseOrder) : Invoice这一服务将由 OrderProcessor 服务提供者提供。OrderProcessor 是一 个合成要素，它通过将其他服务提供者（根据需求契约设计的）连接在一

7、起来 提供一个服务。也就是说被提供的服务方法的某些方面被设计用来以某种方式 使用其他服务提供者。这一合成要素通过它的购买服务端口提供 Purchasing 接 口。所有的消费者接口都是通过这个端口的，从而将消费者客户端从同合成要 素同其他服务消费者或者提供者的相互作用中分割出来。这样做限制了模型中 的耦合性，随着市场和服务消费者和提供者的变化能够更容易的做出改变。图 4. Purchasing 服务规范OrderProcessor 合成要素的组织展现在图 5 中所示的 Project Explorer 视图中。图 5. 定购管理业务功能区域（包）OrderProcessor 服务提供者包含在

8、org:ordermanagement 包中，它用 于组织同定购管理相关的服务。定购管理包也包含相关的服务接口、服务消费 者和服务提供者。图 6 中显示的 OrderProcessor 图表提供了 OrderProcessor 服务者及其 提供的和要求的服务的一个外部视图。 （要求的服务有时被称作请求，以便同功 能需要相区分。 ）外部的或者叫做“黑盒”视图是呈现给服务提供者的消费者查 看的。稍后将显示的合成要素的内部结构提供了一个支持合成要素的执行设计 结构的一个内部的或者叫做“白盒”的视图。图 6. OrderProcessor 服务提供者3 内部结构内部结构外部视图不是一个从执行中分离出来

9、的规范；它仅仅是合成要素某些方面 的视图。如果架构师或者开发人员希望完全的将服务提供者的规范从它的可能 执行中分离出来，就将使用到规范合成要素。规范合成要素定义了一个服务消 费者和服务提供者之间的契约，它从特定的提供者执行中减弱了它们。规范合 成要素能够被许多具体的合成要素识别出来，这些要素以一种识别契约的方式 提供服务，并且提供服务的可接受的质量。请参见“SOA 建模: 第二部分 服 务规范”获得更多细节。OrderProcessor 服务提供者要素十分简单和稳定，在这个例子中，架 构师和开发人员决定不使用服务规范。结果是，使用 OrderProcessor 合成要素 的任何服务消费者都将同

10、这个特定的执行相联系。这是不是一个充分的设计取 决于有多少服务将被使用，以及随着时间的推移它们将发生多大程度的改变。 只有解决方案架构师能够决定一个特定的系统能够容忍什么程度的耦合性。OrderProcessor 合成要素也拥有反映有其他服务提供者（货品计价、 时间表、运送）提供的需要请求的服务端口。这些服务提供者提供了 OrderProcessor 合成要素用来执行其被提供的服务操作的那些服务。每一个服务交互作用点都涉及到一个简单协议，该协议影响被提供的 和被要求的接口。例如，货品计价交互作用点要求 Invoicing 接口启动价格计算器，并且发送运送价格。然而，它可能会花费一些时间来计算运

11、送价格，所 以 OrderProcessor 通过其货品计价端口来提供 InvoiceProcessing 接口，从而使 得货品计价服务提供者能够在其准备好时发送一张发货单。Order Processor 执行设计模型我们现在完成了服务模型的架构，并且在服务提供者的外部视图中捕 获到它。下一步就是为 OrderProcessor 合成要素所提供的 processPurchaseOrder 服务操作提供一种方法。这种方法必须遵循任何一个已经 完成的服务契约或者已经实现的服务规范，也要遵循那些操作已经被定义的服 务规范。内部结构OrderProcessor 服务提供者通过它的购买服务端口提供了一个

12、简单的 服务规范 Purchasing。这个服务规范指定了一个简单的操作 processPurchaseOrder。服务提供者必须为它所提供的全部服务操作提供一些方 法。在这个例子中，我们使用 Activity 作为 processPurchaseOrder 服务操作的 方法。有关的细节被显示在提供服务的 OrderProcessor 合成要素的内部结构中。 OrderProcessor 内部结构在图表、接口、类和活动中被捕获，如图 7 中的 Project Explorer 视图和图 8 中的复合结构图表所示。图 7. OrderProcessor 服务提供者的组织Project Explo

13、rer 视图显示了 OrderProcessor 提供者各个部分的列表， 以及每一个被提供的操作的方法（行为） 。在这个例子中所使用的约定是，使用 一个和合成要素名称一致的类图表，并且在包含该合成要素的包中，显示它的 外部视图。这就是图 6 和图 7 中所显示的图表。同合成要素具有同样名称并且 被包含在合成要素中的复合结构图表，提供了服务提供者结构的内部视图。这 个图表直接位于图 7 中的 OrderProcessor 服务提供者的下面。这些约定能够更 好的协调服务参与者的外部和内部视图，并且如同合成要素一样仔细研究图表。OrderProcessor 复合结构图表如图 8 所示，提供了一个服务

14、提供者的 内部结构的总体视图。再一次显示了合成要素的合成静态结构的各个部分（端 口和属性） 。图 8: OrderProcessor 服务提供者的内部结构OrderProcessor 合成要素的内部视图很简单。它由用于被提供的和被 要求的接口的服务端口、加之许多其他保持服务提供者状态的属性共同合成。 属性 ID 被用来识别服务提供者的实例。这个属性将被用来动态的关联消费者 和提供者的交互作用。属性 schedule 和 shippingInfo 是在 processPurchaseOrder 服务操作的执行中被使用的信息。4 被提供的服务操作的方法被提供的服务操作的方法 被提供的服务操作的方法

15、由服务提供者所提供的每一项服务操作必须通过以下两种方式之一被 实现：Behavior （Activity、Interaction、StateMachine 或者 OpaqueBehavior） ， 它是操作的方法；属于合成要素的一个 Activity 中的 AcceptEventAction （异步调用） 或者 AcceptCallAction （同步需求或者回复调用） 。这允许一个单一的 Activity 拥有多于一个的并发进入点，并且它符合 Business Process Execution Language (BPEL) 中的多重接收活动。这些 AcceptEventActions 通常被用来处理回叫信号，从其他异步的 CallOperationActions 中返回信息。OrderProcessor 合成要素包含两种服务实现风格的例子。 processPurchaseOrder 操作拥有一个同样名字的方法活动。这一活动，如图 9 所 示，是提供服务操作的服务提供者所拥有的一种行为。图 9: processPurchaseOrder 服务操作实现这个图表同用于相同行为的 WebSphere Business Modeler 图表非常符 合。InvoiceProcessing 和 ScheduleProcessing 服务操作通过过程中