BPM vs ESB-оркестровка?

можем ли мы с уверенностью сказать, что если ESB предоставляет функции оркестровки, он имеет право быть реализацией BPM?

Я понимаю, что BPM имеет другую цель, которая заключается в моделировании некоторых бизнес-процессов, и реализация этих бизнес-процессов может быть выполнена любым простым приложением Java/J2EE, сложным приложением SOA или некоторым приложением, говорящим, что я предоставляю BPM. Это правда?

4 ответов


Первый Вопрос:

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

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

  1. давайте возьмем бизнес-процесс, который требует поддерживать свое состояние в течение длительного периода времени. Мы обычно называем их state-ful или long running коммерческие процессы. Для поддержки такого рода бизнес-процессов должен существовать механизм сохранения состояния. Эта функция не относится к функциям оркестровки.
  2. рассмотрим бизнес-процесс, который требует определенных возможностей компенсации. В этом случае некоторые стандарты моделирования бизнес-процессов, такие как WS-BPEL, определили его механизмы компенсации. Таким образом, помимо функций оркестровки, есть некоторые другие функции, которые должны быть продуманный.

Второй Вопрос:

да. Но есть несколько плюсов в движке BPM по сравнению с вашими упомянутыми механизмами реализации.

одним из преимуществ является то, что невозможно достичь уровня абстракции моделирования, предоставляемого движком BPM из приложения Java. Предположим, мы использовали приложение JAVA для реализации логики бизнес-процесса, и этот бизнес-процесс пошел в производство. Скажем, нам нужно изменить URL конечной точки своего партнера услуга. В этом случае теперь реализацию бизнес-процесса необходимо модифицировать, повторно скомпилировать и развернуть обратно в производственную систему. если мы реализуем бизнес-процесс со стандартом языка бизнес-процесса, как WS-BPEL, мы можем изменить конфигурацию бизнес-процесса очень легко и нажать его назад к продукции. Это улучшает эффективность и уменьшает расходы на техническое обслуживание дела. Также есть и другие причины, такие как легкая адаптивность и гибкость.


Я создал эти слайды некоторое время назад, чтобы точно объяснить, как вы можете использовать их и отношения между ними: http://www.slideshare.net/salaboy/jbpm5-community-training-module-25-bpm-for-developers

вам нужно понять различную перспективу между чем-то вроде BPEL/ESB/Orchestration и BPMN (ориентированным на бизнес), у них очень разные области.

Ура


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

таким образом, BPM будет использоваться на уровне оркестровки бизнес-процессов, и ESB позволит и облегчит это, работая в Business Services и Service Enablement.

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

вы можете увидеть эту ссылку:http://blogs.mulesoft.org/why-bpm-and-esb-need-to-work-together/


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

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

основное практическое различие между 2 заключается в том, что промежуточное ПО Orchestration (например, WebSphere Process Server, BizTalk, Oracle BPEL Manager и Windows Workflow Foundation) поддерживает большинство спецификаций WS*. Это включает в себя Ws BPEL, WS Security, WS Atomic Transaction, WS Business Activity,WS Reliable Messaging и т. д. большинство BPM-инструментов нет.

в результате, не стесняйтесь использовать оркестровку на уровне предприятия, но будьте очень осторожны с использованием BPM в этой области.

на практике как BPM, так и инструменты оркестровки позволяют графическое представление бизнес-процесса. Различие в том, что оркестровка может быть выражена через Поставщика BPEL (язык выполнения бизнес-процесса), в то время как BPM выражается через Поставщиком BPMN (нотация моделирования бизнес-процессов). Это еще одна причина избегать инструментов BPM на уровне SOA / Enterprise.

в случаях, когда инструмент BPM реализует спецификации Ws *, это механизм оркестровки для всех практических целей. Различие вновь, что инструменты BPM полагаться на поставщика BPMN и инструменты оркестровки полагаться на поставщика, язык BPEL.

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

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