BPEL: Composizione del servizio per SOA

BPEL (Business Process Execution Language) è diventata una delle tecnologie più importanti della SOA (architettura orientata ai servizi) e consente una composizione facile e flessibile dei servizi nei processi aziendali. BPEL è particolarmente importante perché introduce un nuovo concetto nello sviluppo di applicazioni: la programmazione in generale. Questo concetto ci consente di sviluppare processi rapidamente definendo l'ordine in cui verranno richiamati i servizi. In questo modo, le applicazioni (e i sistemi informativi) diventano più flessibili e possono adattarsi meglio ai cambiamenti nei processi aziendali.

I processi aziendali sono generalmente di natura dinamica. Le aziende devono migliorare e modificare, agire in modo agile, ottimizzare e adattare i processi per migliorare la reattività dell'intera azienda. Ogni cambiamento e miglioramento in un processo aziendale deve riflettersi nelle applicazioni che forniscono supporto per loro. Sebbene questo requisito possa non sembrare molto difficile da soddisfare, la situazione del mondo reale ci mostra un'immagine diversa. Cambiare e modificare le applicazioni è spesso un lavoro difficile, che richiede tempo. Pertanto, le applicazioni non possono reagire istantaneamente ai cambiamenti nei processi aziendali, ma richiedono del tempo per implementare, testare e distribuire le modifiche.

Rendere i sistemi informativi più flessibili e adattabili ai cambiamenti e meglio allineati con i processi aziendali è la principale promessa della SOA. In questo articolo, mostro perché BPEL è così importante e dimostro come sviluppare un processo BPEL.

Approccio orientato al servizio

L'approccio SOA per un'automazione efficiente dei processi aziendali richiede:

  • Modo standardizzato per esporre e accedere alla funzionalità delle applicazioni come servizi
  • Infrastruttura bus aziendale per la comunicazione e la gestione dei servizi, tra cui intercettazione, instradamento, trasformazione dei messaggi, ecc.
  • Linguaggio specializzato per la composizione delle funzionalità esposte delle applicazioni nei processi aziendali

Il primo requisito è soddisfatto dalla più recente architettura distribuita: i servizi Web. Il secondo requisito è soddisfatto dall'ESB (enterprise service bus), che fornisce supporto per la gestione centralizzata, dichiarativa e ben coordinata dei servizi e delle loro comunicazioni. Il terzo requisito, la composizione dei servizi in processi, è soddisfatto da BPEL, il linguaggio specializzato comunemente accettato per la definizione e l'esecuzione dei processi aziendali.

Un processo aziendale, come visto da BPEL, è una raccolta di richiami di servizi coordinati e attività correlate che producono un risultato, all'interno di una singola organizzazione o tra più. Ad esempio, un processo aziendale per la pianificazione di viaggi di lavoro richiamerà diversi servizi. In uno scenario estremamente semplificato, il processo aziendale ci richiederà di specificare il nome del dipendente, la destinazione, le date e altri dettagli di viaggio. Quindi il processo richiamerà un servizio Web per controllare lo stato del dipendente. In base allo stato del dipendente, selezionerà la classe di viaggio appropriata. Quindi richiamerà i servizi Web di diverse compagnie aeree (come American Airlines, Delta Airlines, ecc.) Per controllare il prezzo del biglietto aereo e acquistare quello con il prezzo più basso.

Per i client, il processo BPEL esporrà la sua funzionalità allo stesso modo di qualsiasi altro servizio Web. Dal punto di vista del client, apparirà esattamente come qualsiasi altro servizio Web. Questo è importante e utile, poiché ci consente di comporre servizi in processi semplici, processi semplici in processi più complessi e così via. Ciò significa anche che ogni processo BPEL verrà descritto con una descrizione WSDL (Web Services Description Language).

Concetti principali

BPEL è un linguaggio basato su XML. Un processo BPEL è costituito da passaggi. Ogni passaggio è chiamato attività. BPEL supporta attività primitive e di struttura. Le attività primitive rappresentano costrutti di base e vengono utilizzate per attività comuni, come quelle elencate di seguito:

  • Invocare servizi Web, utilizzando
  • Aspettando la richiesta, utilizzando
  • Manipolazione di variabili di dati, utilizzo di
  • Indicare difetti ed eccezioni, utilizzo , ecc.

Possiamo quindi combinare queste attività in algoritmi più complessi che specificano i passaggi di un processo aziendale. Per combinare attività primitive, BPEL supporta diverse attività di struttura. I più importanti sono:

  • Sequence ( ) per definire un insieme di attività che verranno invocate in una sequenza ordinata
  • Flow ( ) per definire un insieme di attività che verranno invocate in parallelo
  • Case-switch costrutto ( ) per l'implementazione dei rami
  • While ( ) per definire i loop, ecc.

Come vedremo, BPEL non è così diverso dai linguaggi di programmazione, come Java. Ma vedremo che BPEL differisce da Java e supporta le caratteristiche dei processi aziendali. BPEL fornisce anche gestori di errori e compensazione, gestori di eventi e set di correlazione. Fornisce mezzi per esprimere flussi paralleli complessi. Inoltre, rende relativamente semplice chiamare operazioni asincrone e attendere i callback.

I processi BPEL richiedono un ambiente di runtime, un server BPEL, che ci offre un buon controllo sulla loro esecuzione. In genere, i server BPEL forniscono il controllo sulle istanze di processo in esecuzione e su quelle terminate. Supportano processi di lunga durata e possono disidratare lo stato del processo per risparmiare risorse. Alcuni server forniscono il controllo sulle attività del processo e ne consentono il monitoraggio. Infine, utilizzando un server BPEL, tutti i nostri processi vengono distribuiti centralmente, il che semplifica la manutenzione. Tutto ciò rende il server BPEL l'ambiente preferito per l'esecuzione e la gestione dei processi.

La scelta del server BPEL giusto può essere piuttosto difficile, tuttavia, poiché ci sono diverse scelte. Alcuni dei server BPEL più popolari basati su Java EE (il nuovo nome di Sun per J2EE) includono Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration e AquaLogic. Sono inoltre disponibili almeno quattro server BPEL open source: ActiveBPEL Engine, FiveSight PXE, bexee e Apache Agila.

Processo di esempio

Vediamo ora un esempio di processo BPEL per i viaggi d'affari che abbiamo descritto sopra. Svilupperemo un processo asincrono che utilizzerà una chiamata sincrona per controllare lo stato del viaggio dei dipendenti e due chiamate asincrone per acquisire i prezzi dei biglietti aerei. La figura seguente mostra la struttura complessiva del nostro processo. A sinistra, vediamo il client che invoca il processo. Il processo chiama prima il servizio Web sullo stato del viaggio del dipendente. Quindi richiama i servizi Web di entrambe le compagnie aeree contemporaneamente e in modo asincrono. Ciò significa che il processo dovrà implementare l'operazione di callback (e un tipo di porta), attraverso la quale le compagnie aeree restituiranno la conferma del biglietto aereo. Infine, il processo restituisce al cliente la migliore offerta di biglietti aerei. In questo esempio, per mantenere la semplicità, non implementeremo alcuna gestione dei guasti,che è cruciale negli scenari del mondo reale.

Scriviamo ora il codice BPEL. Iniziamo con la dichiarazione del processo, l'elemento radice, dove definiamo il nome del processo e gli spazi dei nomi:

Successivamente, dobbiamo definire i collegamenti dei partner. I collegamenti dei partner definiscono diverse parti che interagiscono con il processo BPEL. Ciò include tutti i servizi Web che verranno richiamati e il client del processo. Ciascun collegamento partner specifica fino a due attributi: myRoleche indica il ruolo del processo aziendale stesso e partnerRoleche indica il ruolo del partner. Nel nostro esempio, definiamo quattro link partner:

Per memorizzare i messaggi e riformattarli e trasformarli, abbiamo bisogno di variabili. Di solito usiamo una variabile per ogni messaggio inviato ai servizi Web e ricevuto da questi. Nel nostro esempio, avremo bisogno di alcune variabili. Per ogni variabile, dobbiamo specificare il tipo. Possiamo utilizzare un tipo di messaggio WSDL, un tipo semplice di XML Schema o un elemento XML Schema. Nel nostro esempio, utilizziamo i tipi di messaggio WSDL per tutte le variabili:

Ora siamo pronti per scrivere il corpo principale del processo. Contiene solo un'attività di primo livello. Di solito, questa è una che ci permette di definire diverse attività che verranno eseguite in sequenza. All'interno della sequenza, specifichiamo prima il messaggio di input che avvia il processo aziendale. Lo facciamo con il costrutto, che attende il messaggio corrispondente. Nel nostro caso, questo è il TravelRequestmessaggio. All'interno del costrutto, non specifichiamo direttamente il messaggio. Piuttosto, specifichiamo il collegamento del partner, il tipo di porta, il nome dell'operazione e, facoltativamente, la variabile che contiene il messaggio ricevuto per le operazioni successive. Colleghiamo la ricezione del messaggio con il partner client e attendiamo che l' TravelApprovaloperazione venga richiamata sul tipo di porta TravelApprovalPT. Memorizziamo il messaggio ricevuto nel fileTravelRequest variabile:

Successivamente, dobbiamo richiamare il servizio Web Employee Travel Status. Prima di questo, dobbiamo preparare l'input per questo servizio Web. Possiamo costruire un messaggio di questo tipo copiando la parte dipendente del messaggio che il cliente ha inviato. Ora possiamo richiamare il servizio Web Employee Travel Status. Facciamo un'invocazione sincrona, per la quale utilizziamo l' attività. Usiamo il employeeTravelStatuslink partner e invociamo l' EmployeeTravelStatusoperazione sul EmployeeTravelStatusPTtipo di porta. Abbiamo preparato il messaggio di input nella EmployeeTravelStatusRequestvariabile. Poiché si tratta di una chiamata sincrona, la chiamata attende la risposta e la memorizza nella EmployeeTravelStatusResponsevariabile:

Il passaggio successivo consiste nel richiamare entrambi i servizi Web della compagnia aerea. Di nuovo, prepariamo prima il messaggio di input richiesto (che è uguale per entrambi i servizi Web). Faremo invocazioni asincrone simultanee. Per esprimere la concorrenza, BPEL fornisce l' attività. La chiamata a ciascun servizio Web consisterà in due passaggi:

  1. L' attività viene utilizzata per la chiamata asincrona
  2. L' attività viene utilizzata per attendere la richiamata

Usiamo per raggruppare entrambe le attività. Le due chiamate differiscono solo nel nome del collegamento partner. Usiamo AmericanAirlinesper uno e DeltaAirlinesper l'altro:

...