4 Conclusioni
L'obiettivo della realizzazione di Zlatan era principalmente quello di testare alcuni aspetti del
Process Engine e realizzare un prototipo dimostrativo funzionante. In particolare, è stato
interessante approfondire l'interoperabilità del PE con la piattaforma Java, l'utilizzo di JMS come protocollo di trasporto e la distribuzione del sistema su più macchine. Altri aspetti interessanti hanno riguardato l'analisi dei problemi del linguaggio BPEL e lo studio delle soluzioni di connettività offerte da SAP.
Il progetto ha anche evidenziato tutte le potenzialità di Java: il linguaggio è stato usato come supporto per la soluzione di una vastissima gamma di tipologie di problemi, dalla programmazione distribuita all'interazione con periferiche seriali, dallo sviluppo di interfacce grafiche alla programmazione web lato server ed all'interrogazione di basi di dati.
4.1 Sviluppi futuri di Zlatan
Il proseguimento nell'implementazione di Zlatan non può non prescindere da una completa reingegnerizzazione del sistema, da effettuarsi sulla base delle conoscenze maturate durante la scrittura del primo prototipo.
Dovrebbe essere innanzi tutto definito in maniera precisa un documento di specifica dei requisiti, attività che non è stata fatta in precedenza a causa della natura estremamente sperimentale del progetto e della scarsa conoscenza iniziale degli strumenti da utilizzare.
Il prototipo suggerisce almeno tre caratteristiche da implementare in una ipotetica versione futura di Zlatan:
1. un ambiente SDK configurabile e parametrico che permetta la scrittura di nuovi driver per i protocolli in ingresso in maniera semplice e automatica, utilizzando la struttura già implementata (ma non standardizzata) per i driver del prototipo (architettura delle classi e dei package, interfaccia utente, pacchettizzazione, file di configurazione);
2. un sistema di autorizzazioni e riconoscimento basato su firma digitale e supportato dalle tecnologie XML già disponibili sul mercato;
3. un modello per la generalizzazione dei dati trattati: dal singolo ordine d'acquisto a qualsiasi tipo di dato aziendale, utilizzando un formato XML compatibile con tecnologie come SAP BC o SAP WAS (vedi § 2.3).
4.2 Considerazioni finali
L'integrazione delle applicazioni aziendali rappresenta sicuramente una buona parte del futuro del mercato dell'informatica. I nomi delle aziende citate più volte nel corso di questo documento ne sono una testimonianza più che valida: i principali produttori di software di tutto il mondo sono impegnati, in maniera diversa, nella specifica e nell'implementazione di protocolli condivisi che garantiscano l'interoperabilità tra le piattaforme.
L'architettura orientata ai servizi potrebbe rimanere per molto tempo il punto di riferimento di questo processo di integrazione, data la sua estrema generalità e le potenzialità non ancora completamente esplorate. Possono invece sorgere dubbi sulle tecnologie che al momento attuale la implementano: l'uso di XML comporta un certo grado di overhead dovuto alla rappresentazione testuale ed alla ridondanza delle informazioni; inoltre, WSDL, SOAP e gli altri standard citati sono afflitti da problemi ampiamente analizzati nei paragrafi precedenti. Non è quindi da escludersi che il mercato possa imporre anche in un futuro prossimo modelli, standard e protocolli (condivisi o imposti de facto) migliori di quelli attuali.
Per concludere, si può riprendere l'esempio già citato nell'introduzione. Allo stato attuale, l'aspetto tecnologico nell'ambito dell'integrazione di applicazioni business è ancora troppo preponderante nei confronti degli aspetti applicativi: la potenza e la flessibilità dell'architettura a servizi non potranno essere sfruttate completamente, finchè gli sviluppatori di sistemi service oriented ed EAI dovranno dedicare del tempo alla soluzione di problemi di basso livello come il tracciamento dei messaggi SOAP scambiati tra i servizi.
