За последние 10 лет я работал с различными продуктами, которые используются для реализации ESB: Apache Camel, Mule, Oracle Service Bus, IBM Integration Bus (WebSphere Message Broker), Spring Integration, FUSE и т. Д. Я могу сказать, чтоВы отличаетесь от разных точек зрения, но самое главное, что вы должны понять, это то, что ESB - это абстрактное понятие - по сути, «шина» с точки зрения шаблонов интеграции, которая соединяет различные услуги в рамках предприятия.По этой причине вы можете создать ESB с продуктом, который нацелен на эту конкретную потребность (например, IIB), или вы можете создать его с помощью чего-то гораздо более общего (например, SpringIntegration).
Точка зрения управления:
Лучшие коммерческие продукты (те, которые вы называете "ESB"), такие как продукты от Oracle или IBM, хорошо подходят дляэта работа.У них есть хорошие пользовательские интерфейсы, которые предназначены для реализации шаблона шины.На рынке рабочей силы вам потребуется найти (может быть, простой или нет) сертифицированных специалистов для работы с этими продуктами.За этими продуктами вы получите поддержку крупных компаний, с которыми у предприятия уже могут быть действующие контракты.Часто эти продукты имеют очень специфические разъемы, которые могут (или нет, с точки зрения разработчика) облегчить вашу жизнь.В качестве примера, продукт IBM будет иметь очень эффективные соединители для IBM MQ или Mainframe CICS.Они также предлагают готовые интеграции с другими продуктами, такими как BPM.При создании более крупных реализаций ESB проекты строятся на том факте, что не все может быть сделано в таком продукте - это означает, что у вас меньше риск, но меньше гибкость.С точки зрения управления проблемами вы относительно безопасны, потому что обвиняете большую компанию, которая поддерживает вас.В отношении более «открытых» продуктов / фреймворков, таких как FUSE, Mule, Camel и т. Д., Вы начнете получать очень гибкое программное обеспечение, которое также может быть дешевле в качестве стартовой цены.Для работы с ним вам понадобятся общие профили, но вам также понадобятся разработчики программного обеспечения для разработки вашего продукта, потому что ничто не заставляет вас создавать потоки сообщений определенным образом.В определенный момент вам понадобятся, по крайней мере, некоторые очень опытные разработчики, потому что вы можете не получить эффективную поддержку, в зависимости от выбранного вами продукта.С точки зрения управления проблемами, вы несете полную ответственность за этот выбор.
Точка зрения разработчика:
Топовые коммерческие продукты будут поставляться со встроенными разъемами идругие операторы - быстро построить POC.Однако любая настройка будет проблематичной (например, у вас может быть HTTP-коннектор, но вам может потребоваться переключиться на какой-то новый алгоритм SHA, который не был стандартным на момент установки).Будет возможно ввести специальные пользовательские разъемы, но гораздо сложнее, чем с «открытыми» продуктами.Вы получите хорошие пользовательские интерфейсы, которые будут скрывать код.Это будет означать ряд недостатков для вас, например, использование репозитория кода будет неэффективным (не может различать две версии), модульные тесты трудно писать и т. Д. Интеграция с другими продуктами, такими как BPM, заставит вас использоватьпредварительно выбранный товар, все остальное будет выполнимо, но дорого.Открытые продукты / структуры будут гибкими, каждый в команде быстро поймет продукт (например, при условии, что все знают Spring).Изменение некоторых основных функций может быть очень дешевым.Тем не менее, все может быстро выродиться, если нет контроля со стороны опытных участников, потому что вы можете написать практически любой код.
Точка зрения архитектора:
Тем не менее, есть кое-что о ESB, что вы должны знать заранее.Вы должны четко понимать, что вам нужно делать (скажем, маршрутизация, обнаружение служб, преобразование протоколов и т. Д.).Если вам нужно реализовать что-то сложное в ESB, например, преобразование бизнес-сообщения, это означает, что бизнес-аналитику необходимо будет взаимодействовать с вашим ESB.Так, например, специалист по банковским платежам должен будет написать для вас XSLT.Этот XSLT может быть простым, но он также может вызвать большие проблемы, за которые вы будете нести ответственность.Теперь, если этот человек также должен знать продукт по вашему выбору, это усложняет ситуацию.Следовательно, дополнительная ценность интеграции ESB с BPM, BAM и т. Д. Очень сомнительна.Следует также отметить, что в настоящее время для большинства предприятий ESB не создает конкурентного преимущества, например, веб-страницы.Таким образом, инвестирование в сверхсложную разработку или готовый продукт должно быть проблематичным.
Заключение
Не уверен, было ли это подавляющим или понятным, но в итоге все сводится к имеющимся у вас ресурсам и сложности задачи.
Точно так же, как комментарий, в отличие от другого ответа на этот вопрос, если вы строите что-то сложное:
- Обратите внимание на точку зрения архитектора выше.
- Вы можете серьезно рассмотреть вопрос об открытых продуктах, потому что по своему опыту я могу сказать вам, что независимо от того, какую поддержку вы оказываете, когда дела идут плохо, у вас лучше работают очень опытные люди и никакой официальной поддержкидействительно спасет вас (кроме вашего лица).