Process Engine: sei per il SI o per il NO ?

“Non è un blog, è una brochure!” Questo è stato il commento di un amico che ha letto Caffè con BEA e sigh, io sarei tra i colpevoli. In effetti nel mio post precedente ho parlato e dato un giudizio positivo di un prodotto BEA, WebLogic Integration. Chiedo venia, purtroppo posso parlare di ciò che conosco. Per tentare di farmi perdonare, vi propongo un’altra riflessione, certo basata su WLI (vedi sopra) ma applicabile a tutti i prodotti dello stesso tipo.Spesso mi sono imbattuto in clienti che mi chiedevano: perchè dovrei usare un motore di processi ? Ecco, secondo me, le ragioni per utilizzarlo e quelle per farne a meno:I motivi del SI

1. si sviluppa più in fretta (perchè i wizard mi nascondono le complessità delle interfacce da usare)
2. si fà l’integration test più in fretta (perchè il debug di front-end e back-end è integrato)
3. la gestione dello stato dei processi è già pronta e non richiede ulteriore sviluppo
4. il monitor dei processi in produzione è già pronto e non richiede ulteriore sviluppo
5. è più semplice modificare l’applicazione quando è già in produzione

I motivi del NO

1. non ho controllo del codice perchè uso molti wizard e componenti già pronti
2. non posso realizzare certi trucchi, perchè lo strumento me lo impedisce
3. vorrei poter controllare alcuni dettagli dei processi in esecuzione, mentre lo strumento me ne visualizza altri

Le due liste non sono esaustive, anzi vi esorto a completarle o a modificarle secondo la vostra esperienza. Per quanto mi riguarda, e qui rischio l’ennesima stroncatura, i sostenitori della seconda lista finiscono spesso per riscriversi un process engine quasi per intero e dunque, io che sono di natura un pigro, mi chiedo: non era meglio prenderlo già pronto? 😉

Un process engine che mantiene le promesse

Tempo fa partecipai ad un avvincente progetto di integrazione: inserimmo un “bus” per lo scambio di messaggi fra le diverse applicazioni di una SIM (Società di Intermediazione Immobiliare) e grazie a questo “strano oggetto” i traders ed i loro capi potevano vedere informazioni tra loro correlate ma che risiedevano in sistemi differenti ed isolati. Le modifiche avvenivano in tempo reale ed i dati erano dunque sempre aggiornati.

Ma non fu questa la parte che più piacque al cliente. L’iniziativa ebbe successo grazie alla rapidità con la quale l’IT riusciva a realizzare le richieste dell’utente finale. Oltre naturalmente, all’affidabilità del sistema, che non perdeva un messaggio.

Se, dopo quasi dieci anni, cito ancora quell’esperienza è perchè il confronto con la realtà di oggi appare ancora istruttivo: le interfaccie di comunicazione fra il bus e le applicazioni da integrare venivano sviluppate a mano di volta in volta, partendo da un set di librerie proprietarie. Non esisteva il concetto di processo o di orchestrazione. Il mapping dei dati era realizzato con uno strumento visuale che alimentava un motore esterno al bus. Forse ciò che è cambiato meno da allora ad oggi è la trasformazione dei messaggi. Eravamo già ad uno stadio evoluto, anche se non utilizzammo standards come XML.

In un progetto più recente che ho potuto osservare da vicino, il system integrator ha semplificato la componente di integrazione ed introdotto l’uso di un motore di processi utilizzando WebLogic Server e WebLogic Integration. Il bus comunica con le applicazioni via SOAP, RMI o JDBC, ed ha integrato la componente di processo consentendo la creazione di nuove funzionalità basate su quelle offerte dei sistemi esterni.

WebLogic Integration ha fatto la parte del leone. Ha consentito l’integrazione delle applicazioni e lo sviluppo dei processi in pochissimo tempo. L’infrastruttura di test inclusa nel prodotto ha ridotto i tempi di collaudo e le funzionalità del motore hanno sollevato il system integrator dall’onere di dover sviluppare da sé la logica di stato e persistenza di messaggi e di processi.

Naturalmente non solo BEA Systems offre strumenti di questo tipo. Ma ciò che voglio evidenziare, al di là dei prodotti utilizzati, è il progresso avvenuto in questo campo. Si programmano sempre meno le interfaccie di comunicazione (che son sempre state una materia ostica, nello sviluppo e nel collaudo) e si riduce sempre di più il tempo di realizzazione di nuove funzionalità, grazie all’uso dei process engine come WebLogic Integration.

Oggi affronto un progetto d’integrazione con grande serenità, convinto che l’adozione di WebLogic Integration sollevi il team da molto lavoro inutile, elimini le cause di tanti errori e consenta di raggiungere l’obiettivo con tempi certi e, cosa più importante, con la soddisfazione del cliente.