Pro e contro delle strategie di versioning dei servizi Web

Question

Aggiornamento 20100224 Non ho davvero bisogno di alcune definizioni zoppicanti da qualche sito Web del fornitore. Quello che cerco è l'implementazione pratica e le sfide affrontate nel ciclo IT/business quotidiano per le persone che implementano effettivamente queste cose.

Più roba segue:

Nessuna strategia di pensionamento è stata creata/adottata: Ovviamente bisogna essere creato. Sono interessato a come crei questa strategia e la vendi alla gestione. Quali sono tutti i costi/benefici che guardi? Esegui un'analisi BE sui requisiti di ricodifica dei clienti rispetto ai requisiti di supporto interno? Assegni un valore $ ai costi di supporto interni delle API antiche?

Implicazioni del supporto IT di produzione: come avete lavorato con i vostri gruppi IT di produzione per implementare la vostra strategia. Cosa gli piace e cosa li rende pazzi?

Software: cosa piace fare al software, cosa gli dice di fare e cosa fanno effettivamente? Cosa funziona meglio per loro?

QA: In che modo QA ama gestire i test. ex. Se hai creato un singolo servizio che gestisce più versioni, il QA esegue la regressione completa per ogni volta che viene apportata una modifica a una delle versioni?

DBA: in che modo il tuo dba si occupa dei processi comuni che sono fondamentali per la registrazione dei dati per l'aggiunta di un campo a una risposta xml? Hai un singolo proc o fai succursali e segmenti basati su uno schema o altro?

---

nota originale

sto raccogliendo informazioni sui pro ei contro dei diversi servizi web di versioning strategie. L'azienda non ha ancora definito una strategia per il ritiro dei servizi Web e i miei servizi Web cambiano in modo significativo a causa di modifiche ai prodotti, modifiche dei requisiti dei clienti e modifiche dell'integrazione dei partner.

Cerco un pro/contro per il mantenimento della posizione indipendente da soli o più versioni/integrate nel tempo e come questo influenza il business tra cui il supporto degli sviluppatori/risorse Integration Developer, il supporto IT di produzione, Software, QA & DBA.

Qualsiasi intuizione, esperienza, risorse o idee sono apprezzate.

Answer 1

I servizi Web nella nostra applicazione sono solo un front-end della logica di business.

La nuova versione del servizio Web viene visualizzata a causa della modifica della logica di business. Quando viene introdotta una nuova versione del servizio web, questa viene posta sotto il nuovo URL. Ad esempio:

ver1 /websvc 
ver2 /websvc2

Esiste un codice speciale tra il livello di servizio Web e il livello aziendale. Questo livello gestisce le differenze nelle versioni dei servizi Web e passa una chiamata all'ultimo livello aziendale.

È il problema del codice di facciata speciale (tra servizio Web e business logic) per conoscere le differenze di versione del servizio web.