Implementazione del broker di un'interfaccia del servizio Web nuova

In questo scenario di servizio Web, il broker fornisce un'interfaccia del servizio Web a un'applicazione diversa da un servizio non Web esistente.

Nel diagramma viene visualizzata un'applicazione esistente il cui file di definizione è importato in una serie di messaggi. Viene creato un file WSDL da una serie di messaggi. La serie di messaggi viene distribuita a un flusso in un broker. Il flusso interagisce con l'applicazione esistente originale e il client del servizio Web.

Legenda dei simboli:

Nel diagramma vengono descritti i simboli utilizzati negli altri diagrammi, che non vengono riportati perché dispongono ciascuno delle proprie descrizioni.

A ciò si fa riferimento qualche volta come facciata del servizio Web. La progettazione dell'interfaccia del servizio Web comprenderà di solito il raggruppamento, la restrizione o il miglioramento dell'interfaccia esistente e non è vincolata da una definizione WSDL esistente.

Possibili utilizzi

Il broker fornisce un'interfaccia dei servizi Web a un'applicazione esistente, fornendo in modo facoltativo altre funzioni, ad esempio il controllo delle richieste effettuate.

Nel tempo è possibile modificare l'implementazione senza influire sull'interfaccia presentata al client dei servizi Web.

Procedura di progettazione

  1. Creare una serie di messaggi per i messaggi aziendali, se possibile importando una definizione di interfaccia esistente, ad esempio, un file di intestazione C o un copybook COBOL.
  2. Creare una definizione WSDL dalla serie di messaggi.
  3. Utilizzare un toolkit SOAP, ad esempio Rational Application Developer per creare un client dei servizi Web adatto basato sul WSDL.
  4. Sviluppare un flusso di messaggi per implementare il servizio Web.

Runtime

Il flusso di messaggi riceve una richiesta del servizio Web, la converte in un formato previsto dall'applicazione esistente e richiama l'applicazione esistente. La risposta da un'applicazione esistente viene convertita in una risposta di servizio Web valida.

Esempio 1

Un'applicazione CICS esistente dispone di un'interfaccia di copybook COBOL.

  1. Importare il copybook di COBOL per creare un modello di messaggio.
  2. Creare un flusso di messaggi con nodi: HTTPInput, HTTPReply e CICS.
  3. Utilizzare i nodi HTTPInput e HTTPReply per fornire la facciata del servizio Web.
  4. Utilizzare il nodo CICS per richiamare l'implementazione CICS originale.

Esempio 2

Il flusso di messaggi viene richiamato come un servizio Web.
Si modifica la progettazione di un flusso di messaggi esistente per interagire con client del servizio Web su HTTP. Il flusso di messaggi esistente prende un messaggio di input ben definito e con il client sarà possibile utilizzare il WSDL esportato dagli strumenti di WebSphere Message Broker per richiamare il flusso di messaggi.

E' possibile utilizzare HTTP come protocollo aggiuntivo o sostituzione adattando la maggior parte dei flussi di messaggi che correntemente utilizzano WebSphere MQ per input o output.


Rappresenta un flusso di messaggi con nodi HTTPInput, Compute1, DataUpdate, Compute2 e HTTPReply.

E' possibile modellare il messaggio di input nel dominio MRM e creare il WSDL dal modello o elaborare un messaggio del dominio XMLNS o XML generico. Se è stato definito il messaggio nel dominio MRM, è possibile configurare la convalida del messaggio di input mediante il nodo HTTPInput. Il nodo genera un'eccezione se il messaggio non è conforme al modello.

E' possibile configurare la creazione di una serie di intestazioni HTTP predefinite per il messaggio di risposta inviato al client mediante il nodo HTTPReply. In tal modo, verranno ridotte le modifiche da effettuare per convertire un flusso che elabora messaggi WebSphere MQ a un flusso che elabora messaggi HTTP.

Esempio 3

Il flusso di messaggi fornisce accesso a un'applicazione WebSphere MQ.
Vengono progettati due flussi di messaggi che inviano e ricevono risposte da client di un servizio Web e interagiscono con un'applicazione WebSphere MQ esistente non adattata alla comunicazione su HTTP.

Il primo flusso di messaggi riceve richieste in entrata da client del servizio Web in un nodo HTTPInput. Comprende un nodo Compute per trasformare la richiesta e un nodo MQOutput per inviare la richiesta modificata all'applicazione WebSphere MQ.

Il secondo flusso di messaggi riceve la risposta dall'applicazione in un nodo MQInput. Il messaggio viene trasmesso a un nodo Compute che trasforma il messaggio e lo invia a un nodo HTTPReply che lo invia come risposta al client del servizio Web originale.

Sebbene sia possibile che le trasformazioni completate da ciascun nodo Compute siano non semplici, è necessario che il codice ESQL nel primo salvi le informazioni di stato HTTP recuperate dal secondo per garantire che le risposte dall'applicazione WebSphere MQ siano restituite al client che ha inviato la richiesta originale.


Rappresenta due flussi di messaggi; il primo dispone di nodi HTTPInput, Compute1 e MQOutput. Il secondo dispone di MQInput, Compute2 e HTTPReply. Il nodo MQOutput che termina il primo flusso inserisce un messaggio in una coda WebSphere MQ assistita da un'applicazione esistente, che inserisce le risposte in una coda di input assistita dal nodo MQInput che avvia il secondo flusso.

Il primo flusso di messaggi riceve il messaggio, effettua le trasformazioni necessarie e codifica l'identificativo della richiesta HTTP nel messaggio in uscita. E' inoltre possibile memorizzare l'identificativo della richiesta in un database, se si preferisce. Il nodo HTTPInput fornisce l'identificativo della richiesta come campo nell'albero LocalEnvironment denominato Destination.HTTP.RequestIdentifier e Compute1 è in grado di leggere e memorizzare tale valore.

Il secondo flusso di messaggi riceve il messaggio di risposta e lo trasforma nuovamente nel formato del messaggio del client. Compute2 legge l'identificativo di richiesta HTTP dal messaggio e imposta LocalEnvironment.Destination.HTTP.RequestIdentifier utilizzando tale valore. Il nodo HTTPReply utilizza l'identificativo della richiesta per garantire che il messaggio raggiunga il client HTTP corretto.

Per l'implementazione di tale scenario è necessaria la corretta gestione di MQMD. E' necessario che i messaggi che vengono immessi in un flusso di messaggi su HTTP dispongano di MQMD prima del relativo invio a un nodo MQOutput. E' inoltre necessario rimuovere MQMD da qualsiasi messaggio immesso in WebSphere MQ prima di inviarlo in un nodo HTTPReply o HTTPRequest (a meno che non si desideri includere un MQMD nel flusso HTTP).

Nel modulo ESQL per Compute1, includere un'istruzione del genere:

SET OutputRoot.XML.A.MessageID =    
			CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);

Nel modulo ESQL per Compute2, codificare un'istruzione del genere:

SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =     
			CAST(InputRoot.XML.A.MessageID AS BLOB);
Concetti correlati
Servizi Web, flussi di messaggi e WSDL
Richiamo del broker di un servizio Web esistente
Implementazione del broker di un'interfaccia del servizio Web esistente
Implementazione del broker di un'interfaccia di un servizio diverso da Web per un servizio Web nuovo
Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ac34540_