Подтвердить что ты не робот

Преимущества сервисной шины предприятия

Где я могу найти некоторую информацию об использовании и преимуществах служебной шины предприятия (ESB)?

Я ищу информацию о:

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

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

Спасибо.

4b9b3361

ОТВЕТЫ

Ответ 2

ESB - это хороший способ реализовать Шаблоны интеграции предприятия.

Виды проблем, которые ESB помогает решить

  • У вас есть несколько протоколов, которые вы хотите нормализовать в одном протоколе (например, FTP, электронная почта, SOAP, XMPP и т.д. в систему обмена сообщениями), например. ActiveMQ. Это позволяет отделить реализацию служб от протокола.
  • Вам нужен последовательный способ привязки сервисов к этой архитектуре, чтобы они могли прослушивать сообщения, обрабатывать сообщения и генерировать сообщения (конечные точки сообщений, адаптеры каналов и т.д.).
  • Вы можете использовать управляемый контейнер для развертывания этих различных компонентов в (например, ServiceMix, Mule)
  • Вы можете захотеть создать несколько заранее подготовленных компонентов и адаптеров в различные протоколы (например, ServiceMix, Mule и Camel имеют много готовых компонентов).
  • Вам могут потребоваться длительные рабочие процессы. Управление бизнес-процессами часто является тем, что предоставляется вместе с ESB (Apache ODE подключается к нескольким ESB с открытым исходным кодом).

Альтернативы ESB

Альтернативы действительно зависят от проблемы, которую вы пытаетесь решить.

  • Для предоставления распределенных услуг люди часто используют серверы приложений, предоставляя услуги через некоторый протокол RPC с точки зрения точки (например, EJB через RMI или веб-службы через HTTP). Таким образом, вместо того, чтобы помещать сообщение на "шину", клиент напрямую вызывает сервер.
  • Чтобы отвечать на конкретные протоколы, вы можете просто создать клиент, который отвечает на этот протокол, например, записывая приложение, которое прослушивает электронные письма с помощью JavaMail или тот, который прослушивает XMPP с помощью Smack. Если ваша проблема ограничена одним или двумя протоколами, возможно, не стоит вносить полный ESB.

Что вам нужно сделать в качестве разработчика для создания ESB-совместимых систем

Это будет зависеть от выбранного вами ESB, хотя, учитывая, что большинство хороших предназначены для вызова во всевозможные протоколы, а также для POJO хоста, вам нечего делать, чтобы создавать ESB-совместимые системы, Стоит попытаться сделать ваш код асинхронным.

Для примера, Apache Camel, вероятно, имеет самую сжатую конфигурацию, здесь tutorial.

Ответ 3

В дополнение к сайтам, которые уже упоминались. Вы должны прочитать эту статью в разделе " Не используйте ESB, если вам абсолютно не нужно". Он был написан техническим директором MuleSource, одним из самых популярных доступных ESB с открытым исходным кодом. Не совсем ответ на ваш вопрос, больше о том, чтобы задать себе вопрос: "Нужен ли мне ESB"?

Ответ 4

Три ключевых преимущества:

  • Шина обеспечивает возможность подключения конечных точек друг к другу без прямого контакта друг с другом. Это упрощает связь для конечных точек, поскольку они должны соответствовать стандартным коммуникационным интерфейсам - шине. (Это с любой технической шиной, а не только с ESB).
  • ESB предоставляет одно место для получения некоторых ключевых показателей конечной точки: частота, доступность и производительность.
  • ESB имеет тенденцию предоставлять более одного интерфейса связи. Однако разработчику нужно только выбрать самый простой способ получить и получить данные с шины.

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

Альтернатива:

  • Просто подключайте вещи друг к другу напрямую, особенно если протоколы связи одинаковы. Это полезно для простых кластеров приложений и не требует слишком много размышлений. Тем не менее, по мере роста числа приложений, поддержка межсоединений становится затруднительной.
  • Другой альтернативой является реализация MQ. Это обеспечит вам способ перемещения данных без сложных взаимосвязей, но тогда вы вынуждены использовать только один канал связи. К счастью для Java, у них есть стандарт JMS.

Практичность:

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

Если у вас нет ESB, я предлагаю вам попробовать Mule для разработки и WebSphere ESB для тестирования и производства. Я имею тенденцию использовать два продукта, которые, как предполагается, следуют стандартам, чтобы убедиться, что поставщики честны и убедитесь, что ваши разработчики соответствуют стандартам, предотвращающим непреднамеренное блокирование вендора.

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

Ответ 5

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

Ответ 6

Посмотрите подкаст Hanselminutes. Он отвечает на несколько вопросов, которые вы действительно должны задать себе перед внедрением служебной шины.

Ответ 7

Корпоративная шина обслуживания (ESB) представляет собой программную архитектуру для промежуточного программного обеспечения, которая предоставляет основные услуги для более сложных архитектур. Например, ESB включает функции, необходимые для реализации сервис-ориентированной архитектуры (SOA). В общем смысле ESB можно рассматривать как механизм, который управляет доступом к приложениям и службам (особенно унаследованным версиям), чтобы представить единый, простой и последовательный интерфейс для конечных пользователей через клиентскую часть на основе Web или форм передние концы.

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

http://searchsoa.techtarget.com/definition/enterprise-service-bus

WSO2 Enterprise Service Bus (продукт)

Документация WSO2 Enterprise Service Bus (ESB) 4.7.0! WSO2 ESB - это быстрый, легкий, 100% открытый источник и удобный ESB, распространяемый под лицензией Apache Software v2.0. WSO2 ESB позволяет системным администраторам и разработчикам удобно настраивать маршрутизацию сообщений, посредничество, преобразование, ведение журнала, планирование задач, переход на другой ресурс, балансировку нагрузки и т.д. Он поддерживает наиболее часто используемые шаблоны интеграции предприятий (EIP) и позволяет осуществлять коммутацию на транспорте, eventing, посредничество на основе правил и посредничество на основе приоритетов для расширенных требований интеграции. Время выполнения ESB спроектировано как полностью асинхронное, неблокирующее и потоковое на основе механизма посредничества Apache Synapse.

WSO2 ESB разработан поверх революционной платформы WSO2 Carbon, основанной на OSGi, которая обеспечивает бесшовную модульность вашего SOA посредством компонентности. Он включает в себя множество функций и дополнительных компонентов (надстроек), которые вы можете установить в ESB, и вы можете легко удалить функции, не требуемые в вашей среде, тем самым позволяя полностью настраивать и настраивать WSO2 ESB для удовлетворения ваших точных потребностей SOA.

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

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

WSO2 ESB - это полноценный ESB с поддержкой предприятия. Он построен на проекте Apache Synapse, который построен с использованием проекта Apache Axis2. Все компоненты построены как пакеты OSGi.

Ответ 8

Взгляните на мою презентацию " Испорченный для выбора - как выбрать правильный ESB".

Я объясню, когда использовать ESB, Integration Suite или просто интеграционную структуру (например, Apache Camel). Я также обсуждаю различия между открытым исходным кодом и проприетарными ESB.

Ответ 10

Первый вопрос, который вам нужно задать самому, - зачем вам ESB?

ESB обычно используется в распределенных архитектурах SOA событий, которые в настоящее время кажутся горячим модным словом. Прежде чем перейти в ESB, позвольте мне напомнить вам о первом законе распределительных систем Мартина Фаулера:

http://martinfowler.com/bliki/FirstLaw.html

"Мой первый закон распределенного проектирования объектов: не распространяйте свои объекты (из P EAA).

Соответствующая глава доступна в Интернете. "

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

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

Что касается преимуществ ESB, они такие же, как SOA, ESB добавляет контекст операций asyn-сообщений (событий).

Ответ 12

Сначала позвольте мне объяснить SOA. Это касается создания архитектуры как набора многоразовых программных модулей, которые отображаются как "Сервисы" с четко определенными интерфейсами. Услуги облегчают свободное соединение и реферат его деталей реализации от клиентов.

SOA может оказаться грязной, если каждый компонент вызывает службы напрямую. Поэтому он имеет следующие общие проблемы.

  • Как вы находите, какие службы используются, а какие нет?
  • Как вы находите клиентов, использующих конкретную услугу?
  • Как вы развертываете обновления службы или открываете новые версии для существующих служб без сбоев?
  • Как вы поддерживаете обратную совместимость для более старых клиентов, ссылающихся на более старые сервисные интерфейсы.
  • Как выполнять протоколирование, аудит, принудительное выполнение и т.д. во всех службах для внутреннего/внешнего трафика?

ESB - это решение для вышеупомянутых проблем. ESB...

  • Помогает привести в порядок
  • Может строго выполнять корпоративные политики
    • например. Безопасность, дросселирование, аудит и т.д. Применяются последовательно
  • Виртуализирует конечные точки службы
    • Упростите управление версиями, гибкие обновления, балансировку нагрузки HA/Load и т.д.
  • Выполнять маршрутизацию, посредничество, преобразование и т.д.

Некоторые примеры использования можно найти здесь. Обратите внимание, что они находятся на сайте разработчика AdroitLogic и строго связаны с UltraESB, AdroitLogic ESB.

Ответ 13

нет нулевой причины использовать ESB. Не делай этого. Непростая сложность. Зачем проходить через посредника, когда вы можете идти прямо? Люди ESB скажут вам, что точка указывает, что это плохо, но почему-то указывать на точку и из ESB хорошо.