Synapse
  1. Synapse
  2. SYNAPSE-975

Non blocking Callout Mediator (Call Mediator)

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: FUTURE
    • Component/s: None
    • Labels:
      None

      Description

      One of the major drawbacks in Callout mediator is, it does not leverage the non-blocking transports.
      Send mediator which leverages the non-blocking transports, does not provide a simple way to implement service chaining scenarios.

      Idea of the the Call Mediator is to solve the above two concerns.

      Call Mediator invokes the backend service in an asynchronous manner and return without waiting for the response.
      Mediation will be paused from that point.
      When response is received, mediation flow resumes from next mediator placed after the Call Mediator.

      User will experience two major features with the Mediator.

      • Service chaining scenarios will be much easier to implement.
      • Since both request and response can be handled within a single sequence, can define reusable sequences.
      1. synapse-configs-for-integration-tests.zip
        18 kB
        Isuru Udana Loku Narangoda
      2. SYNAPSE-975v2.patch
        151 kB
        Isuru Udana Loku Narangoda
      3. sample440.patch
        6 kB
        Isuru Udana Loku Narangoda

        Activity

        Hide
        Isuru Udana Loku Narangoda added a comment -

        Attached patch contains Call Mediator implementation.
        Please review the patch.

        Design in brief
        ---------------
        To keep track of important checkpoints in the mediation flow, a stack (called 'ContinuationState Stack') is kept in the message context.
        Every time when we branch to a new sequence, a entry (called 'ContinuationState') is pushed in to the stack.
        This Stack is used to mediate the response message when service is invoked using the Call mediator.

        Mediators which branches the mediation flow (Sequence, Filter, Switch, Clone, etc) are capable of mediate the message using a ContinuationState.

        Show
        Isuru Udana Loku Narangoda added a comment - Attached patch contains Call Mediator implementation. Please review the patch. Design in brief --------------- To keep track of important checkpoints in the mediation flow, a stack (called 'ContinuationState Stack') is kept in the message context. Every time when we branch to a new sequence, a entry (called 'ContinuationState') is pushed in to the stack. This Stack is used to mediate the response message when service is invoked using the Call mediator. Mediators which branches the mediation flow (Sequence, Filter, Switch, Clone, etc) are capable of mediate the message using a ContinuationState.
        Hide
        Isuru Udana Loku Narangoda added a comment -

        Sample and an integration test attached.
        I will provide documentation later, if we are going to have this feature for synapse 3.0

        Show
        Isuru Udana Loku Narangoda added a comment - Sample and an integration test attached. I will provide documentation later, if we are going to have this feature for synapse 3.0
        Hide
        Isuru Udana Loku Narangoda added a comment -

        Attached file (synapse-configs-for-integration-tests.zip) contains 21 synapse configurations for integration tests.
        After we improve the integration test framework to support automating non-sample synapse configurations, we can use these configs to create integration tests.

        Show
        Isuru Udana Loku Narangoda added a comment - Attached file (synapse-configs-for-integration-tests.zip) contains 21 synapse configurations for integration tests. After we improve the integration test framework to support automating non-sample synapse configurations, we can use these configs to create integration tests.
        Hide
        Isuru Udana Loku Narangoda added a comment -

        I am making some changes to the logic that decide whether to enable/disable stack operations.
        I will submit a new patch next weekend with those modifications.

        Show
        Isuru Udana Loku Narangoda added a comment - I am making some changes to the logic that decide whether to enable/disable stack operations. I will submit a new patch next weekend with those modifications.
        Hide
        Isuru Udana Loku Narangoda added a comment -

        Please find the modified patch from the attachment (SYNAPSE-975v2)

        Thanks.

        Show
        Isuru Udana Loku Narangoda added a comment - Please find the modified patch from the attachment ( SYNAPSE-975 v2) Thanks.
        Hide
        Hiranya Jayathilaka added a comment -

        I've just started to review this. My first question is, why do we need another send mediator? We already have two mediators that enable sending messages out. Introducing a third option might increase the level of confusion. Is there a way to somehow unify this work with the existing callout mediator?

        The issue description says that it's difficult to create chaining sequences with the existing send mediator. This used to be the case, but I think the responseSequence option introduced lately addresses this issue for a great extent. Given that, what problem does this new mediator solve?

        In any case, I'd prefer to spend some time on reviewing this. Since it involves several changes to the mediation engine, we need to figure out exactly what we want to achieve with this.Hope that's ok with you Isuru.

        Show
        Hiranya Jayathilaka added a comment - I've just started to review this. My first question is, why do we need another send mediator? We already have two mediators that enable sending messages out. Introducing a third option might increase the level of confusion. Is there a way to somehow unify this work with the existing callout mediator? The issue description says that it's difficult to create chaining sequences with the existing send mediator. This used to be the case, but I think the responseSequence option introduced lately addresses this issue for a great extent. Given that, what problem does this new mediator solve? In any case, I'd prefer to spend some time on reviewing this. Since it involves several changes to the mediation engine, we need to figure out exactly what we want to achieve with this.Hope that's ok with you Isuru.
        Hide
        Isuru Udana Loku Narangoda added a comment -

        Hi Hiranya,

        There are situations where we want to define templates which does a particular task (ex. Login to Salesforce > Get Account Information) and expose that template as a function module which can be called from anywhere in the message flow. The one who call this template can simply call the template and expect to get the result without knowing the underline synapse configuration of the template.

        <sequence>
        <mediator1/>
        <call-template target="Salesforce.getAccounts"/>
        <mediator2/>
        ....
        ....
        </sequence>

        Inside the template we have to invoke backend services to call salesforce operations. If we use the send mediator with receiving sequence within the template, we cannot get the response back to <mediator2/>

        Show
        Isuru Udana Loku Narangoda added a comment - Hi Hiranya, There are situations where we want to define templates which does a particular task (ex. Login to Salesforce > Get Account Information) and expose that template as a function module which can be called from anywhere in the message flow. The one who call this template can simply call the template and expect to get the result without knowing the underline synapse configuration of the template. <sequence> <mediator1/> <call-template target="Salesforce.getAccounts"/> <mediator2/> .... .... </sequence> Inside the template we have to invoke backend services to call salesforce operations. If we use the send mediator with receiving sequence within the template, we cannot get the response back to <mediator2/>
        Hide
        Hiranya Jayathilaka added a comment -

        Isuru, I believe you can see this through now.

        Show
        Hiranya Jayathilaka added a comment - Isuru, I believe you can see this through now.
        Hide
        Isuru Udana Loku Narangoda added a comment -

        Yes Hiranya. Since we are in the last stage of the 3.0 release and this requires drastic changes in the core, let's make it available in a future release.

        Show
        Isuru Udana Loku Narangoda added a comment - Yes Hiranya. Since we are in the last stage of the 3.0 release and this requires drastic changes in the core, let's make it available in a future release.

          People

          • Assignee:
            Isuru Udana Loku Narangoda
            Reporter:
            Isuru Udana Loku Narangoda
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development