This isn't the same as we discussed on the IRC chat last week, which is fine, the more alternative prototypes the better, but is there some reason you don't like this design or is there a problem with keeping all the rule processing in the Synapse MessageReceiver?
Paul's diagram: http://fremantle.org/synapse_in_axis.PNG
Edited extract from the IRC chat:
ant doesn't the pic say: there'd be a single Synapse dispatcher which just chooses the single Synapse Service/op
ant The SynapseMessageReceiver is where _all_ the rule processing and mediator invoking happens
ant To invoke a mediator it uses a new axis engine which is configured for the relevant rule/mediator
ant Is that what you meant Paul?
paulfremantle that was what I meant
paulfremantle in the picture
paulfremantle where the state of the rule engine is just the state of threads java execution
paulfremantle not in context
Glen-concall there would be two separate levels of dispatch - the FIRST AxisEngine dispatches (always) to Synapse's rule engine
Glen-concall the SECOND one dispatches to a particular mediators, and all that needs doing to make that work is for Synapse to MANUALLY set the service in the MessageContext it send()s to the new engine
ant +1 to glen
paulfremantle yes glen +1 (thats what I tried to draw)
sanjiva what does "MANUALLY set the service in the MessageContext" mean?
Glen-concall messageContext.setService(theMediationIDecidedOn)
Glen-concall it's all running in the same Axis context, so the Synapse engine has access to all the deployed mediation services. It just needs to grab one and stuff it in there, then no further dispatch is needed.
...ant
On 10/25/05, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
Hi all;I draw a picture which my SynpaseToy is based onhave a look at that and comment if any thing has gone wrong
Thanks,
Deepal
................................................................
~Future is Open~
