Decoupling Spring MVC's Controller from the HTTPServlet

Question

I have been working with Spring for a while now to realize that not all of the incoming requests I receive in my app are HTTP-based. Some requests are email-based, and need email-based responses, others are socket-based (receiving notifications when a value changes in my NOSQL store). All of them, though use more or less the same MVC infrastructure.

Therefore, I thought that maybe rearchitecting the application, in order to remove the coupling between controllers and the HTTP infrastructure will help.

The dispatcher should no longer call controller methods directly, but rather extract the request parameters, and use them to create an abstract message (or event), which it then puts on a message bus. On the other hand, every controller will subscribe its actions (instances of the Action class - an implementation of the Command pattern) for different events.

Since I am quite new to Spring Integration, JMS, and other things like that, I have no idea, which messaging technology to choose. Also, I am pretty sure that an architecture like this has been developed already. Perhaps, I may not even be on the right track.

I accept all kinds of suggestions on how to proceed.

Answer 1

You are right that messaging solution with a little help of some integration patterns is the "right" way to go.

You are saying that e-mails and some NoSQL database are already hitting your controller? This means there is some translation layer between these systems and your controllers. With Spring integration you would use Mail-Receiving Channel Adapter to process incoming e-mails and TCP and UDP Support for NoSQL notifications. Spring MVC controllers can still be used for "true" web requests, accessing message channel underneath.

Each channel adapter would have a unique set of transformers to translate adapter-specific message into canonic format. At the end messages from each endpoints would be routed to the same message channel.

So indeed, your example is a perfect fit for ESB-like solution. Also check out Mule ESB, which is even more mature and powerful.