Prima vera sessione "seria" su Indigo. Due relatori d'eccezzione, Steve Swartz e Christian Weyer.

Si inizia spiegando i concetti base, quelli che spesso crediamo di avere chiari ma poi scopriamo che abbiamo delle falle. Sicuramente Indigo richiede una certa nomenclatura SOA oriented. Si parte dall'endpoint con le sue componenti: contratto, binding e address.

Non poteva mancare l'"Hello World". L'unica nota interessante di questa demo è la pulizia della soluzione. Nel suo piccolo evidenzia come si implementa un progetto SOA con Indigo. "Hello World" è composto da 4 progetti: l'assembly che contiene i contratti (le sole interfacce), l'assembly che contiene i servizi (le implementazioni dei contratti), l'assembly che contiene l'host (il processo ospitante i servizi) ed infine l'assembly consumer (la dove troviamo il proxy ed il client). Una distinzione che pare banale ma che troppo poco spesso viene applicata.

A questo punto si entra nel dettaglio del contratto. Indigo propone tre tipologie di contratto: data contract, message contract e service contract. Il primo è di fatto il messaggio (body del payload SOAP). Il message contract è il messaggio SOAP in toto, con il quale possiamo definire gli header SOAP. Infine il service contract è l'interfaccia del servizio.

Per ogni tipologia posso definirne le caratteristiche, come ad esempio il supporto per la sessione, il message pattern ecc. ecc. Un punto fondamentale, che manca totalmente in ASP.NET, è la possibilità di definire le fault (tradotte in SOAP faults) nel contratto.

Nella definizione del contratto posso anche essere estremamente flessibile, facendo in modo, per esempio, che un metodo possa accettare qualsiasi chiamata. Per farlo è sufficiente definire l'attributo action a *.

Si prosegue la presentazione con il binding. Il binding indica come si può consumare il servizio. Il binding è concepito come uno stack, che inizia con il trasporto, quindi l'encoding ed infine le caratteristiche (security, reliability, ecc.). IL binding può essere definito sia a livello di codice che di file di configurazione (opzione più gettonata). Troveremo comunque un set abbastanza ricco di bindings preconfigurati.

Ci spostiamo quindi sui behaviors, i quali definiscono come si deve comportare il servizio. L'instancing, la gestione della concorrenza, il throttling, come propagare il metadato, ecc. sono temi definiti nel behavior.

Si chiude la sessione con un esempio più complesso: IndiMusic. Si fa uso di un pattern di messaggistica duplex, MTOM, ecc ecc.

Che dire ? Gli speacker sono stati estremamente chiari e efficaci. Complimenti.