L'orchestrazione è una responsabilità ESB?

Question

È un bus di servizio aziendale (uno strumento che funge da mediatore, broker di messaggi, attivatore di servizi, ottimizzatore di trasformazione dello schema, provider di ubicazione trasparente, aggregatore di servizi, bilanciamento del carico, monitor e tutto quella roba) responsabile di orchestrare i servizi ?

Che ne dici di inserire un processo aziendale automatizzato con più di mille passaggi e dozzine di invocazioni di servizi all'interno del tuo bus di servizio aziendale?

Lo faresti o useresti uno specialista nell'orchestrazione come un motore BPEL?

Per favore dammi la tua opinione.

Answer 1

Sì e no. Esiste una linea sottile e talvolta indistinguibile tra orchestrazione e aumento di aggregazione / servizio.

In generale, se hai processi di business complessi o di lunga durata (processo è la parola chiave, anche se sto per evitare di definirlo), è più adatto a BPEL.

Compiti semplici, come l'aggregazione dei risultati di tre chiamate di servizio, potrebbero e dovrebbero spesso essere eseguiti in un livello ESB.

Non vale la pena perdere troppo sonno, però

Disclaimer: sono un consulente IBM ESB, anche se non sto scrivendo questo a titolo ufficiale.

Answer 2

No, la responsabilità di un ESB non è l'orchestrazione dei servizi (di per sé). L'ESB fornisce uno strato di astrazione a "livello di infrastruttura software".

Ciò significa che un ESB è un "unico porto logico astratto astratto per la connettività" con qualsiasi servizio pubblicato sul bus.

L'ESB, essendo astratto, significa che i consumatori di servizi sull'autobus non devono "conoscere" dettagli di implementazione del servizio ed è possibile esporre "servizi rivolti internamente" con un singolo modello di documento. L'ESB fornisce servizi di basso livello (come la traduzione del protocollo e la trasformazione dei messaggi), in modo che i servizi interni possano comunicare in modo semplificato.

Ciò implica un po 'di orchestrazione: l'ESB fornisce l'orchestrazione dei servizi di basso livello sopra menzionati (ad es. quando il servizio X viene chiamato tramite IIOP, tradurlo in SOAP con allegati. Quindi trasformare la richiesta da qualsiasi dato serializzato in un payload XML).

L'orchestrazione che in genere si eviterebbe in un ESB è: per elaborare questa vendita (assicurativa), dobbiamo prima convalidare le informazioni fornite dall'acquirente, quindi dobbiamo sottoscrivere il rischio di assicurazione e infine calcolare il premio che deve essere pagato per l'assicurazione, dopodiché dobbiamo & # 8230; ecc.

I passaggi sopra descritti sono chiaramente un processo aziendale (che potrebbe anche essere interrotto & # 8230; ad esempio se non è possibile sottoscrivere automaticamente, un sottoscrittore umano deve valutare ulteriormente il rischio).

I servizi alle imprese (ad es. convalida, sottoscrizione, calcolo dei premi) che compongono un processo aziendale (ad es. vendita di assicurazioni), che è ciò che viene generalmente chiamato orchestrazione, sono più adatti a verificarsi in un motore dei processi aziendali e definiti utilizzando un linguaggio di modellizzazione dei processi aziendali formalizzato (come BPEL).

Anche un'ipotesi sui molti passaggi del processo: nell'esempio sopra, la convalida è un servizio (ovviamente integrato). Le stesse regole di validazione sono interne a quel servizio. Per regole aziendali complesse (cioè non processi aziendali), potrebbe essere necessario l'uso di un motore delle regole aziendali.

Answer 3

La mia breve risposta rapida è NO, non la sua responsabilità.

Preferirei lasciarlo al BPEL o ad una suite BPM.

Mhh non so cos'altro aggiungere :) ... Buona fortuna?

Answer 4

Ora la mia visione.

Per quanto riguarda tutto il lavoro che un ESB deve svolgere, inserire l'orchestrazione dei servizi all'interno del principale elemento infrastrutturale della SOA non è una buona idea.

Aggregato, ok! Ma mantenere occupato il tuo canale di comunicazione con la logica aziendale provocherà sicuramente un impatto terribile sulla capacità di fornire altre funzionalità.

Dopotutto, la maggior parte degli ESB come BEA Aqualogic Service ha un supporto limitato per l'orchestrazione inclusa la mancanza di capacità stateful e attività come attendere (un timer) o selezionare (attendere che alcuni input si spostino sul processo), dividere / unire le funzionalità (già aggiunte su ALSB 3.0) e così via.

Assolutamente no. Basta usare strumenti come un motore BPEL o uno come l'integrazione di Weblogic.

Grazie.

Answer 5

Ogni volta che si hanno due o più servizi che interagiscono, utilizzare l'orchestrator dei servizi, ovvero per i servizi di controllo della composizione e dei processi. Se hai esb esporre questo servizio di composizione su esb. Ora se devi comporre un nuovo servizio che include questo servizio di composizione usa l'orchestrator ed esponi nuovamente su esb. Usa esb come meccanismo di erogazione del servizio e broker e proxy di servizi web. Nel comporre un orchestratore di servizi userà esb per raggiungere servizi di interazione. Se questi servizi interagenti utilizzano schemi xml incompatibili esb può trasformarli / mapparli in schemi comuni in runtime e instradare richieste di servizi in base al contenuto, ad es. namespace.

Answer 6

Sì, l'orchestrazione è una responsabilità, nella maggior parte dei casi, dell'ESB. Oppure, in alternativa, se tracciate una linea tra l'infrazione ESB e l'infrazione dell'orchestrazione, lo state facendo a livello fisico per motivi di prestazione, non per attribuzione logica di responsabilità.

Hai 2 scelte - quando, ad esempio, un sistema HR riceve un nuovo dipendente - dove collochi la logica aziendale che dice " il dipartimento di conformità dovrà prima approvare e verificare, e poi se va bene, il Il dipartimento risorse umane dovrà finalizzare il noleggio, quindi il reparto contabilità avrà bisogno di una nuova voce e quindi il sistema di gestione stipendi dovrà essere aggiornato e, in caso contrario, dovremo inviare un'e-mail a risorse umane " ;? Se tutti i processi aziendali sono considerati "di proprietà" dal reparto / applicazione di avvio, il sistema complessivo che è l'impresa diventa complesso, con sistemi di orchestrazione disparati.

La seconda scelta è centralizzare l'orchestrazione, rendendola essenzialmente un partner logico della piattaforma di messaggistica. Se scegli di vederli come artefatti separati, dipende da te, ma è ugualmente valido descriverli entrambi come ESB.

Answer 7

Un bus di servizio aziendale non dovrebbe mai essere responsabile dell'orchestrazione dei servizi.

L'orchestrazione implica un minimo di "intelligenti", in particolare la capacità di compensare le transazioni fallite. Gli strumenti del bus di servizio spesso affermano che offrono "quotazioni try-catch" o qualcosa del genere, ma la capacità di eseguire la compilazione con ambito è il segno distintivo di uno strumento di orchestrazione adeguato. Inoltre, la capacità di aspettare, conoscere il proprio stato o mantenere le cose in sospeso è un altro indicatore del fatto che hai a che fare con un orchestratore e non con un autobus.

Parlando di oltre 1000 passaggi oltre a dozzine di servizi, considera gli if-then nel processo. Se tutte le istruzioni if-then nei tuoi 1000 passi parlano solo di routing senza modifiche ai payload, allora sei ancora in "routing". e quindi ancora in ESB. Ma se c'è anche un nidificato if-then e comincio a cercare diversi strumenti. Inoltre, if-thens che sembrano routing possono avere un impatto molto rapido sulla logica aziendale. Una volta che la logica di business inizia a comparire, allora è meglio un linguaggio migliore come BPEL o BPMN.

L'esempio di un direttore d'orchestra viene spesso fornito per descrivere come funziona l'orchestrazione, un individuo centrale che dirige i musicisti secondo una partitura. Spesso ciò che viene lasciato è l'idea che il direttore non stia solo dirigendo, ma anche ascoltando, e se qualcosa va storto può compensare in modo affidabile e ripetibile.

Ad esempio, immagina che il nostro primo direttore vada a portare il giocatore di tuba, ma il giocatore di tuba ha deciso di fare qualcos'altro. Un semplice orchestratore in stile flipper " introdurrà la sezione tuba, sapendo benissimo che non c'è, e quindi aspetterà che il pubblico si lamenti più tardi. Un conduttore molto esperto vedrebbe sparire la tuba e avrebbe immediatamente sollevato le corna di baritono più profonde per compensare.