Service chaining

[Supun Kamburugamuva]

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

[indika kumara]

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@...> 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@...
For additional commands, e-mail: dev-help@...

[indika kumara]

> 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@...
For additional commands, e-mail: dev-help@...

[Supun Kamburugamuva]

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@...> 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@...> 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@...
For additional commands, e-mail: dev-help@...

--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

[indika kumara]

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@...> 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@...>
> 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@...>
>> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Supun Kamburugamuva]

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@...> 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@...> 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@...>
> 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@...>
>> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

[indika kumara]

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 <supun06@...> 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@...>
> 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@...>
>> 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@...>
>> > 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@...>
>> >> 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@...
>> >> For additional commands, e-mail: dev-help@...
>> >>
>> >
>> >
>> >
>> > --
>> > Software Engineer, WSO2 Inc
>> > http://wso2.org
>> > supunk.blogspot.com
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Hiranya Jayathilaka-3]

+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 <supun06@...> 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@...> 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@...> 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@...>
> 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@...>
>> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

--

Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

--
Hiranya Jayathilaka
Software Engineer;
WSO2 Inc.;  http://wso2.org
E-mail: hiranya@...;  Mobile: [phone]
Blog: http://techfeast-hiranya.blogspot.com

[Supun Kamburugamuva]

On Mon, Nov 9, 2009 at 1:27 PM, Hiranya Jayathilaka <hiranya911@...> 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@...> 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@...> 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@...> 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@...>
> 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@...>
>> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

--

Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

--
Hiranya Jayathilaka

Software Engineer;
WSO2 Inc.;  http://wso2.org

E-mail: hiranya@...;  Mobile: [phone]
Blog: http://techfeast-hiranya.blogspot.com

--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

[Ruwan Linton]

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 <supun06@...> wrote:

On Mon, Nov 9, 2009 at 1:27 PM, Hiranya Jayathilaka <hiranya911@...> 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@...> 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@...> 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@...> 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@...>
> 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@...>
>> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

--

Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

--
Hiranya Jayathilaka

Software Engineer;
WSO2 Inc.;  http://wso2.org

E-mail: hiranya@...;  Mobile: [phone]
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@...; cell: [phone]
blog: http://ruwansblog.blogspot.com

[Supun Kamburugamuva]

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 <ruwan.linton@...> 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 <supun06@...> wrote:

On Mon, Nov 9, 2009 at 1:27 PM, Hiranya Jayathilaka <hiranya911@...> 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@...> 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@...> 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@...> 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@...>
> 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@...>
>> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

--

Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

--
Hiranya Jayathilaka

Software Engineer;
WSO2 Inc.;  http://wso2.org

E-mail: hiranya@...;  Mobile: [phone]
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@...; cell: [phone]
blog: http://ruwansblog.blogspot.com

--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

[Ruwan Linton]

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 <supun06@...> 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 <ruwan.linton@...> 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 <supun06@...> wrote:

On Mon, Nov 9, 2009 at 1:27 PM, Hiranya Jayathilaka <hiranya911@...> 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@...> 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@...> 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@...> 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@...>
> 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@...>
>> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

--

Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

--
Hiranya Jayathilaka

Software Engineer;
WSO2 Inc.;  http://wso2.org

E-mail: hiranya@...;  Mobile: [phone]
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@...; cell: [phone]
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@...; cell: [phone]
blog: http://ruwansblog.blogspot.com

[Supun Kamburugamuva]

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 <ruwan.linton@...> 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 <supun06@...> 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 <ruwan.linton@...> 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 <supun06@...> wrote:

On Mon, Nov 9, 2009 at 1:27 PM, Hiranya Jayathilaka <hiranya911@...> 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@...> 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@...> 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@...> 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@...>
> 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@...>
>> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

--

Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

--
Hiranya Jayathilaka

Software Engineer;
WSO2 Inc.;  http://wso2.org

E-mail: hiranya@...;  Mobile: [phone]
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@...; cell: [phone]
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@...; cell: [phone]
blog: http://ruwansblog.blogspot.com

--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com