4. 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;
5. 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;
6. 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;
7. The big picture
Somewhere
Client in time... Service
• Sappiamo molto poco: mondi separati dove la connettività
non è cosa certa;
8. «high level» information flow
Client
Somewhere
Operation in time... Service
Request(s)
Operation
• Un’operazione è atomica: certo…è una :-) Handler
• Un’operazione può portare con se più
richieste e più risposte: è una e «trina» ;-) Request
• Il servizio non conosce gli handler; Handler(s)
• Gli handler non conoscono il servizio;
• Gli handler (msg) possono conoscersi:
workflow;
10. 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…;
17. 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;
18. 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 :-)
20. 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:
21. Non proprio tutto facilissimo…
• Ma… gli attributi di Wcf per il DataContractSerializer?
• «ServiceKnownType» & «ServiceKnownTypesProvider»
26. 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;
27. Il client e la comunicazione
• Operations & Messages;
• Errori a livello di «Operation»;
• Errori a livello di singolo
«Message»
28. 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»;
29. «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;
30. «low level» information flow /2
NH
Server-Model Adapter(s) DTO Adapter(s)
• Flusso bi-direzionale identico; Client-Model
• Il Client-Model e il Server-Model:
• Garantiscono consistenza;
• Potrebbero essere shared;
ViewModel
• I processo di adapting conosce +
intimamente il modello: View
• EmitMapper (server-side) rulez :-)
31. 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;
32. 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;
33. 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;
34. 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…
35. 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;
38. 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;
39. «Forse» un po’ si…
Scenario: Video conference con Alessio e Marco