Capire l'ambiente JAX-RPC SI, Parte 1di Arun Gupta traduzione di Alessio Cervellin Note sulla traduzione: Questo white paper spiega come sfruttare al meglio gli strumenti wscompile e wsdeploy che vengono utilizzati per sviluppare, deployare ed invocare un Web Service utilizzando le Java API for XML-based RPC (JAX-RPC). Il presente è il primo di due documenti ed illustra gli strumenti wscompile, wsdeploy e i file di configurazione che utilizzano. Il secondo invece illustra gli scenari più comuni che si possono incontrare nello sviluppo, nel deploy e nell' invocazione di un Web Service e spiega come realizzarli tramite gli strumenti wscompile e wsdeploy. 1.0 Introduzione
1.0 IntroduzioneI Web Service sono applicazioni enterprise che utilizzano
standard e protocolli di trasporto aperti basati su XML per scambiare
dati con i client che li invocano. La JAX-RPC Standard Implementation
(SI) fornisce gli strumenti wscompile e wsdeploy per consentire lo
sviluppo, il deploy e l'invocazione di un Web Service. Essa, insieme al
wscompile e wsdeploy, è disponibile nel Java Web Services Developer
Pack (Java WSDP). Il Java WSDP è un insieme di strumenti gratuiti che
possono essere utilizzati per costruire, testare e deployare
applicazioni XML, Web Service, e applicazioni Web con le più recenti
tecnologie ed implementazioni standard riguardanti i Web Services. Per
sviluppare applicazioni di livello enterprise pienamente supportate che
utilizzino le tecnologie Web Services, è consigliato l'uso di Sun Java
Studio Enterprise e Sun Java System Application Server. La suddivisione del ciclo di sviluppo e deploy di un Web
Service in due appositi strumenti consente anche una separazione logica
delle due fasi. Durante la fase di sviluppo il file WAR grezzo conterrà
solo gli artefatti portabili, un descrittore di deployment necessario
per il successivo deploy, e un model file generato dal wscompile. Il
wsdeploy prende questo WAR file grezzo e genera un WAR file elaborato
pronto per essere deployato, contenente gli artefatti dipendenti
dall'implementazione. Gli scenari più comuni, così come i meccanismi
per implementarli, vengono descritti nella sezione 6.0. 2.0 Il wscompileIl wscompile genera diversi artefatti, sia lato client che
lato server, richiesti dall'ambiente JAX-RPC per sviluppare,
deployare ed invocare un Web Service. E' disponibile sottoforma di
script shell e file batch nella cartella JWSDP_HOME/jaxrpc/bin, dove
JWSDP_HOME è la cartella dove è stato installato il Java WSDP. Sebbene
negli esempi seguenti venga utilizzato lo shell script, entrambi hanno
funzionalità identiche. Usage: wscompile [options] configuration_file dove [options] include: -classpath <path> specifica dove trovare le classi di input -cp <path> stesso di -classpath <path> -d <directory> specifica dove salvare i file di output -define definisce un servizio -f:<features> abilita le funzionalità specificate (vedi sotto) -features:<features> stesso di -f:<features> -g genera informazioni di debug -gen stesso di -gen:client -gen:client genera gli artefatti lato client (stubs, etc.) -gen:server genera gli artefatti lato server (ties, etc.) -source <version> genera codice per la versione JAXRPC SI specificata versioni supportate: 1.0.1, 1.0.3 e 1.1 (predefinita) -httpproxy:<host>:<port> specifica un proxy server HTTP (porta predefinita a 8080) -import genera solo le interfacce e i value types -keep conserva i file generati -model <file> scrive il model file nel file specificato -nd <directory> specifica dove mettere i files generati che non siano classi -O ottimizza il codice generato -s <directory> specifica dove mettere i file sorgenti generati -verbose mostra i messaggi sull'attività del compilatore -version stampa informazioni sulla versione -mapping <file> scrive il mapping file JSR 109 nel file specificato Esattamente una delle opzioni -import, -define, -gen deve essere specificata. L'opzione -f richiede una lista di funzionalità separate da virgola. Funzionalità supportate: (-f) datahandleronly mappa sempre gli attachment al tipo DataHandler documentliteral usa la codifica document literal rpcliteral usa la codifica rpc explicitcontext abilita il service context mapping esplicito infix:<name> specifica un prefisso da utilizzare per le classi tie e i serializzatori generati infix=<name> stesso di infix:<name> (no su Windows) jaxbenumtype mappa le enumeration anonime al rispettivo tipo base nodatabinding disabilita il data binding per la codifica literal noencodedtypes disabilita le informazioni sul tipo di encoding nomultirefs disabilita il supporto di riferimenti multipli norpcstructures non genera le strutture RPC (solo per -import) novalidation disabilita la validazione completa dei documenti WSDL importati resolveidref risolve xsd:IDREF searchschema cerca aggressivamente nello schema i sottotipi serializeinterfaces abilita la serializzazione diretta delle interfacce strict genera codice strettamente aderente alle speciiche JAXRPC 1.1 useonewayoperations permette la generazione di operazioni one-way wsi abilita la WSI-Basic Profile (per document/literal e rpc/literal) unwrap abilita l' unWrapping di elementi document/literal in modalità wsi donotoverride non rigenera le classi donotunwrap disabilita l' unWrapping di elementi document/literal in modalità wsi (predefinito) Opzioni ad uso interno (non supportate): -Xdebugmodel:<file> scrive una versione del model su un file -Xprintstacktrace stampa gli stack trace delle eccezioni -Xserializable genera value types che implementano l'interfaccia Serializable Esempi: wscompile -gen -classpath lib/foo.jar;lib/bar.jar -d generated config.xml wscompile -gen -f:infix:Name -d generated config.xml wscompile -define -f:nodatabinding -f:novalidation config.xml wscompile -import -f:explicitcontext config.xml Il tool funziona nelle modalità import, define o gen e prende come input un file di configurazione. Il formato del file di configurazione, per ciascuna delle modalità, è definito da uno schema che verrà illustrato nella sezione 4.0. 2.1 Task AntInsieme al wscompile viene fornito un task ant. Di seguito sono elencati gli attributi e gli elementi supportati da detto task:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Esempi
L'esempio precedente genera gli artefatti lato client, salva i file .class nella cartella ${build}, e mappa gli header del WSDL ai parametri dei metodi utilizzando il file di configurazione config.xml. Il classpath utilizzato è xyz.jar e la compilazione avviene con le informazioni di debug abilitate.
L'esempio precedente genera le interfacce e i value types per l'endpoint del servizio come da WSDL specificato nel config.xml, salva i file .java nella cartella ${cource.dir}, salva i file .class nela cartella ${build}, e genera il model file model.xml.gz nella cartella corrente. Inoltre stampa lo stack trace nel caso in cui si dovesse verificare una eccezione. Il path è un riferimento ad una struttura di tipo path compile.classpath, definita altrove nell'ambiente di compilazione.
L'esempio precedente genera un WSDL document/literal nella cartella ${wsdl.dir} per l'interfaccia e l'implementazione dell'endpoint specificato nel config.xml, e mappa i metodi con tipo di ritorno void come operazioni di tipo one-way. Fork =”true” fa sì che venga invocato il compilatore javac predefinito in un processo separato.
3.0 La configurazione del wscompile (config.xml)Il file di configurazione è la fonte primaria di informazioni per il wscompile. Queste informazioni vengono analizzate, insieme ai vari switch specificati durante l'invocazione del wscompile, al fine di generare gli artefatti. Diamo un'occhiata alle dichiarazioni di schema in testa al file di configurazione.
Lo schema inizia con la dicitura standard XML, poi dichiara lo
schema nel namespace definito da targetNamespace, ossia
http://java.sun.com/xml/ns/jax-rpc/ri/config. Inoltre definisce altri
prefissi di namespace: xsd, che si riferisce al namespace dello schema
XML, e tns, che si riferisce al namespace del file di configurazione.
Lo schema inoltre richiede che tutti gli elementi dichiarati localmente
siano qualificati e gli attributi no.
Deve contenere uno, e solo uno, degli elementi specificati,
corrispondenti alle quattro differenti modalità per fornire informazoni
al wscompile. Ciascuno di questi metodi richiede un formato differente
per il file di configurazione. Ciascun formato consente di utilizzare
il wscompile nelle sue tre funzionalità principali (-import, -define,
and -gen). La tabella sottostante mostra come le informazioni vengano
fornite al wscompile e il corrispondente formato del file di
configurazione. Vengono inoltre messe in relazione le diverse
funzionalità del wscompile con ciascun formato.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
* E' raccomandato solo -gen:server perchè gli artefatti lato client dovrebbero essere generati solo a partire dal WSDL esposto dopo che il servizio sia stato deployato. Di seguito vengono spiegati i vari formati del file di configurazione. Ogni sezione inizia spiegando le schema del file di configurazione e poi viene fornito un esempio di tale formato. 3.1 A partire dall' interfaccia dell' endpoint del servizioQuesto formato viene utilizzato quando la descrizione di un servizio è definita da un set di interfacce, chiamate interfacce dell'endpoint di servizio nelle specifiche JAX-RPC. Di seguito è illustrato lo schema per la definizione degli elementi:
L'attributo name viene utilizzato per identificare il servizio. E' obbligatorio e viene utilizzato dal wscompile per:
L'attributo targetNamespace, ti tipo anyURI, viene utilizzato
come namespace di destinazione per il documento WSDL generato. E' un
attributo obbligatorio. L'attributo typeNamespace, di tipo anyURI, viene utilizzato
come namespace di destinazione per lo schema XML inserito nella sezione
<type> del documento WSDL generato. E' un attributo obbligatorio. L'attributo packageName, di tipo string, specifica il nome del
package
java nel quale vengono generati gli artefatti relativi al servizio. L'elemento interface, di tipo interfaceType (definito sotto),
viene
utilizzato per specificare la descrizione dell'interfaccia
dell'endpoint del servizio. E' un elemento opzionale. Sebbene si stia
specificando un servizio a partire dal Java, si avrà avrà sempre almeno
un elemento interface nel file di configurazione. L'elemento typeMappingRegistry, di tipo
typeMappingRegistryType
(definito nella sezione 3.5.1), viene utilizzato per specificare il
type mapping registry utilizzato per tutte le interfacce del servizio
specificato. E' un elemento opzionale. Se assente, verrà utilizzato il
type mapping registry standard supportato dall'ambiente JAX-RPC. Il
type mapping standard supporta il set di tipi di dato XML specificato
nella codifica SOAP 1.1 e nelle specifiche XML. Il type mapping
standard inoltre specifica il mapping XML per il set di tipi Java
supportati da JAX-RPC. Questo elemento è richiesto solo se
l'applicazione deve supportare il mapping tra altri tipi di dato XML e
altri tipi
di dato Java oltre a quelli previsti dal mapping standard. L'elemento handlerChains, di tipo handlerChainsType (definito
nella
sezione 3.5.2), viene utilzzato per specificare la catena di handler
che verrà eseguita su client e/o sul server per tutte le interfacce
definite nel servizio. Da notare che dato che tutti gli elementi vengono definiti in sequenza, essi devono comparire nello stesso ordine specificato nello schema. Si dia un'occhiata agli altri tipi utilizzati per definire questa sezione prima di analizzare un file di configurazione di esempio. Il seguente è lo schema per l'elemento interfaceType:
Come già detto, questo elemento viene utilizzato quanto la
definizione di un endpoint è basata sull'interfaccia dell'endpoint
stesso. L'attributo name, di tipo string, specifica il fully-qualified
name
dell'interfaccia dell'endpoint del servizio (un' interfaccia Java). E'
un attributo obbligatorio. L'attributo servantName, di tipo string, specifica il
fully-qualified
name della classe di implementazione dell'endpoint del servizio. L'attributo soapAction, di tipo string, specifica la stringa
SOAPAction
da utilizzare per tutte le operazioni dell'interfaccia. E' un attributo
opzionale. L'attributo soapActionBase, di tipo string, specifica l'URI
base per la
stringa SOAPAction. La SOAPAction per una determinata operazione viene
ottenuta appendendo il nome dell'operazione al valore specificato qui.
Questo attributo è in mutua esclusione con soapAction. E' un attributo
opzionale. L'elemento handlerChains, di tipo handlerChainsType (definito nella sezione 3.5.2), viene utilizzato per specificare le catene di handler che verranno eseguite sul client e/o sul server per l'interfaccia dell'endpoint del servizio. Gli handler definiti a livello di interfaccia vanno in override agli handler definiti a livello di servizio. EsempiSi consideri un Web Service per quotazioni di borsa definito dalla seguente interfaccia dell'endpoint:
Un file di configurazione di esempio per un servizio così definito è il seguente:
com.example.StockQuoteProvider è l'interfaccia dell'endpoint e
com.example.StockQuoteImpl ne è l'implementazione. Tutti gli artefatti
per questa interfaccia vengono generati nel package com.example come
specificato nell'attributo packageName.
In grassetto sono evidenziati gli attributi del WSDL che sono
stati presi dal file di configurazione. La tabella seguente mostra come
gli attributi del WSDL siano derivati dal file di configurazione:
L'indirizzo dell'endpoint per ogni porta presente nel WSDL verrà correttamente valorizzato quando il WSDL sarà deployato.
3.2 A partire da un WSDLQuesto formato viene utilizzato quando la descrizione di un servizio si ha sottoforma di un documento WSDL oppure quanto gli artefatti lato client devono essere generati a partire da un WSDL. Di seguito è mostrato lo schema per specificare l'elemento service:
L'attributo location, di tipo anyURI, specifica l'URL del
documento WSDL. Tale documento può risiedere sia sul file system che da
qualunque altra parte su internet. E' un attributo obbligatorio. L'attributo packageName, di tipo string, specifica il nome del package Java da utilizzare per la generazione degli artefatti. E' un attributo obbligatorio. L'elemento typeMappingRegistry, di tipo
typeMappingRegistryType
(definito nella sezione 3.5.1), viene usato per specificare il
type mapping registry utilizzato per tutte le porte del servizio. L'elemento handlerChains, di tipo handlerChainsType (definito nella sezione 3.5.2), viene utilizzato per specificare la catena di handler che verrà eseguita sul client e/o sul server per tutte le porte definite nel servizio. L'elemento namespaceMappingRegistry, di tipo
namespaceMappingRegistryType (definito nella sezione 3.5.3), viene
utilizzato per definire il mapping tra namespace e package Java per
tutte le porte del servizio. Se il WSDL risiede su internet, allora potrebbe essere necessaria l'opzione -httpproxy del wscompile nel caso in cui si è dietro un firewall. EsempiDi seguito viene illustrato un file di configurazione di esempio per il WSDL generato secondo le modalità appena viste:
Questo file di configurazione presuppone che il fle StockQuoteService.wsdl sia presente nella directory corrente e il wscompile genererà gli artefatti nel package com.example.
3.3 A partire da un Model File (avanzato)Un model file è una rappresentazione dell'endpoint o del
client di un Web Service specifica di JAX-RPC SI, generata dal
wscompile, generalmente disponibile come file .xml.gz. Esso contiene
tutte le informazioni relativamente alle strutture dati interne che
consentono più facilmente la generazione degli artefatti specifici
dell'implementazione. Dato che il wsdeploy supporta solo un set
limitato di switch, la maggior parte di quelli specificati durante
l'esecuzione del wscompile vengono memorizzati come parte del model.
L'attributo location, di tipo anyURI, specifica l'URL del file model (tipicamente con estensione .xml.gz). Questo file può risiedere sia sul file system locale che da qualunque altra parte su internet. Se il model risiede su internet, allora l'opzione -httprpoxy del wscompile potrebbe rendersi necessaria quando ci si trova dietro un firewall. EsempiUn file di configuazione di esempio a partire da un file model è il seguente:
Questo file di configurazione presuppone che il file model.xml.gz si trovi nella cartella corrente.
3.4 A partire da un file di mapping J2EE (avanzato)Un file di mapping J2EE contiene informazioni che mettono in
corrispondenza il mapping tra le interfacce Java e le definizioni WSDL.
Uno strumento di deploy J2EE utilizza queste informazioni assieme al
file WSDL per generare gli stub e i tie per i servizi deployati. EsempiUn file di configurazione di esempio a partire da un file di mapping J2EE è il seguente: Questo file di configurazione presuppone che stock-mapping.xml e StockQuoteService.wsdl si trovino nella directory corrente. 3.5 Funzionalità avanzateQuesta sezione descrive le funzionalità avanzate dello strumento wscompile. Le funzionalità descritte sono utilizzabili solo con i file di configurazione di wscompile a partire dall'interfaccia dell'endpoint o da un WSDL. 3.5.1 Aggiungere i Type MappingsNelle fasi di sviluppo, deploy e invocazione di un Web Service
è raccomandabile utilizzare il type mapping standard di JAX-RPC.
Specificare un mapping personalizzato rende il Web Sevice, e i suoi
client, non portabili.
L'elemento import, di tipo importType (definito sotto), è una
lista di schemi XML che descrive i tipi definiti dall'utente, di solito
sono i tipi utilizzati dai serializzatori pluggable. L'elemento typeMapping, di tipo typeMappingType (definito
sotto), è una
sequenza di type mapping. Da notare che questo elemento ha una
cardinalità "unbounded", quindi può apparire più volte, una per
ciascuna codifica. L'elemento additionalTypes, di tipo additionalTypesType
(definito
sotto), è una lista di tipi Java addizionali che devono essere
elaborati anche quando non compaiono nelle interfacce del servizio.
Questa elaborazione consiste nel generare serializzatori e
deserializzatori per ogni classe che sia un JavaBean per poi inserirli
nel type mapping registry creato dal tool che viene utilizzato a
runtime. Ciò può servire se la classe memorizzata in java.util.Vector
non compare in nessuno delle signature dei metodi dell'endpoint.
Altrimenti, il tool elabora solo le classi che compaiono nell'endpoint. Lo schema per importare una lista di schemi è il seguente:
L'elemento schema, di tipo schemaType (definito sotto), è una lista di schemi da importare.
L'attributo namespace, di tipo anyURI, specifica il namespace
che il documento descrive. E' un attributo obbligatorio. L'attributo location, di tipo anyURI, specifica un URL che
punta allo
schema. E' un attributo obbligatorio. Si consideri il caso in cui lo schema per la classe java.util.Vector sia disponibile nel namespace http://schema.org/java/collections/vector all'indirizzo http://stockquote.org/types/vector. In questo caso, l'elemento import sarà:
Lo schema per definire il type mapping per una particolare codifica è il seguente:
L'elemento entry, di tipo entryType (definito sotto), definisce una lista di type mapping. L'elemento encodingStyle, di tipo anyURI, specifica l' URI che
indica
la codifica. E' un attributo obbligatorio e andrebbe settato a stringa
vuota nel caso di literal. Lo schema che definisce un type mapping per una codifica è il seguente:
L'attributo schemaType, di tipo QName, identifica il nome di un tipo di schema. E' un attributo obbligatorio. L'attributo javaType, di tipo string, identifica il fully qualified name della corrispondente classe java. E' un attributo obbligatorio. L'attributo serializerFactory, di tipo string,
identifica il
fully qualified name della classe serializer factory da utilizzare per
questo tipo. E' un attributo obbligatorio. L'attributo deserializerFactory, di tipo string, identifica il
fully
qualified name della classe deserializer factory da utilizzare per
questo tipo. E' un attributo obbligatorio. EsempiContinuando con il solito esempio, si consideri il caso in cui lo schema importato definisca il tipo XML per la classe java.util.Vector con un elemento dal nome "vector". Inoltre, si supponga di avere disponibili le serializer e deserializer factory in com.example.VectorSerializerFactory e com.example.DeserializerFactory. In questo caso l'elemento typeMapping sarà il seguente:
Si noti che l'elemento schemaType proviene dal namespace
importato. La scrittura di queste serializer e deserializer factory non
rientra nell'ambito di questo articolo.
L'elemento class, di tipo classType (definito sotto), identifica una lista di classi da essere elaborate.
L'elemento name identifica il nome della classe da essere elaborata. Nel solito esempio, se com.example.StockDailyHighs è memorizzato in un java.util.Vector, l'elemento additionalType sarà:
Aggregando tutte le informazioni sul type mapping, l'elemento typeMappingRegistry sarà:
Dunque il file di configurazione completo per l'esempio in oggetto, a partire dall'endpoint di un servizio, è il seguente:
Sebbene questo esempio parta dall'interfaccia dell'endpoint di un servizio, è utilizzabile anche come file di configurazione nel caso in cui si parta da un WSDL.
3.5.2 Aggiungere gli HandlerL'handler di un messaggio SOAP ha accesso al messaggio SOAP che rappresenta la chiamata o la risposta RPC. Questi handler vengono configurati tramite catene di handler [handler chains] di tipo handlerChainsType (definito sotto):
Ogni catena di handler rappresenta una lista ordinata di handler ed è definita dal seguente schema:
L'attributo runAt, di tipo runAtType (definito sotto), specifica se la catena deve essere eseguita lato client o lato server. E' un attributo obbligatorio in quanto l'utente deve specificare se la catena di handler deve essere configurata sul client o sul server. L'elemento handler, di tipo handlerType (definito sotto), specifica la sequenza di handler che compone la catena. Una catena di handler è configurata per agire col ruolo [role]
di un o più
attori [actor] SOAP, specificati utilizzando un URI denominato SOAP
actor name.
Lo schema per la descrizione di un handler è il seguente: L'attributo className, di tipo string, specifica il fully-qualified name della classe handler. E' un attributo obbligatorio. L'attributo headers, di tipo headerListType (definito sotto),
identifica la lista di nomi di header a cui l'handler dovrà accedere.
E' un attributo opzionale. L'elemento property, di tipo propertyType (definito sotto),
definisce
le proprietà di inizializzazione per l'hanlder. Il seguente è lo schema per definire una lista di nomi di header utilizzati dall'handler, ossia una lista di QName:
Questo è lo schema per definire una proprietà di inizializzazione di un handler:
L'attributo name, di tipo string, definisce il nome della proprietà L'attributo value, di tipo string, definisce il valore della proprietà. Questa invece è la lista di valori che può assumere l'attributo runAt, ed indica che l'handler può essere attivato sia sul client che sul server:
EsempiContinuando sempre con lo stesso esempio, si consideri il caso
in cui un client invii una richiesta criptata ad un endpoint e
l'endpoint decripti la richiesta prima di esaminarla. Questa
funzionalità può essere facilmente implementata inserendo degli
handler lato client e lato server.
L'elemento handlerChains lato server sarà:
Questo invece è l'elemento handlerChains lato server con specificato un header, che l'handler può ricevere, chiamato session-id nel namespace http://echo.org/example :
Gli header specificati tramite la precedente configurazione possono essere acceduti dall'handler tramite il seguente codice:
Sebbene questo esempio sia a partire dalle interfacce
dell'endpoint del servizio, lo stesso schema è utilizzabile nel caso in
cui si parta da un WSDL. Stesso schema viene utilizzato per aggiungere
gli handlers al descrittore di deployment.
Si faccia riferimento al tutorial del Java Web Services Developer Pack per un esempio su come realizzare un handler.
3.5.3 Aggiungere i mapping namespace-to-packageIl mapping del namespace permette di specificare il mapping
tra i namespace XML verso/da i package Java. Lo schema per specificare
questo mapping è il seguente: L'elemento namespaceMapping, di tipo namespaceMappingType
(definito sotto), identifica una lista di mapping.
L'attributo namespace, di tipo string, identifica il nome del namespace. E' un attributo obbligatorio. L'attributo packageName, di tipo string, identifica il nome del package. E' un attributo obbligatorio. EsempiSi consideri un WSDL avente la seguente sezione <types> :
In questo pezzo di WSDL tickerSymbol è un tipo complesso definito in due namespace differenti. Il tickerSymbol definito nel namespace http://stockquote.org/types1 namespace ha solo il simbolo ticker. Il tickerSymbol definito nel namespace http://stockquote.org/types2 contiene anche il nome della compagnia a cui appartiene questo ticker. Affinchè il wscompile generi i corrispondenti value types per entrambi i tipi complessi, è necessario specificare i mapping namespace-to-package nel file di configurazione:
Il wscompile genererà com.example.types1.TickerSymbol e
com.example.types2.TickerSymbol con le appropriate variabili membro. Partendo dall'interfaccia dell'endpoint del servizio, il file di configurazione è il seguente:
Si supponga che i value type com.example.types1.TickerSymbol e com.example.types2.TickerSymbol siano utilizzati dall'interfaccia dell'endpoint insieme ad altri value type. In questo caso, il WSDL generato avrà una sezione <types> con tre elementi <schema> :
Tutti i tipi del package com.example.types1 vengono mappati nel namesapce http://stockquote.org/types1, tutti quelli del package com.example.types2 package in http://stockquote.org/types2, e tutti gli altri tipi nel namespace http://stockquote.org/types. 4.0 Il wsdeployIl wsdeploy viene utilizzato congiuntamente al wscompile per
generare un file WAR che può essere deployato in qualsiasi servlet
container (Tomcat nel caso del Java Web Services Developer Pack).
Questo strumento prende in ingresso un file WAR grezzo [raw WAR]
contenente
l'interfaccia dell'endpoint del servizio, l'implementazione, eventuali
value types, eventuali eccezioni specifiche del servizio, un model
file, un descrittore di deployment (jaxrpc-ri.xml), e opzionalmente
qualsiasi altro artefatto specifico dell'implementazione. Il wsdeploy
analizza questo WAR e ne genera un altro specifico dell'implementazione
chiamato WAR elaborato [cooked WAR]. Questo processo
coinvolge la generazione di serialzizatori, ties, descrittori di
runtime, e tutti gli eventuali artefatti necessari per un corretto
deploy del Web Service. error: missing input WAR file Usage: wsdeploy <options> <WAR file> dove <options> include: -classpath <path> specifica un classpath opzionale -keep mantiene i file temporanei -o <output WAR file> specifica dove salvare il file WAR generato -tmpdir <directory> specifica la directory temporanea da usare -verbose mostra messaggi sull'attività del compilatore -version stampa informazioni sulla versione -source <version> genera codice per la versione JAXRPC SI specificata. Le versioni supportate sono: 1.0.1, 1.0.3 and 1.1 (predefinita) L'opzione -o è obbligatoria. Esempi: wsdeploy -o target.war myapp.war Il tool prende il WAR file grezzo myapp.war e genera il file WAR elaborato target.war. 4.1 Task AntInsieme al wsdeploy viene fornito anche un task Ant. Elementi ed attributi supportati da questo task sono:
L'attributo classpath è una struttura di tipo path e può
essere settata anche con elementi <classpath> annidati. Prima che
questo task possa essere usato, è necessario aggiungere al progetto
l'elemento <taskdef> come di seguito: Esempi
Questo esempio prende il WAR file grezzo stock-raw.war e genera il file WAR elaborato stock.war. Il classpath include xyz.jar, e la directory temporanea è ${tmp}.
Questo esempio prende il WAR file grezzo stock-raw.war e genera il file WAR elaborato stock.war. Il classpath è un riferimento alla struttura di tipo path compile.classpath, definita da qualche altra parte nell'ambiente di compilazione, e il file WAR elaborato contiene il codice sorgente degli artefatti lato server generati.
Questo esempio prende il WAR file grezzo stock-raw.war e genera il file WAR elaborato stock.war compatibile con la versione 1.0.3 di JAX-RPC. Fork =”true” fa sì che venga invocato il compilatore javac predefinito in un processo separato.
5.0 Il Descrittore di Deployment (jaxrpc-ri.xml)Il descrittore di deployment, jaxrpc-ri.xml, è incluso nel file WAR grezzo e viene utilizzato dal wsdeploy per generare il file WAR elaborato. Questo descrittore fornisce informazioni necessarie al wsdeploy per deployare il Web Service nel web container. Questa è la dichiarazione in testa a tale descrittore:
Lo schema inizia con la dicitura standard XML, poi dichiara lo
schema nel namespace definito da targetNamespace, ossia
http://java.sun.com/xml/ns/jax-rpc/ri/config. Inoltre definisce altri
prefissi di namespace: xsd, che si riferisce al namespace dello schema
XML, e tns, che si riferisce al namespace del file di configurazione.
Lo schema inoltre richiede che tutti gli elementi dichiarati localmente
siano qualificati e gli attributi no.
L'attributo version, di tipo string, identifica il numero di versione, ed è attualmente riservato per future funzionalità. E' un attributo obbligatorio e il suo valore è fissato a "1.0". L'attributo targetNamespaceBase, di tipo string, identifica l' URI base per i target namespace dei WSDL generati per gli endpoint che non hanno un proprio model file. L'attributo typeNamespaceBase, di tipo string, è simile all'attributo targetNamespaceBase attribute ma viene utilizzato per gli schemi XML inseriti nei WSDL generati. L'attributo urlPatternBase, di tipo string, identifica il pattern dell' URL base per tutti gli endpoint. Se ne può fare l'override utilizzando l' endpointMapping (vedi sotto). Per tutte le proprietà base (targetNamespaceBase, typeNamespaceBase, e urlPatternBase) il valore utilizzato per uno specifico endpoint viene espresso aggiungendo al valore base il nome dell'endpoint. L'elemento endpoint, di tipo endpointType (definito sotto) definisce una sequenza di descrizioni di endpoint. L'elemento endpointMapping, di tipo endpointMappingType,
definisce una
sequenza di mapping di endpoint.
L'attributo name, di tipo string, definisce il nome dell'endpoint. E' un attributo obbligatorio. L'attributo displayName, di tipo string, definisce un nome in forma human-readable per l' endpoint. L'attributo description, di tipo string, definisce una descrizione dell' endpoint. L'attributo interface, di tipo string, identifica il nome dell'interfaccia dell'endpoint del servizio. L'attributo implementation, di tipo string, identifica il nome della classe di implementazione del servizio. L'attributo model, di tipo string, indica il model file, se presente, che descrive l' endpoint.L'elemento handlerChains, di tipo handlerChainsType (definito sopra), identifica le catene di handler da utilizzare per l'endpoint. Si faccia riferimento alla sezione 4.6 per le informazioni riguardanti l'aggiunta di handler chain nel descrittore di deployment. L'unica differenza sta nel fatto che nel descrittore di deployment si possono specificare solo handler lato server. Le catene di handler possono essere specificate sia nel file di configurazione nel momento in cui si usa il wscompile sia qui nel descrittore di deployment. E' raccomandato comunque specificarle nel file di configurazione. Se le catene di handler vengono specificate nel descrittore di deployment, allora vanno in override delle eventuali catene definite nel file di configurazione del wscompile. Il descrittore di deployment contiene inoltre i mapping degli endpoint (tipo i mapping delle servlet ch si hanno nel web.xml) ad un URL. Lo schema per definire questi mapping è il seguente:
L'attributo endpointName, di tipo string, identifica il nome dell' endpoint. E' un attributo obbligatorio. L'attributo urlPattern, di tipo string, definisce l'URL
perl'endpoint.
E' un attributo obbligatorio. Si faccia riferimento alla seconda parte di questo white paper per esempi di descrittori di deployment che definiscono degli endpoint.
6.0 Glossario
7.0 RiferimentiNote sull'autore Arun Gupta è un Ingegnere del team di sviluppo delle API per
l' XML-based RPC (JAX-RPC) presso la Sun Microsystems. Ha maturato
oltre sette
anni di esperienza nell'industria del software, lavorando su svariate
tecnologie inerenti calcolo distribuito, Java, C++, Web. Attualmente fa
parte del team di sviluppo JAX-RPC e rappresenta la Sun all'interno del
WS-I Sample Application Working Group. Ha fatto parte del gruppo
JAX-RPC sin dalle sue origini ed ha apportato un contributo
significativo all'evoluzione della tecnologia. Per commenti scrivere a: users@jax-rpc.dev.java.net. Note sul traduttore Alessio Cervellin è nato nel 1977. E' Ingegnere diplomato
presso l' Università di Roma "La Sapienza" in Informatica ed
Automatica, e dal 2000 lavora come professionista nel settore dell'
Information Technology, specializzandosi sulla piattaforma Java e le
tecnologie
Web. |