Il fatto che i messaggi utilizzati nella realizzazione dell'architettura WebServices vengano incapsulati all'interno di richieste e risposte http rende estremamente facile l'utilizzo di tale metodo di integrazione sistemi anche dove siano presenti firewall ed altri dispositivi per la sicurezza delle reti. Oltre questo e' del tutto gratuito spostare le comunicazioni in ambienti sicuri utilizzando https (quindi sfruttando i vantaggi di SSL) anziche' http.
REF : www.uddi.org
Tramite UDDI viene effettuata una fase cruciale della vita con i WebServices : la registrazione ed il discovery. A tutti gli effetti un UDDIrepository si comporta come un database in cui vengono registrate aziende e servizi affinche' gli utenti e gli sviluppatori sia in grado di cercare, recupera ed utilizzare i servizi effetivametne necessari.
Durante la fase di Inquery (richiesta) ci si puo' muovere per Busines, Service o tModel, qua sotto e' riportata la struttura che lega tali aspetti :
|
|
|
|
Un esempio di struttura del messaggio :
|
La BusinessEntry rappresenta l'azienda che ha servizi da offrire e quindi e' presente nel repository. Una volta effetuata la query si ritrovano nella risposta la lista dei businessServices che tale azienda espone sulla rete ed una serie di proprieta' tra cui la firma digitale. Per ogni BusinessService si puo' leggere il tModel che ne espone una serie di specifiche relative al servizio ed il proprio design.
 |
 |
In definitiva le operazioni relative ad UDDI ed UDDI repository si restringono a query e registrazionedi Aziende, Servizi e tModel.
REF : www.w3.org/TR/wsdl
WSDL e' il linguaggio con cui viene formulata la descrizione del servizio presente nel tModel ricevuto nella query al repository UDDI. Spesso pero' si ottiene dalla query solo l'URL a cui andare effettivamente a recuperare la descrizione voluta.
In ambiente .NET non esiste fisicamente il file wsdl ma al momento della richiesta (una cosa simile a http://[businessUrl]/[SeriveUrl]?wsdl) e' IIS a generare il tModel utilizzando la Reflection ed i metadati contenuti nell'assembly che realizza le funzionalita' desiderate. Cosa che serve per economizzare spazio sia nel repository UDDI che nel VirtualHost dato che i file wsdl sono in plain text e generalmente lunghi.
WSDL risponde ad un preciso SCHEMA.
Un esempio di documento WSDL preso dal sito del w3c :
|
REF : www.w3.org/TR/SOAP
SOAP e' il protocollo per l'accesso e l'invocazione dei metodi pubblicati nei webservices.
Uno dei vantaggi dell'essere dotato di relativo MIME risiede nel fatto che il messaggio puo' essere incluso sia in HTTP che nei protocolli relativi alla posta elettronica. Cio' significa che si puo' effettuare una richiesta via HTTP e, invece di attendere al conclusione del metodo invocato, attendere la ricezione di una mail con allegato il risultato dell'elaborazione.
Ammettiamo infatti che si faccia richiesta di elaborazione ad un determinato URL; per motivi di loadbalancing il server potrebbe delegare ad un altro host l'effettiva esecuzione del metodo, a questo punto il nostro client passa in attesa liberando il servizio e controlla periodicamente la posta con i protocolli adeguati. Al termine dell'operazione l'host che ha esaudito al nostra richiesta invia al nostro client la risposta tramite E-Mail, esso al riceve e prosegue nel task affidato.
In un messaggio SOAP sono presenti tre parti fondamentali :
SOAP e' in grado di rapprensentare i tipi ( sai base che derivati ) ed i metodi attraverso la parte Body del messaggio e con una serie di Tag preposti, questa e' la parte fondamentale del protocollo perché qui si realizzano sia RPC che il trasporto dell'oggetto con i propri valori da un sistema all'altro.
REF : www.w3.org/XML
L'utilizzo di XML come "formato di rappresentazione" dei messaggi e degli ogetti consente un alto grado di liberta' e di interoperabilita' tra sistemi e linguaggi diversi. Questo e' possibile grazie al fatto che tramite XML si riesce a descrivere in maniera strutturale e tipata gli oggetti trasmessi ed irelativi valori.
Ovviamente lo scotto che si paga e' un elevato payload dovuto alla trasmissione in plain text dei messaggi. Sui dispositivi mobili la cosa puo' diventare non accettabile se si considera che per circa 300 k di dato da trasmettere si puo' raggiungere una dimensione del emssaggio di circa 2700k.