Smart Client: gestire informazioni in modalità disconnessa Silvano Coriani

Agenda Che cosa è uno Smart Client? La gestione delle informazioni IssueVision La gestione delle informazioni Un approccio completamente custom Sfruttare l’infrastruttura di SQL Server Utilizzare codice già pronto Offline Application Block

Che cosa è uno Smart Client? Applicazione con interfaccia utente Windows NON un browser, ma UI ricca e adatta a task complessi Utilizza le potenzialità e sfrutta le prestazioni del client Interazione con dati che riesiedono sul server Ma anche gestione di risorse locali Utilizzo “smart” delle tecnologie Web Non una nuova architettura, ma un diverso approccio al client/server o agli n-livelli Consente di gestire situazioni di “connettività occasionale” Dati disconnessi e sincronizzazione Funzionalità di sicurezza avanzate Facilità di distribuzione e manutenzione delle applicazioni anche in scenari complessi

Demo: IssueVision (http://www.windowsforms.net) Desktop client Applicazione pratica di Design Pattern (Observer, Command, ecc.) Creazione e utilizzo di Custom Control (Outlook-style) XP Themes Dati Gestione di dati online/offline Gestione della concorrenza ed eventuali conflitti Deployment No touch deployment e auto update Creazione di Setup e ridistribuzione del .NET Framework Sicurezza DPAPI Encryption WS-Security Code Access Security

Smart Client e gestione delle informazioni Alcune delle caratteristiche implementate in IssueVision presentano molte sfide per lo sviluppatore Come gestisco il funzionamento Offline? Come garantisco un accesso ai dati “responsive” anche mentre il client interagisce (magari via Web Service o altro) con il server remoto? Come gestisco la sincronizzazione dei dati tra client e server? Come riconciliare gli eventuali conflitti che possono verificarsi?

Quando “offline” ha senso… Effettivo utilizzo offline dei dati In caso di connettività completamente assente Situazioni di connettività intermittente Copertura Wireless non perfetta Magazzini, piazzali, utenti mobili, ecc. Quando la concorrenza sui “propri” dati non è particolarmente forte Es: gestione dei “miei” ordini di spedizione, ecc. Quando le attività di modifica sui dati sono relativamente poche

Dove mantenere i dati in locale? Environment.SpecialFolder.LocalApplicationData Scelta migliore per dati non-documentali Nome azienda, nome prodotto, versione Isolated Storage Alternativa valida per applicazioni partial-trust Store sicuro per applicazioni della quale non si conosce la provenienza {userfiles}\My Documents Per i documenti Tip: Mai memorizzare i dati applicativi in “program file”! Forza l’applicazione ad essere eseguita come Admin!!! Database? Code di messaggi?

Alcune possibili soluzioni Approccio completamente custom IssueVision come riferimento Utilizzo di SQL Server/MSDE come store locale Replica dei dati sul SQL Server centralizzato Offline Application Block Flessibilità e potenza …

Approccio custom: quale strategia? Sviluppo “in proprio” di Codice di accesso ai dati e Stored Procedure Gestione delle credenziali di sicurezza DataSet o oggetti custom come store locale dei dati Gestione della concorrenza tra i diversi client Recupero dei dati e sincronizzazione con il server Protezione dei dati offline Abbastanza complesso e costoso

Store locale dei dati Custom Data Object DataSet - Typed datasets Controllo completo sull’implementazione Possono essere più leggeri di un DataSet Ideali per singola istanza di dato, informazioni non tabellari DataSet - Typed datasets Struttura tipizzata, già pensata per gestire le comuni attività sui dati, estendibile <Serializable()> Public Class UserSettings Private m_username As String Private m_password As String Public Property Username() As String Get Return m_username End Get Set(ByVal Value As String) m_username = Value End Set End Property ...

Gestione della concorrenza Politica con la quale vengono gestite le modifiche eseguite da più utenti contemporaneamente e I possibili conflitti Concorrenza ottimistica Verifica i cambiamenti rispetto ai dati originali prima di aggiornare Scelta tipica di applicazioni Smart Client “Last in Wins” L’ultima modifica è quella che viene mantenuta nel database Molto scalabile, ma nessuna forma di integrità dei dati Concorrenza pessimistica Basata su concetti di Lock di record, pagine o tabelle nel database da parte di un singolo utente Massima integrità dei dati Problemi di scalabilità e prestazioni Difficile da implementare in uno scenario Smart Client

Riconciliazione delle modifiche Metodo DataAdapter.Update() HasChanges(), GetChanges(), DiffGram Supporto per transazioni in ADO.NET Ideale per: Applicazioni con un singolo database Dati letti e modificati via Web services In generale, soluzioni che gestiscono “moderate” quantità di dati e “moderato” numero di modifiche in modalità offline Limitare la dimensione del DataSets sul client Tipicamente sotto i 2 MB (regola empirica)

Obiezione: bello, flessibile, ma molto impegnativo da sviluppare se la soluzione è complessa!

Quando i dati in locale crescono Consigliabile l’utilizzo di MSDE Motore relazionale royalty-free Occorre gestire il deployment sui client Ideale per lavorare con grandi quantità di dati relazionali Scenario “database distribuito” Utilizzo della replicazione per sincronizzare i dati con un SQL Server centralizzato Meglio se LAN o VPN

SQL Server Replication Diversi tipi di replica secondo la natura dei dati Merge, Transactional, Snapshot Programmabile per setup e sincronizzazione Trasparente al codice di accesso ai dati dell’applicazione L’applicazione lavora sempre sul db locale Sincronizzazione automatica o custom Attraverso i custom resolver (Stored Proc, componenti COM, ecc) Ideale per: Riconciliare un grande numero di conflitti Eseguire aggiornamenti batch modello “ufficio periferico” “Dimenticarsi” della logica di sincronizzazione!

Obiezione: bello, molto potente, ma occorre SQL Server sul back-end, inoltre temo possa non coprire tutti gli scenari applicativi che devo gestire!

Che cos’è un Application Block? È un componente disponibile in forma di codice sorgente riutilizzabile, progettato seguendo design pattern e best practice, per risolvere in modo flessibile una specifica problematica legata all’infrastruttura di una applicazione Il codice è fornito tipicamente in C# and VB.NET Documentazione Quick Start sample http://www.microsoft.com/resources/practices/code.mspx

Application Block: obiettivi Insieme di API intuitive per gli sviluppatori Utilizzo di design pattern durante la progettazione Modello di configurazione comune e consistente tra tutti gli Application Block Per favorire l’automazione delle attività amministrative Consentono una completa customizzazione attraverso un approccio a plug-in estendibili Disponibilità del codice sorgente anche come reference per lo sviluppo di componenti complessi Ridurre i tempi di sviluppo del codice infrastrutturale

Offline Application Block Copre alcune aree principali Rilevazione della presenza/assenza della rete Fornisce l’infrastruttura per incorporare funzionalità offline in applicazioni di tipo Smart Client Supporta lo sviluppo di interfacce utente asincrone anche durante l’esecuzione di comandi remoti (interrogazioni, aggiornamenti..) Consente di implementare meccanismi di sincronizzazione tra client e server

Offline Application Block Cosa non è coperto Gestione della distribuzione e degli aggiornamenti di una applicazione Vedere sessione successiva… Riconciliazione dei dati L’Offline Application Block mette a disposizione l’infrastruttura, ma la logica e le strategie di riconciliazione appartengono al dominio applicativo Nessuna riconcilazione Individuazione dei conflitti e intervento manuale degli operatori attraverso funzionalità specifiche dell’applicazione Regole automatiche implementate nell’applicazione

Lesson learned in Microsoft Le lezioni imparate dai team che hanno sviluppato questo genere di applicazioni in Microsoft sono state Non è possibile incorporare queste funzionalità DOPO che l’applicazione è stata progettata Alcuni scenari non possono essere coperti da questo genere di applicazioni Esistono considerazioni di deployment e infrastrutturali da tenere in considerazione quando si progettano applicazioni che devono funzionare offline Alcune applicazioni particolarmente “data dependant” non sono buone candidate per il funzionamento in offline

Terminologia dell’Offline Block Offline Mode: La connettività di rete non è disponibile Reference Data: Dati che sono tipicamente read-only e disponibili in cache locale per varie attività Es. Tabelle di decodifica Message Data: Dati creati durante il funzionamento dell’applicazione

Offline Application Block Caratteristiche fondamentali Progettato per lavorare in uno scenario Service Oriented, utilizzando una comunicazione message based Consente un modello di programmazione consistente tra online e offline mode Fornisce una architettura a plug-in per rilevamento dello stato connessione, caching e gestione di code di messaggi Componenti tra loro disaccoppiati Possibili differenti configurazioni per il deployment

Offline Application Block: componenti

Componenti Application: l’applicazione Smart Client Service Agent: fornisce il punto di accesso alle funzionalità offline Service Request: tutti i dettagli di una richiesta sono incapsulati in un service request object Queue: fornisce uno storage persistente per i service request objects Executor: prende le richieste dalla coda e invoca il servizio quando la connessione ritorna disponibile Service: fornisce la logica applicativa utilizzata dallo Smart Client e tipicamente risiede su un server remoto

Offline Application Block: sottosistemi

Sottosistemi Connection State Management: rileva lo stato della connessione di rete Service Agent Management: gestisce i diversi service agent e restituisce i risultati dell’esecuzione di particolari servizi Reference Data Management: gestisce il download dei dati utilizzati come cache sul client Message Data Management: gestisce i messaggi contenenti le operazioni sui dati e la loro sincronizzazione

Service Agent Management Service Agent Manager: gestisce il risultato restituito da un Service Agent Service Agent: classe base per le diverse tipologie di servizi Application Service Agent: creato dallo sviluppatore dell’applicazione per inviare e ricevere i messaggi Online Proxy: creato dallo sviluppatore per comunicare con il servizio remoto e gestire la cache Sono stateless

Architettura fisica dei componenti

Rilevazione della connettività 2 1

Reference Data Management Data Loader Manager: consente all’applicazione di scaricare i dati in cache Reference Data Cache: interfaccia per gli utilizzatori delle funzionalità di caching Caching Block: implementa le funzionalità di caching

Preparazione della cache locale 12 1 11 2 3 4 10 5 6 7 8 9

Refresh della cache locale

Message Data Management Queue Manager: gestisce i diversi provider per le code di messaggi Queue Storage: fornisce l’accesso ai diversi data store In-memory, Isolated Storage, MSDE, MSMQ Executor: legge i messaggi dalla coda e invoca l’Online Proxy

Inserimento dei comandi nella coda 1 2 3 4

Ciclo completo di richiesta-risposta

Sincronizzazione dei dati 5 4 6 7 2 1 3

In sintesi Una delle funzionalità più interessanti da implementare in uno Smart Client è la possibilità di lavorare online – offline Esistono diversi approcci che possono coprire le diverse necessità applicative Possiamo sviluppare il tutto da zero (IssueVision) Massima flessibilità ma costo spesso elevato Basarci su tecnologie esistenti (SQL Server) Ottima scalabilità, trasparente alle applicazioni ma vincolante Oppure basarci su componenti riutilizzabili e ben progettati (Offline Application Block) Soluzione molto flessibile, estendibile in ogni sua componente!! Ottima come spunto per creare una propria metodologia

Riferimenti Esempi di Smart Client Windows Forms http://www.windowsforms.net Offline Application Block Download http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/offline.asp Offline Block GotDotNet workspace http://www.gotdotnet.com/Community/Workspaces/workspace.aspx?id=60dd1bb9-0d1e-45e0-975a-a7f398697344 MSDN Patterns and Practices Web Site http://www.microsoft.com/practices http://msdn.microsoft.com/practices

© 2003-2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Queue Message Classe container per i dati inseriti nella coda Contiene il payload del messaggio: tutti i dati necessari per gestire la richiesta Identità dell’ Application Service Agent che deve ricevere i dati in risposta (Service Agent GUID): popolata automaticamente Payload GUID – identifica ciascun messaggio: generato automaticamente Nome del metodo da chiamare sull’Online Proxy: inserito dall’Application Service Agent Dati da inviare al server: inseriti dalla logica dell’Application Service Agent Dati ricevuti dal server: popolati dall’Online Proxy Può essere liberamente estesa per gestire dati “custom”

Altre classi legate alla chace locale Reference Data Cache: wrapper per fornire l’accesso ai dati nella cache Reference Data Definition – i metadati associati con gli elementi nella cache Reference Data Refresh Controller – responsabile della gestione del refresh della cache quando scaduta Data Loader Manager: crea il messaggio per eseguire il download dei dati nella cache Reference Cache Data Payload: classe che contiene fisicamente i dati della cache