BPM vs ESB - Orchestrazione?

Question

Possiamo tranquillamente affermare che se ESB fornisce funzionalità di orchestrazione, è idoneo per essere un'implementazione di BPM?

Capisco che BPM ha uno scopo diverso, che è quello di modellare alcuni processi aziendali e l'implementazione di quei processi di business può essere fatto da qualsiasi semplice applicazione Java/J2EE, applicazione SOA complessa, o qualche applicazione dicendo che fornisco BPM . È giusto?

Answer 1

prima domanda:

La tua affermazione è valida per alcuni processi di business che si limitano a modelli di interazione richiesta-risposta.

Ma quando si tratta di processi aziendali complessi, dobbiamo considerare alcune altre caratteristiche oltre alle funzionalità di orchestrazione. Qui ho elencato alcuni di questi scenari.

1. Facciamo un processo aziendale che richiede di mantenere il suo stato per un lungo periodo di tempo. Normalmente li chiamiamo processi aziendali a lunga scadenza o di lunga durata. Per supportare questo tipo di processi aziendali, dovrebbe esistere un meccanismo di persistenza dello stato. Questa funzionalità non è rilevante per le funzionalità di orchestrazione.
2. Considerare un processo aziendale, che richiede alcune funzionalità di compensazione. In tal caso, alcuni degli standard di modellazione dei processi aziendali, come WS-BPEL, hanno definito il proprio compensation mechanisms. Quindi, a parte le funzionalità di orchestrazione, ci sono alcune altre caratteristiche che devono essere considerate.

seconda domanda:

Sì. Ma ci sono diversi vantaggi in un motore BPM rispetto ai meccanismi di implementazione citati.

Un vantaggio è che non è possibile ottenere un livello di astrazione di modellazione fornita da un motore BPM da un'applicazione Java. Diciamo che abbiamo utilizzato un'applicazione JAVA per implementare una logica di processo aziendale e che il processo aziendale è andato in produzione. Supponiamo di dover modificare un URL endpoint del suo servizio partner. In questo caso, ora l'implementazione del processo aziendale deve essere modificata, ricompilata e reintrodotta nel sistema di produzione. se implementiamo il processo di business con uno standard di linguaggio di processo aziendale come WS-BPEL, possiamo modificare la configurazione del processo di business molto facilmente e riportarla alla produzione. Ciò migliora l'efficienza e riduce i costi di manutenzione aziendale. Ci sono anche altri motivi come la facile adattabilità e flessibilità.

Answer 2

Ho creato queste diapositive qualche tempo fa per spiega esattamente come si entrambi e le relazioni tra loro è possibile utilizzare: http://www.slideshare.net/salaboy/jbpm5-community-training-module-25-bpm-for-developers

È necessario comprendere la diversa prospettiva tra qualcosa come BPEL/ESB/orchestrazione e BPMN (orientato al business) hanno scopi molto diversi.

Acclamazioni

Answer 3

Normalmente ESB viene assegnato lo strato intermedio - l'aggregazione di servizi di basso livello in unità più grandi servizi, che saranno esposti al business per l'utilizzo nei processi - e BPM nello strato superiore.

Quindi BPM verrà utilizzato nel Business Process Orchestration Layer e ESB lo abiliterà e agevolerà lavorando in Business Services e Service Enablement.

In altre parole, per avere successo con i processi aziendali è necessario innanzitutto che tutti i sistemi e le app siano esposti come servizi; è qui che entra in gioco un ESB.

si poteva vedere questo link: http://blogs.mulesoft.org/why-bpm-and-esb-need-to-work-together/

Answer 4

permettetemi di aggiungere chiarezza, facendo la distinzione tra BPM, orchestrazione, e ESB, attraverso modelli di progettazione e le specifiche.

In generale, "Orchestrazione" è stata definita come un modello composto che utilizza i modelli di progettazione Process Abstraction, Process Centralization e State Repository. In virtù dell'implementazione dello State Repository Pattern e contrariamente a un post precedente, Orchestration supporta processi aziendali sincroni e long run, proprio come BPM.

La principale distinzione pratica tra il 2 è che il middleware di orchestrazione (ad esempio WebSphere Process Server, BizTalk, Oracle BPEL Manager e Windows Workflow Foundation) supporta la maggior parte delle specifiche WS *. Questo include BPW, Ws Security, Ws Atomic Transaction, Ws Business Activity, Ws Reliable Messaging, ecc., Mentre la maggior parte degli strumenti BPM no.

Come risultato, sentitevi liberi di utilizzare Orchestration a livello Enterprise, ma state molto attenti all'utilizzo di BPM in tale ambito.

In pratica, entrambi gli strumenti BPM e Orchestration consentono la rappresentazione grafica di un processo aziendale. La distinzione è che Orchestration può essere espressa tramite Vendor-Neutral BPEL (Business Process Execution Language), mentre BPM è espresso tramite Specifico fornitore BPMN (Business Process Modeling Notation). Questo è un altro motivo per evitare gli strumenti BPM a livello SOA/Enterprise.

Nei casi in cui uno strumento BPM implementa le specifiche Ws *, è un motore di orchestrazione per tutti gli scopi pratici. La distinzione è che gli strumenti BPM basati su strumenti BPMN e orchestrazione specifici del fornitore si basano su BPEL fornitore-neutrale.

Nei casi in cui sia BPM che Orchestration devono coesistere, limitare il BPM all'architettura dell'applicazione (ad esempio lo stile MVC) e consentire a Orchestration di promuovere la condivisione delle risorse aziendali.

Un ESB è un animale completamente diverso. Dovrebbe essere utilizzato per processi asincroni anziché sincroni e si affida a un diverso insieme di modelli di progettazione (ad esempio Service Broker, Accodamento asincrono, Routing intermedio e Pattern di Content Enricher)