synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Newcomer, Eric" <Eric.Newco...@iona.com>
Subject RE: Simple Framwork for Synapse (wrt option2)
Date Fri, 14 Oct 2005 18:26:12 GMT
At some point we will need to discuss rule precedence (i.e. how does the
list get ordered) but assuming that is settled this looks fine...

 

  _____  

From: Paul Fremantle [mailto:pzfreo@gmail.com] 
Sent: Wednesday, October 12, 2005 9:18 AM
To: synapse-dev@ws.apache.org
Subject: Re: Simple Framwork for Synapse (wrt option2)

 

Gmail cut me off midway through!

rules[];

int i= 0;
while (true)
{
    if (rule[i].getExpr().matches(message)) {
          boolean cntnue = rule[i].getMediation ().mediate(message);
          if (!cntnue) break; // don't do anything more 
    }
    i++;
    if (i==rules.length) { // finished rules, now send
        send(message);
        break;
    }
}
    



On 10/12/05, Paul Fremantle <pzfreo@gmail.com> wrote:

I've answered questions below, but the algorithm is up here in
pseudocode:

rules[];
bool loop = true;
int i= 0;
while (loop)
{
    if (rule[i].matches(message)) {
          boolean cntnue = rule.getMediation ().mediate(message);
          if (!cntnue) break;

          if (i<rules.length)



On 10/12/05, Vikas < vikas@infravio.com <mailto:vikas@infravio.com> >
wrote:

Hi,

Regarding the point " So mediator will decide, if more processing needed
to 
done or processing is finished. If finished it can send "false" as
return
parameter to the dispatcher, or "true" if more processing needed to be
done.
Thus, dispatcher will look in the rule table whether more rules are 
registered to a particular URI, if not send it to its original
destination."


 

	 

	???What exactly does "more processing" means here..


<pzf>More processing means matching against further rules</pzf> 

	 

	???Would it be wise to give generic mediation components the
ability to make
	decisions...


<pzf>Yes. They decide whether the message is "consumed" by that
mediation or not. </pzf> 

	 

	???Aren't true/false return values to reflect the sucess status
of  the 
	mediation component. 


<pzf>No. The mediation throws a fault if it fails for some reason.</pzf>

	 

	We would need a separate component in the "Syanpse dispatcher,
which will be
	he rule-engine" to handle the call to the destination once the
rules are
	finished...
	Once a request lands on Synapse -
	The rule engine would need to figure out which rules are to be
fired... 
	???What happens in case multiple rules evaluate to true[whats
the r

	esolving 
	tactic, do we just leave it as a rule-engine fault]??


<pzf>If multiple rule expressions match then each rule is executed in
the order of the rules. While each mediation returns true, then further
rules are executed until no rule matches, at which point the Dispatcher
forwards the message to its To address. If a mediation returns false
then the engine does nothing more with that message - tho of course the
mediation may have done something with it.</pzf> 
 

	 

	So Synapse would have a loop over mediation[the horizontal flow
to the 
	mediation and back] followed by a single call to the actual
service.. 
	
	The flow of response to the client and also the firing of events
depending
	on the data collected based on the mediatons will also have to
be handled in
	the "Dispatcher + rule engine" for eg.. someone might be
interested in 
	firing an event with the details of the time it would take the
	logging/monitoring mediation component to finish its task..
	
	Thus IMHO we would need a lot of sub-components and
compartmentalization of
	the "Dispatcher + rule engine"... 
	
	Thanks!
	
	
	
---------------------------------------------------------------------
	To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
	For additional commands, e-mail: synapse-dev-help@ws.apache.org

 

 


Mime
View raw message