Red Hat JBoss BRMS 5 is an enterprise-supported business rules management, business process management, and complex event processing system based on the JBoss community Drools project. The repository for business rules is a JCR implementation and BRMS 5 exposes a REST and WebDAV API for moving rule packages between environments. There are several ways to migrate a business rules repository from one code promotion environment to the other. This blog post lays out three different approaches, based on the level of formal process control at the organization.
Shared Server Model
Configuration
-
One BRMS server shared by all environments: dev, test, preprod, production
-
Deployment environments technically not 100% isolated from each other
-
BRMS management functions can preventunauthorized changes to production
Release Process
- Rules can be authored in various environments depending on programming interest/expertise of rule authors.
- Rules are snapshotted in BRMS server to identify them as release-ready.
- Once snapshot is made, the rules are available on new URL, hosted by the BRMS server.
- Rule snapshots are referenced by change-set.xml or properties files embedded in application (see next slide).
- Change-set.xml or properties file is updated to point to new snapshot URL.
- No export or deployment of rules necessary for promotion.
Runtime Environment
- Clustered, load balanced and highly available BRMS using Apache is recommended.
- Knowledge agents are responsible for caching rules in application tier and checking BRMS for updates.
- Application can continue to function even if BRMS server fails.
- Alternative to knowledge agents: references to package snapshots in application properties files, but need to set up own polling/caching (for ex., using JBoss Data Grid).
- Rules can be updated in production using Guvnor. Knowledge agent will see update and application logic is updated without redeployment or restart.
Repository Promotion Model
Configuration
- One BRMS for each environment
- Applications deployed in each environment only communicate with that environment’s BRMS server
- Deployment environments can be 100% isolated from each other
Release Process
- Rules can be authored in various environments depending on programming interest/expertise of rule authors.
- Two approaches to rule promotion, either of which should be scripted/automated through a build server:
- Small rule sets/models: Export repository from one deployment environment to the next when promotion happens. Be aware large rule sets/fact models can create long-running export jobs.
- Larger rule sets/models: WebDAV. Must maintain a list of rule packages/snapshots to be transferred and script the transfer operations.
- Only the DEV environment will have complete version history of all the rules. Repository export only captures latest rule version and overwrites repository of target server.
Runtime Environment
- Clustered, load balanced and highly available production environment BRMS using Apache is recommended.
- Rules can be updated in production at runtime without an application restart, but should only be done in emergency circumstances.
- Same knowledge agent or custom caching runtime approach of Shared Server Model applies here.
- Note: It is possible for production instance to fall out of sync with other environments unless you are careful to reproduce those changes in the upstream environments.
Dev-Only Model
Configuration
- One BRMS server, but only used for development of rules
- Deployment environments can be 100% isolated from each other
- Applications in deployment environments refer to rules embedded in application itself
Release Process
- Rules can be authored in various environments depending on programming interest/expertise of rule authors.
- Rules are snapshotted in Guvnor but exported as PKG (binary) files as part of automated build process.
- PKG files are bundled with the application and checked into version control systems with application code.
- Upon release, source code and PKG files are tagged, built, and deployed together to the next environment (dev to test, test to preprod, etc.).
- Releases might involve complete redeployment or patch process could target specific rule PKG updates. Releases will likely require an application restart.
Runtime Environment
- Application refers to local PKG file for rule execution.
- No connection to a BRMS server needed at all at runtime (no checking for rule updates, caching, or knowledge agent configuration).
- BRMS server does not require clustering or high-availability, because it is deployed in the development environment only.
- Rules cannot be updated at runtime in production.
- Code always refers to compiled PKG binaries.
- Only way to update application’s PKG files is to tag, build, and release using the standard release management practice.
