Examining Red Hat JBoss BRMS deployment architectures for rules and events (part II)
(Article guest authored together with John Hurlocker, Senior Middleware Consultant at Red Hat in North America)
In this weeks tips & tricks we will be slowing down and taking a closer look at possible Red Hat JBoss BRMS deployment architectures.
When we talk about deployment architectures we are referring to the options you have to deploy a rules and/or events project in your enterprise.
This is the actual runtime architecture that you need to plan for at the start of your design phases, determining for your enterprise and infrastructure what the best way would be to deploy your upcoming application. It will also most likely have an effect on how you design the actual application that you want to build, so being aware of your options should help make your projects a success.
This will be a multi-part series that will introduce the deployment architectures in phases. You can catch up on last weeks article before continuing with this weeks look at the next two architectures.
The possibilities
A rule administrator or architect work with application team(s) to design the runtime architecture for rules and depending on the organizations needs the architecture could be any one of the following architectures or a hybrid of the designs below.
In this series we will present four different deployment architectures and discuss one design time architecture while providing the pros and cons for each one to allow for evaluation of each one for your own needs.
The basic components in these architectures shown in the accompanying illustrations are:
- JBoss BRMS server
- Rules developer / Business analyst
- Version control (GIT)
- Deployment servers (JBoss EAP)
- Clients using your application
Rules execution server
What you are doing in this architectural scenario is deploying JBoss BRMS as an application in its own environment. You can then expose it as a service (e.g. JMS, SOAP, etc.) so that any applications in your enterprise architecture can remotely execute rules and events.
 |
| Illustration 1: Rules execution server |
This deployment architecture completely externalizes the entire JBoss BRMS rules and events component from your application development process as shown in illustration 1. It then only requires an application to make an external call for rules or event decisions.
Pros
- Completely decoupled architecture
- Common implementation to setup and execute rules
- Upgrades to BRMS versions become easier with single point of focus in your enterprise
Cons
- Possible performance implications due to externalized component relative to your applications
- The execution server could be used by multiple applications.
- a team will need to take ownership of this application and maintain it
Hybrid of the rules execution server
As a final example we present a hybrid architecture that leverages the previous basic rules execution server architecture and adds in the previously discussed (in part I) KieScanner component.
 |
| Illustration 2: Hybrid architecture. |
With this architecture you have the ability to develop applications that just leverage a remote call to execute rules and events decisions, but add in the mix of being able to update rules and events packages without changing the execution server service structure.
As a refresher, remember that the JBoss BRMS API contains a KieScanner
that monitors the rules repository for new rule package versions. Once a
new version is available it will be picked up by the KieScanner and loaded
into your application.
The Cool Store demo project provides an example that demonstrates the usage of JBoss BRMS KieScanner, with an example implementation showing how to scan your rule repository for the last freshly built package.
Illustration 2 shows how the rule execution server is now hosting a KieScanner implemented component to monitor the rules and events packages for updates which would then automatically be picked up for the next application that calls.
Pros
- Completely decoupled architecture
- Common implementation to setup and execute rules
- Upgrades to BRMS versions become easier with single point of focus in your enterprise
- Less maintenance for the execution server component
Cons
- Possible performance implications due to externalized component relative to your applications
Next up
Next time we will take a look at the design time architecture and the options for you to deploy your rules and events into your architecture.
| Reference: | Examining Red Hat JBoss BRMS deployment architectures for rules and events (part II) from our JCG partner Eric Schabell at the Eric Schabell’s blog blog. |
