Lavorando con wsdl di grandi dimensioni, possiamo tagliarlo?

Question

Il mio fornitore di servizi web mi offre un file WSDL di grandi dimensioni, ma al suo interno utilizzeremo solo alcune funzioni.

Credo che il WSDL di grandi dimensioni abbia un impatto negativo sulle prestazioni dell'applicazione.

Utilizziamo il servizio web nell'applicazione del client, tempo di avvio e utilizzo della memoria sono problemi. WSDL di grandi dimensioni significa che jax-ws impiegherà più tempo a eseguire l'associazione e richiederà più memoria per la classe stub.

È possibile tagliare il file WSDL in una versione leggera? Esistono strumenti per questo scopo?

Non credo che il mio fornitore di servizi web genererà un altro WSDL per noi. Potrebbe essere necessario farlo automaticamente nello script di compilazione .

Answer 1

In breve, le tue risposte sono " Nessuno strumento, ma puoi DIY " ;.

Vorrei che ci fossero strumenti semplici in grado di farlo perché il mio WSDL contiene troppe funzioni non utilizzate e schema della struttura dei dati.

Se posso automatizzarlo, WSDL - > rifilato WSDL - > generare classi di stub client. Non verrà generato nulla di inutilizzato, nessun uso improprio, nessuna manutenzione richiesta, non toccheremo il codice generato e posso davvero concentrarmi sul codice in uso. JAR più piccolo, tempo di analisi XML più breve. Se il WSDL viene aggiornato, dovrò solo ricostruire le classi di stub client ed eseguire unit test.

Ho cercato di evitare l'invocazione umana. Ci vuole tempo, facilmente per sbagliare, e bisogna rifare ogni volta ogni piccola modifica sul WSDL originale.

Non sono esperto nello schema WSDL. Sto pensando che può essere fatto da XSLT?

Answer 2

Le dimensioni del WSDL non avranno alcun impatto sulle prestazioni ... a meno che non lo si stia scaricando e / o analizzando per ogni richiesta. E se stai facendo quest'ultima, non farlo. Deve essere elaborato solo quando il servizio cambia e il servizio deve sempre cambiare in modo compatibile, con il supporto continuo di vecchi messaggi (almeno per un periodo di tempo sovrapposto).

Dovresti considerare l'elaborazione di un WSDL come un cambio di programma e farlo come faresti con qualsiasi versione, con controllo delle versioni, test, ecc.

Answer 3

Il problema non riguarda le dimensioni del WSDL stesso. È la dimensione del codice generato che conta. Ad esempio, se si utilizza Axis2 per generare il codice da un WSDL di grandi dimensioni, si finirà per creare una classe Request / Response per ogni operazione WSDL, nonché le classi dei relativi tipi restituiti. Successivamente finiresti con un'enorme classe di stub, che potrebbe influire sulle prestazioni poiché importerebbe le classi richieste dalle operazioni del servizio Web che non ti servono.

Non esiste uno strumento semplice per farlo. Di solito uso notepad ++ per farlo, e SÌ potresti sempre fare errori mentre lo fai.

Un altro errore comune è la scelta di generare sia i metodi di stile Sync che Async, quando il più delle volte (nel mio caso almeno), useresti solo i metodi di stile Sync. Ciò potrebbe aumentare notevolmente anche le dimensioni del tuo stub.

Answer 4

Non ho usato gli strumenti di cui stai parlando, ma puoi eseguire correttamente i metodi del servizio web senza che il codice tocchi mai un file WSDL.

Sembra un buon momento per eseguire un test rapido. Taglia tutto dal file WSDL tranne quello che ti serve per eseguire uno dei metodi più semplici che prevedi di usare. Fai invece riferimento a quella copia del WSDL. Se funziona, sai cosa fare dopo!

Answer 5

Non è necessario tagliare il WSDL. Se hai intenzione di seguire questo percorso, elimina semplicemente tutto ciò che non ti serve nelle classi stub. Assicurati di provarlo mentre procedi per assicurarti che tutto funzioni ancora.

Answer 6

Potresti semplicemente rimuovere manualmente < wsdl: operazione > elementi corrispondenti ai metodi non necessari e vedere se è abbastanza. Dovresti essere in grado di rimuovere quegli elementi senza toccare il resto del file.

Answer 7

La dimensione fisica del WSDL non dovrebbe avere importanza se si generano classi di stub client al momento della compilazione (ad es. tramite AXIS wsdl2java.) Se si sta scaricando il WSDL e analizzandolo per ogni richiesta, il download il tempo probabilmente ridurrà il tempo di analisi. Prendi in considerazione la memorizzazione nella cache del file in locale se il tempo di download diventa un problema. Se il tempo di analisi diventa un problema, ti consigliamo di tagliare il file o memorizzare nella cache gli oggetti analizzati. Prestare attenzione durante la memorizzazione nella cache o il taglio del file poiché sarà necessario integrare eventuali modifiche quando il provider emette un nuovo WSDL. Valuta di aggiornare il tuo WSDL memorizzato nella cache / tagliato ogni volta che il servizio viene riavviato o ad un certo intervallo.