Il modo migliore per simulare il servizio web java

Question

Devo prendere in giro il complicato servizio web java e sto cercando la soluzione giusta. Un modo per farlo sarebbe usare Soap UI, ma ho bisogno di qualcosa che sarebbe in grado di modificare lo stato del server, ad es. una richiesta influenzerebbe le richieste future.

In questo caso particolare, potrebbe essere eseguito rapidamente salvando gli oggetti serializzati sul disco e talvolta generando risposte asincrone al servizio web del client di origine.

Questi due requisiti mi impediscono di utilizzare SoapUI - la logica groovy sarebbe piuttosto complicata e probabilmente difficile da mantenere.

Le mie domande:

1) Ci sono altri vantaggi SoapUI in questo contesto (ad esempio, una facile migrazione alla nuova versione di WSDL) su Java personalizzato finta esecuzione.?

2) Quale sarebbe il modo più appropriato per generare il servizio web da wsdl e anche essere in grado di collegarsi con alcune funzionalità personalizzate, ad es. collegando alcuni ganci che potrebbero essere modificati in file separati (per facilitare ulteriore rigenerazione del codice wsd da wsdl aggiornato)?

Answer 1

Per semplici simulazioni uso soapUI, mentre per i più complicati quando lo stato deve cambiare tra le richieste, utilizzo un semplice emulatore di servizi Web scritto in Python. Tale emulatore utilizza i modelli di risposta creati dal servizio Web reale o le risposte che ho creato in soapUI. In questo modo posso controllare tutta la logica.

L'emulatore per il mio ultimo progetto ha oltre 300 righe di codice Python, ma per precedente, molto più semplice, erano ~ 150 linee di codice Python.

Answer 2

Si consiglia di guardare EasyMock, che consente di creare mock programmaticamente. È possibile specificare comportamenti molto complessi per i tuoi mock.

Answer 3

Presumibilmente stai utilizzando una sorta di stub generato nel tuo client? Dovresti simulare lo stub con una delle API di simulazione (JMock o EasyMock) e iniettare il mock nella classe under test.

Sul lato server verificare la classe che gestisce la chiamata, iniettando mock di qualsiasi oggetto che potrebbe utilizzare per eseguire il proprio lavoro.

Come parte dovresti cercare di mantenere tutte le chiamate in un'unità di test locale (in-process). Permette di controllare facilmente i valori di ritorno da qualsiasi oggetto dipende dal sottotest della classe e quando la suite di test cresce aiuterà a prevenire che i test unitari diventino un ostacolo nel processo di compilazione.

Riguardo alla generazione di una classe Java da WSDL Apache Axis ha qualcosa chiamato WSDL2Java, che genera gli stub client che ho menzionato in precedenza. Questo tipo di utilità è comune nei framework dei servizi Web, ma potrebbe essere stato sostituito da quando i servizi Web EJB3 introdotti sono javax.xml.rpc.ServiceFactory.

Esiste un tutorial sui servizi Web EJB3 e sui client qui (http://www.theregister.co.uk/2007/01/23/ejb_web_services/).