ESB Products VS разрабатывать собственные
Я из фоновых знаний Java. Я пробовал коммутаторы только неделю и читал о других продуктах ESB с открытым исходным кодом, но у меня было много проблем с коммутатором, и я действительно не мог получить выгоду от использования продукта для моего проекта ESB.
Я считаю, что продуктам ESB понадобится некоторая кривая обучения, она не будет гибкой для нашего обычного представления пакета и форматирования кода, будут некоторые ограничения и ограничения, такие как один switchyard.xml для всего нашего уровня интеграции, и будет стоить плата за обслуживание от нашего новые разработчики.
Наша обычная до сих пор интеграция между приложениями через JMS, REST и SOAP WS и наша цель - использовать ESB для предоставления большего количества функций (моих целей) нашему уровню интеграции, как показано ниже.
Безопасность и шифрование сообщений, передаваемых между различными приложениями: с помощью двусторонней аутентификации SSL и создания 3-х серверов с одной целью "Интеграция ESB", доступных только с IP-адреса балансировки нагрузки
Балансировка нагрузки, поэтому уровень интеграции будет независимым от интегрированных приложений: он также будет использовать двустороннюю SSL-аутентификацию
Регистрация всех запросов и ответов (вызывающий, вызываемый сервис, успешный или неудачный ответ, время запроса, время ответа)
Ограничения доступа к очереди сообщений: я думаю, что это будет применяться по умолчанию, если на сервере была двусторонняя SSL-аутентификация
Маршрутизация сообщений, поскольку несколько производимых сервисов будут проходить один и тот же сервисный уровень в моей реализации
Шаблоны обмена сообщениями (синхронизация / асинхронизация) будут использоваться с помощью необязательного свойства в запросе к ESB, и, если он опущен, запрос будет проходить по умолчанию для этой службы.
Асинхронный запрос будет обрабатываться с использованием очереди сообщений и прослушивателя для их использования и вызывать соответствующий WS для его обработки.
Проблемы:
- Я решил использовать сервер приложений tomcat, но я не мог выбрать Tomee для встроенного ActiveMQ или Tomcat с отдельным сервером сообщений ActiveMQ, так как я думаю, что это даст мне больше возможностей
- Я мог бы в будущем без проблем сменить Messaging Server на RabbitMQ.
- Я не смог интегрировать консоль ActiveMQ с tomee и не смог получить документацию по использованию ActiveMQ, встроенной в tomee
- Я не знаю, как добавить базовую аутентификацию для каждого посредника в файле tomee.xml, чтобы обеспечить дополнительный уровень безопасности для очередей в разных посредниках, так как, возможно, у меня будет сценарий использования, который я хочу, чтобы приложения производили / потребляли в очередь напрямую.
- Если сервер ActiveMQ разделен, я мог бы определить реплицированное сообщение между тремя серверами, поэтому, если сервер отключен или поврежден, сообщение будет доступно на двух других серверах. Я не знаю, существует ли эта опция на сервере Tomee
Каков наилучший способ записи Log4j в файловую систему или в базу данных. Я предпочитаю базу данных для добавления страниц регистрации в приложение интеграции на будущее.
Какую конфигурацию приложения я мог бы добавить, чтобы сделать приложение гибким для будущих изменений служб (например, шаблон обмена сообщениями по умолчанию для каждой службы sync/async)?
Пожалуйста, не стесняйтесь исправить все мои мысли и расскажите мне, как достичь своих целей и решить проблемы.
Изменить: я забыл упомянуть, что не будет никакой бизнес-логики на нашем уровне интеграции ESB (только служебная шина)