We now have Guvnor displaying uploaded Drools Flow files. We use the native GWT XML api to read in the XML document and GWT Diagram to generate the diagram. At the moment it's view only, over time we will make it editable - which will sure beat round tripping with Visio that other platforms do.
The Guvnor (BRMS) and Eclipse synchronisation tool has made leaps and bounds in progress for the upcoming 5.0 Milestone 2 release. It now has full bi-direction synchronisation of files between Eclipse and Guvnor. A developer can now work locally with a rule, or other Guvnor assets, they can do lots of small commits to their SCM of choice and when they need to can upload or synchronise that asset with Guvnor. Eclipe diff viewing is also supported.
Synchronisation
Diff Viewer
Version HistoryIn Guvnor, there are many different widgets that are used to display or edit different assets. One interesting widget is about to be added - a widget that could accept images and display them. For this purpose, rolodex, a widget that can display a stack of images, can be used. Rolodex uses deferred binding for the image generation and animation. Let's see how can we quickly add a new widget displaying some predefined images.
First, create a class, implementing RolodexCardBundle interface (from the rolodex library) and declare a few methods that will return the images (just like ImageBundle described in the book):
public abstract class Images implements RolodexCardBundle {
/**
* @gwt.resource img_3861.jpg
*/
public abstract RolodexCard imgA();
/**
* @gwt.resource img_3863.jpg
*/
public abstract RolodexCard imgB();
/**
* @gwt.resource img_3865.jpg
*/
public abstract RolodexCard imgC();
...
private final RolodexCard[] cards = new RolodexCard[]{ imgA(), imgB(), imgC() };
public RolodexCard[] getRolodexCards() {
return cards;
}
}Next, to display those images, create ImageSetWidget (or you-name-it) class extending DirtyableComposite:public class ImageSetEditor extends DirtyableComposite {
// asset and viewer are not used now...
public ImageSetEditor(RuleAsset asset, RuleViewer viewer) {
final Images images = (Images) GWT.create(Images.class);
final RolodexPanel rolodex
= new RolodexPanel(images, 3, images.imgA(), true);
initWidget(rolodex);
}
}
For Guvnor to be able to launch the editor, we have to modify EditorLauncher class:...AssetFormats should be supplied with the new constant for this new type, of course.
else if (asset.metaData.format.equals(AssetFormats.IMAGE_SET)) {
return new ImageSetEditor(asset, viewer);
...
m.addItem(new Item("New ImageSet",
new BaseItemListenerAdapter() {
public void onClick(BaseItem item, EventObject e) {
launchWizard(AssetFormats.IMAGE_SET, "New ImageSet", true);
}
}, "images/rule_asset.gif"));<inherits name='com.yesmail.gwt.rolodex.Rolodex'/>Now, after the project has been rebuilt and redeployed we get the following widget on the screen:
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://
So for instance, doing a PUT to: http://
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.
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.
There is a new BRMS example available. It is written up in the manual as a tutorial, but the information is repeated here. We are having some issues with our build server - so the docs available in the snapshots are probably not as up to date as the source is.
-------------
Fernando runs a dodgy fly by night insurance operation in Sao Paulo, Brasil. These are his rules - would you buy insurance from him ? (I wouldn't).
This example takes you through the key steps in using the BRMS with an example respository, and using rules in a very very simple application (which you can use as a basis for your applications).
So after my last post about the contracting market starting up, we see a new jobserve.com posting for the BRMS, before we even release it :)
Role: Software & Solution Developer/JBoss Rules Expert. Job purpose & accountabilities: JBoss rules expert for PIDP project - risk assessment. Assist tech lead with solution HLD. Assist in solution LLD. Build rules engine... Skills mandatory: JoBoss - mandatory New JBoss BRMS component... Successful candidates will be required to be security cleared prior to appointment.
Employment Business Capital International HR Solutions
I just read this article over at infoq which is titled "CentraSite: Registry/Repository and Free Community Edition". I'm glad that someone is getting this message out, it's something I've been pushing internally for a while now; Enterprise Government is serious and important stuff and deserves more attention.
I want people to realise that rules, processes, policies, xstl transformations, routing configurations, hibernate mapping files etc are all important pieces of enterprise knowledge, for this reason I also prefer the term "asset" to "artefact" to signify that these artefacts are assets of value. I also believe the term "Registry/Repository" under sells the idea. You aren't just creating a JNDI lookup type system for files, all stored assets are versioned along dublin core meta data and user defined classifications. These assets can be be further combined to create configurations of assets, also versioned. If we talk in terms of "rules" you create a package which is a configuration of one or more rules; a specific package configuration will use a specific version of a rule, just because a rule gets updated doesn't mean I want that version of the package configuration to use the newer version of the rule; if I want that I have to create a new version of the package configuration. This provides an important level of auditing, it means applications using this system can be audited to let us know at any point in time what policies where being applied.
Our BRMS, which we are thinking of renaming to KAMS, is a step in this direction. At the core it's just versionable, categorisable and configurable assets, of any type built ontop of Jackrabbit JCR - which is a much stronger spec than JXR which CentreSite is built on. This is in fact a seperate and self contained project, seperate from any rules or gui stuff. Ontop of this is the BRMS, which is built with GWT, currently much of this is hard coded for asset types - like rules, process etc. The plan is to eventually refactor this into a base system with extension points for different asset types.
I have created the first Quick Start movie, which is an introductory tutorial to the BRMS.
This is my first attempt using "Wink" - and I realized that I had the screen resolution set too high after the fact, so consider this a practice run. I would appreciate any feedback on this. Click the image below to display the window in a popup.
Those having problems with the popup window can use this url directly:
http://wiki.jboss.org/wiki/attach?page=RulesRepository%2FQuickStart.swf
The BRMS (Business Rule Management System) has been in the works for sometime. Well, finally, there is something you can use, which works end to end. This is now part of the JBoss Rules 4 Milestone releases, so please, go ahead and start testing it ! There has been great work going on elsewhere in Drools, with respect to the language features, core engine enhancements and the IDE as well (see previous posts).
For a very interim user guide, you can refer to the wiki Quick Start for BRMS. Much more documentation, tutorials etc is on the way.
You can use the milestone releases, or ideally the snapshots (as found here, referring to the wiki link above to make sure you have the latest info, also keep an eye on this blog).
The best way to get going is to take a look at the quick start guide (linked above) and also have some ideas for a model that you want to write rules over (as one of the first things you will do is configure a package).
As always, you can contribute: helpful bug reports are appreciated, as are contributing some specific examples. The wiki is also available to record notes/tips, which can feed into the manual/documentation. I plan on working on a flash based tutorial (a few tutorials will be needed to introduce the concept).
So, the whet the appetite, some screen shots, which show some of the new rule authoring capabilities, as well as the life cycle management are shown (they are not in any particular order, but you can guess what most of them are showing !).
SBVR is a OMG standard for natural language rules and vocabularies (nominally using English). We think SBVR (Semantics of Business Vocabulary and Business Rules) is an important and useful standard, which can be used for rules interchange in a "source" and human readable format (which RuleML? and RIF are not aiming to do).
From a users point of view, there are 2 main aspects to using SBVR (I am skipping the grander vision for SBVR, which goes beyond production rules, I believe, but for now, lets keep it simple, and relevant to us):
SBVR comes under Model Driven Architecture (MDA), and is defined a "Computation Independent Model" (CIM) - what that means to you, is that SVBR is designed primarily for human consumption. However, it is defined in terms of formal logic, and detailed enough to generate models and rules for a specific platform. The next layer "lower down" to CIM in MDA is PIM (Platform Independent Model) - which is where things like RuleML come in. Lower again in MDA terms is the PSM (Platform Specific Model) - this is where rule engine specific languages kick in.
Anyway, enough of my flawed MDA tutorial (if you have followed along this far, well done !). We are working with These guys
to have tooling and a SBVR framework to author rules, and manage vocabularies for JBoss Rules (narrowing SBVR down to production rules to start with). Although SBVR is a CIM (see above) - we think its possible as a format for capturing business rules, and actually generating executable rules directly (perhaps with some assumptions built in - for instance SBVR vocabularies are not strong on data type information that I am aware of).
The first steps are a proof of concept to generate DRL rules from SBVR.
I am also interestsed in the SBVR vocabulary definition "language" as a generic "business object model" for the rule engine to use (regardless of if SBVR is used) - still under investigation.
So, what can I do with SBVR?
This is where you define concepts about the business model, and things like synonyms, all of which help SBVR understand sentences.
You can see content assistance is pretty critical - this is a structure language, but much more free form then templates allow, but still - smart content assistance like is being showed here is invaluable.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:
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.
(if you look carefully you will see the tip of the Sydney Opera House).
(showing browsing a list of "business rules")
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.
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:
(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).
(shows creating a snapshot of a package - either replace existing, or create a new label)
(this shows a frozen view of a package, exactly as you took it, back in the good olde days).
Well I have had a great time in London, but it has gone fast. The entire purpose of this extended trip was to spend quality time with Mark so we could put our heads together and solve some of the hard design issues for the rules repository and version 3.2 (which who knows, may be called version 4?). I think we have achieved a lot.
So sad to be leaving, but also will be nice to be "home" again, still doing the same job of course ! (amazing how hard it is for people to understand that who have "real" jobs).
The rules repository has come along nicely (and we have of course been thinking about the often requested ability to package up process definitions a-la jBPM as well, but that's another story).
So a quick update is in order I believe.
User driven categorisation is working out nicely:
They allow a simple hierarchical classification scheme (of your choice). Thanks to the magic of power arithmetic, you can manage a very large number of rules with a very shallow "tree" of categories. We don't have user specified fields (yet) but its easy to add - initially we want to encourage people to manage rules in something of a standard way (of course, we are prone to being influenced by peoples opinions).
Dublin core makes for a kind of useful set of standard "content attributes" that people can attach meaning to (with the hope that external systems in the future will be able to report and examine the rule base in a meaningful way).
The rule modeller (UI) mentioned before is also working out nice.
Of course, all the meaty stuff has been happening under the covers, so not much time to work on Look and Feel, but that should be changing shortly. Other rule authoring paradigms are plugging in as well. Of course, and it is all being integrated to work with the IDE tooling as much as possible.
Efficient versioning: Every save action in the repository is version ed. This (default) behavior may cause some alarm, due to the number of versions created. Thankfully, the concept of "workspaces" for storage means that the version storage can (if needed) be configured to be on a separate larger device/database to the main repository, allowing for huge rule bases to scale, very handy.
In other news, the "mvel" integration (a simple expression language) is coming along, and should be in the M1 release (more about that in another blog).
We also now have effective dating of rules, which is a handy (and often asked for feature, but often forgotten about-to-implement).
The next steps for the repository (which is as much a list to remind me after I get over the wicket jetlag that is about to hit):
* Archiving of rules (not as easy as it sounds, at least to make it usable).
* Audit logging and reporting (a lot of audit ability is intrinsic to the repository, but still, I have seen many an audit log grow unusable over time).
* Efficient introspection of the rule object model (as we are still pojo based, requires some magic)
* Keeping configuration options under control ;) want it to be as "out of the box" as possible and not terrify people with the possibilities !
* Version browser (started this on Friday, ran out of time !)
* Package management
- packages are sets of rules, which are "baseline" versioned for deployment. This will provide a more technical view of the rule assets in a tree structure (so you can view rules either via categories, or packages). Need to make this as intuitive as possible with sensible defaults.
Comments.
Often you hear/read/see adds for tools (rules or workflow) that claim breathlessly "look ma ! no code" - "rules with out code" - giving control back to the business etc.
(if you haven't, then you obviously have a good marketing detector, and are able to mentally filter out marketing messages). Some products live up to this impossible claim more then others (and some a despicable lies, of course never in the rules community !).
An impossible claim? What did you say?
I say "impossible" in the sense of the definition of "Code" as it appears in the adds. If you take code to mean "ascii or UTF-8 files written in a textual programming languages with file extensions like .java, .c, .rb, .py, in an IDE or programmer focused editor" then I would say its not impossible. But what is "code" really? Lets presume it means a programming language (as opposed to "The Davinci Code"). What is a programming language? Basically symbolic instructions for a machine to understand that makes it do something (I am sure many folks can come up with better definitions). Who said these instructions had to take ascii form? a visual graph (a la jBPM, a JRules decision tree or a Corticon "rule sheet" for instance) could be thought of as "code" itself.
To some this may be irritating semantics, but to less technical people its important to understand what they are getting into. So I should clarify, even when you are using "no code" you are still using "a code" - its just a higher level sort. In many cases this is a Good Thing ! But people do need to still think logically, without ambiguity or woolly headed-ness - machines just will not tolerate it !
I have seen great demos of tools by Corticon (they use clever techniques with a visual decision table metaphor, but its more then a decision table), and I hear good things about Haley Adviser for natural language. I saw great demonstrations of Rule Burst's document based rule management, JRules supports multiple textual and visual rule metaphors with a myriad of smart editors. All really great tools of course, but in their own way, still "a code" is being authored, its just a code (programming language) that is higher level, and close to the domain and perhaps in a more natural or visual form then "ordinary code". You can't wave your hand at these tools and magically have consistent rules (maybe you can in the latest versions ;). You still need to be logical - the tools will do a lot of the heavy lifting, but precision is still required from you, the user, in your logic and intent, and design decisions.
To burst a few bubbles, no one will EVER have true free form natural language for rules. For starters, we don't have exhaustive technology to make computers understand natural language without a very very narrow scope. But MORE SIGNIFICANTLY, even if we did, we would still not have NL rules. Why? because our human languages are deeply flawed, in terms of logic. So even if we technically could have NL rules, other then a few spectacular (and possibly dangerous) failures they would be abandoned in favour of a controlled language of some form.
Have you ever given detailed instructions to a builder for your house renovations, yet still been disappointed? (ask Mark !). Natural language is not a language of logic, or accurate specification of instructions.
As a kid I used to earn pocket money by typing up papers for my father (who is a lawyer) and became familiar with various styles of legal language, legislation (as well as my fathers handwriting, which was much harder). They are worded in a very very formal way, yet fail to come even close to the accuracy of logic that symbolic programming languages provide (and they are not readable other then by experts) - most legislation needs to be tested in courts to be workable, it needs Explanatory Memorandums to patch up the gaping holes etc. This is not what people want when they talk about natural language rules, or "rules with no code".
In summary, whatever your tool of choice, you will still be using "a code" of sorts, and you will not be able to provide the vague sort of instructions to a rule document authoring system that you used to email to assistants, and hope it to work. That is not to devalue these tools at all, its just reality.
And happy new year ! Welcome to the world of tomorrow !
Comments.
I have been beaving away on a new UI/rule modeller specifically for the web (well, at least the web initially, hopefully we will also do it stand alone in the plug in soon).
This came about for 2 reasons:
1) DSLs have proven to be quite popular, and we want to make them available on the web (essentually a very handy templating tool for capturing rule data), and
2) I thought it would be nice to have a helpful and user friendly UI to "coach" people in authoring optimal rules (developers can also look at the drl output, see what makes it tick !).
(and 3: I had some spare brain cycles during JBoss world to work on it! and I thought the above 2 aims could be combined).
Since a picture is worth a thousand words, here is a screenshot:
This should be available in the up coming rule repository user interface. Visually its still quite rough, but its getting there, and the model behind it is solid. I would appreciate any feedback on how to make this a more "intuitive" interface to use (and don't confuse it with decision tables or scorecards, thats another beastie, this is just for a single rule at a time management).
I am integrating this with the (previously seen) dsl-aware business rule editor, as it is a nice fit (some people will use DSLs exclusively to hide details, others may use the modeller exclusively, perhaps a mix - yet more may prever vanilla drl, or a mixture in a package).
One of the nice things about it is that it requires little/no configuration (whereas there is some skill to configuring a dsl - this editor is driven off the model: facts/fields define what operators are relevant etc) - of course a dsl based rule reads naturally, but it is also easy to understand what the rule is doing visually if the model matches the domain. (A future fun little task will be to generate read only statements of the rules - a la the rule builder for email clients for filtering out that pesky spam).
So hows it work: A thats a trade secret ! Oh wait, no its not, its already in the SVN repository probably being crawled all over by google as we speak ! (oh my embarrasing code !). It works as it knows about the facts (model) available to the rules, what operators are applicable, bound variables, and has a limited set of actions it can take (mostly asserting fact, retracting, modifying fields, globals etc - I may add more as needed, but DSLs can template more things as needed).
I am planning to make the operator names/conditional element names configurable (they will have prettier defaults then this, I just ran out of time to do that, the idea is that anyone understanding basic logic should be able to use this, and if they know first order logic, all the better !).
It also has some basic validation (for instance you can't remove a fact that is needed in an action) - lots more can be done with validation to ensure correct rules at the time of entry (rule analysis module is another, seperate topic and a hobby of mine !)
Enjoy !
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.
-- Michael Neale
Both Mark and myself recently returned from the highly informative Business Rules Forum (in Washington DC).
The business rules industry seems to be in quite good shape, and there was a strong showing from all the vendors. I thought I would start with some summaries in general of what we saw, and what I thought.
The engine performance panel
James Owen - an industry commentator and rule practitioner and evangelist of many years experience, kindly hosted a panel on performance challenges for rule engines (for the geeks). It was a real whos-who of rule engine core tech.
Take a look at the panel of braniacs below (James Owen is missing, he was talking).
From left to right (Dr. Ernest Friedman (Jess), Dr. Charles Forgey (Fair Isaac, inventor of RETE), Rev. Daniel Selman (ILog JRules product manager), Rabbi Mark Proctor (some bloke, JBoss Rules), Pedram Abrari (CTO Corticon)
Innovations I found interesting
There were strong offerings from all the vendors on rule management/editing/higher level tools, and an understanding that a lot of the core tech is being commoditised. Nevertheless, there were many different approaches. Here is an outline of the products/companies that tickled my fancy: