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

Question

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

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

Спасибо.

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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