Linea guida: Realizzazione del servizio - I servizi BPEL in un'applicazione SOA
Questa linea guida descrive un'applicazione creata utilizzando BPEL basata sulla coreografia in uno stile SOA.
Relazioni
Descrizione principale

Introduzione

Questa pagina descrive un'applicazione creata utilizzando una coreografia basata su BPEL in uno stile SOA. Le lezioni apprese durante sia la fase di progettazione che di sviluppo di questo progetto, forniscono un'idea generale a chi considera l'utilizzo della coreografia basata su BPEL in una SOA. L'approccio di progettazione viene qui valutato utilizzando un confronto tra Pros e Cons che tiene in considerazione i requisiti del business e gli elementi esistenti dell'applicazione. Questa pagina contiene i suggerimenti per la progettazione e identifica le caratteristiche che suggeriscono l'utilizzo di un approccio BPEL guidato.

Lezioni apprese

  1. La scelta della giusta segmentazione di logica del business tra il flusso di lavoro ed i servizi del partner talvolta è rischioso e sempre importante.

    La logica del business è separata tra la coreografia basata sul flusso di lavoro ed i servizi partner. Infine, è necessario che i servizi partner siano responsabili di una logica intensa o complessa in modo calcolato; mentre la coreografia contiene la logica che viene anticipata per eseguire delle modifiche in risposta alla modifica dei requisiti del business.

    Dato che questa non sarà sempre una separazione pulita, una utile strategia per rimediare a ciò è quella di progettare l'applicazione in modo che cresca modificando il flusso di lavoro ed aggiungendo nuovi servizi partner piuttosto che modificando i servizi partner esistenti.

    Questo è fondamentalmente un approccio interattivo. I primi prototipi probabilmente richiederanno la riproduzione dei servizi partner per raggiungere una progettazione che è possibile si sviluppi aggiungendo nuovi servizi partner.

    Naturalmente, in tutti i casi è necessario conservare il codice non necessario o mai modificabile al di fuori del flusso di lavoro

  2. Utilizzo delle capacità univoche di BPEL

    L'abilità di BPEL di orchestrare i servizi partner che espongono una varietà di binding diversi.

    E' bene fare attenzione a non creare dipendenze sulle caratteristiche di un'implementazione di un partner particolare o di un binding del servizio. L'esecuzione di queste operazioni potrebbe complicare o limitare le modifiche alla coreografia o all'applicazione generale.

    Considerare il conservare i risultati di livello intermedio nelle variabili BPEL come una strategia per migliorare le prestazioni

  3. Dove possibile progettare i servizi del partner in modalità senza stato con operazioni idempotenti.

    Per quello che è lo scopo di questa discussione, idempotente significa che è possibile richiamare un servizio con gli stessi dati di input più volte con la prospettiva che la risposta sarà corretta per ciascuna chiamata. Questa caratteristica può fornire una semplificazione significativa sia per il chiamante che per il servizio poiché semplifica drammaticamente l'iterazione.Le operazioni di recupero di un errore, di riavvio dopo un errore e la scalabilità tramite cluster vengono tutte semplificate. Per il chiamante, il recupero di un errore dalla rete ed i problemi del server e del client vengono semplificati. L'idempotenza è un indicatore chiave per una corrispondenza potenzialmente buona per la coreografia BPEL dei servizi del partner.

    Naturalmente, se vengono richieste iterazioni più complesse, i protocolli dei servizi web includeranno le capacità di compensazione che è possibile impiegare in questi casi. Tutto rimane uguale, se è possibile evitare tali requisiti nella progettazione dell'applicazione generale, il risultato sarà più semplice da conservare e verificare.

Caso pratico

Questo caso pratico descrive un progetto IBM per aggiornare la tecnologia sulle informazioni utilizzata dal businessServicePac®. L'obiettivo di questo progetto è stato quello di risolvere alcuni punti e posizioni dolenti del businessServicePac® per una continuata espansione sia in volume che nelle capacità.

Come molti business di successo, ServicePac® IBM è passato attraverso una sequenza di transizioni incrementali, cominciando dalla combinazione di molti programmi di garanzia distinti in tre business organizzati per settore geografico. In un secondo momento, le operazioni distinte geograficamente sono state combinate in un'operazione singola in tutto il mondo. Negli anni, il business di ServicePac® ha aggiunto continuamente nuove offerte come i servizi di installazione e le offerte per supportare il nuovo hardware IBM. Sebbene il business di ServicePac® sia esso stesso un'operazione mondiale, i prodotti ServicePacs®, sono venduti da varie linee di business IBM e di partner IBM. Ogni organizzazione di vendita dispone di propri sistemi di voci di ordine tagliati per il proprio tipo particolare di business (e non per ServicePacs®). Tali sistemi rappresentano un autentica identità di diverse tecnologie creato in tempi diversi da team diversi.

E' necessario che i sistemi di gestione ordini che gestiscono ServicePacs® effettuino le convalide al momento della gestione dell'ordine in base ai requisiti sviluppati dal business ServicePac®. La convalida di ServicePac può essere complessa. I ServicePac® vengono offerti in più di 100 paesi e le offerte non sono le stesse dovunque. Le offerte ServicePac® variano secondo il modello di prodotto, il paese in cui viene distribuito, il canale delle vendite, il sistema di gestione ordini e le informazioni specifiche dell'utente quali la proprietà attuale dei ServicePac®.

Tradizionalmente, la convalida degli ordini di ServicePac® è stata eseguita all'interno del sistema di gestione ordini, implementando solo quei requisiti di convalida necessari per i canali delle vendite supportati dal sistema. Poiché il business di ServicePac® è cresciuto, il costo della comunicazione dei requisiti di convalida, di coordinazione dello sviluppo, del test e della distribuzione è diventato proibitivo. Inoltre, stabilire una convalida degli ordini appropriata all'interno dei sistemi di ordine ha aumentato in modo significativo il periodo di mercato per le nuove offerte.

L'immagine illustra un approccio orientato al servizio della convalida ordini.

Figura 1 - approccio orientato ai servizi alla convalida ordini di ServicePac®. L'approccio prevede di rendere disponibile un servizio singolo a tutti i sistemi di gestione ordini che eseguono i ServicePac®, piuttosto che inserire una logica di convalida specifica in ciascun sistema di ordine.

Un approccio orientato al servizio per la convalida

Inizialmente è stato evidente che era necessario che la convalida fosse una responsabilità del business ServicePac® e non di ogni sistema di vendite singolo attraverso il quale i ServicePac® vengono ordinati. Le due scelte prese in considerazione erano quella di distribuire il codice che incapsulava i requisiti di convalida ordini in tutti i sistemi di ordine oppure fornire un servizio di convalida ordini centralizzato. Evitare i problemi di gestione associati all'approccio del codice distribuito, è stato il motore maggiore per la scelta dell'approccio del servizio centralizzato.

Il maggior vantaggio singolo dell'esporre la convalida ordini come un servizio per i sistemi di gestione ordini è quello che non è più necessario che i sistemi di gestione ordini implementino, verifichino o eseguano localmente la propria logica di convalida ordini di ServicePac®. Forse la preoccupazione principale (o la paura) viene dai molti proprietari dei sistemi di gestione ordini che hanno adesso una nuova dipendenza di runtime su un sistema esterno eseguita da un'altra organizzazione. Come si apprenderà di seguito, il vantaggio netto del fornire la logica di convalida come un servizio in questo caso supera le preoccupazioni.

Segue un breve riepilogo degli obiettivi strutturali per il progetto:

  1. Progettazione dell'interfaccia: E' necessario che l'interfaccia di convalida sia progettata per gestire con grazia l'evoluzione anticipata del business (ad es. le nuove offerte di prodotti non dovrebbero richiedere in generale alcuna modifica dell'interfaccia)

  2. Indipendenza del protocollo di messaggistica: E' necessario che il servizio di convalida sia accessibile indipendentemente dalla piattaforma di chiamata, dal modello di programmazione, dal livello di trasporto della rete o dalle scelte di hardware.

  3. Flessibilità del business: La logica di convalida è stata implementata per rendere le modifiche anticipate del business sicure, non costose e veloci senza sacrificare le prestazioni, l'affidabilità o compromettere le regole di progettazione fondamentali.

  4. Scalabilità: Scalare a velocità di trasmissione maggiore non dovrebbe coinvolgere la riprogrammazione o test funzionali significativi.

Progettazione dell'interfaccia

Collaborando con il proprietario del business e con gli architetti del business di tutte le parti che gestiscono la nomenclatura del prodotto, è stata sviluppata una tassonomia ben documentata conforme a se stessa per i prodotti correnti e per quelli anticipati. Basandosi sulla tassonomia, è stato sviluppato un modello di dati XML in un linguaggio schema XML che esprime tutti i tipi di prodotto necessari insieme ai relativi attributi. Durante l'offerta dei nuovi prodotti la tassonomia potrebbe cambiare - insieme a modifiche potenziali dello schema, tuttavia, si prevede che il formato di messaggio reale rimanga invariato finché le nuove offerte non ricadano nell'ambito definito della tassonomia.

Questo approccio fornisce al business la flessibilità desiderata per introdurre nuove offerte rapidamente e in modo economico. Naturalmente, non coprirà tutti i casi possibili. Ad esempio, se in una nuova offerta di prodotto esiste un presupposto che non è stato anticipato nelle definizioni esistenti del messaggio verranno inserite le nuove definizioni del messaggio.

Nell'elenco 1 viene visualizzato un payload semplice del messaggio di richiesta di convalida che include un ordine singolo per un singolo ServicePac® per un computer di proprietà dell'utente identificato da il numero di parte ed il numero seriale relativi. Il formato del messaggio supporta più ordini per più ServicePac® che è possibile associare sia con l'hardware esistente che con quello nuovo. In alcuni casi, i messaggi potrebbero avere migliaia di elementi nidificati.

Indipendenza del protocollo di messaggistica

Uno dei maggiori vantaggi dell'utilizzo di BPEL è che le relazioni di messaggistica tra i servizi vengono descritte in modo astratto in WSDL che fornisce un grado di indipendenza del protocollo di messaggistica. Per trarre il massimo del vantaggio da questa funzione è necessario evitare accuratamente la creazione di implementazioni che dipendano da caratteristiche specifiche del protocollo di messaggistica utilizzato durante la fase di sviluppo. Ad esempio, se i binding EJB vengono utilizzati durante lo sviluppo, lo stile della programmazione potrebbe risultare in scambi di brevi messaggi veloci (ad es. scambio frequente di messaggi brevi). Se in un secondo momento il binding viene cambiato in JMS o SOAP su HTTP probabilmente si verificherà un serio collo di bottiglia delle prestazioni risultante da un sovraccarico più grande per messaggio per questi protocolli. In questo caso, è possibile ridurre l'impatto dello spostamento tra i binding seguendo uno stile di programmazione in cui gli scambi di messaggi sono a grande granularità (ad es. scambi relativamente infrequenti di grandi corpi di messaggio)così che il sovraccarico di creazione e ricevuta di messaggi possa essere ammortizzato su più dati.


<?xml version="1.0" encoding="UTF-8"?>
 <spkOrderDataList>
  <header>
   <orderReference>1040-5124-001</orderReference>
   <orderDate>2004-08-15</orderDate>
   <orderingSystem>WEB</orderingSystem>
   <country>US</country>
   <distributionChannel>A</distributionChannel>
   <headerReturnCode/>
  </header>
 <spkSegmentList>
   <orderItemReference>102</orderItemReference>
   <spkPartNumber>69P9921</spkPartNumber>
   <spkType>WMAINTOPT</spkType>
   <spkQuantity>1</spkQuantity>
   <hardwareQuantity>1</hardwareQuantity>
   <spkReturnCode/>
   <hardwareSegment>
    <serialNumber>77X9182</serialNumber>
    <hardwareIdentifier>8676M2X</hardwareIdentifier>
    <hardwareReturnCode/>
   </hardwareSegment>
 </spkSegmentList>
 </spkOrderDataList>
</ServicePacData:validationRequest>

Elenco 1 - Esempio di un messaggio semplice ricevuto dal servizio di convalida composto di un singolo ordine per un singolo ServicePac® che verrà applicato ad un computer esistente identificato da il proprio numero di parte e numero seriale. Il servizio di convalida restituisce il messaggio ricevuto annotato con i codici di verifica o con i codici di errore. Il componente di chiamata è in grado di fornire i propri numeri di riferimento per consentire di correlare la richiesta con la risposta.

Un'altra considerazione per l'indipendenza del protocollo è lo stile di messaggistica. In questo progetto le necessità future di messaggistica asincrona sono state indirizzate dalla creazione di definizioni di messaggi di convalida con un campo (attualmente inesplorato) per correlare i messaggi di richiesta e di risposta, anche se tutto l'utilizzo corrente è asincrono e quindi non è necessaria alcuna correlazione. L'indirizzamento di tali obiettivi copre sia la progettazione del messaggio che la progettazione dell'applicazione.

Flessibilità del business

Fondamentalmente, il servizio di convalida di ServicePac® accetta un ordine e restituisce le informazioni che indicano se l'ordine è valido o meno e se non è valido ne indicano la ragione. L'obiettivo è di ridurre al minimo la riprogettazione, la riesecuzione di test e l'impatto sulle prestazioni quando sono necessarie modifiche in risposta ai nuovi requisiti del business. Chiaramente, è utile avere un'idea dei nuovi requisiti quando si progetta l'implementazione iniziale.

Dettagli iniziali di implementazione:

il servizio di convalida estrae i dettagli dell'ordine di ServicePac® che consistono in: tipi di ServicePac®, l'hardware destinato ad essere applicato, la posizione di distribuzione di ServicePac® (paese), il canale delle vendite ed i dati dell'utente. Quindi la logica del business verifica le informazioni sull'ordine da una raccolta di istruzioni dichiarative fornite dal business ServicePac®. L'insieme di test che è necessario applicare ad ogni ordine fornito dipende dai dettagli dell'ordine.Alcuni test richiedono l'accesso a ulteriori dati disponibili solo da sistemi remoti.

Vi sono tre tipi di dati richiesti per convalidare un ordine: i dati di riferimenti di proprietà di questa applicazione, i dati di riferimento memorizzati nella cache di proprietà di altri sistemi ed i dati in tempo reale che è necessario ottenere da altri sistemi ogni volta che viene convalidato un ordine.

Ai dati di riferimento di proprietà di quest'applicazione di accede attraverso un servizio partner creato come parte di questa applicazione. Questo servizio è disponibile anche per altre applicazione che è necessario accedano ai dati di riferimento di proprietà di questa applicazione.

I dati di riferimento di proprietà di altre applicazioni vengono forniti accedendo ad un servizio partner creato come parte di questa applicazione. Dove possibile il servizio memorizza nella cache i dati ottenuti dalle altre applicazioni per ridurre al minimo il numero degli accessi alla rete. Inserendo la strategia di memorizzazione nella cache all'interno del servizio partner, è possibile modificarla come necessario nel tempo senza richiedere modifiche al resto dell'applicazione

Solo i risultati dei dati ed intermedi che è necessario memorizzare durante il ciclo di vita di una richiesta di convalida, vengono memorizzati nelle variabili BPEL. L'utilizzo delle variabili BPEL elimina l'overhead di accessi evitabili a servizi partner e perciò potrebbe migliorare le prestazioni generali.

L'immagine illustra una vista topologica dell'implementazione guidata del flusso di lavoro della logica del business.

Figura 2 - vista topologica dell'implementazione guidata del flusso di lavoro della logica del business che sceglie quali tra i test intensivi di calcolo o intensivi di dati è necessario eseguire per convalidare un ordine fornito. La stessa interfaccia del servizio viene utilizzata da tutti i sistemi di gestione ordini che devono convalidare degli ordini.

A questo punto si passa ad indagare la natura dei requisiti nuovi che è possibile anticipare dalle discussioni con il business ed a guardare alle tendenze storiche.

Mentre il business ServicePac® si espande, vengono creati nuovi test business per la convalida di ServicePac® tuttavia, non si prevede che verranno modificati i test esistenti. La convalida di prodotti nuovi richiede la valutazione di un nuovo raggruppamento di test esistenti e possibilmente nuovi.

Questo insieme di requisiti rappresenta una buona corrispondenza per un sistema guidato dal flusso di lavoro in cui il flusso di lavoro viene utilizzato per unire insiemi di test richiesti da ciascun tipo di prodotto. E' allora possibile sviluppare gli aspetti di questi test intensivi di calcolo o di dati in una tecnologia meno flessibile ma più efficiente e su cui è stati eseguito il rendering, come servizi partner disponibili nel motore del flusso di lavoro centrale come illustrato nella Figura 2.

Quando si aggiungono offerte business nuove, il sistema di convalida e lo stesso flusso di lavoro vengono modificati per accedere ai servizi partner esistenti (e possibilmente ai nuovi servizi partner che dovevano supportare l'offerta nuova). Presumendo che i servizi partner siano stati segmentati appropriatamente in esterno, questa architettura esibisce una modalità ulteriore molto interessante in cui i requisiti nuovi non richiederanno di eseguire nuovi test o nuove codifiche della funzione precedentemente implementata.

Scalabilità

Poiché l'applicazione BPEL viene distribuita in cima ad una serie di middleware maturi che offrono il clustering come opzione di configurazione, spostare il progetto di convalida ServicePac® a piè di pagina dove è possibile scalare facilmente aggiungendo nuovo hardware come necessario, è stato facile. Naturalmente, l'architettura generale di chiamata dei servizi partner da un motore del flusso di lavoro si adatta esattamente al modello di clustering.

Come punto di progettazione, questo servizio è idempotente dato che le chiamate a questo servizio non hanno effetti da parte di un chiamante individuabile. Perciò, non è necessario che un utente del servizio intraprenda alcuna azione di recupero se una chiamata del servizio restituisce un errore o non riesce a completare. In verità, l'utente del servizio può ritentare in modo sicuro una chiamata in qualsiasi momento. Il fatto che i servizi partner siano spesso idempotenti in modo significativo semplifica i fattori associati allo scalare del processo utilizzando il clustering poiché il recupero degli errori è relativamente semplice e il recupero e il riaviio dopo un errore è facile. Inoltre, non c'è necessità di alcuna "affinità del chiamante" dato che ogni interazione è atomica e non esiste alcun chiamante specifico che esegue una memorizzazione nella cache associato all'elaborazione di una richiesta.

Applicazione del flusso di lavoro e di BPEL

BPEL4WS (Business Process Execution Language for Web Services) è un modello di linguaggio e di programmazione progettato specificamente per l'esecuzione di flussi di lavoro basati sulla logica del business che coinvolge la coreografia dei servizi web. BPEL è uno standard aperto da ciò molte implementazioni dei fornitori sia dei tool che dei runtime di modifica.

L'abilità di descrivere il processo del business ServicePac® attraverso un diagramma di processo schematico e quindi di rappresentare la logica di implementazione utilizzando i costrutti BPEL4WS basati sugli standard ha fornito proprio la combinazione giusta di flessibilità ed isolamento per implementare la logica flessibile del business ServicePac®.

Per questo progetto è stato scelto WSADIE (WebSphere Application Developer Integration Edition) IBM come ambiente di modifica. Gli artefatti di codice sviluppati sono stati destinati ad essere eseguiti sul runtime di WBISF (WebSphere® Business Integration Server Foundation) v5.1.1 IBM che fornisce un motore di esecuzione del processo business per eseguire successivamente il flusso di lavoro. I dati sono ospitati su un server DB2 (v8.1).

Sono stati implementati test singoli necessari per la convalida di ServicePac® come EJB (Enterprise Java Beans), in modo specifico SSB (Stateless Session Beans), in esecuzione nel contenitore WAS (WebSphere® Application Server) EJB. Lo strumento WSADIE ha facilitati l'integrazione di questi EJB come servizi web attraverso la generazione automatica dei file WSDL. Come risultato, è possibile distribuire i test singoli all'interno dello stesso contenitore come il processo BPEL oppure in contenitori dedicati su altre istanze del server.

L'immagine illustra il flusso di lavoro come descritto da un editor grafico BPEL.

La figura 3 mostra una vista dell'editor grafico BPEL del flusso di lavoro di convalida. Il tool supporta i sottoprocessi e loop in errore per semplificare il lavoro sui dettagli delle parti singole del flusso di lavoro generale.

La figura 3 mostra il processo BPEL completamente espanso utilizzato per guidare i servizi di convalida ServicePac® come visualizzato nel tool di creazione e di modifica WSADIE BPEL.

Sono stati raggiunti miglioramenti significativi delle prestazioni quando è stata modificata un'implementazione iniziale di un processo del flusso di lavoro di convalida di ServicePac® per trarre vantaggio dall'utilizzo delle variabili BPEL per mantenere i risultati intermedi piuttosto che effettuare ulteriori chiamate al servizio partner. E' possibile visualizzare un esempio di questo approccio nella figura 3 dove l'elenco di test da eseguire su ciascun elemento di un ordine è memorizzato su una variabile BPEL.

Pros & Cons generale della progettazione

Pros
Cons
1. Aggiunta di nuove offerte più veloci e meno costose

2. L'aggiunta di nuovi sistemi di ordini è meno costosa

3. Convalida comprensiva coerente

4. L'utilizzo del servizio di convalida può essere suddiviso in fasi all'aggiornamento dei sistemi di ordine

5. E' solo necessario implementare e testare la nuova logica di convalida in un'unica postazione.

6. La logica di convalida è di proprietà del business ServicePac® e non viene distribuita attraverso più sistemi esterni.
1. Dipendenze organizzative incrociate del runtime ulteriori

2. Overhead delle prestazioni in forma di latenza di rete supplementare

3. Richiede una nuova progettazione dei sistemi esistenti

4. E' stato creato un nuovo componente centralizzato che potenzialmente è in grado di agire come punto singolo di errore per più applicazioni.

Nel caso dell'applicazione ServicePac® i vantaggi tracciati precedentemente sono stati trovati per fornire un valore significativo ed i cons erano tutti contenibili. Poiché ai chiamanti singoli è stato consentito di continuare la convalida privata fino a che non sia stato superato all'aggiornamento pianificato che copre molti obiettivi, il lavoro di programmazione ulteriore di impacchettamento dei dati per una chiamata di convalida è piccolo aumento che è possibile contenere nell'ambito generale del progetto dell'applicazione chiamante. Per i servizi in linea che dispongono dei requisiti del tempo di risposta che non possono essere soddisfatti dal servizio di convalida, la convalida preliminare in linea può essere eseguita dal chiamante - con un singolo accesso di convalida finale al servizio di convalida. Questa strategia conserva i fattori umani dell'applicazione di chiamata mentre allo stesso tempo preserva l'integrità del processo generale dell'ordinamento di ServicePac®. Per alcuni sistemi precedenti che non dispongono della capacità interna del protocollo dei servizi web, è stato creato un convertitore che accetti un protocollo privato e converta in una chiamata dei servizi web (è stato creato un documento specifico del fornitore nell'adattatore dei servizi web per uno dei chiamanti di questo progetto). La verifica e la dimostrazione della solidità del servizio ha eliminato i timori relativi ai colli di bottiglia delle prestazioni introdotto dal servizio di convalida. Utilizzando la tecnologia clustering, la velocità di trasmissione del servizio di convalida può essere aumentata molto rapidamente se ne sorge la necessità. Infine, la concentrazione della logica di convalida in una implementazione singola significa che il denaro speso per la distribuzione e la verifica di diverse implementazioni indipendenti può essere speso per la distribuzione e la verifica di una singola implementazione che si crede che semplificherà ogni problema associato disponendo di un singolo punto di errore per molti sistemi di gestione ordini disparati.

Infine, la capacità del business di prendere la proprietà vera dei requisiti di convalida e la relativa implementazione, di progettare rapidamente nuove offerte e di assicurare una convalida ordini corretta e coerente all'inizio del processo di ordine ha attivato il business a considerare l'indirizzamento di nuove opportunità in precedenza tecnicamente non realizzabili o proibitive per i costi.