2012-12-13 13 views
15

Background:Come gestire il codice per i servizi Web SOAP con versione?

  • nostri servizi web sono società interna, ma con un sacco di sistemi diversi che li utilizzano
  • ci impegneremo a deprecare/rimuovere le vecchie versioni del api come più possibile

C'è un sacco di informazioni per quanto riguarda il controllo delle versioni dei servizi web, e la nostra decisione è stato quello di utilizzare il seguente approccio alla versione nostri servizi web:

  • Mantieni la versione in URL (so che alcune persone sono contrarie, ma principalmente riguardo ai servizi REST) ​​
  • Mantieni la versione nello spazio dei nomi.

Ma ora stiamo decidendo come implementarlo realmente, e qui non abbiamo trovato molte informazioni sulle migliori pratiche. Usiamo (Java):

  • annotazioni per definire i nostri servizi web (e l'API servizio web)
  • fagioli POJO annotati con annotazioni XML, per definire il contenuto
  • classi Converter per convertire da/per la livello di business e il servizio web di POJO
  • Primavera

Così, per mantenere le vecchie versioni sui servizi web, abbiamo bisogno di mantenere le vecchie versioni del codice. Per fare questo, abbiamo sostanzialmente esaminato due diversi approcci:

1) Per ogni nuova versione, fare una nuova copia completa del codice relativo

Questo approccio sarebbe simile a questa:

com.company.webservice.v3. -all of the web service classes, POJO’s and converters go here 
com.company.webservice.v4. -all of the web service classes, POJO’s and converters go here 

Quindi, qui abbiamo il codice duplicato. Il nostro pensiero in breve:

  • Duplicazione del codice. Saranno diverse classi con codice identico. Forse confondendo in Eclipse.
  • isolamento completo, facile determinare ciò che costituisce una versione specifica
  • rischio ridotto al minimo per influenzare la funzionalità delle versioni precedenti dei servizi di

2) Utilizzare primavera per fare solo una copia di ogni classe che è affetto da una modifica

Questo approccio significa utilizzare Spring IoC e consentire a tutte le versioni dei servizi Web di utilizzare, per quanto possibile, lo stesso codice. Solo quando apportiamo una modifica che influisce sul comportamento/api, creiamo nuove versioni di tali classi. Per esempio:

com.company.webservice.beans.MyXMLAnnotatedPOJOv3.java 
com.company.webservice.beans.MyXMLAnnotatedPOJOv4.java 
com.company.webservice.translators.MyXTranslatorv1.java 
com.company.webservice.translators.MyXTranslatorv2.java 
  • potrebbe essere difficile da vedere chiaramente ciò che costituisce una versione specifica di un servizio web. Forse più facile da omettere influire sulle versioni precedenti dei servizi web mantenendo il codice
  • Nessuna duplicazione di codice.Solo le modifiche sono implementate come nuove classi

Nessun approccio è ottimale, ma non abbiamo trovato molte informazioni a riguardo. Quindi, le mie domande sono: quale dei due approcci useresti? O faresti un approccio completamente diverso?

+0

"quale dei due approcci useresti? O adotteresti un approccio completamente diverso" = principalmente basato sull'opinione – Raedwald

+1

Hai avuto ulteriori esperienze su questo argomento? Sto affrontando lo stesso tipo di problema e voglio definire le migliori pratiche/processi per far evolvere il nostro servizio web. –

risposta

5

Quando la generazione WSDL da Java, vorrei utilizzare la soluzione del pacchetto:

com.company.webservice.v3. 

Ha il problema duplicazione del codice, ma i POJO e convertitori hanno differenze tra le versioni anymay, quindi il riutilizzo del codice potrebbe non essere molto fattibile dopo tutto. Il vantaggio principale è che se si vuole eliminare una vecchia versione, basta cancellare i pacchetti rilevanti.

Manterrei il numero di versione nell'URL, poiché comunque non si sta eseguendo REST. Inoltre, è possibile archiviare i log di accesso, se alcune versioni sono ancora utilizzate.

+0

Grazie per l'input. Penso che ci stiamo appoggiando anche in questa direzione. Ciò che ci turba è che spesso, tra due versioni, apportiamo modifiche minori che riguardano <10 classi, di> 100 in totale. Quindi, ad esempio in Eclipse, la ricerca della classe "MyXMLAnnotatedPOJO.java" potrebbe fornire 7 hit identici in 7 diversi pacchetti da "v1" a "v7". – Magnus

+0

Modifiche compatibili, come l'aggiunta di un'operazione aggiuntiva, non è necessaria una nuova versione. Inoltre, puoi inserire il numero di versione nei nomi delle classi. – Hugo