Retrocompatibilità e servizi Web

Question

Quindi sono un po 'nuovo ai servizi Web e una situazione recente è arrivata dove abbiamo aggiunto un elemento a un tipo di dati che viene restituito al client. I clienti si sono lamentati del fatto che questo ha rotto la loro implementazione perché si è soffocata sul nuovo elemento che non si aspettava. (stiamo fornendo i servizi tramite Axis2).

Per me questo sembra un cambiamento innocuo che il client dovrebbe essere in grado di gestire con garbo (ho lavorato con alcuni framework non-web-service in cui aggiungere informazioni opzionali era completamente accettabile). Potrei capire se abbiamo eliminato o rinominato alcuni campi che causerebbero problemi al client.

Fondamentalmente mi aspetto che wsdl si comporti come un'interfaccia. Se apportassimo una modifica a sottotipi che si interfacciano in modo sostanziale, mi aspetterei che il cliente ignorasse felicemente gli elementi estranei. È solo una breve venuta di servizi web, oppure esiste un modo sano per apportare modifiche passive ai servizi in modo che i nuovi clienti possano ottenere i dati aggiuntivi mentre i vecchi clienti possono aggiornare a loro piacimento?

Answer 1

WSDL agisce in realtà come un contratto più di un'interfaccia. Il WSDL descrive esattamente cosa l'operazione si aspetta di "ricevere" e cosa si aspetta di "restituire". L'analogia più simile a questa sarebbe in C cambiando il prototipo per una funzione senza cambiare la funzione stessa, non si combina e questo causa problemi.

Più specifico è il WSDL, maggiore è il comportamento che si sta "garantendo".

Se avete bisogno di flessibilità nei dati restituiti (cioè l'aggiunta/rimozione di campi ecc) si può fare uno dei seguenti:

1. versione delle definizioni WSDL e pubblicare servizi in grado di reindirizzare le versioni più vecchie alle nuove versioni
2. Utilizzare più tipi di ritorno dati astratti, ad esempio XML per nascondere la complessità o modificare i dati.

2 ha qualche rischio in più, ma può essere gestito con XSD o altre tecnologie. I tuoi particolari requisiti di progetto detteranno ciò che è accettabile.

Answer 2

In passato, quando si trattava di API WebService esposte, ho sempre seguito la filosofia del versioning delle date. Sfortunatamente, devi gestire la retrocompatibilità per qualsiasi API che pubblichi quando non sei in modalità "beta" (e talvolta anche in quel momento).

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 sapremmo quale versione è stato l'ultimo solo controllando la struttura delle cartelle, ed i nostri clienti non avrebbero preoccuparsi di rompere le modifiche fino a quando non erano pronti per l'aggiornamento. Ha funzionato 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 è in effetti la tua interfaccia SOAP pubblicata del tuo servizio web. Molti client usano questo per generare i loro proxy client che espongono tutti i tuoi metodi di webservice nel loro linguaggio di programmazione di scelta. La maggior parte di questi client generati dal codice sono molto fragili e sceglieranno di lanciare un'eccezione se vedono un elemento che non riconoscono (cioè non nel WSDL) piuttosto che ignorarlo. Alcuni sono più rilassati ed è davvero all'altezza della tecnologia client che usano, ad es.I nuovi DataContract di Microsoft dispongono di un'interfaccia IExtensibleData sui loro client per contenere in modo specifico i dati che non riconoscono, in modo che ignorino in gran parte gli elementi sconosciuti.

SOAP e proxy client generati dal codice si prestano a questo tipo di problemi perché generano client che desiderano comprendere "l'intero schema" anziché solo i bit a cui sono interessati. L'alternativa è che utilizzino un Xml Parser e tira fuori i pezzi di cui hanno bisogno.

Se il tuo servizio Web è in fase di sviluppo o modifica costante, SOAP non è davvero la scelta migliore poiché con ogni modifica dovrà rigenerare, ricostruire e ridistribuire i propri client di servizio. A seconda della situazione, potresti prendere in considerazione la possibilità di fornire servizi web REST + POX (Plain Old Xml) anziché analizzarli in quanto non ha il sovraccarico di SOAP, può essere chiamato tramite un normale URL e consumato da ambienti che non possedere una libreria SOAPClient (ad esempio, direttamente in un browser, utilizzando AJAX)

Answer 4

Una possibile risposta sarebbe utilizzare i gruppi di sostituzione per abilitare i modelli astratti nell'XSD che si importa. La possibilità di elaborare un gruppo di sostituzione di questo tipo deve ancora essere convalidata con i framework che si stanno utilizzando per richiamare tali servizi.