You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Supun Kamburugamuva <su...@gmail.com> on 2009/11/08 21:28:10 UTC
Service chaining
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<https://issues.apache.org/jira/browse/SYNAPSE-593>
Thanks,
Supun..
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Service chaining
Posted by indika kumara <in...@gmail.com>.
> And... +1 For keeping and retrieving non string properties.
>
Above idea have came form Andreas sometime back [1] (a comment in the JIRA)
[1] https://issues.apache.org/jira/browse/SYNAPSE-503
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Service chaining
Posted by indika kumara <in...@gmail.com>.
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 <su...@gmail.com> 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 <in...@gmail.com>
> 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 <su...@gmail.com>
>> 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 <in...@gmail.com>
>> > 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 <su...@gmail.com>
>> >> 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: dev-unsubscribe@synapse.apache.org
>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Software Engineer, WSO2 Inc
>> > http://wso2.org
>> > supunk.blogspot.com
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Service chaining
Posted by Supun Kamburugamuva <su...@gmail.com>.
Hi,
With the current implementation a property is used to specify the
out/receiving sequence. Property name is RECEIVING_SEQUENCE. In the send
mediator this property is set to the appropriate sequence.
In the injectMessage method of SynapseEnvironment we look for this property
and if it is present send the message in that sequence instead of main or
out sequence. If a proxy service has two out paths and one have send with
the receiving sequence and one doesn't have a receiving sequence, the
response to the send without the receiving sequence will still go through
the outSequence.
The advantage I see in using a property is, user can set the property using
the normal property mediator as well.
I'm bit unclear about the stack approach suggested by Ruwan. May be I'll
have to think a bit more :)
Thanks,
Supun..
On Tue, Nov 10, 2009 at 4:01 AM, Ruwan Linton <ru...@gmail.com>wrote:
> 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 <su...@gmail.com>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 <ru...@gmail.com>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 <su...@gmail.com>wrote:
>>>
>>>> On Mon, Nov 9, 2009 at 1:27 PM, Hiranya Jayathilaka <
>>>> hiranya911@gmail.com> 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 <
>>>>> supun06@gmail.com> 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 <indika.kuma@gmail.com
>>>>>> > 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 <
>>>>>>> supun06@gmail.com> 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 <
>>>>>>> indika.kuma@gmail.com>
>>>>>>> > 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 <
>>>>>>> supun06@gmail.com>
>>>>>>> >> 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: dev-unsubscribe@synapse.apache.org
>>>>>>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>> >>
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > --
>>>>>>> > Software Engineer, WSO2 Inc
>>>>>>> > http://wso2.org
>>>>>>> > supunk.blogspot.com
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Software Engineer, WSO2 Inc
>>>>>> http://wso2.org
>>>>>> supunk.blogspot.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hiranya Jayathilaka
>>>>>
>>>>> Software Engineer;
>>>>> WSO2 Inc.; http://wso2.org
>>>>> E-mail: hiranya@wso2.com; 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: ruwan@wso2.com; 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: ruwan@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Service chaining
Posted by Ruwan Linton <ru...@gmail.com>.
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 <su...@gmail.com>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 <ru...@gmail.com>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 <su...@gmail.com>wrote:
>>
>>> On Mon, Nov 9, 2009 at 1:27 PM, Hiranya Jayathilaka <
>>> hiranya911@gmail.com> 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 <supun06@gmail.com
>>>> > 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 <in...@gmail.com>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 <
>>>>>> supun06@gmail.com> 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 <
>>>>>> indika.kuma@gmail.com>
>>>>>> > 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 <
>>>>>> supun06@gmail.com>
>>>>>> >> 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: dev-unsubscribe@synapse.apache.org
>>>>>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Software Engineer, WSO2 Inc
>>>>>> > http://wso2.org
>>>>>> > supunk.blogspot.com
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Software Engineer, WSO2 Inc
>>>>> http://wso2.org
>>>>> supunk.blogspot.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Hiranya Jayathilaka
>>>>
>>>> Software Engineer;
>>>> WSO2 Inc.; http://wso2.org
>>>> E-mail: hiranya@wso2.com; 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: ruwan@wso2.com; 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: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: Service chaining
Posted by Supun Kamburugamuva <su...@gmail.com>.
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 <ru...@gmail.com>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 <su...@gmail.com>wrote:
>
>> On Mon, Nov 9, 2009 at 1:27 PM, Hiranya Jayathilaka <hiranya911@gmail.com
>> > 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 <su...@gmail.com>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 <in...@gmail.com>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 <
>>>>> supun06@gmail.com> 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 <
>>>>> indika.kuma@gmail.com>
>>>>> > 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 <
>>>>> supun06@gmail.com>
>>>>> >> 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: dev-unsubscribe@synapse.apache.org
>>>>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Software Engineer, WSO2 Inc
>>>>> > http://wso2.org
>>>>> > supunk.blogspot.com
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Software Engineer, WSO2 Inc
>>>> http://wso2.org
>>>> supunk.blogspot.com
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Hiranya Jayathilaka
>>>
>>> Software Engineer;
>>> WSO2 Inc.; http://wso2.org
>>> E-mail: hiranya@wso2.com; 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: ruwan@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Service chaining
Posted by Ruwan Linton <ru...@gmail.com>.
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 <su...@gmail.com>wrote:
> On Mon, Nov 9, 2009 at 1:27 PM, Hiranya Jayathilaka <hi...@gmail.com>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 <su...@gmail.com>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 <in...@gmail.com>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 <su...@gmail.com>
>>>> 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 <indika.kuma@gmail.com
>>>> >
>>>> > 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 <
>>>> supun06@gmail.com>
>>>> >> 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: dev-unsubscribe@synapse.apache.org
>>>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Software Engineer, WSO2 Inc
>>>> > http://wso2.org
>>>> > supunk.blogspot.com
>>>> >
>>>> >
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Software Engineer, WSO2 Inc
>>> http://wso2.org
>>> supunk.blogspot.com
>>>
>>>
>>>
>>
>>
>> --
>> Hiranya Jayathilaka
>>
>> Software Engineer;
>> WSO2 Inc.; http://wso2.org
>> E-mail: hiranya@wso2.com; 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: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: Service chaining
Posted by Supun Kamburugamuva <su...@gmail.com>.
On Mon, Nov 9, 2009 at 1:27 PM, Hiranya Jayathilaka <hi...@gmail.com>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 <su...@gmail.com>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 <in...@gmail.com>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 <su...@gmail.com>
>>> 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 <in...@gmail.com>
>>> > 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 <
>>> supun06@gmail.com>
>>> >> 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: dev-unsubscribe@synapse.apache.org
>>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Software Engineer, WSO2 Inc
>>> > http://wso2.org
>>> > supunk.blogspot.com
>>> >
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>
>>>
>>
>>
>> --
>> Software Engineer, WSO2 Inc
>> http://wso2.org
>> supunk.blogspot.com
>>
>>
>>
>
>
> --
> Hiranya Jayathilaka
>
> Software Engineer;
> WSO2 Inc.; http://wso2.org
> E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Service chaining
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
+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.
Thanks,
Hiranya
On Mon, Nov 9, 2009 at 12:26 PM, Supun Kamburugamuva <su...@gmail.com>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 <in...@gmail.com>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 <su...@gmail.com>
>> 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 <in...@gmail.com>
>> > 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 <supun06@gmail.com
>> >
>> >> 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: dev-unsubscribe@synapse.apache.org
>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Software Engineer, WSO2 Inc
>> > http://wso2.org
>> > supunk.blogspot.com
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>
--
Hiranya Jayathilaka
Software Engineer;
WSO2 Inc.; http://wso2.org
E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
Re: Service chaining
Posted by Supun Kamburugamuva <su...@gmail.com>.
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 <in...@gmail.com>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 <su...@gmail.com>
> 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 <in...@gmail.com>
> > 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 <su...@gmail.com>
> >> 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: dev-unsubscribe@synapse.apache.org
> >> For additional commands, e-mail: dev-help@synapse.apache.org
> >>
> >
> >
> >
> > --
> > Software Engineer, WSO2 Inc
> > http://wso2.org
> > supunk.blogspot.com
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Service chaining
Posted by indika kumara <in...@gmail.com>.
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 <su...@gmail.com> 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 <in...@gmail.com>
> 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 <su...@gmail.com>
>> 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: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Service chaining
Posted by Supun Kamburugamuva <su...@gmail.com>.
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 <in...@gmail.com>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 <su...@gmail.com>
> 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: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Service chaining
Posted by indika kumara <in...@gmail.com>.
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 <su...@gmail.com> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org