Qual è il modo migliore per eseguire la versione di un servizio Web ASP.NET 2.0?

Question

Sto mantenendo un servizio Web SOAP (ASP.NET versione 2.0) e devo apportare alcune modifiche che modificheranno i valori di ritorno di particolari metodi.

Qual è il metodo generalmente accettato per fare ciò senza rompere le implementazioni esistenti.

I miei pensieri iniziali sono che quanto segue sarebbe tutto possibile.

a) Fornire nuovi metodi specifici della versione all'interno del servizio Web esistente, ad es. getPerson_v1.4
b) Fornire una copia completa del file .asmx con un nuovo numero di versione, ad es. http: /www.example.com/AdminWS_V1_4.asmx. Questa non è un'idea che apprezzo perché il servizio ha più di 50 metodi e copiare quel codice per le modifiche ai metodi 2/3 sembra un codice troppo duplicato.
c) Sostituire il costruttore del servizio Web per consentire il passaggio di un numero di versione. Questo non sembra funzionare, e sulla riflessione non sono sicuro di come sarebbe rappresentato all'interno di un WSDL

C'è un modo generalmente accettato di farlo, o le persone hanno consigli basati sulle loro esperienze in questo settore.

Answer 1

Nel caso generale, c'è di più nella versione di un servizio Web rispetto ai soli nomi dei metodi di versioning e nomi di file .asmx. Idealmente, l'interfaccia per un servizio Web (il suo WSDL) dovrebbe essere un contratto permanente e non dovrebbe mai cambiare. Una delle implicazioni sarebbe che i client che non hanno bisogno della funzionalità modificata non avrebbero mai bisogno di cambiare, e quindi non avrebbero mai bisogno di essere ritestati.

Invece di rompere il contratto esistente, è necessario creare un nuovo contratto che contenga le operazioni modificate. Tale contratto potrebbe "ereditare" dal contratto esistente, cioè "potresti aggiungere i metodi alla fine". Si noti, tuttavia, che si dovrebbe anche inserire il nuovo contratto in un nuovo spazio dei nomi XML: lo spazio dei nomi identifica fondamentalmente il WSDL e lo spazio dei nomi, ma la modifica del WSDL sarebbe una bugia.

È quindi necessario implementare questo nuovo contratto in un nuovo endpoint (file .asmx). Indipendentemente dal fatto che si trovi o meno in una directory diversa o anche su un sito Web diverso, ciò non importa. Ciò che conta è che i clienti che desiderano la nuova funzionalità possano fare riferimento al nuovo WSDL al nuovo URL e chiamare il nuovo servizio al suo nuovo URL, e sii felice.

Si noti che un effetto della modifica di un contratto esistente è che la volta successiva che viene eseguito un "Riferimento Web di aggiornamento", si sarà modificando il codice del codice delle classi del proxy client. Nella maggior parte dei negozi, la modifica del codice richiede un nuovo test e la ridistribuzione. Dovresti quindi pensare a "aggiungere metodi" come "solo aggiungendo del codice client che deve essere testato e distribuito", anche se il codice client esistente non utilizza i nuovi metodi.

Answer 2

abbiamo distribuire alle directory di versione, ad esempio:

http://www.example.com/soap/v1/ http://www.example.com/soap/v2/ http://www.example.com/soap/v3/

ecc

Answer 3

A meno che non si cambia la maggior parte delle firme dei metodi con ogni nuova versione, mi piacerebbe andare con (a) - nomi dei metodi con versione. Questo è il modo in cui i nostri fornitori lo fanno e sta funzionando bene per noi.

Answer 4

Ho appena pensato a un'altra possibile soluzione che sembra abbastanza pulita.

È possibile verificare la presenza di un numero di versione incluso come intestazione SOAP e assumere il numero di versione esistente se questo non è fornito.

Posso quindi fare in modo che il codice si comporti in modo diverso per versioni diverse senza modificare le firme del metodo. Ciò è possibile in quanto i valori di ritorno dei servizi Web sono oggetti XML, quindi la firma del metodo rimane la stessa, ma il contenuto delle modifiche XML si basa sulla versione.

Answer 5

Ho lo stesso problema di versione con i servizi Web che sto sviluppando. Facciamo in modo che i nostri utenti passino un numero di versione dello schema nell'intestazione. Ci dicono quale versione dello schema XML vogliono. In questo modo, siamo sempre retrocompatibili e il codice non è duplicato.

Al mio lavoro, non possiamo dire al cliente che devono passare l'URL al webservice quando lo facciamo. Nelle grandi aziende, le modifiche piccole come un URL potrebbero richiedere mesi di test. Ho la sensazione che non dovresti interrompere la connessione con i tuoi clienti. Quello che facciamo è aggiungere nuove funzionalità alla versione più recente. Quando il client richiede le nuove funzionalità, se le desiderano, sono costrette ad eseguire l'aggiornamento allo schema più recente.