Отключение контроллера Spring MVC от HTTPServlet - PullRequest
6 голосов
/ 18 декабря 2011

Я некоторое время работал с Spring, чтобы понять, что не все входящие запросы, которые я получаю в моем приложении, основаны на HTTP. Некоторые запросы основаны на электронной почте и требуют ответов на основе электронной почты, другие - на основе сокетов (получение уведомлений при изменении значения в моем хранилище NOSQL). Все они, хотя и используют более или менее одинаковую инфраструктуру MVC.

Поэтому я подумал, что, возможно, поможет реструктуризация приложения, чтобы удалить связь между контроллерами и инфраструктурой HTTP.

Диспетчер больше не должен напрямую вызывать методы контроллера, а должен извлекать параметры запроса и использовать их для создания абстрактного сообщения (или события), которое он затем помещает в шину сообщений. С другой стороны, каждый контроллер будет подписывать свои действия (экземпляры класса Action - реализация шаблона Command) на разные события.

Поскольку я довольно новичок в Spring Integration, JMS и других подобных вещах, я понятия не имею, какую технологию обмена сообщениями выбрать. Кроме того, я уверен, что подобная архитектура уже разработана. Возможно, я даже не на правильном пути.

Я принимаю всевозможные предложения о том, как поступить.

1 Ответ

5 голосов
/ 18 декабря 2011

Вы правы, что решение для обмена сообщениями с небольшой помощью некоторых шаблонов интеграции - это "правильный" путь.

Вы говорите, что электронная почта и некоторые базы данных NoSQL уже поражают ваш контроллер?Это означает, что между этими системами и вашими контроллерами существует некоторый уровень перевода.При интеграции Spring вы будете использовать Адаптер канала приема почты для обработки входящих сообщений электронной почты и Поддержка TCP и UDP для уведомлений NoSQL.Контроллеры Spring MVC все еще можно использовать для «настоящих» веб-запросов, получая доступ к каналу сообщений внизу.

Каждый адаптер канала будет иметь уникальный набор преобразователей для перевода адаптера-специфическое сообщение в каноническом формате.В конце сообщения от каждой конечной точки будут перенаправляться на один и тот же канал сообщений .

Так что, действительно, ваш пример идеально подходит для решения, подобного ESB.Также обратите внимание на Mule ESB , который еще более зрелый и мощный.

...