brokering over wcf @ dotnetmarche
DESCRIPTION
Brokering over WCF @ dotNetMarcheTRANSCRIPT
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) ;-)