Examining 2 Ways to Deploy Rules and Event with Red Hat JBoss BRMS (part IV)

(Article guest authored together with John Hurlocker, Senior Middleware Consultant at Red Hat in North America)

In this week’s tips & tricks we will be revisiting the series started around possible Red Hat JBoss Business Rules Management System (BRMS) deployment architectures.

In the last article we talked about the various aspects around rule authoring with a focus on how a rule administrator in charge of your business logic can effectively complete the tasks needed to ensure proper delivery.

In this article we will describe some of the options available to a rule administrator when she wants to deploy rule projects into her enterprise in support of applications making use of them.

Rule artifact deployment

There are various deployment architectures available when using JBoss BRMS. The selection of one will often determine the course needed to be taken when deploying the final rules projects into your enterprise.

To recap the following list is has been covered in detail in the previous three articles (see bottom for links):

• Rules deployed in application
• Rules scanned from application
• Rules execution server
• Hybrid of rules execution server

Based on how an application’s architecture is setup, there are several options available for deploying rule projects or artifacts to your applications. You can use the KieScanner in your application or you can include the rule artifact in your applications deployable artifact.

1. Deploy with application

Rules Packaged with you applications deployable artifact is the most static way to manage your deployments. 

Figure 1: Application deployment with rules artifact.

Each application adds a specific rules artifact version as a dependency that is included in the build of the deployable application artifact. This has been outlined in figure 1, where you see the Build Script block as a placeholder for your organizations continuous integration framework. This chain of tooling ensures the desired rules artifact builds and passes all testing. It will then obtain a copy of the applications code that builds and passes all testing. These two are combined to generate a deployable artifact which is then deployed onto the hosting application server.

For an example of this we can look at the Customer Evaluation demo project where we have an application that contains a unit test. This application depends on a specific version of the customer evaluation rules project, which is included in the project POM file.

<!-- KJar file from project. -->
<dependency>
     <groupId>customer</groupId>
     <artifactId>evaluation</artifactId>
     <version>1.0</version>
     <scope>compile</scope>
</dependency>

This ensures that our application will generate the deployable artifact that is based on version 1.0 of this rules project and no other.

Once deployed the rules can only be updated by building a new version of the rules project, updating the dependency and building the application again as described above.

What about dynamic rules updates?

2. KieScanner

If you are interested in dynamically updating rules without having to redeploy your applications and having the application then pick up the new rules, you need to setup the KieScanner.

Figure 2: KieScanner to monitor external rule artifacts.

In figure 2 the application is build with a KieScanner component configured which is started when the application artifact is deployed. It is configured to scan a repository for certain artifacts, like a specific version, only release versions or for the latest versions.

The specific version is as described above, use of LATEST refers to the latest released or snapshot version of a rule artifact, the most recently deployed rule artifact in your repository. Using RELEASE will get you the last non-snapshot release of the rules artifact in the repository.

For an example of this we refer you to the Cool Store demo project where the KieScanner is setup in our BRMSUtil class to scan for the LATEST version of the coolstore rule artifact.

public BRMSUtil() {    

     

    KieServices kServices = KieServices.Factory.get();

    ReleaseId releaseId = kServices.newReleaseId( "com.redhat", "coolstore", "LATEST" );

    kContainer = kServices.newKieContainer( releaseId );

    KieScanner kScanner = kServices.newKieScanner( kContainer );

    // Start the KieScanner polling the maven repository every 10 seconds

    kScanner.start( 10000L );

}

Now when we update our rule project, build a new version, the deployed application artifact does not need to be changed and will pick up the changes in 10 seconds. Every user of the application will then be using the newer rules.

This completes our series on examining the JBoss BRMS deployment architectures available to you for your enterprise and application development.

Go back to part I...

Go back to part II...

Go back to part III...