How about the introduction of a <callout/> mediator, which could be used to make an external service call and store the response into the Synapse Context?

If one is to write a mediation configuration to accept a message, perform a lookup from another external service, and perform routing or transformation etc. of the original message based on the result received, the above would make things more simpler. i.e. the response received would be available just after the invocation of the <callout> instead of having to write configuration to process the response again from the top level <rules> (i.e. main mediator).

asankha


Paul Fremantle wrote:
I think what you are saying is exactly what I just said!

On 5/5/06, Sanjiva Weerawarana <[EMAIL PROTECTED] > wrote:
On Fri, 2006-05-05 at 14:56 +0100, Paul Fremantle wrote:
> Well I think we need two behaviours. One is to explicitly send the
> current message on and do no more processing (kind of like "goto
> end"). The second is to take a copy of the message and send that
> somewhere without affecting the current flow. However in both cases
> the response message gets handled as a newly injected message into
> Synapse. In the second case you have to configure Synapse to do
> something with the extra response.

I don't see this- if we do what I suggested (and I thought you agreed
with earlier in this thread!), then we have <send/> basically being
built in. However, if the built-in <send/> is reached, then the flow
stops. If you hit an explicit <send/>, then the flow is not stopped.

There's no "new" message created after an explicit <send/> .. the
current message continues to get processed. (Maybe there's another
<send/> sending it somewhere else; who knows.)

Response has nothing to do with this discussion- if the explicit <send/>
causes another messsage to be injected to Synapse, well, cool- but that
has nothing to do with the current message path thru Synapse.

Sanjiva.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to