Version 3

    End of 2007 Note

    Ha ! well its the end of 2007 and actually most of this worked out, surprisingly (despite many many changes and obstacles on the way).

    All of the below have been addressed in one way or another, although testing and analysis GUIs are still early days at this stage, but essentially they are done functionally speaking (just not usable directly at the moment).

     

     

    2007 roadmap for Michael

    This is where I attempt to layout my priorities feature-wise for 2007. This is

    subject to change, and (more realistically) subject to someone else

    implementing it.

     

     

     

     

    • Completion of V1 of BRMS

    This obviously includes the back and, and the web UI, and integration with the

    IDE tooling (thanks to Mark). This should be done in Q1, but realistically I

    expect it to take until the middle of the year to settle down (based on

    experience with past major releases).

     

    • Rule testing tool

    Matthew Shaw has been working very well on a contribution/prototype testing

    tool and IDE. He has a api/engine to generate tests based on rules and models,

    and also execute these "rtl" files to make test assertions on the firings of

    rules. There is also the start of an IDE plug in for this. I aim to productise

    this (thanks mat !) and make it a core part of the rules tools (the execution

    of the rules can also be included in the BRMS lifecycle eventually).

     

    • Rule analysis module

    I started drools-analysis with some spare time in Berlin, and the concept is

    still sound (based on some papers James Owen gave me a while back). I would

    like to take this to fruition. This requires some detailed analysis of the RHS

    of rules which are currently not in the default DRL language definition, but

    its doable. This would be coupled with perhaps some IDE tooling, but most

    likely produce HTML/XML quality reports of ruleset "quality" and logic

    consistency.

     

    This utlity will either be called on demand by a user (command line or IDE or

    programmatically) or by (eventually) the BRMS as part of continuous

    integration style QA of a rulebase. The API should also be such that the

    analysis results can be used by a "self tuning" mechanism in future (and other

    tools) for performance or execution control.

     

    • Natural Language enhancements

    I plan to work on an initial "free form" natural language rule capture wizard.

    Based on my pleasure in using Google Calendar: in google calendar you can

    quickly add an appointment by typing in free text and it will convert that to

    a calendar entry. Similarly a "quick rule" or "quick condition" feature,

    knowing the domain (model) of the rules can take the natural langauge

    expression and convert it to the rule model equivalent (so both can be shown

    on the screen). In envisage that this would work by capturing either a pattern

    or a rule as a sentence, in a popup box, and then converting this to a rule

    construct on screen (this can apply on the web primarily) where the user can

    quickly see that the natural language has been comprehended correctly (using

    the rule modeller visual format, most likely). This is similar to the

    calendar, in that the user enters their appointments textually, but verifies

    that the appointments are correct visually.

     

    • BRMS repository to be extended to other assets types

    Primarily this means process definitions - this is a key part of a "process

    server" or platform. Other items may include service contracts, WSDL etc.

     

     

    Well, thats enough for 2010, but hey, gotta be ambitious. I also know from

    past experience that things change, all the time, lots, so take all this with

    a grain of salt.