A REST API for Drools

Part of the work for the Drools 5 repository is a Rest API - to allow content to be accessed remotely. The initial purpose of this is to let assets in the repository be synced with files in a developers workspace.

Rest turns out to be a perfect fit, we have the usual verbs:

PUT: update content (create a new version).
POST: create a new asset
DELETE: delete an asset
GET: retrieve asset content, or package listing

All actions are of course in the context of a package - but this is all specified by the url:

http:///api/packages//

So for instance, doing a PUT to: http:///api/packages/SomePackage/SomeAsset.drl will update the content of the SomeAsset.drl.

This may be terribly useful to some, terribly un-interesting to others, but at the very least people should appreciate the ability to get and update content to files/workspace from the repository without error prone import processes.

BRMS for Drools 5

Also: Introducing Guvnor.



Guvnor is the new name for the BRMS. The term BRMS kind of has an industry meaning that is slightly different from what we call the Drools BRMS (when we say it, we mean the repository and web tools mostly). Hence, the name Guvnor (kind of related to governance - but really, it just sounds cool). On top of that, we are extending guvnor to manage other asset types - which aren't directly related to rules (but that's another story, for another day).

Anyway, the new look guvnor:


Hopefully, we will have snapshots and milestones available for this very shortly.

Here is a quite tour of some of the more interesting features:

1. Web based decision tables:

This is obviously quite different from the spreadsheet based ones, and use a similar approach to the guided editor to help you set up the table to allow people to enter rule data.

The columns are configured just so:


You can also configure lists of values, or use data driven enumerations (just like before):


You can of course mix and match this with other rule types, as not everything is easy to represent in decision tables.

The most interesting feature (to me) is the integrated testing UI. I am a big fan of test driving anything. So, you can do that with rules. You can specify what you expect your results to be for a given scenario. You can narrow that scenario to an individual rule, if you want, or you can exclude rules (you would want to do this if a particular rule had a destructive side effect). You can also simulate dates for checking date effective rules etc.
This sort of scenario based expectation testing works well when your rules focus on the data and the logic on the data, and avoid programmatic logic and external side effects, of course.

What a scenario looks like:

You can see the expectations (which has one failure in this case) and the input data.

Also, you can treat a list of scenarios as a test suite:

And then run it to get unit test like green/red bars (well all love seeing green !):


From this we can also see what percentage of rules were exercised (and thus increase our confidence that we almost know what we are doing !).

I demonstrated this in Melbourne last week, and this really helped clarify to people what it was all about.

BRMS Introduction - and progress update (Michael Neale)

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.

Business Rule System: To use or not to use? (Edson Tirelli)

One of the most frequently asked questions around is "Why would I want to use a Business Rules Engine?". Usually this question is immediately followed and is related to: "When should I use a Business Rules Engine and when should I not?".

Googling out there you will find several posts, papers and books about it. Examples:

From JBoss Rules Documentation
From Jess Documentation

Those questions are usually answered in terms of the benefits of using the core rules engine component (algorithm), and are all true. We can even state that they justify the need for themselves.

Although, one frequently under looked aspect is the benefit of rules governance you achieve when using a BRMS.

Business Rules require lifecycle management in the same way most other current Enterprise Technologies do.

If one looks at classical application development in an enterprise environment, no one can even imagine it happening nowadays without a control process, involving orchestration of activities, with authorization control for each of the steps, does not matter what is the actual used methodology. The whole process is usually supported by specialized tools, varying from Development Tools, Code Versioning Systems, Automated Integration Tests, and specially, Configuration Management tools.

In the same way, once Rules Engines allow us to separate Business Decision Logic from the application core code, it also allows us to implement a governance infrastructure for Business Rules. It means:

Allows specialized teams to work on each of the roles in a Business Rules lifecycle. For instance, business rules analysts are responsible for maintaining the business rules, while configuration management teams are the ones responsible for the deployment and application core developers worry only about using (interpreting) rules results.

Allows for fine grained control on the access and maintenance of the rules that control the Enterprise Business.

Allows for comprehensive auditing of implemented rules and all changes happening in the corporate environment.

Allows for rule sharing between different applications and corporate business processes. This as we know, allows for consistency between corporate processes and decision making, as well as reduced maintenance costs: a change in the single rule instance will reflect throughout the whole organization.

These advantages are in sync with SOA architecture goals, as well as governance requirements.

So, when analyzing the advantages of using a BRMS, also think about Business Rules Governance and the benefits it brings to the organization.

For more details on the requirements and features of such platform, you can refer to Mark's post about the JBoss Rules server.

[EDIT: Adding related links posted by fellow readers in the comments, as here it is more visible to other readers than staying in the comments.]

Thank you James for posting:

"There are a number of reasons why business rules can be better than traditional code and a lot of benefits to be gained.
There are also many excuses for not taking on business rules as an approach. I wrote more on these topics in my FAQ."

Also, thank you Rajgo:

"Especially, considering that rules are intrinsically more structured than code, it makes all the more sense to use a business rules Management System.
In addition to governance & management, and decision automation, BRMS can provide businesss rules analysis that one could use to refine their policies to meet business goals"