SOA 的概念、产品平台已经广为业界所接受，SOA 适用的业务范围以及可以给业务带来的益处也广为宣传，但是一个项目如何用 SOA 的方法来做业务分析、架构设计到编码实现、测试上线却是很多客户所困惑的事情，包括一些应用开发厂商。大家都知道 SOA 的架构设计和传统的 J2EE 架构设计不一样，开发过程也不一样，比如客户最想知道的一个问题：服务是如何抽取的，什么样的颗粒度是合适的。本系列文章以假定的业务为样例来回答上述问题，通过一个较为真实的例子带读者走一遍 SOA 的开发历程，也从中深刻体会 SOA 的开发和传统开发的不同之处，掌握 SOA 开发的基本要领。

本文将向您介绍如何使用 RSA（Rational Software Architect）和 SOMA-ME（Service Oriented Modeling and Architecture-Modeling Environment）工具，并通过对 第 1 部分 中业务流程的进一步分析，进行服务识别、确定服务规约、进行架构设计。

前言

本系列 第 1 部分 向您介绍了如何使用 WebSphere Business Modeler 来描述业务流程。本文是第 2 部分，将向您介绍如何使用 RSA（Rational Software Architect）和 SOMA-ME（Service Oriented Modeling and Architecture-Modeling Environment）工具，通过对该业务流程的进一步分析，进行服务识别、确定服务规约、进行架构设计。希望能帮助读者体会业务梳理过程中服务抽取的过程和一般技巧。

建模工具简介

IBM Rational Software Architect（RSA）是使用标准 UML 语言的建模工具（其前身就是赫赫有名的 Rational Rose），我们通常可以用它来设计和构建业务应用模型，甚至可以开发应用本身。RSA 具有开放的产品架构，只要安装各种模型插件，就可以识别并构建出各种不同的模型。读者如果有兴趣，也可以自己创建一个模型插件。

Service-Oriented Modeling and Architecture（SOMA）是一种面向服务的设计方法，使用 SOMA 的设计视角和建模过程，我们可以方便地构造出面向服务架构的应用，SOMA 通常也被认为是目前设计 SOA 应用的最佳方法。

IBM 在 RSA 上开发了一套基于 SOMA 方法论的插件，称为 SOMA-ME。安装到 RSA 上以后就可以方便地构建 SOA 应用了。

接下来我们将向您简要介绍如何设置建模环境。

建模环境设置

首先，安装 RSA 7.0 并打最新的补丁（笔者使用的是 fix pack 8），下载地址为 http://www-01.ibm.com/support/docview.wss?rs=2044&context=SSCM72&dc=D400&uid=swg24020744&loc=en_US&cs=utf-8&lang=en。注意，在安装补丁之前 Installation Manager 必须升级到版本 1.2.1 以上。

接着，下载 SOMA-ME，笔者使用的版本是 3.1.1。按照安装说明在 RSA 的菜单中选择“Help”->“Software Updates”->“Find and Install...”，在弹出菜单中选择“Search for new features to install”，点击“New Archived Site”将 SOMA-ME 的安装介质（SOMA-ME-3.1.1.v20080702.zip）添加进来。

然后，选中所有的 Feature，接受许可证协议并开始安装。在随后的第一次启动 RSA 可以用 -clean 选项清除缓存的配置。

最后，创建一个 UML 项目，在其下创建一个 UML Model，选择“SOMA Service Model”，RSA 会自动创建出一个 SOA 项目的框架（如图 2）。

业务流程分析

业务场景介绍

我们在第 1 部分已经介绍了一个大致的业务场景，但对于服务设计来讲，那些描述还不够精细，根据与客户的进一步交流，我们将完整详细的业务流程描述如下。

1. 基本上，业务流程中涉及收费方（Payee）应用、支付方（Payer）应用、支付平台（PP：Payment Platform）、计费系统（Billing）和特约银行（Bank）五个部分。它们的时序图（Sequence Diagram）如图 3。
2. 其中，收费方（Payee）和特约银行（Bank）是外围系统，业务从支付方发起，它包含了用户登录过程及支付的 UI 界面，以及业务相关的内容。我们在系统设计中关注的是支付方（Payer）、支付平台（PP）、计费系统（Billing）三个部分。
3. 支付平台（PP）是作为用户支付的一个通用支付实现，其设计时以通用性为基本目标。即支付平台今后可以接入多种支付方应用，其复杂的计费规则交由计费系统处理。
4. 计费系统（Billing）以支付引擎（PP）的交易为依据，对用户享受的服务进行费用计算，其中费用计算可能有比较复杂的运算规则，例如包月、每笔交易收费、及满足一定条件的打折优惠等等。计费规则大致可以分为按客户类型、按服务流量、按支付金额、按优惠条件计算。

业务流程描述

如果我们将流程中主要的调用关系和时序列出来，可以得到下图（红线为系统边界）。

1. 用户登录支付方应用（Payer）系统，Payer 进行认证授权；
2. 用户在支付方应用（Payer）中选择一笔税单进行支付；
3. 支付方应用（Payer）根据用户选择的税单记录日志、生成支付请求报文并发送到支付平台（PP）。报文包括：金额，银行信息，税单等；
4. PP 检验接收到的支付请求，进行落地（Log）、校验、换签等一系列处理，登记交易流水。PP 的功能：Log、换签、业务处理、检查金额是否正确、路由；
5. PP 通过路由选择将最终的请求报文发送到对应银行；
6. 银行进行对应业务处理；
7. 银行将处理结果发送给 PP；
8. PP 进行落地、校验、换签等一系列处理；
9. PP 根据处理结果进行计费，计费系统（Billing）根据规则可能冻结用户。计费系统（Billing）检查是否欠费，如果欠费，通知支付平台；
10. PP 通过路由选择将最终的应答报文发送到原来的支付方应用（Payer）；
11. Payer 根据应答报文进行业务处理，通知支付方核销。

如何进行服务识别

以上是一段典型的客户业务描述，尽管并不严格，但大致可以看出业务的处理过程。事实上，即便是客户认为描述完整的业务流程，在用 SOMA 方法仔细梳理的过程中，仍会发现大量需要补足的地方。

根据 SOMA 方法论，服务的识别过程可以从多个角度去分析，但这类以流程为主的业务，如果从流程梳理入手来识别服务也许最直接。

定义流程和任务

我们首先创建一个服务流程（Process），不妨叫“B2B 支付流程”，这是一个总的业务流程。在“B2B 支付流程”下可以为流程中的四个主要的业务环节分别创建子流程（Process），分别叫“Payer_ 单笔税单支付流程”、“PP_ 支付流程”、“B_ 记费流程”。

根据前面的流程描述，我们逐个梳理出整个流程中的子流程和相关任务。注意，任务在流程描述中通常表现为一个动宾结构的词组，比如“检查欠费”、“计算费用”、“记录日志”等等。同时，我们也得到四个业务实体（Business Entity），它们通常在流程描述中表现为一个独立的名词，比如：“税单”、“金额”、“银行信息”、“销户通知”等等。

确定候选服务

假定我们认为对所有的任务和实体都有可能成为服务，则选中它们，右键点击“SOMA Identification”“Create Candidate Services”，这样会在 Service Portfolio 文件夹中添加相应的候选服务，如下图。除此之外，根据需求描述中缺失的部分，我们也可以手工添加需要的候选服务。比如：计费规则可以分为按客户类型、服务流量、付费方式、优惠条件等等，这意味着有“获取客户类型”、“使用优惠规则”、“获取付费方式”、“获取流量”等候选服务。

事实上，由于客户的业务描述往往在一开始是不清楚或是有遗漏的，候选服务很可能会在后继阶段才被发现。好在 SOMA 本身是一个迭代的分析过程，任何时候发现需要添加服务时都可以返回到服务识别阶段添加候选服务。

业务实体可能存在一定的包含关系，比如“金额”也许包含在“账户信息”或“税单信息”中，这可能会引起业务实体或候选服务的归并。把握实体颗粒的大小往往是灵活性和复用性之间的平衡。

挑选对外服务

候选服务包含对内的服务和对外的服务，所谓对外的（Exposed）服务就是有严格的对外接口，可以被外界调用的服务。通常情况下，我们推荐将对外服务以 Web Service 方式实现。

在菜单中选择“Window”->“Show View”，在“SOMA-ME”中选择“Service Litmus Test”，经过对每个候选服务多方面的打分测试（SLT）后，得出是否对外暴露（Exposed）调用接口的结论。如图 7。

凡是对外服务都会自动添加到 SOMA 的对外服务（Exposed Services）文件夹中，考虑到实施上的方便性，我们将一些相关性强的服务归并后形成组合式服务（Composite Service），如下图，我们图中右侧列出了组合式服务中的内容。此外，我们假定特约银行有一个已经存在的服务（Bank_ 扣款）。

服务模型设计

确定服务规约

根据需求描述的上下文，为每一个对外服务设计服务规约（Service Specification）。比如：为“换签”服务设计输入和输出属性（InputSignature 和 OutputSignature）和调用端口（port）。

注意：服务名称往往是一个动宾结构的词组（比如“查看余额”），其中的宾语部分很可能可以成为服务的输入和输出参数。此外，前面分析得到的业务实体（Business Entity，比如“税单”）可以转换成一个独立的服务（比如“获得税单”），也可以成为服务的一个调用参数。所有这些参数，大多会以类（Class）的形式组织起来。

设计服务调用关系

一旦服务规约确定后，可以根据流程描述尝试将服务串接起来。这时可能会发现控制类的服务缺失，也可能发现原先设想的接口不一致，或者相互调用的服务之间的规约不匹配等等。反过来，又会调整对原先服务的设计。

假定我们发现需要在支付平台（PP）和计费系统（Billing）分别增加一个逻辑控制的服务，这时可以手工在服务组合（Service Composition）文件夹中添加。

设计服务组件与子系统

最后，我们设计服务组件和子系统。由于本例业务过程中，各业务模块之间的界面非常清楚，所以我们可以直接将各业务模块设计为服务组件。每个服务组件应该含有多个组件，我们用组件结构图（Structure Diagram）来表现组件之间的关系。其中，对外的接口可以定义多个 port（，port 实质上代表了一组功能，其上可以定义多个 Provided Interface（）和 Required Interface（），无论哪一种 Interface 都需要定义一个本地的 Java Class（比如：Logging），但这两种 Interface 可以共享一个全局的 Java Interface（比如：ILogging）。

由于篇幅关系，我们只列举了 PP_ 支付平台的服务组件图。每个服务组件也有对外的端口（概念与服务端口类似），我们只需要引用服务的端口即可。最后，将所有的业务组件拼在一起就完成了整个业务流程的结构图。

小结

SOMA 建模是面向服务架构（SOA）设计的重要的方法论，它可以帮助我们从冗长的客户业务场景描述中分析出最基本的颗粒（服务），以及这些服务之间的关系。基于此，我们可以进一步构建服务组件与子系统，一个 SOA 应用框架就呼之欲出了。

从本质上讲， 流程建模 是一种过程分析的方法，而服务建模是一种对象分析的方法。两种方法都是从不同的角度看待客户业务场景，相互结合的效果使 SOA 设计既能抓住本质，又能贴近现实，既保持灵活，又易于落地。

参考资料

• 查看本系列 第 1 部分：使用 WebSphere Business Modeler 进行业务建模。
• Rational Software Architect for WebSphere Software：为您提供面向架构师和设计人员的 RSA 技术参考资源。
• developerWorks 网站 SOA and Web services 专区：为您提供更多关于 SOA 及 Web 服务的文章、教程等最新技术资源。
• developerWorks 网站 Rational 专区：Rational 软件交付平台的技术资源与最佳实践。
• SOA 中的服务接口设计最佳实践，第 1 部分: 探索服务的开发、接口和操作语义 ：重点讨论服务接口设计的最佳实践，包括有关开发方法、服务粒度以及操作签名方面的概述。
• SOA 实现：服务设计原则 ：通过将这些原则应用到面向服务的体系结构设计，可以帮助通过 IT 灵活性实现业务灵活性远景。

• 下载软件 Rational Software Architect V7.0，安装建模工具。
• 下载软件 Rational Software Architect for WebSphere Software V7.5 试用版。
• 下载软件 RSA Fixpack 8，更新建模工具。
• 下载软件 SOMA-ME 插件，设置 SOA 建模环境。
• 更多 IBM 试用版软件下载。