Eric Schabell

About Eric Schabell

Eric D. Schabell is the JBoss technology evangelist for Integration and BPM products at Red Hat. He is a writer, cyclist and software engineer but not always in that order.

Examining Red Hat JBoss BRMS deployment architectures for rules and events (part I)

(Article guest authored together with John Hurlocker, Senior Middleware Consultant at Red Hat in North America)
 
tips-and-tricks
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, starting this week with the first 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
image1
Illustration 1: Rules in application

Rules deployed in application

The first architecture is the most basic and static in nature of all the options you have to deploy rules and events in your enterprise architecture.

A deployable rule package (e.g. JAR) is included in your application’s deployable artifact (e.g. EAR, WAR).

In this architecture the JBoss BRMS server acts as a repository to hold your rules and a design time tool.
Illustration 1 shows how the JBoss BRMS server is and remains completely disconnected from the deployment or runtime environment.

 

Pros

  • Typically better performance than using a rule execution server since the rule execution occurs within the same JVM as your application

Cons

  • Do not have the ability to push rule updates to production applications
    • requires a complete rebuild of the application
    • requires a complete re-testing of the application (Dev – QA – PROD)

 

image2
Illustration 2: KieScanner deployment

Rules scanned from application

A second architecture that you can use to slightly modify the previous one,
is to add a scanner to your application that then monitors for new rule
and event updates, pulling them in as they are deployed into your enterprise architecture.

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,
as shown in illustration 2.

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.

Pros

  • No need to restart your application servers
    • in some organizations the deployment process for applications can be very lengthy
    • this allows you to push rule updates to your application(s) in real time

Cons

  • Need to create a deployment process for testing the rule updates with the application(s)
    • risk of pushing incorrect logic into application(s) if the above process doesn’t thoroughly test

Next up

Next time we will dig into the two remaining deployment architectures that provide you with an Execution Server deployment and a hybrid deployment model to leverage several elements in a single architecture. Finally, we will cover a design time architecture for your teams to use while crafting and maintaining the rules and events in your enterprise.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


− two = 5



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close