Eric D. Schabell: Examining Red Hat JBoss BRMS design time architecture for rules and events (part IV)

Friday, October 23, 2015

Examining Red Hat JBoss BRMS design time architecture for rules and events (part IV)

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

This is the forth and final part in the series started around possible Red Hat JBoss Business Rules Management System (BRMS) deployment architectures.

Previously we covered in three separate articles the various deployment architectures and rule authoring tasks you have to deploy a rules and/or events project in your enterprise.

In this article we move forward to the various aspects around rule deployments with a focus on the choices available to a rule administrator in delivering the rules to her enterprise applications.

Rule artifacts found in artifact repository.

Deploying with KieScanner

After the rule administrator builds a project it is available in the Artifact repository.  Select Open to get the contents of a pom.xml file.  The project is also downloadable as a jar file that can be included in your deployable artifact (e.g. EAR, WAR).

KieScanner deployment.
Once the project JAR is available in the Artifact repository the KieScanner will pick it up on the configured interval and load the new version into the KieContainer.

Any new KieSessions created in the application will be created against the latest version.

Deploying embedded

If you would rather not use the KieScanner or your rules do not change often enough to require a KieScanner then you can still embedded the rule project within your application.

Embedding rules artifact into application.
Once the project is built its available for download from the Artifact repository page in JBoss BRMS Business Central workbench.

This can be downloaded manually and included into another version control repository or can be accessed through an URL and included in your application:

  • http://localhost:8080/brms-central/maven2/<project_path> 
As an example based on our figures included in this article, our project artifact could be found here:
  • http://localhost:8080/business-central/maven2/org/kie/example/project1/1.0.0/project1-1.0.0.jar
Rule administrator defines a realtime decision server
by putting a rule project into a container.
In this situation the rule project JAR is included in your application deployable (e.g. WAR/EAR) as any other JAR file would.

Deploying realtime decision server

The final option available to a rule administrator has been included in JBoss BRMS 6.1,  an out-of-the-box rule decision server.  

This realtime decision server is deployed by default with JBoss BRMS, but can be deployed to any other web container since it’s a WAR.

Realtime decision server deployments.
Rules can then be instantiated and executed through REST, JMS, or Java interfaces. The realtime decision server manages containers that can run independently of each other. A rule administrator can create a container and select a rule project that will run in that container.  

Once the container is started applications can access them through the container endpoint, for example:
  • http://localhost:8080/kie-server/services/rest/server/containers/Container1  
The container then exposes all the functionality needed by an application through its REST interface as detailed in the documentation.

Going back

If you want to head back and catch up on the previous articles in this series:
Looking to Automate your business?


This concludes this series where we examined Red Hat JBoss BRMS design time architectures for rules and events, with thanks to John Hurlocker.


No comments:

Post a Comment

Note: Only a member of this blog may post a comment.