IBM ODM规则服务集成的最佳实践
企业IT架构中，我们通常会将规则引擎作为一个独立的服务，供企业中的不同应用消费，这也和当前一切皆服务的SOA思想吻合。那么问题来了，规则服务以什么形式部署呢？怎样和应用交互集成呢？Webservice？ 好吧，这是一个标准答案，并且也是一个差不多正确的答案，但我们还有更多需要考虑的东西。
我曾在一个保险行业客户处看到这样一个设计：客户设计了一个webservice，用于定义核保的输入输出，然后定义了一个EJB服务来包装规则服务，供webservice调用，在该EJB的实现中，再调用ODM自带的EJB远程接口执行规则，关键是，这些服务全部部署在同一个应用服务器上。也许有历史原因，但显然这样繁琐的设计不是一个好的设计，对于性能，维护都将是一个挑战。你也许会问性能如何？客户告诉我大概一次核保交易调用的时间为1-2秒。我当时给他们的建议是，直接在Webservice中使用ODM的POJO方式来调用规则引擎，删除中间两层EJB，这样执行性能至少可以提高一个数量级。
在ODM中，产品分别提供了在JavaSE和JavaEE环境中的调用方式，使用都通过规则会话（Rule Session）API完成。
适用场景如下：
- Java SE: 用于JavaSE环境或者 web-only容器. 这种规则会话使用Java SE 执行单元（eXecution Unit）.
- POJO: 用于Java EE 环境中的简单Java对象模型. 这种规则会话使用Java EE 执行单元（eXecution Unit）.
- EJB: 用于Java EE 环境中的 EJB. 这种规则会话使用Java EE 执行单元，可支持本地或远程访问.
- MDB: 用于Java EE 环境中的异步执行. 这种规则会话使用Java EE 执行单元.
ODM也提供了自动生成的Webservice和Rest service，供有远程调用需要的应用使用。具体调用方式的使用，必须根据需求架构做出合理的选择。
例如，下图是某客户计价平台和规则引擎的集成设计，在批量场景下，使用了JavaSE方式，联机场景下，则使用了Webservice+POJO的模式。
一般而言，规则服务集成设计时的原则是：
- 本地调用优先于远程调用，
- 在必须支持远程调用的时候，自定义一个Webservice或者Restservice，并在内部通过POJO调用规则
- 尽量不使用EJB
- 批处理执行模式下，使用JavaSE方式执行，
- 追求极致性能的情况下，可考虑使用嵌入式规则引擎（IlrContext）
注：本文也发布于http://decisionrule.com/zh/2015/03/rule-integration-best-practices, 转载请注明出处。
优质内容筛选与推荐>>1、linux下vi命令大全
2、是什么限制了我们面向对象（的开发）
3、（转）用 ANY、SOME 或 ALL 修改的比较运算符
4、LAMP 下xdebug开启后仍然不见var_dump效果
5、SQLServer 工具箱v1.3（SQL脚本排序，日志清除，数据导入导出）附完整源代码