内容


设计和开发更高效的 SOA,第 4 部分

使用 Rational Software Architect 和 SoaML 构建并管理您的面向服务解决方案的设计

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 设计和开发更高效的 SOA,第 4 部分

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

此内容是该系列的一部分:设计和开发更高效的 SOA,第 4 部分

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

简介

本文是这个 5 部分系列文章中的第 4 部分,本系列介绍了如何使用最新的 Rational 最佳实践开发流程指南和建模工具来设计和构造基于面向服务架构的健壮、灵活的 IT 解决方案。Rational SOMA 2.9 提供了具体的最佳实践开发流程指南,用于成功实现 IT 服务解决方案设计。Rational Software Architect 提供了行业领先的建模工具,支持 Object Management Group 的最新 SoaML 服务建模标准。

在第 1 部分中,我们介绍了 Rational Software Architect 7.5.4 及更高版本,还介绍了 Rational SOMA 2.9,这是一种统一的工具集和流程指南产品,可加速服务解决方案设计和开发工作。第 2 部分概述了流程指南内容,还特别介绍了 Rational SOMA 2.9 的特性。第 3 部分介绍了如何利用 Rational Software Architect 工具,构造使用业务流程建模符号(BPMN) 的业务流程模型,并展示了如何利用它们来构建一个简单的业务流程示例。

本文介绍了 Rational Software Architect 对于服务解决方案设计的支持,以及如何利用其功能来构建健壮的企业级服务模型。本文还讨论了 Rational Software Architect 如何支持企业加强业务部门与 IT 部门之间的协调。这是通过使用业务模型实现的,通过使用 Rational Software Architect 和其他 IBM 工具构建的,旨在促进服务发现和服务解决方案开发。

服务解决方案设计活动的工具支持

流程和表示概述

如第 1 部分和第 2 部分所述,Rational SOMA 2.9 是 IBM 服务解决方案设计的商业化方法,简单地来说,这种方法提供了识别和指定服务、制定服务实现决策的最佳实践。

服务识别是我们能从业务领域踏入 IT 领域的第一步。举例来说,面向业务的输入可能包括业务流程模型、业务职能模型、业务目标和业务领域目标。服务识别包括分析上述和其他输入,以便发现和描述 “候选服务”,即 IT 可为自动化业务而提供的能力。在 SoaML 中,我们将候选服务表示为一种能力 (Capability)(或者更精确地说,就是一个应用了 SoaML «Capability» 构造型的 UML 类)。

开始指定服务的第一步就是根据多种标准评估候选服务,确定其优先级排序,以便支持进一步的设计和实现。按照优先级排序后的候选服务集将作为其他服务指定活动的输入。

选定了需要指定的候选者之后,我们将制定架构和接口设计决策,以便更加正式、完整地描述将实现和实施的服务。这包括基本的接口定义,包括操作及其参数等,此外还包括服务的潜在提供者或消费者必须遵从或履行的其他任何约束或责任。在 SoaML 中,我们表示服务规范主要方式是利用 Service Interface(一种应用了 SoaML «ServiceInterface» 构造型的 UML 接口或类)。更为复杂的服务规范可能包括 Service Contract(一种构造为 SoaML «ServiceContract» 的 UML 协作),以便捕捉上述约束以及仅通过接口本身无法恰当表示的其他方面。

作为服务模型的一部分,我们将提供和/或使用服务的概念组件指定为 Participants(一种应用了 SoaML «Participant» 构造型的 UML 组件)。 ServicesRequests 是使用应用于 Participants 的 UML 端口表示的,并分别使用 SoaML «Service» 和 «Request» 构造型标记。Services 和 Requests 是使用服务接口或不定型的 UML 接口输入的。

制定服务实现决策仅包括确定如何使用运行时组件实现特定服务。可利用某些技术,包括利用 SoaML 的某些方面、基于 UML 的传统组件建模以及特定于技术的解决方案建模来记录这些决策。

支持该方法的工具

实践者可以利用 Rational Software Architect 中基于 OMG 发布的 SoaML 标准的服务建模特性以及其他 Rational Software Architect 功能,自动化其基于 SOMA 的 SOA 设计工作:

  • Rational Software Architect 的 SoaML 特性、它们与该工具的基于 BPMN 的业务流程建模功能的集成、以及通用的 UML 建模功能,帮助自动化 Rational SOMA 服务识别和指定活动;
  • Rational Software Architect 的 SoaML 支持、通用 UML 建模、特定于域的 JEE 和 .NET 解决方案建模,以及特定于域的部署拓扑结构建模均可用于帮助制定和记录服务实现决策。

SoaML 和 Rational Software Architect

Rational Software Architect 提供了 SoaML 配置文件(UML 扩展)以及其他特定于 SoaML 的工具。SoaML 支持是在 Rational Software Architect 7.5.4 中添加的,并在后续版本中得到了增强。这种支持与基于 BPMN 的业务流程建模支持相集成,本系列的第 3 部分重点介绍了这方面的内容。

使用 SoaML 进行服务建模

在这一节中,我们将在构建服务模型时引入服务建模和 SoaML。我们将利用上一篇文章中的业务流程模型作为服务识别的输入。随后介绍以此为基础的服务指定。

创建一个服务模型

在 Rational Software Architect 中,服务建模的第一个步骤是在项目中创建一个服务模型。我们将利用 Model 向导,在上一篇文章用于创建业务流程模型的相同项目中创建服务模型。如果您尚未处于 Modeling 透视图中,则应在此时打开这个透视图,方法是在 “Window” 菜单中选择 “Open Perspective > Other...”。随后在 “File” 菜单中选择 “New > Model Project”(或 “New > UML Model”)来调用 Model 向导。

在 Model 向导中(请参见图 1),选择通过标准模板创建新模型的选项,随后按下 “Next”。

图 1. Model 向导的第一页
Model 向导的第一页
Model 向导的第一页

在向导的下一页中(图 2),选择 “Services Modeling” 类别,随后选择 “Blank Services Model” 模板。(请注意,我们并未 选择 Software Services Profile,该选项已经弃用。)接受默认文件名 “Services”,确保目标文件夹设置为项目的 root 目录,随后按下 “Finish”。

对于比本文所演示的示例更严格的服务建模,可以在向导中选择 “Service Design Model” 模板,这是一个预先构造的模板,其中包含有关其使用方法的重要内部说明,还包括一组丰富的预定义模型构件块,可用于创建结构统一的服务模型。Rational SOMA 2.9 包含一组全面的工作指导,描述了如何使用这种模板构建服务解决方案模型。

注意:如果 “Services Modeling” 类别未列出,请尝试选中 “Categories” 列表下方的 “Show All Templates” 复选框。如果仍未出现在列表中,则或许您未安装用于 SOA 和 WebSphere 的扩展的服务建模特性,此时则需要首先完成安装,之后再继续操作。

图 2. Model 向导的第二页
Model 向导的第二页
Model 向导的第二页

此时,新服务模型的默认图 “Main” 应该在 BPMN 编辑器中打开。该图最初是空白的。此外模型本身 “Services.emx” 也会打开,但我们不需要编辑模型本身,因此将其关闭。此时的工作台应如图 3 所示。

图 3. 显示新服务模型的工作台
显示新服务模型的工作台
显示新服务模型的工作台

与服务相关的工作台元素

下面我们将简单介绍工作台的各个相关部分。

位于中间部分的一大块空白空间当然就是在模型编辑器中打开的新建(空白)服务模型。在进行服务建模时,我们的大多数工作都是在这里完成的。紧接其下的就是 Properties 视图(请参见图 4),此时该视图显示的是图本身的属性,原因是未选中任何内容。与往常一样,其中包含的属性无法一次性全部显示,因此左侧提供了选项卡,允许您选择感兴趣的属性类别。

图 4. 新服务模型图的 Properties 视图
新服务模型图的 Properties 视图
新服务模型图的 Properties 视图

编辑器的右侧提供了面板。除了 Service 折叠项之外,其他的内容都是我们在编辑 UML 模型中通常能够获得的项目。Service 折叠项在编辑服务模型时可用。它提供了执行服务建模时需要用到的大多数类型的元素。图 5 展示了展开 Service 折叠项之后的视图,使您能够看到全部可用元素。

图 5. 面板的 Service 折叠项
面板的 Service 折叠项

本文将构建的服务模型不会用到全部这些元素,因此这里仅做简单介绍,使您简单了解可以使用 SoaML 描述的各类内容。为了将尚未介绍到、但又必须提及的元素降至最少,我将按照与面板显示顺序不同的顺序介绍各个项目。

  • Capability 用于表示一个候选服务,如上文所述。面板提供了三种创建 Capability 的方法。
    • Capability 工具直接创建一个最初与其他任何建模元素都不相关的 Capability。
    • 如果我们确定了一个基于 BPMN 业务流程模型的服务(正如本文示例中所做的那样),那么选择 Capability from BPMN element 更为方便。这允许我们选择一个 BPMN Process、Lane 或 Task,据此创建一个新 Capability,其名称将基于所选内容,并且将包含根据所含或所选 Task 命名的操作。这还能自动创建从 Capability 链接回所选 BPMN 元素的可追溯性链接。
    • 如果我们使用 UML 活动图描述了业务流程,则选择 Capability from UML Activity 更为方便。这允许我们选择一个 UML Activity、Partition 或 Action,据此创建一个新 Capability,并根据所含或所选 Action 为其命名。这还能自动创建从 Capability 链接回所选 Activity 元素的派生链接。
  • Service Interface 用于描述一项服务的接口,包括其提供的操作以及(可选的)服务消费者 必须提供的操作。
    • 如果服务提供了操作,但不需要其消费者提供任何操作,我们将使用 Service Interface (simple)。简单服务接口是基于 UML 接口的。
    • 如果服务同样需要服务的消费者 提供一种或多种操作,例如用于支持异步通信,则应使用 Service Interface (collaborating)。协作式服务接口是一个 UML 类。类似于简单服务接口,它同样指定了服务将提供的操作,但同时也指定了它将利用其他接口来实现这一目标,从而指定服务的消费者 必须提供的操作。
    • 如果我们希望根据 BPMN 元素创建一个服务接口,同时避免创建 Capability,则应使用 Service Interface (simple) from BPMN elementService Interface (collaborating) from BPMN element。本文中未涉及到相关内容。
  • Expose 用于创建从服务接口到其代表的 Capability(或多个 Capability)的 SoaML Expose 关系,以便保持可追溯性。后文将介绍,Rational Software Architect 提供了可为选定 Capability 生成服务接口和 Expose 关系的工具。
  • Service Contract 用于帮助指定服务接口本身无法为其捕捉某些更为复杂的约束或责任的服务。Service Contract 通常包含多个部分,按照服务接口或者 UML 接口分类,代表服务潜在参与者所扮演的角色。Service Contract 也可能包含描述角色交互方式的 UML 行为。例如,Service Contract 可包含一个 UML Interaction,其 Lifelines 代表潜在的参与者。可以为其定义消息序列,表明所需(有效)的操作顺序。
  • SoaML Message Type(基于 UML Data Type、Class 或 Signal)或 UML Data Type 用于指定服务消息,代表将在服务参与者之间传递的数据。
  • Participant 表示将提供和/或使用服务的组件。如果我们正在直接通过业务流程元素创建 Participant,则使用 Participant from BPMN element 较为方便。
  • Agent 是 Participant 的推广,可定义 “一种能够适应其环境并与其环境交互的自治实体的分类” [SoaML 规范,第 50 页]。更多详细信息请参见 SoaML 规范的 §7.1.2。本文中的示例未使用 Agent。
  • Participant 分别通过 ServiceRequest Port 提供或使用服务。Service 或 Request Port 的类型由服务接口或简单 UML Interface 确定,用于表明以怎样的方式参与了哪些服务。Participant 可有随机数量 Services 和 Requests。
  • 我们可以为 Service 或 Request Port 添加一个 Provided InterfaceRequired Interface。这将为该端口的 Service Interface (type) 提供或使用的服务添加一个接口。
  • Service Channel 代表一个 Request 与一个 Service Port 之间的连接,服务操作通过此连接调用。举例来说,UML 复合结构图中出现的 Service Channel,用于演示如何在运行时连接一组服务的元素。
  • Services Architecture 是一种构造型的 UML 协作,描述一组 Participant 如何协力共同实现更高级的 Participant 或某种类型的流程(通常是业务流程)。

服务识别

在服务建模的第一步中,我们将识别部分候选服务,并将其表示为 SoaML Capability。为了保证井井有条,我们希望为它创建一个包。我们将使用 Services 模型中的 Main 图作为所创建的包的概览,因此编辑此图,将一个新 Package 拖放到其中(从面板的 Class 折叠项中),将新 Package 命名为 “Candidate Services”。 这也在新 Package 中创建了一个图,为明确起见,我们将其名称从 “Main” 更改为 “Candidate Services”,如图 6 所示。

图 6. 新的 Candidate Services 包
新的 Candidate Services 包
新的 Candidate Services 包

在开始识别部分候选服务之前,首先让我们回过头来看看上一篇文章中构建的业务流程模型(图 7)。

图 7. 业务流程模型
业务流程模型
业务流程模型

某些候选服务是显而易见的。首先,我们注意到可能需要一项服务来根据 Order Processing Lane 中的 Order Received Start Event 来接收订单。因此在 Service Candidates 图中,使用面板 Service 折叠项中的 “Capability from BPMN element” 工具来创建此服务。在 Select Element 对话框中选择 Order Processing Lane,并设置所需的可追溯性链接选项(图 8)。单击 “OK”,接受默认名称 “Order Processing”。

图 8. Select Element 对话框
Select Element 对话框
Select Element 对话框

要确定可追溯性链接是否已创建,可选择 Capability,并选择 Navigate / To URL,提供 Order Processing Lane 的属性,以便将其显示在 Project Explorer 中(图 9)。

图 9. 转到可追溯性链接
转到可追溯性链接
转到可追溯性链接

我们需要一项表示处理事件的操作,因此为 Capability 添加一个操作,将其命名为 Receive Order。

可想而知,Order Processing 需要能够在其他三个 Lane 上调用请求,因此我们将为这三个 Lane 分别创建候选服务,各作为其自己的 Capability 中的一项操作。首先从 Production 开始。再次使用 “Create from BPMN element”,但这一次选择 Production Lane。这将创建一个名为 “Production” 的新 Capability(以及连接到 Production Lane 的可追溯性链接),但同时也会自动在该 Capability 内创建一个 Request Production 操作,因为 Production Lane 包含一个此名称的 Task。请参见图 10。

图 10. Production Capability
Production Capability

我们可以继续为 Finance 和 Shipping Lane 分别创建 Capability,结果将如图 11 所示。

图 11. 初始候选服务
初始候选服务
初始候选服务

再次观察业务流程,可以确定,我们需要对初始候选服务做出一些修改。

  • 在 Finance 中,可以看到 Prepare Invoice 属于将在内部完成的工作,因此无需为其提供操作,删除此操作。但我们需要为 Shipping 提供一个可调用的操作,以便为 Finance 提供货运价格,因此为其添加一个 “Receive Shipping Price” 操作。
  • 在 Shipping 中,删除 Price Shipping 操作,因为此操作是内部的。
  • 在 Order Processing 中,可以确定 Finance 和 Shipping 将需要一种方法来提供计价和发货计划,因此为其创建操作。

此后,我们将得到如图 12 所示的结果。

图 12. 修改后的候选服务
修改后的候选服务
修改后的候选服务

我们跳过了服务识别的一个重要部分,也就是识别可能需要利用的现有服务。这个简单的示例项目实际上是从零开始构建的,因此其中不存在现有服务。然而,在现实环境中,很少会出现这种不存在现有服务的情况。

现在,我们已经将传入的业务需求(如业务流程模型所示)表示为一组候选服务。这些候选服务代表在实现后能够满足需求并支持业务流程的 IT 能力。下一步是更加具体、准确地指定如何公开和使用服务。

服务规范

我们跳过了服务指定的第一步,也就是根据定义良好的一组标准来评估候选服务,随后利用这组标准来排列候选服务的优先级,并选择用于后续指定、设计和开发的候选服务。在这个简单的示例中,我们实际上为所有这些候选服务排列了优先级。但在现实环境中将需要做出基于优先级的选择。

作为开始,我们在 Services 模型中创建一个 “Specifications” 包(并相应地更改图的名称)。在 Main 图中,以良好的组织形式建立 Specifications 与 Candidate Services 包之间的依赖性关系,如图 13 所示。

图 13. Specifications 包
Specifications 包
Specifications 包

创建服务接口

首先观察 Order Processing Capability,可以看到此处实际上有两种类型的操作。Receive Order 操作与另外两项操作存在着根本的差异,因为前者将对外公开(至少是在概念上),而后者则仅供企业内部使用。因此,我们决定将这些操作表示为两种不同的接口。

首先,我们将创建对外公开的接口。在创建服务规范时保持候选服务可见是非常有帮助的,因此,将 Order Processing Capability 从 Project Explorer 拖放到 Specifications 图中。 现在,可以选定它,从其上下文菜单中调用 Add Services Modeling > Service Interface (simple)。将其命名为 External Order Processing。请注意,我们也获得了服务接口与用于创建它的 Capability 之间的 SoaML Expose 关系。这提供了这个阶段的可追溯性链接。同样,重命名其他操作,使之更好地反映我们的 IT 命名标准。通过相同的方法,我们还创建了一个名为 Internal Order Processing 的服务接口,其中包含另外两项操作。如图 14 所示。

图 14. 与订单处理相关的服务接口
与订单处理相关的服务接口
与订单处理相关的服务接口

这里,我们为 Capability 采用了不同的外观,以便明确表示它是在不同的包中定义的,仅为提供上下文之目的包含于此图之中。

另外三个 Capability 仅在内部使用,因此更为简单。为这三个 Capability 分别创建一个服务接口,如图 15 所示。

图 15. 全部服务接口
全部服务接口
全部服务接口

请注意,可能有人会提出不同意见,例如,Shipping Service Interface 中的操作应该处于独立的接口之中,因为需要使用它们的实践者是不同的。又如,Order Processing 需要 requestShipping(),但不需要 scheduleShipping()。将两个操作置于同一个服务接口中意味着我们不具备为其设计独立提供者的灵活性。也可能有人对 Finance 中的操作提出类似的不同意见。在本例中,为简单起见,我们不会包含这方面的内容。

创建服务数据

我们了解,服务操作需要来回传递数据以便完成工作。有些时候,业务流程模型已经包含了某种类型的数据定义,尽管通常仅仅是一些极高层面的业务术语。本例中的模型并不包含定义,因此我们必须从零开始。

首先,在将用于创建数据定义的 Specifications 包中定义一个 Data 包(图 16)。

图 16. Data 包
Data 包

作为开始,可以看到 receiveOrder() 需要通过某些内容来表示所接收到的订单。我们将为此使用 SoaML MessageType (Class)(在面板 Service 折叠项的 Message Type 中可以找到此项),将其命名为 “Order”。随后为其添加已知的必要属性(图 17)。

图 17. Order 消息类型
Order 消息类型
Order 消息类型

真实、健壮的服务数据分析和建模是此过程的关键组成部分,但这些内容超出了本系列文章的讨论范围。但为完整性起见,我们假设已经指定了这些服务所需的全部数据类型,如图 18 所示。

图 18. 数据指定
数据指定
数据指定

完成服务接口

既然已经指定了数据,我们就需要为使用这些数据的服务接口的操作添加参数。完成后,即可得到如图 19 所示的结果。

图 19. 完成后的 Service Interface
完成后的 Service Interface
完成后的 Service Interface

创建 service contract

假设我们希望指定必须按照特定顺序调用服务操作。一种方法就是创建一个 Service Contract,在其中包含 UML 交互与序列图,指定允许的顺序。

为了创建 Service Contract,可使用面板的 Service 折叠项内的 Service Contract 项。将新的 Service Contract 命名为 “Ordering Contract”。随后可以在 Project Explorer 选定它并打开上下文菜单,选择 Add Diagram > Sequence Diagram。 将新的交互与序列图分别命名为 “Ordering Interaction” 和 “Ordering Sequence”(图 20)。

图 20. 带有一个交互和一个序列图的 Ordering Contract
带有一个交互和一个序列图的 Ordering Contract
带有一个交互和一个序列图的 Ordering Contract

我们希望为各服务接口创建一个 Lifeline,以便利用它们来显示操作的执行顺序。一种便捷方法就是在 Project Explorer 中选择 Service Interfaces,将其拖放到我们的序列图中。这种做法的一种不错的附加效果就是将在类型为 Service Interface 的 Ordering Contract 内为各服务接口创建一个属性。每个 Lifeline 都对应于(表示)一个属性。

5 条 Lifeline 使序列图的标题较宽,因此整个图的宽度也较大。可以采取一些措施来将其减小到更易管理的尺寸。首先,在图中选中全部 5 条 Lifeline,在 Properties 视图的 Appearance 选项卡中,选择 “Show Stereotype” 组中的 “Decoration” 单选按钮。这将删除构造型名称( “«ServiceInterface»”),将宽度适当缩短。请注意,这仅影响 Lifeline 的外观,而不会实际删除构造型的应用。另外,我们还可以删除各 Lifeline 的名称。由于每种类型的 Lifeline 仅有一个,因此无需借助名称即可轻松加以区分。在删除名称后,我们将得到类似于图 21 所示的结果。

图 21. 序列图中的 Lifeline
序列图中的 Lifeline
序列图中的 Lifeline

接下来即可按照希望指定的顺序绘制事件。首先,External Order Processing 角色接收到一笔订单。为了绘制这个事件,可将光标置于图左边缘附近,等待连接器手柄出现,拖动绘制一条连接到 External Order Processing Lifeline 的线条,单击 Asynchronous Message,随后双击 receiveOrder() 操作。图 22 显示了这一系列操作。

图 22. 绘制一个消息事件
绘制一个消息事件
绘制一个消息事件

随后按照所需顺序绘制其他消息事件,使用 Parallel Combined Fragment 显示可能存在的并行性,绘制完成后应如图 23 所示。

图 23. 完成的序列图
完成的序列图
完成的序列图

将此 Interaction 置入 Service Contract 意味着:除了实现对应于其角色的服务接口指定的操作之外,服务的任何参与者都必须遵从此 Interaction 指定的顺序。举例来说,担任 Finance 角色的参与者不能在调用 initiatePricing() 和 receiveShippingPrice() 操作之前调用 Internal Order Processing 参与者上的 receiveInvoice() 操作。

至此,我们已经完成了服务的全部指定。

服务实现

现在我们已经准备好制定决策,确定参与者将有哪些、它们将如何连接在一起以便实现可正常工作的系统,从而确定服务的实现方式。在 SoaML 中,我们使用 Participant 来建模一个将提供和/或使用一项或多项服务的组件。首先,我们将创建一个与 Specification 包存在依赖关系的 Realization 包(图 24)。

图 24. Realization 包
Realization 包
Realization 包

首先,我们确定需要通过相同的 Participant 实现 External Order Processing 和 Internal Order Processing 服务。在实现图中,我们使用面板 Service 折叠项中的 Participant 条目来创建一个 Participant,将其命名为 “Order Processing”。随后选定该 Participant,并从其上下文菜单中选择 Filters > Show External View。这将允许我们添加和查看其边框周围的端口。随后使用 Service 面板项,将该面板项拖放到其边框上,为其添加一个 Service Port。在您进入正确的 “放置区域” 时,Participant 的边框将突出显示。创建 Service Port 时,我们需要回答希望使用哪种 Port 类型。选择 Select Existing Element,随后选择 External Order Processing Service Interface。最后,输入 “ordering” 作为 Port 的名称。图 25 显示了这一系列操作及结果。

图 25. 创建一个 Service Port
创建一个 Service Port
创建一个 Service Port

我们确定同时希望此 Participant 提供 Internal Order Processing 服务,因此添加第二个 Service Port,将其命名为 “internal”。还需要为所用的其他各服务接口提供 Request Port:Finance、Shipping 和 Production。

我们将创建另外三个 Participant,如下所示:

  • Finance Department Participant 将具有一个类型为 Finance Service Interface 的 Service Port。它还有一个类型为 Internal Order Processing 的 Request Port,因为它需要调用一项操作。
  • Production Department Participant 将具有一个类型为 Production 的 Service Port 和一个类型为 Shipping 的 Request Port。
  • Shipping Department Participant 将具有一个 Shipping Service Port、一个 Finance Request Port 和一个 Internal Order Processing Request Port。

完成上述工作并略加整理之后,结果将如图 26 所示。

图 26. 各 Participant
各 Participant
各 Participant

我们还希望显示这些 Participant 在运行时是如何彼此连接以便实际完成其工作的。为此,在 Project Explorer 中选择 Realization 包,再从其上下文菜单中选择 Add Services Modeling > Participant,从而为 Realization 包添加另一个 Participant。我们将其命名为 “Ordering”。随后选定 Ordering Participant,并从其上下文菜单中选择 Add Diagram > Composite Structure Diagram,从而为其添加一个复合结构图。同样将此图命名为 “Ordering”。

首先,为其添加一个 Service Port,将类型设置为 External Order Processing Service Interface(图 27)。

图 27. 带有 Service Port 的 Ordering 结构
带有 Service Port 的 Ordering 结构
带有 Service Port 的 Ordering 结构

可以直接将 Project Explorer 中的各 Participant 拖放到 Ordering 结构图中,以此为结构添加多个部分(表示 Participant)。这将为各 Participant 添加一个部分,并相应地设置其类型。请参见图 28。

图 28. Ordering 结构及其部分
Ordering 结构及其部分
Ordering 结构及其部分

现在,我们需要创建 Service Channel,以便显示 Participant 的 Port 是如何连接在一起的。首先,将 external ordering Port 连接到结构中 order processing 部分的对应端口。为此,将鼠标指针放在 external Port 旁边,按住对外连接手柄,将其拖放到 order Processing 部分的 ordering port 上,随后从可用连接列表中选择 Service Channel。图 29 展示了这一系列操作。

图 29. 绘制一个 Service Channel
绘制一个 Service Channel
绘制一个 Service Channel

现在,我们确定所需的另一个 Service Channel 连接,在此过程中重新排列布局,随后将得到如图 30 所示的结果。请注意,我们隐藏了 Service Channel 上的 «ServiceChannel» 标签,以便使图示更加简洁明了。

图 30. 完成后的 Ordering 结构
完成后的 Ordering 结构
完成后的 Ordering 结构

结束语

在这篇文章中,我们介绍了构建使用 SoaML 的服务模型的 Rational Software Architect 工具。首先,我们简单解释了用于服务识别和服务指定的服务建模、通常选择使用它的用户(及原因)、它如何适应整体流程。随后概述了 Rational Software Architect 支持的服务建模元素。最后为您展示了如何利用服务建模工具来构建一个小型服务模型,在其中包括一些候选服务、一些服务规范以及可能的实现。

后续内容

第 5 部分是本系列的最后一篇文章,其中将介绍使用 Rational Software Architect 构建的服务模型可如何加速有价值的服务解决方案工件的创建。这篇文章还特别侧重介绍了如何利用服务模型来创建 SCA 相关内容。


相关主题

  • BPMN(业务流程建模符号)是 Object Management Group 提出的一种标准,指定了一种描述业务流程的符号。
  • SoaML(面向服务架构建模语言)是 Object Management Group 的一种规范。SoaML 定义了描述和指定面向服务系统的符号和元数据模型。
  • 观看包括两部分内容的系列视频 使用 Rational Software Architect 8.0 进行业务流程建模和 SOA 设计
  • 要了解更多关于 SOA 和服务管理的概念,请阅读 Bobby Woolf 的 developerWorks 文章 SOA 治理简介
  • 要了解更多关于 IBM Global Business Service 的专有服务设计与开发方法,请阅读 SOMA:开发面向服务解决方案的一种方法
  • IBM 现在已经以高度可分拆和可分离采用的形式发布了它的商业最佳实践方法内容。请访问 developerWorks 的 IBM 最佳实践方法页面 以了解更多关于我们的实践方法的信息。
  • IBM Redbook “使用 Rational SDP 构建 SOA 解决方案” 是 Rational SOMA 中具体服务设计方法的主要灵感来源之一。该 Redbook 的最后一次更新时间是 2008 年,因此其中演示的工具有些过时。尽管如此,这仍然是您的 “书架” 中必备的一份出色的服务设计资料。
  • Rational SOMA 2.9 中使用 SoaML 的大量服务建模方法均借鉴自 Jim Amsden 包含五部分的 IBM developerWorks 系列文章 “使用面向服务架构建模语言 SoaML 进行建模”。
  • 访问 OASIS 服务组件架构(SCA)站点,进一步了解使用广泛的实现和运行时技术创建服务组件的这些开放行业规范。
  • 下载 Rational SOMA 2.9。 这是 IBM 服务解决方案设计的商业化最佳实践内容。该 URL 指向 Rational SOMA 2.9 的预发布评估版本和一份可以使用 Rational Method Composer 发布的完整版本。Rational SOMA 也作为一种 Process Advisor 配置产品,随包含服务建模工具的 Rational Software Architect 8.0 及更高版本的各种变体提供。
  • 下载 Rational Software Architect for WebSphere Software 的试用版。 如果可以,我们建议您选择 8.0 或以上版本。要体验 Rational Software Architect 增强的服务解决方案功能,您需要使用 7.5.4 或以上版本。如果您下载了版本 7.5,则请使用随 Rational Software Architect 一起安装的 IBM Installation Manager,以便升级到产品的最新版本,也就是 7.5.x 系列版本。

评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=742027
ArticleTitle=设计和开发更高效的 SOA,第 4 部分: 使用 Rational Software Architect 和 SoaML 构建并管理您的面向服务解决方案的设计
publish-date=07212011