I think we should use an outSequence stack just like a fault stack. So if you specify any new outSequence in the case of proxy the proxy outSequence wont be overridden but will be pushed by the new one.
And we need to change the way proxy out sequence is being picked by the callback receiver. Thanks, Ruwan On Tue, Nov 10, 2009 at 3:39 AM, Supun Kamburugamuva <[email protected]>wrote: > Yes, that makes me uncomfortable as well :). But I'm not sure how else we > can get this across proxy services and message mediation. Any ideas please? > > Thanks, > Supun.. > > > On Tue, Nov 10, 2009 at 3:13 AM, Ruwan Linton <[email protected]>wrote: > >> First of all, good idea... but the last comment on proxy services didn't >> make me comfortable, it is confusing to the users. >> >> Thanks, >> Ruwan >> >> >> On Mon, Nov 9, 2009 at 1:42 PM, Supun Kamburugamuva <[email protected]>wrote: >> >>> On Mon, Nov 9, 2009 at 1:27 PM, Hiranya Jayathilaka < >>> [email protected]> wrote: >>> >>>> +1 >>>> >>>> Looks good to me but can we please change the 'receivingSequence' >>>> attribute to something more appropriate? How about 'responseSequence'? Also >>>> I think this feature can be further generalized without restricting it as a >>>> service chaining feature. With this feature we can say send message to >>>> endpoint 'foo' and direct responses to the sequence 'bar'. We should make >>>> the idea clear when documenting this feature. >>>> >>>> On a different note, have you thought about the implications this may >>>> have when used within proxy services? Just being curious. >>>> >>>> With the current implementation proxy services will be treated the same >>> way. If a send is done with a receiving sequence inside a proxy service >>> that, specified sequence will be executed, not the outSequnce. >>> >>> Thanks, >>> Supun.. >>> >>> >>>> Thanks, >>>> Hiranya >>>> >>>> >>>> On Mon, Nov 9, 2009 at 12:26 PM, Supun Kamburugamuva <[email protected] >>>> > wrote: >>>> >>>>> Hi >>>>> >>>>> Suggested approach. >>>>> >>>>> <main> >>>>> <send receivingSequence="first"/> >>>>> </main> >>>>> >>>>> <sequence name="first"> >>>>> <!-- may be do some xslt --> >>>>> <send receivingSequence="second"> >>>>> <endpoint> >>>>> <address uril="http://first-endpoint"/> >>>>> </endpoint> >>>>> </send> >>>>> <sequence> >>>>> >>>>> <sequence name="second"> >>>>> <may be do some xslt> >>>>> <send receivingSequence="third"> >>>>> <endpoint> >>>>> <address uril="http://second-endpoint"/> >>>>> </endpoint> >>>>> </send> >>>>> <sequence> >>>>> >>>>> <sequence name="third"> >>>>> <!-- send back --> >>>>> <send/> >>>>> <sequence> >>>>> >>>>> Existing approach. >>>>> >>>>> <main> >>>>> <in> >>>>> <send to endpoint 1> >>>>> </in> >>>>> <out> >>>>> <switch with some response message property> >>>>> <case 1: response message is from endpoint1> >>>>> <send to endpoint 2> >>>>> </case> >>>>> <case 2: response message is from endpoint 2> >>>>> <send to endpoint 3> >>>>> </case> >>>>> <case 3: response message is from endpoint 3> >>>>> <send to endpoint 4> >>>>> </case> >>>>> <default> >>>>> <send back/> >>>>> </default> >>>>> </switch> >>>>> <out> >>>>> >>>>> Problem with this approach is that we may not be able to determine >>>>> weather the response is coming from a particular endpoint. Even if we >>>>> solve >>>>> that problem this solution does not seems to be logical. >>>>> >>>>> Thanks, >>>>> Supun.. >>>>> >>>>> >>>>> On Mon, Nov 9, 2009 at 12:09 PM, indika kumara >>>>> <[email protected]>wrote: >>>>> >>>>>> Spun could you please scratch the configurations for a single scenario >>>>>> in both approaches (existing and your suggestions) so that we can >>>>>> compare... And also how much services can your approach chain? ... if >>>>>> it is more than two , what will be the configuration? - could it >>>>>> become similar to the existing approach?.... >>>>>> >>>>>> Thanks >>>>>> Indika >>>>>> >>>>>> On Mon, Nov 9, 2009 at 11:45 AM, Supun Kamburugamuva < >>>>>> [email protected]> wrote: >>>>>> > Hi Indika, >>>>>> > >>>>>> > Thanks for the feedback. Actually I thought about your suggested >>>>>> approach as >>>>>> > well. But if we want to do something complex, this approach can >>>>>> become >>>>>> > pretty hard to implement and maintain. Or it can be very difficult >>>>>> to >>>>>> > implement in some cases. But with my approach the Synapse >>>>>> configuration >>>>>> > become logical and easy. >>>>>> > >>>>>> > Thanks, >>>>>> > Supun.. >>>>>> > >>>>>> > On Mon, Nov 9, 2009 at 10:39 AM, indika kumara < >>>>>> [email protected]> >>>>>> > wrote: >>>>>> >> >>>>>> >> Spun we can do the service chaining with synapse . one resource is >>>>>> [1] >>>>>> >> which does the message chaining with a proxy service. You should be >>>>>> >> able to do same thing even with the main sequence (put response >>>>>> true >>>>>> >> property and call the new service endpoint within the out >>>>>> mediator). >>>>>> >> >>>>>> >> Could you please critically evaluate the existing approaches and >>>>>> your >>>>>> >> suggestions? >>>>>> >> >>>>>> >> And... +1 For keeping and retrieving non string properties. >>>>>> >> >>>>>> >> >>>>>> >> Thanks >>>>>> >> Indika >>>>>> >> >>>>>> >> [1] >>>>>> >> >>>>>> http://adroitlogic.org/knowledge-base-synapse/11-message-chaining-with-synapse.html >>>>>> >> >>>>>> >> On Mon, Nov 9, 2009 at 2:28 AM, Supun Kamburugamuva < >>>>>> [email protected]> >>>>>> >> wrote: >>>>>> >> > Hi all, >>>>>> >> > >>>>>> >> > Ability to call one service, then use that result to call another >>>>>> >> > service >>>>>> >> > and so on is a very important feature in any ESB. But this is >>>>>> hard to >>>>>> >> > implement in the current Synapse configuration language unless we >>>>>> are >>>>>> >> > using >>>>>> >> > something like callout mediator. >>>>>> >> > >>>>>> >> > But with a simple improvement we can get close to achieving full >>>>>> message >>>>>> >> > mediation. The improvement is to allow the user to specify a >>>>>> receiving >>>>>> >> > sequence to the send mediator. When the response comes to this >>>>>> send, it >>>>>> >> > will >>>>>> >> > be directed to the receiving sequence instead of a predefined >>>>>> sequence >>>>>> >> > like >>>>>> >> > main or outSequence. >>>>>> >> > >>>>>> >> > send (response to sequence 1) --------> sequence 1 (do some >>>>>> >> > transformations), send (response to sequence 2) --------> >>>>>> sequence 2, >>>>>> >> > send >>>>>> >> > the response back. >>>>>> >> > >>>>>> >> > Just having this functionality does not complete the whole >>>>>> service >>>>>> >> > chaining >>>>>> >> > requirements. We need a way to store the request and responses >>>>>> and >>>>>> >> > access >>>>>> >> > them from different mediators. To do this we may need to improve >>>>>> the >>>>>> >> > property mediator and improve the xpath functions. >>>>>> >> > >>>>>> >> > I have created a Jira for the first requirement and attached a >>>>>> patch >>>>>> >> > [1]. >>>>>> >> > That is to send with a receiving sequence. Please have a look at >>>>>> it and >>>>>> >> > provide your feedback. I'm always open to improvements :). >>>>>> >> > >>>>>> >> > [1] https://issues.apache.org/jira/browse/SYNAPSE-593 >>>>>> >> > >>>>>> >> > Thanks, >>>>>> >> > Supun.. >>>>>> >> > >>>>>> >> > -- >>>>>> >> > Software Engineer, WSO2 Inc >>>>>> >> > http://wso2.org >>>>>> >> > supunk.blogspot.com >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> >>>>>> >> >>>>>> --------------------------------------------------------------------- >>>>>> >> To unsubscribe, e-mail: [email protected] >>>>>> >> For additional commands, e-mail: [email protected] >>>>>> >> >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Software Engineer, WSO2 Inc >>>>>> > http://wso2.org >>>>>> > supunk.blogspot.com >>>>>> > >>>>>> > >>>>>> > >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Software Engineer, WSO2 Inc >>>>> http://wso2.org >>>>> supunk.blogspot.com >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Hiranya Jayathilaka >>>> >>>> Software Engineer; >>>> WSO2 Inc.; http://wso2.org >>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>>> Blog: http://techfeast-hiranya.blogspot.com >>>> >>> >>> >>> >>> -- >>> Software Engineer, WSO2 Inc >>> http://wso2.org >>> supunk.blogspot.com >>> >>> >>> >> >> >> -- >> Ruwan Linton >> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb >> >> WSO2 Inc.; http://wso2.org >> email: [email protected]; cell: +94 77 341 3097 >> blog: http://ruwansblog.blogspot.com >> > > > > -- > Software Engineer, WSO2 Inc > http://wso2.org > supunk.blogspot.com > > > -- Ruwan Linton Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: [email protected]; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
