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!
|