Web Services

Un Web service è un sistema software progettato per supportare l'interoperabilità machine-to-machine su una rete. Ha un'interfaccia descritta in un formato leggibile da una macchina (specificamente WSDL). Altri sistemi interagiscono con il servizio Web in un modo previsto dalla sua descrizione WSDL usando messaggi SOAP, in genere trasmessi tramite HTTP in formato XML con altri standard web previsti per una architettura SOA. (definizione del W3C)

Cosa sono i Web Services

Le applicazioni client interagiscono con la componente di logica applicativa utilizzando un protocollo di trasporto ed una struttura dati ad-hoc molto spesso proprietaria e legata al linguaggio di programmazione utilizzato.

Architettura 3 tier

L’utilizzo dei web services consente di disaccoppiare l’invocazione del Client dalla logica applicativa interponendo uno strato che consente di esporre il servizio utilizzando un protocollo di trasporto e di struttura dati standard

Architettura basata su servizi

I Web Services solitamente utilizzano come: protocollo di trasporto HTTP

protocollo dati XML (SOAP)

HTTP è un protocollo semplice, leggero, robusto e ben tollerato anche dai sistemi di sicurezza più avanzati.

XML è un protocollo aperto e altamente versatile che ha permesso la definizione del protocollo SOAP che garantisce ricchezza espressiva, estendibilità, portabilità e facilità di comprensione.

Protocolli utilizzati

I web services sono creati da dei produttori, catalogati in un registro pubblico per poi essere ricercati ed utilizzati dai consumatori, secondo questi passaggi logici.

1. Il produttore costruisce il servizio e lo descrive

utilizzando il linguaggio WSDL, registra il servizio nel registry UDDI utilizzato per catalogare i servizi e basato su XML

2. Il consumatore cerca il servizio nel registro UDDI, ottiene la descrizione WSDL del servizio

3. Il consumatore dialoga con il WS utilizzando SOAP

Modello del servizio

Schema di interazione

SOAP Simple Object Access Protocol

SOAP è un protocollo leggero che permette di scambiare informazioni in ambiente distribuito:

SOAP è basato su XML.

SOAP gestisce informazione strutturata.

SOAP gestisce informazione tipata.

SOAP non definisce alcuna semantica per applicazioni o scambio messaggi, ma fornisce un mezzo per definirla.

Simple Object Access Protocol

Il principale svantaggio di SOAP è costituito proprio dalla sua natura testuale, che lo rende molto meno performante rispetto alle sue controparti binarie (CORBA e .NET Remoting).

SOAP non definisce semantiche per i dati e le chiamate, ma tramite l'uso dei Namespaces XML, SOAP permette di dichiararne la semantica usando grammatiche XML definite nei namespaces.

Svantaggi e potenzialità

Un messaggio SOAP è composto da: 1. Un elemento radice, envelope,

obbligatorio. Il namespace di SOAP viene dichiarato

all’interno di questo elemento

2. Un elemento header opzionale. Il suo scopo è quello di trasportare

informazioni non facenti parte del messaggio, destinate alle varie parti che il messaggio attraverserà per arrivare al suo destinatario finale.

3. Un elemento body obbligatorio. Questo elemento contiene il messaggio vero

e proprio.

Struttura SOAP

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cor="http://www.prometheo.it/corsoWS">

<soapenv:Header/>

<soapenv:Body>

<cor:helloRequest>

<nomeUtente>Andrea</nomeUtente>

</cor:helloRequest>

</soapenv:Body>

</soapenv:Envelope>

Esempio di richiesta SOAP

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cor="http://www.prometheo.it/corsoWS">

<soapenv:Header/>

<soapenv:Body>

<cor:helloResponse>

<echoUtente>Ciao Andrea</echoUtente>

</cor:helloResponse>

</soapenv:Body>

</soapenv:Envelope>

Esempio di risposta SOAP

SOAP non è altro che un documento XML che segue determinate regole.

Per maneggiare un documento SOAP si possono usare quindi gli stessi strumenti utilizzati per i documenti XML

Un documento SOAP deve rispettare le regole di formattazione e validazione

SOAP e XML

Un documento XML deve essere ben formato 1. deve iniziare con la dichiarazione: <? xml version=“1.0” ?>

2. deve avere un unico elemento radice.

3. tutte i tag che si aprono devono essere chiusi

4. se un elemento è vuoto, ossia non contiene nessun elemento di testo al suo interno, può essere anche rappresentato con una forma speciale di tag: <foto />

5. Si deve rispettare il maiuscolo/minuscolo (case-sensitive)

6. Tutti gli elementi debbono essere annidati propriamente

7. Tutti i valori degli attributi vanno espressi tra doppi apici.

Formattazione XML

Un documento XML deve essere valido cioè deve rispettare una “grammatica”, ossia deve rispettare una struttura ed una grammatica degli elementi che compongono i documenti scambiati.

E' possibile utilizzare come descrittore un DTD (Document Type Definition) o una maniera ancor più espressiva tramite un XML Schema (XSD)

Validazione XML

WSDL Web Service Definition Language

WSDL è un linguaggio di tipo XML per descrivere servizi di rete come un insieme di punti terminali operanti su messaggi contenenti informazione di tipo “documentale” o “procedurale”.

Solitamente viene creato dal produttore del servizio al fine di esporre le modalità di invocazione (endpoint, protocollo, operazione, parametri di input/output) e successivamente viene pubblicato nel registry UDDI al fine della visibilità in rete.

Web Service Definition Language

WSDL cerca di separare gli aspetti “astratti” della descrizione di un servizio da quelli “concreti” che lo legano a particolari protocolli di rete o di RPC.

1. Livello astratto: il servizio viene definito genericamente riferendosi alle operazioni offerte (interfacce) e al tipo di messaggi scambiati per ciascuna di esse.

2. Livello concreto: le descrizioni astratte vengono istanziate legandole a una implementazione reale (protocolli, indirizzi di rete, ecc.).

Livelli di definzione del servizio

La descrizione astratta di un servizio web è composta:

1. Dalla definizione del tipo di messaggi scambiati tra client e server durante la fruizione del servizio.

2. Dalla definizione delle operazioni tramite le quali si interagisce col servizio scambiando messaggi.

3. Dalla definizione delle porte astratte di connessione, cioè collezioni di operazioni (interfacce) esposte dal servizio.

Descrizione astratta

La descrizione concreta di un servizio web è composta: 1. Dai binding che legano ciascuna porta astratta a un

protocollo e a un formato dati per i messaggi scambiati.

2. Dalle porte, che legano le porte astratte istanziate dai binding a indirizzi di rete reali.

3. Dai servizi, composti da insiemi di porte correlate (che spesso offrono modalità differenti di accesso alla stessa tipologia di servizio).

Descrizione concreta

<definitions> <types>

i tipi di dati che verranno trasmessi

</types>

<message>

i messaggi scambiati

</message>

<portType>

le operazioni (funzioni) supportate

</portType>

<binding>

come si scambiano i messaggi (dettagli SOAP) e protocollo di comunicazione

</binding>

<service>

dove trovare il servizio

</service>

</definitions>

Struttura del WSDL

<?xml version="1.0" encoding="UTF-8"?>

<wsdl:definitions name="serverProva" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

<wsdl:types></wsdl:types>

Esempio di schema WSDL

<wsdl:message name="helloRequest">

<wsdl:part element="corsoWS:helloRequest" name="parameters"/>

</wsdl:message>

<wsdl:message name="helloResponse">

<wsdl:part element="corsoWS:helloResponse" name="parameters"/>

</wsdl:message>

<wsdl:portType name="serverProva">

<wsdl:operation name="hello">

<wsdl:input message="corsoWS:helloRequest"/>

<wsdl:output message="corsoWS:helloResponse"/>

</wsdl:operation>

</wsdl:portType>

Esempio di schema WSDL

<wsdl:binding name="serverProvaSOAP" type="corsoWS:serverProva">

<wsdl:operation name="hello">

<wsdl:input></wsdl:input>

<wsdl:output></wsdl:output>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="serverProva">

<wsdl:port binding="corsoWS:serverProvaSOAP" name="serverProvaSOAP"></wsdl:port>

</wsdl:service>

</wsdl:definitions>

Esempio di schema WSDL

Il root element di un WSDL è costituito dal tag definitions il quale contiene la definizione dei namaspace utilizzati. In particolare definisce i namespace pubblici delle specifiche WSDL, SOAP E XSD e namespace di progetto usati per la definizione dei documenti di stile.

<wsdl:definitions name="serverProva" targetNamespace=http://www.prometheo.it/corsoWS xmlns:corsoWS=http://www.prometheo.it/corsoWS xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/ xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/ xmlns:xsd=http://www.w3.org/2001/XMLSchema> … </wsdl:definitions>

Il Root element: tag definitions

Passiamo in rassegna gli elementi del WSDL partendo dall’ultimo.

Il tag service definisce il servizio, i riferimenti al binding dei dettagli del servizio tramite un nome logico, i riferimenti della location dove il servizio è esposto.

<wsdl:service name="serverProva">

<wsdl:port binding="corsoWS:serverProvaSOAP" name="serverProvaSOAP">

<soap:address location="http://EIDOS-NBGDT:8088/mockserverProvaSOAP"/>

</wsdl:port>

</wsdl:service>

Servizio esposto: tag service

Il tag binding definisce il formato del messaggio, i dettagli del protocollo per ogni Port ed il SoapAction.

<wsdl:binding name="serverProvaSOAP" type="corsoWS:serverProva">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="hello">

<soap:operation soapAction="http://www.prometheo.it/corsoWS/hello"/>

<wsdl:input><soap:body use="literal"/></wsdl:input>

<wsdl:output><soap:body use="literal"/></wsdl:output>

</wsdl:operation>

</wsdl:binding>

Formato dei messaggi:tag binding

Il PortType descrive il servizio, le operazioni che possono essere eseguite e i messaggi che sono coinvolti in queste operazioni. Può essere paragonato ad una libreria di funzioni (o un modulo, o una classe) in un tradizionale linguaggio di programmazione.

<wsdl:portType name="serverProva">

<wsdl:operation name="hello">

<wsdl:input message="corsoWS:helloRequest"/>

<wsdl:output message="corsoWS:helloResponse"/>

</wsdl:operation>

</wsdl:portType>

Dettagli del servizio: tag portType

L'elemento <message> definisce gli elementi di dati di una operazione. Ogni messaggio può essere costituito da una o più parti. Le parti possono essere paragonate a dei parametri di una chiamata di funzione in un linguaggio di programmazione tradizionale.

<wsdl:message name="helloRequest"> <wsdl:part element="corsoWS:helloRequest" name="parameters"/> </wsdl:message> <wsdl:message name="helloResponse"> <wsdl:part element="corsoWS:helloResponse" name="parameters"/> </wsdl:message>

Elementi dei messaggi: tag message

Questo tag serve per contente o importare l’XSD utilizzato per definire i tag dell’XML oggetto di scambio del payload SOAP

<wsdl:types>

<xsd:schema targetNamespace="http://www.prometheo.it/corsoWS">

<xsd:element name="helloRequest">

<xsd:complexType>

<xsd:sequence><xsd:element name="nomeUtente" type="xsd:string"/></xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="helloResponse">

<xsd:complexType>

<xsd:sequence><xsd:element name="echoUtente" type="xsd:string"/></xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

</wsdl:types>

XSD del messaggio XML: tag types

Gli stili di invocazione dei messaggi possono essere di Document o RPC

Document style: si adotta quando i servizi richiedono di scambiarsi veri e propri documenti/dati XML

Il Body contiene il contenuto informativo del messaggio formattato in XML

Il documento scambiato può avere struttura e contenuti qualunque, non definiti a priori

Stili di invocazione

RPC style: si adotta quando si vuole invocare una procedura remota Utilizza una struttura del corpo del messaggio

convenzionale che rappresenta le informazioni necessarie per una RPC: nome della procedura o metodo, segnatura (opzionale), parametri

La risposta della RPC (cioè il valore di ritorno della chiamata) è restituita nel Body di un altro messaggio SOAP, secondo il meccanismo richiesta-risposta (p.e: la chiamata è inviata mediante request HTTP e la risposta fornita come response HTTP)

Stili di invocazione

RPC: Realizza un’invocazione di procedura Basata sulla segnatura della procedura Sincrona Effettua il marshalling/unmarshalling dei parametri da/verso XML

Document Sia sincrona che asincrona Basata sui contenuti del documento Usata quando si devono scambiare dati semi strutturati e di una

certa dimensione

Stile in sintesi

L’operation è l’unità di interazione elementare con un Web service, ed è eseguita attraverso lo scambio di messaggi.

Convenzionalmente: 1. input messages: inviati dall’utilizzatore al Service 2. output messages: messaggi inviati dal Service.

L’interazione con i Web Services può essere asincrona.

Scambi asincroni possono verificarsi all’interno di una operazione a due messaggi, oppure tra due operazioni a messaggio singolo

Operazioni e messaggi asincroni

Un’operazione può essere:

1. request-response: il service riceve una richiesta(input message) e restituisce la risposta relativa(output message)

2. solicit-response: il service invia un messaggio (output message) e riceve una risposta (input message)

3. one-way:il service riceve un messaggio (input message)

4. notification: il servizio invia un messaggio (output message)

A queste operazioni corrispondono diverse combinazioni di messaggi in input e output

MEP : Message Exchange Patterns

A fronte di una richiesta si aspetta una risposta (esempio: servizio web)

<operation name="op1">

<input name="op1Request" message="..." />

<output name="op1Response" message="..." />

<fault name="op1Fault" message="..." />

</operation>

Request / Response

Viene ricevuto un messaggio di output che scatena un evento una invocazione (esempio: messaggio promozionale di acquisto)

<operation name="op2">

<output name="op2Solicit" message="..." />

<input name="op2Response" message="..." />

<fault name="op2Fault" message="..." />

</operation>

Solicit/Response

Viene previsto l’invio di un messaggio al quale non fa seguito una risposta (esempio: logging )

<operation name="op3">

<input name="op3in" message="..." />

</operation>

One-Way

Viene effettuata una notifica a seguito di un’azione precedente (esempio: mail di notifica)

<operation name="op4">

<output name="op4out" message="..." />

</operation>

Notification

Java Web Services: il Server Creazione di un Web Services Server in Java

Con NetBeans è possibile, tramite tool semplificati, creare una classe di gestione delle invocazioni e gli skeleton del servizio.

La classe di gestione utilizza la specifica JSR-109 relativa ai Web Services che tramite le Annotation consente di definire i parametri di configurazione del servizio.

Gli skeleton sono delle classi Java che mappano lo schema XSD dei messaggi e le operation del WSDL.

Creazione di WS Server

Parametri richiesti:

1. Creare un nuovo «Web Services from WSDL»

2. Definire nome, package, sorgente WSDL

Creazione di WS Server

La classe di handler serveProva dovrà essere popolata con il codice necessario per gestire la risposta, di seguito un semplice esempio

@WebService(serviceName = "serverProva", portName = "serverProvaSOAP", endpointInterface = "it.prometheo.corsows.ServerProva", targetNamespace = "http://www.prometheo.it/corsoWS", wsdlLocation = "WEB-INF/wsdl/serverProva/serverProva.wsdl") public class serverProva { public it.prometheo.corsows.HelloResponse hello(it.prometheo.corsows.HelloRequest helloRequest) { HelloResponse helloResponse = new HelloResponse(); helloResponse.setEchoUtente("Ciao " + helloRequest.getNomeUtente() ); return helloResponse; } }

Classe di handler

Le classi skeleton generate automaticamente sono utilizzate per mappare le operazioni ed i tipi di dati.

Sono inseriti in una cartella gestita da NetBeans.

Classi skeleton

Java Web Services: il Client Creazione di un Web Services Client in Java

Con NetBeans è possibile, tramite tool semplificati, creare anche gli stub del servizio.

Gli stub sono delle classi Java che mappano lo schema XSD dei messaggi e le operation del WSDL.

E’ compito dello sviluppatore la creazione della classe client che effettui l’invocazione utilizzando gli stub.

Creazione di WS Client

Parametri richiesti:

1. Creare un nuovo «Web Services Client»

2. Definire sorgente WSDL, package.

Creazione di WS Client

La classe client utilizza gli stub per popolare la busta SOAP. L’oggetto di envelope viene tradotto in blocco XML SOAP dalle librerie java che implementano la specifica JSR-109, in particolare viene utilizzato METRO.

public class Client { public static void main(String[] args) { ServerProva serverProva = (new ServerProva_Service()).getServerProvaSOAP(); ObjectFactory objectFactory = new ObjectFactory(); HelloRequest helloRequest = objectFactory.createHelloRequest(); helloRequest.setNomeUtente( "Andrea" ); HelloResponse helloResponse = serverProva.hello(helloRequest); String responseWS = helloResponse.getEchoUtente(); System.out.println( responseWS ); } }

Classe Client di invocazione

Le classi stub generate, come nel caso delle classi skeleton, automaticamente sono utilizzate per mappare le operazioni ed i tipi di dati.

Sono inseriti in una cartella gestita da NetBeans

Classi stub