Web services

2,454 views

Published on

Published in: Technology
  • Be the first to comment

Web services

  1. 1. I Web Services e il protocollo SOAP che ne è alla base Nelson Firmani Dipartimento di Ingegneria Elettrica Università di L’Aquila, AQ 67040, Italy PremessaScopo del documento è dare una panoramica sui Web Services e sulle diverse tecnologie connesse.Il livello di dettaglio è sufficiente per la realizzazione di un semplice servizio web.Dopo una breve illustrazione dell’evoluzione dell’architettura web si introduce: Il modello dei Web Services Il protocollo SOAP che ne è alla base Realizzazione mediante il toolkit Apache Axis 1.1 di un semplice servizio web Last update: 30/04/2002 1
  2. 2. Architettura della Prima Generazione Web RPC Internet SQL HTTP HTTP Web Web Application Client Server Backend Servers Client Middle tier Backend Web/HTTP Server Browser Documenti statici http Applicazione CGI, PHP DBMS ISAPI, Odbc, rpc RPC NSAPI Sistemi legacyArchitettura a tre livelli (browser, Application Server,DB) • Client: Browser di prima generazione (senza supporto di applet e scripting) • Application Server: Web server con estensioni CGI (Perl, shell, ...) • Comunicazione tra webserver e backend attraverso ODBC, SQL, RPC . • HTTP come protocollo di comunicazione tra client e serverla logica applicativa è concentrata allinterno dello strato intermedio.La presentazione viene realizzata ridisegnando tutta la pagina del browser ad ogni interazione conl’utente. 2
  3. 3. Architettura della Seconda Generazione Web Client WebServer tier ApplicationServer tier Backend tier Web/HTTP Server Documenti statici Browser iiop, orpc, rmi iiop, orpc, rmi CGI, PHP ISAPI, NSAPI http … Servlet Browser Application server Applet, (contenitore di oggetti) Active JSP, ASP … DBMS EJBApplicazione CORBA DB ad oggetti Javabean COM iiop, orpc, rmi DCOM Sistemi legacy Architettura a più livelli (three-tier o multi-tier) • Client (Browser delle ultime generazioni uso di Applet Java e Dynamic HTML) • Un certo numero di Application Server Distribuiti (Business Logic + Data Access Logic) • HTTP come protocollo di comunicazione tra browser e web-server • Comunicazione tra application server e backend attraverso: IIOP (Internet-Inter-ORB-Protocol) come CORBA (fig. 1.1) 3
  4. 4. ORPC (Object Remote Procedure Call) come COM diventati DCOM e poi COM+ (Microsoft) (fig. 1.2) RMI (Remote Method Invocation è comunque basato su IIOP ) e poi con EJB (Enterprise Java Bean) la Sun microsystem è salita ad un ulteriore livello di astrazione nella progettazione di sistemi distribuiti (fig. 1.3) la presentazione può essere realizzata senza ridisegnare tutta la pagina del browser, grazie alla comunicazione attraverso Applet (Sun microsystem) e ActiveX (Microsoft) Contenitore di oggetti che si occupa di aspetti di integrazione e di infrastruttura come concorrenza, sicurezza, disponibilità, scalabilità, gestione, eterogeneità. (ad esempio EJB container) Oggetti/componenti destinati alla logica dell’applicazione e all’interazione con l’esterno ( presentazione, accesso ai dati)Figura 1.1 Modello client server DCOM Figura 1.2 Modello client server CORBA Figura 1.3 Architettura J2EE 4
  5. 5. Architettura della Terza Generazione Web www.acquisti.com Firewall Documenti statici Sistemi Legacy Html, dhtml, Applet, Oggetti CORBA Javascript … Bean Bean Web Extension: CGI, PHP, JSP, ASP, Servlet… Firewall HTTP/HTTPS DBMS HTTP/HTTPS SOAP Html, Wml … Bussines To we b Bussines se ce r vi Documenti statici DBMS Firewall www.spedisci.com Web Extension: CGI, PHP, JSP, ASP, Servlet…Nascono i Web Services basati sui nuovi standard: SOAP e XML.Attorno a SOAP e XML nascono tutta una serie di strumenti analoghi a CORBA, ma basati su HTTP quindifirewall friendly.Miglioramento di scalabilità e performance: distribuzione dei server component su sistemi diversiAffidabilità: replicazione dei server componentFlessibilità: Le modifiche ad un componente non richiedono modifiche agli altri componenti. 5
  6. 6. I Web ServicesI web services rappresentano un nuovo tipo di applicazioni aventi come caratteristica primaria la capacità dipoter essere pubblicati, localizzati ed invocati dal web.Requisito fondamentale per un Web Services è che sia utilizzabile da un’applicazione client scritta in unqualsiasi linguaggio, mediante qualsiasi strumento di sviluppo, e che “giri” su qualsiasi piattaforma.realizzando così l’indipendenza dell’applicazione dal protocollo di trasporto e dalla piattaforma diimplementazione (interoperabilità).Questo tipo di architetture consentono notevoli passi avanti verso il sogno della connettività globaleessi infatti permettono l’integrazione di tutte le applicazioni esistenti sul web senza dover procedere ad unrestyling di parti di codice.Lesecuzione di questi servizi basati sul web necessita di numerosi componenti posti sui vari computer.(Sistemi distribuiti) . Attualmente le più note tecnologie per lattivazione remota di procedure sono DCOM,CORBA, IIOP e EJB. Tutti questi meccanismi sono accomunati da molti aspetti simili, ma esistono altrecaratteristiche che li rendono incompatibili. In estrema sintesi, ciascuna di queste metodologie sembra esserebuona per effettuare comunicazioni tra server omogenei (ovvero che utilizzano la stessa tecnologia, e, inalcuni casi, lo stesso produttore), ma è altrettanto inadeguata quando s’instaurano delle comunicazioni client-server, soprattutto se la comunicazione avviene via Internet, a causa della stretta corrispondenza che questetecnologie esigono tra client e server. DCOM e IIOP (EJB è comunque basato su IIOP), infatti, oltre a nonpoter comunicare fra di loro se non tramite l’utilizzo di appositi bridge, sono tutti poco adatti ad attraversarefirewall (per politiche di security, viene bloccato dai firewall il passaggio di stream binari da porte TCP/IP).Riassumendo, alcuni dei principali aspetti che risultano essere problematici nel campo dell’attualeprogrammazione distribuita sul web sono: • protocolli eterogenei che faticano a comunicare; • protocolli che non funzionano bene attraverso i firewall.SOAP (Simple Object Access Protocol) rappresenta una soluzione a questi problemi. SOAP fornisce unmeccanismo punto-punto, semplice e leggero, per scambiare informazioni tipizzate e strutturate in unambiente distribuito utilizzando XML.Lo standard SOAP non introduce nuovi concetti in quanto si basa su tecnologia già esistente: • Attualmente utilizza il protocollo HTTP come protocollo di trasporto di messaggi richiesta/risposta HTTP sembra essere un ottimo mezzo di trasporto per le chiamate a procedure remote su internet perché è semplice, flessibile, indipendente dalla piattaforma ed è basato su testo quindi non è assoggettato alle intercettazioni dei firewall e per di più, quasi tutti i Web Browser ed i Server lo supportano in modo nativo. • Si basa su XML per rappresentare le informazioni. Questo garantisce ricchezza espressiva, estendibilità, portabilità e facilità di comprensione.Quindi il modello dei Web Services si affianca alle tradizionali architetture a componenti (CORBA,COM+,EJB), permettendo di esporre componenti già esistenti verso nuovi client, scritti magari con linguaggi diversied operanti su architetture diverse.Ma non solo l’obiettivo finale dei Web Services è quello di poter creare software (client o un web serviceclient nel senso che rappresenta un servizio per altri ma per assolvere il servizio richiesto lui stesso può/devefare richiesta di servizi ad altri webservice) in grado di scoprire, accedere, integrare e richiamare in mododinamico e senza alcun intervento umano, nuovi servizi offerti da aziende non note. 6
  7. 7. Lo scenario di un webservice è il seguente: Il servizio è pubblicato in una directory di servizi Il client cerca i dettagli sul servizio in una directory di servizi Il client interagisce con il servizioIl client di un servizio Web deve rintracciare un’applicazione o un elemento funzionale di un programma chesi trova nella rete. A questo scopo, interroga un registro UDDI, effettuando una ricerca per nome, categoria,identificativo o specifiche, e ottiene informazioni sulla posizione di un documento WSDL, nel quale sonoindicate le modalità per mettersi in contatto con il servizio Web richiesto e il formato dei messaggi di richiestasotto forma di schema XML. Il client, a sua volta, creerà un messaggio SOAP conforme allo schema XMLtrovato nel documento WSDL e invierà una richiesta all’host che dispone del servizio.Per fare questo il modello dei Web Services utilizza un set base di protocolli disponibili ovunque.(permettendo così l’interoperabilità tra piattaforme molto diverse e mantenendo comunque la possibilità diutilizzare protocolli più avanzati e specializzati per effettuare compiti specifici.)Riassumendo i protocolli alla base del modello dei Web Services sono: • UDDI (per la pubblicazione e al ricerca dei WebService) • WSDL (per al descrizione e la formalizzazione del servizio offerto) • SOAP (per lo scambio dei dati e linvocazione di procedure remote) • HTTP (per il trasporto) • XML (per la codifica dei dati e dei protocolli)UDDI (Universal Description,Discovery, Integration) è un servizio basato su XML che permette agli utentidei Web services di localizzarli una sorta di “pagine gialle” dei Web services. Senza UDDI, due applicazionipotrebbero comunicare solo se già si conoscessero, conoscessero i servizi offerti e la loro localizzazione;UDDI fornisce un database distribuito su cui si possono registrare le aziende ed i servizi da loro esposti.L’interrogazione del database può essere fatta con il browser (ad esempio su uddi.microsoft.com) o attraversoUDDI API che forniscono ai programmatori un modo semplice per interagire con i dati archiviati in unregistro UDDI. Le API UDDI consistono di tre parti principali: • Inquiry, per permettere agli utenti di effettuare ricerche all’interno del registro. • Publishing, per permettere ai publisher di inserire, modificare, cancellare informazioni rispetto ai propri servizi. • Replication, riservate alla comunicazione server-to-server per la gestione dei registri. 7
  8. 8. Durante la fase di Inquery (richiesta) ci si puo muovere per Busines, Service o tModel.La BusinessEntity rappresenta lazienda che ha servizi da offrire e quindi e presente nel repository. Una voltaeffetuata la query si ritrovano nella risposta la lista dei businessServices che tale azienda espone sulla rete eduna serie di proprieta tra cui la firma digitale. Per ogni BusinessService si puo leggere il tModel che neespone una serie di specifiche relative al servizio ed il proprio design. (Naturalmente i messaggi sonorappresentati in XML e la loro trasmissione si basa su SOAP).La struttura dati di un registro UDDIquindi UDDI è utilizzato da due tipi di utenti • Publisher: compagnia che offre Web services • Client: utente o compagnia che ricerca un Web servicee le informazioni in UDDI sono divise in tre categorie principali (analogia con elenchi del telefono): • White pages Contengono informazioni sui contatti e gli indirizzi del publisher. • Yellow pages Contengono informazioni sui diversi servizi disponibili organizzati per categorie di business, per tipo di servizi, … • Green pages Contengono informazioni sul servizio stesso (possono eventualmente anche contenere il codice WSDL del servizio).In un certo senso UDDI è molto simile a DNS (Domain Name System) la differenza è che DNS lavora ad unlivello più basso, perché risolve indirizzi IP, mentre UDDI lavora a livello più alto perché risolve servizi. 8
  9. 9. XMLSOAP, WSDL si fondano pesantemente su XML e in effetti un messaggio SOAP non è altro che undocumento XML che segue determinate regole. Per maneggiare un documento SOAP si possono usarequindi gli stessi strumenti utilizzati per i documenti XML. Si procederà pertanto ad illustrare cos’è e come siusa un documento XML.XML, ovvero l’ eXtendible Markup Language è nato nel 1997 come sottoinsieme dello StandardGeneralized Markup Language (SGML).XML è un metalinguaggio, cioè un linguaggio usato per definire nuovi linguaggi di marcatura. SGML XML HTML WSDL XHTML SOAP WMLLe caratteristiche fondamentali sono: fornisce un formato per lo scambio di informazioni indipendente dalle applicazioni e dalle piattaforme utilizzate. (comunicazione fra sistemi eterogenei). Un documento XML è un file di testo, quindi può essere facilmente trasmesso via Internet tramite il protocollo http (firewall friendly). In un documento XML l’informazione può essere vista come una struttura di dati astratta fatta ad albero, questo facilita lo sviluppo di applicativi in grado di processare il documento (facile da processare, parser molto leggeri). Un documento XML può essere convenientemente descritto attraverso una DTD (Document Type Definition) o in maniera ancor più espressiva attraverso un XML Schema.(capacità di fornire una struttura ai documenti e di rendere i dati autodescrittivi.) Document <?xml version="1.0" ?> <utente> <nome>nelson</nome> <email>nelson@tin.it </email> utente </utente> nome email 9
  10. 10. XML è utilizzato soprattutto nei seguenti scenari: • Pubblicazione di documenti sul Web; • Codifica e scambio di dati, anche prelevati da database relazionali, tra sistemi eterogenei; • Configurazione di sistemi; • Applicazioni specifiche: sono stati definiti dei linguaggi di marcatura xml per rappresentare informazioni di tipo particolare. Ad esempio: o MathML per la notazione matematica o DocBook per documenti tipo Latex o SVG - grafica vettoriale o SOAPAlla base di XML sta il markup (o marcatore o identificatore o codice o tag), che genericamente è usato perdescrivere degli elementi. Tag di apertura <utente> Elemento <nome> “nome” nelson </nome> Elemento Elemento <email> “utente” “email” nelson@tin.it </email> Tag di chiusura </utente>Un documento XML deve innanzitutto essere ben formato, ossia rispettare tutte le regole di sintassi previstedal linguaggio:Deve iniziare con la dichiarazione XML del tipo: <?xml version="1.0"?> <libri> <? xml version=“1.0” ?> <libro cod=”23-456-5456”> Deve avere un unico elemento radice. <autore> Marco </autore> <titolo> Java </titolo> <foto src=”c23.jpg” /> Tutte le tag che si aprono debbono chiudersi. </libro> <libro cod=”44-488-1677”> Se un elemento è vuoto, ossia non contiene nessun <autore> gianni </autore> elemento di testo al suo interno, può essere anche <titolo> reti </titolo> rappresentato con una forma speciale di tag: <foto /> <foto src=”c44.jpg” /> </libro> Si deve rispettare il maiuscolo/minuscolo (case-sensitive) </libri> Tutti gli elementi debbono essere annidati propriamente Tutti i valori degli attributi vanno espressi tra “” Tutti i caratteri speciali (minore <, maggiore >, etc) sono riportati come “Entità” del tipo &lt, &gt 10
  11. 11. Il problema della unicità delle tag. A questo proposito sono nati i namespaces che permettono la creazione e l’uso di tag con lo stesso nome ma in riferimento a significati ed ambienti diversi. • Ogni elemento può contenere dichiarazioni di namespaces, la cui validità è estesa a tutto il contenuto dell’elemento stesso. • La dichiarazione del namespace viene inserita nei tag di apertura, in modo simile a un attributo. • Il namespace è espresso in una Uniform Resource Identifier (tipicamente una URL di internet, che non viene mai usata dal parser, ma serve solo come identificativo unico). • Ogni prefisso usato in un documento è associato ad un unico namespace. • L’associazione del prefisso al namespace per una tag è fatta con l’attributo xmlns <prfx:name xmlns:prfx="uri"> Questa dichiarazione di namespace indica che tutti gli elementi il cui nome è prefissato da prfx: andranno considerati appartenenti al namespace identificato in modo univoco da uri. Il linguaggio HTML è anch’esso definito ed associato ad un namespace che i browser conoscono e sanno come interpretare: <html:html xmlns:html=”http://www.w3.org/TR/REC-html40”> <html:head> <html:title>Titolo della Pagina</html:title> </html:head> <html:body> Il namespace per lutilizzo dei fogli di stile è: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> Gli elementi della sintassi XML Schema provengono dal namespace: <xs:schema xmlns:xs=“http://www.w3c.org/2001/XMLSchema“> • La dichiarazione di namespace standard indica il namespace per tutti gli elementi non prefissati <name xmlns=”uri”> Ci possono essere più namespaces attivi per lo stesso elemento, ma solo uno standard: <name xmlns="uri1" xmlns:prfx1="uri2" xmlns:prfx2=”uri3”> In un messaggio SOAP abbiamo più namespace attivi: <soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/ “ xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <ns1:saluto soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ xmlns:ns1="urn:SalutoWS"> <ns1:arg0 xsi:type="xsd:string"> Nicola </ns1:arg0> </ns1:saluto> </soapenv:Body> </soapenv:Envelope>Un documento XML deve essere valido cioè deve rispettare una “grammatica”. Infatti, affinché i datiscambiati in formato XML possono essere interpretati allo stesso modo da tutti i partecipanti di unacomunicazione, è necessario che venga codificato un unico documento che funga da prototipo. Tale 11
  12. 12. prototipo ha lo scopo di definire una volta per tutte, la struttura e la grammatica degli elementi checompongono i documenti scambiati.Ci sono due modi per definire una grammatica per i documenti XML : documenti Data Type Definition (file con estensione .dtd) realizzati usando un linguaggio che implementa le grammatiche estese di Backus-Naur (EBNF). (recentemente DTD è stata sostituita da XML Schema) documenti del tipo XMLSchema, che come i DTD, permettono di definire tutti gli aspetti semantici da verificare in un documento XML e di specificare il tipo di dato di ciascun elemento o attributo. Il loro vantaggio rispetto ai DTD è di costituire essi stessi un documento XML, di definire oltre quaranta tipi di dato contro la decina permessa dai DTD, di essere orientati agli oggetti, permettere di definire dei tipi di dati complessi, stabilire dei vincoli sul contenuto degli elementi e dei loro attributi.Ad esempio la struttura di un messaggio soap è descritto dallo schema seguente (è solo una parte delloschema presente in “http://schema.xmlsoap.org/soap/envelope/”):<?xml version="1.0" encoding="UTF-8" ?>- <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/" targetNamespace="http://schemas.xmlsoap.org/soap/envelope/"> - <!-- Envelope, header and body --> <xs:element name="Envelope" type="tns:Envelope" /> - <xs:complexType name="Envelope"> - <xs:sequence> <xs:element ref="tns:Header" minOccurs="0" /> <xs:element ref="tns:Body" minOccurs="1" /> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xs:sequence>…dove ad esempio il frammento di codice:<xs:element ref="tns:Header" minOccurs="0" /><xs:element ref="tns:Body" minOccurs="1" />stabilisce che l’elemento Envelope deve contenere almeno un elemento figlio Body, mentre l’elemento figlioHeader è opzionale avendo un numero di occorrenze di valore pari a 0.Quindi un documento XML contenente la sezione Envelope ma senza la sezione Body non potrà esserevalidato come messaggio SOAP perché, anche se formalmente corretto (documento XML ben formato), nonrispetta la grammatica dello schema.La sintassi ovvero il namespace per ottenere un legame tra il documento XML (da validare come messaggioSOAP) e lo Schema (che definisce la grammatica di SOAP) è la seguente:<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/ soap/envelope”/> 12
  13. 13. Questa istruzione inoltre indica che tutti gli elementi il cui nome è prefissato da SOAP-ENV: andrannoconsiderati appartenenti al namespace identificato in modo univoco dal uri= http://schemas.xmlsoap.org/soap/envelope.Ecco un esempio di documento XML valido come messaggio Soap:<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:Add xmlns:m="Sum-URI"> <Param1>3</Param1> <Param2>4</Param2> </m:Add> </SOAP-ENV:Body> </SOAP-ENV:Envelope> SOAP (Simple Object Access Protocol) 13
  14. 14. SOAP come già detto è un protocollo che permette di scambiare messaggi tra un mittente e un ricevente. Imessaggi SOAP sono basati sul modello della richiesta/risposta (request/response): il client richiede al serverd’invocare l’esecuzione del metodo di un oggetto e il server spedisce la risposta al client.SOAP si propone come protocollo universale per la trasmissione dei dati, di chiamate a procedure remote, epiù in generale come framework per lo scambio di informazione.I messaggi sono codificati con XML e, di solito, incapsulati in richieste HTTP, come esemplificato in figuraStruttura di un messaggio SOAP SOAP Message HTTP Headers SOAP Envelope HEADER BODYEd ecco un esempio di messaggio SOAP incorporato in una richiesta HTTP di un client:POST /axis/Calculator.jws HTTP/1.0Content-Type: text/xml; charset=utf-8Accept: application/soap+xml, application/dime, multipart/related, text/*User-Agent: Axis/1.1Host: 127.0.0.1Cache-Control: no-cachePragma: no-cacheSOAPAction: ""Content-Length: 420<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body> <add soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <op1 xsi:type="xsd:int">4</op1> <op2 xsi:type="xsd:int">8</op2> </add></soapenv:Body></soapenv:Envelope>Le prime righe mostrano gli header HTTP utilizzati per trasportare un messaggio SOAP: 14
  15. 15. POST /axis/Calculator.jws HTTP/1.0Content-Type: text/xml; charset=utf-8Accept: application/soap+xml, application/dime, multipart/related, text/*User-Agent: Axis/1.1Host: 127.0.0.1Cache-Control: no-cachePragma: no-cacheSOAPAction: ""Content-Length: 420Per trasmettere dati con protocollo SOAP è consigliabile usare il metodo POST che trasmette il contenutodella richiesta nel corpo del messaggio di richiesta HTTP piuttosto che sull’URL.Eventuali header personalizzati come SOAPAction vengono trasmessi in coda agli header propri delprotocollo di trasporto e di conseguenza viene ricevuto ed elaborato dal server.Il campo SOAPAction serve per fornire informazioni sullo scopo del payload SOAP in modo che i firewallpossano elaborare preliminarmente l’intestazione HTTP per assicurare l’autorizzazione della request.Se l’intestazione HTTP soddisfa i requisiti dei firewall la chiamata SOAP può essere inoltrata al serverappropriato. E se il server SOAP è in grado di elaborare la richiesta, viene inviata al client la seguenterisposta HTTP:HTTP/1.1 200 OKSet-Cookie: JSESSIONID=3B6289A63CF8B3C07E08015EC59CDCBC; Path=/axisContent-Type: text/xml;charset=utf-8Date: Thu, 17 Jun 2004 21:06:21 GMTServer: Apache-Coyote/1.1Connection: close<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body> <addResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <addReturn xsi:type="xsd:int">12</addReturn> </addResponse></soapenv:Body></soapenv:EnvelopeHTTP/1.1 200 OKIndica che indipendentemente dall’esito della elaborazione del payload SOAP (che è una chiamata ad unmetodo) non si è verificato nessun errore nel livello di comunicazione (trasporto)Analizziamo ora le righe che costituiscono il messaggio SOAP vero e proprio, questo è composto da: SOAP envelope, un elemento radice che definisce il contenuto del messaggio. o Si può considerarlo come una specie di “busta” che racchiude tutto il messaggio. o Ha un attributo name, per identificare il messaggio. o Contiene la dichiarazione dei namespace. o Può contenere un elemento header. o Deve contenere un elemento body. o Ha un attributo encodingStyle da utilizzare per definire l’encoding degli elementi del messaggio che verranno serializzati. SOAP header (opzionale), che contiene informazioni relative all’intestazione del messaggio. Il suo scopo è quello di trasportare informazioni non facenti parte del messaggio, destinate agli 15
  16. 16. “intermediari”, cioè alle varie parti che il messaggio attraverserà per arrivare al suo destinatario finale. SOAP body, che contiene informazioni sul messaggio vero e proprio. o Il corpo di un messaggio SOAP è obbligatorio. o Deve avere un attributo name o Può avere un attributo encodingStyle o Un figlio particolarmente importante di body è SOAP fault. L’elemento SOAP fault è usato per indicare gli errori che possono intercorrere durante la trasmissione del messaggio.È opportuno evidenziare che SOAP definisce soltanto la struttura dei messaggi non il loro contenuto. I tagper descrivere una richiesta di elaborazione o un risultato vengono definiti in uno schema specifico edutilizzati allinterno della struttura SOAP sfruttando il meccanismo dei namespace. Il protocollo SOAPdefinisce la struttura dei messaggi SOAP attraverso due namespace: soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" per la envelope soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" per il meccanismo di serializzazioneCome detto l’envelope è l’elemento che racchiude l’intero messaggio e può contenere zero o più elementiheader e deve contenere un solo elemento body.Esempio:<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> <t:Transaction xmlns:t="http://www.trading.org/tr " SOAP-ENV:actor="http://mysito.it/server“ SOAP-ENV:mustUnderstand=“1“> 15_USER_72 </t:Transaction > </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="http://www.trading.org/ex"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body></SOAP-ENV:Envelope>Nel seguente listato compare un solo elemento opzionale <header>L’utilizzo degli elementi header nel contenitore envelope di un messaggio SOAP permette di estendere unmessaggio in maniera flessibile e decentralizzata. Può essere usato, per esempio, per implementare sistemi diautenticazione, gestione delle transazioni, sistemi per il pagamento. Vediamo come:Lo scenario è il seguente:un messaggio SOAP può viaggiare dal mittente al ricevente passando attraverso una serie di intermediari (onodi SOAP), ovvero delle applicazioni SOAP che sono anch’esse in grado di ricevere e spedire messaggi.Un nodo SOAP che riceve un messaggio deve processarlo e deve descrivere i cambiamenti apportati almessaggio aggiungendo dei blocchi header. Durante il “percorso” i nodi SOAP analizzano gli header. Se unosoltanto dei blocchi header non è comprensibile da un nodo che lo deve processare viene generato un erroreSOAP con codice "env:MustUnderstand" (e da questo momento il messaggio non viene più processato dagliintermediari ma giunge al nodo destinatario finale che si occupa di processare l’elemento body.)altrimenti i nodi intermediari modificano il messaggio (anche il contenuto) durante il processing delmessaggio al fine di fornire alcuni servizi ad esempio nodi che si occupano di fornire servizi di sicurezza, di 16
  17. 17. annotazione, di manipolazione del contenuto e lo trasmette inserendo un nuovo header per il nodosuccessivo. In altre parole quando un messaggio deve transitare per più nodi si creano degli header perciascuno dei nodi intermediari.SOAP header può contenere infiniti blocchi header figli, ed ogni blocco header deve avere: • Almeno un attributo namespace Necessari per specificare la grammatica degli elementi. Ad esempio l’elemento chiamato <Transaction> che compare nel listato è definito nel namespace http://www.trading.org/tr. Il significato del contenuto di questo elemento sarà noto solo a chi conosce questo namespace. • Un attributo actor Che può essere applicato in ogni header per specificare, con una URI, il nodo SOAP (intermediario) che deve processare il messaggio; può assumere anche i seguenti valori: o none: l’header in questione non deve essere elaborato da nessun nodo soap o next: l’header in questione può essere elaborato da tutti i nodi incontrati nel tragitto mittente- ricevente o anonymous: l’header in questione può essere elaborato solo dal nodo finale.Tale valore non viene espresso esplicitamente, ma viene assunto quando nell’header non compare l’attributo actor. • Un attributo mustUnderstand Serve per indicare se il processing di un messaggio è obbligatorio o meno. o Se posto a “1”, indica che l’attore deve elaborare l’header. Se questo non è possibile, l’attore deve generare un errore. o Se posto a “0” (default) indica che l’elaborazione del header è opzionale.Quindi in breve gli intermediari o i soap nodi sono applicazioni che possono processare parti di unmessaggio SOAP mentre questo si sposta dal suo punto d’origine alla destinazione.E i vantaggi offerti da questo modello sono innumerevoli: • Rende possibile aggiungere servizi lungo il percorso del messaggio. • Facilita l’implementazione della sicurezza, perché consente di far passare il messaggio in domini affidabili e conosciuti; • Rappresenta un superamento dell’architettura client-server, aumentando l’efficienza in numerose situazioni (es: smistamento della posta) • Facilita la ricostruzione dell’esatto cammino attraversato da un messaggio, consentendo di verificare la presenza di bottlenecks.Per quanto riguarda l’elemento body esso contiene le informazioni per il destinatario finale del messaggio. 17
  18. 18. Il contenuto di <Body> è definito dall’implementatore del messaggio tramite l’uso di un particolarenamespace. Il destinatario dovrà elaborare i dati e obbedire alla loro semantica, specificata dal namespacedi appartenenza.<SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="http://www.trading.org/ex"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body>Gestione degli erroriNella comunicazione tra un client ed un server, a volte può succedere che qualcosa non funzioni, e siverifichino di conseguenza degli errori, anche a livello in cui opera SOAP. Per esempio, una richiesta nonpuò essere adeguatamente servita, oppure l’applicazione invocata può sollevare degli errori.Le specifiche di SOAP permettono di gestire queste condizioni d’errore, introducendo un opportunoelemento chiamato Fault.L’elemento <Fault> serve a fornire informazioni su errori derivanti dall’elaborazione del messaggio, puòtrovarsi solo all’interno del body e non può comparire più di un volta. <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:MustUnderstand</faultcode> <faultstring>SOAP Must Understand Error</faultstring> <faultactor>http://sitoCheHaSbagliato.it/server</faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body>Il contenuto dell’elemento <Fault> è: • Un elemento <faultcode>, obbligatorio. Che fornisce un codice di identificazione per l’errore, ad uso del software. • Un elemento <faultstring>, obbligatorio. Che fornisce una descrizione testuale dell’errore. • Un elemento <faultactor>, obbligatorio. Che specifica l’attore che ha generato l’errore, se non si tratta del destinatario (cioè se l’errore è stato provocato dalla mancata elaborazione di una header ). • Un elemento <Detail> che contiene informazioni di errore specifiche dell’applicazione e relative al contenuto del body. Deve essere presente nel caso in cui il body non sia stato processato correttamente. 18
  19. 19. Il protocollo SOAP è la soluzione per tutto?Purtroppo, alla semplicità e alla facilità duso di Soap si contrappongono linefficienza delle comunicazionidel suo formato testo (la serializzare in XML/deserializzare da XML del payload informativo, per molielevate di dati, riduce la velocità delle applicazioni) e il suo limitato insieme di funzionalità. Ad esempio,Soap non offre nessun supporto per gli scambi transazionali e le specifiche proposte non comprendono lasicurezza e la consegna garantita dei messaggi.SOAP non è la soluzione per tutto, non rimpiazza le altre tecnologie per il distributed computing, come EJB,RMI, Corba, DCOM, etc. In molti casi infatti usare un protocollo di comunicazione dipendente dallapiattaforma è la soluzione ottimale (ad esempio per applicazioni intranet che richiedono alte performance enon hanno esigenze di interoperabilità).Esistono molte implementazioni di SOAP:Apache SOAP 2.2IBM SOAP4JMicrosoft SOAP toolkitApache Axis Toolkit SOAP "user friendly" supporta e genera WSDL e codice Java ClientIl futuro prossimo di SOAPdovrebbe essere dominato da un nuovo concetto: il WS STACK.Il lavoro di WS STACK si concentra su aspetti legati alla comunicazione sicura attraverso firewall eallutilizzo di una sorta di XML firmato ed autorizzato. 19
  20. 20. Sviluppo di un Web Servizio attraverso il toolkit Apache Axis 1.1Apache Axis 1.1 rappresenta l’evoluzione di Apache SOAP 2.2 da cui eredita le caratteristiche di base.Le novità rispetto al predecessore sono: È perfettamente compatibile con Microsoft SOAP Toolkit. Supporta le specifiche WSDL 1.1. Supporto delle specifiche SOAP 1.2. Supporto per la pubblicazione automatica dei servizi (Java Web Service). Generazione automatica (direttamente da un browser Internet) del documento WSDL per un servizio pubblicato. Tool WSDL2Java e Java2WSDL.L’obiettivo dell’applicazione è fornire un servizio remoto che permetta di ottenere il risultato diun’operazione matematica utilizzando il metodo appropriato e passandogli i parametri corretti. Lefunzionalità supportate sono 2: somma “metodo add()” e sottrazione “metodo sub()”.Il servizio web verrà poi utilizzato da un’applicazione java “CalcClient” sull’application server Tomcat.Lato ServerVediamo il codice sorgente del server, del progetto Calculator:// file Calculator.javapublic class Calculator { public int add(int i1, int i2) { return i1 + i2; }public int subtract(int i1, int i2) { return i1 - i2; }}A questo punto occorre effettuare il deployment del servizio. In questo modo si istruisce l’engine di Axisaffinché in corrispondenza di una determinata richiesta (sottoforma di messaggio SOAP) istanzi la classe e nerichiami il relativo metodo.La prima novità di Apache Axis rispetto ad Apache SOAP riguarda proprio la pubblicazione di questoservizio. Apache Axis consente di pubblicare automaticamente (Java Web Service) un servizio SOAP.Per fare ciò sono sufficienti due semplici operazioni: 1) Copiare il file sorgente Java “calculator.java” nella sottodirectory “webappsaxis” del web server Tomcat 2) Cambiare l’estensione del file sorgente da .java a .jws 3) abilitare il servizio calculator andando in http://localhost:8080/axis/Calculator.jwsCon queste elementari operazioni il servizio è già pronto per accogliere le richieste dei client e fornigli unarisposta. Naturalmente potevamo pubblicare il servizio anche attraverso un file WSDL scritto da noi.In particolare, per l’esempio in questione, la rappresentazione WSDL del nostro servizio generataautomaticamente da Axis ha il seguente contenuto: <?xml version="1.0" encoding="UTF-8" ?>- <wsdl:definitions targetNamespace="http://localhost:8080/axis/Calculator.jws" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" 20
  21. 21. xmlns:impl="http://localhost:8080/axis/Calculator.jws" xmlns:intf="http://localhost:8080/axis/Calculator.jws" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">- <wsdl:message name="addRequest"> <wsdl:part name="i1" type="xsd:int" /> <wsdl:part name="i2" type="xsd:int" /> </wsdl:message>- <wsdl:message name="subtractRequest"> <wsdl:part name="i1" type="xsd:int" /> <wsdl:part name="i2" type="xsd:int" /> </wsdl:message>- <wsdl:message name="subtractResponse"> <wsdl:part name="subtractReturn" type="xsd:int" /> </wsdl:message>- <wsdl:message name="addResponse"> <wsdl:part name="addReturn" type="xsd:int" /> </wsdl:message>- <wsdl:portType name="Calculator"> - <wsdl:operation name="add" parameterOrder="i1 i2"> <wsdl:input message="intf:addRequest" name="addRequest" /> <wsdl:output message="intf:addResponse" name="addResponse" /> </wsdl:operation> - <wsdl:operation name="subtract" parameterOrder="i1 i2"> <wsdl:input message="intf:subtractRequest" name="subtractRequest" /> <wsdl:output message="intf:subtractResponse" name="subtractResponse" /> </wsdl:operation> </wsdl:portType>- <wsdl:binding name="CalculatorSoapBinding" type="intf:Calculator"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> - <wsdl:operation name="add"> <wsdlsoap:operation soapAction="" /> - <wsdl:input name="addRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encodin g/" namespace="http://DefaultNamespace" use="encoded" /> </wsdl:input> - <wsdl:output name="addResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encodin g/" namespace="http://localhost:8080/axis/Calculator.jws" use="encoded" /> </wsdl:output> </wsdl:operation> - <wsdl:operation name="subtract"> <wsdlsoap:operation soapAction="" /> - <wsdl:input name="subtractRequest"> 21
  22. 22. <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encodin g/" namespace="http://DefaultNamespace" use="encoded" /> </wsdl:input> - <wsdl:output name="subtractResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encodin g/" namespace="http://localhost:8080/axis/Calculator.jws" use="encoded" /> </wsdl:output> </wsdl:operation> </wsdl:binding> - <wsdl:service name="CalculatorService"> - <wsdl:port binding="intf:CalculatorSoapBinding" name="Calculator"> <wsdlsoap:address location="http://localhost:8080/axis/Calculator.jws" /> </wsdl:port> </wsdl:service> </wsdl:definitions>Quindi per testare il corretto funzionamento del servizio implementiamo un client.Possiamo scegliere un qualsiasi linguaggio per richiamare il Web Service appena pubblicato. Visto che ilnostro ambiente di lavoro è java e che Axis mette a disposizione l’API JAX-RPC per effettuare chiamateRPC su SOAP il nostro client sarà scritto in java.Lato ClientIl codice del client è il seguente:// file CalcClient.javapackage samples.userguide.example2 ;import org.apache.axis.client.Call;import org.apache.axis.client.Service;import org.apache.axis.encoding.XMLType;import org.apache.axis.utils.Options;import javax.xml.rpc.ParameterMode;public class CalcClient{ public static void main(String [] args) throws Exception { Options options = new Options(args); String endpoint = "http://localhost:" + options.getPort() + "/axis/Calculator.jws"; args = options.getRemainingArgs(); if (args == null || args.length != 3) { System.err.println("Usage: CalcClient <add|subtract> arg1 arg2"); return; } String method = args[0]; if (!(method.equals("add") || method.equals("subtract"))) { System.err.println("Usage: CalcClient <add|subtract> arg1 arg2"); 22
  23. 23. return; } Integer i1 = new Integer(args[1]); Integer i2 = new Integer(args[2]); Service service = new Service(); Call call = (Call) service.createCall(); call.setTargetEndpointAddress( new java.net.URL(endpoint) ); call.setOperationName( method ); call.addParameter( "op1", XMLType.XSD_INT, ParameterMode.IN ); call.addParameter( "op2", XMLType.XSD_INT, ParameterMode.IN ); call.setReturnType( XMLType.XSD_INT ); Integer ret = (Integer) call.invoke( new Object [] { i1, i2 }); System.out.println("Got result : " + ret); }}Dopo la compilazione con il comando:javac CalcClient.javapossiamo eseguire CalcClient dalla linea di comando passando come parametri:la porta di comunicazione (es: 8080), l’azione da eseguire (es: add) e i due operandi (es: 2 e 5).java CalcClient -p8080 add 2 5Analizzando il codice del client appare subito evidente l’utilizzo di due oggetti: Call e Service. Service service = new Service(); L’oggetto Service viene utilizzato come punto di partenza per l’accesso ad un servizio SOAP. Attraverso opportuni costruttori e metodi è possibile ricavare informazioni sul servizio direttamente dal corrispondente documento WSDL, nel nostro caso usiamo un costruttore senza parametri perché specifichiamo manualmente tutti i campi necessari per eseguire il servizio. Call call = (Call) service.createCall(); L’oggetto Call viene utilizzato per invocare un servizio, attraverso il metodo createCall() applicato all’oggetto di tipo Service, si crea un nuovo oggetto di tipo Call vuoto. call.setTargetEndpointAddress( new java.net.URL(endpoint) ); In questo modo si imposta l’URL del servizio. call.setOperationName( method ); In questo modo si imposta il metodo da richiedere al servizio call.addParameter( "op1", XMLType.XSD_INT, ParameterMode.IN ); call.addParameter( "op2", XMLType.XSD_INT, ParameterMode.IN ); Aggiunge i parametri specificati alla lista dei parametri da inviare al metodo associato all’oggetto di tipo Call in questione. call.setReturnType( XMLType.XSD_INT ); Con questo metodo si definisce il tipo del risultato di ritorno presente nella risposta SOAP. 23
  24. 24. Integer ret = (Integer) call.invoke( new Object [] { i1, i2 });Con il metodo invoke si invoca il metodo precedentemente specificato per l’oggetto di tipo Call,passandogli come parametro gli argomenti del metodo stesso. Il valore di ritorno di tale metodo è unoggetto di tipo Object che rappresenta il risultato dell’operazione richiesta al servizio SOAP. 24
  25. 25. Test e verificaSistema Hardware e SoftwareI test realizzati sono stati eseguiti su un computer dotato di una CPU AMD K6 350MHz con 128 MB dimemoria RAM e con sistema operativo Microsoft Windows 98.Pacchetti installati: java2 sdk standard edition 1.4.0 (ambiente di sviluppo) Jcreator LE v2.00 (editor java) Tomcat5.0 (application server) Axis-1_1 (api web service)Installazione java2 sdk: Dopo l’installazione configurare il PATH nel file autoexec.bat: Con l’utility di configurazione del sistema andare in autoexec.bat e aggiungere e selezionare: SET PATH=%PATH%;C:j2sdk1.4.0-rcbinInstallazione Tomcat5.0 Scegliere come directory di destinazione: tomcat Dopo l’installazione aggiungere nel file autoexec.bat: SET JAVA_HOME=C:j2sdk1.4.0-rc (nota su win98 non si deve avviare come servizio quindi dopo linstallazione lanciare lutilità di configurazione del sistema e nel menù esecuzione automatica deselezionare tomcat5 inoltre nella cartella tomcatbin trovare il file startup.bat e selezionare premere il tasto destro del mouse e andare nella scheda memoria quindi selezionare memoria ambiente 4096 e avviare tomcat5 con startup.bat) per verificare lavviamento di Tomcat accedere con un browser Web (Microsoft IExplorer o Netscape Communicator) allURL: http://localhost:8080/ (nota su win 98 per spegnere tomcat5 utilizzare shutdown.bat “anche qui memoria ambiente a 4096”)Installazione di axis-1_1: dopo aver unzippato tra le varie cartelle andare in webapps e copiare la cartella axis e quindi incollarla nella cartella di webapps di tomcat. Sempre in axis copiare la cartella lib e incollarla in C:tomcatwebappsaxis Sempre in axis copiare la cartella samples in C:tomcatwebappsaxis scaricare jaf-1_0_2 dal sito sun e copiare il file activation.jar nella cartella C:tomcatcommonlib 25
  26. 26. Per comodità creiamo un file batch che setti tutti i percorsi necessari al compilatore java:creare in C:tomcatwebappsaxis il seguente file start.bat :set AXIS_HOME=c:tomcatwebappsaxisset AXIS_LIB=%AXIS_HOME%libset AXIS_SAMPLE=%AXIS_HOME%set AXISCLASSPATH=%AXIS_LIB%axis.jar;%AXIS_LIB%commons-discovery.jar;%AXIS_LIB%commons-logging.jar;%AXIS_LIB%jaxrpc.jar;%AXIS_LIB%saaj.jar;%AXIS_LIB%log4j-1.2.8.jar;%AXIS_LIB%xml-apis.jar;%AXIS_LIB%xercesImpl.jar;%AXIS_SAMPLE% 26
  27. 27. Avvio del test ovvero pubblicazione del servizio Calculator e suo utilizzo attraverso un client, quindi verifica dei messaggi SOAP scambiati tra client e server attraverso l’utility TCP monitor. avviare tomcat andare in http://localhost:8080/axis/ controllare con validate se sono caricati i componenti necessari. Copiare Calculator.java presente in axissamplesuserguideexample2 in C:tomcatwebappsaxis Rinominare Calculator.java in Calculator.jws Abilitare il servizio calculator con http://localhost:8080/axis/Calculator.jws 27
  28. 28. Prima di utilizzare il servizio calculator avviamo TCPmonitor e mettiamoci in ascolto sulla porta 8081 pervedere i msg scambiati. Quindi avviamo TCPmonitor con la seguente procedura: C:tomcatwebappsaxis>command.com /e:4096 C:tomcatwebappsaxis>start java -cp %AXISCLASSPATH% org.apache.axis.utils.tcpmon 28
  29. 29. Selezionare HTTP proxysupport e mettiamoci in ascolto sulla porta 8081Adesso utilizziamo il servizio utilizzando come client un nuovo processo attivabile mediante l’apertura diuna nuova finestra dos dove richiamiamo il servizio attraverso le seguenti istruzioni:C:tomcatwebappsaxis>command.com /e:4096C:tomcatwebappsaxis>startjava -cp %AXISCLASSPATH% samples.userguide.example2.CalcClient -p8080 add 2 5 29
  30. 30. Abbiamo richiesto il servizio di somma di due interi. Nella figura sottostante i messaggi soap scambiati: 30
  31. 31. Messaggio SOAP di richiesta inviato dal client:POST /axis/Calculator.jws HTTP/1.0Content-Type: text/xml; charset=utf-8Accept: application/soap+xml, application/dime, multipart/related, text/*User-Agent: Axis/1.1Host: 127.0.0.1Cache-Control: no-cachePragma: no-cacheSOAPAction: ""Content-Length: 420<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <add soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <op1 xsi:type="xsd:int">4</op1> <op2 xsi:type="xsd:int">8</op2> </add> </soapenv:Body></soapenv:Envelope>Messaggio SOAP di risposta inviato dal server:HTTP/1.1 200 OKSet-Cookie: JSESSIONID=3B6289A63CF8B3C07E08015EC59CDCBC; Path=/axisContent-Type: text/xml;charset=utf-8Date: Thu, 17 Jun 2004 21:06:21 GMTServer: Apache-Coyote/1.1Connection: close<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <addResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <addReturn xsi:type="xsd:int">12</addReturn> </addResponse> </soapenv:Body></soapenv:Envelope 31
  32. 32. ConclusioniDai test effettuati si è potuto osservare che Apache Axis permette di lavorare ad un livello di astrazioneelevato, evitando così di dover maneggiare direttamente lenvelope SOAP. Con Axis è possibile, dunque,implementare Web Services e sviluppare client di servizi in maniera molto semplice.In pratica la pubblicazione di un servizio web con Axis si articola di due passi: Creare il codice che descrive il servizio attraverso un linguaggio supportato da Apache Axis, (ad esempio Java). Tale sorgente Java non ha nulla di speciale che lo renda in qualche modo assimilabile ad un servizio web utilizzabile in remoto. La potenza di questa implementazione è anche questa, non dover utilizzare codice particolare per definire i servizi web, sarà il cliente a richiamare il servizio utilizzando SOAP. A questo punto il servizio web è stato scritto e compilato, ora è necessario pubblicarlo. Per far questo nella versione Apache SOAP (antecedente ad Axis) dovevamo creare un deployment descriptor del servizio cioè un file XML contenente le specifiche per la pubblicazione. Ad esempio, per un implementazione Java, il file contiene principalmente il nome del servizio, il nome della classe che fornisce il servizio e il nome del metodo che fornisce il servizio. Con Axis il deployment descriptor è un file WSDL generato automaticamente.Quindi la gestione dei messaggi SOAP, con relative specifiche, è del tutto trasparente allutente che ha scrittoil codice del server. Inoltre al codice che fornisce il servizio non bisogna aggiungere nulla che lo renda inqualche modo compatibile ad un servizio web. Quindi in teoria ogni sistema informativo potrà esporreservizi utilizzando applicazioni già esistenti senza dover procedere ad un restyling di parti di codice.RiferimentiWeb Services Conceptual Architecture (WSCA 1.0) May 2001By Heather Kreger IBM Software GroupTutorial introduttivo dell’IBM “Web Services - The Webs next revolution”http://www.cs.aue.auc.dk/~hk/wsbasics-a4.pdfAXIS http://xml.apache.org/axisSOAP http://www.w3.org/TR/SOAP/UDDI http://www.uddi.org/WSDL http://www.w3.org/TR/wsdlXML Schema Part 1 http://www.w3.org/TR/xmlschema-1/XML Schema Part 2 http://www.w3.org/TR/xmlschema-2/Introduction to WSDL http://www.learnxmlws.com/tutors/wsdl/wsdl.aspxJava Web Service http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-soap_p.htmlJava Web Service http://www.javaportal.it/cws.htmRisorse in C++ su SOAP http://www.cs.fsu.edu/~engelen/soap.htmlRisorse su SOAP http://www.soaprpc.com/WebServices http://www.mokabyte.it numero 62,63,64Risorse su Axis http://xml.apache.org/axis/ Author: Nelson Firmani Last update: 30/04/2002 32

×