Thanks for the reply, Mark.
I didn't want to use application data - I want my clients to use the same
code for any JSR-94 compliant rule engine. My immediate aim is to try out
several implementations with my application, to run performance tests and
just to see the different rulefile styles. JRules, for example, doesn't
have any way (that I've come across so far) to hook up rule execution
provider property map settings to its rule parameter system (which seems to
me to be the equivalent of application data in JRules).
So I need to rely on asserting things into working memory for that reason.
Anyway, validation would still be a problem with application data, wouldn't
it? Maybe even worse because at least a rule that only fires if the logger
is there can never throw a NullPointerException because it is missing...
Mark Proctor
<[EMAIL PROTECTED] To: [email protected]
us.org> cc:
Subject: Re: [drools-user] input validation in rules used by JSR-94 clients
10/11/2005 13:43
Please respond
to user
Don't put the logger in as a fact use ApplicationData to inject it into
conditions and consequences without it having to be in the WorkingMemory.
Mark
Adrian Bigland wrote:
Hi all,
I'm writing Drools into my application through the JSR-94 API, and I've
been considering how to deal with required inputs.
For example, I want to add a logging component to working memory so that
I
can create a good explanation of the results of the rule session. I need
to
match this as a parameter to make it available in the rule consequence.
If
the user doesn't add a logger, none of the logging rules will fire. It
would be better if I could fire a rule that returned some kind of
well-defined error state if the logger is missing, for example asserting
an
error object or something.
There doesn't seem to be a way of matching an absence of an instance of a
class in the rules - in fact, the meaning of such a rule is not entirely
clear.
One way I tried to do this was to count the number of loggers - and
assert
the count as a fact. A rule can match this fact and assert an error. The
only trouble was that I had to implement modes and mode changes in the
rules as well; the scaffolding code was large enough that it destroys the
most important benefits of using a rule engine to begin with, i.e.
recording business logic in a concise and manageable way.
Has anyone tackled this? Am I missing a better approach?
I am currently thinking of simply unit testing the clients to check that
the inputs match the current version of the rules, and programming the
clients defensively.
This also started me thinking about strategies to manage change in rules.
How do you make sure that old clients get a decent error state if they
run
rules that they no longer know how to make good inputs for. Here I
decided
that the best approach was a good versioning system, with major version
changes indicating that a client is no longer 'binary compatible' with a
set of rules. Whatever you do, because rules and code are separate, you
will always have to be careful when deploying them that the clients can
call rules properly, and that the results still mean the same thing that
the client thinks they mean...
**********************************************************************
This e-mail and any attachment is intended for the named addressee(s)
only, or person authorised to receive it on their behalf. The content
should be treated as confidential and the recipient may not disclose this
message or any attachment to anyone else without authorisation.
Unauthorised use, copying or disclosure may be unlawful. If this
transmission is received in error please notify the sender immediately and
delete this message from your e-mail system. Any view expressed by the
sender of this message or any attachment may be personal and may not
represent the view held by First Choice Holidays PLC and its subsidiaries.
All electronic transmissions to and from First Choice are recorded, may be
monitored and are scanned for viruses and content. E-mails containing
viruses will be deleted without notification. Whilst we maintain virus
checks on inbound e-mails we accept no liability for viruses or other
material introduced with this message.
All companies form part of the First Choice Holidays PLC group of
companies.
First Choice Holidays PLC Company Registration No: 48967 (England)
Registered Office: First Choice House, London Road, Crawley, WestSussex
RH10 9GX
**********************************************************************
