La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Web Services Mario Arrigoni Neri. 2 Risorse e servizi Il semantic web si prefigge lo scopo di rappresentare e processare automaticamente le risorse disponibili.

Presentazioni simili


Presentazione sul tema: "Web Services Mario Arrigoni Neri. 2 Risorse e servizi Il semantic web si prefigge lo scopo di rappresentare e processare automaticamente le risorse disponibili."— Transcript della presentazione:

1 Web Services Mario Arrigoni Neri

2 2 Risorse e servizi Il semantic web si prefigge lo scopo di rappresentare e processare automaticamente le risorse disponibili sulla rete La descrizione di una risorsa ne coglie la semantica ed include le informazioni sulla risorsa che possono essere utilizzate in maniera automatica da entità software Non solo per scopi di visualizzazione, ma anche per un uso completo e coerente delle risorse Le risorse statiche, che rappresentano uno stato delle cose e sono veicoli di informazione (o conoscenza) sono solo parte delle risorse disponibili sulla rete

3 3 Le generazioni del WEB Internet fase 1: contenuti statici – Pagine HTML – Risorse FTP – Lutente sa cosa vuole e dove recuperarlo Internet fase 2: applicazioni web – Personalizzazione del livello presentation.. VB-Script, J-Script, DHTML – Contenuti dinamici (Servlet, JSP, ASP, Applet, …) – Lapplicazione interagisce con lutente Internet fase 3: semantic web – Documenti leggibili da agenti artificiali – Servizi utilizzabili da agenti artificiali

4 4 Aspetti dinamici del sem-web URI, HTML, HTTP Statico WWW Infomazione ricerca estrazione rappresentazione interpretazione manutenzione RDF, RDF(S), OWL Semantic Web UDDI, WSDL, SOAP Web Services Dinamico Applicazioni OWL-S Semantic WS SintatticoSemantico

5 5 I web services – 1 I Web service sono un nuovo tipo di applicazioni WEB. Sono applicazioni auto-contenute, auto descriventi e modulari che possono essere pubblicate, localizzate ed invocate attraverso il Web. Possono eseguire funzioni che vanno da operazioni elementari a complessi processi di business… Una volta che un Web service è messo in linea altre applicazioni (ed altri web service) possono raggiungerlo ed invocarlo IBM web service tutorial

6 6 Linguaggi di supporto URI HTMLHTTP UDDI WSDLSOAP Statico Dinamico Accesso/ ricerca DescrizioneAccesso/ fruizione

7 7 Caratteristiche dei WS Protocolli WEB: i Web Service basati su HTTP sono progettati per essere fruiti sulla rete pubblica. – Attraversa i firewall – Permette di operare su reti eterogenee Interoperabilità: SOAP definisce uno standard comune che permette a sistemi differenti di dialogare indipendentemente dalle disomogeneità hardware (interplatform) e software (linguaggi) XML: si propone ovviamente come substrato sintattico per tutti i linguaggi che sostengono la rete dei servizi

8 8 Tematiche classiche Le problematiche principali per la costruzione di un sistema generale di erogazione di servizi sono: – Interazione: occorre specificare una sintassi uniforme per rappresentare i messaggi che si scambiano i client ed i server, indipendentemente dal particolare linguaggio in cui sono implementati. SOAP come evoluzione di D-COM / CORBA – Interfaccia: come descrivere in maniera uniforme le interfacce dei singoli componenti software? WSDL come evoluzione dellIDL di corba – Ricerca: modello fondamentalmente basato su elenchi pubblici: UDDI

9 9 Stato dellarte - architettura HTTP SOAP WSDL UDDI WSDL WS-Security WS-Routing etc… BPEL4WS XML UDDI: fornisce ai client un meccanismo per trovare i web service. Un registro UDDI è simile ad un corba trader, o ad un DNS di applicazioni WSDL: definisce i servizi come una collezione di terminali di rete o porte. Ogni porta è descritta da un indirizzo di rete; insiemi di porte definiscono i servizi SOAP: fornisce un sistema standard per costruire messaggi di richiesta e le risposte fornite dai singoli servizi. Sostanzialmente è un sistema per eseguire chiamate RPC su una rete tramite HTTP (ma non solo…)

10 10 Ciclo di vita Remote Web Service Repository (Web Sites) Write Client Code Service Requestor Invoke Web Service Manual Web Service Lookup SOAP Request SOAP Response WSDL - Web Service Description SOAP - Web Service Message Protocol WSDL File Remote Web service Publish Web Service HTTP GET

11 11 Come funzionano? – SOAP Componenti: – Il codice che deve essere pubblicato come WS – Un server SOAP (Apache Axis) – Un server HTTP (Apache) – Un client SOAP (Apache Axis) (http trasporto) Requestor Messaggi SOAP Fornitore di Web Service Endpoint Client SOAP

12 12 SOAP (Simple Object Access Protocol) SOAP è un paradigma di dialogo tra sistemi software – Stateless: non viene gestito esplicitamente lo stato del dialogo – One-way: lo scambio di messaggi avviene secondo un semplice schema dal mittente al ricevente Fornisce un guscio (Envelope) in cui inserire i messaggi application- dependent Lapplicazione può costruire una sovrastruttura che gestisca protocolli più complessi: – Richiesta / risposta – Richiesta / risposte multiple – Statefull connection – Ecc..

13 13 Il messaggio SOAP SOAP Envelope SOAP Header Header Bock SOAP Body Body subelement

14 14 Il messaggio SOAP: Header Lheader SOAP (opzionale): meccanismo di estensione che permette di inserire nel messaggio dellinformazione extra rispetto allapplicazione le informazioni di controllo comprendono delle direttive, le informazioni sullelaborazione del messaggio, ecc.. questo meccanismo permette di estendere informazioni di controllo in maniera specifica per la specifica applicazione ogni blocco rappresenta un raggruppamento di informazioni e può essere indirizzato ai singoli nodi attraversati lungo la rete che possono modificarlo e/o eliminarlo fornendo valore aggiunto

15 15 Il messaggio SOAP: Body obbligatorio in ogni messaggio contiene le informazioni che si vogliono far passare dal mittente (initial SOAP sender) al destinatario (ultimate SOAP receiver) ogni nodo SOAP assume che il contenuto del corpo del messaggio sia application dependent e sia sostanzialmente comprensibile solo al destinatario finale il messaggio è naturalmente serializzato tramite un opportuno linguaggio XML che fa riferimento ai ns: env = enc = "http://www.w3.org/2003/05/soap-encodinghttp://www.w3.org/2003/05/soap-encoding rpc = "http://www.w3.org/2003/05/soap-rpc"

16 16 Il messaggio SOAP: Esempio … … New York Los Angeles … Los Angeles New York none Blocco

17 17 Una possibile risposta – 1 … JFK LGA EWR JFK LGA EWR

18 18 Una possibile risposta – 2 … LGA EWR

19 19 SOAP ed RPC Uno dei principali impieghi di SOAP è lincapsulamento tramite XML di chiamate di procedura remote (RPC) Per eseguire una RPC occorrono alcune informazioni: – Lindirizzo del nodo SOAP che pubblica il servizio – Il nome della procedura da invocare – Gli identificatori ed i valori da assegnare ai singoli parametri della procedura – I nomi di parametri in uscita ed il tipo del valore restituito – Il pattern di dialogo da usare per svolgere la conversazione – Eventuali dati da inserire nellheader del messaggio SOAP

20 20 Prenotazione tramite SOAP – 1 5 FT35ZBQ Mario Rossi

21 21 Prenotazione tramite SOAP – 2 La chiamata RPC è inserita come sottoelemento di env:Body La procedura changeReservation riceve in ingresso due parametri: – reservation (composta dal solo campo code) – creditCard (composta dai campi name, number ed expiration). Lattributo env:encodingStyle assume un valore che indica quale convenzione è stata utilizzata per codificare i parametri, in particolare il valore indica che la struttura è stata serializzata secondo le specifiche di default di SOAPhttp://www.w3.org/2003/05/soap-encoding Lheader contiene un blocco: – Riservato al destinatario data lassenza di env:role – Comunica una informazione sulla transazione (codice 5)

22 22 Prenotazione tramite SOAP – 3 Immaginando che la RPC sia stata definita come avente due parametri in uscita: il codice della prenotazione e lURL a cui sono raggiungibili i dettagli della stessa, oltre al valore ritornato che contiene lo stato di conferma o attesa dellordine. … m:status confirmed FT35ZBQ

23 23 Estensioni – 1 SOAP fornisce un metodo standard per implementare un sistema di dialogo basato su richiesta-risposta. – La richiesta ha la proprietàhttp://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Excha ngePatternName impostata a response/http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Excha ngePatternName – E si auto-associa un identificatore tramite la proprietà – La risposta si associa alla richiesta tramite la stessa proprietà Errori nellinterpretazione della richiesta … Header not understood

24 24 Estensioni – 2 E possibile usare encoding diversi da quello di default di SOAP, ad esempio è possibile usare RDF Marco Rossi LAX LGA JFK LAX

25 25 Binding – 1 Dato che SOAP è un linguaggio XML può usare una molteplicità di protocolli per il trasporto GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1 Host: travelcompany.example.org Accept: text/html;q=0.5, application/soap+xml HTTP/ OK Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn … HTTP GET POST /Reservations HTTP/1.1 Host: travelcompany.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn.. HTTP POST HTTP Response

26 26 Binding – 2 From: To: Subject: Travel to LA Date: Thu, 29 Nov :20:00 EST Message-Id: Content-Type: application/soap+xml … MAIL

27 27 WSDL Il formato specifico dei messaggi SOAP dipende da come il servizio è stato definito a livello di RPC WSDL (Web Service Description Language) permette di esprimere proprio queste definizioni WSDL è un linguaggio XML che permette di descrivere servizi come insiemi di nodi (o porte) che operano sulla base di messaggi Servizi e messaggi sono descritti: – In modo astratto, indipendente dalla particolare tecnologia – Associati alla particolare infrastruttura da utilizzare (protocollo di trasporto)

28 28 Elementi WSDL Type – è il contenitore per le definizioni di tipi di dato. Ogni definizione fa riferimento ad un particolare sistema di tipi, come ad esempio XSD Message – una definizione astratta e tipizzata dei flussi di dati da e verso il servizio Operation – una descrizione astratta di unoperazione svolta dal servizio Port type – un insieme di operazioni supportate da uno o più nodi Binding – un protocollo concreto ed una specifica del formato dei dati per un particolare port type Port – un singolo nodo definito come la combinazione di un binding e di un indirizo di rete Service – una collezione di nodi (interdipendenti) … anche se …

29 29 Struttura di un file WSDL Il dizionario di WSDL fa riferimento al namespace: Una interfaccia WSDL è composta da una serie di definizioni inserite allinterno dellelemento radice definitions Ad ogni documento WSDL può essere associato un nome, che costituisce una forma semplificata di commento Inoltre può essere specificato il targetNamespace, che deve essere necessariamente non locale e viene usato come contenitore Il riferimento ad una specifica definizione WSDL (service, port, message,…) può essere fatto tramite un QName...http://schemas.xmlsoap.org/wsdl

30 30 Tipi Lelemento types contiene tutte le definizioni dei tipi Per ragioni pragmatiche (come visto in RDF[S]), spesso si usano i tipi di XSD, ma non è un obbligo

31 31 Tipi – linee guida Usare la forma elemento-sottoelemento piuttosto che introdurre degli attributi Non includere attributi o elementi che siano peculiari di una particolare codifica (es: soap:root) Per definire gli array derivare il tipo dallarray definito in SOAP encoding schema Usare xsd:anyType per campi o parametri non tipizzati

32 32 Messaggi I messaggi consistono in una o più parti logiche Ogni parte logica è associaata con un tipo utilizzando un attributo di tipo Gli attributi di tipo sono estendibili dallutente, ma WSDL ne definisce alcuni, tra cui: – element: si riferisce ad un elemento XSD tramite un QName – type: si riferisce ad un tipo (semplice o complesso) tramite un QName *

33 33 Messaggi: parti logiche Le parti sono un meccanismo flessibile per astrarre elementi logici del messaggio (es: parametri di una chiamata RPC) Il sistema di binding può far riferimento alla singola parte per specificare i dettagli implementativi

34 34 Tipi di accessi (porte) – 1 La tipizzazione dei servizi avviene attraverso una lista di operazioni elementari, ciascuna descritta tramite: – Tipo di interazione – Tipizzazione dei messaggi in ingresso / uscita WSDL definisce quattro ripi di interazione: – One-way: il terminale (nodo) riceve un messaggio (procedura) – Request-response: il nodo riceve un messaggio ed invia una risposta (funzione) – Solicit-response: il nodo invia un messaggio e riceve un messaggio correlato (interrupt) – Notification: il nodo invia un messaggio (sensore / interrupt) *

35 35 Tipi di accessi (porte) – 2 One-way Request-response

36 36 Tipi di accessi (porte) – 3 Solicit-response Notification

37 37 Convenzioni Nomi degli attributi (messaggi): è sempre necessario poter fare riferimento ad ogni messaggio per eseguirne il binding. se il nome di uno o più messaggi non viene specificato WSDL lo costruisce per default: – One-way o Notification: omonimo delloperazione – Request-response o Solicit-response: composto dal nome delloperazione e dai suffissi Request, Solicit e Response In un contesto RPC è utile ricostruire la signature originaria del metodo, per questo motivo lattributo parameterOrder elenca i parametri nellordine in cui compaiono nel prototipo (escluso il valore di ritorno)

38 38 Binding Un binding definisce i formati ed i protocolli per le operazioni ed i messaggi definiti in un particolare portType Possono coesistere più binding per lo stesso portType Lassociazione tra il binding ed il portType avviene tramite lattributo type … binding dependent … … binding dependent … … binding dependent … … binding dependent …

39 39 Binding – esempio SOAP

40 40 Altri Binding HTTP GET & POST MIME

41 41 Service e Ports Un elemento service definisce un servizio tramite una serie di sottoelementi ports, che associano un nome convenzionale con lo specifico binding e lindirizzo del nodo che fornisce il servizio

42 42 UDDI (Universal Description, Discovery and Integration) UDDI fornisce un registro per servizi ed è esseziale per luso dinamico degli stessi API di UDDI: – Publication API – insieme autenticato di funizioni che permettono alle società di pubblicare servizi e specifiche di servizi – Inquiry API – insieme pubblico di funzioni che permtono allutente di cercare ed estrarre informazioni dai registri UDDI Web Service Requestor UDDI repository Web Service Provider Invoke through SOAP Discover or access WSDL Register WSDL

43 43 UDDI – classificazione – 1 UDDI classifica i bussiness ed i servizi sulla base di tassonomie Perché classificare? – La ricerca per parole chiave può restituire un gran numero di servizi – La classificazione permette empiricamente una ricerca migliore e più mirata agli effettivi bisogni dellutente

44 44 UDDI – classificazione – 2 UDDI utilizza tre tipologie distinte di registri: Contengono informazioni sul business: nome, descrizione, contatti Informazioni sulla classificazione del business e sui tipi di servizi forniti Informazioni su come ottenere (usare) un determinato servizio: es. lURL del descrittore WSDL White Pages Yellow Pages Green Pages


Scaricare ppt "Web Services Mario Arrigoni Neri. 2 Risorse e servizi Il semantic web si prefigge lo scopo di rappresentare e processare automaticamente le risorse disponibili."

Presentazioni simili


Annunci Google