Обрабатывать вызовы SOAP с помощью ESB / MessageBroker или Grails? - PullRequest
2 голосов
/ 02 марта 2012

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

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

Мне было интересно, рекомендуется ли разделять приложение Grails и сочетать его с чем-то вроде ActiveMQ / ServiceMix / Mule и т. Д.? Любые советы или комментарии приветствуются! И какое решение будет хорошим кандидатом?

1 Ответ

1 голос
/ 02 марта 2012

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

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

Это обусловлено предполагаемым поведением вашего моста SOAP: является ли он асинхронным (т. Е. Запускает и забывает, отправляет сообщение на мост, получает немедленный ACK и позволяет мосту выполнять удаленную диспетчеризацию, когда это возможно) или это так? синхронный (т. е. вызывающий мост удерживается до тех пор, пока удаленный ответ не будет получен и переадресован обратно на него).

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

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

...