Corso di Web Services A A. 2010 2011 Domenico Rosaci SOAP

1. Corso diWeb ServicesA A. 2010 2011Domenico RosaciSOAP SOAP

2. Introduzione • I WS si basano sull’uso di diverse tecnologie sottostanti • Le tecnologie a cui siamo interessati in questo contesto sono: • SOAP • WSDL • WS IL • UDDI SOAP

3. Cos’è un Web Service? • Un WS è un’interfaccia accessibile in rete per funzionalità applicative, costruita utilizzando tecnologie Internet standard • In altre parole, se un’applicazione è tale che si può accedere ad essa tramite una combinazione di protocolli Internet standard come HTTP, XML, SMTP, allora quell’applicazione è un Web Service • Quindi si tratta di un concetto semplice, e per nulla nuovo. Piuttosto, esso sintetizza dei concetti già esistenti da anni relativamente al Web. SOAP

4. Cos’è un WS SOAP

5. Fondamenti di WS • Un WS è quindi un’interfaccia posizionata tra il codice dell’applicazione e l’utente dell’applicazione • Agisce come un “livello di astrazione”, separando i dettagli relativi alla piattaforma e al linguaggio di programmazione dal modo in cui il codice dell’applicazione è effettivamente invocato • Questa astrazione consente ad ogni linguaggio che supporta i WS di accedere alle funzionalità dell’applicazione SOAP

6. Fondamenti di WS SOAP

7. Fondamenti di WS • I WS che vediamo attualmente distribuiti (deployed) sul Web sono siti Web HTML. • In questi siti i servizi applicativi, cioè i meccanismi per pubblicare, gestire, cercare contenuti sono acceduti attraverso protocolli e formati standard: HTTP e HTML • Le applicazioni Client (i Web browser) possono interagire con i servizi applicativi per portare avanti task come ad esempio cercare in un catalogo di libri, procedere ad un acquisto, ecc SOAP

8. Fondamenti di WS • Grazie al livello di astrazione dei WS, non importa quale linguaggio sia stato usato per scrivere i servizi applicativi, e se questo linguaggio è differente da quello in cui è scritto il Browser • Anche l’eventuale eterogeneità dei Sistemi Operativi sottostanti alle applicazioni interagenti è irrilevante • I WS permettono così un’interoperabilità “cross platform” SOAP

9. Fondamenti di WS • C’è attualmente uno sforzo notevole nella comunità Java per definire un’esatta architettura per implementare i WS nel framework di Java 2 EE • Tutti le principali aziende sviluppatrici (IBM, Sun, etc) lavorano continuamente per permettere il supporto dei WS nelle loro piattaforme • IBM per esempio ha integrato i WS nelle sue piattaforme WebSphere, Tivoli, Lotus e DB”, mentre Microsoft ha fatto lo stesso con la piattaforma .NET SOAP

10. Aspetto dei WS • I WS sono un framework per il supporto dei messaggi • La forma più comune di WS è quella di chiamare procedure in esecuzione su un server, tramite messaggi del tipo “chiama questa procedura con questi argomenti” oppure “questo è il risultato della chiamata della procedura” • Il codice dell’applicazione contiene dtutta la logica di business e codifica i task (aggiungere un libro a un catalogo, cercare un libro, ecc.). • Il Service Listener è in grado di comprendere i protocolli (HTTP, SOAP, Jabber, etc.) e sta in ascolto dei messaggi di richiesta • Il Service Proxy può elaborare una risposta per il Service Listener (ma può anche non esserci) SOAP

11. Aspetto dei WS SOAP

12. Aspetto dei WS • Le componenti Service Proxy e Service Listener possono essere componenti stand alone (un HTTP o TCP server ad esempio) o possono essere eseguite nel contesto di altri tipi di application server. • Ad esempio, WebShere Application Server include librerie built in per ricevere messaggi SOAP su HTTP ed usarli per invocare applicazioni Java distribuite in WebSphere. Anche Apache Web Server ha un modulo che implementa SOAP. • La necessità di un Application Server non è fondamentale. I WS possono essere implementati su qualunque sistema che supporti le tecnologie Internet standard, anche su un palmtop o su un cellulare. SOAP

13. Aspetto dei WS • I WS non richiedono il tradizionale modello Client Server per le applicazioni, né richiedono un modello architetturale n tier. • Possono essere implementati in qualunque contesto, anche distribuito, a patto che siano presenti i protocolli Internet standard. SOAP

14. Intersezione di Business e Programmazione • I programmatori tendono a porsi questioni del tipo “come posso eseguire questo task più velocemente?” oppure “Come posso sfruttare l’ereditarietà tra gli oggetti?” • Coloro che si preoccupano del business si pongono invece delle domande del tipo “Come posso assicurarmi che chi usa questo servizio sia realmente chi dice di essere?” oppure “Come posso mettere insieme più WS in un workflow?” • A volte i 2 punti di vista entrano in conflitto. Il Business richiede efficacia, sicurezza, affidabilità, mentre la programmazione ha come obiettivo l’efficienza, la semplicità e la robustezzza. SOAP

15. Business vs Programmazione • Difficilmente i tool WS riescono a conciliare entrambi gli aspetti • Ad esempio, SOAP::Lite è un ambiente di implementazione SOAP basato su Perl, scritto essenzialmente per programmatori. Fornisce un insieme di tool per invocare moduli Perl attraverso messaggi SOAP • Invece Apache Axis è un ambiente di sviluppo SOAP che consente di implementare soluzioni più complesse, realizzando processi o tenendo insieme più WS • La cosa importante da sottolineare è che qualunque approccio WS si basa sulle stesse tecnologie Web (WSDL, UDDI, ecc.). La differenza sta nelle possibilità che il singolo approccio offre al programmatore per interfacciarsi con l’applicazione. SOAP

16. Integrazione Just-in-Time • L’integrazione JIT consente di innestare il modello di distribuzione delle applicazioni Internet sul modello chiamato “Architettura WS” SOAP

17. Integrazione JIT • Il service provider pubblica una descrizione dei servizi che offre attraverso il service registry • Il service consumer cerca nel service registry i servizi che soddisfano le sue necessità • Il consumer può essere una persona o un programma • Il binding fa riferimento a un consumer che sta realmente utilizzando un servizio offerto da un provider • La chiave per l’integrazione JIT è che essa può avvenire in qualunque momento, anche a runtime, come nell’early binding della OOP • Il client potrebbe cioè non conoscere quali procedure chiamerà fino a quando non viene eseguita la ricerca del servizio e si trova il candidato adatto SOAP

18. WS Technology Stack • L’architettura WS è implementata attraverso l’utilizzo di cinque tipi di tecnologie, organizzate in layer disposti su uno stack SOAP

19. WS Technology Stack • La struttura presenta un’evidente similitudine con lo stack dei protocolli TCP-IP SOAP

20. WS Technology Stack • I layer addizionali packaging, description e discovery sono essenziali per fornire l’integrazione JIT • Ogni layer ha a che fare con un determinato business problem, quindi non è necessario implementarli tutti. Quando un nuovo layer va aggiunto, non è necessario riscrivere il codice esistente • L’ambiente distribuito che ne risulta è completamente modulare, diversamente dalle vecchie soluzioni Java o Corba per ambienti distribuiti SOAP

21. Oltre lo Stack • I layer dello stack WS non ricoprono tutte le problematiche possibili. Per esempio, non danno soluzione ai problemi di sicurezza, privacy, trust, workflow e molti altri • Intervengono quindi altri standard quali: • XML (alternativa a SOAP) • XKMS (sicurezza) • SAML (sicurezza) • XML Dsig (firma digitale) • XML Enc (crypting) • XSD (ontologie) • P3P (privacy) • WSFL (workflow) • Jabber (Peer to peer) SOAP

22. Layer 1: Discovery • Il layer Discobery fornisce i meccanismi che permettono al client di scoprire le descrizioni dei servizi dei provider • Uno degli standard più largamente diffusi in questo contesto è l’Universal Description Discovery and Integration (UDDI) • IBM e Microsoft hanno congiuntamente proposto un’alternativa ad UDDI, che è il Web Services Inspection Language (WS Inspection) SOAP

23. Layer 2: Description • Quando un WS è implementato, occorre prendere delle decisioni su come supporterà i protocolli di network, transport e packaging • Una descrizione del servizio rappresenta queste decisioni • Il Web Service Description Language (WSDL) è lo standard de facto in questo contesto • RDF e DARPA sono altre alternative proposte dal W3C, èiù ricche ma molto più complesse di WSDL SOAP

24. Layer 3: Packaging • Affinchè i dati delle applicazioni possona muoversi attraverso la rete mediante il livello di trasporto, essi devono essere “impacchettati” in un formato comprensibile da ognuno degli attori coinvolti • HTML potrebbe essere un formato candidabile, ma esso è troppo strettamente legato alla presentazione delle informazioni, piuttosto che alla rappresentazione del contenuto informativo • XML invece permette di rappresentare la struttura delle informazioni • SOAP è un formato di packaging molto comune, costruito su XML SOAP

25. Layer 4: Transport • Il livello di trasporto include le varie tecnologie che permettono la comunicazione application-to-application • Alcuni protocolli utilizzati sono TCP, HTTP, SMTP e Jabber • Il ruolo primario del livello di trasporto è quello di muovere dati tra due o più locazioni della rete • I WS possono essere costruiti sopra qualunque protocollo di trasporto • La scelta del protocollo di trasporto da utilizzare dipende dalle esigenze specifiche. HTTP ad esempio include il servizio firewall più ubiquo, ma non supporta la comunicazione asincrona. Jabber invece, pur non essendo un vero standard, rappresenta una buona soluzione per instaurare canali di comunicazione asincrona. SOAP

26. Layer 5: Network • Il livello Network è lo stesso che nel modello TCP/IP • Fornisce le principali funzionalità per l’addressing ed il routing su rete SOAP

27. Le applicazioni • Le funzionalità del WS sono implementate attraverso un codice, che rappresenta un generico “livello delle applicazioni” che si serve dei vari layer dello stack sottostanti SOAP

28. Modello Peer Services • Rappresenta una visione alternativa dei WS • Basato sull’architettura P2P, prevede che un insieme di membri condividano una collezione di servizi • Esistono evidenti similitudini tra il modello P2P e i WS • La principale differenza è che nei sistemi P2P il ruolo di consumer e provider è molto interscambiabile, mentre nei WS la differenza è solitamente netta • Instant Messaging è un esempio molto nodo di modello WS P2P. SOAP

29. SOAP: Concetti di base • E’ un protocollo standard di packaging per i messaggi che si scambiano le applicazioni • La specifica definisce niente più che una semplice busta absata su XML per le informazioni che vengono trasferite, ed un insieme di regole per la traduzione dei tipi di dati delle applicazioni in rappresentazioni XML • SOAP è un’applicazione delle specifiche XML • Si rifà fortemente agli standard XML come XML Schema e XML Namespace SOAP

30. XML Messaging • Un messaggio può essere qualunque cosa: un ordinativo d’acquisto, una prenotazione di un volo, una richiesta di ricerca in un catalogo e così via • Essendo XML indipendente da qualunque piattaforma o linguaggio di programmazione, esso può consentire di fare comunicare applicazioni che girano su sistemi operativi diversi, basandosi su linguaggi diversi SOAP

31. RPC e EDI • SOAP ha due applicazioni possibili: RPC e EDI • Remote Procedure Call (RPC) è un meccanismo che permette a metodi che girano su macchine diverse di “chiamarsi” a vicenda scambiandosi dei parametri • Electronic Document Interchange (EDI) definisce un formato standard per documenti e messaggi finanziari e commerciali • Si può usare un “document style” SOAP basato su EDI, con XML che rappresenterà ordini, tabelle fiscali e documenti simili. Oppure usare un “RPC style” SOAP basato su RPC dove XML rappresenterà argomenti per metodi o valori di ritorno SOAP

32. Necessità di una codifica standard • Un’informazione, come ad es. un numero di telefono, si può rappresentare in diversi modi SOAP

33. Codifica standard • Oltre a dire che stiamo usando XML, dobbiamo definire: • Il tipo di informazione che stiamo scambiando • Come l’informazione viene espressa in XML • Come inviare realmente l’informazione Senza tali informazioni, le applicazioni non saprebbero decodificare i messaggi, anche sapendo che essi sono codificati in XML. SOAP fornisce questo tipo di informazioni SOAP

34. Messaggi SOAP • Un messaggio SOAP consiste di una busta contenete un header (opzionale) e un body /richiesto) • L’header contiene blocchi di informazione che indicano come il messaggio deve essere processato (settaggi sul routing e sulla delivery, asserzioni di autenticazione e autorizzazione, e contesti di transazione) • Il body contiene il messaggio vero e proprio. Qualunque cosa possa essere espressa in XML può andare nel body di un messaggio. SOAP

35. Messaggi SOAP SOAP

36. Messaggi SOAP • La sintassi XML per rappresentare un messaggio SOAP message è basata sul namespace http://www.w3.org/2001/06/soap-envelope namespace. SOAP

37. Esempio di document style SOAP SOAP

38. Esempio SOAP • Nell’esempio si fa uso dei “namespace” per definire gli spazi dei nomi principali “soap-envelop” (s), “soap-transaction” (m) e “orderService” (n). • Ogni messaggio possiede l’elemento “contenitore” s:enevelope, l’elemento opzionale s:Header e l’elemento obbligatorio “s:Body” SOAP

39. Sintassi SOAP • Ogni envelope può contenere esattamente un elemento Body • Il contenuto dell’elemento Body, che può essere composto da un qualunque numero di sottoelementi, rappresenta il messaggio vero e proprio • Ogni envelope può contenere al massimo un Header, che se esiste deve apparire come il primo “figlio” di envelope • Il proposito di un header è quello di comunicare informazioni contestuali utili per processare un messaggio (ad esempio, credenziali di autenticazione). SOAP

40. Messaggi RPC Style • Solitamente viaggiano in coppia: un messaggio di richiesta ed un messaggio di risposta • Si immagini, come esempio, che il server offra la seguente funzione che ritorna il valore azionario di un’azienda: • Public float getQuote(String symbol); SOAP

41. Esempio di richiesta SOAP

42. Esempio di risposta SOAP

43. L’attributo mustUnderstand • Questo attributo appare nell’header del messaggio. Se è settato uguale a “true”, esso impone al ricevente del messaggio di “comprendere” il contenuto dell’header oltre che del body • Se il contenuto dell’header non è stato compreso, e mustUnderstand=“true”, il ricevente deve rifiutare il messaggio anche nel caso riuscisse a comprendere il Body SOAP

44. Encoding style • Un encoding style è un insieme di regole che specificano come i tipi di dato sono codificati attraverso la sintassi XML • A tale scopo si usa l’attributo encodingStyle SOAP

45. Distinguere tra le versioni SOAP • La versione di un messaggio SOAP può essere determinata verificando il namespace. • Ad esempio, la versione 1.1. usa il namespace http://www.w3.org/2001/06/soap-envelope, mentre la 1.2 usa il namespace http://www.w3.org/2001/06/soap-envelope. • Se l’applicazione ricevente determina una versione SOAP non supportata nel messaggio del ricevente, può comunicare al ricevente qual è la versione supportata inserendo nell’header l’attributo upgrade SOAP

46. Esempi di errori SOAP SOAP

47. Errori SOAP SOAP

48. Errori standard SOAP

49. “Custom” Faults SOAP

50. L’attributo Misunderstood SOAP