Quale è il migliore approccio ai servizi web - primo contratto o un contratto durare?

Question

Qual è l'approccio migliore per lo sviluppo di servizi web; primo contratto o un contratto durare?
Quali sono i vantaggi e gli svantaggi di ciascuno?

Quali avete esperienza con?

Modifica Questa domanda riguarda la realizzazione di un servizio web (leggi: SOAP) La questione è se le classi di implementazione dovrebbe essere codificata prima e lo schema WSDL e XSD generato da quella (contratto ultimo) o il WSDL e schema XSD scritto prima e le classi di implementazione generato (primo contratto)

Answer 1

Contratto-prima è la generalmente accettata 'best practice'.

Ti fa essere molto chiaro sia con il produttore e consumatore del servizio esattamente ciò che è necessario e ciò che ci si aspetta. Questo diventa particolarmente importante quando si inizia cercando di convertire i tipi Java -> Tipi di XML. Sei anche in grado di riutilizzare gli schemi attraverso il servizio web diverso.

Answer 2

Ho usato entrambi gli approcci. Il mio suggerimento è quello di utilizzare contratto prima dello schema, ma primo codice WSDL.

Scrivi file WSDL ha un sacco di sfumature strane come attacchi, porti e così via. Preferirei che questo sia fatto con strumenti piuttosto che a mano. Ci sono strumenti che consentono di fare questo, ma nessuno di loro sono più semplici di

@WebService
public ...

Per lo meno si può verificare la distribuzione.

Per lo schema, ho suggerito contratto prima perché il linguaggio XML Schema è molto più ricco di quello che si può descrivere in Java. Un esempio Io di solito dare sta dimostrando che XML Schema può limitare le dimensioni di una stringa e applicare un modello di espressione regolare. Fare questo in Java e annotazioni sembra un po 'disordinato.

Un altro vantaggio di fare lo schema di contratto di prima è la presenza di strumenti per convertire il vostro file di schema in documentazione HTML.

Lo strumento XJC in grado di generare i file di classe necessari. Tuttavia, vorrei solo consiglio di fare che alla partenza.

Alla fine si dovrebbe prendere il file WSDL generato e lavorare con quella invece. In questo modo è possibile utilizzare wsimport e verificare che il tutto da WSDL allo schema è valido.

È possibile distribuire con il file WSDL utilizzando l'attributo wsdlLocation nell'implementazione @WebService e il server applicazioni risolverà i dati vincolanti per voi quando gli utenti richiedono il WSDL dal server, ma si conservano ancora le vostre annotazioni. In caso contrario, le annotazioni non appariranno sui file WSDL richiesti.

Answer 3

Ho il sospetto che la risposta è un "dipende".

Il problema è che se si costruisce e pubblicare il contratto, sei destinato da essa. Questo rende più difficile cambiare. Non impossibile, ma difficile.

D'altra parte, è più veloce di pasticciare con il contratto che con il codice, se sei a tuo agio con schemi ecc Così si può fare un certo cambiamento incrementale nel contratto.

Non ci sono anche strumenti che genereranno uno scheletro codice WSDL? Sono quasi positivo ci sono. Se è così, si potrebbe fare bene a fare gli schemi della voce "codice", e generare il codice da esso.