Когда использовать ESB? обмен сообщениями с электронной почтой/XMPP/SMS

Question

Я добавляю дополнительную информацию о приложении, поддерживая несколько методов уведомления. В настоящее время, если на сайте есть исключение или на сайте происходит событие, электронное письмо будет отправлено этим пользователям, но я хочу, чтобы это было более общим. Я хочу, чтобы пользователи могли определять приоритеты своих методов уведомления. Если они хотят получить сообщение XMPP, когда они подключены к сети, они будут уведомлены об этом. Если они не подключены к сети, они получат электронное письмо, и так далее и т. Д.

Кажется, что ESB будет тем, что я хотел бы использовать здесь, но каждый ESB, на который я смотрю, выглядит как тяжеловес. Прямо сейчас у меня нет никаких намерений отправлять/перемещать файлы или еще что-то делать для кластеризации/отказа.

Я немного играл с Smack, и он хорошо работает для того, что я хочу. Это просто клиентская библиотека XMPP. Я думаю, после прочтения этих ответов, я должен определить, сколько я получу от Apache Camel или Active MQ и т. Д. Основным компонентом, который я хочу, является механизм маршрутизации. Я могу легко написать один из моих собственных, который приоритизирует/заказывает разные методы, но мне интересно, выгоднее ли сейчас укусить пулю, а не позже, и придется отказаться от моего настраиваемого механизма маршрутизации.

Answer 1

Я думаю, что пока, как я это делал в прошлом, с другими проектами, я пока откажу свой собственный маршрутизатор сообщений. Это будет более легкий вес, и я буду больше ценить/понимать, как это работает.

Инфраструктура, которую я использую, может использовать JMS-сервер, но в настоящее время использует модель Observer/Publisher для одного JVM. Я использую задания Quartz для обработки всех запросов, поэтому сервер не перегружен слишком большим количеством запросов. Когда я масштабируюсь до большего количества серверов, я могу использовать JMS-очередь, если это необходимо, без изменения моей базы кода.

Walter

Answer 2

ESBs очень тяжеловес. Если у вас не будет человека из Accenture, шепчущего вам в ухо, я настоятельно рекомендую пойти с чем-то более управляемым.

Answer 3

ESBs большой вес. Один из интеграционных проектов должен сделать трюк. На ум приходит интеграция Apache Camel и Spring. Apache Camel уже имеет поддержку электронной почты и XMPP. Spring Integration имеет встроенную электронную почту, но в настоящий момент вам нужно будет создать свой собственный XMPP-адаптер, но, похоже, он находится в пути, см. Spring Integration 2.0.

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

Редактирование: Технически как интеграция Apache Camel и Spring можно рассматривать как ESB, но они определенно находятся в облегченном конце шкалы, так как ни один из них не применяет контейнерный механизм. Дополнительная информация о whether Camel is an ESB.

Answer 4

Я бы порекомендовал Apache Camel - его очень прост в использовании и поставляется с XMPP и mail поддержка - наряду со многими другими components.

Если на более позднем этапе вы хотите управлять автономным верблюдом, вы можете развернуть его в OSGI container too.