Hm... Now I can see that new approach has improved usability. I like this as another option for the service chaining. Let's wait for suggestions from others.
Thanks Indika On Mon, Nov 9, 2009 at 12:56 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
