Linea guida: Sviluppo dei servizi Web
In questa linea guida viene descritto come scoprire, creare, verificare, distribuire e pubblicare servizi Web utilizzando l'ambiente di modellazione RAD6.0.
Relazioni
Descrizione principale

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.

Approcci per la creazione dei servizi Web di 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 bean Java di base da un documento WSDL

    È possibile creare un bean Java di base da un documento ed esporlo come servizio Web. I metodi bean Java generati 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:

    • È 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 Web.
  • 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
Crea un EJB di base da un documento WSDL
No
No
Crea un servizio Web da un JavaBean
Crea un servizio Web da un EJB
No
Crea un servizio Web da un DADX
No
No
Crea un servizio Web da un URL
No
No
Crea un servizio Web da un ISD (Deployment Descriptor, descrittore di distribuzione) di servizio Web
No
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:
  • Proxy di bean Java

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.