Announcement Announcement Module
No announcement yet.
Dynamic/programmatic configuration Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dynamic/programmatic configuration

    I am interesting in using Spring Integration in a programmatic way. Basically, I intend to compose MessageHandlerChain's dynamically from data obtained via a GUI and/or stored in a database. Chain's may also change or be replaced at runtime.

    The reference manual has nothing to say about using spring integration programmatically, and modifying flows at runtime.

    Other than having no usage examples in the manual, are there any gotchas or other reasons why programmatic configuration / dynamic modification of chains should not be done? If this is not a recommended approach, I can always extract the programmatic pieces and put that logic into custom service activators, but unfortunately that will require reinventing a lot of SI functionality.


  • #2
    You are looking for the routing slip pattern. Currently it is not implemented in spring integration.
    This is also a JIRA for this one here


    • #3
      In general the programmatic creation of flows or parts of flows is not well supported at the moment in Spring Integration. This is in part due to the focus on the use of Spring namespaces. Often when you dig below the surface of a simple looking namespace element you will find that the handler for that element is creating and configuring a number of components. Of course you can programmatically create these components and you can see examples of this in some of the tests its just not trivial to do.

      In the past I have approached this in a couple of ways either add some sort of custom builder or if the variation is small use a standard config file and instantiate it with different sets of properties applied by a property placeholder configurer.

      As for replacing chains at runtime do you mean components within the chain? Since the channels that connect stages of the chain are not made available it is not that easy to do but again could be done by digging under the namespace.


      • #4
        @Amol: thanks, the link to the routing slip pattern is useful. Until it is available in SI, I think one can "fake it" by implementing some custom routing functionality. That may very well be the best approach.

        @Jonas: Yeah, I've been digging into the namespace handlers to try and understand the underlying components being created and wired, and know exactly what you mean about it not being trivial. In addition to the component wiring, there is also the lifecycle aspects of the components to consider. However, as you say, it does seem to be quite doable.

        I talked about replacing the entire chain at runtime because, based on my analysis of the SI source, that seemed to be easier than changing the components at runtime -- I guess one would need to hook up the relevant event-driven channel with the new chain via an EventDrivenConsumer instance, and keep a reference to the EventDrivenConsumer for unsubscribe at the next MessageHandlerChain replacement. By contrast, MessageHandlerChain does not expose its handler list for programmatic modification.

        Thanks for both of your responses.


        • #5
          I had a scenario earlier where the incoming message needs to be passed through various components and the choice of components was based on the type of the incoming message.
          My scenario wasn't fairly complex and i had a total to 5 possible combination (or combinations of chain of components i would call).
          I had implemented the solution by explicitly setting up 5 chains with 5 different input channels and all of them putting messages on the same output channel.
          The incoming message with xml payload is given to a router which routes the message to an input channel of an appropriate chain pre configured.
          Thus in a way i am achieving my objective of choosing a chain of processing components based on the incoming message.

          However, things would get ugly if the next processing component is dependent on the result of current execution. In this case, the behavior is too dynamic for the above approach and i would need a simple Process Manager to achieve this. Our implementation here would only give us the flexibility to determine the next processing step based on the current result. In this case the router (or the process manager) would have to be more smart and would invoke other components based on a particular logic executed on the result of a component's result. Please note, the process manager would have to set a reply queue same as a queue it is listening to (could also be a temp queue in case of JMS) in the messages being sent out.

          Does that help you in dealing with the dynamic behavior of your application?


          • #6
            Yup, my thinking right now is to implement a very basic ProcessManager to meet my requirements. Will know more after some initial prototyping and experimenting.