Spring Integration
  1. Spring Integration
  2. INT-1685

Add support for a mid-flow "gateway" to support transactions, error-handling, etc.

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0 Final
    • Fix Version/s: General Backlog
    • Component/s: Core
    • Labels:
      None

      Description

      We are not yet sure what we'll be naming this component. The basic idea is to enable transactional boundaries and error-handling capabilities for a segment of the flow. In some respects it's similar to a "sub-flow" where the boundaries represent a black box around some other arbitrarily complex message flow that happens to expose a single input-channel and optionally a single output-channel.

        Activity

        Hide
        Mark Fisher added a comment -

        An interim approach to this type of demarcation is to create a <gateway> that invokes an interface method annotated with @Transactional. Then to invoke that method from a <service-activator>. The <gateway> might also have an "error-channel" reference. At this point, we are basically considering a composite element that provides that service-activator -> gateway functionality.

        However, we are also considering the idea of wrapping any existing flow (as determined by an input-channel and optional output-channel) as a modular "black-box" with a gateway as its entry point (so that the module appears to be "just another adapter").

        Show
        Mark Fisher added a comment - An interim approach to this type of demarcation is to create a <gateway> that invokes an interface method annotated with @Transactional. Then to invoke that method from a <service-activator>. The <gateway> might also have an "error-channel" reference. At this point, we are basically considering a composite element that provides that service-activator -> gateway functionality. However, we are also considering the idea of wrapping any existing flow (as determined by an input-channel and optional output-channel) as a modular "black-box" with a gateway as its entry point (so that the module appears to be "just another adapter").
        Hide
        Oleg Zhurakousky added a comment -

        Dave, I am reassigning this to you based on Mark's comment which points me to the work that i started and you seem to have a good handle on now. But realize that the target release is set for 2.2. However if you have ideas and ability to swing it before that let's talk and we may push it back up.

        Show
        Oleg Zhurakousky added a comment - Dave, I am reassigning this to you based on Mark's comment which points me to the work that i started and you seem to have a good handle on now. But realize that the target release is set for 2.2. However if you have ideas and ability to swing it before that let's talk and we may push it back up.
        Hide
        David Turanski added a comment -

        >>However, we are also considering the idea of wrapping any existing flow (as determined by an input-channel and optional output-channel) as a modular >>"black-box" with a gateway as its entry point (so that the module appears to be "just another adapter").

        I have a spring-integration-flow project at https://github.com/dturanski/spring-integration-flow. There is also a samples project. This is the "black-box" approach as Mark describes called a 'flow'. There is an outbound gateway that provides uniform error handling. It will output an ErrorMessage if the flow throws an exception or if the flow error channel is mapped to an output port. The output-channel is optional for one-way messaging, but it also supports the case in which the flow does not produce a response under certain conditions.

        I haven't gotten into transactions too much but the internal hooks between the gateway channels and the internal flow channels use Direct and POPS (plain old pub sub) - i.e. the flow channels run in the same thread. So transactions should work when the flow input channel is bound to a @Transactional gateway.

        This component also supports properties injection, etc. so you can create multiple instances of the same flow with different configurations (see the samples project). This feature currently depends on Spring 3.1 property sources so it's not be a likely candidate for 2.1 which uses Spring 3.0

        Does this satisfy the request? Are there additional features or changes you would like to see or scenarios I should test?

        Show
        David Turanski added a comment - >>However, we are also considering the idea of wrapping any existing flow (as determined by an input-channel and optional output-channel) as a modular >>"black-box" with a gateway as its entry point (so that the module appears to be "just another adapter"). I have a spring-integration-flow project at https://github.com/dturanski/spring-integration-flow . There is also a samples project. This is the "black-box" approach as Mark describes called a 'flow'. There is an outbound gateway that provides uniform error handling. It will output an ErrorMessage if the flow throws an exception or if the flow error channel is mapped to an output port. The output-channel is optional for one-way messaging, but it also supports the case in which the flow does not produce a response under certain conditions. I haven't gotten into transactions too much but the internal hooks between the gateway channels and the internal flow channels use Direct and POPS (plain old pub sub) - i.e. the flow channels run in the same thread. So transactions should work when the flow input channel is bound to a @Transactional gateway. This component also supports properties injection, etc. so you can create multiple instances of the same flow with different configurations (see the samples project). This feature currently depends on Spring 3.1 property sources so it's not be a likely candidate for 2.1 which uses Spring 3.0 Does this satisfy the request? Are there additional features or changes you would like to see or scenarios I should test?

          People

          • Assignee:
            David Turanski
            Reporter:
            Mark Fisher
          • Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated: