s/callout/invoke/

:)

Sanjiva.

On Mon, 2006-05-08 at 09:10 +0100, Paul Fremantle wrote:
> Asankha
> 
> This is quite cool, but I'm concerned about putting a synchronous
> blocking into the flow. I'm also concerned we are getting very close
> to BPEL. I think it would be really good if we started thinking about
> how Synapse fits with a BPEL server and stateful/process integration. 
> 
> Paul
> 
> On 5/8/06, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
>         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]
> 
> 
> 
> -- 
> 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