Можно ли с уверенностью сказать, что, если ESB предоставляет функции оркестрации, она может быть реализацией BPM?
Я понимаю, что BPM имеет другую цель, а именно моделирование некоторых бизнес-процессов, и реализация этих бизнес-процессов может выполняться любым простым приложением Java / J2EE, сложным приложением SOA или каким-либо приложением, в котором говорится, что я предоставляю BPM. Это правильно?
Первый вопрос:
Ваше утверждение действительно для некоторых бизнес-процессов, которые просто моделируют взаимодействие запрос-ответ.
Но когда дело доходит до сложных бизнес-процессов, мы должны учитывать некоторые другие функции, помимо функций оркестровки. Здесь я перечислил несколько таких сценариев.
Второй вопрос:
да. Но у механизма 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 назначается среднему уровню - оркестровке низкоуровневых сервисов в более крупные сервисные единицы, которые будут доступны бизнесу для использования в процессах, - и BPM на верхнем уровне.
Таким образом, BPM будет использоваться на уровне Business Process Orchestration Layer, а ESB будет способствовать этому, работая в Business Services и Service Enablement.
Другими словами, чтобы добиться успеха в бизнес-процессах, сначала необходимо, чтобы все ваши системы и приложения были представлены в виде сервисов; вот где в игру вступает ESB.
Вы можете увидеть эту ссылку: http://blogs.mulesoft.org/why-bpm-and-esb-need-to-work-toобщежитие/
Позвольте мне внести ясность, проведя различие между BPM, Orchestration и ESB с помощью шаблонов проектирования и спецификаций.
Вообще говоря, «оркестровка» определяется как составной шаблон, использующий шаблоны проектирования «Абстракция процесса», «Централизация процесса» и «Репозиторий состояний». Благодаря реализации паттерна государственного репозитория и в отличие от предыдущего сообщения, оркестровка поддерживает длительные синхронные бизнес-процессы, как и BPM.
Основное практическое различие между ними состоит в том, что промежуточное ПО 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 и Orchestration позволяют графическое представление бизнес-процесса. Различие в том, что оркестровка может быть выражена через независимый от поставщика BPEL (язык выполнения бизнес-процессов), а BPM выражается через специфичную для поставщика BPMN (нотацию моделирования бизнес-процессов). Это еще одна причина избегать инструментов BPM на уровне SOA / Enterprise.
В тех случаях, когда инструмент BPM реализует спецификации Ws *, он является механизмом оркестрации для всех практических целей. Различие опять же в том, что инструменты BPM полагаются на BPMN, зависящую от поставщика, а инструменты оркестрации полагаются на BPEL, не зависящий от поставщика.
В случаях, когда и BPM, и Orchestration должны сосуществовать, ограничьте BPM архитектурой приложения (например, стилем MVC) и позвольте Orchestration способствовать совместному использованию корпоративных активов.
ESB - это совершенно другое животное. Его следует использовать для асинхронных, а не синхронных процессов и полагаться на другой набор шаблонов проектирования (например, Service Broker, асинхронную организацию очередей, промежуточную маршрутизацию и шаблоны Content Enricher).
