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

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

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

4 6
bpm esb orchestration

4 ответа:

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

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

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

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

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

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

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

10

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

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

Ура

7

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

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

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

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

3

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

Вообще говоря, "оркестрация" была определена как сложный шаблон, использующий абстракцию процесса, централизацию процесса и шаблоны проектирования хранилища состояний. В силу реализации паттерна Государственного репозитория и в отличие от предыдущего поста, Orchestration поддерживает длительно работающие, синхронные бизнес-процессы, так же как УДАРОВ В МИНУТУ.

Основное практическое различие между 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, и инструменты оркестрации позволяют графически представить бизнес-процесс. Различие заключается в том, что оркестрация может быть выражена через Vendor-Neutral BPEL (язык выполнения бизнес-процессов), в то время как BPM выражается через Vendor Specific BPMN (нотация моделирования бизнес-процессов). Это еще одна причина избегать инструментов BPM на уровне SOA / Enterprise.

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

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

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

-2