Brokering over WCF @ dotNetMarche

BROKERING...Silverlight & Wcf using a «more» SOA point-of-view

Mauro ServientiSenior Software Architect @ [email protected]

Microsoft MVP – Visual C# / MCTShttp://milestone.topics.it

Giorgio Formica

Senior Developer @ [email protected]

http://io.non.ho.un.blog....

The Agenda• The big picture:

• Requisiti;• Information flow;• Architecture;

• Technical overview:• Requirements;• Problems;• Solutions;

• Composition:• UI Composition;• Module Composition;• Touchin’ the surface of M-V-VM;

THE BIG PICTUREWhere do we want to go?

Distribuzione geografica• Necessità di supportare un ambiente geograficamente

distribuito;

• Possibilità di supportare scalabilità orizzontale;• Possibilità di supportare idempotenza;• Possibilità di supportare versioning di client e server non sincroni;

Atomicità• Necessità di poter decidere il «livello di atomicità» della

comunicazione in fase di inizio della stessa;

• Possibilità di parallelizzare un set di chiamate;• Possibilità di serializzare un set di chiamate;• Conseguente possibilità di gestire la transazionalità di un set di

chiamate;

Logica di business• Necessità di introdurre nuovi scenari di comunicazione

post deploy senza dover apportare modifiche strutturali al backend dei servizi;

• Possibilità di cambiare la logica di gestione server-side a caldo;• Possibilità di cambiare il livello di «composition» server-side;• Possibilità di gestire dei workflow server-side;

The big picture

• Sappiamo molto poco: mondi separati dove la connettività non è cosa certa;

ClientSomewhere

in time... Service

«high level» information flowClient

Somewhere in time... ServiceOperation

Request(s)

Operation Handler

RequestHandler(s)

• Un’operazione è atomica: certo…è una :-)• Un’operazione può portare con se più richieste e

più risposte: è una e «trina» ;-)• Il servizio non conosce gli handler;• Gli handler non conoscono il servizio;• Gli handler (msg) possono conoscersi: workflow;

IF YOU WANT BLOOD......you’ve got it! :-)

Technical problems• Siamo abituati ad una comunicazione con i servizi

«strongly typed at method level»;• Il proxy è generato da Visual Studio;• Svcutil.exe genera dei proxy/dto per ogni tipo ma

vedremo che a noi non va sempre bene...;

• In realtà Wcf non sa nulla di «metodi» e «classi» ragiona solo in termini di messaggi e azioni (e non solo...);

• Ma il messaggio di Wcf è troppo «raw» per i nostri gusti;• Abbiamo quindi la necessità di essere strongly-typed ma

anche generici… che simpatico…;

Operation: Request/Response

Messaging: Request/Response

Service: Entry Point

Service: Operation handling

Service: Message handling

DEMOA first approach to Kharon

Recap• Ad alto livello è tutto molto semplice:

• «banale» servizio Wcf, senza codice;• Messaggi;• Handlers;

• Se è tutto staticamente noto a compile time possiamo anche usare svcutil.exe;

• La chiamata è una normale chiamata a Wcf;• Un «blobbone» di reference giusto per semplificare il deploy;

Tutto facilissimo, non trovate?• L’infrastruttura (Caronte) vi

offre:• Il trasporto: lo stige;• la forma delle cose da

trasportare: le anime;

• A vostro carico c’è:• La gestione delle anime ;-)• Il client…ovviamente :-)

Si…certo certo…bravo bravo…ma?• Tutto ha un inizio…

• E una fine :-)

Oh my God… <cit.>• Perchè tutto ciò?

• Abbiamo bisogno di Inversion of Control @ Service Instance Level;

• e… ServiceLocator è il male :-)• A questo punto è tutto facile:

Non proprio tutto facilissimo…

• «ServiceKnownType» & «ServiceKnownTypesProvider»

• Ma… gli attributi di Wcf per il DataContractSerializer?

Configuration & Discovery

Why no auto-discovery?• Client docet :-)• Troppi vincoli sul deploy;

Under the Hood with «Windsor»

PAUSA?Sappiate che vi capiamo…

CLIENT POINT-OF-VIEWClient delle mie brame…

Client Agenda :-)• I’m the client and this is my language:

• Client comunication approach;

• Adapt yourself:• Server model – dto – client model;

• Compose your world :-)• UI Composition;• Module Composition;

• A lap around Model-View-ViewModel:• Client side brokering;

Il client e la comunicazione• Operations & Messages;

• Errori a livello di «Operation»;• Errori a livello di singolo

«Message»

Il client e la comunicazione• CorrelationId:

• Gestione del Tracking;• Discard, analisi e valutazione degli errori a livello di singolo

messaggio;• Idempotenza;

• È impostabile o «auto-generato»;

«low level» information flow /1• Un Model per rappresentarli:

• Creazione di un modello server-side per la gestione dell’informazione;• un Adapter per trasformarli:

• Realizzazione di un grafo di adapter per la trasformazione del dato in qualcosa di adatto al trasporto (aka serializzabile)

• un DTO per spedirli:• Definizione di un grafo di Data Transfer Object adatto a viaggiare «on the

wire»;• un Client Model per gestirli:

• Un modello client side che «copia» il modello server side finalizzato a riprodurre e garantire la stessa «development experience»;

• un ViewModel per mostrarli:• Esposizione del modello client alle View attraverso un set di ViewModel in

perfetto stile Model-View-ViewModel;

«low level» information flow /2

• Flusso bi-direzionale identico;• Il Client-Model e il Server-Model:

• Garantiscono consistenza;• Potrebbero essere shared;

• I processo di adapting conosce intimamente il modello:• EmitMapper (server-side) rulez :-)

Server-Model Adapter(s) DTO Adapter(s)

Client-Model

NH

ViewModel+

View

Compose your module(s)• La necessità di rendere l’applicazione estendibile ci porta

verso:• Partizionamento dell’applicazione in «moduli»;• «on demand loading» al fine di minimizzare il traffico fino all’effetiva

richiesta della funzionalità;

• «ModuleLoader»:• Discovery;• Modules on demand loading;

• «EventDrivenModuleManager»:• Module async download service for PRISM v3;

Intermezzo: il solito guastafeste…• Abbiamo dei moduli scaricati on-demand;• I tipi disponibili cambiano a runtime:

• Non possiamo usare svcutil.exe;• Dobbiamo avere per forza i tipi shared tra client e server;

• Ma alcuni tipi shared arrivano dopo…• Anche client-side possiamo usare il concetto di

ServiceKnownType(s);• Ma simpatia Wcf li «cacha» e se ne frega se cambiano;• Client EndPoint «Hack» per invalidare la «cache»:

• ClientConfiguration «depends» on IClientProxyFactory;

Client Type Sharing «gems»• Abbiamo lato server il Framework 4.0 e lato client Silverlight

4.0• «duplichiamo» i progetti:

• E…:• «Linkiamo» i file tra i progetti;• Definiamo gli stessi namspace di base;• Definiamo lo stesso nome dell’assembly:

• okkio alle TeamBuild… Gian Maria vi picchia;• Usiamo le post build action per portare quello che ci serve dove ci serve;

Compose your View(s)• La modularizzazione server-side porta in maniera naturale alla

modularizzazione client-side:• I «moduli» rappresentano parti del un servizio;• Parti di un servizio sono consumate da un modulo non noto

upfront;• In fase di design/protipizzazione è importante definire tutti

insieme la struttura delle region, il loro ruolo e il loro comportamento (RegionAdapters);

• E’ evidente che applicare in un contesto del genere Model-View-ViewModel in maniera quasi religiosa rende estremamente semplice rimpiazzare la rappresentazione visuale;

• Ma…

Client side brokering…• I ViewModel hanno bisogno di parlare tra loro…

• …ma non si conoscono, condividono solo lo stesso «postino» e conoscono il tipo di messaggio;

DEMO…MEGA DEMO :-)Tailspin Toys

CONCLUDENDOChe sudata…

ma siete pazzi…Perché tutto ciò?• La stessa cosa si può fare con un set di servizi ad hoc?

• Certo che si…

• Quindi siete definitivamente pazzi…• Framework riutilizzabile che abbatte la complessità di approccio ad

un modello basato su servizi;• Elevatissima flessibilità:

• Pluggabilità a caldo;• Pluggabile/Estendibile:

• Workflow di messaggi a livello di singola Operazione;• Cache (ad es. sul singolo messaggio);• Etc.. etc…

• Non c’è WCF... quindi se cambia l’architettura non cambia il codice;

«Forse» un po’ si…

Scenario: Video conference con Alessio e Marco

GO… Q&ADo not shoot the pianist(s) ;-)