Rimane un ultimo problema da risolvere e poi saremo in grado di lavorare comodamente sfruttando i servizi Web esposti sulla rete Internet: chi ci dice chi espone dei servizi e quali sono questi servizi ? Se ho bisogno di invocare un servizio che mi fornisca l’ora esatta, l’oroscopo, le previsioni del tempo, ecc. come faccio a sapere chi me lo offre ? Come posso confrontare le proposte sul mercato e scegliere quella che più si adatta alle mie esigenze e, perchè no, al mio budget di spesa ? Quando navighiamo in Internet e cerchiamo delle informazioni su un argomento, per esempio su SOAP, come ci muoviamo di solito ? Navighiamo sul nostro motore di ricerca “di fiducia”, scriviamo SOAP nella casella di testo e premiamo il pulsante “Cerca !”. Ecco la lista dei risultati a nostra disposizione. Sarebbe interessante poter usufruire di servizi analoghi anche per cercare un Web Service. Nel nostro caso potremmo scrivere “previsioni del tempo” o “oroscopo on-line” ed ecco comparire la lista dei servizi disponibili. Ebbene tutto questo, seppur con una dinamica leggermente diversa, è possibile. È stato infatti elaborato un meccanismo di registrazione e di consultazione di un archivio di servizi, pensato appositamente per la ricerca di Web Service sulla rete, o sulla Intranet aziendale. Stiamo parlando di Universal Description, Discovery and Integration (UDDI).

Si tratta di un insieme di funzioni che permettono di:

• Registrare aziende, servizi e informazioni per raggiungere i servizi stessi
• Modificare o cancellare le registrazioni
• Ricercare il database delle registrazioni

Operativamente un’azienda che vuole rendere disponibile un Web Services dovrà:

• Registrarsi come azienda in quanto tale
• Registrare il servizio offerto da un punto di vista descrittivo
• Registrare le informazioni necessarie ad invocare il servizio, come per esempio la URL presso cui è esposto

Queste informazioni sono spesso raggruppate in tre categorie: pagine bianche (business), pagine gialle (service), pagine verdi (technical infos).

Un client che voglia usufruire di un servizio potrà quindi ricercare una di queste voci o eseguire una ricerca su più livelli. Per esempio potremmo cercare tutte le aziende che vendono servizi di una determinata categoria, oppure cercare i servizi offerti da una certa azienda di cui ci fidiamo particolarmente. Ciò che conta è che, al termine di una ricerca completa, avremo ottenuto i dettagli tecnici necessari per invocare il servizio(per esempio la URL del file WSDL, se disponibile). Affinchè tutto questo processo diventi concreto manca ormai una sola ed ultima informazione: come si utilizza UDDI ? Forse la risposta a questa domanda era prevedibile: UDDI è esposto sulla rete Internet ed è raggiungibile sotto forma di Web Service ! Se vogliamo quindi cercare un Web Service dovremo almeno conoscere un Web Service UDDI di cui ci fidiamo e rivolgere a quest’ultimo le nostre richieste. Diverse aziende espongono, anche sul Web, motori di ricerca sui loro registry UDDI. Il database UDDI infatti non è uno ed unico al mondo, chiunque voglia può organizzare il proprio motore di ricerca ed il proprio business registry UDDI, nel rispetto delle raccomandazioni di chi ha creato UDDI stesso (http://www.uddi.org/). Le aziende che appoggiano e supportano UDDI (http://www.uddi.org/community.html) hanno concordato di replicare i loro database, in modo tale da fornire gli stessi record agli utenti. Potremmo inoltre pensare di organizzare nella nostra Intranet aziendale un registry UDDI per i servizi interni. Windows .NET Server, per esempio, fornirà un servizio di sistema per la gestione di un business registry UDDI.
 

Vediamo quindi, per completezza, come si può presentare una ricerca in un registry UDDI dal punto di vista dei messaggi SOAP che vengono scambiati. All’interno di un business registry UDDI abbiamo quattro categorie di informazioni, che per UDDI sono tipi di dati:

• businessEntity: fornisce informazioni non tecniche su una realtà o un’azienda che espone dei servizi, a prescindere da quali siano questi servizi (pagine bianche)
• businessService: fornisce informazioni non tecniche (descrizione, prezzo, ecc.) relativamente a servizi esposti dalle businessEntity (pagine gialle)
• bindingTemplate: fornisce informazioni tecniche (specifiche, entry point, ecc.) riguardo ai servizi (pagine verdi)<(LI>
• tModel: specificano i dettagli di interfacciamento verso un determinato servizio e dipendono dai bindingTemplate (pagine verdi)

Questi tipi di dati sono identificati univocamente all’interno dei registry tramite delle chiavi uuid_key che non sono altro che dei GUID (Global Unique IDentifier). La loro struttura è descritta da XML Schema ottenibili dal sito web di UDDI (http://www.uddi.org/).

Le funzioni API che abbiamo a disposizione in UDDI appartengono a diverse categorie:

 
Se volessimo schematizzare un’interrogazione UDDI, che veda la società Scarpe S.r.l. ricercare dei servizi esposti dalla società Suole S.p.A. avremo:

A questo punto il client ha tutti gli elementi necessari per raggiungere autonomamente il servizio scelto e quindi invocarlo.