Spring Integration dynamic configuration

[mouth4war]

Good morning!

We are studying for the possibility to use Spring Integration in a major project and I have a few questions. I'll post each of these question-scenarios in a separate thread.

Is it possible to configure (or instantiate) the Spring Integration components more dynamically than by using the (fairly static) xml or annotation driven configuration? for example, the message-bus (the basis for everything) would be configured in the xml/annotation and the channels/endpoints/adapters etc would be defined in a database and their configuration/set-up would be fetched at runtime. Is this possible with Spring and/or spring Integration?

Thank you for your time!

[iwein]

I don't see how fetching the configuration from the database would make things more dynamic than fetching from the file system. The problem is to change the configuration of a running system. There are some successes on using OSGi to do this (see http://forum.springframework.org/showthread.php?t=60883).

The problems associated with dynamically changing the implementation of a running application are dealt with by OSGi, so I would suggest to look that way. Spring (and therefore Spring Integration) are very suitable for OSGi.

[mouth4war]

Thank you for your reply.

Maybe I'll try to explain my question a bit differently.

In Spring the channels and endpoints etc are configured one way or another. Using the XML or by using annotations. The framework instantiates objects based on these configurations.

Is it possible to configure just some of the integration needs and create the rest by creating specific objects directly in the code? These objects would be created based on data that is harvested from a database that (possibly) multiple applications share. Is it reasonable/advisable to do so?

I'm pretty new to Spring, so please excuse me if I ask stupid things

[iwein]

You can create any objects you want in code, so you could fill your integration needs like that too. You need to be aware though that you should not try to change the wiring within an application context while it is already started.

During startup you can do anything you want with BeanFactoryPostProcessors or BeanPostProcessors, but that doesn't give you a dynamic system at runtime (after startup). In any case Spring Integration doesn't have specific support for this, but if you come up with a good use case this could change.

I don't really see why you would want to load your configuration instructions from a database, but I'd be interested to learn.

[mouth4war]

I'm just trying to dig out information that I was told to dig so unfortunatelly I can't give a use case or further information at this time.

[iwein]

I'm just trying to dig out information that I was told to dig so unfortunatelly I can't give a use case or further information at this time.

That's fine, but I'm trying to figure out what you're digging for. Maybe you should tell the person that told you to dig that you found me =). I can think of quite a few ways to change configuration dynamically based on information in a database, but I don't see a reason why you would want to, so I can't tell you which would make sense in your situation.

[mouth4war]

I've managed to get some new details on what I'm supposed to dig out.

Here's a list :-)

1. Dynamic configuration meant the possibility of add, remove, shutdown and start componenets/targets. OSGi is propably a tool for that?
2. What are the boundaries and nature of Spring Integration?
3. How does Spring Integration work internally (how are the messages propagated from one component to another)?
4. Is there a failover/persistence support for the messages? What happens if the server is shutdown with brute force, can the Spring Integration continue from this once it has been started again?

That's the list of thing I'm going to have to present to my team about Spring Integration. At the moment I'm not too confident on my presentation ;-)

[iwein]

1. Dynamic configuration meant the possibility of add, remove, shutdown and start componenets/targets. OSGi is propably a tool for that?
2. What are the boundaries and nature of Spring Integration?
3. How does Spring Integration work internally (how are the messages propagated from one component to another)?
4. Is there a failover/persistence support for the messages? What happens if the server is shutdown with brute force, can the Spring Integration continue from this once it has been started again?

That's the list of thing I'm going to have to present to my team about Spring Integration. At the moment I'm not too confident on my presentation ;-)

If you like a class A presentation on Spring Integration you could get one of us to come do it. I would welcome the opportunity.

Now for your questions:
ad 1. Yes, definitely. I have a working sample I could demonstrate.
ad 2. Spring Integration works within a Spring ApplicationContext. There are many adapters for different transport protocols, but Spring Integration does not provide it's own.
ad 3. Messages are passed through a Queue or direct method call based on your channel configuration.
ad 4. You can have parts of the system operate within a transaction when using direct channels. It is possible although not the default to persist messages along the way. Alternatively you can rely on JMS for guaranteed delivery.

[mouth4war]

What if there are two or more applications running with Spring Integration with slightly different channel etc. configurations but servicing same parties, can these SI applications interoperate easily?

[iwein]

Can you show me a code sample of what you're trying to do?