KIE Community

Well, its been a while since any updates. In the mean time I have moved house, twice, once to Sydney (temporarily) and then back to my home in Queensland, so its been a disruptive period. I have been working out of the wonderful Red Hat Sydney office (North Sydney, photos later – amazing view !), as well as dropping into the Queensland office (no photos, not so scenic).

So, introducing the BRMS: The BRMS has (roughly) 3 aspects:

1. BRMS Administrators,
2. Users of all kinds, and
3. Developers/architects.

These 3 aspects correspond to the 3 groups that will be using it, in many cases there is overlap (ie users could be developers, or users could be non technical, or a developer could be all three !). Keep this rough division in mind when reading through the rest of this introduction (not all the functionality applies to all the groups).

Of course, the pretty stuff you see is just the icing on the web cake, but there is plenty going on underneath, as has been covered before, so I won’t bore you with it. Its important to note that the IDE (as shown previously by mark) forms a part of this (but I won’t cover it here). This, coupled with recently described new features makes for a load of goodness.

The BRMS (starting from an empty state following a rough order in which things may happen):

Categories: As mentioned previously, generally you want to start with some categories created to help you find your rules. Categories are completely non technical, in the sense they can be called whatever you want, and do whatever you want, they have no bearing on how the rules work. This would normally be a BRMS Admin type of job.

Status Management: You can use status flags (any item can only have one status at a time, whereas it can have multiple categories) to manage, well, statuses (or statii???). This can effect deployment (if you want it to). The system starts with just a “Draft” status – any new changes are saved as draft status. You can add more to this list. Statuses are applied either on the individual “asset” level, or at a whole “package” level – if you do it at the package level it applies it to all the assets below it. This would normally be an Admin job.

Assets: I have mentioned “assets” – well the short version is that they are really just rules, or a decision table, or a chunk of rules, or a model, or a document – any thing that you want to treat as one controlled, versionable unit (an “atomic” unit if you like). This also includes other config and definition items needed for rules, and in future, things like processes and service definitions. We have a dream. This is a KEY POINT to keep in mind, if your mind is as warped as mine.

Packages: packages, in this sense, are a physical grouping of rules. This grouping is a bit like a folder, and would certainly make sense to developers and technical users. You can view the world through packages if you like, but as your rules and packages get more numerous, categories can be a more flexible and controlled way of finding rules
/assets.

The package view of the world looks something like the following:
From here you can browse for rules, or you can view and edit the package configuration (all the top level stuff you need to make a ruleset work). This is a fairly technical view of the world.

Nice view: I thought I would share a nice picture of the desk I was at in the Sydney office, just to keep everyone interested:

(if you look carefully you will see the tip of the Sydney Opera House).

Browsing a package: Packages show a breakdown of broad asset types, according to their “format” (which is a Dublin Core attribute, for those who care).

(showing browsing a list of “business rules”)

This little bar of “hieroglyphics” allow you to launch various wizards to create new things (packages, models, rules etc) from within the package view of the world. There are tool-tips to tell you what each one does.
There are also some other wizards which can help you out with configuring the package, should you need help !

Uploading stuff: Should you need some jar’s for a model, then that respective “asset type” will allow you to upload stuff (uploading automatically creates a new version of something – so you can’t accidentally overwrite it):

Browsing rules: When you use the rules “tab” – you can use the previously defined categories to navigate lists of rules.
Authoring rules: This is one of the fun parts. There are many many ways to author rules, some formats are ideal for the IDE, some are good for the web, lets take a look at a few key ones:

(shot of the modeller in action)

The rule modeller uses knowledge of the package to provide a “guided editor” for rules. This can be augmented with DSL configurations if needed. We haven’t decided the final name for this. There is also an eclipse version in the works:

Phew, thats a lotta buttons. On the left hand side of the web view is all the boring “meta data” including lists of categories that the rule belongs to. The bottom right is the all important documentation.

Some people have asked how this is stored: well, as mentioned previously, it depends on the “asset” format itself – the repository is content agnostic in that regards (it can and does store anything, in any format). At the moment the modeller uses XML, but this will most likely be enhanced to be DRL itself, and RuleML (in the case of RuleML, many features will have to be disabled to produce RuleML compliant rules). In any case, you probably don’t really care about that. So its time for another picture:

(even DSL rules are in on the action, complete with content assist, many people still like the personal tough you only get with plain text).

More wizards than Middle Earth: Creating a new “rule asset” is done through wizards (on the web anyway):

Before I go, I will show briefly the “snapshot” and deployment features. You can, at any time, take a “snapshot” of a package, and all its “assets” – which can be used for deployment. This snapshot is frozen (read only normally), and lives in a separate “area” to allow you to make concurrent changes to the rules themselves. There can be as many snapshots as you like, and they are “labelled” according to some meaning you give them. You can copy snapshots, delete, or simply update them with the latest. Some screen shots may help:

(shows creating a snapshot of a package – either replace existing, or create a new label)

(this shows a list of snapshots, from the “deployment” tab) of course this is an Admin feature !

(this shows a frozen view of a package, exactly as you took it, back in the good olde days).

History/versions: Every change you make to an “asset” is versioned – you can at any time view the history, and with one click restore any item (and you can undo that restore of course) – I tried to make it as intuitive as possible :

And finally, I will leave with a photo of the Really Cool foyer of the Sydney office:

OK, that’s it, that should be sufficient for now.

Enjoy !

PS this is of course available in SVN, we always develop out in the open: drools-repository and drools-jbrms are the models for anyone crazy enough.

Michael.