9.3. Architecture

This section covers the innards of the BRMS - it is not necessary to use this if you are integrating or an end user of the BRMS application. However, JBoss Rules is open source, so build instructions form part of the manual.

You may want to build from source if you want to re-use components, or embed the application in your own.

Architectural diagram

Figure 9.2. Architectural diagram


The above diagram shows the major components of the system and how they integrate and are deployed. The Admin guide has more details on the parts that are highly configurable (eg database).

The BRMS is deployed as a war, which provides user interfaces over the web, and provides binary packages via URLs (or files). It utilized the JSR-170 standard for data storage (JCR). JBoss Seam is used as the component framework, and GWT is used as the widget toolkit for constructing the ajax based web user interface.

9.3.1. Building from source

This section will go over the steps you will need to take to build various components. Mostly this is automated, but the manual process is described for thoroughness.

9.3.1.1. Modules

There are 2 modules: drools-repository (back end) and drools-jbrms (front end and rules integration). The drools-jbrms module depends on the drools-repository module, as well as other components. The BRMS is part of the main build for all of Drools - when you build Drools - you will also build the BRMS.

9.3.1.2. Working with Maven 2

Maven 2 is used as the build system. To get started, you will need to check out the WHOLE of the source tree for JBoss Rules. This includes the other modules, and the top level lib and repository directories (which are needed by the build). As the BRMS build is part of the main drools build.

Initially, you should go into the root of the jboss-rules checked out source tree, and run mvn install to install all the components for the inter project dependencies. If the build is broken (no ! say it isn't so !) you can use the flag -Dmaven.test.skip=true to prevent failing unit tests from preventing the build.

When you want to build the BRMS - you can go into the drools-jbrms directory, and run "mvn package" - this will run the tests, and then build a deployable war. The only thing this won't do is rebuild the GWT front end (see the next section for details on that). Once you have the war file (in the target directory) you should be good to go !

9.3.1.3. Working with GWT

The GUI widgets for the web front end are developed with GWT (google web toolkit). If you need to make changes to or build the GUI, you will need to download GWT separately. Once GWT is downloaded, you can modify the build.properties file in the drools-jbrms directory to point to where you installed GWT. Once you have this, you can use the ant tasks to build the GWT components, as well as launch GWT in debug/hosted mode should you desire. If you run the build, it will update the webapp directory in the project with the new "compiled" artifacts (GWT does not use JSP, only html and javascript at runtime).

9.3.1.4. Debugging, Editing and running with Eclipse

Each module has a ready to go and up to date eclipse project configuration, so you can just import them into your eclipse workspace. These projects are generated by maven (mvn eclipse:eclipse to refresh them in case they are wrong or outdated). They have been manually modified to have project dependencies (means you can step through code when debugging).

Some environment variables are required in eclipse (Window->Preferences->Java->Build path->Classpath variables): the M2_REPO, as normal, to point to where maven downloads shared dependencies. GWT_HOME should point to where you installed GWT. GWT_DEV must point to the platform specific "dev" jar that ships with the version of GWT you have.

How you launch from eclipse: you can launch unit tests, as normal (in which case you only need M2_REPO setup - you don't even need to download GWT seperately) - OR, you can launch it in "hosted mode" using the GWT browser, which is great for debugging (from GUI to back end, you can step through code, and make changes on the fly and simply hit refresh). There is a JBRMS.launch file in in the drools-jbrms directory. This should allow Eclipse to launch the JBRMS in debug mode - open the Run dialog (Run->Run), and then choose "JBRMS" from the list. Launching this will open a new window, with the BRMS in debug mode, ready to go

Normally

Downloading and debugging the BRMS with GWT is optional, and if you are only working on non GUI issues, you can skip this step.

9.3.2. Re-usable components

The BRMS uses a service interface to separate the GUI from the "back end" functionality - in this case the back end both includes the asset repository (drools-repository and JCR) as well as the compiler specifics to deal with rules.

The main interface is RepositoryService, which is implemented in ServiceImplementation. The GWT ajax front end talks to this interface (via the asynchrony callback mechanism that GWT uses). The seam configuration file is components.xml (consult Seam documentation, and the components.xml file for details).

This service interface may be re-used by alternative components or front ends.

The GWT user interface may be re-used - as it is GWT there is only one html page: JBRMS.html. For those familiar with GWT, each of the "features" can be used separate (eg in a portal) - look at the JBRMSFeature class and the classes that implement it (they can in theory be stand alone).

Normally the BRMS is intended to be deployed as its own war, however you could in theory combine it with your own application (with some care) - but it is easier to keep it as a separate war, and will make it easier to upgrade to newer releases as they come out.

The JBRMS.html file can be customized - for example to change logos or embed the BRMS in another page. Take a look at the JBRMS.html file for details (its very simple).

9.3.3. Versioning and Storage

The Admin guide goes over configuration options in some detail, for database and filesystems.

Versions of assets are stored in the database along with the data.

When "snapshots" are created, copies are made of the entire package into a separate location in the JCR database.

For those familiar with jcr and jackrabbit, you can look at the *.cnd files in the source for the node type definitions. In a nutshell, a package is a "folder" and each asset is a file: an asset can either be textual or have a binary attachment.

9.3.4. Contributing

Consult the wiki and project home-pages if you are interested in contributing. A useful way to contribute is via logging issues or feature requests in JIRA. However, if you are creating an issue in JIRA for the BRMS, it is important that you choose "drools-brms" as the component in the list in JIRA (or else it may get lost !)