内容


使用面向服务体系架构建模语言(SoaML)建模,第 3 部分

服务实现

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 使用面向服务体系架构建模语言(SoaML)建模,第 3 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:使用面向服务体系架构建模语言(SoaML)建模,第 3 部分

敬请期待该系列的后续内容。

关于本系列文章

在本系列文章的第一篇中,“第 1 部分:服务识别”(“查看本系列文章的更多内容”),我们概括了一种基于 IBM® 面向服务建模与架构(SOMA)的方法,以识别与业务需求相联系的服务。我们从获取实现业务任务所需的业务目标(Goals)及阶段性业务目标(Objectives)开始起步。然后我们将会对所需要的业务操作和业务流程进行建模,以满足一定的目标。接着我们会使用业务流程,以识别揭示服务接口的候选功能。

在本系列文章中的第二篇,“第 2 部分:服务规范”中,我们对服务接口的具体内容进行建模。服务接口定义了潜在消费者需要知道所有内容,以决定他们是否对使用服务感兴趣,以及怎样去使用它。它还指定了一个服务提供商成功地实施服务所必须知道的事情。这就是说,一个服务接口通过特定的联系点,定义了消费者与提供商之间可能发生的交互。

在本文中,我们还看到了服务实际上是如何提供的,或者用统一建模语言(UML)术语来说,是如果实现的。服务实现设计从决定哪一个参与者会提供和使用什么服务开始。该决定在服务可用性、分布情况、安全性、交易范围及耦合方面,具有十分重大的意义。在作出这些决定之后,您就可以设计每一项服务的功能性性能的实施方式,由此,进而决定所需要服务实际的使用方式。注意在设计服务实施方案方面,并没有把我们限制在一个特定的抽象层次之上。我们可以在不同的机构之间、不同的服务参与者之间以手工业务流程的方式来实施服务,也可以通过一些软件平台上信息化服务来实施服务。相同的概念应用于这些抽象的层次或者不同的关注点之间。重点在于在区分处在松散参与者之间的服务以及请求,并将其组合成一个服务价值链。

本系列文章接下来的一篇,“第 4 部分:服务组合”,将会描述怎样组合这些服务以创建新的服务。最后一篇文章,“第 5 部分:服务实现”,则将会使用 IBM® Rational® Software Architect 的 UML-to-SOA 转换特性,以创建一个可以直接在 IBM® WebSphere® Integration Developer 软件中使用的 Web 服务实施方案,以实施、测试和部署所完成的解决方案。

本文的写作背景

对 SOA 建模的完整理解,需要知道提供商具体是如何实施一项服务,以及消费者具体是如何使用此项服务的。如果实施方案实施起来很困难,那么有可能是因为服务规范是不合适的,或者是识别了错误的服务。本文向您展示了怎样设计我们在前面文章中开发的每一项服务的实施接口。实施方案的设计由三个步骤组成:

  1. 决定由哪一个服务提供商提供哪一项服务。
  2. 设计服务的实施方案。
  3. 组合并连结在建模一个完整的实施方案中所涉及到的所有服务消费者与提供商。

决定由哪一个提供商提供什么服务(不止一个提供商),由许多的因素决定,包括:

  • 功能性的聚合以尽可能地实现重用
  • 服务最有可能被使用的地方
  • 服务最有可能被部署到的地方
  • 需要什么质量的服务
  • 功能性区域的稳定性
  • 预期最有可能发生变更的地方
  • 域中能够容忍多大程度的耦合
  • 降低耦合情况以降低变更所能产生的影响
  • 安全性问题
  • 合适的平台实施方案技术
  • 对已有系统的集成与重用

所有这些关注点的具体分析,已经超出了本文的讨论范围,但是在 IBM® SOMA 方法中却进行了详细地讨论。这里,我们在一定程度上假设,IT 架构师会决定由哪一个参与者提供什么服务,这样我们就可以只关注于如何对提供商进行建模,以及怎样将它们组合到消费者方案中。

注意:
面向服务的架构建模语言(SoaML)标准使用术语参与者,而且不区分服务提供商与服务消费者。这是因为,通常意义上,参与者即会提供服务又会使用服务。从参与者的服务和请求端口来看,可以很清楚地看到实际上提供了什么以及使用了什么,使得进一步识别参与者变得不太必要。

对于本系列的所有文章,我们将会使用现有的 IBM® Rational® 工具,来构建方案工件,并将其联系在一起,这样我们就可以根据需求确认方案,并且更加有效地管理变更。另外,我们通过将 Object Management Group(OMG)SoaML Profile 添加到 IBM® Rational® Software Architect 中的 UML 模型里,来扩展统一建模语言(UML)以进行服务建模。表 1 提供了总体流程的概况,我们将会在开发本文范例的过程中使用这一流程与相应的工具来构建工件。

表 1. 开发进程角色、任务与工具
角色任务工具
业务执行主管传递业务目标与阶段性业务目标IBM® Rational® Requirements Composer
业务分析员分析业务需求IBM® Rational® Requirements Composer
软件架构师设计解决方案的架构IBM Rational Software Architect
Web 服务开发员实施解决方案IBM® Rational® Application Developer(RAD)

服务识别与规范评审

让我们从评审在前面文章中识别和指定的服务规范开始。图 1 显示了揭示处理购买订单所需功能的服务接口。

图 1. 处理购买订单的功能
显示揭示的功能
显示揭示的功能

图 2 显示了完整的 Scheduling 服务接口。该服务接口是一个简单的接口,因为对于使用日程安排服务来说,并没有感兴趣的协议。

图 2. Scheduling 服务接口
 Scheduling ServiceInterface 的类图
Scheduling ServiceInterface 的类图

图 3 显示了 ShippingService 服务规范。

图 3. Shipping 服务接口
 ShippingService ServiceInterface 的图
ShippingService ServiceInterface 的图

该服务接口有一点点复杂,因为通过使用一个简单的回叫形式的交互,它为传递者订购者之间的交互进行了建模。因为这种指定包含了一个协议,我们使用一个定义服务协议中会涉及到的角色(属性)的服务接口来建模。这些角色的责任是由它们的类型定义的,它就是服务接口提供或者需要的接口。ShippingService 服务拥有的 shippingService 交互定义了传递者与订购者之间进行的交互。这种交互将会成为联系该服务接口定义的服务的服务渠道的协议。

图 4 显示了 InvoicingService 服务规范。

图 4. InvoicingService 接口
 ShippingService ServiceInterface 的图
ShippingService ServiceInterface 的图

该协议同样有一些复杂,因为提供的和需要的服务功能性性能必须得到调用,并对应于特定的顺序。在这种情况下,可以使用一种活动来定义协议。

图 5 显示了 Purchasing 服务规范。

图 5. Purchasing 服务接口
 Purchasing ServiceInterface 的图
Purchasing ServiceInterface 的图

Purchasing 服务接口代表了在原始 Process Purchase Order 业务过程中指定的功能性性能。它代表了识别的和设计的服务,以实现业务过程。因为没有与该规范相联系的协议,我们使用一个简单的接口,再一次对其建模。

现在我们就可以设计工件了,该工件提供了每一种服务,并实现了揭示的功能。

服务的实现

所谓的服务定义了一系列的能够满足服务消费者或者用户需要的功能。服务实施方案设计的第一步,是划分服务。这就是说,我们必须想好我们将会提供什么服务,哪一个服务提供商会提供什么样的服务功能。这是设计一个 SOA 非常关键的一部分,因为选择提供商将会建立服务消费者与提供商之间的关系。因此,这就建立了一个系统以及系统各部分之间潜在耦合关系的功能。

您可以将所有的操作都放到一个单独的服务中,并因此拥有一个简单的解决方案。但是同时所有的客户都会依赖于一个服务,这就造成了很高的耦合度。提供商方面很小的一个变更,都有可能会造成所有消费者也都会产生变更。就这就是过去 C 编程时代模块化最常面临的问题。您也许会说,可以为每一个功能性性能都创建一个单独的服务,但是这将会导致产生一个复杂的系统,该系统在内聚度和封装性上面的表现十分糟糕。在消费者与提供商之间进行模块化交互可能是十分困难的,这种交互遵循一种交互协议使用一系列相关的功能性性能。

于是,决定服务的参与者是一种需要技巧的工作,并且通常会受到大量折中考虑的影响。其中分布性会发挥十分关键性的作用。如果我们可以设计不受参与者位置影响的 SOA 方案的话,那还不错,但是通常来说这是不现实的。服务部署的位置,会是消费者及其他需要服务的群体所在的地方,它对方案的性能、可用性及安全性方面会有重大意义的影响。在方案架构中忽略这一点,在方案的可执行性方面会造成十分严重的后果。

我们在这里面临的问题是十分简单的,所以初始 Business Process Modeling Notation(BPMN)业务过程概述中的汇于泳道,对于哪些参与者将会提供服务,哪些将会消费服务,都给出了一个明确的线索。图 1 中的所有服务及该图下面具体的服务规范,为所有的服务提供了服务提供商的模型。这是一个十分简单的例子,其中有多个参与者只会提供一种服务,并且只有一种功能。这与实际情况是不相符的。参与者通常会提供或者消费(或者即提供又消费)多种拥有多种功能性性能的服务,在这里,我们故意把这个例子简化,使之抽象出具体复杂的情况以便您更好地理解其中的概念。

注意:
本文中提到的服务实现化问题的概念,与在 SOMA 中描述的有些出入。在 SOMA 中,服务实现处理的是架构性决策问题,它关注的是方案的模板与模式、SOA 引用架构的具体内容、技术上的可实现性以及原型问题。这超出了本系列文章的讨论范围,本文只涉及到了决定由哪些参与者提供服务、哪些参与者消费服务,以及怎样决定这些内容。

结账

一个结账者为计算一个购买订单的初始价值提供了 Invoicing 服务。然后当他得知传递信息之后,可以进一步地完善估价活动。初始价值估计可以用于确认客户拥有相应的支付能力和信用,或者一直想要购买产品。在完成整个订单之前就进行确认会更好。

在开始这个服务时,我们创建一个定义其需求的系统用例,以及一个叫做 Invoicer 实现用例的参与者,如图 6 所示。Invoicer 参与者将会位于信用包中,并导入 CRM(客户关系管理)包,以使用公共的服务数据(信息类型)定义。

图 6. 最初的 Invoicer 服务提供商
显示 Invoicer Participant 的图
显示 Invoicer Participant 的图

Invoicer 参与者提供了 InvoicingService 服务。我们通过向 Invoicer 添加 Service 来对其建模,它是 InvoiceService 服务接口类型的。所有的服务是由服务接口输入的,该服务接口定义了什么功能性性能是提供的,什么是需求的,以及使用它们的协议。图 7 显示了 Invoicer 与添加的结账服务。

图 7. 对 Invoicer 服务提供商添加 InvoicingService
 向 Invoicer 添加结账服务
向 Invoicer 添加结账服务

我们可以通过服务的类型来知道该服务提供了 Invoicing 接口,并且需要使用 InvoiceProcessing 接口。从服务的类型中,我们可以知道与服务相关消费者使用服务所需要执行的操作,以及 Invoicer(或者其他的提供商)实施时必须执行的操作。服务的任意使用和实施必须与服务的规范及其协议相一致。

Invoicer 提供了 Invoicing 接口,它涉及到了两种操作:

  • initiatePriceCalculation
  • completePriceCalculation

Invoicer 必须为每一种指定如何提供操作的服务操作提供一种设计。当价值估算按照服务协议中指定的那样完成时,方法必须调用 InvoiceProcessing 接口的 processInvoice 操作。如图 8 所示,Invoicer 构件拥有两个与提供操作名字相同的行为。

图 8. Invoicer 服务实施
服务操作实施图
服务操作实施图

completePriceCalculation 活动是 Invoicing::completePriceCalculation 服务操作的方法。它使用一种模糊行为,来估计总体的价值,然后它会激活结账端口上的 InvoiceProcessing::processInvoice 操作。(processInvoice 操作的目标输入帧是结账服务端口,如包含操作的活动分区所示)。注意这与 InvoicingService 服务接口指定的结账协议相一致。

initiatePriceCalculation 模糊行为是 initiatePricesCalculation 服务操作的方法。该操作通过使用自然语言或者在模糊行为主体中获取的 Java™ 代码来实施。

产品日程安排

一个产品日程安排参与者会提供 Scheduling 服务,以决定在什么地方生产货物以及什么时候生产。可以使用该信息来创建一个使用的传递日程安排以处理购买订单。

产品参与者通过它的日程服务端口来提供 Scheduling 服务接口,如图 9 所示。

图 9. Productions 服务提供商
 Productions Participant 的图
Productions Participant 的图

服务操作方法是 requestProductionsSchedulingsendShippingSchedule 行为。这些实施方案的具体内容并没有显示在图表中,并有可能由开发员使用一些更加实用、特定平台的语言来实施。

传递

一个传递服务提供商会为一个客户提供 Shipping 服务接口以传递货物。它还需要 ScheduleProcessing 接口,以请求客户处理完整的日程安排。图 10 显示了 ShippingService 服务接口来提供传递服务。

图 10. Shipper 服务提供商
Shipper 规范与实施
Shipper 规范与实施

在本事例中,我们将 Shipper 参与者的指定与它的实现分隔开来。该指定参与者无论是在内部还是外部,都为实现参与者描述了架构。我们这样做是因为可能会有 Shipper 参与者指定的许多种不同实现方法,每一种方法都有不同的附加的功能及需要及服务的质量。我们展示了一个实现的参与者,ShipperImpl。特别是对集合的服务,我们将会使用 Shipper 参与者,而不是直接地引用 ShipperImpl。然后,在部署和运行的时候,该规范可以替换成各种的实施方法,以获得服务所需的质量。

后续的内容

现在我们已经完成了满足业务目标所需要的服务参与者的识别、指定以及执行(或者实现。结果是服务方案架构的技术中心设计模型。但是我们仍然没有创建一个服务参与者,该参与者集合了 Invoicer、Productions 及 Shipper 提供的服务,并使用它们来处理一个购买订单。本系列五篇文章的第四部分,“使用面向服务体系架构建模语言(SoaML)建模,第 4 部分:服务组合”,显示了怎样集合和联系这些服务提供商,以为业务需求提供一个完整的方案。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=475650
ArticleTitle=使用面向服务体系架构建模语言(SoaML)建模,第 3 部分: 服务实现
publish-date=03182010