3. Web Services

3. Web Services

L’obiettivo dei web services (servizi web) è la realizzazione di un ambiente distribuito grazie a cui tutti i componenti applicativi possono comunicare ed interagire tra loro senza problemi, il tutto in maniera indipendente dalle piattaforme e dai linguaggi di programmazione.

Secondo la (23) un servizio web è un elemento funzionale disponibile da Internet tramite i protocolli come HTTP e SMTP.

Un servizio web può rappresentare qualsiasi servizio come un accesso tramite login, una richiesta di un informazione (come il costo di un prodotto), oppure la chiamata di un’operazione remota (RPC).

Concettualmente la tecnologia dei web services non è molto dissimile da CORBA e CGI, la maggiore differenza sta nell’utilizzo del linguaggio XML al posto di altri linguaggio proprietari.

Essendo XML capace di rappresentare i dati indipendentemente dallo piattaforma utilizzata, nel corso degli anni tutti i principali linguaggi hanno dato realizzato un supporto ai web services.

In generale, secondo la (23), è possibile sintetizzare le caratteristiche dei web services nel seguente modo:

 l’utilizzo di XML come linguaggio di rappresentazione dei dati permette l’interoperabilità eliminando cosi tutte le specificità dovute alla piattaforma alla rete utilizzata ed al linguaggio di programmazione

 non è strettamente correlato (loosely coupled) in quanto l’interfaccia di un servizio web può evolversi nel tempo senza compromettere la capacità del client di interagire con il servizio stesso.

 indipendenza dal firewall grazie all’utilizzo del protocollo HTTP per il trasposto di messaggi, che permette di non dover modificare le regole di accesso dei firewall

 è di grana grossa (coarse grained) perché fornisce un metodo naturale per la definizione dei servizi

 può essere asincrono o sincrono (dove per sincronia si intende il legame di un client durante l’esecuzione di un servizio)

 supporto per RPC (Remote Procedure Calls) visto che dispone sia di parametri di ingresso che di uscita.

 possibilità di scambio di documenti grazie all’utilizzo di XML

Gli svantaggi della tecnologia dei web services sono i seguenti:

 non esistenza di standard consolidati per l’applicazione di transazioni distribuite

 performance minori rispetto ad approcci di distributed computing quali JAVA RMI, DCOM o CORBA

 insicurezza dovuto all’uso di HTTP che evita il firewall

3.1 Introduzione ai Web Services

Nel corso degli anni sono state proposte diverse tecnologie per l’utilizzo di web services, ma quella che allo stato attuale è maggiormente affermata sul piano mondiale si compone da nel seguente modo:

1. il protocollo SOAP (inizialmente acronimo di Simple Object Access Protocol, anche se dalla versione 1.2 il significato di SOAP è SOAP) che fornisce una struttura di incapsulamento per il trasporto di documenti XML attraverso i protocolli Internet standard quali SMTP, HTTP e FTP.

2. Il linguaggio WSDL (Web Service Description Language) tecnologia XML che permette la descrizione dell’interfaccia di un servizio Web, permette inoltre la presentazione delle chiamate nonché dei parametri d’ingresso e d’uscita e dei rispettivi tipi (testo, numero, data gregoriana, dati binari, etc).

3. I servizi UDDI (Universal Description, Discovery and Integration) che fornisce un registro a livello mondiale per promuovere la pubblicazione, la ricerca e l’integrazione di servizi Web.

Queste tre tecnologie permettono quindi la creazione di applicativi che sono in grado di ricercare, accedere, integrare e richiamare dinamicamente ed autonomamente nuovi servizi offerti.

Ovviamente non è la prima volta che vengono create tecnologie che offrono queste possibilità, ma l’introduzione di XML rendono i web services di base molto flessibili ed adatti a supportare pure infrastrutture di business dinamici.

La relazione tra le tre tecnologie può essere cosi illustrata:

Figura 10: Raffigurazione della tecnologia dei web services

Il client di un servizio Web rintraccia servizio, tramite un registro UDDI, effettuando una ricerca per nome, categoria, identificativo o specifiche.

Come risultato ottiene le informazioni sulla posizione di un documento WSDL, che contiene le modalità di connessione.

Il client creerà un messaggio SOAP conforme allo standard WSDL e invierà una richiesta all’host che risponde al servizio.

La tecnologia dei web services trovano impiego nelle architetture altamente distribuite ed orientate ai servizi come SOA (Service Oriented Architecture) (21).

I web services, infatti, possono comunicare sia come un processo autonomi che come parte di uno più complesso ed organizzato.

Per esempio possono offrire servizi semplici come un cambio valuto, un calcolo del codice fiscale, oppure applicazioni di ricerca di ristoranti per client mobili.

Il servizio può essere visto come elemento modulare autonomo (self-contained) e definito in ogni particolare (self-describing) e quindi anche come parte di un sistema di dimensioni più ampie.

Ovviamente le caratteristiche dei web service, rendono tale tecnologia molto importante in ambito aziendale perché permette di risolvere classici problemi d’integrazione tra varie applicazioni d’impresa EAI (Enterprise Application Integration).

3.2 Il protocollo SOAP

Come descritto nel paragrafo precedente, il protocollo SOAP fornisce la struttura di incapsulamento per il trasporto dei documenti ed assume ruoli diversi a seconda del contesto di utilizzo, infatti viene usato sia per lo scambio di documenti che per il meccanismo RPC (Remote Procedure Call).

Nel protocollo SOAP, essendo derivato dall’XML, tutte le informazioni vengono descritte in chiaro, tramite una serie definita e documentata di convenzioni.

Quindi teoricamente due piattaforme software che vogliono comunicare tramite SOAP devono essere in grado di:

 inviare e ricevere datti attraverso HTTP e SMTP

 costruire e decodificare allegati binari secondo la codifica MIME (Multipurposer Internet Mail Extension)

 costruire e decodificare documenti XML in base alle regole di imbustamento (enveloping) della codifica SOAP

3.2.1 Analisi di un messaggio SOAP

Le specifiche SOAP descrivono quattro elementi principali:

 convenzioni di formattazione di incapsulamento e instradamento dei dati sotto forma di envelope (busta)

 collegamento a un tipo di trasporto o di protocollo

 regole di codifica

 meccanismo di RPC

Si seguito verranno esaminate le fasi dell’imbustamento (enveloping) di un messaggio XML (io.xml), contente dati personali, che simula la richiesta del codice fiscale di una persona <?xml versione=”1.0” encoding=”UTF-8”> <codfis xmlns=”urn:example-codice-fiscale”> <data> <name>Davide</name> <surname>Gazzè</surname> <city>Siracusa</city> <date>24/09/1983</date> <sex>M</sex> </data> </codfis>

Il file io.xml è il file base su cui costruire il documento SOAP, le operazioni da eseguire per il passaggio sono le seguenti:

1. inserimento del codice XML all’interno del body SOAP 2. inserimento del body SOAP all’interno di un envelope SOAP 3. inclusione facoltativa di intestazione SOAP

4. dichiarazione dei namespace 5. direttive per lo stile

L’envelope soap è principalmente costituito da due componenti essenziali: 1. header

2. body

Ognuno di questi, a sua volta, possono contenere altri blocchi d’informazioni, cosi come illustrato nella figura successiva:

Figura 11: Envelope SOAP

Il documento SOAP, in seguito dell’imbustamento, è il seguente:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol"> <n:priority>1</n:priority> <n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env:Header> <env:Body> <codfis xmlns=”urn:example-codice-fiscale”> <data> <name>Davide</name> <surname>Gazzè</surname> <city>Siracusa</city>

<date>24/09/1983</date> <sex>M</sex> </data> </codfis> </env:Body> </env:Envelope>

L’envelope SOAP è il tag XML più esterno, chiamato envelope, stabilisce l’inizio e la fine del documento SOAP.

L’intestazione ed il body SOAP sono delimitati rispettivamente dai tag header e body. Siccome le versioni di protocollo SOAP 1.1 e SOAP 1.2 non stabiliscono convenzioni sul contenuto dell’intestazione, i partecipanti alla comunicazione devono accordarsi sugli elementi da inserire nell’intestazione e sul loro significato.

Questo genere di comportamento non è solitamente adottato da altri protocolli basati su SOAP, infatti ebXML Message Service stabilisce formati specifici per l’intestazione SOAP, come il tag <MessageHeader> che contiene, a sua volta, tag come <From>, <To> e <MessageId>.

Il body SOAP è riservato ai dati veri e propri che costituiscono il “contenuto informativo”. Nell’uso di SOAP per le procedure di RPC, la definizione di intestazione e body non cambia; il tag <body> è riservato esclusivamente per la chiamata del metodo e i relativi parametri, mentre <header> viene usato per le informazioni destinate all’infrastruttura sottostante, come, per esempio, il codice identificativo di transazione.

L’envelope SOAP non specifica tutte le informazioni necessarie per la comunicazione, infatti sono mancanti le specifiche richieste dal protocollo con il quale SOAP è stato messo in relazione.

L’elenco seguente mostra le informazioni inserite in testa a un messaggio SOAP collegato al protocollo HTTP:

SOAPAction = “urn:soaphttpclient-action-uri” Host = localhost

Content-Type = text/xml; chaeset=utf-8 Content-Length = 164

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

…

</env:Envelope>

Il termine SOAPAction è obbligatorio nel caso di utilizzo di SOAP 1.1, mentre diventa inusuale in SOAP 1.2 in quanto ritenuto come estensione del protocollo sottostante.

3.3 I servizi UDDI

Il progetto UDDI (24) (Universal Description, Discovery and Integration) fornisce una metodologia standard per la pubblicazione e la ricerca di informazioni sui servizi Web. Si tratta di un’iniziativa, secondo la (23), di mercato che mira a creare un “framework aperto e indipendente dalla piattaforma per descrivere servizi, individuare aziende e attività commerciali utilizzando Internet”.

La nascita di UDDI è essenzialmente dovuta all’utilizzo dei Web Service per il commercio elettronico, infatti le aziende utilizzano i servizi offerti da altre aziende per portare a termine le proprie transazioni commerciali.

La ricerca manuale dei possibili partner commerciali non è una via praticabile, sia per il numero (che può risultare elevato) che per i possibili errori che si possono effettuare. Prima del progetto UDDI non esisteva alcun approccio di mercato per rendere la aziende raggiungibili dai propri clienti e partner con informazioni sui prodotti e servizi web.

Un’azienda concettualmente può registrare su un registro UDDI tre tipi diversi d’informazioni, queste sono:

 pagine bianche (white pages) che comprendono le informazioni di base sui contatti, sull’identificativo dell’azienda come la ragione sociale, l’indirizzo e la partita IVA che

quindi permettono di rintracciare il servizio web a partire dagli identificativi dell’azienda.

 pagine gialle (yellow pages) che comprendono le informazioni su un servizio web in base a tassonomie standardizzate, per consentire ad altri utenti di localizzare un tipo di servizio.

 pagine verdi (green pages) che si riferiscono alle informazioni tecniche delle funzioni rese disponibili dal servizio Web ospitato dall’azienda, quindi tra esse vengono menzionate i puntatori alle informazioni di raggruppamento dei servizii web oltre che alle istruzioni per la localizzazione.

Si può concludere affermando che UDDI è stato progettato per essere interrogato da messaggi SOAP al fine di fornire collegamento a documenti WSDL, quindi sta logicamente alla base del funzionamento dei web service.

Nella seguente figura illustra il processo di realizzazione del progetto UDDI.

Figura 12: Servizi UDDI

L’UBR (UDDI Business Registry) è un archivio pubblico, distribuito su vari nodi, nel quale i dati sono sincronizzati meditante copie del servizio (replication), che sono ospitate da ciascun nodo tra quelli scelti dall’operatore.

Viene definito UBR l’insieme dei nodi pubblici, la copia dei contenuti garantisce che l’accesso a un qualsiasi nodo metta a disposizione le stesse informazioni e la medesima qualità di servizio di qualsiasi altro nodo.

L’inserimento di un contenuto in un UBR viene eseguito su un singolo nodo che diviene così il possessore primario di quel contenuto (master owner) su cui si dovranno effettuare le operazioni di aggiornamento o di annullamento.

Si noti che UDDI non si limita agli UBR, infatti è possibile che un’azienda metta a disposizione un web service al di fuori dell’UBR e quindi creare una serie di nodi privati. UBR offre una serie di servizi d’interrogazione ampiamente accessibili, che possono essere pubblicati soltanto da entità autenticate.

Le specifiche UDDI prevedono due API:

 inquiry API (API d’interrogazione)

 publishing API (API di pubblicazione)

La modalità d’accesso è la medesima per entrambe, ma sono utilizzati documenti XML, strutture dati e punti di accesso diversi.

Le inquiry API reperiscono le informazioni e la gestione degli errori relative a un’attività commerciale o a un servizio.

Tutte le informazioni di lettura fatte su un nodo UDDI utilizzano un messaggio delle API di tipo inquiry che non prevedono procedure di autenticazione e che utilizzano il protocollo HTTP.

Le publishing API sono usate per creare, conservare e aggiornare le informazioni contenute in un registro UDDI, queste API richiedono autenticazione di accesso.

3.4 Il linguaggio WSDL

Come descritto nei paragrafi precedenti, il protocollo SOAP ed UDDI permettono la possibilità di inviare e ricevere informazioni oltre che ricercare dei web services, ma questa struttura è incompleta se non accompagnata ad un sistema di descrizione delle informazioni operative (23), il linguaggio WSDL (pronunciato “wiz-dal”) fa questo.

Infatti esso è una grammatica XML che si propone di descrivere un servizio web come una serie di punto di accesso (access endpoint) che è rappresentato dall’URL a cui indirizzare le richieste di servizio (25), quindi un documento WSDL permette di automatizzare le procedure di comunicazione tra applicazioni.

Il linguaggio WSDL è, sotto un certo punto di vista, analogo a CORBA IDL (Interface Definition Language) o Microsoft IDL, in quanto permette di definire i tipi di dato, le interfacce e le firme dei metodi relativi ad una porzione di codice.

Le funzioni che il linguaggio WSDL permette di effettuare sono le seguenti:

 descrizione degli endpoint ed i loro messaggi indipendentemente dal formato e dal protocollo di rete utilizzato

 esatta descrizione dei dati da scambiare

 trattazione dei tipi di porta come collezioni astratte di operazioni di un servizio web

Più nello specifico un file WSDL specifica i parametri e i vincoli che stabiliscono le modalità di svolgimento della comunicazione ed i collegamenti ai protocolli (come SOAP, GET di HTTP, POST di HTTP e MIME).

Siccome il linguaggio WSDL fornisce una descrizione astratta dell’interfaccia Web, per questo è possibili pensare alla generazione di codice d’implementazione del servizio partendo dal documento di descrizione, oppure il suo viceversa.

Ovviamente questo indubbio vantaggio ha fatto si la realizzazione di strumenti per la generazione di descrizioni WSDL partendo da componenti esistenti.

3.4.1 Struttura di un documento WSDL

Di seguito vengono elencati i tag principali di un documento WSDL, l’utilizzo del simbolo “*” indica che il tag può essere presente più volte.

<definitions> <import></import>* <types> <schema></schema> * </types> <message> * <part></part> * </message> <portType> * <operation> * <input><input/> <output></output> </operation> </portType> <binding> * <operation> * <input></input> <output></output> </operation> </binding> <service> * <port></port> </service> </definitions>

Come definite su (23), la struttura sopra presente definisce tutti gli aspetti del servizio che si intende esportare.

La descrizione avviene su due livelli:

 astratto dove viene definito il servizion in termini di operazioni offerte (interfacce), tipo di messaggi , etc.

 concreta che permette l’istanziazione delle descrizioni astratte in termini di protocollie indirizzi di rete

Il linguaggio WSDL separa, quanto più possibile, gli aspetti “astratti” da quelli “concreti” che lo legano a particolare protocolli di rete o RPC.

Questo modo di agire su due livelli porta ai seguenti vantaggi:

1. possibilità di avere più implementazioni diverse di una stessa descrizione astratta. 2. riutilizzo di descrizioni astratte per la descrizione di nuovi servizi.

3.4.2 Elemento <definition>

L’elemento <definition> contiene la descrizione del servizio e tutte le dichiarazioni dei namespaces utilizzate all’interno del documento.

Si noti che alcuni namespace possiedono un prefisso (xsd, soap, soapenc, xer, etc.) mentre altri ne sono privi, di seguito un esempio di definizione per un web service d’esempio: <definitions targetNamespace="urn:prova" xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:SOAP-ENC=”http://schemas.xmlsoap.org/soap/encoding/” xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/” xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/” xmlns=”http://schemas.xmlsoap.org/wsdl/” xmlns:tns="urn:prova" >

Per una comprensione di questo elemento occorre specificare che non tutti i namespace sono reali, in quanto sebbene sia prassi far corrispondere il documento di schema XML, a cui si riferisce l’URI, ad un URL reale, non sempre questa consuetudine viene rispettata. L’attributo targetNamespace specifica la definizione di namespace che il documento sta creando, esso viene utilizzato al posto dell’attributo del nome.

Il namespace di destinazione crea un nuovo identificativo univoco, al cui interno è inserito qualsiasi tipo di dato o definizione astratta contenuta nel documento e deve essere un riferimento assoluto.

3.4.3 Elemento <import>

L’elemento <import> svolge un azione simile alla direttiva #include dei linguaggi di programmazione C e C++, infatti permette di ripartire gli elementi della definizione di un servizio in documenti indipendenti da includere, all’occorrenza, nel documento principale. L’utilizzo appropriato dell’elemento <import> rende il documento WSDL modulare e semplifica la definizione di nuovi servizi mediante il riutilizzo di elementi già presenti. Un esempio di import è il seguente:

<import namespace=”http://asf.gils.net/xer”

location=”http://asf.gils.net/xer/ez.xsd”/>

3.4.4 Elemento <types>

L’elemento <types> di un documento WSDL indica I tipi di dati usati all’interno degli elementi <message>.

Per la definizione dello schema viene utilizzato la definizione di schema XML (XSD : XML Schema Definition).

Nell’esempio seguente viene rappresentato uno schema di un ipotetico web service di anagrafe, dove il tipo “PersonInfo” rappresenta le informazioni anagrafiche di una persona:

<types> <xsd:schema targetNamespace="urn:anagrafe"> <xsd:import namespace="http://schemas.xmlsoap.org/soap/encoding/"/> <xsd:import namespace="http://schemas.xmlsoap.org/wsdl/"/> <xsd:complexType name="PersonInfo"> <xsd:all>

<xsd:element name="nome" type="xsd:string"/> <xsd:element name="cognome" type="xsd:string"/>

<xsd:element name="comuneNascita" type="xsd:string"/> <xsd:element name="dataNascita" type="xsd:string"/> <xsd:element name="sesso" type="xsd:string"/>

</xsd:all> </xsd:complexType> </xsd:schema>

</types>

Per la definizione di nuovo tag vengono offerti nuovi elementi come <simpleType> e <complexType>. Mentre il primo si riferisce al formato di un singolo elemento, il secondo descrive un elemento composto da altri (concettualmente analogo alle strutture dei linguaggi di programmazione).

Per ogni elemento semplice viene definito un tipo base (analogo del concetto di tipo di dato dei linguaggio di programmazione) che sono riportati nella seguente tabella in Appendice A. Per una trattazione più completa del XML schema si rimanda al riferimento (26) e (27).

3.4.5 Elemento <message>

L’elemento <message> descrive i dati scambiati nello svolgimento di un web service, quindi si fa esplicito riferimento ai tipi definiti nella sezione <types>.

I dati contenuti all’interno di questo elemento sono astratti.

Nello specifico l’elemento <message> si compone di uno o più sottoelementi <part> ciascuno di quali identifica il nome del parametro ed il tipo che lo compone.

Un esempio di <message> composto da un unico <part> è il seguente: <message name="example1">

<part name="dato1" type="xsd:string"/> <part name="dato2" type="xsd:int"/> </message>

Da quest’esempio si evince che il tipo messaggio è univocamente definite dall’attributo name (example1 nell’esempio sopra) e che comprende due sottoelementi “dato1” e “dato2” rispettivamente di tipo semplici string e int.

Da notare che i tipi utilizzati potrebbero anche essere definito nell’elemento <types> dello stesso documento WSDL, in questo caso la sintassi sarebbe:

<message name="example2">

<part name="return" type="tns:example_type"/> </message>

In questo caso il messaggio “example2” è di tipi complesso di nome “example_type”.

3.4.6 Gli elementi <portType> e <operation>

L’elemento <portType> specifica l’insieme di operazioni supportate dal web service e rappresenta il cosiddetto “endpoint”, in altre parole esso specifica il gruppo di azioni che possono essere eseguite.

L’elemento <operation> si riferisce alla descrizione astratta di un operazione e da un punto di vista logico è analogo alla definizione di un metodo di una classe.

Un’operazione può comprendere messaggi in ingresso, nel sottoelemento <input>, e messaggi di uscita nel sottoelemento <output>.

Entrambi questi elementi fanno riferimento a elementi <message> definiti nel paragrafo precedente.

Di seguito viene riportato un esempio di descrizione di portType di un’operazione di nome “example” con un messaggio d’ingresso di nome “tns:exampleRequest” ed uno d’uscita di nome “tns:exampleResponse”: <portType name="examplePortType"> <operation name="example"> <input message="tns:exampleRequest"/> <output message="tns:exampleResponse"/> </operation> </portType>

Le specifiche del WSDL definiscono diverse “primitive di transmissione”:

 request-response

 solicit-response

 one-way

 notification

Nel modello request-response il client inoltra una richiesta e aspetta la ricezione di un messaggio di risposta sincrono, in questo caso nella descrizione WSDL si hanno sia gli elementi <input> che <output> nel ordine descritto.

Nel modello solicit-response il servizio Web sollecita una risposta dal client ed attende una risposta, in questo caso nella descrizione WSDL appare prima l’elemento di <output> e poi quello di <input>.

Nel modello one-way l’operazione è unidirezionale, il client, infatti, invia un messaggio senza aspettarsi nessuna risposta. In questo caso, nel documento WSDL, è presente solo un messaggio di <input>.

Infine nel modello notification l’operazione è un notifica, quindi il servizio Web invia un messaggio unidirezionale senza attendere alcuna risposta. In questo caso, nel documento WSDL, è presente solo un messaggio di <output>.

3.4.7 Elemento <binding>

L’elemento <binding> costituisce la specifica del protocollo relativa a <portType>, quest’ultimo può essere definito tramite standard come HTTP, SOAP o MIME oppure con una propria.

La scelta del protocollo può essere definita dall’utilizzo del servizio stesso (per esempio SOAP supporta allegati al proprio interno)

Il tag <binding> attraverso i seguenti passi:

 definizione della definizione astratta delle operazioni, dei messaggi di ingresso e di uscita

 corrispondenza con il protocollo utilizzato dal servizio web per il trasporto La descrizione del tab <binding> esula da questa trattazione e quindi si rimanda a (27).

3.4.8 Elemento <service>

I tag descritti, fin ora, servono per la definizione dell’interfaccia astratta di un web service, per l’interfaccia concreta occorre specificare l’endpoint (URL) che fisicamente ospita il servizio.

Quest’operazione viene effettuata dal tag <service>, di cui viene mostrato un esempio:

<service name="example"> <documentation>

Io documento il servizio </documentation>

<port name="examplePort" binding="tns:exampleBinding"> <soap:address location="http://example.com"/> </port>

</service>

Di questo elemento si possono distinguere due sottoelementi ossia I tag : <documentation> e <port>.

Il primo, che è opzionale, da una descrizione del servizio, mentre il secondo è obbligatorio e con l’attributo “name” identifica univocamente il nome del servizio.

All’interno di questo elemento si trova l’attributo “binding“ che si riferisce alla descrizione astratta, inoltre l’elemento <port> ha un sottoelemento <soap:address> che fa parte dell’estensione SOAP e identifica l’URL nel quale è collocato il servizio Web (“http://example.com” nell’esempio sopra).

3.5 Utilizzo di web service su PHP

Dalla descrizione fin ora fatta, si evince che la tecnologia dei web services è molto potenti, quindi nel corso degli anni tutti i principali linguaggi di programmazione ne hanno dato un supporto.

Per quanto riguarda il linguaggio PHP, il supporto della tecnologia web service è stato introdotto nella versione 5 tramite classi di gestione per i messaggi SOAP ed il WSDL, esse sono:

Nome

della

classe

Descrizione

SoapClient

WSDL

SoapServer

descrizione WSDL

SoapHeader

SoapParam

SoapVar

servizio SOAP

Questa serie di classi può essere utilizzata sia in associazione con il linguaggio di descrizione WSDL, sia in maniera del tutto autonoma da essa.

A parte questo supporto nativo dei web services, esistono diversi framework che permettono l’utilizzo della tecnologia dei web services.

Tra questi quelli che risultano più complete e utilizzate sono: 1. WSO2 Web Services Framework for PHP

2. NuSOAP

La prima, scaricabile dal (29) permette la generazione di codice PHP dal WSDL e viene supportata dall’azienda WSO2 (specializzata in prodotti per l’utilizzo di web services oltre in altri prodotti).

La libreria NuSoap (30) nasce come progetto open source ed è raggiungibile sul loro sito http://sourceforge.net/projects/nusoap.

Essa, similmente alle classi di PHP permette la gestione di SOAP e di WSDL sia lato client che lato server, inoltre offre diverse librerie che permettono l’analisi del WSDL.

La libreria NuSOAP, allo stato attuale, non supporta la gestione di UDDI, esistono comunque molte altre classi esterne che permetto l’uso di UDDI, tra queste si ricorda il progetto opensouce phpUDDI raggiungile sul (31).

3.5.1 La scelta di NuSOAP

Tra le diverse librerie fin ora presentate, alla fine la scelta di utilizzo per l’estensione del content type Drupal con la tecnologia web services è ricaduta su NuSOAP (30).

Questa scelta è dovuta principalmente al grande utilizzo dalla libreria stessa in molteplici progetti, dalla semplicità con cui è possibile creare sia un client che un server ed dalle funzionalità di analisi di WSDL messe a disposizione.

Purtroppo, come verrà discusso nel quinto capitolo, l’analisi di WSDL di NuSOAP e tutt’altro che completo.

Altri punti a favore di NuSOAP sono la documentazione messa a disposizione dal sito, che risulta essere sufficientemente chiara.

Inoltre esistono diversi tutorial che permettono l’apprendimento di moltissimi aspetti della libreria in poco tempo.

Infine il carattere opensource della libreria e la notevole diffusione fa pensare che la libreria sarà supportata dalla community negli anni avvenire.

3.5.2 Confronto tra web services e xml-rpc

Come detto precedentemente, la tecnologia dei web services si pone come evoluzione dei precedenti protocolli analoghi vista l’adozione di XML che permette una maggiore generalità per la gestione della comunicazione.

Esistono, però, diverse tecnologie che permettono la comunicazione di dati tra sistemi diversi connessi in rete, ma visto l’eterogeneità dei dati da trattare, si è scelto di analizzare solo la tecnologia XML-RPC in quanto, sotto diversi aspetti, risulta del tutto analoga al protocollo SOAP.

XML-RPC (22) è una tecnologia multipiattaforma che permette di effettuare chiamate di procedure remote (RPC), utilizza XML per la codifica della richiesta e si appoggia al protocollo HTTP per la comunicazione vera e propria.

Nonostante la relativa semplicità, XML-RPC permette di trasmettere strutture dati complessi, in quanto presenta un sistema proprio di tipizzazione dei dati.

Tra le mancanze di XML-RPC si trovano: 1. non object oriented

2. insicuro

3. impossibilità di effettuare chiamate asincrone 4. impossibili di estendere i tipi base

5. mancanza di supporto di sessioni 6. impossibilità di spedire file allegati

Questi limiti mettono XML-RPC in una notevole posizione di svantaggio rispetto a SOAP, infatti data la natura del problema, l’utilizzo di una tecnologia più completa, giustifica appieno la complessità della tecnologia SOAP, che quindi rimane la scelta migliore.