设计和实现决策服务的最佳实践:第 1 部分 : 一个创建可重用决策服务的 SOA 方法

决策服务是最近的热门话题,甚至演变为产品特性。作为解决方案架构师或开发人员,您可能已经看到,我们必须走出纯产品的范围,开始思考如何设计和实现决策服务,从而轻松地维护和使用它们。本系列第 1 部分将介绍使用 IBM® Business Process Manager Advanced 和 WebSphere® Operational Decision Management 设计和实现决策服务的一些最佳实践。本文将介绍在设计基于规则的决策服务时需要考虑的要点,这些服务遵循最佳实践并且可以融入到大型 IT 架构中。 本文来自于 IBM Business Process Management Journal 中文版

Jerome Boyer, 高级技术人员, IBM

Jerome Boyer 是一位 IBM 专家,精通 BPMS、SOA 和 Complex Event Processing 部署中的 Enterprise Business Rule Management 系统。Jerome 作为首席 ILOG BRMS Architect 领导 IBM Software Services for WebSphere (ISSW) 项目。他在设计、管理和开发大规模企业 IT 解决方案方面有超过 20 年经验,涉及的行业包括电信、金融、保险和电子商务市场。他参与了业务规则部署方面的大多数 ILOG 项目的技术和架构评估。Jerome 还设计了用于收集实现 BPM 的最佳实践的 ISIS 方法。


developerWorks 投稿作者

2013 年 5 月 06 日

概述

决策服务是一种制定决策的服务,在本文中,将通过业务规则技术实现决策服务。作为一种服务,决策服务具有可重用的逻辑,可以为某种业务功能服务。最近,人们热衷于使用决策服务 一词,甚至将它用作产品特性的名称。另一个趋势是无差别地使用产品特性,这简化了决策服务的设计以及它在 SOA 中的作用,遗弃了多年以来的 SOA 实践。在使用自上而下方法定义的业务流程模型中,如果范围仅限于某个流程,未提供可重用能力,那么决策服务行为并不是一种服务,它只是一种决策行为。本文将帮助开发人员和架构师设计和实现可以在可持续环境中用作可重用组件的决策服务。

使用业务规则管理系统实现决策服务,这将保证业务逻辑在服务层的透明性和密封性。可以在业务用户需要的时候更改业务逻辑,无需重新部署任何业务流程或业务应用程序。通过使用 WebSphere Operational Decision Management(以前称为 IBM ILOG® JRules),业务分析师可以对规则本身进行维护。

业务规则生命周期完全不同于可执行的业务流程定义 (BPD) 或服务编排(SCA 组件,BPEL 或 ESB 中的仲裁流)。它允许每天更改业务规则,而这对于业务流程定义或可重复服务是无法想象的。

作为一个业务服务,决策服务应当鼓励所有服务使用者重用服务,而不只是重用业务流程应用程序。

决策服务的一个基本示例是数据验证,在数据验证场景中,业务需求会对数据进行约束,决策服务就是确定是否记录某个问题或拒绝业务交易。在索赔处理中,“索赔验证” 或 “索赔裁决” 是另外一些决策服务的示例。批准一项贷款或一个保险单以及评估是否存在骗保行为也属于决策服务。决策服务是对核心应用程序逻辑的具体化,是一种服务提供程序,由业务流程应用程序和所有其他应用程序使用。决策服务的关键特性是可重用性和良好的适应性。

规则处理是面向数据的处理,通常需要处理大量的数据才能制定一个决策。另一方面,业务流程管理产品是面向流程的,行为与行为之间只携带少量的信息。在下一小节中可以看到,这两种技术是一种垂直的关系。

从设计角度来看,IT 架构师和开发人员需要解决以下几个问题:

  • 如何识别决策服务?
  • 业务需要制定哪种类型的决策?
  • 如何设计决策服务?
  • 规则处理需要满足哪些对象模型要求??
  • 我应该使用哪种方法从业务流程中设计服务,是使用自上而下的方法,还是自下而上的方法?
  • 我的规则集是否是服务规范?
  • 从哪里获得数据?

在实现层上,如果盲目使用产品特性,开发人员最终会得到糟糕的性能和可维护性,或者草率的解决方案。本文利用经过长期检验的 SOA 设计模式来实现可持续的决策服务,通过这些介绍设计可重用决策服务的关键几点。


不使用 BPMS 的 BRMS

决策服务不一定与业务流程行为有关。仅在业务流程模型中查找决策服务将会大大缩小潜在的改进空间。SOA 中部署的大部分决策服务与任意自动化业务流程并无直接联系。至少有十年的时间,BRMS 部署的主要驱动因素集中在服务实现层上,在该实现层上必须实现敏捷性,业务逻辑的修改非常频繁,受到业务需求的推动。这些项目表明,不应当总是从业务流程模型入手!对现有业务服务运营进行分析可让您快速找到利用 BRMS 技术实现现代化的决策操作。这遵循一种更加传统的 SOA 方式,需要识别、规划和实现服务,解决可重用性、适应性和变更管理的问题。因此,一定要注意了解决策服务并不是一种产品特性,而是一种服务。此外,将 BRMS 和 BPMS 产品划分到统一范畴会造成混淆。首先,它们所管理的元素的生命周期十分不同:业务规则的生命周期为几个小时或一天,流程定义的生命周期为几周或几个月。在流程中嵌入规则意味着必须在每次修改业务规则时修改流程定义,并迁移所有活动的流程实例。第二,业务流程所有者与业务规则所有者通常是不同的。在涉及多个决策活动的流程中,决策逻辑可能属于不同部门所有者:索赔处理员、欺诈评估员和裁定员,他们与索赔处理业务流程所有者处于不同的主题专家组中。

流程路径控制流范围内的业务规则将决定该流程应遵循哪些流程路径。这类规则仅仅是 OMG 定义的行为业务规则的一个子类。BPMN 网关并不是一种决策服务。网关之前的行为更加侧重于发现决策逻辑或规则,以及评估是否需要对业务规则具体化。

图 1. 业务规则的各种衍生
业务规则的各种衍生

推断、计算、派生、约束甚至处理所涉及的业务规则分属不同类别,需要使用不同的 BRMS 产品。使用 BRMS 的路径选择规则(特别是嵌入式规则引擎),并不是十分重要。

IBM Business Process Manager 和 WebSphere Operational Decision Management 属于互补产品,可以满足不同范围的需求。在本文中,我们首先将讨论如何识别业务流程模型内的决策服务。


识别决策服务

在进行业务流程建模时,以 IBM Blueworks Live 为例,业务流程分析师可以识别流程定义中参与决策制定的行为。这些决策大部分情况下由人或某些支持业务逻辑的软件做出。在流程发现的这个阶段,敏捷业务规则开发方法(参阅 Eclipse Process Framework Project (EPF)Agile Business Rule Development)建议将这些行为命名为决策点。决策点是指业务流程中所有涉及变化和决策的点,它包含所有将制定决策的潜在业务规则。决策服务是指以可重用的方式实现一个或多个决策点。大多数情况下,会出现一对一对映射,但是决策服务可能包括多个决策点,比如当处理决策的数据模型相同的时候,以及流程中的行为是连续的并且可以归到一个行为中的时候。例如,在索赔业务流程中,Validate claimVerify coverage 决策点可能会映射到某个惟一的决策服务,因为一旦索赔生效,流程将直接进入检查承保范围的环节:

图 2. BPD 中的决策点
BPD 中的决策点

要识别决策点,需要查看流程定义中的行为描述,并搜索表示决策的动词,比如 “评估”、“验证”、“计算”、“检查”、“选择” 等等。典型的决策点类似于审核贷款资格、在保险单上签名、检查退休金计划、审核申请、计算价格或确认索赔。如前所述,业务流程图中的 BPMN 并不是一项决策服务。它是一种控制流分支机制,为流程中的有序流程确定路线。大多数情况下,决策服务的结果被用作决策网关的输入。

在进行流程建模时,与主题专家进行讨论有助于加深对决策范围的理解:例如,我们讨论的规则多于 10 个还是少于 10 个?决策背后的逻辑的所有者是谁?这种逻辑多长时间变化一次?这种变更的生命周期是多少?信息模型在流程的这个阶段是否完整?

通常,业务流程实例仅包含最少量的行为之间的信息,包括它所管理的业务实体的关键信息,以及目前为止从不同用户界面中收集的数据元素。制定决策可能需要更大的数据量。例如,要确认一项索赔,需要查看保险单,与索赔有关的历史记录,比如医疗发票,以及索赔人的历史记录。

要成为一个决策服务,决策行为需要具备可重用的逻辑、清晰的输入和输出。制定本地路径选择决策的流程路线选择规则并不是可重用的服务,它们只是一组规则集合,提供具体的流程变量来帮助流程行为进行参数化。在大多数情况下,流程路线选择规则的数量非常有限。很少会定义在流程变量级别使用的规则 —— 没有丰富的数据模型和复杂决策,其他应用程序不会重用它们;没有外部规则生命周期需求,修改需求会很少,实质上这些规则是静态的。这些规则可以在 IBM Business Process Manager 流程应用程序中较好地实现为 Javascript™。

识别决策点可帮助项目经理发现、分析和实现规则,在多数情况下,可以使用业务流程实现行为以外的资源。

要真正实现 BRMS 的价值,必须理解在哪些位置定义当前的业务规则:是谁触发了对规则的更改,由谁实现它们,以及谁拥有并定义逻辑。另外一个重要内容是收集关于规则的元数据,以便实现更好的治理。


决策服务是业务服务

应该敬爱那个决策服务视为业务服务部门的一部分。当使用 IBM SOA 参考架构对不同类型服务分类时,应该将决策服务视为业务服务的一部分。首先,它是 “一种具有指定结果的可重复行为的逻辑表示”(如 Open Group SOA Work Group 定义的那样),因此它是一项服务;其次,它归一些业务部门所有、由他们进行定义并托管,但是由 IT 部门进行部署和管理,因此它是一项业务。索赔裁定就是一个很好的决策服务示例:业务定义了如何裁定索赔、如何计算免赔额、需要赔偿的内容等业务策略,而服务则公开为 SOA 内的可重用组件。

图 3. SOA 参考架构
SOA 参考架构

大多数决策都应用到了业务用户想要控制的业务实体上,其中包括索赔、订单、故障单、服务请求或银行交易,这些实体本身有自己的生命周期。决策服务通过提供使用者需要遵循的原则和决策,参与到了这种生命周期中。

决策服务通常不是一个独立的部分;它应当是范围更大的内容的一部分。例如,AdjudicateClaimClaimManagerService 内的一个同步操作,underwriteLoanLoanManagerService 内的一个操作,如 rateApplicantsaveLoangetLoan 操作。输入至少包括主业务实体,而输出可以是采取决策后的相同实体或一个专门的结果对象。例如,对于数据验证,可以将一系列问题报告为一个响应。

为了遵循 SOA 最佳实践,决策服务的设计需要采用与松散耦合相同的模式,执行粗粒度操作,使用者和提供者之间只存在最低的负荷,如下所述:

  • 耦合或依赖性是指每个程序模块对其他每个模型的依赖程度。服务接口规范在开发时应当最大程度减少对使用者和提供者的假设。它们甚至可以包括不同的特性:一个来自使用者的角度,另一个来自生产者的角度。要进行松散耦合,在对某个应用程序或模块进行修改之后,不应强制对另一个应用程序或模块进行修改。下面是一些不同的耦合因素:
    • 时间:一个系统是否可用不影响另一个系统。可以通过使用 ESB 对这种耦合提供支持。
    • 数据模型:数据模型的差异不会阻碍集成。通过使用 ETL 流程或仲裁流可以很好地支持这一点。
    • 实现:服务实现对于调用方是隐藏的,这意味着,例如,使用者并不知道服务正在使用规则技术,而且不应当指定希望使用的规则集版本,或者获得所执行的规则的名称。
  • 对于粗粒度操作,服务操作应当提供重要的业务价值。它通常包含一个细粒度服务组合,特别是数据服务。业务规则服务呈现重要的业务决策,需要对大量数据元素进行复杂处理。
  • 为了最大程度地减少有效负载,传递给服务的信息(包括关键数据元素)应当减至最小。驱动因素包括性能、组件之间的依赖关系、可重用性和更小的变更管理影响。

获取数据的职责应当落在服务一方。服务不应当要求使用者提供所有所需的数据,特别是服务所需的任何参考数据。当使用 BPM 作为工作流引擎,其中以人为中心的流程只携带最少量的信息时,也不应该由使用者提供数据。IBM Business Process Manager Advanced 还支持服务编排和仲裁引擎,它结合了细粒度服务来针对决策服务比较数据。

服务设计考虑

如前所述,决策服务是更大组件中的一项操作。设计需要解决典型的接口特性,Brian Petrini 和 Kim Clark 在他们的两篇最新文章中已对此进行了讨论(参阅 参考资料)。对于决策服务,接口特性至少包括下表中的属性,其中以一个 “承诺贷款” 决策服务为例:

表 1. “承诺贷款” 决策服务的接口特性
特性 描述 示例
功能定义
主数据对象 被服务的或服务使用的主要业务实体 贷款申请
操作 描述服务提供的操作。使用动词 + 名称的方式(如果可能) assessLoanEligibility
读取 / 更改 操作结果是否要对数据进行更改 更改。可能是拒绝申请的理由列表,如果接受申请的话,则是潜在的贷款条件。
请求-响应 您需要发送什么数据,您会因此得到什么? LoanApplication 作为请求-响应,LoanApplication 包括物业,借款,财务信息。
技术接口
传输 接口使用的介质,用于在请求方和提供方之间来回发送数据。 HTTP
协议 请求方与提供方有关如何以及何时通过传输功能来彼此发送数据的协议。 SOAP
数据格式 数据的 Wire 格式 XML 文档 UTF-8
交互类型
交互类型 使用者如何与服务交互。该类型可以是 fire-forget 或请求-响应阻塞传输,请求-响应非阻塞传输,带确认的请求,回调等等。 请求-响应阻塞传输
批处理或单个处理 处理单个业务操作或同时处理一组操作? 单个操作
消息的大小 提供方为了满足 SLA 而接受的消息的大小。 1 MB
Performance
响应时间 从发出请求并通过此接口接收到响应所用的时间。 平均 <800 ms。范围为 300ms 到 1.5s。
吞吐量 一定时间期限内可以处理的请求的数量。 20
容量 一段较长时间内的最大容量。 每月 2 百万申请。
并发性 在同一时间可以处理的请求的数量。 同一时间可以处理 3 到 6 个并发请求。
完整性
验证 要使请求被接受,请求方必须遵守哪些数据验证规则? 在执行此操作前执行验证规则集。对模型的约束也将确保对必要字段进行一定程度的控制。
事务性 定义接口提供的交易支持级别。
状态性 在执行一系列调用之前声明必要的设置。服务是否应当在调用之间保持状态一致? 无状态
事件顺序 请求的顺序
幂等性 如果同一请求发出两次,是否获得相同结果? 相同的规则集将获得相同的结果,这意味着没有时间保障。对于本例而言,没有约束可以确保一项贷款申请在不同时间具有相同的响应。
安全性
身份/身份验证 确保获得许可的用户和系统能够发出请求。可以请求用户 ID 和系统 ID。
授权 执行所请求操作的授权。 开放 / 无控制
隐私 谁可以看到通过接口发送或接收的数据? 目前为止未指定任何人。
所有权 谁拥有操作涉及到数据? 业务逻辑属于贷款担保部门,RBO 属于企业架构团队。
可靠性
可用性 出现计划外宕机的频率和持续时间? 工作日时间 7 × 12 小时的服务可用性。
交付保证 确保请求获得处理的程度。 Web 服务不支持 WS-Transactionality,没有交付保证。
错误处理
错误管理能力 如果在调用接口时出错,如何处理错误,以及由谁处理它们? 通过找错将错误报告给请求方。
已知的例外条件 在设计阶段发现的错误,因此可以预计以有意义的方式报告给调用方。 业务错误将以与贷款申请有关的问题的形式报告。
意外错误的表示 意外错误如何呈现给请求方? 意外错误未被规则集捕捉。

信息模型考虑因素

在处理业务规则应用程序时,一个主要的设计因素是查看信息模型。知识工程师通常将信息模型称为事实模型,用于规则处理的信息模型与 IBM Business Process Manager 内的流程变量定义是不同的,因为它基于对不同业务规则的分析,而流程变量旨在从 Coaches 中收集数据并在行为之间传递数据。规则定义可以驱动用于规则处理的数据模型。在声明业务策略时,业务用户使用一个由概念数据模型 (CDM) 表示的词汇表。使用 Rational® Software Architect 之类的产品,您可以用简单的 UML 类图或素描 (sketch) 图对概念数据模型建模。这样做的目的是与业务分析师进行沟通,从而在图表中包括高级实体描述和它们之间的关系。图 3 显示了一个用于索赔处理申请的 CDM,它执行了如下所示的业务规则分析:

A claim must have a data of loss set between the effective date and expiration 
date of the active insurance policy. 
When there are injured persons, all the medical invoices attached to the claim 
should have a data of servicing within a year after the accident (date of loss)
图 4. 概念数据模型
概念数据模型

要使用 WebSphere Operational Decision Manager 编写有效的规则,开发人员可以应用面向对象的最佳建模实践。因此,设计行为包括将概念数据模型转换为逻辑数据模型 (LDM),在 LDM 中将生成 XSD 或 Java 模型。要在 WebSphere Operational Decision Management 中支持更好的规则编写体验(以及更好的规则执行性能),我建议使用 Java 语言作为执行模型。这使我能够添加行为方法来简化规则的编写和处理,使用继承特性来简化模型,使用封装功能支持特定设置,添加工厂方法(例如,创建与集合相连的实例),添加可重用的特性,如对集合方法排序、计算、本地数据缓存等等。

还要注意的是,规则使用的信息模型必须在规则集实现期间进行不断进行修改。采用独立的模型有助于在不会影响使用者的情况下频繁修改模型,这样做效率更高。

从方法学的观点来看,为了与项目相关方进行有效沟通,我将这个具体的信息模型引用为规则业务对象 (Rule Business Object, RBO)。这有助于将它与服务实现模型、BPM 中的流程变量、消息传递级别的规范 (canonical) 模型以及 Service Exposition Model 区分开来。

图 5. 针对不同范围的不同模型
针对不同范围的不同模型

一个良好的架构可以利用不同的信息模型视图向业务应用程序的不同层传递数据:图形用户界面、数据库、服务合同、业务流程数据、消息传递结构和业务规则。这种模式并不新鲜,BPM 和 Java EE 应用程序已经应用了这种模式很长一段时间。

在图 5 中,由集成的外部应用程序创建的业务对象被称为 Application Specific Business Object (ASBO)。当对后端系统进行更新时,ASBO 定义也需要进行相应修改。ASBO 不会表示服务数据的类型或 RBO。使用 IBM Business Process Manager Advanced,您可以利用现有的连接器(继承自 WebSphere Business Integration)接收来自外部企业系统的信息模型,并将 ASBO 构建为一组 XSD。

Service Exposition Model 在服务接口定义中实现了具体化,它变成 IBM Business Process Manager Advanced Library 中的一个 WSDL 文件。另一方面,Service Implementation Model (SIM) 在内部被定义为支持服务实现的模块;它的范围为整个服务域。

这种封装有助于从实现的角度修改 SIM,对于使用者能够可靠地使用模型。ASBO 终究不是 SIM,因此您应当避免为 ASBO 编写逻辑;而是为更加稳定的 SIM 编写逻辑。

图 6. SEM – SIM – ASBO - RBO
SEM – SIM – ASBO - RBO

例如,假设您有一个 “claimdb” 数据库,其中保存着索赔、保险单、受保人等信息。通过使用 IBM Business Process Manager Integration Designer,您可以利用出局 JDBC 适配器直接从技术服务中获取 ASBO 定义。这同样适用于使用出局 Web 服务。XSD 定义是使用 JDBC 适配器模块的一部分。

对于消息传递定义,一种好的做法是应用规范数据模型模式将不同数据模型之间的映射数量限制为两个,一个是使用者和规范模型之间的映射,另一个是规范模型和服务生成者之间的映射。您应当使用 SEM 作为规范模型的来源。

从决策管理的角度来看,RBO 被用作 WebSphere Operational Decision Management eXecutable Object Model(或 XOM)。这样可以将该 XOM 分离到一个单独 Java 项目,使用 JAR 封装并轻松地进行单元测试。使用 XSD 到 Java 编译器(比如由 JAXB 提供)生成 JAVA bean 将很有趣。如上所述,与 XSD 相比,我倾向于使用 Java 作为底层编程语言,从而能够向业务对象添加有效的行为,而不用使用 BO 来传递数据元素。

根据团队实践,RBO 的开发可以遵循多种设计和实现路径,比如 UML 到 Java,UML 到 XSD,然后 XSD 到 Java。在使用 IBM Business Process Manager Advanced 时,信息模型可以在 Integration Designer 中通过业务对象编辑器定义。

图 7. 开发 RBO 的两条可能路径
开发 RBO 的两条可能路径

XSD 被用作 XSD 到 Java 编译器的输入,该编译器由 JAXB 提供。生成的 Java bean 和其他 Java 类在 Decision Designer 中的 RBO Java 项目中使用。

在结束对信息模型的讨论之前,让我们了解一下规则处理的一个重要因素——对参考数据的访问,类似枚举值或值列表。如果枚举值是静态的,它们可以在 XSD 中定义为枚举,成为 BOM 的一部分,并且可以通过规则词汇表轻松访问它。如果参考数据是动态的,那么可以在不同时间频繁添加值以支持新的业务需求。BOM 层可用于这个目的,但是有时候这些动态数据位于一个服务中。以下代码所示的规则条件(搜索代码是否是已知的)可能使用这种服务。本地缓存变得非常重要,因为它可以避免从规则条件或操作调用外部服务。

If … 
     the medical procedure code is known

可以通过类似如下所示的 Java 方法实现前面条件的可执行模型:

Public Boolean searchCode(String code)

该方法使用了一个缓存的值映射。缓存由应用服务器在内部管理,在新的枚举值加入到数据管理 (MDM) 时遵循动态的更新模式。参考数据将决定是选择使用 XSD 还是 Java 作为规则的底层执行模型。

牢记这些最佳实践后,我们现在将进入到决策服务设计和实现阶段。


设计决策服务

在开发决策服务接口时,应当最大程度地减少对对使用者的假设,以便可以应用松散耦合最佳实践。在决策服务中,主要的耦合来自于信息模型,而生成者应当能够针对规则处理修改数据模型,并且避免对使用者产生影响。这可以通过设计一个请求-响应模式来实现,该模式携带使用者可以发送和理解的最重要的信息。在 图 8 中,发送的内容是索赔单号而不是完整的数据图,其中根元素为索赔。获取数据的任务由服务实现端完成,在服务实现端有多种功能可用来使用缓存和贪婪加载 (eager loading) 获取战略。

决策服务必须作为一个操作集成到更大的组件中,并且这个操作应当提供重要的业务价值。该组件支持其他相关的业务操作。例如,“裁定索赔”、“确认索赔”、“检查承保范围” 都属于索赔处理模块中的决策服务操作,如图 8 所示。该服务接口可以是 IBM Business Process Manager Integration Designer Library 的一部分,在模块之间共享,并作为在 IBM Business Process Manager Process Designer 中开发的流程应用程序的工具箱。

图 8. 索赔管理器组件的部分接口定义
索赔管理器组件的部分接口定义

需要注意的是,WSDL 目前无法提供足够的信息来表示接口正在做什么。如 表 1 所示,有关服务的其他元数据记录在一个单独的文档中。大多数情况下,第一个接口设计由第一个项目驱动,但是仍然建议不要设计业务流程和决策服务的点对点集成,而是考虑创建一个长期的可重用服务。这样做是为了避免设计紧密耦合的接口,因为在这种接口中,只有一个用户可以向服务生成方发送数据。即使在第一个项目中,设计一个长期的、可持续的解决方案和架构也是非常重要的。IBM SOMA 方法建议采用一个简单的、决定性的服务测试,可评价服务的业务敏捷性、可组构性(使服务能够参与到服务组合的属性),以及实现具体化的能力。和许多其他业务服务一样,决策服务应当顺利通过这项测试。

还需要考虑其他一些约束,比如许可授权以及操作和维护成本。我经常遇到在一个中央服务器中部署 JRules eXecution Unit 的要求,以便在应用程序之间共享资源。这种部署约束强制使用远程调用,并在服务器之间编组和解组数据。如果可能的话,最好在服务层内部署 XU。我将在本系列第 2 部分介绍如何实现此操作。

查看数据的所有权有助于了解数据的提供者和接收者。在大多数使用 IBM Business Process Manager 的新业务流程实现中,会从不同条目表 (Coach) 中收集新的数据元素。这些数据必须保存到一个记录系统中。在大多数情况下,已经定义了一个现有数据库来保存大部分信息,但并不总是这样做。通常,需要对底层的物理数据模型进行修改。这一直是一个敏感话题,因为当前的数据库可能由不同的应用程序使用。通常,由于时间约束以及快速投资回报的要求,项目组可能会选择添加一个新数据库。必须避免这样做,因为这样可能导致 IT 以及维持不同数据库之间数据的完整性变得更复杂。这种架构决策需要与所使用的数据治理保持一致。

作为首个数据记录者,业务流程不应当将数据作为流程实例的一部分,或者用 JavaScript 或 JDBC 代码将数据直接写到新数据库中。相反,数据服务层必须实现自己的接口,并可供可执行的业务流程使用。一个服务操作可以将流程变量的结构(按照流程的定义)映射到现有的物理数据。通过使用 IBM Integration Designer,映射可以通过仲裁流或映射功能完成,这种方法比在 IBM Process Designer 中使用 JavaScript 更好。

在未来,如果数据库可以合并,那么流程定义不会发生改变,因为接口没有改变;只有集成实现发生了变化。数据访问层服务立即被决策服务实现重用,因此使用 BPMS 和 BRMS 会强制创建一个数据访问层策略,该策略随后会演变为可重用的服务。再次强调,治理是此处的关键,可用于识别和处理数据所有权关系与变更管理策略。


实现决策服务

如前面的小节所述,要支持敏捷业务流程,需要让业务流程在行为之间携带最少量的信息。对外部决策服务的调用应当使用任意业务实体的业务键,而不是业务实体本身。大多数决策服务需要通过推断历史数据来制定决策;这些数据没有在 Coaches 中定义,而是保存在一个记录系统中。在实现决策服务的过程中,会加载所需的数据并构建一个富数据图,供规则引擎进行处理。规则编程的最佳实践是在调用规则引擎之前收集所有数据。这种逻辑的实现需要对上述的所有数据服务层以及其他服务(比如管理参考数据的服务)进行编排。在 IBM Business Process Manager Advanced 中,您可以使用一个 BPEL 流程实现此目的。

图 9. 实现决策服务所涉及的组件
实现决策服务所涉及的组件

在 WebSphere Operational Decision Management 规则集中,不建议调用数据访问层服务来访问规则流内部的数据,主要是因为很难有效地管理调用失败后出现的异常、超时和恢复。这类处理必须在执行规则之前完成。

在图 9 中,所涉及的组件包括远程数据访问服务,主要用于管理保险单 (PolicyManagerService)、管理索赔和历史信息 (ClaimService),以及获得隐私信息 (PersonManagerService)。

出于性能考虑,在使用 IBM Business Process Manager 时,必须在服务层以纯 Java SCA 组件的形式实现决策服务 (ClaimDecisionServices)。优先选择 Java 语言来快速实现决策服务。这种方法提供了灵活性,可以脱离任何集成来开发 Rule Business Object 模型和规则本身,并进行单元测试。代码是一个标准的 JRules RES 集成,它使用了 RES 工厂和 RES 会话 API。

下面的代码片段在 RuleProcessingImpl 类中实现,它支持将 RBO 作为信息模型 (Claim) 并使用 RES API。这些代码可以封装到 EJB 或 POJO façade 中,并像其他可重用服务一样作为 Web 服务部署到相同的服务器中,或者远程部署到专门用于规则处理的服务器。这种方法非常灵活。

public ClaimProcessingResult validateClaim(Claim claim) {
   ClaimProcessingResult outResult = null; 
   try { 
	IlrSessionRequest sessionRequest = 
		prepareSessionRequest(validateClaimRsName);
	// Set the input parameters for the execution of the rules 
	Map<String,Object> inputParameters = new HashMap<String,Object>();
	inputParameters.put("validateClaim", claim); 
	sessionRequest.setInputParameters(inputParameters); 

	// Execute rules
	outResult=executeRule(sessionRequest, "validateResult"); …

在使用远程服务器完成所有规则处理时,可以使用 WAR 或 EAR 完成上述代码的打包,并将它部署到运行 XU 的 WebSphere Application Server 中。在 图 10 中,MP_DecisionServices 是一个 WAR,支持 WebSphere Operational Decision Management 中实现的不同决策服务。这些决策服务在业务流程发现阶段衍生并在惟一接口中指定。

public interface ClaimProcessingDecisionService { 
	public abstract ClaimProcessingResult adjudicateClaim(Claim claim); 
	public abstract ClaimProcessingResult validateClaim(Claim claim); 
	public abstract ClaimProcessingResult verifyCoverage(Claim claim); 
	public abstract ClaimProcessingResult validateMedicalInvoice( 
			MedicalBill medicalInvoice); }
图 10. 远程服务器上的决策服务
远程服务器上的决策服务

WebSphere Operational Decision Management 支持托管的透明决策服务 (HTDS) 的概念,可以将规则集公开为一个 Web 服务。一个专门的 Web 应用程序 (jrules-res-htds-WAS7.ear) 被部署到规则执行服务器并使用 XML 文档。在 JRules 7.1.1 之前,该特性仅支持 XML 文档;因此,只有需要添加 Java 实用类来支持更好的规则处理,所以最好使用您自己的服务,如前所述。WebSphere Operational Decision Management 支持在 HTDS 中使用 Java XOM。我将在本系列第 2 部分中详细介绍这一内容。然而,不应将作为 Web 服务公开的规则集视为业务服务,它表示可以通过 SOAP over HTTP 远程调用的一种方法或操作。使用 HTDS 的主要考虑因素是需要由使用者向 HTDS 发送所有数据。在使用 BPM 工作流时,比如纯 IBM Business Process Manager BPD 解决方案,建议您不要在流程定义中进行服务编排和低级别的集成。这些逻辑必须是服务层的一部分。决策服务通过实现这种逻辑为规则引擎准备数据,调用规则执行并处理结果。

在评估最佳实现选项时,可以研究一下不同的用例或模式。表 2 展示了 Business Process Manager and WebSphere Operational Decision Management 的最适合用于支持各种用例的特性:

表 2. 支持各种用例的产品特性
用例 Business Process Manager 功能 WebSphere Operational Decision Management 功能
BPD 能够发送所有数据元素,XML 足以支持信息模型
不存在 XSD 枚举范围以外的参考数据
JRules 决策服务
SOAP 客户机
Web 服务集成
Java 集成
内嵌的 HTDS
RES 和 XML 绑定
规则可以在应用程序之间重用,XML 足够多,BPD 发送部分信息
MDM 中 XSD 枚举以外的参考数据
高级集成服务
Web 服务集成
在服务层/本地 SCA Java 组件,仲裁流或 BPEL 组件中部署的 Rule eXecutable Unit
Java
HTDS 中的决策服务
可重用的规则集
基于 Java 的 RBO
BPD 发送部分信息
MDM 中 XSD 枚举以外的参考数据
高级集成服务
Web 服务集成
Java 的集成服务
HTDS 和 Java XOM,以及 ID 中的集成服务
需要在 Coach 或 activity 级别验证数据
需要在相同 JVM 中作为流程引擎组合服务
Java 集成
规则引擎 API
嵌入式 XU

注意:

  1. 第一个决策因素与规则的词汇表和表达有关:大多数业务规则应用程序需要使用有效的词汇表来公开一种简单的语言,业务分析师可以使用这种语言编写规则。这意味着在表示信息模型的 Java bean 上添加行为方法。需要注意的是,WebSphere Operational Decision Management 支持在 BOM 到 XOM 的映射中添加脚本逻辑,但是您可以避免使用脚本,因为使用 Java 更合适。
  2. 第二个因素是评估 BPD 是否能够为规则引擎获得所有数据。大多数流程应用程序只携带有关 Coaches 或流程行为的数据元素。决策服务需要更大的数据图,包括历史信息。流程无法加载数据,或者在设计时未考虑这一点。这个工作应当由服务层完成。
  3. 第三个因素与参考数据的管理有关。大部分业务应用程序在一个单独的组件(如 MDM 产品)中定义和管理这些重要的元素,并且在运行规则引擎的 JVM 中缓存它们。

我将在本系列第二部分详述所有这些集成模式。在上面列出的几个因素中,第三种用例在设计可扩展、可持续的解决方案时最常使用,并且会强制使用 Advance Integration Service (AIS) 特性。


结束语

总之,您需要了解规则处理所用的信息模型,了解谁创建了哪些业务实体,以及这些数据图是如何构建并发送给规则引擎的,这些非常重要。您还需要了解参考数据管理。决策服务需要集成到 SOA 中并用提供者的服务接口特性进行描述。选择 XSD 还是 Java 与所使用的技术有关;例如,在使用 IBM Business Process Manager Standard 时,Java 是一个更好的选择,因为服务实现可以更好地管理规则引擎所需的数据图。

在本系列第 2 部分中,我将深入探讨使用 IBM Business Process Manager and WebSphere Operational Decision Management 特性来实现与 IBM Business Process Manager 集成在一起的决策服务的细节。

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=928816
ArticleTitle=设计和实现决策服务的最佳实践:第 1 部分 : 一个创建可重用决策服务的 SOA 方法
publish-date=05062013