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
