Anno accademico 2007-08



Scaricare 2.21 Mb.
Pagina1/21
02.02.2018
Dimensione del file2.21 Mb.
  1   2   3   4   5   6   7   8   9   ...   21


Università di Roma "La Sapienza"

Facoltà di Ingegneria

Corso di Laurea Specialistica in Ingegneria Informatica

Tesina di Seminari di Ingegneria del software

Prof. Giuseppe De Giacomo

Analisi,Studio e Sperimentazione di Tecnologie Web Service

Supervisore: A cura di:

Ing.Massimo Mecella Alessandro Gabrielli

Anno accademico 2007-08
Indice
Introduzione
Capitolo 1 – Service-Oriented Architecture e Web Services: concetti base

1.1 SOA: Service-Oriented Architecture

1.1.1 Caratteristiche di una SOA

1.1.2 Come funziona una SOA

1.2 Web Services

1.3 Web Services con Architettura SOA

1.4 Standard e Tecnologie alla base dei Web Services

1.4.1 XML

1.4.1.1 DTD: Document Type Definition

1.4.1.2 XML-Schema

1.4.2 WSDL

1.4.2.1 Struttura di un documento WSDL

1.4.2.2 Tipologia di un servizio

1.4.2.3 Utilizzo di un documento WSDL

1.4.4 SOAP

1.4.4.1 Toolkit per implementare SOAP

1.4.4.2 Struttura dei messaggi SOAP

1.4.4.3 Messaggi SOAP:la serializzazione dei dati

1.4.4.4 SOAP e Remote Procedure Calls

1.4.5 UDDI

Capitolo 2 – Apache Axis

2.1 Axis


2.2 JAX-RPC

2.3 Architettura di Axis

2.3.1 Handlers e Message Path in Axis

2.3.1.1 Message path server-side

2.3.1.2 Message path client-side

2.3.1.3 Schema riassuntivo del message path

2.4 Installare Axis

2.5 Deployment di Web Service su Axis

2.6 Gestione delle sessioni

2.7 Strumenti per il monitoraggio delle comunicazioni

2.7.1 TcpMonitor

2.7.2 SOAPMonitor

2.8 Esempio: BancadiRomaWS

2.8.1 Scenario

2.8.2 Server side

2.8.2.1 Accesso a database in J2EE:Configurazione di Tomcat

2.8.3 Client Side

2.8.4 Messaggi SOAP

2.8.4.1 Request message del metodo getLoanQuote

2.8.4.2 Response message del metodo getLoanQuote

2.8.4.3 Request message del metodo getLoan

2.8.4.4 Response message del metodo getLoan

2.9 Esempio: OrchestratoreWS

2.9.1 Server-side

2.9.2 Client-side

CAPITOLO 3 – Apache Axis2

3.1 Apache Web Service Stack

3.2 Nascita di Axis2

3.3 Installazione di Axis2

3.4 Differenze tra Axis2 ed Axis1.x

3.5 Architettura di Axis2

3.5.1 Moduli core

3.5.2 Moduli non-core

3.6 Axis2 Data Binding (ADB)

3.7 AXIOM

3.8 Gestione delle sessioni

3.8.1 Tipi di Sessioni in Axis2

3.9 Esempio: BancaDiCreditoCooperativoWS

3.9.1 Server-side

3.9.2 Client-side sincrono(Blocking API)

3.9.3 Client-side asincrono(Non-blocking API)

3.9.4 Client-side asincrono(Non-blocking API,Dual Transport)

CAPITOLO 4 - Enterprise Java Beans e Web Services

4.1 Introduzione

4.2 Enterprise Java Bean

4.3 EJB e Web Services

4.3.1 Esportare gli EJB tramite web services

4.4 Axis e JBoss

4.5 JBoss - Database

4.5.1 Configurazione di JBoss

4.5.2 Deploy di un file di configurazione -DS

4.5.3 MySQL Database Configuration

4.5.4 Indirezione a due livelli

4.6 Esempio: BancaDeiPaschiDiSienaWS

Capitolo 5 – Standard per la notifica di eventi nei web-services

ABSTRACT


5.1 Introduzione

5.2 Il ruolo del broker nei sistemi publish/subscribe

5.3 WS-NOTIFICATION

5.3.1 Note sulla terminologia utilizzata

5.3.2 Cosa definisce

5.3.3 Cosa non definisce

5.3.4 Scenario di funzionamento in assenza di broker

5.3.5 Scenario di funzionamento in presenza di broker

5.3.6 Confronto tra gli scenari

5.3.7 Server WS-Notification

5.3.8 Apache Muse

5.3.9 Caratteristiche

5.3.10 Architettura

5.3.11 Deployment Descriptor

5.3.11.1 Il Router

5.3.11.2 The Resource Types

5.3.11.3 Creating Custom Serializers

5.3.12 Esempio

5.3.12.1 Il Pattern Observer

5.3.12.2 wsn-producer

5.3.12.3 wsn-consumer

5.3.12.4 Compilazione,deploy ed esecuzione


Conclusione
Sviluppi Futuri
Bibliografia

Introduzione




L’integrazione tra sistemi e piattaforme eterogenee in ambito distribuito è senza dubbio uno dei problemi più complicati da risolvere.

Un'altra problematica alla quale si sta cercando di dare delle risposte tecnologiche efficienti è il riutilizzo delle componenti software. La necessità di sviluppare applicazioni distribuite ha ben presto evidenziato le difficoltà di tecnolgie iniziali quali COM,DCOM CORBA che erano sufficienti a garantire il riutilizzo delle componenti applicative,ma che hanno ben presto mostrato evidenti limiti nella distribuzione della soluzione sulla rete. Dai problemi legati all’utilizzo di queste tecnologie è nata l’esigenza di definire un nuovo standard indipendente dalla piattaforma per descrivere le funzionalità offerte da una componente,ed in contemporanea,di un protocollo di dialogo tra chiamante e componente applicativa che fosse indipendente dal trasporto,semanticamente completo e sicuro. Sono così comparsi i web service,che realizzano attraverso il protocollo SOAP il dialogo con le componenti e con WSDL (Web Service Description Language) la descrizione dell’interfaccia della componente.
Un Web Service,sostanzialmente,è un componente software (che esegue uno specifico compito)che può essere pubblicato,localizzato e consumato attraverso il Web. Esso è indipendente dalla piattaforma e può quindi essere esposto su differenti sistemi e comunicare con ogni altro;inoltre,esso è indipendente dal linguaggio di programmazione,essendo possibile svilupparlo in Java,Visual Basic,C++,C, etc. La tecnologia dei Web Services non è una tecnologia proprietaria ed i dettagli implementativi sono nascosti da una interfaccia in formato XML. Le tecnologie abilitanti alla base dei Web Services sono,infatti,tutte tecnologie aperte e/o standard de-facto (XML, SOAP, WSDL e UDDI).
Seguendo le linee di questa evoluzione,oggi nelle architetture applicative si ragiona in termini di componenti che offrono servizi applicativi,sia verso l’interfaccia utente sia verso altre applicazioni e componenti.

Questo è il concetto che sta alla base di SOA (Service Oriented Architecture) e COM,DCOM,CORBA e Web Services rappresentano le tecnologie per realizzarla.


Il principio che ispira una Service-Oriented Architecture è semplice:gli sviluppatori costruiscono diversi servizi invece di una grande applicazione monolitica e tali servizi devono risultare installabili e riusabili per supportare applicazioni e processi diversi. I benefici immediati di questo approccio sono evidenti:aumentare il riuso della funzionalità del software e guadagnare in flessibilità,poiché gli sviluppatori possono modificare e ottimizzare l'implementazione di un servizio senza influire sui client di quel servizio. Il requisito centrale di SOA risiede nel disaccoppiare l'interfaccia del servizio dall' implementazione. Questa separazione comporta un vantaggio in termini generali e non solo da un punto di vista programmatico: lo sviluppo del sistema è semplificato poichè tutti i suoi sottosistemi (legacy o moderni, interni o esterni) possono essere esposti e consumati come servizi.
Con SOA diventa quindi obsoleto il concetto di applicazione mentre diventa fondamentale quello di servizio inteso come una funzionalità di business realizzata tramite componenti che rispettano un’interfaccia standard.
I servizi possono essere quindi realizzati attraverso differenti tecnologie,implementati in diversi linguaggi di programmazione e distribuiti su piattaforme eterogenee. Con SOA viene definita l’architettura che li caratterizza ma accanto ad essa nasce l’esigenza di una rappresentazione che astragga dalla loro implementazione e mostri semplicemente il loro comportamento: behavior. Questo si può fare mediante una rappresentazione sotto forma di stati e transizioni:i transition system.
Un Transition System TS è quindi un modello relazionale astratto basato sulle nozioni primitive di stato e transizione rappresentato dalla tupla T = < A, S, So, δ, F> dove:
– A è l’insieme delle azioni

– S è l’insieme degli stati

– So  S è l’insieme degli stati iniziali

– δ  S x A x S è l’insieme delle transizioni

- F  S è l’insieme degli stati finali
Ogni servizio,sia un COM,DCOM,CORBA o Web Service,viene quindi rappresentato attraverso uno specifico TS ed implementa un’architetura di tipo SOA.
Lo scopo di questa tesina è quello di approfondire lo studio su una perticolare tipologia di servizi:i Web Service,analizzando funzionalità offerte ed approcci seguiti da differenti tipi di tecnologie nelle fasi di implementazione,compilazione,deploy ed esecuzione.
Nel primo capitolo parleremo del legame tra l’architettura SOA e i Web Services per passare poi ad analizzare gli standard caratteristici di quest’ultimi.

Nel secondo capitolo verrà presentato Axis 1.4,un engine SOAP open source realizzato da Apache che permette di creare servizi in modo semplice ed efficiente e rappresenta forse una delle tecnologie migliori per iniziare a costruire Web Services.

Nel terzo capito parleremo di Axis 2,che può essere visto come l’evoluzione di Axis 1.* essendo stato sviluppato sempre da Apache;verranno descritti i motivi che hanno portato alla creazione di una nuova architettura anziché continuare ad effettuare modifiche su quella di Axis per poter cooperare con i nuovi standard che si vanno via via definendo.

Nel quarto capitolo analizzeremo il legame tra gli Enterprise Java Bean e i Web Services discutendo le modalità attraverso le quali è possibile esporre un EJB come servizio;vedremo quindi come esporre una business logic implementata in un Session Bean e strettamente legata alla piattaforma J2EE come Web Service,discutendo i vantaggi derivanti da tale scelta progettuale tra i quali appunto,quello di disaccoppiare completamente la piattaforma sulla quale è implementato il servizio da quella utilizzata dai client che interagiscono con esso.

Nel quinto capitolo verranno presentati alcuni gli standard per la notifica di eventi nei Web Services e in particolare la specifica del WS-Notification;mostrerò quindi un possibile modo per implementare tale specifica attraverso l’utilizzo del progetto open source Apache Muse attraverso il quale è possibile implementare publisher e subscriber che comunicano rispettando appunto la specifica del WS-Notification. Nell’esempio che verrà presentato verranno descritti in dettaglio il producer,il consumer,i metodi utilizzati,le classi implementate i problemi riscontrati e ogni messaggio o evento che viene generato.
Una cosa importante da sottolineare è che nessuna delle tecnologie(Axis1.x,Axis2 e JBoss) utilizzate in questo contesto supporta l’implementazione di servizi statefull in grado di mantenere lo stato della conversazioni con i client. E’ compito del programmatore implementare tali tipologie di servizi:si rappresenta inizialmente il servizio con un TS e successivamente si scrive il codice che concretamente implementa i metodi esposti. Tali tecnologie non contengono infatti alcun tool che a partire da un file xml che descrive il TS costruisce automaticamente la classe che implementa il servizio.

Capitolo 1 – Service-Oriented Architecture e

Web Services: concetti base

Lo scopo di questo capitolo è quello di introdurre i concetti fondamentali dell’Architettura Orientata ai Servizi (SOA: Service-Oriented Architecture),per poi discutere quali siano i punti di contatto con la tecnologia dei Web Services.


1.1 SOA: Service-Oriented Architecture

Una Service-Oriented Architecture (SOA, Architettura Orientata ai Servizi) è un modello architetturale per la creazione di sistemi residenti su una rete che focalizza l’attenzione sul concetto di servizio. Un sistema costruito seguendo la filosofia SOA è costituito da applicazioni, chiamate servizi,ben definite ed indipendenti l’una dall’altra,che risiedono su più computer all’interno di una rete (ad esempio la rete interna di una azienda o una rete di connessione fra più aziende che collaborano: intracompany e intercompany network). Ogni servizio mette a disposizione una certa funzionalità e può utilizzare quelle che gli altri servizi hanno reso disponibili,realizzando,in questo modo,applicazioni di maggiore complessità. SOA è una forma particolare di Distributed System[1].


1.1.1 Caratteristiche di una SOA

L’astrazione delle SOA non è legata ad alcuna specifica tecnologia, ma semplicemente definisce alcune proprietà, orientate al riutilizzo e all’integrazione in un ambiente eterogeneo, che devono essere rispettate dai servizi che compongono il sistema [1,2]. In particolare un servizio dovrà:

• essere ricercabile e recuperabile dinamicamente.

Un servizio deve poter essere ricercato in base alla sua interfaccia e richiamato a tempo di esecuzione. La definizione del servizio in base alla sua interfaccia rende quest’ultima (e quindi l’interazione con altri servizi) indipendente dal modo in cui è stato realizzato il componente che lo implementa.

• essere autocontenuto e modulare.

Ogni servizio deve essere ben definito, completo ed indipendente dal contesto o dallo stato di altri servizi.

• essere definito da un’interfaccia ed indipendente dall’implementazione.

Deve cioè essere definito in termini di ciò che fa, astraendo dai metodi e dalle tecnologie utilizzate per implementarlo. Questo determina l’indipendenza del servizio non solo dal linguaggio di programmazione utilizzato per realizzare il componente che lo implementa ma anche dalla piattaforma e dal sistema operativo su cui è in esecuzione:non è necessario conoscere come un servizio è realizzato ma solo quali funzionalità rende disponibili.

• essere debolmente accoppiato con altri servizi (loosely coupled).

Un’architettura è debolmente accoppiata se le dipendenze fra le sue componenti sono in numero limitato. Questo rende il sistema flessibile e facilmente modificabile.

• essere reso disponibile sulla rete attraverso la pubblicazione della sua interfaccia (in un Service Directory o Service Registry) ed accessibile in modo trasparente rispetto alla sua allocazione. Essere disponibile sulla rete lo rende accessibile da quei componenti che ne richiedono l’utilizzo e l’accesso deve avvenire in maniera indipendente rispetto all’allocazione del servizio. La pubblicazione dell’interfaccia deve rendere noto anche le modalità di accesso al servizio.

• fornire un’interfaccia possibilmente a “grana grossa” (coarse-grained).

Deve mettere a disposizione un basso numero di operazioni, cioè poche funzionalità, in modo tale da non dover avere un programma di controllo complesso. Deve essere invece orientato ad un elevato livello di interazione con gli altri servizi attraverso lo scambio di messaggi. Per questo motivo e per il fatto che i servizi possono trovarsi su sistemi operativi e piattaforme diverse è necessario che i messaggi siano composti utilizzando un formato standard largamente riconosciuto(piattaforma indipendente). I dati che vengono trasmessi attraverso i messaggi possono essere costituiti sia dal risultato dell’elaborazione di un certo servizio sia da

informazioni che più servizi si scambiano per coordinarsi fra loro.

• essere realizzato in modo tale da permetterne la composizione con altri.

Nell’architettura SOA le applicazioni sono il risultato della composizione di più servizi. E’ per questo motivo che ogni servizio deve essere indipendente da qualsiasi altro,in modo tale da ottenere il massimo della riusabilità. La creazione di applicazioni o di servizi più complessi attraverso la composizione dei servizi di base viene definita Service Orchestration.

Queste sono dunque le caratteristiche di un sistema di tipo SOA, di cui adesso passiamo a descrivere il funzionamento.
1.1.2 Come funziona una SOA

Gli attori di un sistema SOA sono tre:

• Service Provider

• Service Consumer

• Service Registry.

Il Service Provider è un’entità che mette a disposizione un qualche servizio. Tale servizio, per poter essere trovato da altre entità che vogliono utilizzarlo, deve essere reso visibile sulla rete, in termine tecnico Pubblicato. A tal fine il Service Provider comunica al Service Registry le informazioni relative al servizio, perchè vengano memorizzate. Il Service Registry possiede quindi le informazioni, come URL e modalità di accesso, di tutti i servizi disponibili.

Nel momento in cui un Service Consumer dovrà utilizzare un servizio farà richiesta delle informazioni ad esso relative al Service Registry. Con queste informazioni il Service Consumer potrà comunicare direttamente con il Service Provider ed utilizzare il servizio. In figura sono riportate le interazioni fra le entità appena descritte. Tutte queste interazioni passano attraverso quella che in figura viene genericamente definita Rete di Comunicazione, la quale in un’implementazione reale di una SOA può essere costituita sia da Internet sia da una intranet.


Figura 1:Esempio di Architettura SOA
SOA definisce,dunque,le caratteristiche che i componenti facenti parte di un sistema devono avere al fine di poter definire quest’ultimo un’architettura orientata ai servizi.

Dopo aver descritto cos’è l’architettura SOA ed il funzionamento di un sistema di questo tipo, vediamo adesso cosa sono i Web Services,quali tecnologie utilizzano ed il loro legame con SOA.



1.2 Web Services

I Web Services sono delle applicazioni web che cooperano fra loro,indipendentemente dalla piattaforma sulla quale si trovano,attraverso lo scambio di messaggi.

Ognuna di queste applicazioni viene chiamato Web Service (Servizio Web),o più semplicemente servizio,del quale il Web Services Architecture Working Group (del W3C) [1,3] dà la seguente definizione:

Un Web Service è un’applicazione software identificata da un URI (Uniform Resource Identifier), le cui interfacce pubbliche e collegamenti sono definiti e descritti come documenti XML, in un formato comprensibile alla macchina (specificatamente WSDL). La sua definizione può essere ricercata da altri agenti software situati su una rete,i quali possono interagire direttamente con il Web Service, con le modalità specificate nella sua definizione, utilizzando messaggi basati su XML (SOAP), scambiati attraverso protocolli Internet (tipicamente HTTP).

Le tecnologie su cui si basano i Web Services, appena citate nella definizione, sono:

• XML, eXtensible Markup Language

• SOAP, Simple Object Access Protocol

• WSDL, Web Services Description Language

• UDDI, Universal Description, Discovery and Integration.

Figura 2:Standard dei Web Services


Attraverso l’utilizzo di questi ed altri standard i Web Services rendono possibile la comunicazione e la cooperazione, attraverso il web, di più applicazioni (servizi) che mettono a disposizione alcune funzionalità e, allo stesso tempo, utilizzano quelle rese disponibili da altre. Si può cioè ricercare e invocare servizi che possono essere composti per formare un’applicazione per l’utente finale, per abilitare transazioni di business o per creare nuovi Web

Services.[4] Di queste tecnologie XML ha dato un contributo molto importante alla nascita dei Web Services. Linguaggio a marcatori (tag) derivato da SGML, Standard Generalization Markup Language, come ad esempio il più conosciuto HTML, HyperText Markup Language, l’XML è utilizzato per la memorizzazione di informazione in maniera strutturata. XML è un formato indipendente dalle varie piattaforme; ciò è dovuto, oltre che all’essere universalmente riconosciuto come standard, anche al fatto che tale tecnologia si basa sul formato testo e quindi un documento XML può essere letto chiaramente su qualsiasi sistema operativo. Questa indipendenza lo rende la soluzione ideale per lo scambio di informazioni attraverso il Web.


I vantaggi offerti dai Web Services sono:

• Indipendenza dalla piattaforma: i Web Services possono, infatti, comunicare fra loro anche se si trovano su piattaforme differenti.

• Indipendenza dall’implementazione del servizio: l’interfaccia che un Web Service presenta sulla rete è indipendente dal software che implementa tale servizio. In futuro tale implementazione potrà essere sostituita o migliorata senza che l’interfaccia subisca modifiche e quindi senza che dall’esterno (da parte di altri utenti o servizi sulla rete) si noti il cambiamento.

• Riuso dell’infrastruttura: per lo scambio di messaggi si utilizza SOAP che fa uso di HTTP, grazie al quale si ottiene anche il vantaggio di permettere ai messaggi SOAP di passare attraverso sistemi di filtraggio del traffico sulla rete,quali “Firewall”.

• Riuso del software: è possibile riutilizzare software implementato precedentemente e renderlo disponibile attraverso la rete. Il concetto di Web Services implica quindi un modello di architettura ad oggetti distribuiti (oggetti intesi come applicazioni), che si trovano localizzati

in punti diversi della rete e su piattaforme di tipo differente.


Il legame con l’architettura SOA sta nel fatto che,sfruttando al meglio tutte le caratteristiche della tecnologia dei Web Services,il sistema che si ottiene implementa proprio un’architettura orientata ai servizi. Ad oggi i Web Services rappresentano la soluzione migliore per la realizzazione di una SOA su larga scala,ovvero su Internet.
1.3 Web Services con Architettura SOA

La presenza del Service Registry (o anche Service Directory o Service Broker) è ciò che rende il sistema,nell’esempio di utilizzo dei Web Services visto precedentemente un’architettura Service-Oriented (SOA).

Per implementare il Service Registry i Web Services fanno uso di UDDI, Universal Description, Discovery and Integration. UDDI è un servizio di registro pubblico in cui le aziende possono registrare (pubblicare) e ricercare Web Services. Esso mantiene informazioni relative ai servizi come l’URL e le modalità di accesso. Anche UDDI è un Web Service, il quale mette a disposizione due operazioni:

• Publish, per la registrazione

• Inquiry, per la ricerca.

Si ottiene così quella che oggigiorno è da molti considerata la migliore soluzione per l’implementazione di un sistema con architettura ServiceOriented.

In figura 3 è riportata la schematizzazione del funzionamento di un sistema con architettura SOA, realizzato attraverso l’uso dei Web Services.


Figura 3:Architettura Service-Oriented realizzata con la tecnologia dei Web Services.
1.4 Standard e Tecnologie alla base dei Web Services

I Web Services si basano su tecnologie oggi riconosciute universalmente come standard: XML, WSDL, SOAP e UDDI. Vediamole quindi una per una partendo da quella che è un pò il comune denominatore di tutte le altre:XML.


1.4.1 XML

XML, eXtensible Markup Language, è un metalinguaggio nato nel 1998 e derivato da SGML (Standard Generalization Markup Language). Il termine “metalinguaggio” significa che esso è un linguaggio per mezzo del quale se ne possono creare altri. “Esteticamente” simile ad HTML, poichè anch’esso è basato su marcatori o “tag” (questo è un tag: ), ne differisce profondamente. Essi infatti non sono semplicemente due linguaggi diversi ma appartengono a

categorie diverse; HTML è un linguaggio, in cui il comportamento di ogni marcatore è già stabilito, mentre XML è, come già anticipato, un metalinguaggio, che permette allo sviluppatore di definire marcatori personalizzati e di specificarne il ruolo.

Il motivo che ha portato alla creazione di XML è stata la necessità di avere documenti strutturati e flessibili che potessero essere utilizzati sulla rete per lo scambio di dati. I due linguaggi HTML e SGML, non erano adatti allo scopo, per due motivi opposti. HTML ha una struttura rigida dove i tag disponibili sono predefiniti e dal comportamento già stabilito. Al contrario SGML fornisce una struttura personalizzabile ma troppo ampia e complessa per giustificarne un utilizzo via web.

Inoltre XML ha un formato indipendente dalle varie piattaforme;ciò è dovuto, oltre che all’essere universalmente riconosciuto come standard,al fatto che tale tecnologia si basa sul formato testo e quindi un documento XML può essere letto chiaramente su qualsiasi sistema operativo. Il contenuto di un documento XML è costituito da marcatori e dati strutturati secondo un ordine logico determinato da una struttura ad albero. Il formato del documento è testuale e questo permette all’utente di accedervi direttamente in lettura.
Il compito di un documento XML è memorizzare i dati all’interno di una struttura gerarchica che rappresenti le relazioni esistenti fra di essi,senza curarsi minimamente della loro rappresentazione visuale. Tali dati possono poi essere visualizzati in molti modi differenti,a seconda del caso,come ad esempio una semplice pagina HTML. Abbiamo detto che ogni sviluppatore può creare i propri marcatori ma,affinchè questi siano interpretabili correttamente da chiunque voglia accedere ai dati contenuti nel documento,c’è bisogno di un meccanismo che definisca quali elementi sono presenti,la loro struttura e le relazioni fra di essi. Tecnologie create per assolvere questo compito sono Document Type Definition,XML-Schema e XML Namespace.
1.4.1.1 DTD: Document Type Definition

Una Document Type Definition è un file in cui è riportata la definizione di tutti gli elementi, e dei loro attributi, usati nel documento XML, specificando inoltre la correlazione tra di essi. Tale file permette ad un’applicazione di sapere se il documento XML che sta analizzando è corretto o no, dato che gli elementi, essendo stati creati dallo sviluppatore, risulterebbero privi di significato senza una loro definizione. Una DTD definisce quindi la struttura di un particolare tipo di documento XML, rispetto al quale si può valutare la conformità di una data istanza XML.

Le DTD, primo strumento di questo genere, presentano però delle limitazioni: possiedono una sintassi complessa (non sono scritte in XML), non permettono di specificare tipi di dato e sono difficilmente estendibili.
1.4.1.2 XML-Schema

Uno strumento, creato allo stesso scopo delle DTD,che superà le limitazioni di queste ultime è XML-Schema.

Un documento XML-schema definisce[5]:

• gli elementi e gli attributi che possono comparire in un documento,

• quali elementi sono elementi figlio,

• l’ordine ed il numero degli elementi figlio,

• se un elemento è vuoto o può includere testo,

• i tipi di dato per gli elementi e gli attributi,

• i valori di default ed i valori costanti per gli elementi e gli attributi.

Rispetto alle DTD, gli XML-Schema sono estensibili e scritti in XML, rendono possibile la definizione di tipi di dato e di vincoli, ammettono l’ereditarietà e supportano i namespace.


XML Namespace

XML Namespace è utilizzato per risolvere la possibile ambiguità fra elementi di documenti diversi. Gli elementi di un documento XML sono identificati da un nome che è unico all’interno del documento stesso,ma può accadere che un elemento appartenente ad un altro file abbia lo stesso nome. Questo fatto crea un problema di ambiguità quando ci si riferisce a questi elementi;tale ambiguità viene risolta con l’introduzione dei namespace. Un namespace identifica l’insieme di tutti gli elementi di un documento,semplicemente associando un prefisso ai loro nomi. In questo modo due elementi appartenenti a file diversi ed aventi lo stesso nome possono essere identificati univocamente grazie al fatto che essi appartengono a namespace differenti.


1.4.2 WSDL

WSDL, ovvero Web Services Description Language,è un linguaggio,basato su XML,usato per descrivere,in modo completo, un Web Service. Più precisamente un documento WSDL fornisce informazioni riguardanti l’interfaccia del Web Service in termini di:

• servizi offerti dal Web Service,

• URL ad essi associato,

• modi per l’invocazione,

• argomenti accettati in ingresso e modalità con cui debbono essere passati,

• formato dei risultati restituiti,

• formato dei messaggi.

In altri parole si può dire che un file WSDL fornisce la descrizione relativa ad un Web Service in termini di:

- cosa fa,

- come comunica,

- dove si trova.

Attraverso tale file si può quindi conoscere tutti i dettagli per poter invocare correttamente un servizio.
1.4.2.1 Struttura di un documento WSDL

Un documento WSDL è un file XML costituito da un insieme di definizioni. Il documento inizia sempre con un elemento radice chiamato definitions ed al suo interno utilizza i seguenti elementi principali nella definizione dei servizi:

• Types - definizione dei tipi dei dati utilizzati.

• Message - definizione dei messaggi che possono essere inviati e ricevuti.

• Port Type - insieme di servizi, Operation, offerti da un Web Service.

• Binding - informazioni sul protocollo ed il formato dei dati relativo ad un particolare Port Type.

• Service - insieme di endpoint relativi al servizio.

Figura 4:Elementi WSDL


Ciascuno di questi elementi identifica una distinta sezione del documento contenente informazioni relative ad uno specifico aspetto. Vediamo meglio come è strutturato un file WSDL analizzando un esempio e descrivendo i costrutti di cui è costituito.

Cosa fa un Web Service è descritto nelle sezioni delimitate dai tag:

• types

• message



• portType

Le caratteristiche di comunicazione sono invece descritte in:

• binding

Infine il punto di accesso ad un servizio è definito da:

• service

L’elemento types racchiude le definizioni dei tipi dei dati che sono coinvolti nello scambio dei messaggi. Come sistema standard per la tipizzazione,WSDL si basa su quello definito per gli schemi XML (XSD, XML Schema Definition) ed allo stesso tempo è però possibile aggiungere anche altri tipi.

La sezione relativa ai messaggi definisce invece l’input e l’output dei servizi. Ogni elemento message racchiude le informazioni, come parametri e loro tipi, relative ad uno specifico messaggio. Si possono avere ad esempio due message: uno relativo al messaggio di input ed uno relativo al messaggio di output. Ogni elemento part identifica un parametro.

La sezione portType riporta dettagli relativi alle operazioni che un Web Service rende utilizzabili. Ogni operazione viene descritta facendo uso di un’ulteriore elemento chiamato operation. Al suo interno vi sono i messaggi di input e/o di output accettati dal servizio e l’ordine che è necessario seguire per il passaggio dei parametri. Messaggi di input ed output vengono identificati rispettivamente dagli elementi input e output e la presenza di solo uno dei due o di entrambi e, nel secondo caso, l’ordine in cui vengono riportati determinano la tipologia del servizio che, come vedremo fra poco, può avere diversa natura. L’elemento (opzionale) fault specifica il formato del messaggio per ogni errore che può essere restituito in output dall’operazione.

La sezione binding porta alla seconda parte di un documento WSDL,passando da cosa fa un Web Service a come comunica. Qui viene stabilito il legame di ogni servizio del Web Service al protocollo per lo scambio di messaggi,il quale può essere HTTP GET/POST,MIME o SOAP; quest’ultimo è il protocollo che viene utilizzato più frequentemente. In particolare si specifica il protocollo per ognuno dei messaggi di un servizio offerto dal Web Service. Inoltre di solito viene scelto HTTP(S) come protocollo di trasporto per i messaggi SOAP. Questa combinazione viene appunto definita “SOAP over HTTP(S)”. Assumendo “SOAP over HTTP(S)” come protocollo di scambio messaggi e trasmissione,all’interno di binding avremmo prima di tutto la definizione dello stile del collegamento,che può essere rpc o document, e la specificazione di HTTP come protocollo di trasporto,facendo uso di un elemento relativo a SOAP chiamato wsdlsoap.

Per quanto riguarda lo stile del collegamento, la differenza fra “rpc” e “document”, che influisce sulla struttura del corpo del messaggio SOAP (elemento ), è la seguente:

• Document: il contenuto dell’elemento del messaggio SOAP è costituito da un documento.

• RPC: l’elemento contiene l’invocazione ad una procedura remota, una Remote Procedure Call (RPC) appunto. La struttura del corpo del messaggio SOAP (elemento ) deve rispettare alcune regole riportate nelle specifiche di SOAP. Secondo queste regole l’elemento può ad esempio contenere solamente un elemento il cui nome è lo stesso dell’operazione,cioè la procedura remota, che viene invocata e tutti i parametri di tale operazione devono essere riportati come sottoelementi di questo elemento.

Vi sono poi tanti elementi operation quanti sono i servizi (operazioni) messi a disposizione. All’interno di ogni elemento operation si possono trovare gli elementi input,output e fault; input ed output riportano,facendo uso dell’elemento wsdlsoap:body, il tipo di encoding che può essere encoded o literal:nel caso encoded deve essere specificato anche l’attributo encodingStyle.

L’ultima sezione,identificata dall’elemento service,è relativa alla localizzazione del Web Service. Al suo interno si trova l’elenco di tutti i servizi messi a disposizione;ognuno di essi è definito da un’elemento port che riporta il collegamento utilizzato ed al suo interno ha un’ulteriore elemento wsdlsoap:address che indica l’indirizzo URL,chiamato anche endpoint,al quale può essere trovato il Web Service.


1.4.2.2 Tipologia di un servizio

Prima ho accennato,nella sezione relativa a portType ed ai messaggi di ingresso ed uscita delle operazioni,al fatto che un servizio può essere di natura diversa,cioè appartenere ad una tipologia piuttosto che ad un altra,in relazione alla presenza e all’ordine degli elementi input ed output. Le tipologie a cui un servizio pu`o appartenere sono quattro:

• One-way

• Request-response

• Solicit-response

• Notification

One-way. Nel caso One-way è presente il solo elemento input. Come intuibile dal nome,la comunicazione avviene in una sola direzione: viene inviato un messaggio da un client al servizio,dopodichè il primo continua la sua computazione senza attendere una risposta dal secondo.

Request-response.In questo caso sono presenti entrambi gli elementi input ed output,in questo ordine. Il servizio riceve il messaggio Request dal client e,dopo aver eseguito l’elaborazione relativa alla richiesta,manda indietro un messaggio Response.

Solicit-response. Come nel caso precedente vi sono entrambi gli elementi ma in ordine inverso. E’ il servizio ad iniziare la comunicazione inviando un messaggio al client ed attendendo poi una sua risposta.

Notification. Questo caso è l’opposto del One-way. Il servizio spedisce un messaggio al client senza attendere una sua risposta. E’ quindi presente solo l’elemento output.


Ognuna di queste tipologie individua la natura del servizio che stiamo descrivendo. Ad esempio la tipologia Request-response è quella utilizzata nel modello di comunicazione RPC (Remote Procedure Call),mentre si può avere il caso One-way quando sia presente un servizio che memorizza dati ricevuti da più client, senza restituire un messaggio di risposta.
1.4.2.3 Utilizzo di un documento WSDL

Esistono alcuni strumenti,come il tool WSDL2Java (facente parte del framework Axis di cui parleremo più avanti),che prendono in input un documento di questo tipo per creare a runtime l’implementazione del client per accedere al servizio. Ma più semplicemente si può vedere il vantaggio apportato dall’uso dei documenti WSDL nel disaccoppiamento del servizio Web dal protocollo di trasporto e dai percorsi fisici,come gli endpoint. Si ottiene così un livello di indirezione,simile a quello che si ha fra i DNS e gli indirizzi internet,grazie al quale non è necessario configurare direttamente l’URL del servizio. In questo modo se vi saranno molti client che utilizzano il servizio,nel momento in cui esso cambia indirizzo,non si dovrà riconfigu-

rarli tutti,ma semplicemente aggiornare tale informazione nel documento WSDL,poichè è da questo che i client otterranno l’endpoint[6].
1.4.4 SOAP

SOAP è un acronimo per Simple Object Access Protocoll,un protocollo leggero pensato per facilitare l’interoperabilità tra applicazioni e piattaforme eterogenee nell’era della programmazione distribuita su Internet. Alla base di SOAP sta un’idea tanto semplice quanto intelligente che si può riassumere in questo modo: non inventare nessuna nuova tecnologia, ma utilizzare al meglio quelle esistenti.

Con SOAP il web diviene qualcosa di più di un semplice scambio di documenti: infatti SOAP mette le applicazioni in comunicazione tra loro, e si candida per costruire il framework su cui costruire i web services. Inoltre SOAP è candidato a diventare il meccanismo che consente a tutti i sevizi di esporre le proprie caratteristiche e di comunicare “service to service” o “componente to service”, sia tra piattaforme omogenee che, soprattutto tra piattaforme eterogenee. Il cambiamento apportato da SOAP è dovuto al fatto che oggi come oggi è possibile utilizzare una varietà di protocolli binari per l’invocazione di oggetti remoti. Questo significa che le applicazioni client sono create per comunicare con applicazioni server specifiche. Ma il più grande dei problemi consiste nel fatto che se si vuole eseguire i client al di là di un firewall, è necessario configurare quest’ultimo in modo apposito, sempre che sia possibile. E SOAP risolve brillantemente entrambi i problemi, consentendo uno sviluppo e soprattutto una distribuzione semplificata delle applicazioni.

Figura 5:Utilizzo del protocollo SOAP in un contesto distribuito


1.4.4.1 Toolkit per implementare SOAP

I principali toolkit che implementano il protocollo SOAP:



  1. Apache SOAP 2.2.

  2. Microsoft SOAP Toolkit.

  3. Apache Axis

Apache SOAP 2.2

  • Conforme alla specifica SOAP 1.1 del W3C.

  • Sul lato client estende Java con alcuni package.

  • Sul lato server è semplice codice Java +deployment descriptor per la pubblicazione.

  • Limitazioni:

    • Non supporta il linguaggio WSDL.

    • Presenta delle limitazioni rispetto alla specifica 1.1 (Attributo encodingStyle e mustUnderstand hanno valore predefinito, non supporta l’elemento root XML, non supporto l’attributo actor).

Microsoft SOAP Toolkit 2.0

Microsoft è stata una tra le prime aziende a muoversi nella direzione di SOAP, anche per permettere a tutti gli sviluppatori che realizzano soluzioni distribuite utilizzando COM e COM+, di orientarsi verso uno standard davvero universale quale è SOAP. Il toolkit di Microsoft è composto essenzialmente da alcune utilità che permettono di creare uno strato di comunicazione SOAP attorno a qualsiasi componente COM progettato ad hoc. In particolare il SOAP Toolkit è composto da:




  • Alcune librerie ActiveX da utilizzare come oggetti per lo sviluppo di applicazioni client

  • Una utilità, il WSDL Generator, che permette la generazione dei file WSDL e WSML

  • I filtri ISAPI per poter gestire i file WSDL e WSML da Internet Information Server

  • Altre utilità

La filosofia di base di Microsoft Toolkit è la seguente: qualsiasi componente COM può essere utilizzato come fornitore di servizi via SOAP,a condizione che per esso venga predisposta un’opportuna coppia di file WSDL e WSML che contengano la descrizione del servizio da esporre attraverso Internet Information Server. Sarà lo stesso Internet Information Server, attraverso il filtro ISAPI opportuno, a saper gestire i file WSDL attraverso i quali il client richiederà il servizio al server. Il client pertanto, attraverso SOAP,farà una request HTTP al file WSDL generato appositamente per un certo componente COM attraverso il WSDL Generator.

Il filtro ISAPI installato come plugin in Internet Information Server si occuperà di trasformare la chiamata al file WSDL in una reale richiesta di servizio al componente COM sul server ed effettuerà la response SOAP contenente il payload di ritorno.

Anche nel caso di Microsoft SOAP Toolkit,ha senso parlare di installazione lato client ed installazione lato server. L’installazione client ha come obiettivo la copia e la registrazione degli oggetti ActiveX necessari per fare in modo che un’applicazione client che voglia utilizzare servizi SOAP possa farlo, nel caso specifico si tratta di una serie di librerie DLL da utilizzare come riferimenti all’interno degli ambienti di sviluppo che si utilizzano.

L’installazione server invece,ha come obiettivo l’installazione e la configurazione dei filtri ISAPI da utilizzare per fare in modo che Internet Information Server possa ricevere request di file WSDL.
Le caratteristiche supportate da SOAP Toolkit 3.0 sono le seguenti:


  • Specifiche del consorzio W3C relative a WSDL 1.1

  • Specifiche del consorzio W3C relative a SOAP 1.1

  • Specifiche del consorzio W3C relative a XML Schema Part 0 (Primer), Part 1 (Structure) e Part (Datatypes).

  • Array di tipo semplice e complesso e array multidimensionali

  • Type Complex

  • Supporto per operazioni WSDL RPC-encoded e document-literal.

  • SOAP Headers

Il toolkit permette di eseguire chiamate a servizi e pubblicare questi attraverso due livelli di API (Application Program Interface): “high-level” oppure “low”. La scelta dipenderà dalle caratteristiche dei messaggi SOAP che si desidera inviare o dal livello di monitoraggio desiderato. Ovviamente le “high-level” API facilitano il lavoro dello sviluppatore il quale può ignorare diversi meccanismi interni come: connessioni, serializzazioni, deserializzazioni, ecc.


Fra le “high-level” API troviamo gli oggetti:

  • SoapClient

  • SoapServer

Fra le “low-level” API troviamo gli oggetti:

  • SoapConnector

  • SoapSerializer

  • SoapReader



Servizio Add

Client

Web Server:IIS

Apache SOAP

Visual Basic +

Microsoft SOAP Toolkit


Int:2


Int:4


6


Figura 6:Incompatibilità tra toolkit SOAP

Apache SOAP per tutti i valori di risposta richiede sempre la loro tipologia. Ad esempio: <return xsi:type="xsd:int">6 è la risposta attesa, dove viene specificato esplicitamente che si tratta di un intero. Microsoft SOAP Toolkit non specifica la tipologia dei dati inviati. Ad esempio: 6 è la risposta inviata.

Problema: Apache SOAP e Microsoft SOAP Toolkit di base sono incompatibili. (Apache SOAP rigetta i dati inviati dal server).

È stato necessario introdurre un nuovo deserializzatore sul client Apache SOAP, in questo modo, il client accetta la risposta del server VB anche se non è specificato il tipo di dato inviato.



Apache Axis

  • Rappresenta l’evoluzione di Apache SOAP 2.2, da cui eredita le caratteristiche di base. Elimina i difetti del predecessore: È perfettamente compatibile con Microsoft SOAP Toolkit.

  • Supporta le specifiche WSDL 1.1.

Novità:

    • Supporto parziale 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.

1.4.4.2 Struttura dei messaggi SOAP

Abbiamo detto SOAP è basato su XML. In effetti,un messaggio SOAP non è altro che un documento XML che descrive una richiesta di elaborazione o il risultato di una elaborazione, dove le informazioni contenute nella richiesta e nella risposta vengono serializzate secondo un formato prestabilito, utilizzando XML come strumento che garantisce l’indipendenza dalla piattaforma.

SOAP consiste di tre parti: una busta, che definisce un framework, per la descrizione del contenuto del messaggio e della modalità di elaborazione (SOAP envelope construct), un insieme di regole di codifica per l’espressione di istanze di tipi di dati definiti dalle applicazioni (SOAP encoding)ed una convenzione per la rappresentazione di chiamate e risposte di una procedura remota(SOAP RPC).

SOAP necessita di un protocollo di trasporto: nella sua versione iniziale si appoggiava all’ HTTP standard mentre nelle ultime versioni utilizza anche FTP e altri standard.


HTTP supporta diversi modi per la richiesta di informazioni mediante un’intestazione di richiesta; utilizza cioè dei metodi per descrivere le intenzioni del server oppure alcuni campi dell’intestazione per includere le coppie nome-valore dei dati di richiesta. Quando il server risponde genera un messaggio costituito da un’intestazione di risposta che include una riga di stato e i campi dell’intestazione per includere coppie nome-valore dei dati di risposta. Metodi e intestazioni forniscono un framework flessibile e semplice da capire.

Il protocollo SOAP è adatto a supportare un’architettura client-server:i dati richiesti ed elaborati fra client e server sono organizzati in messaggi SOAP e vengono trasportati attraverso il protocollo HTTP o un altro protocollo di trasporto. I messaggi SOAP sono fondamentalmente trasmissioni unidirezionali da un mittente ad un destinatario ma sono spesso combinati per implementare modelli del tipo richiesta/risposta.

Un vantaggio notevole offerto da SOAP consiste nell’imposizione di una struttura di dati per la richiesta e, quando disponibili, per la risposta.

Di seguito analizzeremo i messaggi SOAP generati quando un client si connette al servizio BancaDiRomaWS attraverso i quali mostrerò come viene rispettata la sintassi ed alcune caratteristiche dei messaggi SOAP, che si possono schematizzare come in figura:





Messaggio SOAP completo



Standard HTTP e SOAP HTTP Headers






per i dati




  1   2   3   4   5   6   7   8   9   ...   21


©astratto.info 2017
invia messaggio

    Pagina principale