JBoss.org Community Documentation

- Prev
- Next

## Chapter 2. Release Notes

## 2.1. New and Noteworthy in KIE API 6.0.0

### 2.1.1. New KIE name

KIE is the new umbrella name used to group together our related projects; as the family continues to grow. KIE is also used for the generic parts of unified API; such as building, deploying and loading. This replaces the droolsjbpm and knowledge keywords that would have been used before.

Figure 2.1. KIE Anatomy

### 2.1.2. Maven aligned projects and modules and Maven Deployment

One of the biggest complaints during the 5.x series was the lack of defined methodology for deployment. The mechanism used by Drools and jBPM was very flexible, but it was too flexible. A big focus for 6.0 was streamlining the build, deploy and loading (utilization) aspects of the system. Building and deploying activities are now aligned with Maven and Maven repositories. The utilization for loading rules and processess is now convention and configuration oriented, instead of programmatic, with sane defaults to minimise the configuration.

Projects can be built with Maven and installed to the local M2_REPO or remote Maven repositories. Maven is then used to declare and build the classpath of dependencies, for KIE to access.

### 2.1.3. Configuration and convention based projects

The 'kmodule.xml' provides declarative configuration for KIE projects. Conventions and defaults are used to reduce the amount of configuration needed.

Example 2.1. Declare KieBases and KieSessions

    <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">

      <kbase name="kbase1" packages="org.mypackages>

        <ksession name="ksession1"/>

      </kbase>

    </kmodule>

Example 2.2. Utilize the KieSession

    KieServices ks = KieServices.Factory.get();

    KieContainer kContainer = ks.getKieClasspathContainer();

    KieSession kSession = kContainer.newKieSession("ksession1");

    kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));

    kSession.fireAllRules();

### 2.1.4. KieBase Inclusion

It is possible to include all the KIE artifacts belonging to a KieBase into a second KieBase. This means that the second KieBase, in addition to all the rules, function and processes directly defined into it, will also contain the ones created in the included KieBase. This inclusion can be done declaratively in the kmodule.xml file

Example 2.3. Including a KieBase into another declaratively

    <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">

      <kbase name="kbase2" includes="kbase1">

        <ksession name="ksession2"/>

      </kbase>

    </kmodule>

or programmatically using the `KieModuleModel`.

Example 2.4. Including a KieBase into another programmatically

    KieModuleModel kmodule = KieServices.Factory.get().newKieModuleModel();

    KieBaseModel kieBaseModel1 = kmodule.newKieBaseModel("KBase2").addInclude("KBase1");

### 2.1.5. KieModules, KieContainer and KIE-CI

Any Maven produced JAR with a 'kmodule.xml' in it is considered a KieModule. This can be loaded from the classpath or dynamically at runtime from a Resource location. If the kie-ci dependency is on the classpath it embeds Maven and all resolving is done automatically using Maven and can access local or remote repositories. Settings.xml is obeyed for Maven configuration.

The KieContainer provides a runtime to utilize the KieModule, versioning is built in throughout, via Maven. Kie-ci will create a classpath dynamically from all the Maven declared dependencies for the artifact being loaded. Maven LATEST, SNAPSHOT, RELEASE and version ranges are supported.

Example 2.5. Utilize and Run - Java

    KieServices ks = KieServices.Factory.get();

    KieContainer kContainer = ks.newKieContainer(

            ks.newReleaseId("org.mygroup", "myartefact", "1.0") );

    KieSession kSession = kContainer.newKieSession("ksession1");

    kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));

    kSession.fireAllRules();

KieContainers can be dynamically updated to a specific version, and resolved through Maven if KIE-CI is on the classpath. For stateful KieSessions the existing sessions are incrementally updated.

Example 2.6. Dynamically Update - Java

    KieContainer kContainer.updateToVersion(

                    ks.newReleaseId("org.mygroup", "myartefact", "1.1") );

### 2.1.6. KieScanner

The `KieScanner` is a Maven-oriented replacement of the KnowledgeAgent present in Drools 5. It continuously monitors your Maven repository to check if a new release of a Kie project has been installed and if so, deploys it in the `KieContainer` wrapping that project. The use of the `KieScanner` requires kie-ci.jar to be on the classpath.

A `KieScanner` can be registered on a `KieContainer` as in the following example.

Example 2.7. Registering and starting a KieScanner on a KieContainer

    KieServices kieServices = KieServices.Factory.get();

    ReleaseId releaseId = kieServices.newReleaseId( "org.acme", "myartifact", "1.0-SNAPSHOT" );

    KieContainer kContainer = kieServices.newKieContainer( releaseId );

    KieScanner kScanner = kieServices.newKieScanner( kContainer );

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

    kScanner.start( 10000L );

In this example the `KieScanner` is configured to run with a fixed time interval, but it is also possible to run it on demand by invoking the `scanNow()` method on it. If the `KieScanner` finds, in the Maven repository, an updated version of the Kie project used by that `KieContainer` it automatically downloads the new version and triggers an incremental build of the new project. From this moment all the new `KieBase`s and `KieSession`s created from that `KieContainer` will use the new project version.

### 2.1.7. Hierarchical ClassLoader

The CompositeClassLoader is no longer used; as it was a constant source of performance problems and bugs. Traditional hierarchical classloaders are now used. The root classloader is at the KieContext level, with one child ClassLoader per namespace. This makes it cleaner to add and remove rules, but there can now be no referencing between namespaces in DRL files; i.e. functions can only be used by the namespaces that declared them. The recommendation is to use static Java methods in your project, which is visible to all namespaces; but those cannot (like other classes on the root KieContainer ClassLoader) be dynamically updated.

### 2.1.8. Legacy API Adapter

The 5.x API for building and running with Drools and jBPM is still available through Maven dependency "knowledge-api-legacy5-adapter". Because the nature of deployment has significantly changed in 6.0, it was not possible to provide an adapter bridge for the KnowledgeAgent. If any other methods are missing or problematic, please open a JIRA, and we'll fix for 6.1

### 2.1.9. KIE Documentation

While a lot of new documentation has been added for working with the new KIE API, the entire documentation has not yet been brought up to date. For this reason there will be continued references to old terminologies. Apologies in advance, and thank you for your patience. We hope those in the community will work with us to get the documentation updated throughout, for 6.1

## 2.2. What is New and Noteworthy in Drools 6.0.0

### 2.2.1. PHREAK - Lazy rule matching algorithm

The main work done for Drools in 6.0 involves the new PREAK algorithm. This is a lazy algorithm that should enable Drools to handle a larger number of rules and facts. AngendaGroups can now help improvement performance, as rules are not evaluated until it attempts to fire them.

Sequential mode continues to be supported for PHREAK but now 'modify' is allowed. While there is no 'inference' with sequential configuration, as rules are lazily evaluated, any rule not yet evaluated will see the more recent data as a result of 'modify'. This is more inline with how people intuitively think sequential works.

The conflict resolution order has been tweaked for PHREAK, and now is ordered by salience and then rule order; based on the rule position in the file.. Prior to Drools 6.0.0, after salience, it was considered arbitrary. When KieModules and updateToVersion are used for dynamic deployment, the rule order in the file is preserved via the diff processing.

### 2.2.2. Automatically firing timed rule in passive mode

When the rule engine runs in passive mode (i.e.: using fireAllRules) by default it doesn't fire consequences of timed rules unless fireAllRules isn't invoked again. Now it is possible to change this default behavior by configuring the KieSession with a `TimedRuleExectionOption` as shown in the following example.

Example 2.8. Configuring a KieSession to automatically execute timed rules

    KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration();

    ksconf.setOption( TimedRuleExectionOption.YES );

    KSession ksession = kbase.newKieSession(ksconf, null);

It is also possible to have a finer grained control on the timed rules that have to be automatically executed. To do this it is necessary to set a `FILTERED` `TimedRuleExectionOption` that allows to define a callback to filter those rules, as done in the next example.

Example 2.9. Configuring a filter to choose which timed rules should be automatically executed

    KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration();

    conf.setOption( new TimedRuleExectionOption.FILTERED(new TimedRuleExecutionFilter() {

        public boolean accept(Rule[] rules) {

            return rules[0].getName().equals("MyRule");

        }

    }) );

### 2.2.3. Expression Timers

It is now possible to define both the delay and interval of an interval timer as an expression instead of a fixed value. To do that it is necessary to declare the timer as an expression one (indicated by "expr:") as in the following example:

Example 2.10. An Expression Timer Example

    declare Bean

        delay   : String = "30s"

        period  : long = 60000

    end

    rule "Expression timer"

        timer( expr: $d, $p )

    when

        Bean( $d : delay, $p : period )

    then

    end

The expressions, $d and $p in this case, can use any variable defined in the pattern matching part of the rule and can be any String that can be parsed in a time duration or any numeric value that will be internally converted in a long representing a duration expressed in milliseconds.

Both interval and expression timers can have 3 optional parameters named "start", "end" and "repeat-limit". When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

Example 2.11. An Interval Timer with a start and an end

    timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)

The value for start and end parameters can be a Date, a String representing a Date or a long, or more in general any Number, that will be transformed in a Java Date applying the following conversion:

    new Date( ((Number) n).longValue() )

Conversely the repeat-limit can be only an integer and it defines the maximum number of repetitions allowed by the timer. If both the end and the repeat-limit parameters are set the timer will stop when the first of the two will be matched.

The using of the start parameter implies the definition of a phase for the timer, where the beginning of the phase is given by the start itself plus the eventual delay. In other words in this case the timed rule will then be scheduled at times:

    start + delay + n*period

for up to repeat-limit times and no later than the end timestamp (whichever first). For instance the rule having the following interval timer

    timer ( int: 30s 1m; start="3-JAN-2010" )

will be scheduled at the 30th second of every minute after the midnight of the 3-JAN-2010. This also means that if for example you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

### 2.2.4. RuleFowGroup and AgendaGroups are merged

These two groups have been merged and now RuleFlowGroup's behave the same as AgendaGroups. The get methods have been left, for deprecation reasons, but both return the same underlying data. When jBPM activates a group it now just calls setFocus. RuleFlowGroups and AgendaGroups when used together was a continued source of errors. It also aligns the codebase, towards PHREAK and the multi-core explotation that is planned in the future.

## 2.3. New and Noteworthy in KIE Workbench 6.0.0

The workbench has had a big overhaul using a new base project called UberFire. UberFire is inspired by Eclipse and provides a clean, extensible and flexible framework for the workbench. The end result is not only a richer experience for our end users, but we can now develop more rapidly with a clean component based architecture. If you like he Workbench experience you can use UberFire today to build your own web based dashboard and console efforts.

As well as the move to a UberFire the other biggest change is the move from JCR to Git; there is an utility project to help with migration. Git is the most scalable and powerful source repository bar none. JGit provides a solid OSS implementation for Git. This addresses the continued performance problems with the various JCR implementations, which would slow down once the number of files and number of versions become too high. There has been a big "low tech" drive, to remove complexity. Everything is now stored as a file, including meta data. The database is only there to provide fast indexing and search. So importing and exporting is all standard Git and external sites, like GitHub, can be used to exchange repositories.

In 5.x developers would work with their own source repository and then push JCR, via the team provider. This team provider was not full featured and not available outside Eclipse. Git enables our repository to work any existing Git tool or team provider. While not yet supported in the UI, this will be added over time, it is possible to connect to the repo and tag and branch and restore things.

Figure 2.2. Workbench

The Guvnor brand leaked too much from its intended role; such as the authoring metaphors, like Decision Tables, being considered Guvnor components instead of Drools components. This wasn't helped by the monolithic projects structure used in 5.x for Guvnor. In 6.0 Guvnor 's focus has been narrowed to encapsulates the set of UberFire plugins that provide the basis for building a web based IDE. Such as Maven integration for building and deploying, management of Maven repositories and activity notifications via inboxes. Drools and jBPM build workbench distributions using Uberfire as the base and including a set of plugins, such as Guvnor, along with their own plugins for things like decision tables, guided editors, BPMN2 designer, human tasks.

The "Model Structure" diagram outlines the new project anatomy. The Drools workbench is called KIE-Drools-WB. KIE-WB is the uber workbench that combines all the Guvnor, Drools and jBPM plugins. The jBPM-WB is ghosted out, as it doesn't actually exist, being made redundant by KIE-WB.

Figure 2.3. Module Structure

## Important

KIE Drools Workbench and KIE Workbench share a common set of components for generic workbench functionality such as Project navigation, Project definitions, Maven based Projects, Maven Artifact Repository. These common features are described in more detail throughout this documentation.

The two primary distributions consist of:

- KIE Drools Workbench

  - Drools Editors, for rules and supporting assets.

  - jBPM Designer, for Rule Flow and supporting assets.

- KIE Workbench

  - Drools Editors, for rules and supporting assets.

  - jBPM Designer, for BPMN2 and supporting assets.

  - jBPM Console, runtime and Human Task support.

  - jBPM Form Builder.

  - BAM.

Workbench highlights:

- New flexible Workbench environment, with perspectives and panels.

- New packaging and build system following KIE API.

  - Maven based projects.

  - Maven Artifact Repository replaces Global Area, with full dependency support.

- New Data Modeller replaces the declarative Fact Model Editor; bringing authoring of Java classes to the authoring environment. Java classes are packaged into the project and can be used within rules, processes etc and externally in your own applications.

- Virtual File System replaces JCR with a default Git based implementation.

  - Default Git based implementation supports remote operations.

  - External modifications appear within the Workbench.

- Incremental Build system showing, near real-time validation results of your project and assets.

The editors themselves are largely unchanged; however of note imports have moved from the package definition to individual editors so you need only import types used for an asset and not the package as a whole.

## 2.4. New and Noteworthy in Integration 6.0.0

### 2.4.1. CDI

CDI is now tightly integrated into the KIE API. It can be used to inject versioned KieSession and KieBases.

    @Inject

    @KSession("kbase1")

    @KReleaseId( groupId = "jar1", rtifactId = "art1", version = "1.0")

    private KieBase kbase1v10;

    @Inject

    @KBase("kbase1")

    @KReleaseId( groupId = "jar1", rtifactId = "art1", version = "1.1")

    private KieBase kbase1v10;

Figure 2.4. Side by side version loading for 'jar1.KBase1' KieBase

    @Inject

    @KSession("ksession1")

    @KReleaseId( groupId = "jar1", rtifactId = "art1", version = "1.0")

    private KieSession ksessionv10;

    @Inject

    @KSession("ksession1")

    @KReleaseId( groupId = "jar1", rtifactId = "art1", version = "1.1")

    private KieSession ksessionv11;

Figure 2.5. Side by side version loading for 'jar1.KBase1' KieBase

### 2.4.2. Spring

Spring has been revamped and now integrated with KIE. Spring can replace the 'kmodule.xml' with a more powerful spring version. The aim is for consistency with kmodule.xml

### 2.4.3. Aries Blueprints

Aries blueprints is now also supported, and follows the work done for spring. The aim is for consistency with spring and kmodule.xml

### 2.4.4. OSGi Ready

All modules have been refactored to avoid package splitting, which was a problem in 5.x. Testing has been moved to PAX.

- PrevChapter 1. Introduction
- Top of page
- Front page
- NextChapter 3. Compatibility matrix