Mi chiamo Andrea Gumina. Sono laureato in Scienze dell'Informazione e lavoro per un'azienda di consulenza IT. Da qualche anno mi occupo di integrazione di sistemi; di SOA (Service Oriented Architecture) da poco meno di due.
mantenere i documenti delineati dal SOA Reference Model di Oasis (descrizioni delle funzioni, effetti, policy, contratti, ecc.)
Lasciavo intuire, inoltre, la necessità, sopratutto in fase di progettazione, di poter eseguire ricerche.
Un registry-repository esposto secondo le specifiche UDDI gestisce:
nomi logici e chiavi (del servizio, di chi lo offre, delle interfacce, dei punti di accesso e delle etichette)
etichette (i tModel, a loro volta etichettati da altri tModel, assegnati al servizio, a chi lo offre e ai punti di accesso)
riferimenti (URL contenute in tModel) a documenti vari (ad esempio interfacce, descrizioni, policy, contratti, ecc.)
Le ricerche, quindi, implicano conoscenza, almeno sommaria, di chi offre cosa o del modello di catalogazione (la tassonomia, rappresentata con le etichette). In alcuni casi (ad esempio quando si ignora la catalogazione adottata o si ha solo una vaga idea di cosa cercare), queste modalità possono essere insufficienti.
Di grande valore può essere la ricerca a testo libero sui documenti. Poter ricercare all’interno di queste informazioni (funzioni, effetti, interfacce, strutture dei messaggi, policy, ecc.) da buona certezza di trovare cosa si cerca (riduce il rischio, ad esempio, di duplicare l’esistente). Purtroppo la specifica UDDI non prevede questo tipo di ricerca: il registry-repository può implementarla esponendola solo al suo interno (interfacce utente, sopratutto, o API proprietarie).
Meno potente, diversa, ma prevista dalla specifica è la ricerca attraverso etichette. Usate come folksonomy (si veda, ad esempio, SOA Infrastructure Blog: Folksonomies In The Enterprise), come tassonomia o come compromesso tra le due, individuano insiemi di servizi. Presuppone un attento studio propedeutico (è necessario trovare una classificazione semplice, adatta, poco rigida ed efficace).
stabilisce la sintassi e la semantica delle operazioni e dei messaggi usati per interagire con i registry
è lo standard attualmente più implementato, più commercializzato e più utilizzato
non prende in considerazione le funzionalità richieste alla “parte repository“
Avvalendosi, però, dei tModels (definibili in breve come etichette legate a valori, URI o altri tModels), è possibile “implementare” quello che si richiede ad un repository (se pur con delle limitazioni). Il prezzo da pagare è la complessità, mitigabile da interfacce utente (utilizzabili solo da umani) o API (che hanno però il difetto di essere proprietarie e di riportare al problema di partenza).
Il registry-repository non può e non deve essere uno strumento isolato dal resto: per il governo, per il riuso, per il rigore del flusso di lavoro (la progettazione, ad esempio, deve poter contare sul registry-repository per sapere cosa già esiste e cosa manca, l’IDE utilizzato per “sviluppare” le composizioni, le orchestrazioni ed i processi deve potersi integrare, ecc.). UDDI garantisce queste integrazioni; le interfacce proprietarie non le escludono ma non le assecondano.
L’integrazione serve a collocarlo nel flusso di lavoro, favorendone (potremmo dire imponendone) l’utilizzo; il flusso di lavoro e l’utilizzo contribuiscono al governo (la governance).
UDDI, probabilmente, non è la SOLUZIONE, come non lo è l’approccio proprietario. UDDI ha il pregio di essere uno standard: garantisce l’integrazione del registry-repository con gli altri strumenti e componenti e ne semplifica la collocazione nel flusso di lavoro, favorendone l’utilizzo.
la questione è risolta offrendo sempre entrambe? (vedi ad esempio le API di Flickr)
oppure, più ragionevolmente, le circostanze e il problema determinano una o l’altra?
La presentazione che Paul Fremantle condivide su Slideshare (tenuta all’ApacheCon 2008) fa chiarezza sulla controversia, evidenzia fatti su cui riflettere e consiglia di scegliere ciò che è più appropriato per il problema e la situazione.
