BPEL e l'orchestrazione di servizi

Salve di nuovo :)

In questo post volevo parlare di un argomento che mi sta facendo penare non poco ultimamente :P
Intendo parlare di BPEL (Business Process Execution Language).
E' un linguaggio basato su file XML e la struttura del file non serve solo a descrivere i processi di business ma anche per eseguirli, quindi può essere considerato come un linguaggio di programmazione.

Può essere visto come un linguaggio interpretato e gli interpreti sono i motori BPEL. Questi motori non funzionano come un'interprete per un classico linguaggio di programmazione come potrebbe essere l'interprete Perl, ma piuttosto funzionano come dei container per processi di business.
Infatti per essere eseguito, un processo BPEL deve essere "deployato" su un motore, che ne controlla la validità e, se conforme alla specifica, lo rende "eseguibile" dai consumer.
Uso il termine "consumer" perchè BPEL è pensato principalmente per essere utilizzato in architetture SOA (Service Oriented Architecture) ed in esse l'utilizzatore di un servizio è chiamato consumer, che in linea di massima può essere considerato il client.
Personalmente ho fatto alcune prove utilizzando il motore Apache ODE (Orchestration Director Engine), il motore messo a disposizione da Intalio BPMS (Business Process Management System) ed il motore installabile in Virtuoso Universal Server tramite un'estensione.

BPEL è utilizzato in architetture Service-Oriented perché fondamentalmente un processo è visto come un servizio, o meglio, una volta fatto il deploy di un processo su un motore questo viene esposto verso l'esterno proprio come un web service che espone le proprie informazioni tramite WSDL.
Il processo, quindi, è un servizio a tutti gli effetti. Ai client che effettuano richieste il fatto che "dietro" la loro richiesta si nasconde un motore BPEL che esegue processi di business è assolutamente trasparente, essi vedono un servizio e nient'altro.

Cosa ha di diverso un processo BPEL, quindi, rispetto ad un normale web service?
BPEL può essere visto come uno strumento per offrire un servizio che scaturisce dalla composizione di altri servizi. In un'architettura SOA si parla di orchestrazione di servizi. Un processo BPEL quindi non espone operazioni semplici. Esso non fa altro che richiamare altri servizi per raggiungere un determinato scopo. Ad esempio può richiamare in sequenza diversi servizi utilizzando l'output del precedente come input del successivo, richiamare ciclicamente dei servizi ed eseguire anche parallelamente richieste a servizi diversi.
Alla fine del suo lavoro può ovviamente restituire un risultato al consumer oppure un fault. Possono essere eseguite sia richieste sincrone che asincrone. Insomma, è un web service :)

E' una cosa utile? comoda?
Potenzialmente si, praticamente ho i miei dubbi..

Come ogni cosa, ci sono dei pro e dei contro.

Pro:
L'unico che personalmente abbia trovato è che essendo un linguaggio XML-based, la sua struttura è ben definita, è facile eseguirne il parsing e la validazione. Questo ha reso possibile lo sviluppo di tool molto comodi per lo sviluppo di processi. Editor grafici che permettono di fare il design con il classico drag-and-drop.
Personalmente ho provato ad utilizzare il plugin per Eclipse BPEL Designer ed Intalio BPMS. Quest'ultimo non è proprio un designer BPEL. E' un designer per processi di business, ma modellati tramite BMPN (Business Process Model and Notation) che, a differenza di BPEL, è stato progettato solo per modellare i processi di business. Intalio comunque dal modello BPMN genera un file BPEL che può essere installato in qualsiasi motore. Ne esistono diversi altri, sia opensource che con licenze commerciali, ma non li ho mai utilizzati.
Devo dire che soprattutto Intalio è veramente comodo per modellare i processi, anche BPEL Designer lo è, ma richiede una conoscenza maggiore di BPEL per essere utilizzato.

Contro:
Purtroppo i contro (sempre riguardo la mia esperienza) sono molti di più dei pro.
Innanzitutto, come succede in molti editor grafici che cercano di fare ogni cosa dall'interfaccia senza eseguire nessun intervento sul codice, si perde ogni controllo su cosa succede "sotto" il designer. Questo problema l'ho riscontrato soprattutto con Intalio in quanto il loro framework è stato progettato per avere quello che viene chiamato zero-code development.
Effettivamente lo scopo è raggiunto, infatti anche volendo non c'è la minima possibilità di modificare a mano il codice dei processi. L'unico modo sarebbe prendere il file BPEL generato e modificarlo con un altro editor.
Con BPEL Designer, invece, la cosa non è così grave. Nonostante tramite l'editor grafico si possa fare praticamente tutto, è possibile modificare direttamente il codice sorgente del processo. Il problema è che non sempre l'interfaccia grafica "si accorge" delle modifiche fatte a mano.

Un altro problema, che personalmente trovo molto grave, è che siccome c'è un motore che legge il file XML ed in base al suo contenuto esegue delle azioni, è impossibile eseguire il debug di un processo. I tool grafici possono dire se ci sono errori di validazione. A volte si riesce ad eseguire il deploy di processi che non passano la validazione, ma non sempre è così. Questo non è un grosso problema, perché ad esempio ODE al momento del deploy se c'è qualcosa che non va da degli errori di compilazione, indicando dov'è il problema. I messaggi di errore a volte sono chiari, altre volte sono di difficile comprensione, ma almeno da qualche errore subito. Il problema nasce quando ci sono problemi nella logica, come qualche conversione dei dati, qualche assegnamento errato (si, un semplice assegnamento può essere qualcosa di molto poco semplice in BPEL), una condizione di uscita di un ciclo che non si verifica ecc..
E' comprensibile che non sia possibile eseguire un vero e proprio debug di un processo, ma il problema è che non si riesce ad avere nessun controllo sul processo installato. Quindi niente log personalizzati, niente messaggi ecc. Anche restituire un fault in base ad una condizione non è una cosa così semplice, ma li è colpa mia che non mi sono visto bene l'argomento :)
Quindi, per il capire cosa c'è che non va in un processo ci si deve basare sui messaggi di fault e sui log del motore. Ancora una volta, non sempre questi sono immediatamente comprensibili. Nella mia (breve) esperienza ogni volta che c'era qualcosa che non andava dovevo fare diverse ricerche per capire il significato dei messaggi di errore.

Ancora un altro problema: BPEL mal si adatta ai cambiamenti.
Infatti su diversi post, non necessariamente scritti da detrattori di BPEL (addirittura su un blog di un tipo che dava dei consigli ai neofiti), ho letto che quando c'è da fare qualche cambiamento o c'è qualcosa che non va in un processo, la cosa migliore è rimodellarlo daccapo. O_O
Ok, è una cosa che posso anche accettare se sto modellando un processo di Hello World, ma che succede se devo modificare un processo che magari richiama 10 servizi in parallelo, per ognuno gestisce i fault ed in base ad i risultati ricevuti decide se e quali altri servizi chiamare?

Ancora. Gli errori di validazione.
Non so voi, ma in generale ogni volta che c'è un errore di validazione in un file XML è un mal di testa.
Quando ci sono errori di validazione in file BPEL, o WSDL è ancora peggio.
Si, a volte si devono modificare anche i file WSDL di altri servizi che magari già sono funzionanti e installati in un web service engine perché per esempio (e mi è capitato con ODE) non supporta una direttiva import per importare schemi XSD che non siano locali.

Aderenza agli standard.
Come ho detto alcuni motori fanno i capricci su alcune cose, ad esempio Apache ODE con la questione degli import nei file WSDL.
Sempre per quanto riguarda Apache ODE (si è capito che è quello che ho utilizzato maggiormente? ) ho dovuto sbattere non poco la testa cercando di usare SOAP 1.2 per poi scoprire che solo l'1.1 è supportata.
La versione 1.2 è raccomandazione W3C dal lontano giugno 2003... ed ODE è un progetto tutt'altro che morto!
Infine, mi è capitato di constatare che semplici processi siano eseguiti da alcuni motori e non da altri.
In particolare mi è capitato che un semplicissimo processo di test funzionasse tranquillamente su Apache ODE ma sul motore di Virtuoso non riuscivo nemmeno a fare il deploy.

Insomma, BPEL 2.0 è standard dal 2004, ma i motori non sono ancora abbastanza maturi.

Conclusioni
Dopo alcuni giorni spesi a fare sperimentazioni varie mi sono fatto l'idea che BPEL si presta bene per implementare processi semplici, che utilizzano tipi di dati base e con un'orchestrazione non troppo laboriosa. Però lo standard è stato ideato proprio per implementare orchestrazioni complesse..
Inoltre non è facile da imparare, soprattutto l'utilizzo degli editor grafici porta a dover trovare un tutorial per ogni cosa che si vuole fare, per capire dove si deve cliccare ecc..
Infine i tool ed i motori nonostante i molti sforzi ancora non raggiungono un buon livello per essere utilizzati in ambiente industriale, però, io ho utilizzato solo tool opensource, magari le soluzioni proprietarie funzionano meglio.

Nonostante tutto, trovo BPEL un ottimo strumento per la modellazione dei processi. Però, per la modellazione, non per l'esecuzione.
Trovo che si possano metter su orchestrazioni di servizi in modo molto più semplice utilizzando altre tecnologie, utilizzando i web service engine per esporli ai client.

Queste sono solo considerazioni mie personali, magari sono dovute alla mia poca esperienza al riguardo, ma ho notato che sono idee abbastanza condivise in rete.
Chissà, se mi capiterà di acquisire un po' di esperienza (e spero di no) magari capisco tutti gli errori che ho commesso e mi ricredo, però visti i risultati scarsi ottenuti dopo qualche giorno di sperimentazione ne dubito fortemente :)

Ok, direi che si può concludere questo post che sembra più uno sfogo personale.. :P
Alla prossima :)

Virtuoso Universal Server: un DBMS per tutto

Salve :)
In questo post volevo parlare di un DBMS che ho scoperto recentemente e ho trovato molto interessante.

Parlo di Virtuoso Universal Server (http://virtuoso.openlinksw.com/), un DBMS che, un po come tutti, promette di risolvere tutti i problemi del mondo :)
La particolarità di questo server è che effettivamente può fare un po' di tutto, nel senso che può essere usato sia come DBMS relazionale, sia come un NoSQL Database, come XML Store e come Triple Store.

Come DBMS relazionale offre un po' tutte le caratteristiche che offrono gli RDBMS tipici come MySQL e simili. Ovviamente supporta il linguaggio SQL, inoltre mette a disposizione molte funzioni utili.

Per quanto riguarda le sue funzionalità come XML Database, Virtuoso non è uno store nativo, cioè il documento XML non è visto come unità fondamentale di memorizzazione e i dati fisicamente non vengono memorizzato secondo la struttura di questi documenti. Infatti questi vengono memorizzati in tabelle SQL, come tipo di dato XML appunto. In pratica questo tipo di dato sarebbe un long varchar, ma utilizzando il tipo XML viene fatto anche il parsing dei documenti, in modo tale che, se durante un inserimento viene passato qualcosa che non è un documento ben formato, viene notificato direttamente un errore.
Ha diverse funzioni per l'utilizzo dei documenti XML e supporta XPath, XQuery e le trasformazioni XSLT.

Per quanto riguarda invece le sue funzionalità come Triple Store, il modello di dati utilizzato è il modello a grafo, che è quello utilizzato dalla maggior parte dei Triple Store che non si basano su database relazionali. In realtà non so il modello di dati fisico quale sia, ma il modello utilizzato per i dati in memoria è sicuramente a grafo.
E' possibile interrogarlo tramite il linguaggio SPARQL , eseguire update tramite SPARUL ed è possibile importare ed esportare dati in formato RDF. I formati di serializzazione RDF supportati sono HTML+RDFa, RDF-JSON, N3, Turtle, TriG, TriX e RDF/XML.


Virtuoso permette di essere utilizzato sia come SQL che NoSQL Database grazie alla virtualizzazione dei dati. Il modello fisico di memorizzazione è comune a tutti i motori DBMS, ma ognuno di essi vede i dati come se fossero memorizzati nel formato che più si adatta a loro.
La cosa penalizza le prestazioni?
In teoria potrebbe, ma in pratica leggendo in giro sembra sia abbastanza veloce. Personalmente l'ho provato solo su pochi dati e non ho eseguito nessuno stress test quindi non ho elementi per giudicare.
Come Triple Store sembra si comporti particolarmente bene. Ho visto diversi benchmark che lo confermano e anche in questa classifica W3C sembra si comporti abbastanza bene: http://www.w3.org/wiki/LargeTripleStores.

Questa immagine riassume un po la virtualizzazione dei dati e i vari moduli da cui è composto Virtuoso:

Un'altra caratteristica molto interessante è che è molto semplice esporre le funzionalità di Virtuoso come web services. Infatti supporta può essere interrogato sia utilizzando SOAP che REST.

Si possono scrivere delle stored procedures e pubblicarle direttamente come servizi, con tanto di generazione automatica del WSDL.

Inoltre è possibile in qualche modo riutilizzare anche i web service scritti in Java, modificando un po il codice per eseguire una sorta di wrap. E' possibile riutilizzare anche i servizi scritti in linguaggi della piattaforma .NET.

Infine è disponibile un'estensione per poter utilizzare Virtuoso come motore BPEL4WS!

Grazie a questa è possibile organizzare le orchestrazioni dei servizi facendone il deploy direttamente nel DBMS.

Insomma, a mio parere le potenzialità sono molte, soprattutto negli scenari in cui si ha bisogno di dover gestire diversi tipi di dati ed avere la gestione migliore per ognuno di essi.

Inoltre poter gestire i dati, i servizi e magari anche le orchestrazioni da un unico punto semplifica parecchio la gestione..

Per concludere, Virtuoso è disponibile sia in versione commerciale che open source. La versione open source ovviamente ha qualche limitazione, non supporta infatti la replicazione dei dati e quello che chiamano "Virtual Database Engine", che permette di eseguire query SQL su database multipli remoti.

Personalmente ho fatto qualche sperimentazione con la versione opensource. Credo che sia molto più comodo utilizzarlo su sistemi Unix che non su Windows. Su sistemi come Ubuntu, per esempio, sono disponibili già i binari installabili dal gestore di pacchetti. Su Windows invece per poterlo compilare c'è bisogno di strimenti come Visual Studio ed altra roba..

Bene, direi che ho concluso con questo post pubblicitario :)

In questi giorni ho accantonato Virtuoso per fare delle prove con l'XML Database eXist. Se lo trovo interessante magari scriverò qualcosina anche su quello :)

Al prossimo post!