My replies are inline, below:
On 11/29/06, Arjun Dhar <[EMAIL PROTECTED]> wrote:
Date: 29th Nov 2006
Hi,
from a business perspective there are some additional requirements that
need
to be addressed. I'll keep this short :)
Security
---------
The state of the rules persisted such be such that it cannot be read if
protected. Currently, a DRL file saved on eclipse does not provide this
feature.
Technically I'm looking at building the following; if you guys do it,..all
the
more better: (Basic requirements)
1.1. Save in encrypted format
1.2. On opening ask for key to decrypt file
1.3. Disable copying of text from .Drl/DSL editor to any other
application
...goes without saying that in additon, that if a person wishes to use a
non-
eclipse base IDE then the packages can be re-used.
Our new repository is JCR based, so you could have rules managed stored
completely outside eclipse (only put in eclipse what you need to debug).
Obviously to hide rules from developers will be unusual, but not unheard of
;) (I have heard of it). As for encryption - that would be necessary for a
vanilla file based system, but I think its not the write way to solve this
problem when there are simpler/safer ways (I have a fair bit of past
experience of crypto, and it is harder then it seems to get right).
Re 1.3: yes with web UIs, you have some control over this, but if it is
shown on someones screen, you can't positively prevent them from grabbing
it/writing it down (unless we had one of those flashy-things from Men In
Black !).
Versioning
----------
While one can argue that simply putting, these files on a versioning
system
takes care of it. There needs to be inherent support for versioning by the
system.
No where in the DRL file can I specify a version; so that during runtime I
can
obtain that information about the file. Work arounds can be coded, but
there
should be standard support.
e.g. A company has a rule in 2002 on some loan policy; In 2004 the rule is
ammended but the people with loans before 2004, the previous version of
the
rule would continue to apply indefinitely.
I know the work around to this, but wouldnt it be nice (Yes: Nice to Have
priority), if the Rule engine could keep both versions active for us in
the
working memory and we can determine at runtime which version to use
instead of
adding date conditions all over the rules in the DRL file.
It's easier to manage, and we all know how important that is to us! :)
This is known as a "Grandfathered rule" if I am not mistaken. Basically you
have old data, and you want the rules to be bound appropriately to that old
data, so when the old data flows again through the system, the grandfathered
rule applies rather then the latest.
Whilst the repository can support date effective/expired, that only applies
to a point in time, not to specific data - and is more to do with
controlling deployment and retiring rules (after the effective date, the
rule can no longer physically be applied).
To get it to specific data, we need some more though (I will post seperately
after this thread).
..In additon the the above important requirements here is a WISH LIST::
a. Allow mutual exclusion of rule-sets or even agenda groups (in addtion
to
the ME of only rules currently using Activation-Group). A mutually
excluded
agenda group may not regain focus even if auto-focus is on.
Reason:: A company servicing multiple clients, can play with existing
rules/sets by simply changing these attributes and customizing what parts
may
or may not be applicable.
Hmmm... this sounds more like a generic Rule Flow solution is needed (graph
oriented).
b. Allow rules to belong to multiple activation groups.
Reason: Groups can have intersections; and an intersection implies a rule
that
belongs to two or more activation groups.
possible, but rule flow may be better solution for more control.
c. Agenda sub-groups
Reason: This can be an alternative to 'b'. Defining new groups from
existing
ones can accomplish what 'b' wishes to, in addition to that any activity
of a
Group would apply to all its memebers in the sub-group making this a
powerful
feature.
Similar to above, and I think this may confuse people more then it is
needed, when a declarative rule flow specifying the processing logic
external to the rule attributes would be clearer.
Some work was done using jBPM to provide a graphical rule flow in co-ercing
flow through different agenda-groups in a rule package, if anyone wants to
run with that and make it a standard add-on module that would be great I
think (hardest work is probably in tooling integration if anything).
thanks,
Arjun Dhar
(Engineer & Consultant)
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
