Il Governo Danese sta mettendo in campo un’iniziativa simile al SPCoop (Sistema Pubblico di Cooperazione), del CNIPA (Centro Nazionale per l’Informatica nella Pubblica Amministrazione): la OIO Service Oriented Infrastructure.
Le linee guida sinora redatte illustrano l’architettura focalizzando l’attenzione sui temi dell’interoperabilità, della sicurezza, della flessibilità, della scalabilità, della semplicità e dell’estendibilità.
In questo post vorrei fare alcune considerazioni sull’interoperabilità partendo dalle scelte operate dal progetto Danese.
—-><—-
L’interoperabilità è la capacità, resa “semplice”, di colloquio tra i servizi ed i loro utilizzatori. E’ assicurata da standard (Oasis, W3C ed altri) che costituiscono il fondamento dell’infrastruttura: il potenziale dei servizi non sarebbe nulla senza la possibilità di renderli accedibili con il minimo sforzo a quante più piattaforme possibili.
Ogni prodotto sviluppato per il mercato di SOA (Service Oriented Architecture) supporta un certo numero di standard. Le aziende che acquistano prodotti da fornitori diversi (con la necessità poi di farli interoperare) si fidano di ciò che è dichiarato e confidano sulle implementazioni. I guai sorgono quando si iniziano a fare prove: prodotti per cui è dichiarato il supporto totale ad un certo standard non riescono ad interoperare con altri per i quali si fanno le medesime dichiarazioni.
Le specifiche prevedono più possibilità, margini e di certo non i dettagli implementativi, cosicché una certa libertà interpretativa ed implementativa è lasciata ai produttori: la non totale implementazione della specifica, l’introduzione di namespace proprietari, la libera interpretazione di alcune parti hanno come risultato la mancata interoperabilità.
Questa situazione limita l’architettura, la fa evolvere sotto la guida delle implementazioni dei prodotti piuttosto che delle reali necessità. Le integrazioni punto-punto diventano indispensabili, le soluzioni custom irrinunciabili ed il vendor lock-in senza ritorno: tutte cause di insuccesso per una SOA.
L’interoperabilità è fondamentale, ma talvolta è carente o addirittura inesistente. I progettisti Danesi, consci del problema, hanno scelto di intraprendere la strada della personalizzazione delle specifiche sia fissando dettagli implementativi che ampliando ove necessario: così WS-Security di Oasis è diventato OWSA (OIO Web Service Architecture) Message Security Profile, WS-ReliableMessaging di Oasis è diventato OWSA Reability Profile, WS-I Basic Profile è stato personalizzato in OWSA Basic Profile e così via; nel dettaglio WS-Security è stato personalizzato per stabilire la tipologia delle credenziali, gli algoritmi e la lunghezza delle chiavi, WS-ReliableMessaging per stabilire la versione su cui basarsi, fissare i parametri dei tentativi (ogni quanto, fino a quando) e per imporre un esplicito riscontro ad ogni invio, WS-I Basic Profile per comprendere il protocollo SMTP (Simple Mail Trasfer Protocol) come possibile trasporto oltre HTTP. Mentre le prime due personalizzazioni riguardano dettagli implementativi e costituiscono un timido tentativo di risolvere una parte ridotta dei possibili problemi, la prima fa riflettere: aggiunge un’estensione proprietaria ad una specifica che dovrebbe garantire l’interoperabilità…
- La strada da intraprendere per conseguire l’interoperabilità è quella di fissare minuziosamente i dettagli implementativi?
- Le personalizzazioni (sia dettagli implementativi che estensioni) riescono ad eliminare ogni ambiguità, ogni incertezza sulle specifiche?
- La personalizzazione è conseguibile da chiunque che non sia un grande cliente o che non possa assicurare un alto numero di clienti?
- In un mercato ormai globale, la personalizzazione è la soluzione al problema dell’interoperabilità?
Le personalizzazioni sono fatte alla medesima stregua delle specifiche su cui si fondano: un certo numero di persone si riuniscono, fanno proposte, votano, producono versioni da sottoporre ad un pubblico più vasto che appone correzioni o modifiche, giungendo alla votazione finale; se le specifiche lasciano incertezze le estensioni riescono a chiarirle tutte ed a non introdurne di nuove? Difficile si possa prevedere tutto, probabilmente rispetto al processo delle specifiche c’è maggiore collaborazione tra i vendor ed i richiedenti delle personalizzazioni (che in questo caso sono i clienti) e, speranzosamente, si riesce a risolvere tutte le cause di mancata interoperabilità in un numero accettabile di iterazioni successive. Quello che si ottiene è l’integrazione punto-punto di vecchio retaggio venduto come l’interoperabilità di SOA: cambiando fornitore si dovrà ricominciare da capo, nuovi interlocutori dovranno o acquistare prodotti già personalizzati o seguire la trafila.
Oltretutto c’è da indagare su chi può aspirare a vedere le proprie personalizzazioni implementate su un prodotto di mercato. Le grandi aziende o le aziende che si interfacciano con un elevato numero di controparti probabilmente riescono a trovare fornitori disposti ad implementare le personalizzazioni; i partner, comunque, sono obbligati a rivolgersi ai medesimi fornitori perdendo l’agnosticità dell’implementazione cui SOA, tra le altre cose, mira. Le piccole aziende raramente tentano di ottenere (a costi ragionevoli) la piena collaborazione dei produttori al fine di vedere le proprie personalizzazioni implementate su prodotti di mercato. In un mercato globale, inoltre, grandi o piccole che siano le aziende hanno prima o poi la necessità di accedere a servizi offerti da altri (o permettere agli altri di accedere a servizi che l’azienda offre): si impone ai nuovi interlocutori di fornirsi solo da determinati vendor o gli si impone di chiedere ad altri fornitori che le personalizzazioni siano implementate?
Al fine di mitigare gli sforzi il progetto Danese prevede la fornitura di un toolkit (sia Java che .Net) da usare per implementare velocemente e coerentemente le personalizzazioni. Questo comunque non è la panacea: risolve i problemi fin quando è usato direttamente o come riferimento, comunque, come detto prima, è un approccio che maschera l’integrazione punto-punto. Altro discorso sarebbe se il comitato stesso, oltre a pubblicare la specifica, fornisse o patrocinasse lo sviluppo di reference implementation: rilasciate con licenze che assicurano l’utilizzo senza royalty risolverebbero i problemi. Capisco, per vari motivi non è di semplice applicazione (benché, ad esempio per alcune JSR, si sia già fatto): in alcuni casi basterebbe riportare sulla specifica le parti che servono al colloquio, però completamente non stralci.
—-><—-
Hai trovato questo post interessante? Sottoscrivi il feed completo e partecipa alla discussione
