WSDL generazione generazione ripetibile

Question

Mi è stato chiesto di esaminare il processo di compilazione di un'applicazione basata su un servizio esistente. Ha diversi moduli basati sui servizi in cui alcuni servizi sono forniti da una terza parte. I wsdls usati nel processo di compilazione vengono portati giù e nella build tramite http. Per competenza, sto usando maven 3 e axistools-maven-plugin per generare le classi da wsdl.

Questo mi ha fatto pensare. Se il server remoto non funziona, la mia build fallirà. Se anche la wsdl cambia la mia build potrebbe fallire. Voglio questo? I wsdl remoti sono versionati nel nome servizio/wsdl, quindi non dovrebbero essere apportate modifiche importanti alle API, ma sono di terze parti e non posso davvero fare affidamento su questa convenzione.

Non sarebbe meglio scaricare il wsdl localmente e costruire contro un file che si trova sotto il controllo del codice sorgente? Avrei una build ripetibile corretta quindi senza il pericolo che il server remoto non sia disponibile. Questo però non sembra molto agile. Se adotto questo approccio, come faccio a rendermi conto di eventuali cambiamenti nel wsdl remoto?

Sono sicuro di non essere la prima persona a chiedermi le migliori pratiche sulla costruzione di wsdls. Qualcuno può evidenziare quale meccanismo è considerato il metodo migliore per produrre una build ripetibile dai servizi generati da wsdls remoti?

Answer 1

Se si desiderano build veloci e affidabili, la regola d'oro non è affidarsi a nulla che non controlli!

Nel tuo caso memorizzerò il WSDL localmente nella cache in modo che la compilazione non fallisca se la fonte originale non è disponibile o cambia. Tuttavia, se si è preoccupati che il WSDL possa cambiare, creerei anche un processo di compilazione separato che viene eseguito ogni giorno e confronta la copia memorizzata nella cache con l'originale, in caso contrario se sono diversi. Questo ti dà il meglio di entrambi i mondi ... build ripetibili e preallarme se il WSDL cambia.

Dove/come si memorizza nella cache il WSDL dipende interamente da voi, ma limitarlo nel controllo della versione è un'opzione semplice e veloce.

Answer 2

Vorrei scaricare i file WSDL e inserirli nel controllo del codice sorgente con il resto del progetto.

Il vantaggio principale è che garantisce una build ripetibile. Se li scarichi su ogni build non è ripetibile. Ad esempio, diciamo che tu costruisci e distribuisci in un ambiente di sviluppo o di test, fai firmare l'applicazione, quindi crea e distribuisci in live. Se il WSDL è cambiato, la tua build live è diversa da quella che è stata firmata nel test e potrebbe funzionare diversamente. Se hai problemi con le comunicazioni di rete, potresti non essere nemmeno in grado di costruire affatto.

Significa che non si otterrà automaticamente l'ultima versione del WSDL, ma questa è una buona cosa.

Answer 3

Se si sa che il servizio web ha un wsdl fisso, meglio usare una copia locale di esso.

Se è probabile che lo stesso wsdl cambi, utilizzare l'url sempre per la build.

Se la rete in discesa è un problema, creare due profili di build separati (in Maven), uno per il locale e un altro per l'url.