L’introduzione di semilavorati applicativi, facilmente riutilizzabili, impone di valutare attentamente le interdipendenze tra i Web service
Si sente spesso dire che con i Web service (Ws) si è “scoperta l’acqua calda”. Il paradigma del computing distribuito (in opposizione a quello centralizzato), infatti, è già utilizzato da tempo all’interno di Corba (Common object request broker architecture), J2Ee (Java 2 enterprise edition) o Dcom (Distributed com). Tuttavia, gli approcci tradizionali sfruttano la creazione di una fitta rete di relazioni strette tra i singoli componenti cosa, questa, che li rende poco flessibili e ne impedisce il riutilizzo in contesti differenti. Le Soa, invece, incoraggiano la creazione di applicazioni flessibili e riutilizzabili, separando l’implementazione del servizio dalle interfacce applicative. Questo significa, in sostanza, che queste architetture permettono una scalabilità virtualmente infinita dei servizi e dei partecipanti. Le Soa si concretizzano nell’implementazione di “legami deboli” tra i componenti applicativi creati, in modo che qualsiasi cambiamento intervenuto sul Ws avvenga con la garanzia dell’isolamento, senza cioè che questo si rifletta sugli altri elementi dell’architettura. Le prime sperimentazioni dei servizi online sono, spesso, frutto delle iniziative di It manager illuminati ma, con il proliferare dell’utilizzo dei servizi Web in azienda, si impone con urgenza il problema di assicurarne la gestione ottimale.
L’impatto organizzativo
La questione del miglior presidio delle Soa all’interno di ambienti applicativi compositi inizia a essere sentita con urgenza. Soprattutto dalle realtà che, negli scorsi anni, hanno realizzato (e vorrebbero, di conseguenza, riutilizzare in contesti di business mutati) numerosi servizi Web. Questo significa, quindi, tener conto delle dipendenze che il Ws ha, sia a livello organizzativo che con gli altri servizi. Il riuso, infatti, impone di rivedere l’ottica dei gruppi di lavoro interni all’azienda, tipicamente verticali, per ragionare non più in termini di singole funzioni, ma di fornitori e utilizzatori di servizi. In seconda battuta, poi, occorre tenere in considerazione le dipendenze che si instaurano tra i diversi servizi, in quanto l’invocazione (richiamo) di un Ws ha effetti sugli elementi ad esso correlati. Un altro legame è quello che si realizza a livello di rappresentazione dei dati. In passato, le applicazioni erano create sulla base delle conoscenze del momento e le differenze nei diversi formati di rappresentazione dei dati erano superate con l’utilizzo di apposite interfacce di integrazione. Per i Ws è diverso, perché il loro valore aggiunto si esprime proprio nella misura in cui è possibile riutilizzarli velocemente, in contesti differenti, senza grossi sforzi di adattamento. Una strada percorribile è quella di avere versioni multiple delle interfacce disponibili per gli utenti, obbligando il creatore del servizio a occuparsi anche delle traduzioni.
