Phase and RuleSet vs. Rule and Mediators

[ant elder <an...@gmail.com>]

>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

Re: Phase and RuleSet vs. Rule and Mediators

[Sanjiva Weerawarana <sa...@opensource.lk>]

On Mon, 2005-11-14 at 21:22 +0000, Paul Fremantle wrote:
> Ant
> 
> I need to think about this more. I had been thinking TCP/IP default
> network routing (i.e. the network decides the path) rather than Loose
> Source Routing (message decides path). On the whole network-decides is
> simpler, less flexible and more stable, message decides is more
> complex, dangerous and powerful. MS had something like this
> (WS-Routing) but it was killed for security reasons. 
> 
> If we take this model, I would suggest an approach where we default to
> network-decides and then have a way for message to override if
> necessary. That could be an extension of the current model.

Big +1. Let's start simple and then worry about adding all the fancy
bells and whistles.

> I still would like to get some agreement on the approach we have in
> code and then move from there. I think it has got to the point of
> non-productive not even to have a HEAD. 

I agree wholeheartedly. We're spinning around in design playland right
now and that's not at all productive. Let's get the show on the road
with a basic starting point.

Sanjiva.



---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org

Re: Phase and RuleSet vs. Rule and Mediators

[Paul Fremantle <pz...@gmail.com>]

Ant

I need to think about this more. I had been thinking TCP/IP default network
routing (i.e. the network decides the path) rather than Loose Source Routing
(message decides path). On the whole network-decides is simpler, less
flexible and more stable, message decides is more complex, dangerous and
powerful. MS had something like this (WS-Routing) but it was killed for
security reasons.

If we take this model, I would suggest an approach where we default to
network-decides and then have a way for message to override if necessary.
That could be an extension of the current model.

I still would like to get some agreement on the approach we have in code and
then move from there. I think it has got to the point of non-productive not
even to have a HEAD.

Paul

On 11/14/05, ant elder <an...@gmail.com> wrote:
>
> Ok, that sounds reasonable. So how about:
>
> 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 <pzfreo@gmail.com > 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.
> >
> > Paul
> >
> >
> >
> > On 11/14/05, ant elder < ant.elder@gmail.com> 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
> > >
> >
> >
>

Re: Phase and RuleSet vs. Rule and Mediators

[ant elder <an...@gmail.com>]

Ok, that sounds reasonable. So how about:

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 <pz...@gmail.com> 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.
>
> Paul
>
>
>
> On 11/14/05, ant elder < ant.elder@gmail.com> 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
> >
>
>

Re: Phase and RuleSet vs. Rule and Mediators

[Paul Fremantle <pz...@gmail.com>]

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.

Paul



On 11/14/05, ant elder <an...@gmail.com> 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
>