Retrocompatibilità e Web Services

Question

Quindi sono un po 'nuova a servizi Web e una situazione di recente è venuto da dove abbiamo aggiunto un elemento a un tipo di dati che viene restituito al client. I clienti si sono lamentati che questo ha rotto la loro attuazione, perché soffocato sul nuovo elemento che non si aspettava. (Stiamo fornendo i servizi via Axis2).

A me questo sembra un cambiamento innocuo che il cliente dovrebbe essere in grado di gestire correttamente (ho lavorato con alcuni quadri non web-service, in cui l'aggiunta di informazioni facoltative era completamente accettabile). Potrei capire se abbiamo eliminato o rinominato alcuni campi che che potrebbe causare problemi per il cliente.

In sostanza mi aspetterei che il WSDL per agire come un'interfaccia. Se facciamo un cambiamento che sottotipi in sostanza, che l'interfaccia, mi sarei aspettato il client di ignorare allegramente elementi estranei. E 'solo una breve venuta di servizi web, o c'è un modo sano di fare modifiche passivi ai servizi in modo che i nuovi clienti possono ottenere i dati aggiuntivi, mentre i vecchi clienti possono aggiornare a loro piacimento?

Answer 1

WSDL in realtà agisce come un contratto di più di un'interfaccia. Il WSDL descrive esattamente ciò che l'operazione si aspetta di "ricevere" e che cosa si aspetta di "ritorno". L'analogia più vicino a questo sarebbe in C cambiare il prototipo per una funzione senza modificare la funzione stessa, si suole partita e che provoca problemi.

Il modo più preciso il WSDL è il comportamento più che si sta "garantire" per essere a posto.

Se avete bisogno di flessibilità nei dati restituiti (vale a dire l'aggiunta / rimozione di campi ecc) è possibile eseguire una delle seguenti operazioni:

1. Versione le definizioni di WSDL e pubblicare servizi in grado di reindirizzare le versioni precedenti a versioni più recenti
2. Utilizzare i tipi di ritorno dei dati più astratti, come ad esempio XML per nascondere i dati di complessità o la modifica.

2 ha un po 'di rischio, ma può essere gestito con XSD o altre tecnologie. I suoi particolari esigenze del progetto saranno dettare ciò che è accettabile.

Answer 2

In passato, quando si tratta di API WebService a vista, sono sempre andato con la filosofia della data-versioni. Purtroppo, si ha a che fare con la compatibilità per qualsiasi API rilasciate al pubblico una volta che sei fuori dalla modalità "beta" (e talvolta anche allora).

Quello che abbiamo fatto è stato davvero semplice; il giorno della nuova API è stato rilasciato, ci piacerebbe creare una struttura di cartelle in questo modo:

http://mydomain.com/path/to/service/2009/12/17/servicename.svc

In questo modo vorremmo sapere quale versione è stato l'ultimo semplicemente controllando la struttura delle cartelle, ed i nostri clienti, non avremmo dovuto preoccuparsi di rompere i cambiamenti fino a che non erano pronti per l'aggiornamento. Ha lavorato come un campione per noi; l'unica cosa che potrebbe avere cambiato è stato quello di utilizzare una singola cartella in modo che sarebbe più facile per vedere tutti insieme:

http://mydomain.com/path/to/service/2009-12-17/servicename.svc

Answer 3

Un WSDL è effettivamente l'interfaccia SOAP pubblicato del vostro servizio web. Molti clienti usano questo per generare i loro proxy client che espongono tutti i vostri metodi webservice nel loro linguaggio di programmazione di scelta. La maggior parte di questi clienti di codici generati sono molto fragili e sceglieranno di un'eccezione se vedono un elemento che non riconoscono (vale a dire la sua non nel WSDL), piuttosto che ignorarlo. Alcuni sono più rilassato ed è davvero fino alla tecnologia client che usano le nuove DataContract'S vale a dire Microsoft hanno interfaccia IExtensibleData sui loro clienti per contenere specificamente i dati non riconoscono in modo che sarà in gran parte ignorano elementi sconosciuti.

SOAP e il codice generato dal proxy client si presta a questo tipo di problemi perché generano i clienti che vogliono capire 'l'intero schema' piuttosto che solo i bit sono interessati ad. L'alternativa è per loro di utilizzare un XML Parser e solo tirare fuori i pezzi di cui hanno bisogno.

Se il servizio Web è in fase di sviluppo o il cambiamento costante allora SOAP non è davvero la scelta migliore in quanto significherà con ogni cambio dovranno rigenerarsi, ricostruire e ridistribuire i loro clienti di servizio. A seconda della situazione che si può prendere in considerazione la fornitura di servizi REST + POX (Plain Old XML) web, invece, come la sua più semplice da analizzare in quanto non ha il sovraccarico di SOAP, può essere chiamato tramite un URL normale e consumata da ambienti che non hanno una biblioteca SOAPClient (ad esempio direttamente in un browser, utilizzando AJAX)

Answer 4

Una possibile risposta potrebbe essere quella di utilizzare i gruppi di sostituzione per consentire modelli astratti del XSD si importa. La possibilità di elaborare un tale gruppo di sostituzione è ancora da validare con i quadri che si utilizza per richiamare tali servizi.