Implementazione del broker di un servizio Web nuovo: dettagli

Questa è una panoramica di uno scenario end-to-end tipico dove il broker implementa un servizio Web.

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

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.

Il servizio Web fornisce un'interfaccia basata sulle operazioni già esposte dal sistema esistente. E' possibile che questa interfaccia sia composta da tutte le operazioni esistenti, da alcune serie secondarie e/o da operazioni composite.

Per definire l'interfaccia:
  1. Esaminare le funzioni aziendali fornite dal sistema esistente
  2. Selezionare la serie secondaria di questa funzione aziendale da esporre
  3. Decidere la modalità di rappresentazione nell'interfaccia (numerose operazioni discrete o poche operazioni multifunzione)
Una decisione di base prevede di scegliere se l'interfaccia del servizio Web sarà in stile RPC o documento (fare riferimento a Servizi Web, flussi di messaggi e WSDL e Relazione tra WSDL ed il modello di messaggio).
  • Un'interfaccia in stile RPC è progettata di solito per la mappatura a una serie sottostante di operazioni fornite da alcune API e le operazioni individuali (richiami di metodo) dispongono di payload relativamente ridotto.
  • E' possibile che un'interfaccia in stile documento disponga di un numero ridotto di operazioni, ciascuna con un payload maggiore, ad esempio un documento che rappresenta una richiesta di prestito.
WS-I (consultare http://www.ws-i.org/) consiglia di utilizzare solo WSDL in stile documento, ma molti servizi Web vecchi utilizzano lo stile RPC.

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 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. Creare la definizione WSDL. A meno che non siano già state create le categorie del messaggio richieste, creare una categoria del messaggio per ciascuna operazione dei servizi Web da esporre e associare i messaggi del broker esistenti ai ruoli SOAP appropriati (input, output o fault) (fare riferimento a Gestione di un file di categoria dei messaggi).
    • Se si sceglie il WSDL in stile documento, la serie del messaggio non viene modificata.
    • Se si sceglie il WSDL in stile RPC, i messaggi corrispondenti alla richiesta e alla risposta per ciascuna operazione WSDL vengono creati e aggiunti alla serie di messaggi in modo automatico.
  3. La procedura di creazione del WSDL risulterà nell'inclusione automatica dei file di definizione dei messaggi (mxsd) di SOAP appropriati nella serie di messaggi. Questo comprende in modo specifico il file mxsd di protezione SOAP e (se lo stile WSDL è codificato in RPC) il file mxsd di codifica SOAP.
  4. Se è in corso la creazione di un client di servizi Web nuovi, utilizzare il WSDL creato con la tecnologia del client dei servizi Web scelta. Effettuare tale operazione con uno strumento diverso da WebSphere Message Broker, ad esempio Rational Application Developer o .NET.
  5. 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"
  6. 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/SOAPAction HTTP per determinare il probabile contenuto; tale operazione è possibile solo con HTTP. WS-I non consiglia di utilizzare il campo Azione SOAP.

  7. E' possibile fornire la mappatura dai messaggi di payload consentiti ai messaggi richiesti dal sistema esistente. Ad esempio, è possibile disporre di una definizione di mappatura singola con entrambi i messaggi message1a e message1b mappati alla stessa 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”) ...
     
    Successivamente, conosciuto il contenuto, è 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. 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.

Per uno scenario simile, fare riferimento all'esempio: esempio Host servizio Web.

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
ac34570_