Является ли оркестровка обязанностью ESB?

Question

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

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

Вы бы сделали это или воспользовались бы услугами специалиста по оркестровке, например движка BPEL?

Пожалуйста, выскажите свое мнение.

Answer 1

Да и нет. Существует тонкая, а иногда и неразличимая грань между оркестровкой и агрегацией / расширением сервиса.

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

Простые задачи, такие как объединение результатов трех вызовов службы, можно и часто следует выполнять на уровне ESB.

Не стоит терять слишком много сна, хотя

Отказ от ответственности: я консультант IBM ESB, хотя я не пишу это в официальном качестве.

Answer 2

Нет, ответственность ESB не заключается в организации услуг (как таковых). ESB обеспечивает уровень абстракции на уровне & «Уровень инфраструктуры программного обеспечения &».

Это означает, что ESB является & единым логическим абстрактным портом вызова для подключения " с любым сервисом, который публикуется в автобусе.

ESB, будучи абстрактным, означает, что потребители услуг в шине не должны & знать " подробности развертывания сервиса, и есть возможность выставить " внутренне стоящие сервисы " с одной моделью документа. ESB предоставляет сервисы низкого уровня (такие как трансляция протокола и преобразование сообщений), так что внутренние сервисы могут общаться в упрощенном виде.

Это подразумевает некоторую оркестровку: ESB обеспечивает оркестровку вышеупомянутых низкоуровневых сервисов (например, когда сервис X вызывается через IIOP, преобразуйте его в SOAP с вложениями. Затем преобразуйте запрос из любых сериализованных данных в полезную нагрузку XML).

Оркестровка, которую вы обычно избегаете в ESB: Чтобы обработать эту (страховую) продажу, нам сначала нужно проверить информацию, предоставленную покупателем, затем нам нужно подтвердить риск страхования и, наконец, рассчитать премия, которую нужно заплатить за страховку, после чего нам нужно & # 8230; и др.

Описанные выше шаги явно являются бизнес-процессом (который даже может быть прерван & # 8230; например, если автоматическое страхование не возможно, тогда человеческий страховщик должен дополнительно оценить риск).

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

Также сделайте предположение о многих шагах в вашем процессе: В приведенном выше примере валидация - это (конечно) сервис. Сами правила валидации являются внутренними для этой службы. Для сложных бизнес-правил (т.е. не бизнес-процессов) может потребоваться использование механизма бизнес-правил.

Answer 3

Мой короткий быстрый ответ - НЕТ, это не его ответственность.

Я бы предпочел, чтобы это было в BPEL или BPM.

Ммм, я не знаю, что еще добавить :) ... Удачи?

Answer 4

Теперь мое собственное видение.

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

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

После всего, большинство ESB такие как BEA Aqualogic Service, имеют ограниченная поддержка оркестрации включая отсутствие состояния возможности и такие действия, как ожидание (таймер) или выбор (ожидание ввода каких-либо входных данных в процесс), возможности разделения/объединения (уже добавлены в ALSB 3.0) и так далее.

Ни за что.Просто используйте такие инструменты, как движок BPEL или такой инструмент, как Weblogic Integration.

Спасибо.

Answer 5

Если у вас есть две или более взаимодействующие службы, используйте оркестратор служб, т. е. для служб управления композицией и процессом. Если у вас есть ESB выставить этот сервис композиции на ESB. Теперь, если вам нужно создать новый сервис, который включает в себя этот сервис, используйте orchestrator и снова откройте его на esb. Используйте esb в качестве механизма доставки сервисов, посредника и прокси веб-сервиса. При составлении сервиса оркестратор будет использовать esb для взаимодействия с сервисами. Если эти взаимодействующие службы используют несовместимые XML-схемы, esb может преобразовать / отобразить их в общую схему во время выполнения и направить запросы на обслуживание на основе содержимого, например, Пространство имен.

Answer 6

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

У вас есть 2 варианта - когда, например, система управления персоналом получает нового сотрудника - где вы размещаете бизнес-логику с надписью &, отдел соответствия сначала должен будет одобрить и проверить, а затем, если это ОК, отдел кадров должен будет завершить работу по найму, тогда бухгалтерии потребуется новая запись, а затем система обновления заработной платы будет нуждаться в обновлении, а если это не удастся, тогда нам нужно будет отправить электронное письмо в отдел кадров & Quot ;? Если все бизнес-процессы считаются «принадлежащими» инициирующему отделу / приложению, то вся система, которая является предприятием, становится сложной, с разрозненными системами оркестрации.

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

Answer 7

Enterprise Service Bus никогда не должен отвечать за организацию сервисов.

Оркестровка подразумевает минимум & "умных"!, в частности, возможность компенсации неудачных транзакций. Инструменты служебной шины часто говорят, что они предлагают & Quot; try-catch & Quot; или что-то в этом роде, но способность запускать скомпонованную область является признаком правильного инструмента оркестровки. Кроме того, способность ждать, знать свое состояние или держать вещи в напряжении - еще один показатель того, что вы имеете дело с оркестратором, а не с автобусом.

Говоря о 1000+ шагах и десятках сервисов, подумайте о том, если-то в процессе. Если все операторы if-then в ваших 1000 шагов говорят только о маршрутизации без изменений в полезных нагрузках, то вы все еще находитесь в & Quot; routing & Quot; и поэтому все еще в ESB. Но если есть хотя бы один вложенный if-then, и я начинаю искать разные инструменты. Кроме того, если-то, что выглядит как маршрутизация, может очень быстро повлиять на бизнес-логику. Как только бизнес-логика начинает проявляться, лучший язык, такой как BPEL или BPMN, становится лучше.

Пример дирижера оркестра часто дается, чтобы описать, как работает оркестровка, центральная личность, направляющая музыкантов согласно партитуре. Часто не учитывается идея, что проводник не только направляет, но и слушает, и если что-то идет не так, может компенсировать надежным, воспроизводимым способом.

Например, представьте, что наш первый проводник идет, чтобы привести игрока с тубой, но сказал, что игрок с тубой решил пойти и заняться чем-нибудь другим. Простой & Quot; orchestrator & Quot; принесет секцию тубы, прекрасно зная, что ее там нет, а затем подождите, пока публика не пожалуется. По-настоящему опытный проводник увидит, что туба исчезла, и немедленно поднимет более глубокие баритон-рога, чтобы компенсировать это.