Is this an abuse of Spring Integration?

[evanspa]

Hello All,

A colleague of mine wishes to use Spring Integration for a particular use case, but I'm not sure if it's the *correct* usage of Spring Integration --- and would greatly appreciate any opinions / comments from the Spring community. Here's the use case in question:

A request comes into a Servlet, and the Servlet needs to perform multiple tasks in parallel, collect the "output" from each task, and then formulate a single response. To make a long story short, the intent is follow the composite message processor pattern (leveraging patterns: splitter, router and aggregator) to accomplish this. This is all happening within the context of a Servlet processing a request --- therefore the queues would all be memory based and the format of messages would not be something that required marshaling / un-marshaling; they would just be raw Java objects.

From a conceptual standpoint, the approach makes perfect sense to me (I'm very familiar with the Hohpe/Wolfe EI text). Where I'm not comfortable is whether this represents a good usage of Spring Integration. I say this because the context here is that of processing a request within a Servlet --- and this is certainly not the *traditional* usage of Spring Integration (integrating hetergenous applications; using physical queues and topics; etc).

So my question is, is this an appropriate use of Spring Integration? Should I instead be looking at more "lighter" approaches that deal at the level of thread and thread coordination and such?

Thank you,

-Paul

[oleg.zhurakousky]

and this is certainly not the *traditional* usage of Spring Integration

I am not sure I agree with that. Architecting your system or small part of the system based on the Message exchange IMHO means "flexible architecture" and therefore is the right approach if for integration requirements that you have described. It is also the right approach if such part of the system can change in the future (grow, scaling etc.) as it is easy to change/reconfigure EIP modules or plug in different patterns. So it doesn't really matter if you are writing small console program or large enterprise (web-based) application that integrates with heterogeneous systems. Its really about the task you are trying to accomplish and based on what you described such task is a perfect fit for a framework such as Spring Integration.

The 'lighter' part will come with 'how' you use spring integration. For example if you need to accomplish asynchronous Message handoff, are you going to introduce JMS and JMS-based channel or you simply use a build-in Executor channel? Does your flow or part of it have to by async or should you rely on the fact that the web-server already created a thread for you and you should just use that? IN other words with Spring Integration you can assemble a very simple, light and extensible flow that addresses your requirements, but you can also augment it with the same simplicity as your requirements evolve.

Anyway, it is the right use case for SI

[evanspa]

Oleg,

Thank you very much for the quick reply --- I greatly appreciate your thoughts in this matter. I was thinking my use case wasn't traditional based on the typical examples used from the Hohple/Woolf text (the examples used in the text are mostly around integrating systems/applications from an enterprise standpoint). But based on your comments, I'm going to pursue using SI for my use case. To your point, my usage will be lighter in that I won't be using JMS-based queues; I'll be using the QueueChannel class (for in-memory based queues).

Regards,

-Paul

[oleg.zhurakousky]

You are welcome.
Keep us posted of your progress as well as the issues you encounter (if any. . . nope not).