Se chiediamo ad un avvocato di scrivere un contratto, garantendo un certo introito :-), ci innondera' sicuramente di domande e probabilmente scrivera' 40/50 pagine di documento dove ogni singola parola ha un suo peso specifico. In sostanza la regola e', ogni aspetto non 'normato' o definito rappresenta un threat.

In ambito IT si tende ad essere piu' lassisti ed il tempo dedicato a definire il contratto risulta quasi sempre insufficiente. La domanda che ci dobbiamo porre inizialmente e', che cos'e' un service contract? Mi piace molto la definizione data in "SOA: Principles of Service Design" che dice: "A service contract establishes the terms of engagement, providing technical constraints and requirements as well as any semantic information the service owner whishes to make public.".

In termini pratici un contratto viene rappresentato attraverso un insieme di documenti, ognuno dei quali rappresenta un aspetto del servizio. I principali sono

1. Definitzione  del WSDL
2. Definizione dello schema XML
3. Descrizione della WS-Policy
4. SLA, Service Level Agreement

Il WSDL definisce quali funzionalita', in termini di operation e metodi, il nostro servizio espone. Lo schema XML definisce la struttura del payload fra consumer e provider. WS-Policy definisce le modalita' di accesso al servizio (es. sicurezza, crittografia, ecc.). Lo SLA definisce il livello del servizio che siamo in grado o vogliamo mantenere (es. 24x7, 99.99%).

Se noi sviluppassimo un Web Service (con ASP.NET o WCF) seguendo scrupolosamente questa procedura potremmo garantire di avere dei servizi molto solidi e scalabili nel tempo, almeno a livello contrattuale. Purtroppo questo processo oggi non avviene praticamente mai. Il processo che usiamo solitamente e' quello di partire dal codice, applicare gli attributi necessari e fare in modo che il framework esponde i contratti per noi. Il risultato e' che abbiamo contratti molto weak e poco durevoli. I principali motivi sono:

1. Si e' concentrati sul codice e non sul contratto, quindi le funzionalita' che il servizio deve veramente erogare
2. Il contratto e' impreciso in quanto molti frameworks non supportano pienamente le restrizioni degli schemi XML e WSDL
3. Diventa troppo 'facile' cambiare il contratto, edit and build
4. In molti frameworks non vi e' alcuna validazione a runtime dello schema
5. I deserializzatori del payload SOAP sono molto spessi troppo flessibili

Sebbene abbiamo un certo tipo di supporto dai tool di sviluppo per il mondo dei servizi basati su SOAP, meno evidente e' la definizione dei contratti nel mondo ROA (o REST). Sun ha pubblicato una proposta nel 2006 chiamata WADL, Web Application Description Language. Dopo due anni mi sembra sia rimasta abbastanza lettera morta. L'alternativa consiste in WSDL 2.0, nella quale vi e' una buona apertura al binding sul protocollo HTTP.

Quindi, se andiamo a stilare la stessaa lista usata per SOA in ROA, possiamo scrivere:

1. Definitzione  del WSDL 2.0
2. Definizione dello schema XML
3. Descrizione della policy su protocollo HTTP
4. SLA, Service Level Agreement

Che manca allora? Direi una buona coperyura da parte degli strumenti di sviluppo.