实际使用时，有四种使用URule Pro的方式，分别是嵌入式模式、本地模式、客户端服务器模式以及独立服务模式。

嵌入式模式

所谓的嵌入式，是指将URule Pro直接嵌入到我们的Java Web应用当中，作为应用的一部分运行。这种模式的好处是配置起来比较简单；而不好的地方在于因为将URule Pro直接嵌入到我们的应用当中，如果我们有多个涉及到规则引擎的应用， 那么每个应用都需要嵌入一个URule Pro模块，所以更多的时候我们使用的是独立服务模式。

本地模式

本地模式类似于嵌入式模式，所不同的是嵌入到我们客户端应用中的URule Pro模块仅仅为其规则计算部分(core部分)，不含设计器部分(console部分)； 之后将测试好的知识包导出为一个.data格式文件，然后把文件放在客户端应用的一个指定目录下或数据库中，这样客户端应用在调用知识包时就直接到这个指定目录下或数据库中查找目标.data文件并加载。

这种模式非常适用于规则运行环境封闭，且需要对外部屏蔽规则设计细节的应用需要，其部署模式简单、快捷，一旦有新的知识包放入指定目录中，客户端应用会自动检测并加载新的版本。

客户端服务器模式

客户端服务器模式是指将URule Pro部署为一个独立的Java Web应用，在这个应用里定义各个业务系统所需要业务规则，定义好后统一存储到一个规则存储仓库当中。 业务系统要使用规则时只需要指定URule Pro Server的地址即可通过HTTP协议取到目标规则包，然后解析并运行，其运行模式图如下所示：在客户端服务器模式下，一个URule Pro Server可以下挂多个需要用到规则引擎的业务系统，但实际的业务规则在运行时还是发生在各个业务系统中，而不是URule Pro Server上。

各个业务系统在运行业务规则时，会首先检查要运行规则对应的规则包在本地缓存中是否存在，如果存在则直接使用，不存在则通过配置的URule Pro Server地址向Server发出使用对应规则包的请求， URule Pro Server收到请求后会将指定的规则包序列化成JSON，通过HTTP协议传递给请求的业务系统。业务系统收到传递过来的规则包后，会首先对其进行反序列化，将JSON格式的规则包反序列化为Java对象并在本地缓存下来，然后再使用这个规则包进行业务规则的计算。

可以看到，在这个过程当中，URule Pro Server只负责业务规则的定义、编译与发布，不负责具体的业务规则执行，具体的规则执行还是发生在各个业务系统当中，可以大大减轻URule Server的压力，使得规则的计算可以分布到各个业务系统所在的服务器上， 从而可以根据需要对计算规则的服务器进行灵活的扩充。

客户端服务器模式下的规则包更新

在客户端服务器模式下规则包的更新有两种方式：一种是主动推送方式；一种为定时更新的方式。

主动推送方式是指URule Pro Server在规则包更新后，会主动将更新后的规则包通过HTTP协议推送到配置好的各种客户端业务系统应用的缓存当中，这样各个客户端业务系统中的规则包就可以与Server中的规则包时刻保持一致， 但这种推送方式要求对应的各个客户端业务系统应用必须是一个标准Java Web应用，否则这种推送无法实现，如果您的客户端业务系统应用是一个Java应用，而非一个标准的Java Web应用，那么要更新规则包就不能采用这种推送方式，而需要使用定时更新的方式。

定时更新方式是指具体调用规则的业务系统，可以通过相应的参数配置，周期性的检查URule Pro Server上当前客户端业务系统用到的规则包是否有更新，如果有则主动从Server上取下来并序列化成Java对应缓存到当前业务系统中备用，如果没有更新则不做任何操作。

所以如果您的业务系统是一个非Java Web应用，那么更新规则包可以采用定时更新的方式实现；相反如果您的业务系统是一个标准的Java Web应用，那么主动推送和定时更新两种方式都可以，当然主动推送的方式更为合适。

独立服务模式

独立服务模式也是规则引擎的传统运行模式，那就是把规则的调用以一个Restful服务的形式对外提供，客户端可以是Java、C#、C++或Javascript，客户端只需要把标准的JSON格式的输入数据提交给规则服务器，服务器调用规则计算完成后会以JSON格式作为响应返回。Restful服务支持安全验证， 提供完善的调用测试页面，同时对于输入数据，还支持复杂的JSON数据嵌套，以最大限度满足复杂业务需求；对于大批量并发调用，URule Pro提供完整的集群支持。