The goal of this guide is to provide a detailed description about the configurations specific to the BRS. There are two types of configurations: rule-component.conf and services.xml and next sections discuss those in detail.
Rule component configuration is to provide the capability to define the configuration information related to the rule component . The configuration for the rule-component.conf is shown bellow.

RuleEngineProvider : The class is to specify the rule service provider implementation. The default one is org.wso2.carbon.rule.engine.jsr94.JSR94BackendRuntimeFactory. The default JSR94 API provider is the open source Drools rule engine. Properties are to be used to specify configuration information for the rule service provider. For example, for the JSR94BackendRuntimeFactory , there are two important properties : class and uri. The class is to provide the JSR 94 rule service provider and the default value for it is org.drools.jsr94.rules.RuleServiceProviderImpl. The uri is to provide the JSR 94 rule service provider URI and the default value of it is http://drools.org/.Another import property is default.properties.provider, which can be used to provide default properties to be used when creating rule execution sets and loading rule service provider.
FactAdapters : To register adapters for creating facts to be injected in to the rule engine from the data in the message. The registered fact adapters can be used within fact definitions by specifying the name of a fact adapter.
ResultAdapters : To register adapters for handling results from the rule engine execution.The registered result adapters can be used within result definitions by specifying the name of a result adapter.
A example rule-component.conf is shown bellow.
<RuleServer>
<RuleEngineProvider class="org.wso2.carbon.rule.engine.jsr94.JSR94BackendRuntimeFactory">
<Property name="default.properties.provider"
value="org.wso2.carbon.rule.engine.drools.DroolsJSR94DefaultPropertiesProvider"/>
</RuleEngineProvider>
</RuleServer>The configuration to be used to provide information required to expose a rule script as a web service. There are two important parts in the services.xml of a rule service: rule set definition and facts/results definitions.
<ruleService name="xs:string" tns="xs:string">
<description>xs:string</description>
<ruleset [ path="xs:string" ] [ key="xs:string" ]>
In-Lined
</ruleset>
<operation name="xs:string"> *
<with-param type="xs:string"/>*
<result [ name="xs:string" ]>
<element type="xs:string"/>*
</result>
</operation>
</ruleService>RuleSet definition
ruleset configuration is to specify the rule script which can be in the classpath, registry, or in-lined.
Facts/Results definitions
Facts/results configuration is should be specified per operation. Facts are used for formulating the facts to be inserted into the rule engine from the incoming message. These also are used in constructing in-message of the WSDL for a rule service. Results are used to extract the results of a rule engine execution and used in constructing out-message of the WSDL for a rule service.
An example for a .drl for a rule service is shown bellow.
OrderApprovalService Rule Service Configuration - OrderApprovalService.drl
<ruleService name="OrderApprovalService">
<description>OrderApproval Service Description</description>
<ruleset path="conf/rules.drl"/>
<operation name="placeOrder">
<with-param type="samples.userguide.PlaceOrder"/>
<result>
<element type="samples.userguide.OrderReject"/>
<element type="samples.userguide.OrderAccept"/>
</result>
</operation>
</ruleService>