JBoss.orgCommunity Documentation

Chapter 17. Architecture

17.1. Building from source
17.1.1. Modules
17.1.2. Working with Maven 2
17.1.3. Working with GWT
17.1.4. Debugging, Editing and running with Eclipse
17.2. Re-usable components
17.3. Versioning and Storage
17.4. Contributing

This section covers the technical aspects of Guvnor, it is not necessary to use this if you are integrating or an end user of the application. However, Drools 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 within another.

Architectural diagram

Figure 17.1. Architectural diagram


The above diagram shows the major components of the system and how they integrate and are deployed. The User Guide has more details on the parts that are highly configurable (e.g. database).

Guvnor is deployed as a WAR, which provides user interfaces over the web, and provides binary packages using URLs (or files). It uses 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.

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

Each module has a ready to go and up to date eclipse project configuration, so they can merely be imported into the eclipse workspace. These projects are generated by Maven. Use the mvn eclipse:eclipse command to refresh them in case they are wrong or outdated. They have been manually modified to have project dependencies which means that the code can be stepped through when debugging.

Some environment variables are required in eclipse (for 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 to launch from Eclipse: unit tests can be launched, as normal (in which case only M2_REPO setup is needed, GWT does not need to be downloaded separately), or it can be launched it in hosted mode using the GWT browser, which is great for debugging (from GUI to back end, the code can be stepped through, and changes made on the fly and simply hit refresh). There is a Guvnor.launch file in in the guvnor-webapp directory. To launch Guvnor in debug mode, open the Run dialog (Run->Run), and then choose Guvnor from the list. Launching this will open a new window, with Guvnor in debug mode, ready to go.

Downloading and debugging Guvnor with GWT is optional, so if there are no GUI issues being worked on then this step can be safely skipped.

Guvnor uses a service interface to separate the GUI from the back end functionality. In this case the back end both includes the asset repository (guvnor-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 using the asynchronous callback mechanism that GWT uses. The Seam configuration file is beans.xml. Refer to the Seam documentation, and the beans.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 is only one html page: Guvnor.html.

Normally Guvnor is intended to be deployed as its own WAR, however it can be combined with another application (with some care), but it is easier to keep it as a separate WAR. We recommend deploying Guvnor by itself because this will make it easier to upgrade to newer releases as they come out.

The Guvnor.html file can be customized. For example to change logos or embed Guvnor in another page. Take a look at the Guvnor.html file for details.

Refer to Chapter 12, Database configuration for for configuration options 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 Apache Jackrabbit, the *.cnd files are in the source for the node type definitions as some wish to view these. 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.

As an open source project, contributions from the wider community are encouraged. In order to contribute consult the wiki and project home pages. A useful way to contribute is via logging issues or feature requests in JIRA. This is JIRA link to use.