Upload
angiola-spina
View
218
Download
2
Embed Size (px)
Citation preview
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
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
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
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
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
40
© 2003-2004 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
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