Websphere 与规则引擎交互的首选方法
我将深入研究一个面向规则的项目（使用.NET的ILOGs规则-现在是IBM）。我读了一些关于如何设置规则处理以及如何与规则引擎交互的不同观点 我所看到的两个主要想法是将规则引擎集中（到它自己的服务器场中）并通过web服务API（或者在ILOG的情况下通过WCF）针对服务器场编程。另一方面是在每个应用服务器上运行一个规则引擎实例，并与它进行本地交互，每个实例都有自己的规则副本 集中化的好处是易于将规则部署到集中的位置。规则可以根据需要进行扩展，而不是每次扩展应用程序服务器配置时进行扩展。这从购买许可证的角度减少了浪费。这种设置的缺点是增加了服务调用的开销、网络延迟等 本地运行规则引擎的好处/坏处与集中式配置的好处/坏处完全相反。没有缓慢的服务调用（快速API调用），没有网络问题，每个应用服务器都依靠自己。管理规则的部署变得更加复杂。每次向应用程序云添加节点时，您都需要更多的规则引擎许可证 在阅读白皮书时，我看到Amazon正在按应用服务器配置运行规则引擎。他们似乎在缓慢地部署规则，并认识到规则发布的滞后是“可以接受的”，即使业务逻辑在给定的时间段内不同步Websphere 与规则引擎交互的首选方法,websphere,rule-engine,Websphere,Rule Engine,我将深入研究一个面向规则的项目（使用.NET的ILOGs规则-现在是IBM）。我读了一些关于如何设置规则处理以及如何与规则引擎交互的不同观点 我所看到的两个主要想法是将规则引擎集中（到它自己的服务器场中）并通过web服务API（或者在ILOG的情况下通过WCF）针对服务器场编程。另一方面是在每个应用服务器上运行一个规则引擎实例，并与它进行本地交互，每个实例都有自己的规则副本 集中化的好处是易于将规则部署到集中的位置。规则可以根据需要进行扩展，而不是每次扩展应用程序服务器配置时进行扩展。这从购买许
问题：根据您的经验，对于一个还没有在规则驱动的世界里花太多时间工作的商店，将规则集成到基于.net的web应用程序中的最佳方式是什么？我从不喜欢集中化的论点。这意味着所有东西都耦合到规则引擎中，而规则引擎成为系统中所有规则的倾倒场。很快你就因为害怕未知而无法改变任何事情：“我们将打破什么？” 我更喜欢遵循亚马逊的理念，将服务作为独立、自治的组件。我认为这意味着服务拥有自己的数据和规则 这还具有划分规则空间的额外好处。随着规则集的增长，其维护变得越来越困难；最好将它们保持在可管理的大小 如果部分规则集是共享的，我更喜欢数据驱动的DI方法，其中服务可以拥有自己的规则引擎实例，并在启动时从数据库加载公共规则。如果您的iLog许可证使多个实例成本过高，那么这可能不可行。在这种情况下，本应起到帮助作用的产品实际上可能会主导将带来痛苦的架构选择。这将是一个很好的论据，支持一个成本较低的替代方案（例如，JavaLand中的JBoss规则） 那么数据驱动的决策树方法呢？Rete规则引擎真的有必要吗？o是“企业工具”决定驱动您的选择吗
我会尝试设置规则引擎，使其尽可能与企业的其他部分分离。如果可以，我不会让它呼叫数据库或服务。最好将此作为要求作出决定的对象的责任。让他们调用必要的web服务和数据库来组装必要的数据，将其传递给规则引擎，并让它完成自己的工作。耦合是你的敌人：试着设计你的系统来最小化它。保持规则引擎的隔离是一种很好的方法。根据我使用规则引擎的经验，我们已经应用了一组相当基本的实践来管理与规则引擎的交互。首先，这些一直是商业规则引擎（iLog、Corticon）而不是开源引擎（Drools），因此，由于许可成本的原因，本地部署到每个应用服务器从来都不是一个可行的选择。因此，我们一直采用集中式模型，尽管有两种主要风格：
- Web服务的远程执行-与您在问题中指定的方式相同，我们调用规则引擎产品提供的基于SOAP的服务。在web服务领域中，我们有几种选择：（1）“Boxcar”请求，允许应用程序将处理请求的规则排队，并将它们分块发送，而不是一次性消息；（2） 调整供应商提供的线程和过程选项。这包括允许按功能分离决策服务，并为每个服务分配W3WP和/或使用web花园。你可以对boxcars、线程和进程进行大量的调整，而获得正确的组合与其说是一门精确的科学，还不如说是一个反复试验的过程（以及了解规则集和数据）
- 远程调用过程中的规则引擎——一个经典的批处理风格技巧，可避免序列化和反序列化的开销。远程进行调用，启动对规则引擎的进程内调用。这可以按计划（如批量）或根据需求（如“boxcars”请求）完成。无论哪种方式，都可以通过直接与流程和数据库交互来避免服务调用的大量开销。这个过程的缺点是，您没有IIS或EJB/Servlet容器为您管理线程，而您必须自己管理线程