This post continues experimenting with the sample application known as Weightwatcher to showcase a number of new technologies and techniques including:
- The all-in-one Vagrant image for OpenShift 3
- The OpenShift Origin 3 oc rsync feature
- Drools 6.3.0.FINAL KIE Execution Server (Decision Server)
- A method for rule life cycle management with Containers
Drools 6.3.0.FINAL
The Drools KIE Execution Server (Decision Server) now preserves the KIE Container state on restart. This means that you need only create the KIE Execution Server Container once and, moreover, upon restart your Decision Server is ready to immediately accept and process client requests such as to reason over incoming facts. It also makes it easy to deploy multiple stateless Decision Servers in a simple horizontally scalable (cloud friendly) manner.
OpenShift Origin 3 Vagrant Image
OpenShift Origin 3 has an all-in-one Vagrant image which allows a developer to quickly and easily build a complete OpenShift environment on their local workstation. In addition, OpenShift 3 now includes an rsync feature for copying files to/from the file system and OpenShift container (oc rsync).
Rule Life Cycle Management
One way to author rules is via the Drools workbench. This takes the form of a web application implemented as a war file known as drools-wb. The JBoss BRMS equivalent is known as business-central. The rules themselves live in a git repository consisting of a number of artefacts including a .jar file. To make these authored rules, and subsequent rule changes, visible to the KIE Execution Server it is necessary to promote these artefacts from the workbench repository across to the KIE Execution Server repository. There are various ways to accomplish this, but for this OpenShift 3 (Docker Container) centric example we are going to make use of the oc rsync feature to directly copy repository contents from one OpenShift 3 container to another.
Schematic
The steps to demonstrate this approach can be summarised as per below. In step 1, the Analyst creates and/or changes rules from his Browser pointing to the workbench application. Once satisfied with the changes, the Analyst selects build-and-deploy to permanently save the changes to the repository. To push the changes across to the seperate KIE Execution Server instances, the Analyst must first in Step 2 issue an oc rsync command to the Workbench container to copy down the repository contents to the (local) file system. Then in Step 3, the Analyst issues another oc rsync instruction but this time to copy the local file system based repository contents to replace the contents in the running KIE Execution Server container. These rync steps can, of course, be automated as necessary. Note that the KIE Execution Server becomes aware of changes to its rule repository via a configurable “scanning” behaviour which is not shown here.
Example
Visit GitHub for a worked example including documentation in chapter 6 of the above techniques.