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

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

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

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

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

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

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

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

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

мой короткий быстрый ответ Нет, это не его ответственность.

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

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

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

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

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

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

ни за что. Просто используйте такие инструменты, как BPEL engine или WebLogic Integration.

спасибо.

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

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

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

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

служебная Шина предприятия никогда не должна отвечать за организацию служб.

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

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

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

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