1 smart client: gestire informazioni in modalità disconnessa silvano coriani

1

Smart Client: gestire informazioni in modalità disconnessa

Silvano Coriani

2

Agenda

• Che cosa è uno Smart Client?– IssueVision

• La gestione delle informazioni• Un approccio completamente custom• Sfruttare l’infrastruttura di SQL Server• Utilizzare codice già pronto

– Offline Application Block

3

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

4

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

5

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?

6

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

7

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?

8

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

• …

9

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

10

Store locale dei dati

• Custom Data Object– 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<Serializable()> Public Class UserSettings Private m_username As StringPrivate m_username As String Private m_password As StringPrivate m_password As String

Public Property Username() As StringPublic Property Username() As String GetGet Return m_usernameReturn m_username End GetEnd Get Set(ByVal Value As String)Set(ByVal Value As String) m_username = Valuem_username = Value End SetEnd Set End Property ...End Property ...

11

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

12

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)

13

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

14

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

15

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!

16

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

17

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

18

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

19

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

20


• 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

21

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

22

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

23


• 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

24

Offline Application Block: componenti

25

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

26

Offline Application Block: sottosistemi

27

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

28

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

29

Architettura fisica dei componenti

30

Rilevazione della connettività

1122

31

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

32

Preparazione della cache locale

11

22

33

44

6677

88

99

1010

1111

1212

55

33

Refresh della cache locale

34

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

35

Inserimento dei comandi nella coda

11

22

33

44

36

Ciclo completo di richiesta-risposta

37

Sincronizzazione dei dati

11

33

44

55

66

77

22

38

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

39

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/workspa

ce.aspx?id=60dd1bb9-0d1e-45e0-975a-a7f398697344

• MSDN Patterns and Practices Web Site– http://www.microsoft.com/practices– http://msdn.microsoft.com/practices

41

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”

42

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