Le lingue
Pagine
Legale
2. Architettura della Prima Generazione Web RPCInternet SQL HTTPHTTPWebWebApplicationClient Server Backend Servers ClientMiddle tier Backend Web/HTTP ServerBrowserDocumentistatici http Applicazione CGI, PHPDBMS ISAPI,Odbc, rpcRPC 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 conlutente. 2 3. Architettura della Seconda Generazione WebClient WebServer tierApplicationServer tier Backend tierWeb/HTTP Server Documenti staticiBrowser iiop, orpc, rmi iiop, orpc, rmi CGI, PHP ISAPI, NSAPI httpServlet Browser Application server Applet, (contenitore di oggetti) Active JSP, ASP DBMS EJBApplicazioneCORBA DB ad oggettiJavabeanCOM iiop, orpc, rmiDCOMSistemi legacyArchitettura 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. 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 dellapplicazione e allinterazione con lesterno ( 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. Architettura della Terza Generazione Webwww.acquisti.com Firewall Documenti staticiSistemiLegacyHtml, dhtml,Applet, Oggetti CORBAJavascript Bean Bean Web Extension: CGI, PHP, JSP, ASP, Servlet FirewallHTTP/HTTPSDBMSHTTP/HTTPS SOAP Html, Wml BussinesTowe bBussines se ce r vi Documenti staticiDBMS Firewallwww.spedisci.comWeb Extension:CGI, PHP, JSP,ASP,ServletNascono 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. 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 unapplicazione client scritta in unqualsiasi linguaggio, mediante qualsiasi strumento di sviluppo, e che giri su qualsiasi piattaforma.realizzando cos lindipendenza dellapplicazione 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 lintegrazione 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 sinstaurano 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 lutilizzo 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 dellattualeprogrammazione 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/rispostaHTTP sembra essere un ottimo mezzo di trasporto per le chiamate a procedure remote su internetperch 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 losupportano 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 lobiettivo 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. Lo scenario di un webservice il seguente:Il servizio pubblicato in unadirectory di serviziIl client cerca idettagli sulservizio in unadirectory di servizi Il client interagisce con il servizioIl client di un servizio Web deve rintracciare unapplicazione 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 allhost che dispone del servizio.Per fare questo il modello dei Web Services utilizza un set base di protocolli disponibili ovunque.(permettendo cos linteroperabilit 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.Linterrogazione 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 allinterno del registro. Publishing, per permettere ai publisher di inserire, modificare, cancellare informazioni rispetto aipropri servizi. Replication, riservate alla comunicazione server-to-server per la gestione dei registri. 7 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 dibusiness, per tipo di servizi, Green pages Contengono informazioni sul servizio stesso (possono eventualmente anche contenere ilcodice 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. 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.SGMLXMLHTML WSDLXHTMLSOAPWMLLe caratteristiche fondamentali sono:fornisce un formato per lo scambio di informazioni indipendente dalle applicazioni e dallepiattaforme utilizzate. (comunicazione fra sistemi eterogenei).Un documento XML un file di testo, quindi pu essere facilmente trasmesso via Internet tramite ilprotocollo http (firewall friendly).In un documento XML linformazione pu essere vista come una struttura di dati astratta fatta adalbero, questo facilita lo sviluppo di applicativi in grado di processare il documento (facile daprocessare, parser molto leggeri).Un documento XML pu essere convenientemente descritto attraverso una DTD (Document TypeDefinition) o in maniera ancor pi espressiva attraverso un XML Schema.(capacit di fornire unastruttura ai documenti e di rendere i dati autodescrittivi.) Document [email protected] utente nomeemail 9 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 Elemento nome nelson ElementoElemento utente [email protected] Tag di chiusura 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: Deve avere un unico elemento radice. Marco Java Tutte le tag che si aprono debbono chiudersi. Se un elemento vuoto, ossia non contiene nessun gianni elemento di testo al suo interno, pu essere anche reti rappresentato con una forma speciale di tag: Si deve rispettare il maiuscolo/minuscolo (case-sensitive) Tutti gli elementi debbono essere annidati propriamente Tutti i valori degli attributi vanno espressi tra Tutti i caratteri speciali (minore , etc) sono riportati come Entit del tipo <, > 10 11. Il problema della unicit delle tag. A questo proposito sono nati i namespaces che permettono la creazione e luso 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 dellelemento 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. Lassociazione del prefisso al namespace per una tag fatta con lattributo xmlns 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 anchesso definito ed associato ad un namespace che i browser conoscono e sanno come interpretare: Titolo della Pagina Il namespace per lutilizzo dei fogli di stile : Gli elementi della sintassi XML Schema provengono dal namespace: La dichiarazione di namespace standard indica il namespace per tutti gli elementi non prefissati Ci possono essere pi namespaces attivi per lo stesso elemento, ma solo uno standard: In un messaggio SOAP abbiamo pi namespace attivi: Nicola 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. Tale11 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 cheimplementa le grammatiche estese di Backus-Naur (EBNF). (recentemente DTD stata sostituita daXML Schema)documenti del tipo XMLSchema, che come i DTD, permettono di definire tutti gli aspetti semanticida verificare in un documento XML e di specificare il tipo di dato di ciascun elemento o attributo. Illoro vantaggio rispetto ai DTD di costituire essi stessi un documento XML, di definire oltrequaranta tipi di dato contro la decina permessa dai DTD, di essere orientati agli oggetti, permettere didefinire dei tipi di dati complessi, stabilire dei vincoli sul contenuto degli elementi e dei loroattributi.Ad esempio la struttura di un messaggio soap descritto dallo schema seguente ( solo una parte delloschema presente in http://schema.xmlsoap.org/soap/envelope/):- - - - dove ad esempio il frammento di codice:stabilisce che lelemento Envelope deve contenere almeno un elemento figlio Body, mentre lelemento 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: 12 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:34 SOAP (Simple Object Access Protocol)13 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 serverdinvocare lesecuzione 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 SOAPSOAP MessageHTTP 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: 42048Le prime righe mostrano gli header HTTP utilizzati per trasportare un messaggio SOAP:14 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 sullURL.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 lintestazione HTTP per assicurare lautorizzazione della request.Se lintestazione 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: close12/1.1 200 OKIndica che indipendentemente dallesito 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. oSi pu considerarlo come una specie di busta che racchiude tutto il messaggio. oHa un attributo name, per identificare il messaggio. oContiene la dichiarazione dei namespace. oPu contenere un elemento header. oDeve contenere un elemento body. oHa un attributo encodingStyle da utilizzare per definire lencoding degli elementi delmessaggio che verranno serializzati.SOAP header (opzionale), che contiene informazioni relative allintestazione del messaggio. Il suoscopo quello di trasportare informazioni non facenti parte del messaggio, destinate agli 15 16. intermediari, cio alle varie parti che il messaggio attraverser per arrivare al suo destinatariofinale.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. Lelemento 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 envelopesoapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" per il meccanismo diserializzazioneCome detto lenvelope lelemento che racchiude lintero messaggio e pu contenere zero o pi elementiheader e deve contenere un solo elemento body.Esempio:DISNel seguente listato compare un solo elemento opzionale Lutilizzo 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 anchesse 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 lelemento 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. 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 namespaceNecessari per specificare la grammatica degli elementi. Ad esempio lelemento chiamato che compare nel listato definito nel namespace http://www.trading.org/tr. Ilsignificato del contenuto di questo elemento sar noto solo a chi conosce questo namespace. Un attributo actorChe 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: lheader in questione non deve essere elaborato da nessun nodo soapo next: lheader in questione pu essere elaborato da tutti i nodi incontrati nel tragitto mittente-riceventeo anonymous: lheader in questione pu essere elaborato solo dal nodo finale.Tale valore nonviene espresso esplicitamente, ma viene assunto quando nellheader non compare lattributoactor. Un attributo mustUnderstandServe per indicare se il processing di un messaggio obbligatorio o meno.o Se posto a 1, indica che lattore deve elaborare lheader. Se questo non possibile, lattoredeve generare un errore.o Se posto a 0 (default) indica che lelaborazione 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 dorigine alla destinazione.E i vantaggi offerti da questo modello sono innumerevoli: Rende possibile aggiungere servizi lungo il percorso del messaggio. Facilita limplementazione della sicurezza, perch consente di far passare il messaggio in dominiaffidabili e conosciuti; Rappresenta un superamento dellarchitettura client-server, aumentando lefficienza in numerosesituazioni (es: smistamento della posta) Facilita la ricostruzione dellesatto cammino attraversato da un messaggio, consentendo di verificarela presenza di bottlenecks.Per quanto riguarda lelemento body esso contiene le informazioni per il destinatario finale del messaggio. 17 18. Il contenuto di definito dallimplementatore del messaggio tramite luso di un particolarenamespace. Il destinatario dovr elaborare i dati e obbedire alla loro semantica, specificata dal namespacedi appartenenza.DISGestione 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 lapplicazione invocata pu sollevare degli errori.Le specifiche di SOAP permettono di gestire queste condizioni derrore, introducendo un opportunoelemento chiamato Fault.Lelemento serve a fornire informazioni su errori derivanti dallelaborazione del messaggio, putrovarsi solo allinterno del body e non pu comparire pi di un volta.SOAP-ENV:MustUnderstandSOAP Must Understand Errorhttp://sitoCheHaSbagliato.it/serverIl contenuto dellelemento :Un elemento , obbligatorio. Che fornisce un codice di identificazione per lerrore, ad uso del software.Un elemento , obbligatorio. Che fornisce una descrizione testuale dellerrore.Un elemento , obbligatorio. Che specifica lattore che ha generato lerrore, se non si tratta del destinatario (cio se lerrore stato provocato dalla mancata elaborazione di una header ).Un elemento che contiene informazioni di errore specifiche dellapplicazione e relative al contenuto del body. Deve essere presente nel caso in cui il body non sia stato processato correttamente. 18 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. Sviluppo di un Web Servizio attraverso il toolkit Apache Axis 1.1Apache Axis 1.1 rappresenta levoluzione 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 serviziopubblicato.Tool WSDL2Java e Java2WSDL.Lobiettivo dellapplicazione fornire un servizio remoto che permetta di ottenere il risultato diunoperazione 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 unapplicazione java CalcClient sullapplication 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 lengine 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 Tomcat2) Cambiare lestensione del file sorgente da .java a .jws3) 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 lesempio in questione, la rappresentazione WSDL del nostro servizio generataautomaticamente da Axis ha il seguente contenuto:- - - - - - - - - - - - - - 21 22. - - - 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 lAPI 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 ;importorg.apache.axis.client.Call;importorg.apache.axis.client.Service;importorg.apache.axis.encoding.XMLType;importorg.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 arg1 arg2");return;}String method = args[0];if (!(method.equals("add") || method.equals("subtract"))) {System.err.println("Usage: CalcClient arg1 arg2"); 22 23. return; } Integer i1 = new Integer(args[1]); Integer i2 = new Integer(args[2]); Serviceservice = 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), lazione 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 lutilizzo di due oggetti: Call e Service.Service service = new Service();Loggetto Service viene utilizzato come punto di partenza per laccesso ad un servizio SOAP.Attraverso opportuni costruttori e metodi possibile ricavare informazioni sul servizio direttamentedal corrispondente documento WSDL, nel nostro caso usiamo un costruttore senza parametri perchspecifichiamo manualmente tutti i campi necessari per eseguire il servizio.Call call = (Call) service.createCall();Loggetto Call viene utilizzato per invocare un servizio, attraverso il metodo createCall() applicatoalloggetto di tipo Service, si crea un nuovo oggetto di tipo Call vuoto.call.setTargetEndpointAddress( new java.net.URL(endpoint) );In questo modo si imposta lURL del servizio.call.setOperationName( method );In questo modo si imposta il metodo da richiedere al serviziocall.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 alloggetto ditipo 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. Integer ret = (Integer) call.invoke( new Object [] { i1, i2 });Con il metodo invoke si invoca il metodo precedentemente specificato per loggetto 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 delloperazione richiesta al servizio SOAP. 24 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 linstallazione configurare il PATH nel file autoexec.bat:Con lutility di configurazione del sistema andare in autoexec.bat e aggiungere e selezionare:SET PATH=%PATH%;C:j2sdk1.4.0-rcbinInstallazione Tomcat5.0Scegliere come directory di destinazione: tomcatDopo linstallazione 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 diconfigurazione del sistema e nel men esecuzione automatica deselezionare tomcat5 inoltre nellacartella tomcatbin trovare il file startup.bat e selezionare premere il tasto destro del mouse e andarenella 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 oNetscape Communicator) allURL: http://localhost:8080/(nota su win 98 per spegnere tomcat5 utilizzare shutdown.bat anche qui memoria ambiente a4096)Installazione di axis-1_1:dopo aver unzippato tra le varie cartelle andare in webapps e copiare la cartella axis e quindiincollarla nella cartella di webapps di tomcat.Sempre in axis copiare la cartella lib e incollarla in C:tomcatwebappsaxisSempre in axis copiare la cartella samples in C:tomcatwebappsaxisscaricare jaf-1_0_2 dal sito sun e copiare il file activation.jar nella cartella C:tomcatcommonlib25 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. 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 lutility TCP monitor.avviare tomcatandare in http://localhost:8080/axis/controllare con validate se sono caricati i componenti necessari.Copiare Calculator.java presente in axissamplesuserguideexample2 in C:tomcatwebappsaxisRinominare Calculator.java in Calculator.jwsAbilitare il servizio calculator con http://localhost:8080/axis/Calculator.jws27 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.tcpmon28 29. Selezionare HTTP proxysupport e mettiamoci in ascolto sulla porta 8081Adesso utilizziamo il servizio utilizzando come client un nuovo processo attivabile mediante lapertura 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. Abbiamo richiesto il servizio di somma di due interi. Nella figura sottostante i messaggi soap scambiati:30 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: 42048Messaggio 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: close1232. 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, (adesempio Java). Tale sorgente Java non ha nulla di speciale che lo renda in qualche modo assimilabilead un servizio web utilizzabile in remoto. La potenza di questa implementazione anche questa, nondover utilizzare codice particolare per definire i servizi web, sar il cliente a richiamare il servizioutilizzando SOAP.A questo punto il servizio web stato scritto e compilato, ora necessario pubblicarlo. Per far questonella versione Apache SOAP (antecedente ad Axis) dovevamo creare un deployment descriptor delservizio cio un file XML contenente le specifiche per la pubblicazione. Ad esempio, per unimplementazione Java, il file contiene principalmente il nome del servizio, il nome della classe chefornisce 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 dellIBM Web Services - The Webs next revolutionhttp://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 FirmaniLast update: 30/04/2002 32
Top Related