Tecnologie di riferimento

Tecnologie di riferimento

In questo capitolo si presentano le tecnologie utilizzate in ambito Web Service. Il primo paragrafo viene introdotta l'architettura dei Web Service, SOA ed ESB. A seguire vengono introdotte i protocolli e gli standard alla base dei Web Service. Infine una panoramica sulle implementazioni di quegli standard per il linguaggio Java e la loro evoluzione degli ultimi mesi.

1 Architettura dei Web Service

Definire con precisione quale sia l'architettura dei Web Service è molto più complesso di quanto si possa pensare. Lo sviluppo di questa tecnologia ha seguito un percorso tale che è venuta a mancare la definizione standard dell'architettura su cui si basa. In alcuni articoli che ho consultato a riguardo ho trovato commenti piuttosto preoccupati su questa mancanza, ma anche commenti di chi preferisce proseguire senza specificare questo aspetto [51,52,53,54,55]. Quella che segue è una descrizione dell'architettura dei Web Service basata su una nota W3C dell'11 Febbraio 2004 chiamata WS-Arch [30]. In questo articolo, l'architettura Web Service è suddivisa in modelli, dove per modello s'intende un sottoinsieme dell'architettura che si occupa di gestire un aspetto specifico trattato dall'architettura generale. I vari modelli, anche se si concentrano su aspetti diversi, possono condividere alcuni concetti, magari visti da punti diversi.

• Il Message Oriented Model si concentra sui messaggi, la loro struttura, il loro trasporto etc., senza particolari riferimenti alla ragione per cui i messaggi sono stati creati o al loro significato.
  L'essenza del modello orientato ai messaggi ruota attorno ad alcuni concetti chiave illustrati nel grafo precedente: l'agente che invia e riceve il messaggio, la struttura del messaggio in termini di header e body e il meccanismo usato per inviare il messaggio.
• Il Service Oriented Model si concentra sulla questione dei servizi, action e così via. Per chiarezza, in qualsiasi sistema distribuito i servizi non possono essere adeguatamente realizzati se non si ha qualche nozione sui messaggi scambiati, il contrario non è vero: un messaggio può non avere nozioni sul servizio a cui è destinato.
                              Il modello orientato ai servizi è il più complesso di tutti i modelli dell'architettura. Comunque, anche lui si basa su pochi concetti chiave. Un servizio è realizzato da un agente e utilizzato da un'altro agente. Inoltre il modello orientato ai servizi fa uso di metadati che sono una proprietà chiave delle Service Oriented Architecture (SOA), come vedremo nel prossimo paragrafo. Questi metadati sono usati per rappresentare vari aspetti del servizio: dai dettagli delle interface al binding del trasporto, dalla semantica del servizio a quali politiche restrittive sono applicate al servizio.
• Il Resource Oriented Model si focalizza sulle risorse esistenti e chi le controlla.              Il modello delle risorse è ereditato dal concetto di risorsa dell'Architettura Web e serve ad includere le relazioni tra risorse e i detentori delle stesse.
• Il Policy Model si focalizza sulle relazioni tra gli agenti ed i servizi.
             Le Policies sono applicate agli agenti che vogliono far uso di determinate risorse dalle persone che le gestiscono. Le Policies possono essere introdotte per gestire aspetti quali la sicurezza, qualità del servizio (QoS), management etc..

1.1 Service Oriented Architecture

Un sistema distribuito è formato da diversi agenti software discreti che devono cooperare insieme per svolgere determinate funzioni. Inoltre, gli agenti in un sistema distribuito non operano nello stesso ambiente, quindi devono comunicare affidandosi a protocolli software e hardware attraverso una rete. Questo implica che le comunicazioni in un sistema distribuito sono intrinsecamente meno veloci e disponibili di quelle tramite invocazione diretta nel codice e usando memoria condivisa. Questo ha delle importanti implicazioni architetturali, poichè i sistemi distribuiti richiedono che gli sviluppatori prendano in considerazione l'imprevedibile latenza di una comunicazione remota e gestire le problematiche derivate dalla concorrenza e dai possibili fallimenti parziali.

I distributed object systems sono sistemi distribuiti nei quali la semantica dell'inizializzazione di un oggetto e dei suoi metodi sono esposti a sistemi remoti tramite meccanismi proprietari o standard per inoltrare la richiesta oltre i confini del sistema, effettuare marshall o unmarshall degli argomenti dei metodi, etc.

Una Service Oriented Architecture (SOA) [33,35] è una forma d'architettura di sistemi distribuiti tipicamente caratterizzata da queste proprietà:

• Vista logica: Il servizio è un'astrazione, vista logica, del programma, database, processo etc., definito in termini di cosa fa, tipicamente astraendo un'operazione.
• Orientato ai messaggi: Il servizio è formalmente definito in termini dei messaggi scambiati tra l'agente fornitore e l'agente fruitore e non sulle proprietà degli agenti stessi. La struttura interna degli agenti, compreso ad esempio il linguaggio di programmazione usato per implementarlo, la struttura dei processi o la struttura delle basi di dati, sono deliberatamente astratti nella SOA: non deve essere assolutamente necessario sapere qualcosa dell'implementazione di un agente per interagirci. Un beneficio chiave di questa funzionalità interessa i cosiddetti sistemi legacy.
• Orientato alla descrizione: Un servizio è descritto da metadati interpretabili da una macchina. Questa descrizione deve supportare la natura pubblica della SOA: solo quei dettagli utili all'uso del servizio devono essere resi pubblici. La semantica del servizio deve essere, direttamente o indirettamente, inserita in questa descrizione.
• Granulare: I servizi tendono ad usare poche operazioni con messaggi relativamente grandi e complessi.
• Orientato alla rete: I servizi tendono ad essere utilizzati attraverso una rete, anche se non è un requisito assoluto.
• Indipendente dalla piattaforma: I messaggi sono inviati in un formato standard indipendente dalla piattaforma usata.

1.2 Enterprise Service Bus

Un Enterprise Service Bus (ESB) è un'infrastruttura software che fornisce servizi di supporto ad architetture SOA complesse. Un ESB si basa su sistemi disparati, interconnessi con tecnologie eterogenee, e fornisce in maniera consistente servizi di orchestration, sicurezza, messaggistica, routing intelligente e trasformazioni, agendo come una dorsale attraverso la quale viaggiano servizi software e componenti applicativi. Un ESB si contraddistingue come soluzione migliorativa, rispetto ad altre più classiche di tipo SOA oriented, in quanto ad esso sono delegati i servizi comuni, denominati core service (Security, tracking, routing etc..), che andrebbero altrimenti realizzati.

1.3 Event-Driven Architecture

Event-driven architecture (EDA) è un paradigma di architettura sofware per la produzione, gestione, utilizzo e reazione agli eventi.

Per evento s'intende "una significativa modifica allo stato". Ad esempio quando un acquirente compra una macchina, il suo stato cambia in "venduta". Il sistema di gestione del venditore può trattare questo cambio di stato come un evento da raccogliere, segnalare e far processare da varie applicazioni a corredo dell'architettura.

Questo paradigma architetturale può essere applicato nella specifica e implementazione di applicazioni e sistemi che trasmettono eventi attraverso componenti software fortemente disaccoppiati e servizi. Un sistema orientato agli eventi tipicamente è costituito da produttori e consumatori di eventi. I consumatori si sottoscrivono a degli intermediari detti event manager, mentre i produttori pubblicano gli eventi a questi managers (Subscribe and Publish, S&P). Quando un manager riceve un evento dal produttore, lo notifica al consumatore. Se questo è indisponibile, lo memorizza e tenta un ulteriore invio in seguito. Questo metodo di trasmissione degli eventi è riferito nei sistemi orientati ai messaggi come "store and foward"

Costruire applicazioni e sistemi basandosi su questo tipo di architettura permette di ottenere una maggiore affidabilità, poiché i sistemi basati sugli eventi sono, per costruzione, più tolleranti ad ambienti imprevedibili ed asincroni.

1.4 Staged Event-Driven Architecture

SEDA [31,32] è l'acronimo di staged event-driven architecture. Questa architettura è stata ideata da Matt Welsh dell'Università di Harvard e prevede di decomporre un'applicazione complessa, orientata agli eventi, in un set di fasi (stages) connessi da code. Questa architettura risolve il problema di overhead presente in modelli basati su thread, e disaccoppia eventi e thread dalla logica applicativa. Questo permette di prevenire che le risorse siano occupate da un carico di lavoro che eccede le loro capacità, evitando un approccio thread-based, dove ogni richiesta è associata ad un thread.

In figura viene mostrato come si può adattare a questa architettura un processo di gestione di una richiesta HTTP ad un Web Server.

Strutturando il processo in un set di fasi (stages) si introduce modularità, riuso del codice e permette lo sviluppo di strumenti di debug per applicazioni complesse basate sugli eventi. Ogni fase è separata dalle altre tramite code ed ad ognuna di esse è associata un pool di thread, non esposti all'applicazione. Questa architettura si presta a fornire funzionalità di bilanciamento del carico, controllando il flusso dei dati attraverso le code e agendo sui pool di thread associate ad esse. Abbiamo quindi un buon compromesso tra la programmabilità dei thread ed i benefici dell'orientamento agli eventi.

2 Protocolli e tecnologie dei Web Service

L'approccio ai Web Service è basato su un maturo set di standard largamente accettato e usato. Questa sua diffusione permette a client e service di poter comunicare attraverso un'ampia varietà di piattaforme scavalcando i confini dei linguaggi utilizzati.

Una breve panoramica sugli standard che tratteremo e sulla loro struttura gerarchica è mostrata nella seguente figura.

1 XML

Lo XML [15], acronimo di eXtensible Markup Language, ovvero "Linguaggio di marcatura estensibile" è un metalinguaggio creato e gestito dal World Wide Web Consortium (W3C), semplificazione e adattamento dello Standard Generalized Markup Language (SGML), da cui è nato nel 1998. Esso è un meta-linguaggio di markup, cioè un linguaggio che permette di definire altri linguaggi di markup. A differenza di HTML, XML non ha tag predefiniti e non serve per definire pagine Web né per programmare. Esso serve esclusivamente per definire altri linguaggi. XML è dunque un meta-linguaggio per definire la struttura di documenti e dati. Il termine "documento" ricorre spesso nella terminologia XML. Anche se esso può far pensare pagine a Web o altri prodotti dell'elaborazione di testo, è utilizzato nella sua accezione più ampia di contenitore di informazioni. L'XML è diventato lo standard de facto per descrivere i dati che devono essere scambiati attraverso la rete.

A corredo di XML ci sono una serie di strumenti ad esso correlati:

• DTD (acronimo di Document Type Definition): è un documento attraverso cui si specificano le caratteristiche strutturali di un documento XML attraverso una serie di 'regole grammaticali'. In particolare definisce l'insieme degli elementi del documento XML, le relazioni gerarchiche tra gli elementi, l'ordine di apparizione nel documento XML e quali elementi e quali attributi sono opzionali o meno.
• XML Schema: come la DTD, serve a definire la struttura di un documento XML. Oggi il W3C consiglia di adottarlo al posto della DTD stessa, essendo una tecnica più nuova ed avanzata. La sua sigla è XSD, acronimo di XML Schema Definition.
• XLink: serve a collegare in modo completo due documenti XML; al contrario dei classici collegamenti ipertestuali che conosciamo in HTML, XLink permette di creare link multidirezionali e semanticamente avanzati.
• XSL (acronimo di eXtensible Stylesheet Language): è il linguaggio con cui si descrive il foglio di stile di un documento XML.
• XSLT (dove la T sta per Trasformations) è una versione estesa dell'XSL. L'obiettivo principale per cui l'XSLT è stato creato è rendere possibile la trasformazione di un documento XML in un altro documento. È possibile anche aggiungere al documento trasformato elementi completamente nuovi o non prendere in considerazione determinati elementi del documento origine, riordinare gli elementi, fare elaborazioni in base al risultato di determinate condizioni, ecc. In termini strutturali, XSLT specifica la trasformazione di un albero di nodi in un altro albero di nodi.
• XPath: è un linguaggio con cui è possibile individuare porzioni di un documento XML e sta alla base di altri strumenti per l'XML come XQuery.

2 SOAP

         

Il Simple Object Access Protocol (SOAP) [13] è un protocollo basato su XML per lo scambio d'informazioni in un ambiente distribuito che descrive un formato comune per trasmettere dati tra clients e services, fornendo le linee guida riguardo la formattazione del documento XML, ad esempio per separare i dati effettivi dai contenuti addizionali. L'elemento base è il messaggio SOAP, che consiste di una SOAP Envelope, un SOAP Header opzionale e un SOAP Body. L'envelope specifica la codifica utilizzata e gli spazi dei nomi (namespaces). Questi ultimi sono utilizzati per prevenire eventuali conflitti di nomi, giacché i tags di namespace diversi potrebbero avere lo stesso nome, ma un diverso significato. L'header, se presente, estende il messaggio in maniera modulare.

E' importante capire che un messaggio SOAP può muoversi da un client ad un servizio attraverso più punti intermedi, come avviene nelle architetture ESB. Ognuno di questi intermediari riceve e inoltra il messaggio fornendo servizi aggiuntivi, quali applicare politiche di sicurezza o trasformazione dei dati. I dati contenuti nell'header servono appunto per fornire informazioni utili ad eseguire queste operazioni. Un esempio classico è appunto quello della sicurezza, dove il corpo del messaggio è codificato e nell'header sono presenti i dati necessari per procedere alla decodifica. Il SOAP Body infine contiene la parte principale del messaggio, chiamata Payload.

Un altro standard, SOAP Message with Attachment (SwA) [16], specifica il formato di un messaggio SOAP che comprende degli allegati. Ovviamente il livello di messaggio è indipendente dal livello di trasporto, quindi la busta SOAP può essere impacchettata per essere inviata via HTTP, SMTP, etc. , ma la struttura e il contenuto della busta SOAP rimarrà immutato.

3 WSDL

SOAP fornisce una struttura standard per organizzare i dati da inviare al servizio, ma come fa un client a conoscere il formato del contenuto di un messaggio SOAP richiesto dal un certo servizio? Per fornire queste informazioni il servizio espone un documento XML, chiamato WSDL, che contiene una descrizione delle interfacce dello stesso. Il documento WSDL è scritto utilizzando il Web Service Description Language (WSDL) [17]. Per scoprire la descrizione di un Web Service, un client deve trovare il suo WSDL. Un modo, peraltro il più comune, è quello di trovare il puntatore al documento WSDL nella registrazione del servizio, che può essere in un registro UDDI.

4 UDDI

Le specifiche Universal Description, Discovery and Integration (UDDI) [18] definiscono come pubblicare e reperire informazioni riguardanti un servizio in un registro. Più specificatamente definiscono uno schema UDDI e un'API. Il primo descrive le strutture dati XML da inserire nel registro mentre le API descrivono come i dati devono essere immagazzinati e come possono essere reperiti. Un "registro UDDI" è un registro conforme a questa specifica.

5 WS-*

Gli standard definiti finora permettono ad un client di trovare i servizi necessari ed effettuare una richiesta che entrambe le parti possano interpretare correttamente. Ci poi sono una serie di altri standard che vengono definiti di "alto livello" e forniscono servizi aggiuntivi in modo modulare. I principali sono:

• WS-Security [19]: uno standard sviluppato da Oasis-Open [62] per applicare politiche di sicurezza ai messaggi SOAP. Nello specifico indicano come possono essere garantiti integrità e confidenzialità. Inoltre include dettagli sull'uso di SAML e Kerberos, due protocolli di rete per l'autenticazione, e di certificati come X.509, uno standard per certificati a chiave pubblica.
• WS-Addressing [20]: uno standard che specifica come le informazioni relative a al trasporto del messaggio devono essere incapsulate nel messaggio stesso. Questo permette ad esempio di specificare a chi inviare la risposta del messaggio rendendo la comunicazione totalmente asincrona e svincolare la durata della comunicazione a quella della connessione.
• WS-Reliability [21]: uno standard per implementare strumenti che garantiscono la consegna del messaggio o dei messaggi rispetto alla politica scelta, come InOrder, AtLeastOnce, AtMostOnce etc.

3 La tecnologia J2EE per la gestione dei Web Service

Anche se sono progettati per essere indipendenti dal linguaggio e dalla piattaforma utilizzata, un linguaggio preferenziale per sviluppare Web Service e le applicazioni che li utilizzano è Java. La portabilità e l'interoperabilità delle applicazioni scritte in Java si sposano bene con gli obiettivi di interoperabilità dei Web Service. Un set di base di tecnologie Java per lo sviluppo di Web Service è integrato nel Java 2 Platform Enterprise Edition (J2EE). Queste tecnologie sono progettate per essere usate con XML e aderenti a standard come SOAP, WSDL e UDDI.

A seguire saranno presentate le principali implementazioni di specifiche in ambito Web Service in Java:

JAXP per il parsing dei documenti XML.

JAXB per il data binding.

JAX-RPC per effettuare chiamate a procedure remote.

JAX-WS, evoluzione di JAX-RPC.

SAAJ per creare, modificare e inviare messaggi SOAP.

JAXR per interfacciarsi ai registri come quelli UDDI.

3.1 JAXP

Java API for XML Processing (JAXP) [22,37] è una API utilizzata per processare documenti XML. Usando JAXP, un'applicazione può invocare un parser per eseguire il parsing di un documento XML. Un parser è un programma che effettua la lettura del documento XML e lo divide in blocchi discreti. Inoltre controlla che il documento sia ben formato e può validarlo rispetto ad uno XML Schema (XSD) oppure ad un XML Document Type Definition (DTD). E' evidente che la funzione del parser è estremamente importante poiché si occupa di presentare i dati contenuti nel documento XML all'applicazione.

I due classici approcci per processare documenti XML sono:

• Simple API for XML processing (SAX)
• Document Object Model (DOM)

SAX è un'API di basso livello il cui principale punto di forza è l'efficienza. Quando un documento viene parsato usando SAX, una serie di eventi vengono generati e passati all'applicazione tramite l'utilizzo di callback handlers che implementano l'handler delle API SAX. Gli eventi generati sono di livello molto basso e devono essere gestiti dallo sviluppatore che, inoltre, deve mantenere le informazioni necessarie durante il processo di parsing. Oltre ad un utilizzo piuttosto complicato, SAX soffre di due limitazioni di rilievo: non può modificare il documento che sta elaborando e può procedere alla lettura solo "in avanti": non può tornare indietro. Quindi, quello che è stato letto è perso e non è possibile recuperarlo.

DOM invece ha come punto di forza la semplicità d'utilizzo. Una volta ricevuto il documento, il parser si occupa di costruire un albero di oggetti che rappresentano il contenuto e l'organizzazione dei dati contenuti. In questo caso l'albero esiste in memoria e l'applicazione può attraversarlo e modificarlo in ogni suo punto. Ovviamente il prezzo da pagare è il costo di computazione iniziale per la costruzione dell'albero, ma soprattutto il costo di memoria dello stesso, che può diventare un problema cruciale in sistemi che devono processare grandi quantità di dati.

A questi rappresentanti delle due principali tecniche di rappresentazione dei dati XML si aggiungono altri due parser di recente concezione:

• StAX (Streaming API for XML) [45]
• TrAX (Transformation API for XML)

StAX è un pull parser. A differenza di SAX, che è un push parser, non riceve passivamente i segnali inviati all'handler per elaborarli, ma è l'utente a controllare il flusso degli eventi. Questo significa che il client richiede (pull) i dati XML quando ne ha bisogno e nel momento in cui può gestirli, a differenza del modello push, dove è il parser a inviare i dati non appena li ha disponibili a prescindere che l'utente ne abbia bisogno o sia in grado di elaborarli. Le librerie pull parsing sono molto può semplici delle push parsing e questo permette di semplificare il lavoro dei programmatori, anche per documenti molto complessi. Inoltre è bidirezionale, nel senso che oltre a leggere dati XML è anche in grado di produrli. Rimane il limite di poter procedere solo "in avanti" nell'elaborazione del documento XML.

TrAX, con l'utilizzo di un XSLT stylesheet, permette di trasformare l'XML. Inoltre poiché i dati vengono solitamente manipolati con SAX o DOM, questo parser può ricevere in ingresso sia eventi SAX che documenti DOM. Può anche essere usato per convertire i dati da un formato all'altro, infatti, è possibile prendere un documento DOM, trasformarlo e scriverlo su file, come prendere l'XML da file, trasformarlo e restituirlo in forma di documento DOM.

La tabella seguente riassume brevemente le caratteristiche principali dei parser presentati:

3.2 JAXB

La Java API for XML Binding (JAXB) [27,43] fornisce un modo per mappare un documento XML su di una collezione di oggetti Java basandosi sullo schema XML del documento. L'utilità sta nel fatto che l'applicazione così può lavorare direttamente sul contenuto Java invece che sul contenuto XML.

L'utilizzo di JAXB è semplice: si utilizza un binding compiler fornito con l'implementazione di JAXB per trasformare, o legare, lo schema XML del documento in un set di classi e interfacce. La combinazione di queste classi derivate e dell'implementazione del pacchetto javax.xml.bind delle specifiche di JAXB costituiscono il binding framework che permette di:

Convertire il contenuto XML in un albero di oggetti Java (marshalling)

Convertire un albero di oggetti Java in un documento XML (unmarshalling)

Validare un albero di oggetti rispetto ad uno schema.

3.3 JAX-RPC

Lo standard Java API for XML-based Remote Procedure Call (JAX-RPC) [23,38,39] è una  API Java per accedere ai servizi attraverso chiamate remote in XML basate su SOAP. Le API includono le funzionalità per effettuare chiamate RPC basate su XML rispettando le specifiche SOAP 1.1. JAX-RPC permette ad un client basato su Java di chiamare metodi di Web Service in un ambiente distribuito. Dal punto di vista dell'applicazione, JAX-RPC offre un modo per chiamare un servizio. Dal punto di vista dello sviluppatore, offre un modo per rendere il servizio disponibile ad essere invocato dal client. JAX-RPC è progettato per nascondere la complessità del SOAP e, quando viene utilizzato per effettuare una chiamata RPC, non richiede di esplicitare il codice del messaggio SOAP. JAX-RPC quindi converte una chiamata RPC in un messaggio SOAP e lo invia al server. Dal lato server, JAX-RPC converte il messaggio SOAP e chiama il servizio. L'eventuale risposta del servizio segue il processo inverso, venendo convertita in un messaggio SOAP e inviata al client.

JAX-RPC fornisce numerosi modi per consentire ad un client di invocare un servizio. Il client può invocare il metodo remoto attraverso un oggetto locale chiamato stub oppure può usare un proxy dinamico per invocare il metodo o ancora utilizzare il JAX-RPC Dynamic Invocation Interface (DII). Il primo, ad ogni modo, rimane lo scenario classico d'utilizzo di JAX-RPC:

• Il client e service usano i tools forniti con JAX-RPC per generare gli stubs e ties partendo dal WSDL o dalle classi del servizio.
• Il client usa gli stubs per effettuare una chiamata di procedura remota come farebbe con un metodo locale.
• Lo stub si preoccupa di convertire la chiamata in un messaggio SOAP (marshalling) e di spedirlo al server
• Dal lato server un oggetto chiamato tie o skeleton trasforma il messaggio SOAP in una chiamata al servizio (unmarshalling).
• Il processo viene invertito nel caso di una risposta del server per il client.

3.4 JAX-WS

La versione successiva a JAX-RPC 1.4 è stata chiamata JAX-WS 0, acronimo di Java API for XML-based Web Service [24,34,36,44].

Prima di discutere cosa è cambiato nel passaggio da JAX-RPC a JAX-WS vediamo cosa è stato mantenuto:

• JAX-WS continua a supportare SOAP 1.1 su HTTP 1.1, quindi l'interoperabilità non viene influenzata. Gli stessi messaggi possono ancora essere scambiati.
• JAX-WS continua a supportare WSDL 1.1, quindi le conoscenze acquisite su quello standard continuano a essere utili. JAX-WS supporta anche WSDL 0.

Cos'è cambiato?

• SOAP 1.2
• JAX-WS, oltre a SOAP 1.1, supporta anche SOAP 1.

• XML/HTTP
• Le specifiche WSDL 1.1 definiscono un binding HTTP, che consiste in un modo per inviare messaggi XML via HTTP senza SOAP. JAX-RPC ignorava l'HTTP binding mentre JAX-WS lo supporta.
• WS-I's Basic Profiles (Web Service interoperability)
• JAX-RPC supporta WS-I's Basic Profile (BP) 1.0. JAX-WS supporta la versione successiva, BP 1.1.
• Nuove funzionalità Java
• JAX-RPC si basa su Java 1.4, mentre JAX-WS si basa su Java 5.0. JAX-WS sfrutta le nuove funzionalità offerte dalla nuova versione di Java.
• Java EE 5, il successore di J2EE 1.4, aggiunge il supporto a JAX-WS, ma mantiene anche quello per JAX-RPC, anche se può creare confusione agli utenti.
• Il modello di data mapping
• JAX-RPC ha il suo modello di mapping, che copre circa il 90% dei modelli di tipi. Quelli non coperti sono mappati in javax.xml.soap.SOAPElement.
• Il modello di mapping di JAX-WS è JAXB. JAXB promette di mappare tutti i modelli di tipo.
• Il modello di mapping di interfacce

Il modello di mapping di interface di JAX-WS non è molto differente da quello di JAX-RPC, comunque:

• Il modello di JAX-WS fa uso delle funzionalità di Java 5.
• Il modello di JAX-WS aggiunge funzionalità asincrone.
• Il modello di programmazione dinamica
• Il modello di client di JAX-WS è abbastanza differente da quello di JAX-RPC.
• Introduce funzionalità orientate ai messaggi.
• Introduce funzionalità asincrone dinamiche.
• JAX-WS aggiunge anche un modello di server dinamico che JAX-RPC non aveva.

• MTOM (Message Transmission Optimization Mechanism) .
• JAX-WS, tramite JAXB, aggiunge il supporto a MTOM, la nuova specifica per gli allegati. Microsoft non ha mai creduto nella specifica SOAP with Attachment (SwA), ma sembra che tutti supportino MTOM, quindi l'interoperabilità per gli allegati sembra raggiunta.
• Il modello degli handlers.
• Il modello degli handlers è stato modificato da JAX-RPC a JAX-WS.
• Gli handlers JAX-RPC si basano su SAAJ 1. Gli handlers JAX-WS si basano sulla nuova specifica SAAJ 1.3.

Vediamo adesso quali novità sono state introdotte con SOAP 1.2, XML/HTTP, WS-I Basic Profile e Java 5.

SOAP 1.2

Dal punto di vista del modello di programmazione non c'è grande differenza tra SOAP 1.1 e SOAP 1. Come programmatore Java, l'unico punto dove si incontrano differenze è nell'uso degli handlers. SAAJ 1.3 è stato aggiornato per supportare SOAP 1.

XML/HTTP

Come per i cambiamenti fatti per SOAP, non ci sono molte differenze da un punto di vista di modello di programmazione tra messaggi SOAP/HTTP e XML/HTTP. Anche per questi l'unica modifica rilevante per un programmatore, sta nell'uso degli handlers. Il binding  ha il suo handler e il suo set di proprietà nel message context.

WS-I basic profiles

JAX-RPC 1.1 supporta WS-I Basic Profile (BP) 1.0 [14]. Il team del WS-I ha continuato a sviluppare BP 1.1 e gli associati AP1.0 [28] e SSBP 1.0 [29]. Questi nuovi profili chiarificano alcuni aspetti secondari e definiscono gli allegati. JAX-WS 0 supporta questi nuovi profili. Per la maggior parte, non intaccano il modello di programmazione Java. L'eccezione sono gli allegati. WS-I non solo chiarisce alcune questioni sugli allegati, ma definisce il loro tipo XML: wsi:swaRef.

Vediamo brevemente la storia di questi profili per semplificarne la comprensione. Il primo profilo base WS-I (BP 1.0) fece un ottimo lavoro per chiarire le varie specifiche. Ma non tutto fu perfetto, soprattutto per quanto riguarda il supporto per i SOAP with Attachments (SwA). Nella seconda versione gli allegati furono separati dal profilo base (BP1.1) e alcune aspetti mancanti furono sistemati. A questo punto furono aggiunti due supplementi al profilo base: AP 1.0 e SSBP 1.0. AP 1.0 è l'Attachment Profile [28] che descrive come usare SwA. SSBP 1.0 è Simple SOAP Binding Profile [29], che descrive un Web Service che non supporta SwA (come il .NET di Microsoft).

Java 5

Ci sono numerosi cambiamenti nel linguaggio Java. JAX-WS ovviamente li sfrutta, come ad esempio l'uso di annotazioni nel codice per definire un servizio già nella classe che lo implementa.

Il cambio di nome da JAX-RPC a JAX-WS ha molte motivazioni, le principali sono:

• Molti sviluppatori sarebbero stati ingannati dal nome e avrebbero pensato che la specifica fosse ristretta all'uso di RPC e non di Web Service.
• JAX-WS usa JAXB per tutti i databinding. Questo ha introdotto molti problemi di compatibilità con la precedente versione visto che utilizza dei binding diversi. Il cambio di nome tende a rimarcare che le due tecnologie sono diverse e la migrazione tutt'altro che banale.

Il porting alle nuove specifiche è quindi un'operazione complessa che può comportare una profonda modifica dei progetti esistenti. Tale operazione deve essere quindi ben ponderata e studiata prima i procedere. Vediamo alcune motivazioni per cui adeguarsi ai nuovi standard.

Ragioni per rimanere a JAX-RPC

• Si vuole continuare ad utilizzare tecnologie basate su specifiche ben collaudate.
• Non si vuole passare a Java 5.
• Si vuole inviare messaggi SOAP codificati o creare WSDL in stile RPC/encoded.

Ragioni per passare a JAX-WS 0:

• Si vuole usare le nuove API orientate ai messaggi.
• Si vuole usare MTOM per inviare dati allegati.
• Si vuole un miglior supporto agli schemi XML attraverso JAXB.
• Supporto al modello di programmazione asincrona.
• Supporto al SOAP 1.
• Per avere la possibilità di eliminare il SOAP e utilizzare l'XML/ binding.

Nonostante ci possano essere delle buone motivazioni per ritardare il passaggio alle nuove specifiche, in futuro le applicazioni basate su JAX-RPC smetteranno di essere supportate, come già successo per AXIS, e il passaggio sarà a quel punto inevitabile.

Vediamo l'architettura alla base di JAX-WS:

Runtime:

Il modulo Runtime è disponibile all'applicazione a tempo di esecuzione e rappresenta il cuore del framework dei Web Service.

Tools:

Sono gli strumenti per convertire i WSDL e le classi o sorgenti Java in servizi.

APT.

Uno strumento di Java SE: un framework per elaborare le annotazioni.

Annotation Processor:

Un APT Annotation Processor per elaborare i sorgenti Java con annotazioni javax.jws.* e convertirli in Web Service.

Runtime SPI:

Una parte di JAX-WS che definisce il contract tra il JAX-WS RI (Reference Implementation) runtime e Java EE.

Tools API

Una parte di JAX-WS che definisce il contract tra il JAX-WS RI tools e Java EE.

JAXB XJC-API

Lo schema compiler.

JAXB runtime-API

Una parte di JAX-WS che definisce il contract tra il JAX-B RI e JAX-WS RI.

3.5 SAAJ

Nella descrizione di JAX-RPC e JAX-WS è stata più volte nominata questa importante API. SOAP with Attachment API for Java (SAAJ) [25,40] è una API per la creazione, manipolazione e invio di messaggi SOAP. Altre API XML usano SAAJ per svolgere le loro funzioni, come appunto JAX-RPC e JAX-WS. SAAJ 1.3 è conforme a SOAP 1.2 e SwA, quindi può essere utilizzato per creare e inviare messaggi SOAP con o senza allegati.

3.6 JAXR

La Java API for XML Registry (JAXR) [26,42] è un'API Java che può essere utilizzata per avere un accesso standard a registri come UDDI. Le specifiche JAXR forniscono dunque un'interfaccia standard per costruire clients indipendenti dal registro utilizzato.