When implementing a decision service, you may require state. But what is state and what is a stateful decision service?
Sometimes a decision service needs to consider information or context from previous invocations of the service.For example, you might want to award a customer discount if they purchased more than two items in one week. The information you keep about each invocation is called the state, and a decision service that uses state in its business logic is stateful.

This article discusses three ways you can build stateful decision services with ODM:

  • Build stateful rules with Decision Server Insights (DSI)
  • Build a stateful decision service with ODM and a tightly coupled database
  • Build a stateful decision service with ODM on Cloud and a loosely coupled database

This article will focus on ODM on Cloud and decision services with a loosely coupled database.

Identifying Stateful Rules

When designing a decision service, an important consideration is to determine whether it requires state.  If decisions are made purely on input data, it is stateless. Take the following stateless rule:

if
    the customer name is "Jon"
then
    set the discount of 'the customer' to 10%

The decision is based on the customer name.  There is no historical data and the rule is stateless.  Now consider this:

definitions
    set 'recent purchases' to the purchase history of 'the customer'
            where each purchase was made in the last week
if
    the number of purchases in 'recent purchases' is more than 2
then
    set the discount of 'the customer' to 10%

This rule applies a discount only if the customer has made more than two previous purchases in the last week.  The rule looks at the purchase history which makes it stateful.

Three Ways to Build Stateful Rule Applications

If your decision service requires state, you must decide how to implement it.  Consider the following:

  • The data throughput and performance of your stateful rules
  • The amount of state to be stored
  • Whether you are developing on premise, or on public or private cloud

This will narrow down your choice to three:

  1. DSI is your first choice if the solution requires high performance event processing. For example, DSI could be used for monitoring the state of engines.  This application would require dozens of sensors to process hundreds of events per second from the engine.  However, DSI is a powerful platform and it takes time to build and deploy applications. If your design goal is to create simple stateful decision services in short timescales you may wish to consider the next two options.
  2. Stateful XOM. It is possible to build stateful decision service with a XOM layered on a database.  The XOM fetches the context during each rule invocation.  Consider this approach if you are not using DSI and your rules require large amounts of contextual data.   Use this approach with caution as you will need to add database query code to the XOM which makes it hard to debug.  Also, be aware that accessing an external database from the XOM is incompatible with ODM on Cloud.
  3. Stateful Facade. Layer a façade over a database and a stateless decision service to implement a stateful decision service.  Consider this approach if you are storing a small amount of state and you are developing on ODM on Cloud.

The advantages and disadvantages of each approach are summarized below:

We will now discuss the Stateful Facade design pattern.

The Stateful Façade Design Pattern

The design pattern for creating a stateful façade over a stateless decision service is shown below:


The key component of this design is the Stateful Controller.  The Controller extracts state from a database and passes it to a stateless decision service.  The Controller may also write state back to the database.  The sequence of events is shown below:

  1. The client application requests a stateful decision via an API.
  2. The Stateful Controller extracts state associated to the request from the database.
  3. A stateless decision service is invoked with state passed in the input.
  4. The decision service executes business rules and passes back updated state in the output
  5. The updated state is stored in the database
  6. The Stateful Controller passes the response to the client

Tutorial

Now that you understand the concepts behind stateful decision services, you might be interested in the tutorial on GitHub.  The tutorial takes you through building a stateful decision service using the Stateful Façade Design Pattern.  The tutorial uses free trials of ODM on Cloud, Cloudant and Node-JS.

The steps for the tutorial are described in Tutorial.pdf.

Join The Discussion

Your email address will not be published. Required fields are marked *