This is the way Prototye2 is designed, (Code in Scratch area), which is more or less same to Paul's and Deepal's picture.
1. Once a request comes, Listener (in this case AxisServlet) calls AxisEngine.receive(MR)
2. There is a handler in "PreDispatch" pahse called "SynapseInHandler", which will call the "SynapseRuleEngine" and populate with available rules for that *message*. Then this rules are set as a propety in that MessageContext.
3. After that it calls "SynapseDispatcher" in "Dispatch" phase, which will select the relevent *Mediator* for the *first* rule in the list. So the rules are extract from the propety that has been put in "SynapseInHandler" to MessageContext. At this point relevent "MessageReceiver" will be registered.
4. Then go to the MessageReciever and do the medation. Now as decide in IRC, Mediator do it's work and see if more rules are there for this messge. If "no", retrun "false". So the message will be put into bus.
if "yes", return "true". Then MR will create a new MessageContext, put all the "states" related to old MC and called AxisEngine.receive(MC).
Now this message doesn't need to "populate" old rules, because it has allready done. So it can programatically skip "SynapseInPhase". Once it reach "SyanpseDispatcher" it will select the "Medator" and the rest will be as mentioned in above.
Now the basic point here is, MR will decide to loop for more rules, with the aid of Mediator. Thus, Mediators more or less more intellegent to know, whether more rules are there for that message.
{This only for a message}
Once a another mesage hits, it will start the process mentioned above 1 - 4. So rules will be handled per message basis.
Saminda
On 10/19/05, Paul Fremantle <[EMAIL PROTECTED]> wrote:
Ok. So is exactly the case where you want to say this is a new message. I agree with that scenario. But I still think that it helps limit the possibility of endless loops and improves the performance if the default behaviour is not to re-evaluate the matching rules between rules.
PaulOn 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]
