Smart Client: gestire informazioni
in modalità disconnessa
Silvano Coriani
1
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
2
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
3
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
4
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?
5
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
6
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?
7
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
• …
8
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
9
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
<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 ...
• DataSet - Typed datasets
– Struttura tipizzata, già pensata per gestire le comuni attività sui dati,
estendibile
10
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
11
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)
12
Obiezione: bello, flessibile, ma molto
impegnativo da sviluppare se la
soluzione è complessa!
13
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
14
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!
15
Obiezione: bello, molto potente, ma
occorre SQL Server sul back-end, inoltre
temo possa non coprire tutti gli scenari
applicativi che devo gestire!
16
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
17
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
18
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
19
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
20
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
21
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
22
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
23
Offline Application Block: componenti
24
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
25
Offline Application Block: sottosistemi
26
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
27
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
28
Architettura fisica dei componenti
29
Rilevazione della connettività
1
2
30
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
31
Preparazione della cache locale
12
1
11
2
3
4
10
5
6
7
8
9
32
Refresh della cache locale
33
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
34
Inserimento dei comandi nella coda
1
2
3
4
35
Ciclo completo di richiesta-risposta
36
Sincronizzazione dei dati
5
4
6
7
2
1
3
37
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
38
Riferimenti
• Esempi di Smart Client Windows Forms
– http://www.windowsforms.net
• Offline Application Block Download
– http://msdn.microsoft.com/library/default.asp?url=/library/enus/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
39
© 2003-2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
40
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”
41
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
42