Corso web services
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Corso web services

on

  • 1,057 views

 

Statistics

Views

Total Views
1,057
Views on SlideShare
1,057
Embed Views
0

Actions

Likes
0
Downloads
22
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Corso web services Presentation Transcript

  • 1. Web Services
  • 2. 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
  • 3.  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
  • 4.  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
  • 5.  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
  • 6.  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
  • 7. Schema di interazione
  • 8. SOAP Simple Object Access Protocol
  • 9.  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
  • 10.  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à
  • 11.  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
  • 12. <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
  • 13. <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
  • 14.  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
  • 15.  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
  • 16.  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
  • 17. WSDL Web Service Definition Language
  • 18.  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
  • 19. 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
  • 20.  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
  • 21.  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
  • 22. <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
  • 23. <?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
  • 24. <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
  • 25. <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
  • 26. 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
  • 27. 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
  • 28. 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
  • 29.  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
  • 30.  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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. 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
  • 35.  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
  • 36.  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
  • 37. 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
  • 38. 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
  • 39. 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
  • 40. Viene effettuata una notifica a seguito di un’azione precedente (esempio: mail di notifica) <operation name="op4"> <output name="op4out" message="..." /> </operation> Notification
  • 41. Java Web Services: il Server Creazione di un Web Services Server in Java
  • 42.  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
  • 43. Parametri richiesti: 1. Creare un nuovo «Web Services from WSDL» 2. Definire nome, package, sorgente WSDL Creazione di WS Server
  • 44. 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
  • 45.  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
  • 46. Java Web Services: il Client Creazione di un Web Services Client in Java
  • 47.  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
  • 48. Parametri richiesti: 1. Creare un nuovo «Web Services Client» 2. Definire sorgente WSDL, package. Creazione di WS Client
  • 49.  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
  • 50.  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