Implementazione del broker di un'interfaccia del servizio Web esistente: dettagli

Questa è una panoramica di uno scenario end-to-end tipico dove si dispone di un client del servizio Web e si desidera che il broker renda disponibile qualche funzionalità di servizi diversi da servizi Web esistente.

Un sistema basato su C o Cobol esistente fornisce regole business da esporre in modo utile come un servizio Web.

Come nel precedente esempio (Implementazione del broker di un servizio Web nuovo: dettagli), esistono dei meccanismi per consentire al broker di richiamare operazioni nel sistema esistente (vale a dire che il sistema espone un'interfaccia al broker). Il sistema esistente è di solito abilitato per WebSphere MQ e questo significa che riceve messaggi MQ in cui sono contenuti i dati dell'applicazione, li distribuisce all'implementazione sottostante e quindi comprime i valori di restituzione come risposta MQ. Le strutture dei dati fornite e restituite dalle operazioni esistenti sono definite in un file di intestazione C o in un copybook Cobol.

In questo esempio esiste tuttavia un vincolo sull'aspetto del servizio Web: si dispone già della definizione WSDL per il client dei servizi Web.

Uno scenario possibile prevede che un client di servizi Web distribuiti in modo diffuso fornisca già accesso a una particolare funzione aziendale e il ruolo del broker sarà di fornire la stessa interfaccia a una nuova implementazione basata sul sistema esistente. E' probabile che il provider dei servizi Web originali fornisca una diversa qualità del servizio o sia discontinuo per alcuni motivi.

Come in precedenza, il broker è in grado di richiamare la funzione del sistema esistente suWebSphere MQ.

Per implementare lo scenario:

  1. Importare le strutture dai dati API esistenti, utilizzando ad esempio il programma di importazione C. Se è necessario utilizzare il WSDL in stile documento, è necessario creare gli elementi globali richiesti nel modello del broker mediante la procedura guidata del programma di importazione. WS-I (consultare http://www.ws-i.org/) consiglia che il payload del servizio Web sia qualificato dallo spazio dei nomi; specificare quindi lo spazio dei nomi di destinazione durante l'importazione.

    A questo punto si dispone del modello di messaggio per i dati da utilizzare per richiamare le operazioni esistenti.

  2. Importare il file WSDL esistente per creare il modello di messaggio appropriato per i documenti di istanza previsti (fare riferimento a Importazione delle strutture dati). Il flusso analizzerà la richiesta SOAP corrispondente e sarà necessaria la trasformazione del formato dati esistente richiesto. E' possibile controllare le definizioni del messaggio importato e utilizzare ESQL e/o gli editor di mappatura per assistenza nella creazione del flusso. Non vengono creati file di categoria o WSDL dal modello di broker.
  3. La procedura di importazione del WSDL risulterà nell'inclusione automatica dei file mxsd di SOAP appropriati nella serie di messaggi. Questo comprende in modo specifico il file mxsd di protezione SOAP e, se richiesto, il file mxsd di codifica SOAP.
  4. Implementare la ricezione della richiesta del servizio Web mediante il flusso di messaggi, vale a dire renderlo provider dei servizi Web. I nodi endpoint sono HTTP o MQ, a seconda del canale di trasmissione utilizzato dal client. Le proprietà del nodo di input sono le seguenti:
    • dominio: "MRM"
    • serie: la serie di messaggi in cui è contenuta la definizione della protezione SOAP
    • tipo: "Envelope"
    • formato: "XML1"
  5. Quando viene richiamato dal flusso, il programma di analisi crea un albero logico che comprende la protezione SOAP come definita dal file mxsd SOAP pre-canned. L'analisi continua in modo automatico nei punti di connessione all'interno della protezione SOAP (intestazione e contenuto SOAP), tentando di essere in corrispondenza con altre definizioni del messaggio nella serie di messaggi. Applicare la convalida al nodo di input se richiesto.

    A questo punto si dispone dell'albero logico, ma non si conosce il payload SOAP ricevuto. Verificare il campo Azione/Azione SOAP HTTP per determinare il probabile contenuto; tale operazione è possibile solo con HTTP. WS-I non consiglia di utilizzare il campo Azione SOAP.

  6. E' possibile fornire una mappatura singola dai messaggi di payload consentiti ai messaggi richiesti dal sistema esistente. Ad esempio, una definizione di mappatura singola è in grado di eseguire la mappatura dei messaggimessage1a e message1b allo stesso messaggio di destinazione message2.
    In alternativa, è possibile fornire mappature separate per ciascun tipo di messaggio o per gruppi di tipi di messaggio correlati. Tale approccio risulta in definizioni di mappatura più gestibili e nuovamente utilizzabili. Lo svantaggio è che per l'utente è necessario determinare il payload ricevuto prima di applicare la mappatura. E' possibile effettuare questa operazione in ESQL, come riportato di seguito:
     
     DECLARE SOAPENV NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
     SET contentType = FIELDNAME(InputBody.SOAPENV:Body.*[<]);
     IF (contentType = ‘foo’) ...
     
    oppure utilizzando un riferimento del campo, ad esempio:
     
     DECLARE R REFERENCE TO InputRoot.MRM.SOAPENV:Body.*[<];
     IF (FIELDNAME(R) = “foo”) ...
     
    Una volta che il contenuto è noto, è possibile diramare il flusso in modo appropriato (ad esempio, utilizzando un nodo RouteToLabel) con ciascuna diramazione con nodi Compute e/o mappature del contenuto. Per flussi semplici è possibile mantenere tutta la logica in un nodo Compute singolo, se richiesto.

    Richiamare ora il sistema esistente (normalmente con WebSphere MQ), recuperare qualsiasi risposta prevista e trasmettere la risposta del servizio Web. Questa operazione è simile allo scenario precedente (Implementazione del broker di un servizio Web nuovo: dettagli), ad eccezione del fatto che è necessario che il flusso di dati esegua la mappatura tra il formato dei dati utilizzato dal client del servizio Web e il formato utilizzato dal sistema esistente abilitato per WebSphere MQ. E' necessario che il designer del flusso di dati tenga presente la possibilità che l'applicazione aziendale non proceda all'invio della risposta prevista in tempi ragionevoli.

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 nuova
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
Attività correlate
Implementazione del broker di un'interfaccia del servizio Web esistente: dettagli
Richiami del broker di un servizio Web esistente: dettagli
Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ac34580_