Introduzione
RAD 6.0 fornisce un esteso insieme di tool per supportare la scoperta, la creazione, la verifica, la distribuzione e la
pubblicazione dei servizi Web. Questi tool consentono lo sviluppo di servizi Web basati sugli standard più recenti e il
supporto della distribuzione su più ambienti di esecuzione. Forniscono anche molte procedure guidate per supportare e
agevolare i diversi approcci di sviluppo. In questo documento vengono descritti i vari approcci forniti da RAD 6.0 per
sviluppare un servizio Web e si discutono le considerazioni sullo sviluppo relative alle opzioni di distribuzione del
servizio Web e del livello di interoperabilità.
Approcci di sviluppo
Le procedure guidate dei servizi Web in RAD 6.0 consentono di creare un servizio Web utilizzando sia l'approccio
top-down che bottom-up. L'approccio top-down consente di iniziare con un documento WSDL (Web Services Description
Language) e generare un bean Java di base o un EJB di base che può essere utilizzato per creare un servizio Web.
L'approccio bottom-up consente di creare un servizio Web da un bean Java, un EJB, un file DADX (Document Access
Definition Extender), un URL (Uniform Resource Locator) o un file ISD (Deployment Descriptor, descrittore di
distribuzione) di servizio Web esistente. La figura 1 descrive gli approcci di creazione dei servizi Web forniti da RAD
6.0.
Figura 1 - Approcci di creazione di servizi Web di RAD 6.0
Durante la creazione di un servizio Web, la procedura guidata permette facoltativamente di:
-
Verificare il servizio Web appena viene creato utilizzando il tool Explorer dei servizi Web.
-
Generare un proxy di client utilizzabile nelle applicazioni client per accedere al servizio Web.
-
Verificare un proxy client utilizzando il tool UTC (Universal Test Client) o un'applicazione JSP di esempio
generata dal tool.
-
Pubblicare il servizio Web su un registro UDDI (Universal Description, Discovery and Integration) utilizzando il
tool Explorer dei servizi Web.
I servizi Web sviluppati in RAD 6.0 devono essere creati in un progetto Web o EJB e contenere prodotti di lavoro che si
attengono ai seguenti standard:
-
WSDL (Web Services Definition Language) versione 1.1
-
SOAP (Simple Object Access Protocol) versione 1.1 (incluse le implementazioni SOAP 2.2 e 2.3 di Apache)
-
UDDI (Universal Description, Discovery and Integration) versione 2.0
-
WSIL (Web Services Inspection Language) versione 1.0
-
JAX-RPC (Java API for XML-based Remote Procedure Call), conosciuto anche come JSR-101
-
JSR-109 e JSR-921 (che implementano i servizi Web Enterprise)
-
Profilo di base 1.0 di WS-I (Web Services Interoperability)(conformità facoltativa)
-
WS-Security
Per ulteriori informazioni su questi argomenti, consultare Concetti: servizi Web per J2EE.
Sviluppo top-down
Lo sviluppo top-down permette di prendere una definizione astratta di un servizio Web contenuto in un documento WSDL e
generarne una implementazione concreta. (Nota: RAD 6.0 fornisce anche una procedura guidata per la creazione di un
documento WSDL). Sono supportati i seguenti due approcci:
-
Creazione di un EJB di base da un documento WSDL
Simile al precedente, questo approccio consente di creare un EJB di sessione stateless di base da un documento
WSDL ed esporlo come servizio Web. I metodi nell'EJB corrispondono alle operazioni descritte nel documento WSDL
e contengono una implementazione superficiale sostituibile. Le seguenti considerazioni si applicano a questo
approccio e ai relativi prodotti di lavoro generati:
-
Questo approccio può essere utilizzato solo se si seleziona IBM WebSphere v6 come ambiente di esecuzione
del servizio Web (vedere Dipendenze di distribuzione)
-
È possibile immettere l'URI di un documento WSDL oppure, in alternativa, quello di un documento WSIL o HTML
che punta al file WSDL come origine per il servizio Web.
-
Il file WSDL deve contenere un elemento di servizio. È possibile, facoltativamente, generare anche un
documento di riferimento di WSDL standardizzato (WSIL) per il servizio Web risultante.
-
Il servizio Web generato deve essere creato in un progetto EJB. In aggiunta, viene creato un progetto di
Router per abilitare il servizio Web a ricevere richieste sul trasporto HTTP (nota: il trasporto JMS non è
supportato in questo approccio). Il progetto di Router può essere un progetto Web o EJB e può non essere lo
stesso progetto di quello contenente il servizio Web ma deve essere nello stesso file EAR contenente.
Sviluppo bottom-up
L'obiettivo dello sviluppo bottom-up è quello di esporre un componente o una risorsa di applicazione esistente come
servizio Web. Di seguito, vengono discussi i vari approcci.
-
Creazione di un servizio Web da un bean Java
Questo approccio consente di selezionare un bean Java esistente ed espone i relativi metodi come servizio Web.
I prodotti di lavoro generati comprendono:
-
File WSDL: questo file descrive il servizio Web ed ha come estensione .wsdl. È possibile scegliere tra tre
stili di WSDL (Documento/Letterale, RPC/Letterale e RPC/Codificato). Per gli effetti di interoperabilità di
ogni opzione, consultare Conformità del profilo di base di WS-I.
-
SEI (Service Endpoint Interface): questa interfaccia Java definisce i metodi del servizio Web. Il nome del
file relativo ha un suffisso _SEI.
-
Descrittore di distribuzione di servizio Web: il file webservices.xml specifica i dettagli di
implementazione e distribuzione del servizio Web.
-
File di mappatura di JAX-RPC: questi file definiscono il modo in cui gli elementi di Java del servizio Web
vengono mappati a e da WSDL.
-
Creazione di un servizio Web da un EJB
È possibile esporre i metodi di un bean di sessione stateless come servizio Web. I prodotti di lavoro generati
sono simili a quelli generati per un bean Java bean e includono un file WSDL, SEI, il descrittore di
distribuzione del servizio Web e i file di mappatura di JAX-RPC. Le seguenti considerazioni si applicano a
questo approccio e ai relativi prodotti di lavoro generati:
-
Il servizio Web generato deve essere creato in un progetto EJB.
-
Deve essere creato un progetto di router per abilitare il servizio Web a ricevere richieste da client. Se
si utilizza SOAP su HTTP come metodo di trasporto, creare il progetto di Router come progetto Web. In caso
contrario, se il client utilizza SOAP su JMS, crearlo come progetto EJB (il Router di JMS viene
implementato come bean basato sui messaggi in questo caso). I progetti di Router e servizio Web non possono
essere gli stessi ma devono essere contenuti nello stesso file EAR.
-
Se si utilizza SOAP su JMS, è necessario configurare un provider JMS nel proprio server. Inoltre, non sarà
possibile utilizzare l'Explorer del servizio Web per verificare il proprio servizio Web.
-
Creazione di un servizio Web da un file DADX
Questo approccio consente di inserire i dati di DB2 a cui si accede tramite DB2 XML Extender o istruzioni SQL
regolari all'interno di un servizio Web. I dati a cui si accede attraverso DB2 XML Extender consistono di
documenti XML che vengono mappati a un database DB2 utilizzando un documento DAD (Document Access Definition).
Il punto di partenza dell'approccio è un file DADX che specifica come creare un servizio Web utilizzando
l'insieme di operazioni definite da istruzioni SQL regolari o in un file DAD. I prodotti di lavoro generati
comprendono il file WSDL standard, SEI, il descrittore di distribuzione del servizio Web e i file di mappatura
di JAX-RPC. Le seguenti considerazioni si applicano a questo approccio e ai relativi prodotti di lavoro
generati:
-
Questo approccio può essere utilizzato solo se si seleziona IBM SOAP come ambiente di esecuzione del
servizio Web (vedere Dipendenze di distribuzione).
-
È possibile generare facoltativamente un file DADX da una combinazione di una o più istruzioni SQL,
procedure memorizzate e file DAD.
-
Il file DADX dovrebbe essere contenuto in un gruppo DADX che definisce la connessione JDBC e altre
informazioni condivise tra file DADX all'interno del gruppo.
-
Il servizio Web generato deve essere creato in un progetto Web.
-
Creazione di un servizio Web da un URL
Dal relativo URL, è possibile creare un servizio Web che accede direttamente a un servlet in esecuzione su un
server remoto. La procedura guidata consente di descrivere l'interfaccia di servlet in termini di porte,
operazioni e parametri e genera un documento WSDL che descrive il servizio Web risultante. Le seguenti
considerazioni si applicano a questo approccio e ai relativi prodotti di lavoro generati:
-
Questo approccio può essere utilizzato solo se si seleziona IBM SOAP come ambiente di esecuzione del
servizio Web (vedere Dipendenze di distribuzione).
-
Di solito, la porta corrisponde alla parte del nome di dominio/host dell'URL, l'operazione alla parte della
radice del contesto di servlet e URI, i parametri ai parametri di input di servlet.
-
Il servizio Web generato deve essere creato in un progetto Web.
-
Non c'è alcun servizio Web da distribuire dopo che è stato già implementato dall'URL attivo.
-
Creazione di un servizio Web da un file ISD (Deployment Descriptor, descrittore di distribuzione)
Quando viene distribuito un servizio Web, la relativa configurazione e attributi di esecuzione vengono definiti
in un file descrittore di distribuzione ISD. Questo file fornisce informazioni sul servizio che dovrebbe essere
reso disponibile ai client dall'ambiente di esecuzione SOAP, ad esempio URI, metodi, classi di implementazione
(JavaBean ed EJBs), serializzatori e deserializzatori. È possibile creare un servizio Web da un file ISD
utilizzando queste informazioni disponibili. Ciò consente di impegnare le implementazioni esistenti del
servizio Web e redistribuirle come nuovi servizi Web senza dover specificare nuovamente le loro informazioni di
configurazione e mappatura. Le seguenti considerazioni si applicano a questo approccio e ai relativi prodotti
di lavoro generati:
-
Questo approccio può essere utilizzato solo se si seleziona IBM SOAP come ambiente di esecuzione del
servizio Web (vedere Dipendenze di distribuzione).
-
Il servizio Web generato deve essere creato in un progetto Web
Linee guida per lo sviluppo
Le seguenti sezioni si occupano di importanti considerazioni relative allo sviluppo di un servizio Web in RAD 6.0.
Descrivono le opzioni di sviluppo disponibili basate sulla distribuzione e sui requisiti di conformità di WS-I del
proprio servizio Web.
Dipendenze di distribuzione
Gli approcci (top-down e bottom-up) disponibili per creare un servizio Web dipendono dall'ambiente di esecuzione
obiettivo per la distribuzione. RAD 6.0 supporta i seguenti ambienti di esecuzione di servizi Web:
-
IBM WebSphere v6
Questo è l'ambiente di esecuzione predefinito dei servizi Web in RAD 6.0 e quello consigliato a scopo di
produzione. Supporta sia il protocollo di trasporto JMS che HTTP, consentendo in tal modo ai client e ai server
del servizio Web di comunicare tramite connessioni HTTP o code e argomenti JMS. Si noti che un servizio Web
deve essere implementato come un EJB se sarà accessibile attraverso il trasporto JMS.
-
IBM SOAP
L'ambiente di esecuzione IBM SOAP supporta i protocolli SOAP versione 2.2 e 2.3 di Apache (consultare Risorse)
ed era il solo ambiente di esecuzione di servizi Web supportato in WebSphere Studio versione 5.0 e precedenti.
Dovrebbe essere utilizzato solo con obiettivi di compatibilità retroattiva.
-
Apache Axis 1.0
Questo ambiente di esecuzione supporta l'implementazione di SOAP Apache Axis versione 1.0 (consultare Risorse).
Non è consigliato per la produzione a causa dei potenziali problemi di interoperabilità del servizio Web
(consultate Problemi con l'utilizzo dell'ambiente di esecuzione Apache Axis 1.0 nei contenuti della guida del
tool)
Si consiglia di scegliere l'ambiente di esecuzione IBM WebSphere v5 a meno che la destinazione di distribuzione
richieda specificatamente di utilizzare l'implementazione di Apache SOAP o Apache Axis (in tal caso, prestare
attenzione alle limitazioni associate descritte nel contenuto della guida del tool Limitazioni dei servizi Web). La
tabella 1 riassume gli approcci di creazione del servizio Web supportati da RAD 6.0 per ogni ambiente di
esecuzione.
Approccio
|
IBM WebSphere v6
|
IBM SOAP
|
Apache Axis 1.0
|
Crea un JavaBean di base da un documento WSDL
|
Sì
|
Sì
|
Sì
|
Crea un EJB di base da un documento WSDL
|
Sì
|
No
|
No
|
Crea un servizio Web da un JavaBean
|
Sì
|
Sì
|
Sì
|
Crea un servizio Web da un EJB
|
Sì
|
Sì
|
No
|
Crea un servizio Web da un DADX
|
No
|
Sì
|
No
|
Crea un servizio Web da un URL
|
No
|
Sì
|
No
|
Crea un servizio Web da un ISD (Deployment Descriptor, descrittore di distribuzione) di servizio Web
|
No
|
Sì
|
No
|
Tabella 1 - Approccio di creazione di servizio Web supportato per ambiente di esecuzione
Conformità del profilo di base di WS-I
Il profilo base di WS-I (Web Services-Interoperability,interoperabilità dei servizi Web) è un insieme di requisiti
pubblicati dall'organizzazione di WS-I per promuovere l'interoperabilità attraverso le piattaforme, i sistemi operativi
e i linguaggi di programmazione. Definisce WSDL e i requisiti di traffico di protocollo (SOAP/HTTP) che un servizio Web
deve soddisfare per essere conforme a WS-I. RAD 6.0 comprende tool di convalida che possono essere utilizzati per
verificare la conformità del servizio Web ai requisiti del profilo di base di WS-I 1.0. È possibile impostare un
livello di conformità (Richiesto, Suggerito o Ignorato (predefinito)) per lo spazio di lavoro o progetto prima di
sviluppare un servizio Web o di eseguire i tool di convalida dopo lo sviluppo.
Si consiglia di sviluppare i servizi Web che sono conformi al profilo di base di WS-I. A tal fine, si dovrebbero
seguire le successive linee di guida:
-
Utilizzare Documento/letterale o RPC/letterale per lo stile di WSDL (RPC/codificato non è conforme a WS-I)
-
Utilizzare SOAP su HTTP come protocolli di messaggio e trasporto (SOAP su JMS non è conforme a WS-I)
-
Non utilizzare alcuna opzione di sicurezza per il servizio Web (la firma digitale XML e la codifica XML non sono
conformi a WS-I)
Considerazioni sul proxy di client
-
Ci sono 2 tipi di proxy di client che si possono facoltativamente generare quando si crea un servizio Web:
Il proxy di client bean Java consente di richiamare i metodi del servizio Web tramite chiamate di procedura remote.
Può essere creato solo in un progetto Web di client se IBM SOAP o Apache Axis 1.0 viene selezionato per l'ambiente
di esecuzione di client. Altrimenti, per un ambiente di esecuzione di client IBM WebSphere v6, può essere creato in
un progetto Web, Java, EJB o di client di applicazione.
-
Funzione di servizio Web definita dall'utente
Questa opzione consente di creare una funzione definita dall'utente (UDF) di DB2 per ogni metodo del servizio Web
che si desidera richiamare. Richiede l'installazione nel database del pacchetto di UDF per l'utente dei servizi Web
di DB2 e di DB2 XML Extender. L'UDF viene creata e aggiunta alla definizione di database con tutti i prodotti di
lavoro di client correlati e memorizzati in un progetto Web.
-
Selezionare un differente EAR per il servizio Web e il client di servizio Web per ridurre la possibilità di
incontrare errori di esecuzione. Tenere presente che il client è previsto come un'applicazione diversa dal servizio
Web e i servizi Web non sono destinati alla comunicazione tra applicazioni.
Risorse
Per ulteriori informazioni sugli argomenti in basso, fare riferimento al corrispondente collegamento.
|