Pagina 2 di 3
Descrizione con WSDL
SOAP funziona molto bene quando tutto ciò che riguarda il servizio Web è noto. Tuttavia, questo non è sempre il caso. La descrizione dell'interfaccia per l'accesso a un servizio Web è WSDL (Web Services Description Language). Questo standard è stato sviluppato congiuntamente da IBM, Microsoft e webMethods. Ognuna di queste tre società aveva il proprio approccio allo sviluppo di uno standard per la descrizione dei servizi Web: IBM ha creato NASSL, Microsoft ha sviluppato SCL e webMethods ha ideato WIDL.
Il risultato della loro collaborazione è stata la versione 1.1 del linguaggio WSDL Per quanto riguarda il W3C, va notato che, proprio come con SOAP, il consorzio W3C basato sulla versione 1.1 ha sviluppato la versione 1.2 di WSDL, che ora è una raccomandazione del W3C. La descrizione WSDL di un servizio Web contiene tutte le informazioni necessarie per utilizzare il servizio, incluso metodi disponibili e le loro impostazioni. Queste informazioni sono contenute nei seguenti cinque elementi:
- protocolli supportati. - Messaggi del servizio Web (richiesta, risposta). Tutti i metodi disponibili. - L'URI del servizio. - tipi di dati utilizzati.
Tutte queste informazioni sono memorizzate nell'elemento radice della descrizione WSDL.
WSDL Descrizione del servizio Web
Sì... non puoi capirlo senza un bicchiere, ma questo è uno dei file WSDL più semplici (!). Sfortunatamente, una delle carenze dell'estensione SOAP PHP 5 è che, a differenza di altre implementazioni SOAP, non consente di generare descrizioni WSDL automaticamente (almeno non ancora). Molto probabilmente questo problema verrà risolto in una versione futura di PHP.
A proposito!
Per generare automaticamente una descrizione WSDL, puoi utilizzare implementazioni alternative del protocollo SOAP in PHP:
Ricerca nella Directory con UDDI
Ora che sappiamo come ottenere informazioni su un servizio Web e come interrogarlo, dobbiamo imparare a trovare tale servizio. A questo scopo, esiste qualcosa di simile alle "Pagine gialle", ovvero UBR (Universal Business Registers - Universal Business Registers) - directory di servizi Web.
Esistono diversi registri di questo tipo, inclusi quelli di IBM, Microsoft, NTT-Com e SAP. Questi registri sincronizzano i loro dati, quindi puoi usarne uno qualsiasi. La versione corrente dello standard UDDI è UDDI 3.0, sebbene la maggior parte delle implementazioni utilizzi la versione 2. Gli sviluppatori di questo standard includono giganti come HP, Intel, Microsoft e Sun.
Per interagire con UBR c'è due tipi di API: API di richiesta e API di pubblicazione. Interfaccia L'API di richiesta (Richiesta) è per l'esecuzione di query servizi nei registri UBR e l'interfaccia L'API di pubblicazione consente agli sviluppatori di registrare i propri servizi. Sembra che sia solo questione di tempo prima di riempire di spam il contenuto dei registri :)
A proposito!
Esistono registri di test progettati per testare la registrazione dei servizi prima che vengano inseriti in registri "reali".
Ecco come appare la richiesta del servizio Web:
Nell'esempio sopra, puoi vedere che la richiesta UDDI è incapsulata in un messaggio SOAP, quindi sembra abbastanza familiare. La risposta alla richiesta è anche un documento SOAP di seguito riportato:
Installazione
Installare l'estensione SOAP per PHP5 è abbastanza semplice. In Windows, questo modulo si trova nella sottodirectory ext della directory di installazione di PHP. Per usarlo, devi aggiungere la seguente riga al file php.ini: estensione=php_soap.dll Per funzionare è necessario questo modulo, che è incluso in PHP 5 per impostazione predefinita, almeno nella versione Windows.
Come WSDL 1.1 definisce i servizi Web e come creare modelli Java per verificare e trasformare i documenti WSDL
Serie di contenuti:
A proposito di questa serie di articoli
I servizi Web sono una caratteristica importante della tecnologia Java™ nell'informatica aziendale. In questa serie di articoli, Denis Sosnovsky, consulente di servizi Web e XML, parla di framework e tecnologie chiave che sono preziosi per gli sviluppatori Java che utilizzano i servizi Web. Segui gli articoli della serie per rimanere aggiornato sugli ultimi sviluppi del settore e sapere come applicarli ai tuoi progetti.
I servizi Web per le applicazioni aziendali si basano fortemente sull'uso delle definizioni dei servizi. Le definizioni del servizio descrivono l'accordo di base tra un fornitore di servizi e qualsiasi potenziale consumatore, specificando i tipi di funzionalità fornite dal servizio e i messaggi all'interno di ciascuna funzionalità. Produttori e consumatori sono liberi di scegliere come implementare i propri oggetti di scambio, purché i messaggi effettivi che inviano siano conformi alla definizione del servizio. L'uso di una definizione di servizio per descrivere come vengono scambiati i messaggi XML è ciò che distingue i servizi Web dalle precedenti tecnologie di programmazione distribuita.
Sono stati proposti vari metodi per definire i servizi Web, ma WSDL 1.1 rimane l'approccio più utilizzato. WSDL 1.1 presenta alcuni inconvenienti, inclusa una struttura eccessivamente complessa che rende difficile la lettura per chi non lo sapesse. Soffre anche della mancanza di un'autorevole definizione formale, che ha portato a successivi "chiarimenti" che colmano alcune lacune del documento di specifica originale. Di conseguenza, gli stack dei servizi Web tentano di gestire i documenti WSDL 1.1 nel modo più flessibile possibile. Questa flessibilità può aumentare la confusione nella comprensione di WSDL 1.1, poiché gli sviluppatori vedono un'ampia varietà di strutture WSDL senza alcuna indicazione di quale approccio sia preferito.
In questo articolo, ti mostreremo come analizzare i documenti WSDL 1.1 ed esamineremo le prime parti del modello Java per la convalida dei documenti WSDL e la loro conversione in formato standard.
Analisi di WSDL 1.1
Spazi dei nomi utilizzati
Questo articolo utilizza:
- prefisso wsdl per rappresentare lo spazio dei nomi WSDL 1.1 http://schemas.xmlsoap.org/wsdl/ ;
- il prefisso soap per lo spazio dei nomi http://schemas.xmlsoap.org/wsdl/soap/ utilizzato dall'estensione SOAP 1.1 per WSDL 1.1;
- il prefisso xs per lo spazio dei nomi http://www.w3.org/2001/XMLSchema utilizzato per le definizioni dello schema XML.
La revisione 1.1 del WSDL pubblicata all'inizio del 2001 è tecnicamente sostituita dalle raccomandazioni del W3C WSDL 2.0 pubblicate nel 2007. WSDL 2.0 offre una struttura più chiara rispetto a WSDL 1.1, insieme a una maggiore flessibilità. Ma WSDL 2.0 soffre di un problema di gallina e uova: WSDL 2.0 non è ampiamente utilizzato perché non è ampiamente supportato e poiché non è ampiamente utilizzato, gli sviluppatori di stack di servizi Web hanno pochi incentivi a supportarlo. Nonostante tutte le sue carenze, WSDL 1.1 è abbastanza buono per la maggior parte degli scopi.
La specifica WSDL 1.1 originale era imprecisa in termini di numero di funzionalità utilizzate. Poiché l'obiettivo del WSDL era lavorare con le definizioni dei servizi SOAP, includeva anche il supporto per funzionalità SOAP (come la codifica rpc) che in seguito si sono rivelate indesiderabili. La Web Services Interoperability Organization (WS-I) ha affrontato questi problemi nel Core Profile (BP), che fornisce le migliori pratiche per i servizi Web che utilizzano SOAP e WSDL. BP 1.0 è stato approvato nel 2004 e BP 1.1 è stato rilasciato nel 2006. Questo articolo discute WSDL 1.1 in base alle raccomandazioni WS-I BP e non affronta funzionalità deprecate come la codifica rpc per SOAP.
Si presume che la struttura dei documenti XML sia data dalle definizioni dello schema XML. La specifica WSDL 1.1 originale includeva una descrizione dello schema, ma lo schema non corrisponde alle descrizioni testuali sotto diversi aspetti. Ciò è stato successivamente corretto in una versione modificata dello schema, ma il documento WSDL 1.1 non è stato modificato per riflettere questa modifica. Il gruppo BP WS-I ha quindi deciso di apportare ancora più modifiche allo schema WSDL e ha creato quelle che vengono propagandate come le migliori pratiche per questo schema scivoloso. I documenti scritti per una versione di uno schema non sono generalmente compatibili con altre versioni (anche se usano lo stesso spazio dei nomi), ma fortunatamente la maggior parte degli strumenti dei servizi Web ignorano sostanzialmente lo schema e accettano qualsiasi cosa sembri ragionevole. (Vedi i collegamenti a molti schemi WSDL nella sezione).
Anche la versione BP WS-I dello schema WSDL 1.1 non è molto utile per garantire che la specifica del documento WSDL 1.1 sia soddisfatta. Il diagramma non riflette tutte le limitazioni di BP WS-I, soprattutto per quanto riguarda l'ordine dei componenti. Inoltre, XML Schema non è in grado di gestire molti tipi di vincoli facilmente applicabili nei documenti (come attributi alternativi o elementi aggiuntivi richiesti da uno schema separato). Pertanto, la convalida di un documento WSDL 1.1 rispetto alla specifica WSDL 1.1 (come modificata da WS-I BP) implica molto di più della semplice convalida dello schema XML. Torneremo su questo argomento in questo articolo. Ma prima, diamo un'occhiata alla struttura delle descrizioni dei servizi WSDL 1.1.
Descrizione Componenti
I documenti WSDL 1.1 utilizzano un elemento radice fisso con un nome conveniente
C'è anche un elemento
Una descrizione completa di un servizio richiede in genere almeno un elemento di ciascuno di questi tipi, ad eccezione di
I Listati 1 e 1 mostrano un esempio di una definizione di servizio WSDL suddivisa in due documenti WSDL, in modo che i componenti di descrizione dell'interfaccia siano contenuti nel file BookServerInterface.wsdl e i componenti di implementazione siano contenuti nel file BookServerImpl.wsdl. Il Listato 1 mostra BookServerInterface.wsdl.
Listato 1. BookServerInterface.wsdl
Il Listato 2 mostra BookServerImpl.wsdl. Elemento
Listato 2. BookServerImpl.wsdl
Oltre alle definizioni degli elementi (e degli attributi) nello spazio dei nomi WSDL 1.1, WSDL 1.1 definisce anche elementi aggiuntivi. Hanno lo scopo di popolare celle specifiche nelle descrizioni dei servizi WSDL 1.1 per trasmettere informazioni aggiuntive necessarie per un particolare tipo di servizio. Gli unici elementi aggiuntivi WSDL 1.1 ancora ampiamente utilizzati sono i binding per SOAP 1.1 (sono forniti in , negli elementi
Dettagli del componente
Elemento
Perché un elemento
Oltre ad
Figura 1. Relazioni tra i componenti WSDL
Messaggi rappresentati da elementi
Elementi
WSDL 1.1 definisce diversi modelli di interazione tra un client e un fornitore di servizi, rappresentati da diverse sequenze di elementi figlio.
Ogni elemento
In molti aspetti
Confronto di SOAP 1.1 e 1.2
SOAP 1.1 è stato ampiamente utilizzato per i servizi Web da quando la specifica è stata pubblicata nel 2000. SOAP 1.2 è stato sviluppato con un più ampio supporto del settore attraverso il W3C e pubblicato come standard W3C ufficiale nel 2007. SOAP 1.2 è meglio documentato e più pulito di SOAP 1.1, con alcuni degli aspetti brutti di 1.1 rimossi chirurgicamente. Nonostante questa struttura ripulita, ci sono poche differenze pratiche tra i due per la maggior parte dei servizi Web. Probabilmente la caratteristica più significativa di SOAP 1.2 è che è l'unico modo ufficialmente supportato per utilizzare il supporto avanzato per SOAP XML-binary Optimized Packaging (XOP) e SOAP Message Transmission Optimization Mechanism (MTOM) allegati SOAP. In un ciclo Servizi web Java Finora ho utilizzato SOAP 1.1 perché alcuni stack più vecchi non supportano SOAP 1.2, ma per lo sviluppo di nuovi servizi Web, 1.2 è probabilmente la scelta migliore.
Elementi
Elementi figlio
Entrano in gioco le estensioni definite dal WSDL
All'interno di ogni elemento figlio
L'ultimo componente di una descrizione del servizio WSDL è l'elemento
Lavorare con WSDL
Non sorprende che, con tutte le variazioni di schemi e regole per i documenti WSDL 1.1, molti documenti non seguono le migliori pratiche BP WS-I. Il supporto di molte deviazioni dalle migliori pratiche da parte dell'intero stack dei servizi Web ha contribuito a perpetuare l'uso di costrutti obsoleti o non corretti, portando alla diffusione di pratiche scorrette in tutto il settore. E non sono assolutamente immune da questo contagio: guardando i documenti WSDL che ho citato come esempi di codice per questa serie, ho scoperto con mia sorpresa che nessuno di essi è completamente corretto.
Quindi, quando ho deciso di scrivere questo articolo, ho pensato che sarebbe stato bello includere uno strumento in grado di confrontare i documenti WSDL rispetto alle migliori pratiche. Sembrerebbe che da qui sia solo un passaggio per convertire i documenti WSDL nella forma corretta, a condizione che il WSDL originale sia privo di errori. Ma il lavoro si è rivelato molto più di quanto inizialmente previsto e includerò tutte le informazioni su questo modello nei prossimi due articoli di questa serie.
Sono stati creati molti modelli diversi per lavorare con i documenti Java WSDL, incluso il linguaggio di descrizione dei servizi Web ampiamente utilizzato per Java Toolkit (WSDL4J), che è l'implementazione di riferimento di JSR 110 (vedere la sezione ). Nessuno di questi modelli corrisponde a quello che stavo per fare, a causa della duplice affermazione del problema: in primo luogo, leggere documenti WSDL in qualsiasi forma semisensibile e segnalare errori e deviazioni dalle migliori pratiche e, in secondo luogo, scrivere documenti WSDL senza errori riformattati in una forma conforme alle migliori pratiche. WSDL4J, ad esempio, non conserva l'ordine degli elementi di input in modo che i problemi di ordine possano essere segnalati e non elabora le definizioni dello schema, quindi non può essere utilizzato direttamente per controllare i riferimenti dagli elementi.
Modello WSDL
Convalida e verifica
In questo articolo uso il termine verifica fare riferimento alla convalida di un documento WSDL, perché il termine alternativo è convalida, comunemente usato per i documenti XML, significa controllare i documenti rispetto a una definizione di schema.
In precedenza, avevo già implementato parzialmente il modello WSDL per l'utilizzo con il data binding JiBX come parte del progetto JiBX/WS. Questo modello è di solo output e include un numero relativamente piccolo di classi che, in alcuni casi, combinano dati da elementi nidificati di una struttura XML WSDL (
Un'altra opzione consiste nel generare codice dallo schema WS-I BP per WSDL 1.1. Dopo aver visto questo, mi sono reso conto che il semplice utilizzo diretto delle classi generate avrebbe creato confusione, poiché lo schema includeva tipi ridondanti e alcuni costrutti scomodi utilizzati per rappresentare diversi modelli di messaggistica (alcuni dei quali sono stati poi banditi dal BP WS- scrivo) .
Quindi ho finito per compilare le classi a mano, anche se il risultato era più o meno lo stesso come se avessi iniziato con il codice generato dallo schema e ridotto semplicemente duplicazioni e complessità non necessarie. L'associazione dati JiBX supporta più associazioni alle stesse classi, quindi sono stato in grado di creare un'associazione di input per gestire l'intera gamma di opzioni consentite da qualsiasi versione di WSDL 1.1, sebbene la configurazione di un'associazione di output per l'output WSDL fosse solo nella forma ottimale .
Il Listato 3 mostra la parte della classe Definitions corrispondente all'elemento radice
Listato 3. Classe di definizioni (parziale)
public class Definitions estende ElementBase ( /** Enumera gli elementi figlio nell'ordine previsto. */ static enum AddState ( invalid, imports, types, message, portType, binding, service ); /** Elenco di nomi di attributi consentiti. */ public static final StringArray s_allowedAttributes = new StringArray(new String ("name", "targetNamespace" )); /** Convalida il contesto da utilizzare. */ private ValidationContextL'organizzazione di questi elementi figlio in mostra come il modello supporta sia il modulo di input generale che il modulo di output in conformità con Consiglio pratico. Invece di un unico elenco di elementi figlio di tutti i tipi, vengono utilizzati elenchi separati per ogni tipo. Il binding di input JiBX tratta gli elementi figlio come un insieme non ordinato chiamando lo specifico di questo tipo metodo del set di elementi ogni volta che un elemento figlio è fuori posto. Anziché sostituire uno qualsiasi dei valori precedenti, il metodo set aggiunge l'istanza all'elenco tipizzato, come si vede nel metodo set addMessage() utilizzato sugli elementi figlio.
Ulteriori attributi ed elementi sono consentiti in qualsiasi elemento WSDL (generalmente, tutti gli attributi o gli elementi che non utilizzano lo spazio dei nomi WSDL 1.1). Un esempio di tali elementi aggiuntivi sono le configurazioni WS-Policy incorporate nei documenti WSDL degli articoli precedenti. questo ciclo così come i collegamenti alle politiche effettive. Idealmente, questi elementi aggiuntivi dovrebbero precedere qualsiasi elemento figlio dallo spazio dei nomi WSDL 1.1, ed è così che vengono gestiti nell'associazione di output. L'associazione di input gestisce elementi e attributi aggiuntivi con il codice della classe base dalle classi di elementi WSDL non mostrate in e consente agli elementi di seguire in qualsiasi ordine (generando un avviso se seguono un elemento dallo spazio dei nomi WSDL 1.1).
Il modello elabora gli elementi noti utilizzando associazioni separate per ciascuno spazio extra nomi, ognuno dei quali ha il suo proprio set classi. Tratterò la gestione di questi elementi aggiuntivi in modo più dettagliato nel prossimo numero. Servizi Web Java, dove il codice sorgente verrà presentato in modo più dettagliato.
Verifica del modello
Alcune verifiche di base dei dati WSDL vengono eseguite quando gli oggetti non sottoposti a marshalling corrispondenti agli elementi vengono aggiunti alla struttura ad albero del documento WSDL, come mostrato nel codice addMessage() alla fine di . Questo codice utilizza il metodo checkAdd() per controllare l'ordine degli elementi figlio e il metodo addName() per verificare che sia rappresentato un nome valido (il testo corrisponde al tipo di schema NCName e il valore è univoco all'interno del tipo di elemento) e mappa il nome a un oggetto. Ma questo è solo un controllo delle informazioni più basilari per singolo elemento; per controllare altre proprietà di ciascun elemento e le relazioni tra gli elementi, è necessario codice aggiuntivo verifica.
JiBX consente di chiamare gestori di interni personalizzati come parte del processo di marshalling e unmarshalling. Per eseguire la logica di verifica, il modello WSDL utilizza uno di questi gestori aggiuntivi, il metodo post-set. Il metodo post-set viene chiamato dopo che l'oggetto associato è stato annullato, quindi questo accade spesso buon modo eseguire i controlli del tipo di verifica degli oggetti. Nel caso della convalida WSDL, l'approccio più semplice consiste nell'eseguire la verifica di tutti gli oggetti da un singolo metodo post-set sull'elemento radice
Altri componenti aggiuntivi
Questo articolo fornisce un'introduzione di base alla struttura e all'uso di WSDL e un'introduzione al Java Data Model per WSDL, progettato per supportare la verifica dei documenti WSDL e la loro trasformazione in un modulo di best practice.
L'articolo successivo proseguirà questo argomento affrontando i problemi comunemente riscontrati durante la scrittura di attestazioni WS-Policy e WS-SecurityPolicy. Esaminerà inoltre più da vicino il modello WSDL e il processo di verifica, inclusa l'estensione del modello per includere le attestazioni WS-Policy/WS-SecurityPolicy integrate nel WSDL.
In questo articolo parlerò di cos'è un file WSDL, perché ne hai bisogno e come lavorarci.
Mappa degli articoli
Cos'è WSDL
WSDL è un linguaggio di descrizione del servizio Web che ha una struttura XML. Lo scopo principale di un file WSDL è fornire un'interfaccia per l'accesso alle funzioni di servizio restituite dai tipi di dati; percorso al server che elabora le richieste, ecc.
Il percorso del file wsdl è solitamente http://host/services/wsdl/gbdar-v2-2.wsdl
Esistono molti strumenti, librerie, progettati per leggere il file WSDL.
SoapUi
Uno di questi strumenti è soapUi(). Installando una distribuzione progettata per la tua piattaforma, sarai in grado di creare nuovo progetto comando File/Nuovo progetto SoapUi. Nella finestra di dialogo per la creazione di un nuovo progetto, lasciare selezionata la casella di controllo Crea richieste di esempio
Esecuzione di query
Il nuovo progetto genererà automaticamente modelli di richiesta per il servizio descritto nel file wsdl. Sul lato sinistro dell'albero vedrai un elenco di funzioni contenute nel file WSDL. Espanderò la funzione di replica. Al suo interno è presente una richiesta Request1, facendo doppio clic su di essa vedremo una finestra di dialogo con un template di richiesta, al posto dei parametri di default verranno messi dei punti interrogativi. Affinché la funzione venga eseguita correttamente, è necessario compilare tutti i parametri che non sono contrassegnati dal tag Optional, quindi fare clic sul triangolo verde nell'angolo in alto a sinistra della finestra di dialogo.
Se tutti i parametri sono corretti, sulla destra apparirà la risposta del servizio alla richiesta.
SoapUi offre la possibilità di visualizzare i parametri del file WSDL, per questo è necessario fare doppio clic sul nome dell'interfaccia (contrassegnata con un'icona verde nell'albero del file WSDL, ho gdbar-v2-2SOAP). Nella finestra di dialogo puoi trovare:
- Scheda Panoramica - descrizione parametri generali WSDL, elenco delle funzioni e relative azioni del server
- Scheda Endpoint di servizio - percorso del server e altri parametri
- contenuto .wsdl albero di navigazione dei file
- Conformità WS-I - qui puoi creare un report dell'interfaccia WS-I
Generazione di documenti
SoapUi ci consente di generare documentazione per le funzioni WSDL. Per fare ciò, fare clic su fare clic con il tasto destro per interfaccia e chiamare il comando Genera documentazione. Di conseguenza, otteniamo manuale dettagliato in formato html.
Questo è tutto, iscriviti alle nuove voci, lascia commenti, dai suggerimenti per migliorare l'articolo.
Il titolo dell'argomento è davvero una domanda, perché Io stesso non so cosa sia e per la prima volta cercherò di lavorarci nell'ambito di questo articolo. L'unica cosa che posso garantire è che il codice seguente funzionerà, tuttavia, le mie frasi saranno solo supposizioni e ipotesi su come io stesso comprendo tutto questo. Quindi andiamo...
introduzione
Dobbiamo partire da ciò per cui è stato creato il concetto di servizi web. Quando è apparso questo concetto, esistevano già tecnologie nel mondo che consentivano alle applicazioni di interagire a distanza, dove un programma poteva chiamare un metodo in un altro programma, che poteva quindi essere lanciato su un computer situato in un'altra città o addirittura in un altro paese. Tutto questo è abbreviato in RPC (Remote Procedure Calling - chiamata di procedura remota). Gli esempi includono le tecnologie CORBA e per Java - RMI (Remote Method Invoking - remote method invocation). E tutto sembra andare bene in loro, soprattutto in CORBA, perché puoi lavorarci con qualsiasi linguaggio di programmazione, ma mancava ancora qualcosa. Credo che lo svantaggio di CORBA sia che funziona attraverso alcuni dei suoi protocolli di rete invece del semplice HTTP, che passerà attraverso qualsiasi firewall. L'idea di un servizio Web era quella di creare un tale RPC da inserire nei pacchetti HTTP. Iniziò così lo sviluppo della norma. Quali sono i concetti base di questa norma:- SAPONE. Prima di chiamare procedura a distanza, è necessario descrivere questa chiamata in File XML e formato SOAP. SOAP è solo uno dei tanti markup XML utilizzati nei servizi web. Tutto ciò che vogliamo inviare da qualche parte tramite HTTP viene prima trasformato in una descrizione SOAP XML, quindi inserito in un pacchetto HTTP e inviato a un altro computer della rete tramite TCP/IP.
- WSDL. Esiste un servizio web, ad es. un programma i cui metodi possono essere chiamati in remoto. Ma lo standard richiede che a questo programma sia allegata una descrizione, che dice che "sì, non ti sei sbagliato - questo è davvero un servizio web e puoi chiamare tali metodi da esso". Questa descrizione è rappresentata da un altro file XML che ha un formato diverso, ovvero WSDL. Quelli. WSDL è solo un file XML che descrive un servizio Web e nient'altro.
Approccio generale
I servizi Web hanno sempre un client e un server. Il server è il nostro servizio Web ed è talvolta indicato come l'endpoint (ad esempio, punto finale, dove raggiungono i messaggi SOAP dal client). Dobbiamo fare quanto segue:- Descrivi l'interfaccia del nostro servizio web
- Implementa questa interfaccia
- Avvia il nostro servizio web
- Scrivere un client e chiamare in remoto il metodo del servizio Web desiderato
server
Avvia IDEA e crea un nuovo progetto Crea nuovo progetto. Specifica un nome ciaoservizioweb e premere il pulsante Prossimo, quindi il pulsante Fine. Nella cartella src creare un pacchetto it.javarush.ws. In questo pacchetto creeremo l'interfaccia HelloWebService: pacchetto ru. javarush. ws; // queste sono annotazioni, ad es. un modo per contrassegnare le nostre classi e metodi, // in relazione alla tecnologia dei servizi web importa javax. jw. WebMetodo; importa javax. jw. servizio web; importa javax. jw. sapone. Rilegatura del sapone; // diciamo che la nostra interfaccia funzionerà come un servizio web@Servizio web // diciamo che il servizio Web verrà utilizzato per chiamare i metodi@SOAPBinding(style = SOAPBinding.Style.RPC) interfaccia pubblica HelloWebService( // diciamo che questo metodo può essere chiamato in remoto@WebMethod public String getHelloString(Nome stringa) ; ) In questo codice, le classi WebService e WebMethod sono le cosiddette annotazioni e non fanno altro che contrassegnare la nostra interfaccia e il suo metodo come un servizio web. Lo stesso vale per la classe SOAPBinding. L'unica differenza è che SOAPBinding è un'annotazione con parametri. In questo caso, il parametro style viene utilizzato con un valore che dice che il servizio web funzionerà non tramite messaggi di documento, ma come un classico RPC, ad es. per chiamare il metodo. Implementiamo la nostra logica di interfaccia e creiamo una classe HelloWebServiceImpl nel nostro pacchetto. A proposito, noto che la classe che termina con Impl è una convenzione in Java, secondo la quale l'implementazione delle interfacce è così designata (Impl - dalla parola implementazione, cioè implementazione). Questo non è un requisito e sei libero di nominare la classe come vuoi, ma le buone maniere lo richiedono: pacchetto ru. javarush. ws; // stessa annotazione della descrizione dell'interfaccia, importa javax. jw. servizio web; // ma qui viene utilizzato con il parametro endpointInterface, // indicando il nome completo della classe di interfaccia del nostro servizio web@WebService(endpointInterface= "it.javarush.ws.HelloWebService") la classe pubblica HelloWebServiceImpl implementa HelloWebService ( @Override public String getHelloString (nome stringa) ( // ricambia solo il saluto restituisce "Ciao, " + nome + "!" ; ) ) Eseguiamo il nostro servizio web come server autonomo, ad es. senza la partecipazione di alcun Tomcat e dei server delle applicazioni (questo è un argomento per una discussione separata). Per fare ciò, nella struttura del progetto nella cartella src creiamo un pacchetto ru.javarush.endpoint e in esso creeremo una classe HelloWebServicePublisher con il metodo main: package ru. javarush. punto finale; // classe per avviare un server web con servizi web importa javax. xml. v. punto finale; // classe del nostro servizio web importare it. javarush. v. ciaowebserviceimpl; public class HelloWebServicePublisher( public static void main(String. . . args)( // avvia il server web sulla porta 1986 // e all'indirizzo specificato nel primo argomento, // avvia il servizio Web passato nel secondo argomento punto finale. pubblicare( "http://localhost:1986/wss/hello", nuovo HelloWebServiceImpl() ); ) ) Ora esegui questa classe facendo clic Maiusc+F10. Non apparirà nulla nella console, ma il server è in esecuzione. Puoi verificarlo digitando http://localhost:1986/wss/hello?wsdl nel tuo browser. La pagina aperta, da un lato, dimostra che abbiamo un server web (http://) in esecuzione sulla porta 1986 sul nostro computer (localhost) e, dall'altro, mostra la descrizione WSDL del nostro servizio web. Se interrompi l'applicazione, la descrizione diventerà inaccessibile, così come il servizio web stesso, quindi non lo faremo, ma passeremo alla scrittura del client.Cliente
Nella cartella del progetto src creiamo un pacchetto ru.javarush.client e in esso la classe HelloWebServiceClient con il metodo main: package ru. javarush. cliente; // necessario per ottenere la descrizione di wsdl e attraverso di essa // raggiungere il servizio web stesso importa java. rete. URL; // tale eccezione si verificherà quando si lavora con l'oggetto URL importa java. rete. MalformedURLException; // Classi per analizzare xml con descrizione wsdl // e raggiungi il tag di servizio al suo interno importa javax. xml. spazio dei nomi. Qnome; importa javax. xml. v. servizio; // interfaccia del nostro servizio web (ci serve altro) importare it. javarush. v. servizio web ciao; public class HelloWebServiceClient( public static void main(String args) genera MalformedURLException( // crea un collegamento alla descrizione di wsdl url= nuovo URL( "http://localhost:1986/wss/hello?wsdl") ; // Esaminiamo i parametri del prossimo costruttore nel primissimo tag di descrizione WSDL - definizioni // guarda il primo argomento nell'attributo targetNamespace // 2° argomento guarda dentro attributo nome QName qname = nuovo QName ("http://ws.javarush.ru/" , "HelloWebServiceImplService" ); // Ora possiamo raggiungere il tag di servizio in descrizione wsdl, Servizio di servizio= servizio. creare (url, qname) ; // e quindi al tag port nidificato in esso, in modo che // ottiene un riferimento a un oggetto del servizio Web remoto da noi HelloWebService ciao = servizio. getPort(HelloWebService.class) ; // Evviva! Ora puoi chiamare metodo remoto Sistema. fuori. println(ciao. getHelloString("JavaRush" ) ) ; ) ) Ho fornito un massimo di commenti sul codice nell'elenco. Non ho nulla da aggiungere, quindi corri (Shift + F10). Dovremmo vedere il testo nella console: Hello, JavaRush! Se non l'hai visto, probabilmente hai dimenticato di avviare il servizio web.Conclusione
Questo thread presentato breve digressione ai servizi web. Ancora una volta, gran parte di ciò che ho scritto è una mia ipotesi su come funziona, e quindi non dovrei fidarmi troppo. Vi sarei grato se persone esperte Verrò corretto, perché allora imparerò qualcosa. UPD.Linguaggio di descrizione dei servizi Web (WSDL)
Negli ultimi esempi, potresti aver visto singoli pezzi di codice WSDL. Ricordiamo che WSDL è una grammatica basata su XML progettata per descrivere come i client esterni possono interagire con i metodi Web disponibili indirizzo dato URL all'interno di ciascuno dei protocolli di comunicazione supportati. In molti modi, un documento WSDL può essere considerato come un "contratto" tra un client del servizio Web e il servizio Web stesso. Questo è un altro metalinguaggio. In particolare, WSDL è usato per descrivere le seguenti caratteristiche qualunque metodo web disponibile:
Il nome del metodo Web XML;
Numero, tipo e ordine dei parametri (se presenti);
Tipo di reso (se presente);
Condizioni di chiamata HTTP GET, HTTP POST e SOAP.
Nella maggior parte dei casi, i documenti WSDL vengono generati automaticamente dal server Web corrispondente. Ricordalo quando aggiungi il suffisso ?wsdl a URL puntando a un file *.asmx, il server Web genera un documento WSDL per il servizio Web XML specificato.
http://localhost/SomeWS/theWS.asmx?wsdl
Ma se IIS genera automaticamente un documento WSDL per un determinato servizio Web XML, perché è necessario avere una conoscenza approfondita della sintassi dei dati WSDL generati? La risposta di solito dipende da come verrà utilizzato il servizio. applicazioni esterne. Per i servizi Web XML destinati all'uso "interno", generalmente è sufficiente il WSDL generato dal server Web.
Nel frattempo. È del tutto possibile iniziare a sviluppare un servizio Web XML creando manualmente un documento WSDL (come discusso in precedenza). L'idea principale alla base dell'avvio dello sviluppo con la creazione di un documento WSDL è legata ai problemi di compatibilità. Ricordiamo che prima dell'avvento della specifica WSI, non era raro che diversi strumenti di creazione di servizi Web generassero WSDL incompatibili. Se inizi lo sviluppo con il codice WSDL, puoi creare il documento nel modo desiderato.
Come puoi immaginare, iniziare a sviluppare un servizio Web XML creando un documento WSDL richiede un'ottima conoscenza della grammatica WSDL, che va oltre lo scopo di questo capitolo. Ma considereremo Struttura basilare documento WSDL. Dopo aver compreso le basi, è possibile valutare i vantaggi dell'utilità riga di comando wsdl.exe.
Commento. Le ultime informazioni su WSDL può essere trovato su http://www.w3.org/tr/wsdl.
Definizione di un documento WSDL
Il documento WSDL effettivo viene aperto e chiuso dall'elemento radice ‹definizioni›. Il descrittore di apertura di solito definisce vari attributi xmlns. Definiscono gli spazi dei nomi XML che definiscono i vari sottoelementi. Come minimo, l'elemento ‹definizioni› deve specificare lo spazio dei nomi in cui sono definiti gli elementi WSDL stessi (http://schemas.xmlsoap.org/wsdl). Per essere utile, il tag di apertura ‹definizioni› deve specificare anche gli spazi dei nomi XML che definiscono i tipi di dati semplici WSDL, i tipi di schema XML, gli elementi SOAP e lo spazio dei nomi di destinazione. Ad esempio, ecco come appare la sezione ‹definizioni› per il nostro servizio web calcolatrice.
‹wsdl:definizioni xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:soapinc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns-mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tns="http://www.IntertechTraining.com/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:http="http://schemes.xmlsoap.org/wsdl/http/"
targetNamespace="http://www.IntertechTraining.com/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"›
‹/wsdl:definizioni›
Nel contesto dell'elemento radice, puoi trovare cinque elementi figlio. Forma generale Il documento WSDL dovrebbe assomigliare a questo.
‹?versione xml="1.0" codifica="utf-8"?›
‹wsdl:definizioni …›
‹wsdl:tipi›
‹!-- Elenco dei tipi disponibili per questo servizio Web --›
‹wsdl:/tipi›
‹wsdl:messaggio›
‹!-- Formato messaggio --›
‹wsdl:/messaggio›
‹wsdl:portType›
‹!-- Informazioni sul porto --›
‹wsdl:/portType›
‹wsdl:rilegatura›
‹!-- Informazioni vincolanti --›
‹wsdl:/binding›
‹wsdl:servizio›
‹!-– Informazioni sul servizio Web XML stesso --›
‹wsdl:/servizio›
‹wsdl:/definizioni›
Come ci si aspetterebbe, ciascuno di questi sottoelementi conterrà elementi e attributi aggiuntivi che perfezionano la descrizione delle capacità disponibili. Diamo un'occhiata al più importante dei nodi validi a turno.
L'elemento ‹tipi›
Per prima cosa esamineremo l'elemento ‹tipi›, che contiene le descrizioni di tutti i tipi di dati offerti dal servizio Web. Potresti saperlo linguaggio XML esso stesso definisce un certo numero di tipi di dati "di base", tutti definiti all'interno dello spazio dei nomi XML http://www.w3.org/2001/XMLSchema (che deve essere specificato nel contesto dell'elemento radice ‹definizioni›). Prendi, ad esempio, il metodo Subtract() del nostro servizio Web calcolatrice, che ha due parametri di input di tipo intero. In termini WSDL, il tipo di Common Language Runtime System.Int32 è descritto nel contesto di un elemento ‹complexType›.
‹s:nome elemento= "Sottrai"›
‹s:sequenza›
‹s:elemento minOccurs=" 1 "maxOccurs=" 1 "nome=" X"tipo=" s:int" /›
‹s:element minOccurs="" 1 "maxOccurs=" 1 "nome=" y"tipo=" s:int" /›
‹/s:sequenza›
‹/s:tipo complesso›
‹/i:elemento›
L'intero restituito dal metodo Subtract() è anche descritto all'interno dell'elemento ‹types›.
‹s:nome elemento=" Sottrai risposta"›
‹s:complessType›
‹s:sequenza›
‹s:elemento minOccurs=" 1 "maxOccurs=" 1 "nome=" Sottrairisultato"tipo=" s:int"/›
‹/s:sequenza›
‹ /s:tipo complesso›
‹/i:elemento›
Se si dispone di un metodo Web che restituisce o riceve tipi personalizzati dati, appariranno anche nel contesto dell'elemento ‹complessType›. Vedremo i dettagli su come esporre tipi di dati .NET personalizzati usando il metodo Web in seguito. Ad esempio, supponiamo di aver definito un metodo Web che restituisce una struttura denominata Point.
public structPoint(
stringa pubblica pointName;
La descrizione WSDL per questa "struttura complessa" assomiglierebbe a questa.
‹s:complessType name=" punto"›
‹s:sequenza›
‹s:elemento minOccurs=" 1 "maxOccurs=" 1 "nome=" X"tipo=" s:int" /›
‹s:elemento minOccurs=" 1 ""maxOccurs=" 1 "nome=" y"tipo=" s:int" /›
‹s:elemento minOccurs=" 0 "maxOccurs=" 1 "nome=" nomepunto"tipo=" s:stringa" /›
‹/s:sequenza›
‹/s:tipo complesso›
L'elemento ‹messaggio›
L'elemento ‹messaggio› viene utilizzato per definire il formato per lo scambio di richieste e risposte per questo metodo Web. Poiché un unico servizio Web consente il passaggio di più messaggi tra mittente e destinatario, un singolo documento WSDL può definire più elementi ‹messaggio›. In genere, queste definizioni utilizzano i tipi specificati all'interno dell'elemento ‹tipi›.
Indipendentemente dal numero di elementi ‹messaggio› definiti in un documento WSDL, di solito sono "presenti" in coppia. La prima definizione rappresenta il formato di input del messaggio e la seconda definizione rappresenta il formato di output dello stesso messaggio. Ad esempio, viene definito il metodo Subtract() del servizio Web CalculatorWebService i seguenti elementi
‹wsdl:nome messaggio=" SottraiSoapIn"›
‹wsdl:part name="parameters" element="tns:Subtract" /›
‹/wsdl:messaggio›
‹wsdl: nome messaggio=" SottraiSoapOut"›
‹wsdl:part name="parameters" element="tns:SubtractResponse" /›
‹/wsdl:messaggio›
Qui vedi solo la comunicazione SOAP del servizio corrispondente. Come discusso all'inizio di questo capitolo, i servizi Web XML possono essere invocati utilizzando SOAP o i metodi HTTP GET e POST. Ma se abiliti la comunicazione HTTP POST (le spiegazioni appropriate verranno fornite in seguito), il WSDL generato dovrebbe mostrare i seguenti dati di ‹messaggio›.
‹wsdl: nome messaggio=" SottraiHttpPostIn"›
‹nome parte="n1" type="s:string" /›
‹nome parte="n2" type="s:string" /›
‹wsdl:/messaggio›
‹wsdl:nome messaggio=" SubtractHttpPostOut"›
‹nome parte="Body" element="s0:int" /›
‹wsdl:/messaggio›
Gli elementi ‹messaggio› da soli non sono molto utili. Tuttavia, queste definizioni di messaggio sono referenziate in altre parti del documento WSDL.
Commento. Non tutti i metodi Web richiedono sia una richiesta che una risposta. Se il metodo Web è "unidirezionale", necessita solo dell'elemento ‹messaggio› della richiesta. È possibile contrassegnare un metodo Web come unidirezionale utilizzando .
L'elemento ‹portType›
L'elemento ‹portType› definisce le varie relazioni che possono verificarsi tra il client e il server, e ciascuna di queste relazioni è rappresentata da un elemento ‹operazione› annidato. È facile intuire che le operazioni più tipiche qui dovrebbero essere SOAP, HTTP GET e HTTP POST. Tuttavia, ci sono anche altre operazioni. Ad esempio, un'operazione unidirezionale consente al client di inviare un messaggio questo server web, ma non riceve una risposta (è come chiamare un metodo senza attendere un valore restituito). L'operazione richiesta-risposta consente al server di inviare una richiesta mentre il client sta rispondendo (che può essere considerata un'aggiunta all'operazione richiesta-risposta).
Per illustrare il formato dell'elemento ‹operazione› annidato facoltativo, considera la definizione WSDL per il metodo Subtract().
‹wsdl portType nome= "CalculatorWebServiceSoap"›
‹wsdl:nome operazione=" Sottrarre"›
‹wsdl:input messaggio=" tns:SottraiSoapIn" /›
‹wsdl: messaggio di output=" tns:SottraiSoapOut" /›
‹ /wsdl:operazione›
‹wsdl:/portType›
Notare come gli elementi ‹input› e ‹output› si riferiscono al nome del messaggio corrispondente definito all'interno dell'elemento ‹messaggio›. Se il metodo HTTP POST fosse abilitato per il metodo Subtract(), vedresti il seguente elemento aggiuntivo ‹operazione›.
‹wsdl:portType name="CalculatorWebServiceHttpPost"›
‹wsdl:input messaggio=" s0:SottraiHttpPostIn" /› ‹wsdl: messaggio di output=" s0:SubtractHttpPostOut" /› ‹wsdl:/operazione› ‹wsdl:/portType› Infine, si noti che se questo metodo Web è descritto con la proprietà Description, l'elemento ‹operazione› conterrà un elemento ‹documentazione› annidato. L'elemento ‹vincolante› Questo elemento specifica il formato esatto dello scambio GET, POST e SOAP. Questo è il più "prolisso" di tutti gli elementi contenuti nel contesto dell'elemento radice ‹definizione›. Ad esempio, ecco la definizione dell'elemento ‹binding›, che descrive come il chiamante può interagire con il metodo Web MyMethod(). usando il SAPONE. ‹wsdl:binding name="CalculatorWebServiceSoap12" type=" tns:CalculatorWebServiceSoap"› ‹soap12:trasporto vincolante=" http://schemas.xmlsoap.org/soap/http" /›
‹wsdl:nome operazione=" Sottrarre"› ‹soap12:operazione soapAction=" http://www.IntertechTraining.com/Subtract"stile="documento" /› ‹wsdl:input› ‹sapone12:uso del corpo=" letterale" /› ‹/wsdl:input› ‹wsdl:output› ‹sapone12:uso del corpo=" letterale" /› ‹/wsdl:output› ‹/wsdl:operazione› ‹/wsdl:rilegatura› L'elemento ‹servizio› Infine, abbiamo l'elemento ‹servizio›, che specifica le caratteristiche del servizio Web stesso (come il suo URL). Lo scopo principale di questo elemento è descrivere l'insieme di porte aperte da questo server Web. L'elemento ‹services› può utilizzare un numero qualsiasi di elementi ‹port› nidificati per fare ciò (non confonderli con l'elemento ‹portType›). Ecco come appare l'elemento ‹servizio› per CalculatorWebService. ‹wsdl:nome servizio= "Calculator WebService"› ‹wsdl:documentazione xmlns:wsdl ="http://schemas.xmlsoap.org/wsdl/"› Meraviglioso servizio Web di calcolatrice ‹/wsdl:documentazione› ‹wsdl:nomeporta= "CalculatorWebServiceSoap" vincolante= "tn:CalcolatriceWebServiceSoap"› ‹soap:indirizzo location= "http://localhost:1109/CalculatorWebService/Service.asmx"/› ‹/wsdl:porta› ‹wsdl:porta name="CalculatorWebServiceSoap12" vincolante=" tn:CalcolatriceWebServiceSoap12"› ‹soap12:indirizzo posizione= "http://localhost:1109/CalculatorWebService/Service.asmx"/› ‹/wsdl:porta› ‹/wsdl:servizio› Quindi, come puoi vedere, il codice WSDL restituito automaticamente dal server ITS non è molto complesso, ma poiché WSDL è una grammatica basata su XML, questo codice è piuttosto dettagliato. Tuttavia, ora dovresti avere una migliore comprensione del ruolo del WSDL, quindi diamo un'occhiata più da vicino ai protocolli di comunicazione dei servizi Web XML. Commento. Ricorda che lo spazio dei nomi System.Web.Services.Description contiene molti tipi che ti consentono di leggere e manipolare a livello di codice il codice WSDL non elaborato (puoi verificarlo tu stesso se sei interessato).
