ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 使用 WebSphere Business Modeler 进行业务建模

使用 WebSphere Business Modeler 进行业务建模

原创 Linux操作系统 作者:CloudSpace 时间:2009-07-30 16:41:07 0 删除 编辑

周 晖 (zhuish@cn.ibm.com), Websphere 架构师, IBM
陈 宇翔 (chenyux@cn.ibm.com), 资深 Websphere 工程师与行业架构师, IBM

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. 业务流程
soa Modeling

以下为图中每个节点的业务功能介绍:

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. 支持请求数据项
soa Modeling

比如这个业务里面的支付请求业务项 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. 泳道按角色定义图
soa Modeling

下面定义流程的每个节点,以第一个节点—支付请求为例,从 WBM 的选用板中拖一个任务到缴费系统的泳道,点击属性,在常规标签中输入名称支付请求。

定义一个业务节点,除了要描述业务实现的功能,还要定义完成此业务所需要的业务项,和完成以后可以提供给下一步的业务项。点击属性的输入标签,点击添加,点击关联数据右端,弹出类型选择,选择业务项 ->PAY_REQEUST,输出也是 PAY_REQUEST。

如果是人员任务,还要定义组织架构,任务以什么方式分配到什么角色或是资源,任务在什么情况下进入升级处理,如任务没有人去声明处理,或是处理时间超时等进入升级,进入升级后的通知操作,以 Email 还是任务项的形式通知什么人去处理。


图 4. 编排业务流程
soa Modeling

逐个定义业务流程的每个活动项,并用合适的连线连接。


图 5. 业务流程图
soa Modeling

如上图,为最终的 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. 规则定义,确定客户类型的条件
soa Modeling

点击添加,也即添加一个条件,在第一项下选择建模工件,然后选择输入的属性 PAYER_NO,运算符选择小于等于,第二项选择数字,然后输入 10000。

确定以后点击规则操作的右端,弹出规则操作对话框,如下图为 then 的操作定义,主要是对输出的业务属性的赋值,详细信息中选择 Type,值规范中选择特定值,输入“按月计费”。


图 7. 规则定义,确定客户类型的结果
soa Modeling

这样就形成了客户类型的第一个规则。

针对每个业务规则,WBM 会生成很容易读懂的脚本,如下图是确定客户类型的第二个规则。


图 8. 规则定义,生成的可理解的规则语言
soa Modeling

类似的,再设置计费的业务规则。通过条件判断,给输出的 CHARGEITEMBO 的 Fee 赋值。





回页首


模型导出

完成了业务建模以后,要导出业务模型,并将之导入 WID,以生成项目文件和项目框架。

在 WBM 中点击项目右键,选择导出,进入下图界面:


图 9. 导出 Modeler 的业务模型
soa Modeling

选择 Websphere Integration Developer(开发工具)。

点击下一步,选择导出文件存放目录。进入下一步的导出设置:


图 10. 按模块和库的方式导出业务模型
soa Modeling

注意:一般按推荐选项,然后把实施模块名称和库名词修改为英文,为了开发方便起见,流程的节点名字,流程业务项都最好用英文,这样最终生成的 WID 就都是英文变量,否则在 WID 中的中文变量、项目名会带来一些开发的麻烦。

然后点击完成,就可以生成 WID 的导入项目,一般是项目名称 + 生成日期时间的 zip 交换文件。

至此,我们完成了业务建模的工作,包括业务数据 ( 业务表单 ) 的建模、流程建模和规则建模,并把业务建模的成果导入开发环境,形成了粗的开发框架。

小结

对一个具体的业务例子,我们应用业务建模的方法,通过 WBM 对此业务例子进行了业务建模。业务建模使得业务人员把需求以一种比较标准的方式移交给 IT 开发人员,消除了从业务需求和 IT 实现之间的歧义。这个业务建模是未来服务识别的一个重要输入,也可以导入开发环境,生成开发框架,是 SOA 架构设计的重要一环。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14789789/viewspace-610877/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-07-08

  • 博文量
    355
  • 访问量
    854655