In collaborazione con
Protocolli e Strumenti
I Web Services sono Componenti Software accessibili attraverso i normali protocolli in uso su Internet (HTTP, XML, SMTP, ecc...).
Il modello dei Web Services non si pone in concorrenza con le tradizionali architetture a componenti (CORBA, COM+, EJB) ma le affianca, permettendo di esporre componenti già esistenti verso nuovi client, scritti magari con linguaggi diversi ed operanti su architetture diverse.
La forza del modello dei Web Services è di utilizzare un set base di protocolli disponibili ovunque, permettendo l'interoperabilità tra piattaforme molto diverse e mantenendo comunque la possibilità di utilizzare protocolli più avanzati e specializzati per effettuare compiti specifici.
I protocolli alla base del modello dei Web Services sono quattro:
-
XML è lo standard usato per rappresentare i dati trasportati
-
SOAP è lo standard usato per definire il formato dei messaggi scambiati
-
WSDL è lo standard usato per descrivere i parametri, i metodi ed i valori di ritorno dei servizi
-
UDDI è lo standard promosso dall'omonimo consorzio, e serve per rintracciare i servizi sulla rete.
Non ci soffermeremo sui pregi di XML, basta solo ricordare i dati trasportati.
SOAP, il protocollo per il messaging e le Remote Procedure Call
SOAP è un protocollo che specifica come formattare i dati in formato XML, dati che possono essere messaggi, o chiamate di procedure remote.
SOAP prevede un formato standard per l'encoding dei dati, che può comunque essere esteso a piacere e definisce come usare i protocolli come HTTP, SMTP, e altri per il trasporto dei dati stessi. Utilizzando SOAP con HTTP si mette la richiesta SOAP nel messaggio di richiesta HTTP, e la risposta può essere il solo codice di stato HTTP 200 (che indica che tutto è andato bene) o un messaggio SOAP più dettagliato contenente i valori di ritorno. Anche in caso di errore si può inviare il solo codice di stato HTTP 500 (Internal Server Error), o si può inviare un messaggio SOAP con la descrizione dettagliata del codice di errore.
SOAP è stato sottoposto l'anno scorso al W3C da Microsoft e IBM per essere standardizzato. La versione 1.1 è la versione attuale, mentre la 1.2 è quella su cui sta attualmente lavorando il W3C.
SOAP significava Simple Object Access Protocol, ma dalla versione 1.2 non è più un acronimo.
WSDL, l'IDL dei Web Services
WSDL ovvero Web Services Description Language è il linguaggio utilizzato per descrivere i Web Services.
Attraverso il WSDL è possibile sapere il formato dei messaggi da inviare al Web Service, quali sono i metodi esposti, quali sono i parametri ed i valori di ritorno. È l'equivalente del linguaggio IDL usato da COM e CORBA per definire le interfacce.
UDDI, le pagine gialle dei servizi WEB
Universal Discovery, Description ed Integration (
http://www.uddi.org) è un consorzio a cui partecipano quasi 300 aziende che ha come scopo quello di favorire lo sviluppo, la scoperta e l'interoperabilità dei servizi Web. UDDI fornisce un database distribuito su cui si possono registrare le aziende ed i servizi da loro esposti.
L'interrogazione del database può essere fatta con il browser (ad esempio su uddi.microsoft.com) o tramite SOAP.
Realizzazione di un Web Services
Esistono due approcci per lo sviluppo di un Web Service, prendere un componente esistente e trasformarlo in un Web Service o scriverne uno apposta.
Se un componente esiste già si può cercare un Toolkit esistente che permette con poco sforzo di creare il wrapper SOAP per esporlo come Web Service. A seconda della completezza del Toolkit, può anche essere generato automaticamente il file WSDL ed eventualmente il componente può essere registrato automaticamente su un server UDDI (pubblico o privato).
Se bisogna costruire un Web Service da zero si può scriverlo come se fosse un componente normale e seguire l'approccio precedente, oppure scrivere direttamente un componente con un'interfaccia SOAP e file WSDL associato.
Strumenti e Toolkit
Esistono molti Toolkit disponibili sul mercato per semplificare la realizzazione e/o l'utilizzo di Web Services, ma i più diffusi sono:
-
Microsoft SOAP Toolkit 2.0 - È un Toolkit che fornisce interfacce di alto e basso livello che permettono di realizzare Web Services e di invocarli. Sono disponibili esempi ed un Wizard per esporre componenti COM già esistenti utilizzando IIS come Web Server e generando automaticamente anche il file WSDL
-
Microsoft Visual Studio.NET e .NET Framework - Il nuovo ambiente Microsoft nasce con lo scopo di favorire lo sviluppo e la diffusione dei Web Services. La realizzazione di Web Services in questo ambiente è immediata come quella di creare delle normali classi
-
Apache SOAP Toolkit e AXIS - Sono due toolkit per Java che permettono lo sviluppo e l'utilizzo di Web Services. Il SOAP Toolkit è ottimo come prodotto SOAP, ma non dispone di tool per la lettura e generazione di file WSDL. AXIS è la nuova versione che li supporta ma è ancora in fase di sviluppo
-
IBM Web Services Toolkit - È basato sul Toolkit Apache e lo estende fornendo il supporto per i file WSDL e per l'utilizzo di UDDI.
Interoperabilità ed evoluzioni future
I Web Services sono nati soprattutto per superare i problemi di interoperabilità tra le normali architetture a componenti. Questo scopo non è ancora stato completamente raggiunto a causa della giovinezza degli standard, dalla mancanza di standardizzazione e dell'assenza di implementazioni di riferimento.
Attualmente l'XML Protocol Working Group è ancora al lavoro, e ha prodotto il Working Draft delle specifiche SOAP 1.2.
Esistono vari tipi di problemi che possono pregiudicare la comunicazione tra le varie implementazioni, ma sono raggruppabili in problemi che riguardano il file WSDL, il protocollo SOAP, e il protocollo di trasporto.
Problemi legati al WSDL
Non tutti i toolkit supportano XML Schema in versione 2001 (l'unico che è una Raccomandazione del W3C) nel file WSDL. Alcuni sono fermi alle versioni 1999 o 2000.
I tipi di base tra le varie versioni sono quasi identici e se si è fortunati basta cambiare la versione di XML Schema nel file WSDL. Altrimenti bisogna riscrivere il file WSDL, almeno per quanto riguarda i tipi. Questo problema è presente in tutti i toolkit di qualche mese fa, comprese alcune versioni del toolkit di IBM, ma ora è stato risolto. Il SOAP Toolkit 2.0 di Microsoft non ha questo problema.
Alcuni toolkit, tra cui il SOAP Toolkit 2.0 di Microsoft, non supportano file WSDL che importano altri file. In questo caso bisogna riunire i file in un file unico, magari utilizzando un programma scritto ad hoc, in attesa che il problema venga risolto. Il problema è che alcuni toolkit, come quello di IBM, generano file WSDL solo in questa modalità, rendendosi incompatibili.
In entrambi i casi la necessità di modificare il file WSDL pregiudica la portabilità del Web Service.
Problemi legati a SOAP
Non tutti i toolkit supportano gli stessi tipi di dati. Questo problema esiste solo nell'utilizzo di interfacce ad alto livello (quelle che leggono il WSDL e generano il codice proxy corrispondente). Ad esempio l'oggetto SoapClient del SOAP Toolkit di Microsoft supporta solo i tipi compatibili Automation (i tipi di Visual Basic), mentre il Web Services Toolkit di IBM non supporta alcuni tipi che invece vengono supportati nativamente dal toolkit Apache.
In questo caso bisogna o utilizzare le interfacce a basso livello o modificare il codice prodotto per adattarlo allo specifico caso.
Anche utilizzando interfacce a basso livello si può andare incontro a delle incompatibilità sui tipi supportati.
Un altro problema sempre legato ai tipi di dato è dovuto al fatto che le specifiche di SOAP 1.1 sono antecedenti ad XML Schema 2001. Esistono alcuni punti della specifica SOAP che non sono completamente congruenti con XML Schema.
Problemi legati al protocollo di trasporto
In alcuni casi i problemi sono a livello di protocollo HTTP, in quanto non tutti i toolkit (soprattutto quelli minori) supportano header HTTP particolari (richiesti da SOAP) e non tutti riescono a stabilire connessioni HTTPS (criptate con SSL) richieste per motivi di sicurezza da alcuni Web Service.
Se ci si affida ai toolkit più diffusi (Apache, Microsoft, IBM) il supporto è garantito, e per gli altri toolkit potrebbe essere solo una questione di tempo.
Evoluzioni future
Il modello dei Web Services è ancora molto giovane, quindi molti punti importanti presenti nelle architetture più diffuse sono ancora in attesa di una definizione e/o standardizzazione.
Ad esempio la gestione della sicurezza, dell'autenticazione, delle transazioni, dell'interazione fra più componenti, sono ancora tutte da definire e standardizzare.
Esistono alcuni protocolli che sono stati proposti per risolvere questi problemi:
-
XML Signature e SOAP-DS (SOAP Digital Signature) - Sono protocolli per la gestione di messaggi XML e SOAP con firma elettronica, per garantire l'integrità dei messaggi e la loro provenienza
-
SOAP with Attachments - È un protocollo per la gestione degli allegati per messaggi SOAP
-
XAML - È un protocollo basato su XML per la gestione di transazioni utilizzanti lo schema Two-Phase Commit
-
WSFL e XLANG - Sono protocolli per la gestione del workflow di componenti e la gestioni di transazioni utilizzanti il metodo della compensazione
-
XML Encryption - È un protocollo per la cifratura di documenti XML.
Nessuno di questi protocolli è ancora uno standard affermato, sono solo proposte più o meno supportate.
XML Signature e XML Encryption sono in corso di approvazione da parte del W3C.
Discuti sul forum
Stampa
![[LM]](../../../images/skin/default/icons/lm_sm.png){kind=icon}
.
Made with GIMP
& WPP.