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

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

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

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

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

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

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

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

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

например, Apache Camel, вероятно, имеет самую краткую конфигурацию, вот учебник.

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

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

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

варианты:

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

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

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

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

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

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

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

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

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

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

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

WSO2 Корпоративный Автобус(продукта)

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

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

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

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

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

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

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

взгляните на http://www.windowsazure.com/en-us/develop/java/how-to-guides/service-bus-queues/ и http://www.windowsazure.com/en-us/develop/java/how-to-guides/service-bus-topics/ это хороший материал.

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

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

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

" мой первый закон дизайна распределенных объектов: не распределяйте свои объекты (из P ЕАА.)

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

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

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

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

очень краткий обзор преимуществ ESB можно найти здесь:

http://javaenterpriseworld.blogspot.de/2014/02/benefits-of-esb.html

основные профи примерно перечислены...

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

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

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

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

на ESB является решение выше вопросы. ESB...

• помогает приводит в порядок
• может строго следить за соблюдением корпоративной политики
  • например, безопасность, регулирование, аудит и т. д. применяется последовательно
• виртуализирует конечные точки службы
  • облегчите управление версиями, гибкие обновления, Ha / балансировку нагрузки etc.
• выполнять маршрутизацию, посредничество, преобразование и т. д.

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