内容


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

服务实施

Comments

系列内容:

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

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

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

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

关于本系列文章

在本系列文章的前面几篇中(见于“查看本系列文章中的更多内容”),我们概括了一种方法,以识别与业务需求相联系的服务。在开始工作前,我们会获取实现业务任务所需要的业务目标。接下来,我们对业务过程进行了建模,并处理了满足目标所需的过程。然后我们完成了识别服务的指定,将它们分配给参与者,并实现了参与者。

在本系列文章中的第一篇“第 1 部分. 服务的识别”中,我们查看了怎样识别与业务相关的服务,来最大化面向服务架构(SOA)的潜力。我们识别了基于业务需求所需要的功能,并通过服务界面揭示了这些功能。

在第 2 篇文章“第 2 部分. 服务的指定”中,我们对服务界面的具体内容进行了建模。服务界面会定义服务消费者所需知道的一切事,以决定他们是否对使用服务感兴趣,以及怎样去使用它。它还指定了一个服务提供商所需知道的一切事以成功地实现服务。

在第 3 部分. 服务的实现中,我们对涉及到了参与者 Invoicer、Productions 以及 Shipper 服务界面的实现进行了建模。每一个参与者都根据服务界面来提供和实现功能。每一个提供的服务操作都有一种方法,去描述服务实际实现的方式。这种方法可以是任意 UML 行为,包括 Activity、Interaction、StateMachine 或者 OpaqueBehavior。这种抉择需要建模者来作出。

在第 4 部分. 服务的组成中,我们查看了怎样通过服务渠道将可协调的请求与服务联系起来,来集合服务参与者。这些集合就是服务参与者结合的方式,以提供方案,包括其他服务的执行。

在本文中,也就是本系列文章的最后一篇中,我们将会使用 IBM®Rational®Software Architect UML 到 SOA 的转变特性,以创建一个可以在 IBM®WebSphere®Integration Developer 中直接使用的 Web 服务,以执行、测试和部署完成的方案。

本文的创作背景

前面文章中的步骤创建了一个满足业务需求的完整 SOA 方案模型。因此,我们知道了该方案架构满足的需求,以及当需求变更时需要改变什么。

为了部署和运行这个方案,我们需要创建一个实际的执行,它与模型中获取的结构性和设计决定相协调。我们可以使用模型作为一个向导来手工创建该方案。但是可能这很容易出错,繁琐且费时,并且需要一个有高度业务能力的开发员以确保实际的决定作出了正确的实现。很有可能手动创建方案,使用模型作为指南是非常有用的。但是拥有一个完整规范确实的模型,能够给我们一个机会去利用模型驱动开发(MOD),来从模型中创建一个或者多个方案草图,然后在特定平台的编程环境中完成具体的编码工作。这就是本文的主题。我们将会使用才 Rational Software Architect UML 到 SOA 的转变特性,来创建一个可以在 WebSphere Integration Developer 中直接使用的 Web 服务,以执行、测试和部署完成的方案。

有了本系列的各篇文章,我们会使用已存在的 IBM Rational 工具来构建方案工件,并将它们联系在一起,这样我们就可以根据需求来确认方案,并且更加有效地管理变更。另外,通过向 IBM Rational Software Architect 中的 UML 模型来添加 OMG SoaML Profile,我们扩展了统一建模语言(UML)。表 1 提供了开发该范例将会使用全部过程的总结,以及用于构建工件的工具。

表 1. 开发进程角色,任务和工具
角色任务工具
业务执行传递业务目标与目的IBM®Rational®Requirements Composer
业务分析员分析业务需求IBM Rational Requirements Composer
软件架构设计架构IBM Rational Software Architect
Web 服务开发员实现方案IBM®Rational®程序开发员
Web 服务集成部署一项 Web 服务IBM WebSphere 集成开发员

开始时让我们评审在前面文章中创建的服务以及服务参与者,使用 SoaML,面向服务架构建模语言建模:第 1 部分:服务的实现(见于“本系列文章的更多内容”)。

服务规范以及实现评审

图 1 提供了完整范例的概述。顺序管理包包含了关键的模型元素:Purchasing ServiceInterface 与 OrderProcessor 以及 Manufacturer 参与者。Ordermanagement 包会从其他的包中导入模型元素。客户关系管理(CRM)包包含了定义用于实现服务的持续性实体的域数据模型,以及用于在服务参与者之间交换信息的服务数据 MessageTypes。服务数据是满足特定服务需求域数据上的视图(一个选择和项目)。

信用、产品和传递包分别定义了 Invoicer、Productions 以及 Shipper 参与者,以及他们相应提供的服务界面。OrderProcessor 是提供购买服务,并为结账、日程安排和传递使用服务。

Manufacturer 参与者是联系在服务价值链中其他参与者的引用。这就是说,orderProcessor 拥有结账者、产品和传递者部件提供满足的需求。Manufacture 参与者还提供了一个购买服务,但是它是通过将其委托给它的 orderProcessor 内部构件而实现的。所有的服务操作都有一种方法,去指示服务实际上是如何执行的,以及被消费的服务实际上是如果被使用的。

Manufacturer 参与者还会坚持在第一篇文章“使用 SoaML,面向服务架构建模语言建模:第 1 部分:服务的识别”中定义的 Process Purchase Order 服务架构。Manufacture 参与者的部件会限制于参与者的角色,以显示服务模式是如何遵循和实现的。这就可以确保方案遵循企业结构指导原则,而且它提供了结构部件与方案部件之间的追踪性。

图 1. 处理购买订单概述
处理模型的购买订单图
处理模型的购买订单图

服务建模最佳实践

UML 2 建模通过使我们从具体的细节过程中抽离出来,来提高对系统的理解能力。尽管如此,建模并不是一副万灵药,而有意义的模型图仍然可以请求企业去创建和理解。支持计算的通用模型,是需要的自然结果,可以用于广泛的程序域以及各种层次的抽象级别,而且它代表了特定平台执行模型的语义。另外,活动模型样式或者操作的类型需要得到限制,以支持那些模型向目标执行平台的有效转换。

在这种情况下,目标平台是 WebSphere Integration Developer Web 支持的服务以及 用于实现 Web 服务的 SOA 编程模型,第 1 部分: IBM SOA 编程模型简介。包含的业务目标(XSD)、界面(WSDL)、模块集合(SCDL,Open SCA 的 IBM 处理器,有时也叫做“经典 SCA”),处理(BPEL4WS:Web 服务的业务进程处理语言)以及 Java™构件。为了在这个特定的 Web 服务平台上支持 UML 模型的转变,我们需要遵循服务建模最佳操作。我们先将对象管理组(OMG)SoaML 标准概述转换为 SOA 方案架构,然后使用一个特定的建模样式,以产生可以转换为 Web 服务的模型。

UML 一般使用概述来定制。所谓的 概述定义了一系列的构造型类,可以使用附加的属性以及关系来扩展一个或者多个 UML 元类。概述应用于 UML 模型以使用这些扩展。这些应用的概述通常支持模型驱动架构中两个目的:

  • 首先,对概述最常用的就是定制想要支持的抽象程度。在这种情况下,我们对我们的 Purchase Order Process 模型应用 OMG SoaML 概述,以扩展 UML 好支持服务建模。该概述中的许多构造型都会简单地澄清怎样使用 UML 元类来为 SOA 方案建模,并限制在 UML 中完成的任务,以确保 SOA 模型反映了 SOA 原则。例如,<<Participant>>构造型用于指示一个对服务消费者或者提供商建模的 UML 构件。举一个限制的例子,SoaML 需要 <<Participant>> 构件实现或者使用的所有界面,以通过服务和请求端口(UML 端口)进行处理。这就是降低联系的消费者与提供商之间的耦合度,而不是整体的构件。然后,有一些界面更改,只有那些更改过的端口才会得到检查,以响应更改,而不是与构件联系的所有端口。
  • 模型驱动架构(MDA)的第二个目的,是支持特定平台的标记。这些标记由其他的构造型以及属性组成,这些构造型和属性用需要的信息来“标记”一个模型以将其转换为特定的平台。例如,在转换为一个 Web 服务容器时,一个特定的 UML 包可能会需要有特定的统一资源标记(URI)。

有时,概述的这两个目的会合并在一起。例如,对 UML 的扩展以支持关系数据建模,,它由单个概述组成,概述为实体-关系-属性(ERA)数据建模扩展 UML,并提供了需要的标记以将 UML 域模型转换为 IBM®Info Sphere®Data Architect 逻辑性数据模型(Lames)。

在其他的情况下,当其他的概述用于驱动转换时,还有一个概述可以用于支持建模。例如,考虑一下在 Java™Platform,Enterprise Edition(JEE)上执行的 SOA 设计建模。对同一模型同时应用 SoaML 概述与 Enterprise JavaBeans™(EJB)转变概述,可以帮助使用程序。SoaML 概述构造型将会应用于模型元素,以支持服务建模;尽管如此,EJB 转变概述构造型将会应用于模型元素,以指导 Rational Software Architect UML 到 EJB 转变的执行,同时生成执行代码。当然,相同的 SOA 模型还可以使用 SoaML 概述标记,来生成 Web 服务。它将会忽略掉 EJB 转换的标记。

接下来的部分描述了对 SOA 模型的最佳建模操作方式,这些 SOA 模型会转换为 Web 服务,特别是 IBM®SOA 编程模型中执行的特定 Web 服务并为 WebSphere Integration Developer 所支持。

数据建模

服务操作参数的类型会是 UML Primitive Type、DataType 或者 SoaML<<MessageType>>DataType 中的一种。建模员不应该假设数据的位置,值访问或者引用语义访问,也不应该假设任何清晰的并发管理设备。假设服务执行会在数据的临时拷贝上进行,数据应该从它的原始源来转移、转换或者即转移又转换。这就确保在服务消费者与服务提供商之间的数据的耦合度降到最低。

SoaML 支持服务操作的远程程序访问(RPC)或者文件中心样式参数。RPC 样式支持多种输入和输出参数。文件中心样式最多允许一个输入和一个输出。使用 SoaML MessageType 参数来指示文件中心的样式。

服务建模

正如在 SoaML 概述中指定的那样,一个服务参与者必须通过服务端口实现或者使用所有的界面。这就确保与构件相联系的服务参与者之间不会发生耦合。

活动建模

一个联合的服务提供商会为每一次操作提供一种行为,以为服务操作的方法建模。

注意:
所谓联合的服务提供商就是一个既不抽象又不是<<specification>>构件的构件。

可以使用任意的行为,但是如果模型目标平台是 Web 服务,那么就很方便使用可以轻松转换为 BPEL4WS 的活动。例如,Order Processor 服务提供商构件的活动模型,就是 processPurchaseOrder 操作的方法。关于活动还有一些事情需要解释:

  • 方法行为的签名必须匹配其规格操作。
  • 操作的输入与输出部分会在包含操作的右下角找到,而且它们会顺时针排列到右下角。该帧排序响应于访问操作参数的顺序,而目标输入帧会成为第一个帧,而操作的类型会成为最后的输出帧。目标输入帧代表了操作请求发送至的目标对象(例如,拥有操作的标识符)。
  • 输入与输出帧类型通常不会得到设置,因为可以从相应的参数中得到它们。
  • 该活动并不使用对象流来简化图表的创建过程。相反,操作上输入与输出的名字,会标上范围内背景标识符(拥有活动的类)中的参数、变量或者结构性特性。UML 2 都支持它们,但是使用它们中的哪一个取决于您个人的偏好。
  • 活动参数节点(在活动的左边和右边)并没有得到使用。相反,活动的参数(它必须响应于规格操作的参数)会在输入与输出帧上得到直接的引用。
  • 活动分区被设置为代表包含活动的端口或者服务端口。所有的调用和所有的事件都会通过端口来接受。在这种情况下分区并没有得到命名,因为代表的属性提供了足够的信息以识别分区。
  • 访问操作的目标输入帧并没有得到设置。作为一个选择,活动分区代表了该分区中访问调用的服务端口。它们叫做 UML 2 中的 <<instance>> 分区,并拥有定义完善的语义。目标输入帧也可以得到设置,但是这可能会是多余的。
  • Accept Call 操作的 returnInformation 帧与访问操作的目标输入帧得到相同的处理。它还是活动分区代表的端口,而且它通过接受的访问来代表交易点。
  • 任务表达与模糊操作一起显示,而操作的名字包含了引用变量、参数和结构化特性的任务表达。任务声明中的 lvaluervalue 由一个冒号加等号隔离开来( := )。
  • 对象上的 Guard 表达式与控制流是引用变量、参数和结构化特性的 Java 或者 XPath Boolean 表达式。
    • 对象流上的数据由流程的名字引用。
    • 对象流上数据的类型由它的来源决定。

这些规则用于简化活动建模过程,简化活动图,并更好地响应从 BPEL 中生成的项目。

转换为 Web 服务

转换需要使用转换配置。

配置转换

您可以选择 File > New > Other > Transform Configuration,来创建一个转换(见于图 2)。

图 2. 创建一个新的转换配置
'选择一个向导 ' 屏幕视图
'选择一个向导 ' 屏幕视图

对于本例我们将会使用从 UML 到 SOA 的转变,如图 3 所示。

图 3. 选择从 UML 到 SOA 的转变
'新的转变配置  ' 窗口
'新的转变配置 ' 窗口

大多数的转变的配置由三个基本的部件组成:

  1. 选择转换源元素
  2. 选择(或者创建然后选择)目标元素
  3. 配置转变属性

可允许的源元素是由选择的特定转变定义的。通常来说,最好只转换整个的模型,而不是模型的私人部分。这就可以确保模型,它代表了私人版本的资源,被当作模型转变方面的 汇编单元。通过确保工作区内资源的更改,响应于应该处理的转变,来简化模型管理以及转变依赖性处理过程,以确保得到的工件与它们的源元素保持同步化。例如,您不会想到 Java 类中的私人方法,并且只汇编这种方法,然后为剩余的类将其插入到比特代码中。在一个快速变更的环境中进行管理可能不太现实,它可能需要您本人,而不是构建器和汇编器去知道由于更改发生而可能要求汇编的所有附件。

在本例中,PurchaseOrderProcess 模型是源,而工作区作为目标被关闭。所有转换的模型都被置于新的 WebSphere Integration Developer 项目(见于图 4)中。

图 4. 配置转变源与目标
屏幕上所选择的转变源
屏幕上所选择的转变源

图 4 的大图

转换配置参数代表了没有包含在模型中的转变选项。一般来说,控制针对总体选项,而不是对应用到一个特定模型元素上的选项。UML 到 SOA 的转变只有很少几个转变选项,如图 5 所示。

图 5. 配置转换特性
两列:属性与值
两列:属性与值

处理 UML 元素而不将构造型设置为 True,意味着 SoaML 概述实际上是可选的。数据类型,构件和活动会转换为 Web 服务方案而不需要任意的构造型,或者构造型会离开特定的模型元素。但是,应用 SoaML 构造型以简化服务模型,是一个比较好的建模操作。

这就会完成配置将 PurchaseOrderProcess 模型转换为一个 Web 服务方案。项目会位于工作区中。

运行转换

执行 PurchaseOrderProcess2WebServices 转换是十分简单的:

  1. 选择在前面部分中创建的 PurchaseOrderProcess2WebServices.tc 转换配置文件。
  2. 从弹出菜单中,选择 Transform > UML to SOA

转变配置中选择的转变得到了执行,因此将源模型转换为 Web 服务工件,并将结果得到的 WebSphere Integration Developer 项目置于工作区内。然后您可以启动 WebSphere Integration Developer,并将已经存在的项目导入到 WebSphere Integration Developer 工作区内,以完成、部署和测试结果。

技巧:
如果模型发生了变更,那么您需要返回这种转变。

转变的结构如图 6 所示,使用 Project Explorer 中的 Modeling 视图。

图 6. 转变结果
结果的 Project Explorer 视图
结果的 Project Explorer 视图

检查结果

UML 到 SOA 的转变配置会在一系列的 Eclipse 项目中置放结果的元素。这些项目要么是 WebSphere Integration Developer 库要么是模块项目,如下面的子章节中所述。

  • 项目包含了由其他项目所共享的业务目标、界面和模块导出。
  • 模块项目为 UML 服务模型中的每一位参与者都包含了一个模块执行。

您可以将这些项目导入到 WebSphere Integration Developer 工作区内。

技巧:
您可能会发现关掉 Automatic Build 会非常的有用,否则直到所有的项目都被导入之后,导入才会加速。

模型与库

转变配置中每一个模型的源,是用与模型相同的名字转换为一个 WebSphere Integration Developer 库。该库为源模型中的每一个类和数据类都包含了一个 XSD 元素,为每一个 UML 界面都包含了一个 WSDL 定义。这些库定义了所有 WebSphere 模块使用的业务目标与界面,其中的模块是从转变配置的选择源中的构件所生成的。

图 7 显示了 WebSphere Integration Developer 中导入生成的库以及模块项目,同时 PurchaseOrderProcess 被展开了以显示生成的业务目标与界面。注意 WebSphere 中的文件夹与名字域,直接响应于 UML 服务模型中的包结构。这就可以确保不同的资源与工具之间稳定的名字域管理与再使用。

图 7. ProcessPurchaseOrder 库及其业务目标和界面
网络域中的 PurchaseOrderProcess XSD 与 WSDL
网络域中的 PurchaseOrderProcess XSD 与 WSDL

让我们细看一下业务目标与界面,并将它们与它们的 UML 源代码相比较。图 8 使用 WebSphere Integration Developer Business Object 编辑器,该编辑器在 PurchaseOrder 业务对象上打开,以显示从服务数据模型中生成的 XSDs,在“使用 SoaML,面向服务架构建模语言来进行建模:第 3 部分. 服务的实现”中有所论述。正如您可以看到的那样,XSDs 可以精密地响应于它们的源数据类型。点击图片以查看生成的源。

图 8. 从服务数据模型中生成的 XSDs
PurchaseOrder 项视图
PurchaseOrder 项视图

每一项 UML 界面都会转换为一个 WSDL portType。图 8 中为 Invoicing 界面生成的 WSDL 显示在图 9 中。点击图片以查看生成的 WSDL 源。WSDL 同样类似于 UML 界面。

图 9. 为 Invoicing 界面生成的 WSDL
Invoicing 项视图
Invoicing 项视图

构件以及模块集合

UML 服务模型中的每一项服务提供商构件,都会转换为一个 WebSphere Integration Developer 模块。集合服务消费者(有时也叫做 用户)和提供商并没有什么 Web 服务。因此,WebSphere Integration Developer 会使用一个属性,也就是 服务组件体系结构(Service Component Architecture)(SCA)的早期版本。可以在使用服务构件描述语言(SCDL)的 .component 文件中找到模块集合,它是服务构件集合的 XML 文件语言。一些公司会协作以为 SCA 开发一种标准。见于 Open SOA 网站以得到进一步的信息。

UML 到 SOA 的转变会为每一个参与者都创建 WebSphere Integration Developer 模块,以最大化再使用的程度。SCA 模块不能从其他的模块中收集到。但是,它们可以从其他的模块中导入服务,然后间接地使用它们。因此,UML 中参与者之间的联系作为 WebSphere Integration Developer 中导入与导出之间的联系而执行。例如,您可以考虑一下 图 1 中所示的 Invoicer 服务提供商。

图 10 显示了相应的 WebSphere Integration Developer 模块集合。每一个服务和请求端口都会创建模块导入和导出。SCA 不能为相同的交易点支持提供的和需要的界面,因此提供和需要界面的服务和请求端口都会创建隔离的导入与导出元素。invoicingExport 服务导出了提供的结账界面;尽管如此,invoicingImport 导入了 Invoicer 服务提供商的结账服务端口所需的 InvoiceProcessing 界面。

图 10. Invoicer 模块集合
为 Invoicer 所收集的 WID SCA
为 Invoicer 所收集的 WID SCA

注意模块的名字。一个模块就是一个 eclipse 项目,但是因为模块是可再用的元素,所以它必须管理像其他可再用元素之类的名字冲突。UML 到 SOA 转变使用规则,基于服务提供商构件完全有效的名字用于创建模块项目名,由它包含的包决定。这就产生了很长的模块名,由于 URLs 长度的限制,名字过长可能会在 Windows 平台上产生一些运行上的问题。只要名字冲突在一定的背景下解决了,那么这些模块名可以轻松地重构成更短的名字。

Productions 构件会产生另一个模块集合,如图 11 所示。该模块没有含有导入,因为服务端口并不需要什么界面。

图 11. 产品模块集合
为 Productions 收集的 WID SCA
为 Productions 收集的 WID SCA

这些模块都使用一个 BPEL 过程来实际执行相应服务提供商构件提供的服务。在接下来的部分中会显示这种方法的具体内容。

查看一下图 12 以查看为 OrderProcessor 构件创建的模块集合。

图 12. OrderProcessor 模块集合
为 OrderProcessor 收集的 WID SCA
为 OrderProcessor 收集的 WID SCA

OrderProcessor 服务提供商为结账、日程安排以及传递服务提供了购买服务以及请求。将图 1 中的消费者与提供商构件联系的服务渠道,会作为 OrderProcessor 模块中的导入执行,以导出相应服务提供商的导出。这就允许 WebSphere Integration Developer 中模块得到有效的重复使用,并将 UML 服务模块独立于 SCA 的发展过程之外。当 SCA 得到标准化之后,UML 服务模型就不再需要变化了;只有转换才有必须要得到更新。

活动与 BPEL 过程

服务提供商提供的每一项功能性性能(操作)必须得到一定程度的执行。执行要么使用每一项操作的方法,要么使用一些其他行为中的方法或者 Accept Call 操作来在 UML 中设计执行。通过让操作者去决定什么时候愿意且有能力响应一条请求时,,而不是在服务消费者调用操作时立马就需要响应请求,后一种方法使消费者与提供商之间的耦合度得到了有效的降低。

WebSphere Integration Developer SCA 采取不同的方法。每一个导出都必须限制于集合中的某个构件,该构件为界面中的操作提供了一种执行方法。SCA 中的构件拥有以下的执行类型:

  • 人们的任务
  • Java
  • 进程
  • 角色组
  • 状态机

图 12 中的 OrderProcessor 服务提供商通过它的购买服务提供了一个单一的功能性性能以处理购买订单。这个操作的实现就是 UML 服务模型中的操作。UML 到 SOA 的转换从该进程中创建了一个 BPEL 进程,并将其作为导出操作的执行方案来使用。

图 13 中的 BPEL 进程非常相似于 OrderProcessor 参与者中的 processPurchaseOrder 活动。UML 活动是怎样转换为一个 BPEL 进程的具体细节信息,可以在 Rational Software Architect 的 Help 部分中找到。

图 13. OrderProcessor 进程构件与执行
为 OrderProcessor 生成的 BPEL
为 OrderProcessor 生成的 BPEL

图 13 的大图

解除耦合界面以及执行方案

正如前面所述的那样,WebSphere Integration Developer SCA 执行方案通过书写一个导出来提供功能,它向实现所提供服务的构件提供了一个界面。因为一个构件可以有一个执行类型,所以该导出所有界面提供的所有操作,都必须按照相同的方式执行。这就将执行类型与一个导出的所有界面联系了起来(所有导出可以由一个构件执行)。如果开发员想要更改一个特定操作的执行类型(例如,从一个任务更改为以 Java 实现的自动化服务),那么界面必须得到重组,以让不同的构件能够使用不同的构件执行类型。反过来,这又需要对那些界面的所有消费者都作出更改。这种界面设计耦合起来以执行的方法,阻止了 SOA 方案本来能够支持的商业目标的实现。

UML 并没有该规格以及执行耦合。提供的每一项操作可以拥有一个方法行为,方法行为是一个活动、交流、状态机或者模糊行为(代码)。建模员会独立地设计每一项操作的执行方案。这就可以产生一种情况,那就是相同的服务提供商构件对通过相同的界面中提供的不同操作,使用不同的行为类型。我们需要有一些方法,将这些服务提供商转换为 Web 服务。

还有另外一个因素需要考虑一下。构件是通过 UML 来得到实例化的,而不是它们拥有的行为。因此,实例化特征与生命周期与相同构件中的所有行为相同。另外,构件为所有它拥有的行为都建立了一个背景或者范围,因此允许这些行为能够共享对构件状态(属性和端口)的访问。因此,在转换为 Web 服务时,我们必须要有一些东西去管理这些特征、声明周期,并共享能够实现 UML 语义的状态。这就是引入业务进程执行语言(BPEL)的原因(见于参考资料 以得到更多关于 BPEL 的信息)。

我们不是创建一个单独的 SCA 构件,以执行模块集合中参与者的每一项操作,而是创建一个单独的 BPEL 进程以响应构件自身。您将会注意到图 13 中 BPEL 的名字是 OrderProcessor,,与 OrderProcessor 服务提供商相同,而不是 processPurchaseOrder,也就是提供的操作的名字。

让我们细看一下图 14 以查看 Productions 构件是怎样转换为 WebSphere Integration Developer Web 服务的。

图 14. Productions 参与者
Productions 参与者的类图
Productions 参与者的类图

注意为 requestProductionScheduling 设计的执行方法使用一项 Activity(具体内容不知道),但是 sendShippingSchedule 使用 OpaqueBehavior 以及 Java 代码中提供的执行方法。该服务提供商集合的模块如图 15 所示。

图 15. Productions 服务提供商执行方法
为 Productions 生成的 BPEL 的图
为 Productions 生成的 BPEL 的图

BPEL 进程为 Productions 服务提供商构件而创建。服务提供商的独特属性用于定义活动中所有 Invoke、Receive 与 Reply 活动的相关性。构件提供的每一项操作都由该进程的一个片段执行。以一个 pick 元素开始的进程用于处理每一项操作请求。然后每一项操作会创建一个范围,以为 UML 行为中定义的变量提供一个位置。然后范围包含了转换行为的结果。如果行为是一个 UML 活动,那么范围就会包含从活动中生成的 BPEL,如果行为是一个用 Java 语言写成的 OpaqueBehavior,那么行为的实体会复制到范围中的 Java 活动。如果行为是由 HTML 或者 JavaServer™Pages(JSP)语言写成的 OpaqueBehavior,那么会向范围中添加一个 Human Task 活动中。

这就提供了界面及其执行的完整解除耦合的操作。例如,如果建模员或者开发员决定将一项服务操作从任务中更改到自动化的 Java 代码中,那么只有该操作范围内的任务元素才会需要更改。客户不会意识到执行发生了更改,直到他们注意到服务运行的更快了,所以他们不需要再去做大量繁琐的工作为止。

完成方案

UML 到 SOA 的转变并没有生成完成的方案。这就是因为将执行内容集成到模型中的努力,要比使用编辑器将其集成到特定平台的工件中要困难的多。UML 2 Activities 还有一些特性没有转变成 BPEL。在未来的版本中会加入这些内容。在 Rational Software Architect 中的 Help 中可得到特定版本可得到的具体内容。

一般来说,WebSphere Integration Developer 需要做一些或者全部的以下开发活动。

  1. 如果模型中没有提供它的话,为模糊的行为添加 Java 代码。就算模糊行为的实体中提供了 Java 代码,也很容易产生错误,因为 Content Assist feature 和 Java(或者一个操作语言)汇编尚未与 Rational Software Architect 中的建模功能相集成。
  2. 为业务进程添加相关性。需要相关特定信息以识别构件的实例,UML 到 SOA 的转变尚不支持这种实例。而未来的版本会支持。
  3. 为任务创建一个用户界面(UI)。UML 模型可能含有模糊行为中的 JSP 或者 HTML。但是,就像 Java 源代码一样,这可能是不完整或者不合适的。集成开发员可能想要使用 Human Task 编辑器,Page Designer,或者其他的工具来创建完整的任务,它有合适的外观并完成程序 UI。
  4. 配置监视器模型。目前,UML 到 SOA 的转变并不会创建监视器信息,以评价关键的性能指示器(KPIs),该指示器可能被建模成服务和服务提供商的限制性因素。集成开发员可以使用 WebSphere Integration Developer 中的Monitor Model Editor 工具,以配置哪些数据应该收集起来以模拟更新和业务评价。

系列文章的总结

使用 IBM Software Services 概述来导出 Rational Software Architect 中的建模服务(见于“本系列文章更多内容”以得到最近的四篇文章)。第一篇文章,使用 SoaML,面向服务架构建模语言:第 1 部分:服务的识别,涉及到怎样使用业务过程和服务架构,来指定一系列的服务应该怎样联系起来,以及组合起来以完成一些目标。这些需求通常用于指定完成了什么目的。然后服务架构可以是十分有用的,以识别提供实际业务价值的服务。

使用 SoaML,面向服务架构建模语言建模:第 2 部分:服务的规定展示了怎样为服务界面的具体内容建模。如果一项服务可以解决问题的话,那么一个服务界面定义了潜在消费者需要了解的事情。如果是这样的话,以及实际上它是如何使用的。服务界面还决定了潜在消费者所需要的信息,以决定服务是否能够解决问题,如果能解决的话,怎样使用它。服务界面还定义了需要什么服务的提供商以完成服务。

接下来的文章,第 3 部分. 服务的实现第 4 部分. 服务的组合,展示了怎样设计和建模参与者,这些参与者要么提供服务,要么消费服务,以及这些服务操作是如何被执行的。文中还描述了服务提供商是如果指示结构与将他们联系在一起的服务契约,服务提供商会参与到业务目标、目的、进程、需求以及结构指导原则。

这篇最后的文章描述了怎样使用 IBM UML 到 SOA 的转变,来在 IBM WebSphere Integration Developer 所支持的 Web 服务平台上实现服务。WebSphere Integration Developer 支持一种 SOA 编程模型,该模型与在 Rational Software Architect 中获取的识别、规定和实现设计相协调。通过使用 WebSphere Integration Developer,您可以完成服务编程,然后为任务生成一个 UI,部署并测试您的程序。


相关主题

  • SoaML,一个扩展 UML 2 的 OMG 标准,用于建模服务,面向服务架构(SOA)和面向服务解决方案。此模型已在 IBM Rational Software Architect 中实现。
  • Daniels,John 和 Cheesman,John。“UML Components: A Simple Process for Specifying Component-based Software”。(Addison-Wesley Professional,2000 年)
  • Ali Arsanjani 的 基于服务的建模和架构,是有关 IBM 全球商业服务的面向服务建模和架构(SOMA)方法(IBM® developerWorks®,2004 年 11 月。
  • IBM 业务服务建模,是 Jim Amsden 的一篇 developerWorks 文章(2005 年 12 月),描述了业务过程建模和服务建模的关系,以实现双方的收益。
  • 建模面向服务解决方案 是 Simon Johnston 最著名的文章,描述了服务建模的方法,驱动 IBM UML Profile for Software Services 的开发,RUP for SOA 插件(developerWorks,2005 年 7 月)和 SoaML。
  • 用于实现 Web 服务的 SOA 编程模型,第 1 部分: IBM SOA 编程模型简介,Donald Ferguson 和 Marcia Stockton(developerWorks,2005 年 6 月),描述了用于面向服务架构(SOA)的 IBM 编程模型,其使非编程人员可以创建和重用 IT资产。模型包括组件类型,连线,模版,应用适配器,统一数据展现,以及一个企业服务总线(ESB)。本文是系列文章的第 1 部分,该系列文章介绍了 IBM SOA 编程模型,以及哪些是必须选择、开发、部署和推荐编程模型元素。
  • 阅读用于实现 Web 服务的 SOA 编程模型,第 1 部分: IBM SOA 编程模型简介,Donald Ferguson 和 Marcia Stock 所作,以了解更多有关 服务数据对象,其简化和统一了应用软件从海量数据源访问和操作数据的方式(developerWorks,2005 年 6 月)。
  • 参见 Web Servoces for Business Process Execution Language,了解更多有关 BPEL 1.1 规格的内容。
  • 订阅 developerWorks Rational 专区时事通讯。时刻关注 developerWorks Rational 内容。每隔一周,您将会收到 Rational 软件交付平台的技术资源和最佳实践的最新更新。
  • 浏览 技术书店,获得有关这些和其它技术主题的书籍。
  • 下载 IBM Rational 软件的试用版本

评论

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

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