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
