决策剖析
决策服务的用途是基于传入的恶劣天气事件，智能地向各个部门生成通知和指令。此规则引擎的输入和输出遵守 Common Alerting Protocol (CAP)，这是 OASIS/ITU-T 9 发布的一个 XML 规范（参见 参考资料）。输入数据包含有关天气警报的信息，比如降雨和起雾。图 4 显示了一个示例 CAP XML 的输入片段。
图 4. 输入 XML 片段
基于这些警报，决策服务制定为各个城市部门生成通知或指令的决策，从 图 5 中的示例输出片段可以看出。
这些智能通知和指令由业务规则生成。
图 5. 输出 XML 片段
决策服务创建流程
基于规则的开发的一个重要优势是，它从应用程序代码中外部化了业务规则，并分离出了开发周期。基于规则的开发将应用程序开发和部署周期与规则的开发和部署跟踪分离开来。因此，创建基于规则的应用程序的流程不同于传统的开发流程。创建一个决策服务的流程如 图 6 中的流程图所示。可在此流程图中看到，创建一个决策服务需要规则分析师、规则架构师和业务主题专家协同工作。（查看 图 6 的更大版本。）
图 6. 创建决策服务的流程
应用程序开发流程中所涉及的任务包括：
1. 初始化
a. 规则发现
b. 规则分析
c. 准备环境
2. 开发
a. 项目创建
b. 规则设计
c. 规则创作
3. 部署和执行
a. 部署
b. 审计
4. 支持业务用户
a. 创建场景 Excel 模板
b. 发布到 Rule Team Server
5. 规则维护
a. 编辑/编写规则
b. 测试
c. 部署
从总体上讲，该流程从以下步骤开始：
1. 初始化阶段，规则分析师发现并获取业务策略。
2. 然后分析策略以创建无歧义的业务规则。
3. 规则开发人员使用 Rule Studio 创建规则项目和编写初始规则集。
4. 然后将规则部署到 Rule Execution Server (RES)，它利用 WebSphere ILOG JRules 的托管透明决策服务 (Hosted Transparent Decision Services, HTDS) 功能来将规则集公开为 Web 服务。
5. 要使业务用户能够维护业务规则，需要将规则发布到 Rule Team Server (RTS)。业务用户不仅可在 RTS 中编写规则，他们还可使用决策验证服务 (Decision Validation Service, DVS) 从 RTS 测试这些规则。
6. 准备好后，将规则提取并部署到 RES。
这些流程中每一个的详细信息都已提供。但是首先有几点需要注意。
图 6 中所示的流程图显示了创建一个决策服务的典型流程，这就是我们的案例分析中使用的流程。但是，这并不是说这是惟一有效的流程，或者甚至是所有情形的推荐流程。例如，使用一个决策仓库进行审计是一个可选步骤，组织可选择跳过。
本文不是一篇详细的教程，更像一个开发流程示例。它可用作产品文档的补充，而不能替代它。但是，文中提供了在一个任务中使用 WebSphere ILOG JRules 向导时，要输入到向导中的详细信息。另外，WebSphere ILOG JRules 提供了一个庞大的功能和特性集合，但此流程不会尝试涉及所有这些功能。例如，我们不会为本案例分析中的 Microsoft Office 或 EJB 部署使用规则解决方案。
此外，尽管 图 6 描绘了一系列有序步骤，但规则开发常常会得到一个敏捷、迭代式的开发周期，这实际上是推荐的方法。但是，在一次迭代中，此流程可在跳过一些已完成的活动后应用，比如准备环境或创建项目。
此案例分析使用 WebSphere Application Server Community Edition 默认的 WebSphere ILOG JRules 安装，因此未包含与 WebSphere ILOG JRules 的安装和配置相关的步骤，包括身份验证和权限管理。
发现业务规则
业务规则可能被认为是用于制定决策的条件语句。任何组织都拥有大量业务规则，它们常常禁锢在主题专家的头脑中。这些规则以业务策略的形式传达，比如以下规则：
如果降雨量较大，向排水部门发送评估降雨量的指令，而不是评估污水管容量。
如果水广场已被清场且威胁级别较高，则发送接通水广场的指令，以及向排水部门发送监视广场的水质量的指令。
一个典型的规则集中有几十或几百个这样的策略。其中每个策略适用于一个业务人员且可单独理解，但它们结合在一起即可制定业务决策。
在一个 BRMS 的上下文中，业务规则是可执行的单元；因此，每条策略都需要细化以准确采集业务规则，而不留下任何歧义。这种细化通常是一个两步过程：
1. 执行规则分析，以确定规则组和总体规则流逻辑。
2. 使用业务对象模型 (BOM) 中定义的术语编写业务策略。
以下文章点击率最高
Loading…