*Does this mean the mediations can actually
re-issue a request back into the system after modification?
*If thats the case it would give us all the
flexibility we were talking about during the IRC and this does make a stronger
and clear case for a mediation 'consuming' the
message and
returning a true/false to the engine.. thus making it stop evaluating
rules.
*But then going by the above example and the sample
code wouldn't the engine on receiving a 'false' from the mediation
-stop rule evaluation
-make a call to the service (for the consumed
and modified message)
*Am i loosing track of something??
~Vikas.
----- Original Message -----
Sent: Wednesday, October 19, 2005 4:12
AM
Subject: Re: Rule Engine /
Dispatcher
In that case the rule should "consume" the message (i.e. return false),
and "re-issue" the message into the system, at which point the rule matching
starts again. Another reason why there is a difference between the mediator
letting the message "continue" in the current flow versus being "consumed".
We do need a well-defined API call for a mediation to "issue" a
message directly into the "bus" (i.e. the rule matching space) rather than
having to open an HTTP connection. This is also important for a T mediation
where I want the message to be copied and go to two places.
Paul
On 10/18/05, ant
elder <[EMAIL PROTECTED]>
wrote:
What
about when a mediator alters something? A msg comes in and a rule for http://glen.org doesn't match but
a rule for http://fremantle.org does, so
a mediator is invoked and that changes it to http://glen.org?
...ant
On 10/18/05, Paul
Fremantle <[EMAIL PROTECTED]>
wrote:
Aha
- now thats a fine question!
There are two ways out of
that.
1) The mediator can say it has dealt with the message (return
false).
2) We can (and *need*) to build a data structure from the rules
based on the potential matches. For example, you cannot match http://glen.org if you have
already matched http://fremantle.org because
they are incompatible. The typical way of doing this is to build a state
machine that captures possible "follow-on" rules from each rule.
Paul
On 10/18/05, Glen
Daniels <
[EMAIL PROTECTED]> wrote:
>
If the Rule Engine is a handler that takes over control of
> the
message then it can iterate through the rules. Each time
> it
comes to a hit, it uses a separate (i.e. not the one that
> this
handler is running under) AxisEngine to execute the
> modules and
mediator for that rule. It retains control until
> no more rules
match and then sends the message on.
"until no more rules match"
- are you saying that EVERY run through the
matching engine has to
check EVERY rule?
I really hope you're not saying
that....
--G
---------------------------------------------------------------------
To
unsubscribe, e-mail: [EMAIL PROTECTED]
For
additional commands, e-mail: [EMAIL PROTECTED]
|
