L’ambiente di sviluppo per applicazioni enterprise a crescita più rapida è probabilmente il Web. Se da un lato il terreno del Web è estremamente fertile per la nascita e l’evoluzione di applicazioni anche molto complesse, dall’altro lato pone problemi di uniformità, creazione di standard e qualità.
Il web engineering, in questo senso, diventa una vera e propria disciplina che decreta la metodologia e regola lo sviluppo delle applicazioni enterprise basate sul Web, che devono rispondere a requisiti di affidabilità, qualità e usabilità. Questa esigenza traspare in tutte le aree, anche in quelle meno legate agli aspetti prettamente produttivi come, per esempio, la team collaboration.
Le applicazioni Web basate sui flussi di lavoro rappresentano, probabilmente, la strada più promettente per un’evoluzione in questo settore, ma i requisiti che devono soddisfare non sono pochi. Tra gli altri, legati a coefficienti di efficacia e produttività, tali applicazioni devono anche rispondere a requisiti di agilità ed evoluzione. Il ciclo di revisione di queste applicazioni deve essere necessariamente molto breve, in modo da velocizzare l’introduzione di migliorie. Inoltre devono consentire una adozione efficiente delle modifiche e quindi “evolvere” verso soluzioni sempre migliori.
Una strada in questa direzione è rappresentata, per esempio, dai cosiddetti Domain Specific Languages (DSL), ovvero linguaggi di programmazione molto specifici, ristretti e ottimizzati per un particolare dominio o problema. Prima si definiscono i processi, i tipi di dati in gioco, i soggetti e le diverse modalità di interazione. Da queste definizioni deriva poi il linguaggio specifico con cui possono essere programmate applicazioni più efficienti per un particolare dominio. La programmazione, in sostanza, si sposta a un livello molto più alto, per parlare con le stesse logiche e la stessa semantica dei processi aziendali. È facile immaginare come potrebbe migliorare la comunicazione tra i responsabili dello sviluppo software e i responsabili dei processi aziendali di fronte a un’evoluzione simile dei linguaggi. Ma costruire applicazioni più efficienti e dal ciclo di revisione più breve può non essere sufficiente. Sono molti i casi in cui è necessario che i processi si adattino al contesto in cui si trovano. È questo l’obiettivo di framework come il Cawe (Context-aware workflow environment), vedi figura 1, sviluppato dall’ Università di Torino.
Architettura del framework Cawe
(Cliccare sull’immagine per visualizzarla correttamente)
A partire da una rappresentazione gerarchica dei flussi è possibile costruire applicazioni che ne siano “consapevoli”. In questo modo le applicazioni si possono adattare e riconoscere tipi di utenti diversi: da un lato i service-users, ovvero i beneficiari di un prodotto/servizio, dall’altro gli interacting-users, ovvero gli utenti che interagiscono direttamente con il sistema. A seconda del contesto e degli utenti, quindi, il workflow prende un percorso diverso e in questo senso si adatta. Il motore di workflow fa uso di un modulo di personalizzazione che restituisce una implementazione dipendente dal contesto: quindi fornisce le informazioni necessarie per prendere un percorso piuttosto che un altro a seconda delle condizioni a contorno. Flussi di lavoro che si adattano nelle applicazioni portano a strumenti più intelligenti e più vicini all’operatività reale di un’organizzazione.
Applicazioni nuove, distribuite all’interno dell’azienda, che tuttavia devono sempre poter comunicare e interagire tra loro. L’EAI (Enterprise Application Integration) passa oggi necessariamente attraverso i servizi (Web Services). Sostanzialmente viene definito un modello logico che prescinde dall’implementazione. Il fornitore del servizio mette a disposizione le specifiche, che sfruttano una tecnologia standard (Xml, Wsdl, Soap, Uddi). Un’architettura Soa (Service Oriented Architecture) è quindi caratterizzata da fornitori e clienti di servizi, che comunicano tra loro attraverso protocolli standard. Nei modelli più complessi questi due soggetti software collaborano con la mediazione di brokers, che hanno il compito di migliorare e ottimizzare l’attività di service providing.
La qualità di fornitura e funzionamento dei servizi diventa quindi elemento cruciale, motivo dello studio presentato dall’Università di Camerino sulla QoS Evaluation (valutazione della qualità di servizio).
Con il diffondersi di questi servizi, infatti, e soprattutto con l’aumentare delle applicazioni aziendali, è sempre più necessaria la realizzazione di “contratti” sulla qualità del servizio, ovvero di Sla (Service Level Agreeements).
Questi possono essere realizzati in SLAng (il linguaggio che specifica la qualità del servizio QoS). Per ogni interazione tra un servizio e l’utilizzatore, ma anche per ogni interazione tra due servizi, deve essere specificato uno Sla.
I servizi vengono misurati mediante transazioni. Ogni transazione corrisponde a una comunicazione o a un’operazione su database e così via. In un modello distribuito, con molti fornitori di servizi, occorre introdurre anche il concetto di transazione distribuita. Processi aziendali simultanei devono quindi essere coordinati da un transaction coordinator in modo da evitare errori in caso la transazione non vada a buon fine. Transazioni di durata maggiore e che vedono coinvolti più soggetti, richiedono inoltre l’introduzione del concetto di compensazione e quindi dei gestori di compensazione. Se una parte del processo fallisce, in questo modo non deve essere annullata tutta la transazione.
La struttura estesa di coordinamento delle transazioni, a questo punto, diventa la struttura che comprende coordinatori delle transazioni, fornitori di servizi, eventuali adattatori e tutte le comunicazioni tra questi elementi. Considerando il fatto che negli anni a venire saremo sempre più dipendenti da processi composti da fornitori di servizi, brokers, transaction coordinators, Sla e tutti gli altri elementi in gioco, la garanzia che questi processi vadano a buon fine diventa sempre più urgente. Non ci si può permettere che transazioni finanziarie diano errore perché un service provider è momentaneamente occupato. La struttura di coordianamento e di ottimizzazione giocherà quindi un ruolo cruciale.
