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
