On 10/20/05, Vikas
<[EMAIL PROTECTED] >
wrote:
Hi all,
I do think
that "Synapse should control this instead of the mediation."
But a few
afterthoughts:
---wouldn't re-evaluating all
rules at this point be same as thinking that a new message is being
processed?
<ant>Good point. I guess the one difference when using the
non-blocking API Paul is talking about is that a new thread is used to
re-evaluate the rules - although I'm not sure how useful that is if the
original thread just terminates without doing anything more. Maybe there needs
to be a way to say reintroduce the messaging using the current thread. Would
be easier to implement that if Synapse was controlling the reintroduction
instead of the mediator. It does seem like having a way for a mediator to
introduce new messages into Synapse locally to be processed concurrently would
be a useful feature, what ever the outcome of this
discussion.</ant>
<Vikas> +1 for that
feature! </Vikas>
For the new message injected
into the system by synapse[on behalf of a mediation] or the mediation
itself
---- There r two
cases
*There might be a set of mediation rules for the other service
which definitely needs to be done before accessing the other service (else
it's a breach of contract)
*Bypass the
global rules for such messages[in case the global rule says..maintain count
of incoming requests]
<ant>Couldn't the rule control
this? So the counting rule in your example would only match messages coming
from an HTTP transport listener, or perhaps any non-local transport
listener?</ant>
<Vikas>So, would Synapse have separate
listeners for local messages and for messages from outside(consumers)! And the
engine would need to have separate mechanisms to handle these different
messages.</Vikas>
--- So a 'true' from the mediation(a
state in the state-machine sense) would tell the engine to go forward
in the particular branch of the state-machine and a 'false' would lead to
the state-machine's initial state(i.e. revaluation of rules).[As if
a new message has come in.]
<ant>There still needs to be a way for a
mediator to say to Synapse "stop, do nothing more with this message", which is
what I thought returning false was going to mean. I still like the idea that
the Synapse rule processor is able to spot that a mediator has done something
that means re-evaluation is necessary. Even if that's quite simplistic for
now, such as when a mediator changes anything in the
headers.</ant>
<Vikas>Sorry if i have
caused confusion.
1) What i was hinting at it that the engine can't be
remembering the actual message it had passed on to the Mediation. So a
mediation will have to tell the engine that it had not changed something and
the engine can still pursue the branch - The mediation returns a
true.
2)In case the mediation does change something, it
returns a false and injects a new message into the system. [notice the bold
text above] I used the term 'as if' because it is not actually a new message,
its just a modified request re-introduced by the mediation.
</Vikas>
--- Can somebody shed some
light on how complex would it be for the engine to keep track of the
rule that caused the mediation to be called (thus identify the property, or
the 'special thing' thats important). Complexity in terms of both data
and computation.
--- Also it will have to then keep
track of all the decision points that had been passes in the state
machine..[ It
would implementation specific – but it definitely needs to hold this
information]
Have a good day!
----- Original Message -----
Sent:
Wednesday, October 19, 2005 5:12 PM
Subject:
Re: Rule Engine / Dispatcher
Ok I agree with you, it seems
better not to re-evaluate all the matching rules. I guess the point I was
debating is wouldn't it be nicer if Synapse controlled this instead of the
mediator?
The Mediator is just like any regular mediator without
using any special Synapse nonblocking API:
public boolean mediate(Message m)
{
m.setTo("http://xmethods/stockquote");
return true;
}
And Synapse says, oh, you've
changed wsa:to, thats one of those "special things", better make this a
new request.
That way we can change our minds about what
constitutes a "special thing" without having to change any mediator code,
and we could maybe build some smarts into Synapse so that it can somehow
check if any rules before the current rule were interested in a wsa:to of
http://xmethods/stockquote and if not then this wouldn't
have to be a new request.
...ant
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.
Pau
