Service-Oriented Rule Architectures

Using InRule with Service-Oriented Architectures (SOA)

Due to the flexibility of the InRule SDK and the .NET framework, InRule can be configured to run in a vast array of possible application architectures. However, many customers today consider business rule processing to be an enterprise service, with the same service being available to many disparate systems. A single rule processing service may be required to process rules for many different business problems against many different data schemas. A platform-agnostic service interface and expose rule execution to many other platforms built on various technology stacks.

With InRule, it is possible to easily create a "generic" service interface using WCF or Web APIs that can accept and return many different data schemas. In addition, this service can accept input that denotes which rules should be run against a given set of data. A service with this interface is then capable of reuse across many different business problems and potential calling applications.

Most reusable services have some basic requirements to be considered "enterprise" services, all of which are accommodated by the WCF or Web API services approach and the free-threaded capabilities offered by InRule:

• High availability
• Scale-out easily as demand grows, without changing code
• Multi-threaded request handling 

Note that InRule does offer stateful rule processing as part of the rule session, but most rule services are designed to be stateless so that each rule request is completely independent of every other rule request. In the stateless scenario, a rule session is only used for a single request and then discarded. The stateless architecture offers far more flexibility for scale-out and declarative deployment, and is therefore recommended over stateful approaches wherever possible.

A sample SOA for Business Rule processing.

Stateless rule service requests are spread across one or more identical rule processing servers.