Является ли оркестровка ответственностью ESB?
Является ли Enterprise Service Bus (инструмент, который выступает в качестве посредника, посредника сообщений, активатора сервиса, усилителя преобразования схемы, провайдера прозрачного местоположения, агрегатора сервисов, балансировщика нагрузки, монитора и всего такого) ответственным за организацию сервисов?
Как насчет размещения автоматизированного бизнес-процесса с более чем тысячами шагов и десятками сервисных вызовов внутри служебной шины предприятия?
Вы бы сделали это, или вы бы использовали специалиста по оркестровке, такой как двигатель BPEL?
Пожалуйста, дай мне свое мнение.
7 ответов
И да и нет. Существует тонкая, а иногда и неразличимая грань между оркестровкой и агрегацией / расширением сервиса.
В общем, если у вас есть какой-либо длительный или сложный бизнес-процесс (ключевым словом является процесс, хотя я собираюсь избегать его определения) - это лучше всего подходит для BPEL.
Простые задачи, такие как объединение результатов трех вызовов службы, могут и часто должны выполняться на уровне ESB.
Не стоит терять слишком много сна, хотя
Отказ от ответственности: я консультант IBM ESB, хотя я не пишу это в официальном качестве.
Нет, ответственность ESB не заключается в организации услуг (как таковых). ESB обеспечивает уровень абстракции на "уровне программной инфраструктуры".
This means that an ESB is a "single logical abstract port of call for connectivity" with any service that is published on the bus.
ESB, будучи абстрактным, означает, что потребителям сервисов на шине не нужно "знать" подробности развертывания сервиса, и возможно представить "сервисы, обращенные внутрь", с единой моделью документов. ESB предоставляет услуги низкого уровня (такие как трансляция протокола и преобразование сообщений), так что внутренние службы могут общаться в упрощенном виде.
Это подразумевает некоторую оркестровку: ESB обеспечивает оркестровку вышеупомянутых низкоуровневых сервисов (например, когда сервис X вызывается через IIOP, преобразуйте его в SOAP с вложениями. Затем преобразуйте запрос из любых сериализованных данных в полезную нагрузку XML).
Оркестровка, которую вы обычно избегаете в ESB: Для того, чтобы обработать эту (страховую) продажу, нам сначала нужно проверить информацию, предоставленную покупателем, затем нам нужно подтвердить риск страхования и, наконец, рассчитать необходимую премию. быть заплаченным за страховку, после которой мы должны… и т. д.
Описанные выше шаги, несомненно, являются бизнес-процессом (который может быть даже прерван… например, если автоматическое страхование не возможно, тогда человеческий андеррайтер должен дополнительно оценить риск).
Бизнес-сервисы (например, валидация, андеррайтинг, премиум-расчет), составляющие бизнес-процесс (например, страховая продажа), который обычно называют оркестровкой, лучше всего подходят для бизнес-процесса и определяются с использованием формализованного бизнес-процесса. Язык моделирования (например, BPEL).
Также сделайте предположение о многих шагах в вашем процессе: В приведенном выше примере валидация - это (конечно-детальная) услуга. Сами правила проверки являются внутренними для этой службы. Для сложных бизнес-правил (т.е. не бизнес-процессов) может потребоваться использование механизма бизнес-правил.
Мой короткий быстрый ответ НЕТ, это не его ответственность.
Я бы предпочел, чтобы это было в BPEL или BPM.
Ммм, я не знаю, что еще добавить:) ... Удачи?
Теперь мое собственное видение.
Что касается всей работы, которую должен выполнять ESB, то размещение оркестровки сервисов внутри основного элемента инфраструктуры вашего SOA не является хорошей идеей.
Совокупно, хорошо! Но занятость вашего канала связи бизнес-логикой, безусловно, вызовет ужасные последствия в способности предоставлять другие функции.
В конце концов, большинство ESB, таких как BEA Aqualogic Service, имеют ограниченную поддержку оркестрации, включая отсутствие возможностей отслеживания состояния, а также такие действия, как ожидание (таймер) или выбор (ожидание, пока какой-либо ввод не будет перемещен в процессе), возможности разделения / объединения (уже добавлено на ALSB 3.0) и тд.
Ни за что. Просто используйте такие инструменты, как BPEL-движок, или такой инструмент, как Weblogic Integration.
Благодарю.
Всякий раз, когда у вас есть две или более служб, которые взаимодействуют, используйте оркестратор служб, т.е. для служб управления композицией и процессом. Если у вас есть ESB выставить этот сервис композиции на ESB. Теперь, если вам нужно создать новый сервис, который включает этот сервис, используйте orchestrator и снова откройте его на esb. Используйте esb в качестве механизма доставки сервисов, посредника и прокси веб-сервиса. При составлении сервиса оркестратор будет использовать esb для взаимодействия с сервисами. Если эти взаимодействующие сервисы используют несовместимые XML-схемы, esb может преобразовать / отобразить их в общую схему во время выполнения и направить запросы сервиса на основе содержимого, например, пространства имен.
Да, оркестровка является обязанностью, в большинстве случаев, ESB. Или, в качестве альтернативы, если вы проводите грань между инфраструктурой ESB и инфраструктурой оркестровки, то вы делаете это на физическом уровне из соображений производительности, а не для логического распределения ответственности.
У вас есть 2 варианта - когда, например, система HR получает нового сотрудника - где вы размещаете бизнес-логику, которая гласит: "Отдел соответствия должен сначала одобрить и проверить, а затем, если все в порядке, потребуется отдел HR чтобы завершить работу по найму, тогда бухгалтерии понадобится новая запись, а затем система заработной платы будет нуждаться в обновлении, а если это не удастся, тогда нам нужно будет отправить электронное письмо в HR"? Если все бизнес-процессы считаются "принадлежащими" инициирующему отделу / приложению, то вся система, которая является предприятием, становится сложной, с разрозненными системами оркестрации.
Второй вариант - централизовать оркестровку, по сути, сделав ее логическим партнером платформы обмена сообщениями. Если вы решите рассматривать их как отдельные артефакты, это зависит только от вас, но в равной степени можно описать оба эти параметра как ESB.
Enterprise Service Bus никогда не должен отвечать за организацию сервисов.
Оркестровка подразумевает минимум "умов", в частности, способность компенсировать неудачные транзакции. Инструменты служебной шины часто говорят, что они предлагают "попробовать-поймать" или что-то в этом роде, но способность запускать компоновку с заданной областью является признаком правильного инструмента оркестровки. Кроме того, способность ждать, знать свое состояние или держать вещи в напряжении - еще один показатель того, что вы имеете дело с оркестратором, а не с автобусом.
Говоря о 1000+ шагах плюс десятках сервисов, подумайте, если-то в процессе. Если все операторы if-then в ваших 1000 шагов говорят только о маршрутизации без изменений в полезных нагрузках, то вы все еще находитесь в "маршрутизации" и, следовательно, все еще в ESB. Но если есть хотя бы одно вложенное if-then, и я начинаю искать разные инструменты. Кроме того, если-то, что выглядит как маршрутизация, может очень быстро повлиять на бизнес-логику. Как только бизнес-логика начинает проявляться, лучший язык, такой как BPEL или BPMN, становится лучше.
Пример дирижера оркестра часто дается, чтобы описать, как работает оркестровка, центральный человек, направляющий музыкантов согласно партитуре. Часто не учитывается идея, что проводник не только направляет, но и слушает, и если что-то идет не так, может компенсировать надежным, воспроизводимым способом.
Например, представьте, что наш первый дирижер идет, чтобы привести игрока с тубой, но сказал, что игрок с тубой решил пойти заняться чем-то другим. Простой "оркестратор" в стиле пинбола принесет секцию тубы, прекрасно зная, что ее там нет, а затем подождет, пока зрители не пожалуются. По-настоящему опытный проводник увидит, что туба исчезла, и немедленно поднимет более глубокие рога баритона, чтобы компенсировать это.