Sicurezza e Web Services

Introduzione 
 9
di standard dei Web Services, quelli sulla sicurezza, approfonditi nei tre successivi 
capitoli. Come detto, i capitoli 5, 6 e 7  conterranno separatamente i tre standard 
fondamentali dello stack di sicurezza dei Web Services (XML-Signature, XML-
Encryption, SAML). Il Capitolo 9 completerà il percorso cognitivo, rilegando in se i 
concetti esposti, qui troverà posto lo standard unificante delle tecnologie 
menzionate nel resto del documento: lo standard WS-Security. Il Capitolo 10, 
conclude la tesi con un esempio di interoperabilità tra due piattaforme distinte, in 
cui metteremo in pratica le conoscenze teoriche acquisite sulla sicurezza dei Web 
Services. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1. Gli standard dei Web Services  
 10 
 
 
 
1. GLI STANDARD DEI WEB SERVICES 
 
 
 
 
1.1 XML: Meta-Linguaggio di inter-scambio data-oriented 
 
L’ eXtensible Markup Language (XML)1 offre un linguaggio standard text-based 
potenzialmente comprensibile a tutte le applicazioni. XML è completamente 
indipendente dalla piattaforma, è un formato dati universale ed è auto descrittivo. 
Questi punti diverranno fondamentali in tema di sicurezza WS.  La natura text-
based genera un sovraccarico in più nel volume dei dati ma non richiede un 
middleware speciale per processarli. L’XML è il cuore e l’anima dei WS.  Il core 
degli standard di sicurezza XML è anch’esso XML-based. 
 
 
1.1.1 Le origini di XML 
 
XML è già il più diffusamente accettato formato per l’interscambio dei dati. XML è 
essenzialmente il mondo del dato strutturato. Fu sviluppato per superare le 
limitazioni del HiperText Markup Language (HTML), il quale è buono per 
descrivere come qualcosa debba essere visualizzato ma è povero nel 
differenziare cosa è dato e cosa è visualizzazione. HTML fu il primo veloce e 
sporco approccio usato per il Web con le sue ricche pagine testo e grafica 
collegate assieme usando l’hiper-text.   
HTML realizzò i traguardi prepostosi. Esso è semplice,  il formato è human-
readable, usa un set di tags per tutti i documenti ed è completamente focalizzato 
al documento. Però, un solo set di tag non può descrivere i dati.  Un catalogo, per 
esempio,  necessita di  un tag <PREZZO>, un manuale di riparazione avrà bisogno 
di un tag <PARTNUM>, i tags <ALLERGENI> <EFFETTI COLLATERALI> saranno 
                                                   
1
 http://www.w3.org/XML/ 
1. Gli standard dei Web Services  
 11 
fondamentali per i medicinali e così via. Nessuno eccetto i produttori di browsers 
può aggiungere tags al set standard HTML. In contrasto  a ciò, con XML , le 
compagnie , i consorzi, i corpi di standardizzazione possono definire il propri tipi di 
documento con loro unico metadato. XML è un meta linguaggio. Esso viene infatti 
utilizzato per la definizione di altri linguaggi. 
L’XML è un sottoinsieme dello Standard Generalized Markup Languages (SGLM). 
Uno dei suoi scopi era quello di separare i contenuti dalla presentazione.  SGML, 
però, era troppo esteso e troppo complesso per la descrizione di documenti Web.  
Esso aveva così tante opzioni che semplicemente confondevano la giovane e naif 
visione del Web. 
HTML permette un piccolo riuso del codice. XML con Document Type Definitions 
(DTSs) ora quasi sostituito dl XML Schema,  permette alle comunità di accordarsi 
nello schema per i tipi di dato. Questo è stato fatto in svariati settori come in 
chimica, musica, matematica, assicurazioni, farmaceutica e centinaia di altre 
industrie.  Le singole compagnie,dunque, hanno potuto generare schemi per uso 
interno con come la Merrill Lynch con il suo X4ML. 
XML indirizza il connubio tra la complessità progettuale di SGML e il set prefissato 
di tag dell’HTML. Inoltre i documenti XML sono documenti SGML completamente 
legali ,  XML non è un’applicazione di SGML ma un suo subset. La proprietà più 
potente che XML eredita dal suo predecessore è l’estensibilità. 
 
 
1.1.2 XML e Web Services  
 
I dati destinati ad un uso WS possono essere creati in XML o convertiti in XML dal 
loro formato nativo. Questi dati possono essere prelevati da un database 
relazionale piuttosto che processati da un linguaggio di programmazione quale 
Java o C# e trasformati in XML. 
XML archivia i dati con un tag elemento descrittivo come questo: 
 
<PartNo>54-2345</PartNo>  
 
Qui, <PartNo>  è il tag elemento descrittivo e 54-2345 è la descrizione del dato. I 
tags XML sono inclusi di brackets ( < > ) e hanno un inizio e una fine. Il tag di fine 
1. Gli standard dei Web Services  
 12 
è marcato da uno slash ( / ). Gli elementi possono avere uno o più attributi che 
usano coppie nome valore: 
 
<?xml version="1.0"?> 
<shipOrder> 
<shipTo> 
<name>Tove Svendson</name> 
<street>Ragnhildvei 2</street> 
<address>4000 Stavanger</address> 
<country>Norway</country> 
</shipTo> 
<items> 
<item> 
<title>Empire Burlesque</title> 
<quantity>1</quantity> 
<price>10.90</price> 
</item> 
    <item> 
<title>Hide your heart</title> 
<quantity>1</quantity> 
<price>9.90</price> 
      </item> 
   </items> 
</shipOrder> 
Listato 1.1. La struttura gerarchica XML dei tag di un ordine di acquisto. 
 
 
 
1.1.3 XML Namespace  
 
I nomi di un documento XML potrebbero essere confusi da altri nomi presenti in un 
altro documento XML. I namespaces di XML risolvono il problema, garantendo un 
meccanismo per separare e distinguere i nomi.  Un namespace opera più o meno 
come un package i C++ o Java,  permette cioè, ai nomi locali di collidere coi nomi 
di altri insiemi esterni  definendo l’ambito contestuale dell’elemento. I namespace 
sono tipicamente costituiti da un nome lungo, per questo vengono abbreviati da 
prefissi nel locale (con l’attributo speciale xmlns).  Quando si vedono prefissi 
comuni come wsee per il WS schema, si tenga conto che questi potrebbero essere 
associati a namespace anche molto lunghi.  
I namespaces sono un punto critico per i WS perché quando un documento viene 
processato da diverse organizzazioni, le collisioni di nomi sono comuni. Si 
consideri che un singolo WS genera almeno  quattro tipi di documento per una 
conversazione: l’istanza del documento che trasporta i dati , la busta SOAP che 
definisce il formato del messaggio, l’istanza WSDL che descrive l’interfaccia e lo 
1. Gli standard dei Web Services  
 13 
schema WSDL che valida la definizione dell’interfaccia. Altre in aggiunta 
dipendono dal tipo di servizio. 
I namespace sono uniform resource identifiers (URI). 
xmlns:myns=http://www.myorg.com/namespace/XML 
questo nome non dipende dall’elemento del documento XML nel quale risiede.  È 
tecnicamente un uniform resource name (URN). Un URN è solo un nome e non 
punta a qualcosa, non può essere dereferenziato. L’unica ragione che spinge ad 
utilizzare un URL al suo posto è che l’URL  è un nome corrispondente a un DNS 
registrato ed è quindi garantito essere l’unico su tutto il globo. 
 
 
1.1.4 XML Schema 
 
Già SGML includeva un insieme di elementi che definivano come e quali 
particolari elementi o attributi erano usati nell’istanza del documento XML. Questi 
sono i Document Type Definitions. Più confusamente, rispetto all’XML Schema, i 
DTDs erano specificati in un differente linguaggio del SGLM stesso. I DTDs 
avevano altre limitazioni superate recentemente con l’introduzione dell’XML 
Schema. Gli XML Schemas sono stati creati per definire e validare un documento 
XML. Sono descritti in XML. Definiscono i tipi di dato e l’ordine degli elementi 
richiesto.  Ovviamente se vi è la necessità di inserire un nuovo tipo di dato, uno 
schema può essere cambiato indipendentemente dai dati. È pratica comune usare 
xsd come prefisso da associare al namespace di riferimento di XML Schema come 
mostra il Listato 1.2. 
 
<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema"> 
<xsd:element     name="shipOrder" type="order"/> 
<xsd:complexType name="order"> 
    <xsd:element   name="shipTo"    type="shipAddress"/> 
    <xsd:element   name="items"     type="cdItems"/> 
</xsd:complexType> 
<xsd:complexType name="shipAddress"> 
    <xsd:element   name="name"      type="xsd:string"/> 
    <xsd:element   name="street"    type="xsd:string"/> 
    <xsd:element   name="address"   type="xsd:string"/> 
    <xsd:element   name="country"   type="xsd:string"/> 
</xsd:complexType> 
<xsd:complexType name="cdItems"> 
    <xsd:element   name="item"      type="cdItem"/> 
</xsd:complexType> 
<xsd:complexType name="cdItem"> 
    <xsd:element   name="title"     type="xsd:string"/> 
    <xsd:element   name="quantity"  type="xsd:positiveInteger"/> 
1. Gli standard dei Web Services  
 14 
    <xsd:element   name="price"     type="xsd:decimal"/> 
</xsd:complexType> </xsd:schema> 
Listato 1.2. XML schema di un ordine d’acquisto. 
 
XML Schema è fondamentale per la validazione automatica delle istanze di 
documenti XML conformi. I tipi semplici di XML Schema sono string, integer, 
double, float, date, time. Il tipo viene specificato nella definizione dell’elemento: 
<xsd:element name="CustomerNumber" type="xsd:integer"/>  
Il processore XML valida le istanze dei documenti sulla base dello schema 
comparando  gli elementi e i tipi presenti nella definizione dello schema con quelli 
dell’istanza documento XML. I dati complessi possono essere modellati bene  
usando il costrutto ComplexTypes.  
Gli XML Schemas sono un’importante innovazione per la sicurezza XML. Essi 
sono molto più complessi dei DTDs, ma definiscono più stringenti limiti nella 
definizione degli schemi. Questo è buono nell’ottica della XML Security che 
intende accuratezza consistenza come essenziali. Gli XML Schemas sono tools 
fondamentali per una precisa definizione delle tecnologie di Web Services Security 
quali XML Signature, XML Encription e WS-Security. 
 
 
1.1.5 XML Transformation 
 
Le trasformazioni XML sono la vera ragione per cui si dice che i WS sono una 
forma di middleware loosely coupled ( basata cioè su una connessione debole tra 
le coppie) . Tradizionalmente il middleware utilizzato genera connessioni stringenti 
tra le parti.  Un cambiamento in un blocco del sistema non influenza 
armonicamente tutto il resto ma tutto il sistema si arresta. Con le trasformazioni 
XML, se  una parte del sistema WS viene cambiata, eseguendo la necessaria 
XML transformation dinamicamente a runtime, essa rimane compatibile con il 
resto del sistema.  Le quattro trasformazioni descritte in seguito sono 
XPath,XSLT,XQuery e XMLBeans. 
 
XPath 
La trasformazione è detta XPath perché, nella sua semplificazione, è un modo per 
fare riferimento a una parte di un documento XML in maniera simile al path del file 
1. Gli standard dei Web Services  
 15 
system. Per esempio è possibile riferirsi al nodo radice di un documento XML 
usando l’espressione XPath  / .  Ci si potrebbe riferire al nodo foo al di sotto del 
nodo corrente attraverso l’espressione ./foo. Questa è l’idea di base di XPath. 
Come ogni cosa in XML, sembra di andar dal semplice al complesso con veloci 
ragionamenti.  XPath non verrà descritto in dettaglio ma è necessario possedere 
famigliarità con questo linguaggio per diverse ragioni.  Ad esempio, quando viene 
usato in XML Signature bisogna conoscerlo per decidere cosa si deve firmare.  
Viene poi utilizzato in molte altre specifiche come l’XSLT, Xpointer, XML 
Encription.  
 
XSLT 
L’Extensible Stylesheet Language Transformation trasforma un documento XML in 
una differente struttura. Uno style sheet (foglio di stile) fornisce le istruzioni che 
descrivono come modificare o ristrutturare un documento. In questo modo, è 
possibile cambiare nome agli elementi tags, riordinare le sequenze, rimuovere e 
aggiungere elementi e così via. Uno scenario tipico per XSLT potrebbe essere 
quello della ricezione di un’ ordine di acquisto e della sua trasformazione nella 
struttura interna richiesta. Oppure l’unione di più documenti in uno.  XSLT è 
frequentemente usato per le trasformazioni dall’interno ai formati standard esterni 
delle industrie.  Nell’industria delle assicurazioni, XSLT è usato per traslare forms 
interne nel formato standard industriale ACORD (anch’esso un dialect XML).  
Un diffuso tipo di documento che viene generato dall’XSLT è l’HTML che può 
essere generato per esempio quando è necessario visualizzare informazioni. 
 
XQuery 
XQuery è un linguaggio di trasformazione emergente che copre lo stesso campo 
di XSLT ma, a differenza di esso, è più improntato su query.  XSLT è orientato al 
document-style, infatti è relativamente semplice trasformare documenti XML in 
documenti HTML, mentre XQuery è preferibile per le trasformazioni data-style, 
come fare una query ad un documento XML per ottenere un altro documento 
XML. È però anche vero che entrambi i linguaggi risolvono perfettamente entrambi 
gli stili.  
 
 
1. Gli standard dei Web Services  
 16 
1.2 SOAP: Messaging XML e Accesso remoto alle applicazioni 
 
 
1.2.1 Le origini di SOAP  
 
Il Simple Object Access Protocol è stato sviluppato nel 1998 da Microsoft in 
collaborazione con UserLand e DevelopMentor. Il fine era proprio quello di 
interconnettere applicazioni attraverso l’interscambio di dati strutturati sopra 
protocolli Web.   
Con la versione SOAP 1.1, il comitato tecnico ha deciso di mantenerne il nome  
originale come acronimo. Infatti SOAP 1.1 non è ne simple (semplice), ne accede 
agli oggetti nel senso esatto del temine. Può incapsulare però dati e operazioni 
che fanno questo. 
L’idea di SOAP è di creare un container uniformato che preveda una varietà di 
protocolli di trasporto. 
SOAP è uno schema di  packaging XML-based per il trasporto di messaggi XML 
da un’applicazione ad un’altra. SOAP offre un container standard che può 
trasmettere su praticamente ogni protocollo (come HTTP).  Un importante accordo 
sulle direttive informatiche , specialmente in relazione alla sicurezza, si trova nel 
SOAP header. Si analizzerà in modo dettagliato i SOAP headers quando si 
approfondirà WS-Security nel Capitolo 8. 
 
 
1.2.2 Come SOAP lavora 
 
Dopo che XML ha definito i contenuti del messaggio, SOAP definisce come i dati 
si muovono da un punto all’ altro della rete. SOAP permette di inviare e ricevere  
dei documenti XML a comuni protocolli di trasporto di dati.  Se il concetto di inviare 
e ricevere messaggi su HTTP suona famigliare ,il middleware Web-based non è 
proprio nuovo, per lungo tempo, infatti, gli esperti hanno aggiunto comandi extra ai 
messaggi HTTP.  SOAP formalizza questo processo e lo fa non solo per 
documenti XML, ma anche per l’esecuzione di procedure remote. 
SOAP supporta i modi RCP/encoded e Document/literal.  RPC/encoded viene 
attuato circa più o meno come il tradizionale middleware RPC. Le comunicazioni 
1. Gli standard dei Web Services  
 17 
RPC tendono alla sincronizzazione e a comunicazioni a grana fine, generando un 
adattamento a integrazioni intra-organizzative dove ci si aspetta una velocità di 
rete più alta e una latenza più bassa. Document/literal supporta meglio l’approccio 
a connessione detta ad accoppiamento lasco. La comunicazione, in questo caso, 
tende all’asincronismo e i blocchi di dati scambiato sono a grana più grossa. 
Questa seconda soluzione è più adatta per integrazioni inter-organizzative. 
 
 
1.2.3 La struttura di SOAP 
 
SOAP prevede una busta (envelope) che contiene un messaggio XML e le 
informazioni riguardanti la gestione di molteplici politiche. Le applicazioni restano 
così sollevate dal carico della gestione del trasporto, prelevando solo i dati utili 
contenuti nella busta. 
All’interno della busta SOAP trovano posto due sotto elementi: l’header e il body. 
- SOAP header : contiene informazioni riguardanti il messaggio SOAP che sono 
usate per il management e per la sicurezza. SOAP è stato progettato per 
essere estendibile e l’area preposta alla gestione delle estensioni è l’header 
SOAP. 
 - SOAP body: Contiene le informazioni sensibili del messaggio XML 
(payloads). Qui risiedono le informazioni che scambiano le applicazioni, come 
documenti, richieste d’ordine, contratti oppure informazioni sulla chiamata a 
procedura remota, metodi da chiamare e parametri relativi. 
 
<?xml version="1.0" ?> 
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> 
<env:Header> 
<n:alertcontrol xmlns:n="http://example.org/alertcontrol"> 
<n:priority>1</n:priority> 
<n:expires>2004-06-22T14:00:00-5:00</n:expires> 
</n:alertcontrol> 
</env:Header> 
<env:Body> 
<m:alert xmlns:m="http://example.org/alert"> 
<m:msg>Pick up Bobby at school at 2PM</m:msg> 
</m:alert> 
</env:Body> 
</env:Envelope> 
Listato 1.3  Questo semplice messaggio SOAP evidenzia il contenuto del SOAP header e del SOAP body. 
1. Gli standard dei Web Services  
 18 
 
                Figura 1.1. La struttura base di un messaggio SOAP  
 
 
1.3 WSDL: Schema per gli Oggetti e le interfacce XML/SOAP 
 
Il Web Service Description Language (WSDL) è tipicamente usato dagli 
sviluppatori per produrre tool di sviluppo di WS. Esso descrive quali funzionalità il 
WS espone, come esso comunica e dove si trova. Inoltre WSDL definisce la 
struttura SOAP utilizzata da un particolare WS. 
 
 
1.3.1 Le origini di WSDL 
 
WSDL è un linguaggio XML che descrive un WS.  Quando si definisce un 
contratto per un’architettura service-oriented, esso si riferisce al file WSDL.  Lo 
standard WSDL è stato guidato da Microsoft, IBM e Ariba. Questo gruppo ha poi 
sottoposto il WSDL 1.1 al W3C nel Marzo 2001 dove ha immediatamente 
guadagnato il supporto di altri 22 membri. Esso è stato quindi ufficialmente 
categorizzato a standard W3C con leggeri aggiustamenti. I tools di sviluppo 
utilizzando WSDL, definiscono le procedure remote da chiamare dall’esterno nel 
linguaggio di programmazione usato dal tool. Per gli  sviluppatori esterni chiamare 
una di queste WSDL RPCs è come utilizzare un’ oggetto o chiamare un metodo in 
locale.  Inoltre WSDL è orientato al monitoraggio e all’analisi dei sistemi.  
1. Gli standard dei Web Services  
 19 
Tecnicamente WSDL crea uno schema per gli oggetti e le interfacce XML/SOAP.  
 
 
1.3.2 Gli elementi di WSDL  
 
Un documento WSDL, come abbiamo detto, contiene tre sezioni che producono 
operazioni, binding e servizi. Il documento inizia con un tag <definitions>  e la 
definizione dei namespace. La sezione delle operazioni è identificata dai tag 
<message> e <portType> che descrivono cosa le operazioni fanno. Il tag 
<binding> descrive come le operazioni sono invocate. In fine, il tag <service> 
indica dove i servizi sono localizzati. Questa struttura è evidenziata in Figura 1.2 
 
Figura 1.2. Il layout di un file WSDL 
 
Nei seguenti listati è riportato un WSDL per una semplice calcolatrice che somma 
e sottrae. Un servizio presente nel sito Web di SalCentral.  L’esempio è stato 
spezzato in quattro sezioni per mettere in evidenza ognuna di esse. 
 
<definitions name="SimpleCalculator.csimplecalc" 
targetNamespace="http://sal006.salnetwork.com:83/xmlone/SimpleCalculator/ 
CSimpleCalc.xml" 
xmlns:tns=http:"//sal006.salnetwork.com:83/xmlone/SimpleCalculator/ 
CSimpleCalc.xml" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"  
xmlns="http://schemas.xmlsoap.org/wsdl/"> 
Listato 1.4. Sezione Definitions del WSDL di SimpleCalculator 
 
1. Gli standard dei Web Services  
 20 
Nel seguente Listato 1.5 viene mostrato l’uso dei tag <message> prima e poi quello 
di <portType>. Le descrizioni dei messaggi da generare vengono ordinatamente 
raggruppate in modo che la prima definisca la richiesta e la seconda la risposta. 
Successivamente i port types identificano a chi è inviato il messaggio e come. Un 
port type è una collezione di operazioni. In questo caso, le operazioni Add e 
Subtract. 
 
<message name="AddRequest"> 
        <part name="X" type="xsd:long" /> 
        <part name="Y" type="xsd:long" /> 
</message> 
  <message name="AddResponse"> 
        <part name="Return" type="xsd:long" /> 
</message> 
  <message name="SubtractRequest"> 
        <part name="X" type="xsd:long" /> 
        <part name="Y" type="xsd:long" /> 
</message> 
  <message name="SubtractResponse"> 
        <part name="Return" type="xsd:long" /> 
</message> 
  <portType name="SimpleCalculator.csimplecalcPortType"> 
        <operation name="Add"> 
            <input message="tns:AddRequest" /> 
            <output message="tns:AddResponse" /> 
        </operation> 
        <operation name="Subtract"> 
            <input message="tns:SubtractRequest" /> 
            <output message="tns:SubtractResponse" /> 
        </operation> 
</portType> 
Listato 1.5. La sezione Operations di SimpleCalculator 
 
La seconda grande sezione del WSDL descrive come le operazioni vengono 
eseguite dal binding al trasporto. 
 
<binding name="SimpleCalculator.csimplecalcbinding" 
type="tns:SimpleCalculator.csimplecalcPortType"> 
  <soap:binding style="rpc" 
transport="http://schemas.xmlsoap.org/soap/http" /> 
  <operation name="Add"> 
    <soap:operation soapAction="http://sal006.salnetwork.com:83/xmlone/ 
       SimpleCalculator/CSimpleCalc.xml#Add" /> 
    <input> 
      <soap:body use="encoded" 
namespace="http://sal006.salnetwork.com:83/xmlone/SimpleCalculator/ 
       CSimpleCalc.xml" 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> 
    </input> 
    <output> 
      <soap:body use="encoded" 
namespace="http://sal006.salnetwork.com:83/xmlone/SimpleCalculator/ 
       CSimpleCalc.xml" 
1. Gli standard dei Web Services  
 21 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> 
    </output> 
  </operation> 
  <operation name="Subtract"> 
    <soap:operation 
soapAction="http://sal006.salnetwork.com:83/xmlone/SimpleCalculator/ 
       CSimpleCalc.xml#Subtract"/> 
    <input> 
      <soap:body use="encoded" 
namespace="http://sal006.salnetwork.com:83/xmlone/SimpleCalculator/ 
       CSimpleCalc.xml" 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> 
    </input> 
    <output> 
      <soap:body use="encoded" 
namespace="http://sal006.salnetwork.com:83/xmlone/SimpleCalculator/ 
       CSimpleCalc.xml" 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> 
    </output> 
  </operation> 
</binding> 
Listato 1.6. La sezione Binding di SimpleCalculator. 
 
La terza e ultima sezione del WSDL file descrive dove il WS risiede attraverso uno 
specifico indirizzo URL. In molti casi, un Web Server fa partire  una servlet  
quando viene ricevuta una richiesta WS. In questo esempio il Web server gira 
immediatamente questa richiesta a uno script CGI. 
 
<service name="SimpleCalculator.csimplecalcService"> 
    <port name="SimpleCalculator.csimplecalcPort" 
binding="tns:SimpleCalculator.csimplecalcbinding"> 
    <soap:address 
location="http://sal006.salnetwork.com:82/bin/simplecalc.cgi" /> 
    </port> 
  </service> 
</definitions> 
 
Listato 1.7. La sezione Defining Where di SimpleCalculator. 
 
 
1.4 UDDI : Pubblicazione e Ricerca di Web Services 
 
L’Universal Description, Discovery, and Integration (UDDI) è un servizio di 
pubblicazione e ricerca per WS. UDDI è un sforzo di Microsoft, IBM, Ariba, 
CommerceOne, Accenture e altri.  Esso affonda le sue radici in Discovery of Web 
Services (DISCO) di Microsoft e Advertisement and Discovery of Services (ADS) 
di IBM.  
1. Gli standard dei Web Services  
 22 
La proposta di UDDI è di raccogliere definizioni di WS registrarle e pubblicarle. Un 
repository UDDI gestisce informazioni circa i tipi di servizio e cosa il servizio offre, 
rendendo queste informazioni accessibili attraverso un ben definito protocollo per 
client WS.  
La specifica UDDI è un formato per la registrazione di un business, un API per 
l’accesso SOAP e le regole per operare col registro. A ogni servizio è associato un 
identificatore unico chiamato tModel. Un tModel punta a una specifica che 
definisce una risorsa. 
È possibile cercare un servizio specifico in un registro attraverso le pagine bianche 
UDDI, dove l’identità base e le informazioni per il contatto possono essere trovate. 
Le pagine gialle UDDI categorizzano business e servizi per tassonomia.  Ogni 
categorizzazione aiuta i consumatori a trovare un particolare servizio che fa 
matching con i requisiti della richiesta. Le pagine verdi UDDI offrono i dettagli di 
binding per un servizio. Permettono di accedere al WSDL del servizio. 
UDDI può essere utilizzato all’interno delle organizzazioni come un singolo luogo 
dove pubblicare e trovare ogni servizio disponibile.  Ma può essere altresì 
utilizzato nel Web pubblico . Questa visione di UDDI richiederà un lungo periodo di 
tempo per verificarsi perché i WS hanno un valore intrinseco che non possiamo 
definire free o open per i suoi potenziali utenti. Questi saranno soggetti a contratti, 
pagamenti, responsabilità, l’ordinamento di questi dal punto di vista contrattuale e 
legislativo è un processo complesso. Alla fine, questo modello garantirà la 
negoziazione automatica dei contratti e alta sicurezza. 
La sicurezza è un punto critico per i registri UDDI. Per esempio chi è autorizzato a 
pubblicare, usare ed eseguire l’update delle descrizioni dei WS? Le relazioni di 
business richiedono fiducia. Senza una trust relationship non è possibile entrare in 
transazioni.  L’autenticazione e l’autorizzazione degli editori e dei richiedenti e le 
loro autorità di accesso ai servizi offerti deve essere esplicitata e indirizzata da 
UDDI, specialmente quando viene usato su Internet pubblico. 
UDDI cerca di accordare tutte queste necessità con l’ausilio di forti standards di 
sicurezza  che discuteremo nei Capitolo 5,6 e 7.  
Sussistono diversi dubbi sulla sua affermazione a livello globale ma come una 
directory interna di WS UDDI potrebbe eccellere. Il miglior modo per le 
organizzazioni di attuare il riuso dei componenti WS.