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 |
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
- 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. |
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
- Possible performance implications due to externalized component relative to your applications
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.