Prototype Bean with Spring integration [INT-852]

[spring-operator]

shanti sharma opened INT-852 and commented

Spring Integration is not respecting scope="prototype" setting when specified in annotation/XML configuration.

We have a requirement to initialize Prototype bean , when the flow is triggered by SI. SI is always creating a singleton bean.

Please provide us solution/workarounds for this.

---

Affects: 1.0.3

[spring-operator]

Grzegorz Grzybek commented

Hello

Can you please describe what is the kind of bean you want to be a prototype? Is this some Spring-Integration specific bean (channel, transformer, selector) or some business component (e.g. ServiceActivator)?

Your scenario may be implemented using some FactoryBean, which produces new objects in it's getObject() method.

Regards Grzegorz Grzybek

[spring-operator]

Grzegorz Grzybek commented

Hello! Anyone still interested in this issue? If so, please give some more information!

[spring-operator]

shanti sharma commented

Here is some detail -

We have a channel, which receives a request from JMS queue and transfers control to a Business service (NOT SI component). Our requirement was to have the Business service as "prototype" bean, Which is not honored by Spring Integration, everything in spring integration is initialized as singleton ( as far as we observed). (We can use a lookup method to resolve this issue, but with lookup method required CGI-lib whereas we are using javaassit)

[spring-operator]

Mark Fisher commented

Can you provide a configuration excerpt?

When you use a "ref" from a Spring Integration component (e.g. service-activator), that reference may be to a prototype bean. It's just like any other bean reference. However, as with any other bean reference the injection happens only once. This is the way "prototype" scope works in Spring generally. What it does mean is that any other "ref" would hold a distinct instance.

When you say that you want to instantiate the bean "when the flow is triggered", I believe you might be looking for something more like a custom scope? i.e. a "flow" scope that would act similar to a "request" scope in a web application. Is that the case?

If so, then the next question would be why do you need that scope? I assume that you have something stateful, whereas the main idea in Spring Integration is to keep all state in the Message (payload and headers) while using stateless services.

Can you please provide some information about the stateful requirements of your services?

Thanks, Mark

[spring-operator]

Thomas Ziem commented

I have a similar requirement.

I also have a stateful service. Each service instance is mapped to an unique conversation id. The service itself is a complex state machine (Commons SCXML) which can send events to other services as well. All services should be connected over message channels and channel adapters. What I need is a SI component that can route a message (e.g. with a conversation id in the message header) to my specific service instances. Or with other words I need message channels and channel adapters in scope="prototype".

Regards, Thomas

[spring-operator]

Oleg Zhurakousky commented

I wholeheartedly agree with Mark on this one

At the core of EIP architecture is the concept of Pipes and Filters where Filter (router, service-activator, aggregator etc.) is by definition a stateless component. The only component that ever manages the state of a conversation is Message which itself defines a mechanism to separate the business state of the conversation (payload) with integration state of the conversation (message headers and message history). You "Package the information into a Message, a data record that the messaging system can transmit through a message channel." and connect to a Filter (router, service-activator, aggregator etc.). Filter is only aware of the channel it is attached to and must be re-usable or it would completely break the architecture rendering unpredictable side effects . Besides Message, EIP defines several other mechanisms to manage and deal with the state of your conversation by allowing you to augment the state of the message in transit (Content Enricher), buffer the message (Aggregator, Resequencer etc.) and most importantly correlate buffered messages via custom correlation strategy (Correlation Identifier).

What you are proposing is to have filters maintain the state by asking them to be state aware. The funny thing is they always are, via accessing the state data within the Message and acting accordingly.

[spring-operator]

Oleg Zhurakousky commented

I am re-classifying it to a "New Feature Request", since it is not a bug.

[spring-operator]

Thomas Ziem commented

Ok. Does it mean that stateful services can not be integrated with spring-integration?

[spring-operator]

Oleg Zhurakousky commented

It depends on your definition of stateful service. For example, look at the latest sample from SI Loan Broker. Loan Broker as a component is as stateful as it can possible be but it is assembled from stateless components which are state-aware when they need to be (the Aggregator aggregates messages for each individual consumer/request)

As Mark suggested before, it would be helpful for all of us if you could elaborate on your statefull requirement. I am afraid you are trying to apply SI Framework in areas for which it wasn't designed for and until you share it with us it is hard to come up with any reasonable suggestion.

[spring-operator]

Thomas Ziem commented

Very nice sample. The question is: Can I integrate the Loan Broker into a web environment with multiple user requests? Exactly that is my problem. I also have service similar to the Loan Broker. My assumption is that you can't use it within a web environment. Am I right?

[spring-operator]

Oleg Zhurakousky commented

Thomas

Of course it could be used with Web or any other client. In fact in Part 2 we're planning to introduce two things:

1. Various clients (WS, Web, Flex etc.)
2. Async interactions.

Yes as of right now, this SI implementation of LB is sync, however it only means that the client is managing the threads. In other words if you have multiple requests all hitting the same service, your app server allocates a new thread for each request. This means you can easily wright a simple webapp and call the gateway as service and achieve the same results.

Having said that, aggregation is limited to collecting and correlating Messages before they are released. We are starting to see a need and requirements around introducing a bit more then just that. We need to provide an infrastructure around managing Conversations which is a bit more sophisticated then simple aggregation, but still rooted to Aggregator pattern.

Stay tuned and we'll be posting updates as requirements are formalized.

[spring-operator]

Thomas Ziem commented

That's the point. I'm looking forward to hearing from you!

Regards, Thomas

[spring-operator]

Artem Bilan commented

Resolving this as Dynamic Integration Flows Support