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

Ответ 1

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

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

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

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

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

Ответ 2

Нет, ответственность ESB - это не оркестровка услуг (как таковая). ESB обеспечивает уровень абстракции на "уровне инфраструктуры программного обеспечения".

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

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

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

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

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

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

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

Ответ 3

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

Я бы предпочел это сделать для BPEL или пакета BPM.

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

Ответ 4

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

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

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

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

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

Спасибо.

Ответ 5

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

Ответ 6

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

У вас есть 2 варианта - когда, например, система HR получает нового сотрудника - где вы размещаете бизнес-логику, которая гласит: "Департамент соответствия должен будет сначала утвердить и проверить, а затем, если это нормально, HR отделу необходимо будет завершить работу по найму, тогда бухгалтерии потребуется новая запись, а затем система начисления заработной платы нуждается в обновлении, а если это не удастся, нам нужно будет отправить электронное письмо в HR"? Если все бизнес-процессы считаются "принадлежащими" инициирующим отделом/приложением, тогда общая система, являющаяся предприятием, становится сложной, с разрозненными системами оркестровки.

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

Ответ 7

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

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

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

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

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