Visto che si sono mosse le massime autorità del settore,
mi sembra giusto aggiungere il mio personale parere, in qualità di ... minima
autorità del settore 
Parto da questa
affermazione:
<quote>
Remember
that WSDL/XSD/Policy is the contract, period. (Tim Ewald)
</quote>
Una frase molto lapidaria, per
lo meno se viene estrapolata dal contesto, come sto facendo io ora.
Il contratto, insomma, deve essere definito in termini universali (nel senso
di interoperabili, condivisibili da piattaforme differenti). Altrimenti perde la
nozione stessa di contratto e diventa, appunto, una
interpretazione.
Questa è la visione di chi definisce lo schema per i
contratti e ne
fa, di fatto, uno standard.
Niente da dire.
Poi c'è chi, in base a quello standard, si trova a dover definire un contratto. A
progettare, insomma, l'interfaccia esposta da un servizio (interfaccia in senso
generico, indipendentemente da ciò che questo significa a livello di linguaggio
di programmazione / runtime).
In che modo ?
Scrivendo il contratto nei
termini previsti dal modello per i contratti: WSDL/XSD.
In fin dei conti, quando un
notaio prepara un contratto (ok, non è lo stesso concetto di contratto, ma da un
certo punto di vista si tratta pur sempre di un documento che mette d'accordo
due parti), segue i canoni previsti dalla legge ed utilizza il linguaggio
giuridico, non certo lo slang di tutti i giorni.
Il risultato è che per mettersi
d'accordo sul passaggio di proprietà di un'automobile vengono preparati un bel
po' di fogli dal significato spesso oscuro.
Definire un contratto
scrivendosi a mano il file wsdl è tedioso.
Non tutti ne sono capaci (per lo
meno a farlo from scratch con notepad), e sicuramente la probabilità di errore
non è trascurabile.
Ecco dove sta il problema,
secondo me.
Occorre uno strumento che
permetta di definire il contratto senza impelagarsi nei meandri di
WSDL.
Un designer ben fatto, ad
esempio, oppure ...
... il linguaggio che si utilizza nell'implementazione del
servizio.
In questo senso, "definire il
contratto in C#" non significa utilizzare C# come lingua franca e universale, ma
semplicemente come strumento in grado di produrre quella stessa lingua franca e
universale.
WSDL rimane lo standard per formalizzare un contratto, in pratica è la
forma
del contratto.
C# (o Java che sia) è
solo un mezzo per esprimerla.
E' ovvio, e anche qui non ci
piove, che un conto è semplificare, un conto è nascondere:
<quote>
I think
that writing some code in your tool and having it generate the logical part of
your contract is a bad idea if you don't know and care about exactly how it
works (Tim Ewald)
</quote>
<quote>
quelli
che conoscono WSDL e XML e li sanno scrivere (ma soprattutto leggere) .... in
media scrivono codice migliore di quelli che ignorano il funzionamento interno
di ciò che usano (Paolo Pialorsi)
</quote>
Un'ultima considerazione.
Eccessivamente forzosa, però ha il suo perchè, secondo me.
Io e un mio amico ci dobbiamo
scambiare un listato. Il formato di scambio è l'assembly x86.
Possiamo metterci a scrivere
assembly (ammesso di esserne capaci) e scambiarci quello. Ci siamo attenuti
rigorosamente allo schema.
In alternativa possiamo scrivere
in C.
Un listato C non è un formato di
scambio valido, non fosse altro perchè non è detto che entrambi conosciamo il
C.
Però se siamo d'accordo sul
compilatore da utilizzare, possiamo assumere che lo stesso codice C, compilato
su macchine differenti ma con ambiente equivalente, produca lo stesso codice
macchina. Se manca uno di questi requisiti, crolla tutto il castello, però
...
... se i requisiti ci sono
tutti, il C può essere allora considerato un formato di scambio valido
?