Paul
On 10/19/05, ant elder <[EMAIL PROTECTED]
> wrote:
Some use cases would definitely help with thinking abut this. Here's one:
I want to log all requests to the xmethods stockqoute service, so I have a rule for that which calls a logging mediator.
I also have some clients which use the wso2 stockquote service, as its better.
But today the wso2 server's down, and they're all off in Kashmir so haven't noticed. So I add a rule to divert everything from the wso2 service to the xmethods service.
Wouldn't I probably want the xmethods request logging Mediator to still get called for all the ex-wso2 requests?
...ant
On 10/19/05, Paul Fremantle <[EMAIL PROTECTED] > wrote:I guess I had a simpler model in mind. I simply thought that in general, the message modifications would NOT cause the rules to be re-evaluated - because this makes it very easy to get into endless loops by mistake. On the whole, I don't expect users to use the "multiple rules" model as the composition model. I expect most composition to take place within composite mediators.
The cases where the mediatior creates a new message are more like the cases where it is a client. For example, if a mediation wants to create an alert because the order amount is greater than $1m, then it will create a new message. However, since all messages should be mediated by the bus, the most logical thing is for that message to be placed straight into the bus.
I guess what I'm saying is - lets look at this scenario - and understand WHY did the message to http://glen.org need to be completely re-evaluated by Synapse? Because in the general flow of things I imagine this is an unusual case.
PaulOn 10/19/05, ant elder < [EMAIL PROTECTED]> wrote:How is a Mediator going to know when it can return true and have the existing rule matching continue or that it must put a new local message into the system and return false? Isn't it the case that any time a Mediator alters anything in the message then all the rules will need to be re-evaluated as the alteration may mean a previously unmatched rule may now match?
If that is the case then instead of the Mediator having to kick off a new messages how about the Synapse container itself trapping message alterations and working out if the rule matching needs to restart at the beginning or not?
...antOn 10/19/05, Paul Fremantle < [EMAIL PROTECTED]> wrote:Vikas
I just posted a picture of how I imagine the Synapse engine might fit into Axis2. Here is a second picture that shows the flow in the scenario we are discussing.
In this picture, the first mediator runs as normal, but the second mediator decides that it needs to completely create a "new" message to http://glen.org and this should be mediated by Synapse as well. In this case the mediator calls a non-blocking API that we provide that issues the new message into the SynapseRuleEngine. Then the mediator returns false and the original message is no longer processed. However the new message is now being processed in the SynapseRuleEngine on a new thread.
I have shown that call going directly to the SynapseRuleEngine, but in fact its more likely we would have a "in-JVM" Axis2 listener alongside the HTTP listener that would create the new thread and dispatch to the SynapseRuleEngine.
PaulOn 10/19/05, Vikas < [EMAIL PROTECTED]> wrote:*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' themessage 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 -----From: Paul FremantleSent: Wednesday, October 19, 2005 4:12 AMSubject: Re: Rule Engine / DispatcherIn 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.PaulOn 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
