synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vikas" <vi...@infravio.com>
Subject Re: Simple Framwork for Synapse (wrt option2)
Date Wed, 12 Oct 2005 10:39:16 GMT
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..
???Would it be wise to give generic mediation components the ability to make 
decisions...
???Aren't true/false return values to reflect the sucess status of  the 
mediation component.

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 resolving 
tactic, do we just leave it as a rule-engine fault]??
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! 


Mime
View raw message