There's a "stage" which is a bunch of "rules" and all the rules in a stage have the same "type".
A SynapseMessage has a List of Stages (the routing path) and this is initialized with the stages from the applicable "phase" when the SynapseMessage enters Synapse.
A Mediator can look at the list of stages in a SynapseMessage and add/delete stages to/from the list. A Mediator can also access the Synapse configuration to find the names of all the available Stages so it can know the names of the stages it may add.
Does that sound plausible?
If so then there's the questions about can we have a response routing path available for the mediators in the request path to fiddle with, or what does a mediator returning false mean - killing the message, or skipping to the next stage if there's still stages in the routing path (so to kill a message a Mediator needs to return false and set the routing path to null)?
...ant
On 11/14/05, Paul Fremantle <[EMAIL PROTECTED]
> wrote:
Ant
The reason we need both stages and rules is because if we simply have rules then the ordering of those rules is complex. The stages offer a way of ordering those rules while still having some optimisation within a stage. Basically they offer a structuring model.
I was of the opinion you were - and the synapsejoint ruleset had that model. But even building a few simple rules i started to see that the ordering was going to be too hard. I think the stages offer a nice structure. I think it also makes sense to restrict each ruleset to a rule-type because I still believe we can do optimisation on a given set of rules if they all conform to the same rule model.
In particular your idea of routing to another stage is much more likely to be workable in practice if we have stages than if we only have rules, because the stages can be fixed in a deployment whereas if my deployed mediators config is dependent on which rules are deployed thats very fragile.
PaulOn 11/14/05, ant elder < [EMAIL PROTECTED]> wrote:>From the IRCs and prototypes it seems like people accept that its useful for a Rule to be able to have a list of Mediators instead of being restricted to a single Mediator.
We have a Mediator interface and a RuleEngine interface which represents the RuleSet/Stage:
public interface RuleEngine {
public boolean process(SynapseEnvironment sc, SOAPMessageContext smc);
}
And then there's the phase which defines a list of RuleSets/Stages/RuleEngines
inPhase order="a b"
outPhase order="b c"
So...aren't we just duplicating lots of stuff and making things complicated? The phase is a rule and the RuleEngine is a Mediator. The inPhase and outPhase are just Rules with the condition being isResponse() or isResponse() == false, and the phase order is the list of Mediators on the Rule.
If you need the extra function the ruleSet/stage gives you couldn't you implement that in a Mediator? (especially when Synapse provides the function to enable a Mediator control the routing path described in that earlier post)
...ant
