本文将介绍高级治理解决方案的 IBM ODM 治理框架。本文基于可配置的 Java 业务逻辑（如规则治理产品示例所示）提供了常用规则治理实现的一个灵活替代方案。我们将展示，使用规则（而不使用 Java）治理更改流程可在 ODM 中提高高级治理的能效和灵活性。
对于更改活动的治理，我们建议您查看一下ODM V8.5 中新增的治理功能。
规则治理示例
产品示例中提供的治理扩展的架构如 图 1 所示。本示例的核心是会话控制器，它根据状态提供访问权限。决策中心提供了一个自定义会话控制器，名为 Workflow">SessionController，它扩展了 IlrDefaultSessionController。WorkflowSessionController 替代诸如 checkUpdate、checkCreate 和 checkDelete 之类的方法来执行治理操作。
该架构的限制如下：
状态库权限由嵌入到决策中心 EAR 中的文本配置文件控制。如果不重新部署 EAR，则无法应用配置更改。 采用 Java 实现自定义业务逻辑。由于实现和测试 Java 更改非常昂贵，因此可能需要与每个新版本的 ODM API 合并。此外，还需要针对节点的每个更改来重新部署决策中心 EAR。 项目访问是通过组合两个不同的角色概念来控制的：功能角色和项目角色。这可能会导致角色激增。
图 1. 规则治理 ODM 产品示例的架构
基于规则的规则治理
考虑以下场景：如果您将 EAR 文件中的治理逻辑委派给一个决策服务（如 图 2 所示），会出现什么情况。
图 2. 规则治理决策服务
图 2 中的架构假定决策中心与决策服务器位于相同的应用程序服务器上，以便允许进行本地 POJO (Plain Old Java Object) 调用。另一个方法是将 J2SE 规则引擎嵌入到决策中心 EAR 中。如果决策中心没有访问决策服务器的权限，则会使用该方法。
治理决策服务和治理会话控制器之间的参数接口是通过常规的规则集签名模式来实现的。该模式能够更改规则模型 (.brmx)，无需重新部署决策中心 EAR。使用映射到规则模型的 Excel 动态域来构建对象模型。