Терминология служебной шины предприятия

Может ли кто-нибудь объяснить на начальном-промежуточном уровне терминологию "автобус", "транспорт" и "конечная точка" в контексте служебной шины предприятия? Я разработчик С# с несколькими годами опыта, но только начинаю работать с ESB.

Кажется, что "шина" - это фактически очередь, на которую вы можете отправлять и получать сообщения. Я в порядке с этим. Однако я работаю над каким-то существующим кодом, используя NServiceBus, и я думаю, что если бы я наследовал терминологию "конечная точка" и "транспорт", сделайте огромный скачок вперед в моем понимании.

Ответ 1

Позвольте мне попытаться разъяснить вам эти условия:

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

  • Routing. Сообщения могут быть перенаправлены в разные службы, в зависимости от содержимого сообщения или спецификации конечной точки.
  • Преобразования сообщений/посредничество между различными форматами
  • Преобразование транспортного протокола. ESB должен иметь возможность бесшовно интегрировать приложения которые используют разные транспортные протоколы (JMS, HTTP/S, чистый TCP и т.д.).
  • Улучшение сообщения. Сообщения могут быть обогащены отсутствующими данными перед дальнейшей обработкой.
  • Безопасность
  • Управление и мониторинг

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

Конечно, это лишь очень краткие описания терминов. Помните, что Enterprise Service Bus - это только ловушка для определенного типа архитектуры (или концепции), но она никоим образом не стандартизирована. Таким образом, конкретные реализации могут сильно отличаться друг от друга. Если вас интересует стандартизованный ESB, вы можете взглянуть на JBI (Java Bussiness Integration). Существует несколько версий JBI с открытым исходным кодом, среди которых Apache ServiceMix, Mule, OpenESB. Очень хорошее введение в технологии ESB представлено в "Open Source ESBs in Action ", опубликованной Manning.

Ответ 2

Я бы рекомендовал посмотреть ресурсы, связанные с интеграцией Enterprise Application Integration (EAI), которая вращается вокруг ESB и различных моделей и шаблонов, используемых для интеграции решений. Подумайте, что это архитектура GoF для ESB:

http://www.enterpriseintegrationpatterns.com/

и

http://www.enterpriseintegrationpatterns.com/toc.html

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