SOA 的概念、产品平台已经广为业界所接受，SOA 适用的业务范围以及可以给业务带来的益处也广为宣传，但是一个项目如何用
SOA 的方法来做业务分析、架构设计到编码实现、测试上线确是很多客户所困惑的事情，包括一些应用开发厂商。大家都知道
SOA 的架构设计和传统的 J2EE 架构设计不一样，开发过程也不一样，比如客户最想知道的一个问题：服务是如何抽取的，什么样的颗粒度是合适的。
本系列文章以假定的业务为样例来回答上述问题，通过一个较为真实的例子带读者走一遍 SOA 的开发历程，也从中深刻体会
SOA 的开发和传统开发的不同之处，掌握 SOA 开发的基本要领。在这过程中，充分使用 IBM 的
SOA 工具一步一步实施，让读者最终可以重现此 SOA 的开发过程。
本系列文章，共分为 4 个部分，本文为第 1 部分，将向您讲述业务建模，即如何从一个具体需求开始，使用
IBM 的 SOA 建模工具 WBM(Websphere Business Modeler) 进行业务建模。第
2 个部分是服务建模和架构设计，以业务建模为输入，通过 RSA(Rational Software Architect)+SOMA-ME(Service
Oriented Modeling and Architecture--Modeling Environment)，进行服务识别、确定服务规约，进行架构设计。第
3 部分介绍如何使用 WID(Websphere Integrated Developer) 进行开发，从
WBM 导入业务建模，生成开发的粗框架，然后具体编码实现，并进行单元测试和系统测试。第 4 部分，这是一个示例项目用
SOA 方法进行实施，总结实施中的一些经验。
本文的业务案例是支付平台的业务，也即支付方通过支付平台支付费用，如水电煤费之类的费用。支付平台根据请求到银行扣款，然后根据一定的规则收取支付平台费用，最后向收费方核销费用。
这个业务是个常见而典型的业务。业务流程如下：
图 1. 业务流程
以下为图中每个节点的业务功能介绍：
1、用户登录缴费平台，选择一笔费用进行支付，提交请求，触发支付流程，进入流程节点报文处理，缴费平台的缴费要求和支付平台的报文处理之间通过
JMS 绑定。
2、流程进入支付平台，对进入的报文进行处理，曝光记录日志，从支付请求报文中提取数据，把支付相关信息写入数据库。
3、支付平台将支付请求发往银行，和银行之间通过 MQ 通讯，把报文发给指定的 MQ 队列，异步等待另外一个
MQ 的银行报文回复
4、银行响应，支付平台接收银行回来的报文，通过 MQ 绑定此节点输入
5、报文处理，支付平台处理已接收到的回复报文，如更新银行支付信息的数据库
6.1、对这笔支付进行计费，如果交易成功，则按如下的规则进行计费
计费业务规则：
根据客户代码 PAYER_NO 的值，确定是哪类客户：包月客户，按次客户，按交易量客户
如果是包月客户，不计费
如果是按次客户，计费一次，一次收费 0.5 元
如果是按交易量计费，则交易金额低于 10000，收费 1 元，交易金额大于 10000，收费 2 元，更新计费表，在数据库中提交交易费用，记录交易流水。
6.2、支付响应，支付平台给缴费系统回应是否支付成功。
7、支付核销，缴费平台把核销的报文发送给收费方做费用核销。
IBM WebSphere Business Modeler ( 简称 WBM) 是一个简单易用的业务过程建模工具，除了可以对流程建模，还可以对业务规则建模、对业务数据建模，WBM
是非系统设计的数据建模，对于系统设计阶段的数据建模，可以用 Rational Data Architect
建模
在业务建模中，业务数据建模是个比较关键的步骤，业务人员做需求分析的时候，把业务流程流经的每个节点的业务数据梳理出来，很形象的来说就是一个业务表单，要做这个业务，需要哪些业务信息。
本文 WBM 的版本是 V6.1.2。
在 WBM 中建立项目文件
打开 WBM，选择菜单 -> 文件 -> 新建 -> 项目 ->Websphere
Business Modeler-> 业务建模项目。输入项目名称及缺省流程名称，点击下一步。选择泳道布局
-> 点击完成。
建立业务数据项
接下来建立业务数据项。通过 WBM 建立的业务数据模型，称为业务项。
在项目树下，点击业务项，右键 -> 新建 -> 业务项。如下图：
图 2. 支持请求数据项
比如这个业务里面的支付请求业务项 PAY_REQUESR，业务上会包括：
交易代码
交易序列号
请求时间
支付者编号
支付者银行帐号
支付的业务类型
支付的笔数
支付的总金额
记账日期
支付的详单（注，业务上可以一次支付多笔业务，每笔业务有一个详单）。
分别输入各个业务项的属性和类型，每个业务项的属性均可以输入属性描述，便于对数据项业务含义的理解。还可以添加业务项的说明文档。
再分别完成请求回复的业务项 (PAY_RESPONSE)、计费业务项 (CHARGEBO)、核销信息
(HEZHU)、计费项（CHARGEITEMBO）。在实际架构设计中，这些业务项就是数据架构设计的原型，在详细的数据架构设计中，会针对
IT 的需要增加一些字段。
WBM 的业务数据建模支持数据类型的嵌套和数组的定义，如 PAY_REQUEST 中就包含有 PAY_DETAIL
的数据结构数组。数据项即可以通过 XSD（XML Schema Definition，XML 纲要）导入。
这个业务有典型的业务流程，有严格的执行顺序，虽然主要是自动流程，但也可以引入人工流程做异常处理。
用 WBM 建模，可以把业务模型直接导入开发环境，这样一方面可以重用业务模型，不需要重新编排业务流程，另外一方面也消除了
IT 人员重新画业务流程和业务人员的流程上理解不一致带来的差异，也即消除了业务模型到 IT 模型的沟壑。
WBM 支持泳道形式的业务流程建模，也支持自由形式的流程建模。考虑到泳道形式的业务流程更易于理解，我们用泳道方式对支付业务建模。
先定义泳道，可以有多种方式划分泳道，如角色、资源、分类、位置、组织架构单元等。在本示例中，都是自动流程，我们按不同的角色的方式划分，如按下图方式定义角色：
根据业务需求定义了 5 个：
计费系统
支付平台
缴费系统
银行
收费方
如下图，在项目树下，点击资源 -> 右键 -> 新建 -> 角色，输入角色名称，重复其他
4 个角色的定义。
图 3. 泳道按角色定义图
下面定义流程的每个节点，以第一个节点—支付请求为例，从 WBM 的选用板中拖一个任务到缴费系统的泳道，点击属性，在常规标签中输入名称支付请求。
定义一个业务节点，除了要描述业务实现的功能，还要定义完成此业务所需要的业务项，和完成以后可以提供给下一步的业务项。点击属性的输入标签，点击添加，点击关联数据右端，弹出类型选择，选择业务项
->PAY_REQEUST，输出也是 PAY_REQUEST。
如果是人员任务，还要定义组织架构，任务以什么方式分配到什么角色或是资源，任务在什么情况下进入升级处理，如任务没有人去声明处理，或是处理时间超时等进入升级，进入升级后的通知操作，以
Email 还是任务项的形式通知什么人去处理。
图 4. 编排业务流程
逐个定义业务流程的每个活动项，并用合适的连线连接。
图 5. 业务流程图
如上图，为最终的 WBM 的流程建模。图中每个节点的输入输出都会显示。
在业务中，计费是按照规则计费的。有 2 个规则，一个是客户分类规则，另一个是计费规则。WBM 可以对业务规则进行建模，和
WID(Websphere Integration Developer) 的规则建模类似。WBM 可以先建一个规则模板，然后再模板上再实例化为业务规则，也可以直接建立业务规则。通过模板的方式建规则，是个很好的规则重用方式。
对于第一个规则：客户分类，是按照 PAY_REQUEST 中的业务属性支付者编号 PAYER_NO 来划分的，如果
PAYER_NO 小于 10000 就是包月客户，也即不对每次交易计费。如果 PAYER_NO 大于等于
10000 且小于 20000 就是按次客户，一次支付计费 0.5 元，也即不对每次交易计费。如果 PAYER_NO
大于 20000 就是按交易金额计费的，交易金额低于 10000，收费 1 元，交易金额大于 10000，收费
2 元。
一个业务规则建模分为 2 部分，一是条件定义 If，二是 then 的操作。如下图为条件定义，通过 AND/OR
可以定义多个条件组合，条件定义多是输入变量的一些判断。
从选用板中拖一个业务规则任务到计费系统的泳道中，属性 -> 常规 -> 名称中输入确定客户类型，在属性
-> 输入中选择两个输入：CHARGEITEMBO,PAY_REQUEST。输出中选择 CHARGEBO
和 CHARGEITEMBO。在业务规则标签中添加规则，输入名词确定客户类型，点击添加规则，点击规则条件右端，弹出规则条件对话框如下：
图 6. 规则定义，确定客户类型的条件
点击添加，也即添加一个条件，在第一项下选择建模工件，然后选择输入的属性 PAYER_NO，运算符选择小于等于，第二项选择数字，然后输入
10000。
确定以后点击规则操作的右端，弹出规则操作对话框，如下图为 then 的操作定义，主要是对输出的业务属性的赋值，详细信息中选择
Type，值规范中选择特定值，输入“按月计费”。
图 7. 规则定义，确定客户类型的结果
这样就形成了客户类型的第一个规则。
针对每个业务规则，WBM 会生成很容易读懂的脚本，如下图是确定客户类型的第二个规则。
图 8.
规则定义，生成的可理解的规则语言
类似的，再设置计费的业务规则。通过条件判断，给输出的 CHARGEITEMBO 的 Fee 赋值。
完成了业务建模以后，要导出业务模型，并将之导入 WID，以生成项目文件和项目框架。
在 WBM 中点击项目右键，选择导出，进入下图界面：
图 9.
导出 Modeler 的业务模型
选择 Websphere Integration Developer（开发工具）。
点击下一步，选择导出文件存放目录。进入下一步的导出设置：
图 10.
按模块和库的方式导出业务模型
注意：一般按推荐选项，然后把实施模块名称和库名词修改为英文，为了开发方便起见，流程的节点名字，流程业务项都最好用英文，这样最终生成的
WID 就都是英文变量，否则在 WID 中的中文变量、项目名会带来一些开发的麻烦。
然后点击完成，就可以生成 WID 的导入项目，一般是项目名称 + 生成日期时间的 zip 交换文件。
至此，我们完成了业务建模的工作，包括业务数据 ( 业务表单 ) 的建模、流程建模和规则建模，并把业务建模的成果导入开发环境，形成了粗的开发框架。
对一个具体的业务例子，我们应用业务建模的方法，通过 WBM 对此业务例子进行了业务建模。业务建模使得业务人员把需求以一种比较标准的方式移交给
IT 开发人员，消除了从业务需求和 IT 实现之间的歧义。这个业务建模是未来服务识别的一个重要输入，也可以导入开发环境，生成开发框架，是
SOA 架构设计的重要一环。
学习
获得产品和技术
| 
