1. Primo semestre 2009
in collaborazione con:

2. Silverlight 2.0: Networking Explained
Tecniche di accesso alla rete con Silverlight 2.0
» Andrea Boschin

3. Agenda
» Introduzione » Tecniche Avanzate
• Networking basics • Sockets
• Cross domain policies • Polling Duplex
• Tecniche di
programmazione » Strumenti a supporto
• Serializzazione
» Strumenti • Syndication
• HttpWebRequest • XamlReader
• WebClient
• Web Services » Domande & Risposte
www.xedotnet.org 3

4. Agenda
» Silverlight ai minimi termini
• E’ un plugin per il browser
• Funziona sui più comuni browser
• Funziona sui più comuni S.O.
• Ha un supporto per il video molto efficace
• Si programma con XAML e linguaggi evoluti (C#)
• E’ una piattaforma per lo sviluppo di applicazioni
• Una piattaforma per “applicazioni online” richiede un eccellente supporto
alla rete
• Silverlight ha una serie di strumenti per l’accesso alla rete molto evoluti e
di semplice utilizzo
27/02/2009 www.xedotnet.org 4

5. Introduzione
» Architettura
• L’accesso alla rete è mediato dal browser che contiene il
plugin.
• Il plugin perciò non è in grado di fare nulla di più di quello che
la sandbox del browser gli mette a disposizione
• Questa scelta ha il vantaggio di condividere con il browser il
contesto
• Caching
• Autenticazione
• Cookies
www.xedotnet.org 5

6. Introduzione
» Limiti di HTTP
• Supporto esclusivo a GET e POST
• Header quasi completi, sia standard che custom
• HttpStatus limitato a 200 e 404 (attenzione!)
• Supporto al redirect solo su domini “abilitati”
www.xedotnet.org 6

7. Introduzione
» Accesso solo a dominio di origine
• La limitazione è superabile ma con la collaborazione del
destinatario (cross-domain-policy)
• L’accesso può essere Cross-domain, Cross-scheme o Cross-Zone
(solo su Windows) e ci sono differenze tra le varianti
• La ricerca del dominio si basa sull’origine dello XAP
• Partecipano protocollo, dominio e porta
• http://domain:port
• https://domain:port
• Il limite serve a evitare il “sea surf” (Cross Site Forgery)
www.xedotnet.org 7

8. Cross Domain Table
Classe Image, classe
MediaElement per
Classi WebClient e File dei tipi di
download progressivi File di origine XAML Flussi multimediali
HTTP carattere
(supporti, immagini,
ASX e così via)
Allowed schemes HTTP, HTTPS HTTP, HTTPS, FILE HTTP, HTTPS, FILE HTTP, HTTPS, FILE HTTP
Non consentito da
Cross-scheme access Non consentito Non consentito Non consentito No
HTTPS
Richiede un file dei
criteri di protezione. Consentito se diverso Consentito se diverso Consentito se diverso
Cross-domain access Non consentito
Non consentito per da HTTPS da HTTPS da HTTPS.
HTTPS.
Non consentito da Non consentito da Non consentito da Non consentito da Non consentito da
Cross-zone access (on
un'area Internet ad un'area Internet ad un'area Internet ad un'area Internet ad un'area Internet ad
Windows)
aree più restrittive. aree più restrittive. aree più restrittive. aree più restrittive. aree più restrittive.
Consentito allo stesso
sito e schema. Consentito alla stesso
Redirection allowed Consentito tra domini schema e a siti uguali Non consentito Non consentito Non consentito
solo con un file dei o diversi.
criteri di protezione.
www.xedotnet.org 8

9. Cross Site Forgery
» Cross Site Forgery
Il client chiede una pagina
Nella pagine viene inserito un url malizioso (es. Immagine)
L’url viene richiamato dal client inviando i cookie etc...
Se l’utente casualmente si era autenticato ad un
sito privato l’url può causare operazioni illecite
Gli uri devono essere esplicitamente
autorizzati con delle policy
www.xedotnet.org 9

10. Cross Domain Policies
» Cross Domain Policies
• Il plugin si aspetta che a fianco ai file scaricabili sia disponibile
un file di policy
• clientaccesspolicy.xml
• crossdomain.xml (compatibile flash)
• Se non trova almeno un file di policy solleva un’eccezione...
• http://domain:port/downloads/file.xml
• http://domain:port/clientaccesspolicy.xml
• http://domain:port/crossdomain.xml
• In caso di Servizi non IIS hosted e Socket occorre esporre un
metodo per leggere il file di policy
www.xedotnet.org 10

11. Cross Domain Policies
» clientaccesspolicy.xml
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="*" />
</allow-from>
<grant-to>
<resource path="/files.ashx" include-subpaths="false" />
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
N.B: E’ bene specificare sempre le policy il più possibile restrittive soprattutto in grant-to
www.xedotnet.org 11

12. Programming Model
» Programming Model
• L’accesso alla rete da Silverlight 2.0 è esclusivamente
Asincrono
• Il modello sincrono avrebbe causato problemi di “freeze”
del browser
• La programmazione Asincrona complica un po’ il codice
• L’uso accorto di delegate e lambda expression consente
di semplificare di molto
www.xedotnet.org 12

13. Asyncronous Tip #1
» Semplificare il codice
• Nel framework è presente la classe Action<T>
(parente di Func<T>)
• Possiamo specificare dei delegate che eseguano
semplici operazioni in risposta
public DownloadFile(
int id,
Action<string> success,
Action<Exception> fail)
www.xedotnet.org 13

14. Asyncronous Tip #2
» Thread Marshaling
• La programmazione asincrona implica l’uso di Thread
• Il rientro dalla callback avviene in un thread diverso da quello
della UI
• Per evitare UnauthorizedAccessException bisogna fare il
“marshaling”
www.xedotnet.org 14

15. Asyncronous Tip #2
» Tecniche di sincronizzazione
• Uso di Dispatcher.BeginInvoke()
• Richiede sempre un riferimento ad un UIElement
• Uso problematico perchè non è possibile verificare se si è realmente in un
thread separato: In questo caso fallisce senza senza eccezioni
• Uso di SynchronizationContext.Current
• Ritorna “null” se si è in un thread separato
• Si può usare solo all’interno del Thread della UI
• Uso di AsyncOperationManager
• Non necessita di un “riferimento” ad un UIElement
• Utile per sincronizzare all’interno di classi di business prima di chiamare
un delegate o sollevare un evento.
www.xedotnet.org 15

16. HttpWebRequest
» HttpWebRequest & HttpWebResponse
• Utile per avere il massimo controllo sul protocollo.
• Consente di forgiare la richiesta per esigenze speciali
• Consente di specificare header e di fare upload di file
• Attenzione: Richiede il marshaling del thread nella risposta
www.xedotnet.org 16

17. WebClient
» WebClient
• Si tratta della classe più “comoda” per fare download
• E’ meno generica e ha dei metodi specifici per determinate
esigenze
• DownloadStringAsync
• OpenReadAsync
• OpenWriteAsync
• UploadStringAsync
• Consente di specificare gli header
• Consente di avere notifiche sul progredire del download
• Non richiede sincronizzazioni di thread
www.xedotnet.org 17

18. WebServices
» Accesso a Web Services
• Si tratta sicuramente di uno dei metodi preferenziali per l’accesso ai dati
• Il proxy maschera il processo di comunicazione
• La serializzazione/deserializzazione sono già implementate
• Per accedere a ASMX e WCF si deve usare BasicHttpBinding
• Sono supportati CustomBinding e PollingDuplexHttpBinding
• Non è direttamente supportato WebHttpBinding ma lo si può usare
mediante WebClient
• Solo Trasporto HTTP (no binary)
• Non richiede sincronizzazione di thread
www.xedotnet.org 18

19. WebServices
» Supporto ai protocolli
• Supporta solo WS-I Basic Profile 1.0 e in particolare SOAP 1.1
• I principali protocolli WS-* non sono disponibili
• WS-Security non è direttamente supportato ma si possono iniettare gli
header manualmente
• L’uso di cookie e altri metodi di autenticazione è gestito dal browser
• Non è possibile accedervi da Silverlight
• Per questo è sconsigliabile ospitare i servizi in-domain nel sito che li utilizza
www.xedotnet.org 19

20. WebServices
» Serializzazione / Deserializzazione
• Oggetti complessi come i DataSet non sono supportati. Se un
servizio li espone si deve manipolare direttamente l’XML
• Alcune classi particolarmente complesse (ad esempio quelle
che implementano ISerializable) potrebbero non essere
deserializzabili
www.xedotnet.org 20

21. ADO.NET Data Services
» Accesso a Servizi REST
• Silverlight supporta ADO.NET DataServices (già “Astoria”)
• Un DataService incapsula un modello ad oggetti di Entity
Framework oppure una propria classe
• Grazie ad essi è possibile usare LINQ nelle applicazioni
Siverlight
• Il modello Asincrono complica un po’ le cose
• C’è qualche limite nella complessità dell’ObjectModel
www.xedotnet.org 21

22. ADO.NET Data Services
» Cos’è REST?
• Indirizzo
• Uri della risorsa cui si vuole accedere
• Azione
• Attività da svolgere: GET, POST, PUT, DELETE
• Rappresentazione
• Modalità con cui si desidera accedere alla risorsa
(AtomPub o JSON)
www.xedotnet.org 22

23. Socket
» Uso dei Socket
• E’ utile in scenari dove si riceva un flusso di dati costante
• E’ possibile per mezzo della classe Socket
• E’ disponibile solo il protocollo TCP (no UDP)
• Il set di porte va dalla 4502 alla 4534
• Si usa un meccanismo a “rilancio” con SocketAsyncEventArgs
• SocketAsyncEventArgs contiene lo stato attuale del socket quindi
ne deve essere usata una distinta per ogni Socket creato
www.xedotnet.org 23

24. Socket Server
» Socket Server
• Occorre gestire attraverso il canale la richiesta di
clientaccesspolicy.xml
• Il client invia la richiesta “<policy-file-request/>”
• Il file clientaccesspolicy.xml ha una apposita sezione
<policy>
<allow-from>
<domain uri="file:///" />
</allow-from>
<grant-to>
<socket-resource port="4502-4506" protocol="tcp" />
</grant-to>
</policy>
www.xedotnet.org 24

25. Polling Duplex
» PollingDuplexHttpBinding
• Il polling è un metodo alternativo per raccogliere informazioni
che cambiano continuamente
• Dalla Beta 2 è stato introdotto un nuovo binding in WCF per
supportare questo scenario
• Il meccanismo implica l’uso di un Callback Contract
• E’ nettamente più efficiente di un polling “handmade”
• E’ un po’ complesso da configurare
www.xedotnet.org 25

26. Polling Duplex
» Come funziona PollingDuplexHttpBinding?
• In un polling classico il client è sempre disconnesso salvo il tempo
necessario alla richiesta
• Con il polling duplex il client è sempre connesso salvo il tempo di
recuperare il timeout
• Il server mantiene la connessione in uno stato di attesa fintanto
che non arriva qualcosa da inviare al client o il timeout
• I vantaggi:
• C’è un solo processo di lavoro che notifica tutti i client
• I client vengono aggiornati non appena il dato è disponibile
• Tutti i client sono sincronizzati
www.xedotnet.org 26

27. Polling Duplex
» Callback Contract
• Il duplex implementa Async Pattern
• Il client deve esporre un proprio contratto che verrà usato dal
server per notificare gli eventi
• Il server usa l’OperationContext per recuperare l’istanza del
contratto di callback e la memorizza
www.xedotnet.org 27

28. Polling Duplex
» PollingDuplexHttpBinding Server
• Il server è molto complesso
• Mantiene un’anagrafica dei client connessi
• Gestisce la concorrenza tra richieste e risposte
• Gestisce il Fault dei canali per capire le disconnessioni
• Lavora in background per decidere se notificare i client
• Se non è ospitato da IIS:
• Implementa un ServiceHost
• Implementa un metodo per restituire le policy
www.xedotnet.org 28

29. Consumare i dati
» Deserializzazione XML
• XamlReader
• Utile per caricare on-demand “pezzi” di User Interface
• XmlSerializer
• Quando si deve caricare una gerarchia di oggetti completa
• XDocument
• Quando è necessario accedere a pochi valori in un documento XML
• Syndication
• Quando si devono consumare feed RSS 2.0 o ATOM 1.0
27/02/2009 www.xedotnet.org 29

30. » JavaScript Object Notation
• Se si ha bisogno di un flusso di dati molto compatto JSON è l’ideale
• System.Json
• Usa una gerarchia di oggetti che rappresenta gli elementi della
notazione. Ha il difetto di non essere strong-typed
• System.Runtime.Serialization.Json.DataContractJsonSerializer
• Consente di serializzare/deserializzare un modello ad oggetti vero e
proprio
27/02/2009 www.xedotnet.org 30

31. www.xedotnet.org 31

32. 27/02/2009 www.xedotnet.org 32

33. Link
Andrea Boschin
Blog: http://blog.boschin.it
E-mail: andrea@boschin.it
Website: http://www.boschin.it
User group: http://www.xedotnet.org
www.xedotnet.org 33

34. » I prossimi Meeting
• WebCongress 2.0
• 27/3/2009 – Università di Pordenone – BOSCHIN, DOTTOR, SENATORE, VERNOLE
• TDD: Test Driven Development
• 3/4/2009 – Mestre, Novotel Castellana – MAURO SERVIENTI
• .NET Micro Framework - (Virtual Meeting)
• 30/4/2009 – Online ore 21:30 – MIRCO VANINI
• NetTiers & Code Generation: Rapid Application Prototyping
• 8/5/2009 – Mestre, Novotel Castellana – DAVIDE SENATORE
• PROGRAMMING WITH C# 3.0
• 5/6/2009 – Mestre, Novotel Castellana – ANDREA DOTTOR
27/02/2009 www.xedotnet.org 34