Slverlight Networking (Andrea Boschin)
- 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: [email protected] 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
Editor's Notes
- #3: In questo meeting sarà mio incarico parlarvi di Silverlight 2.0, e in particolare di Networking. Non sarà un meeting in cui parleremo diffusamente delle caratteristiche più sceniche di Silverlight, ma piuttosto cercherò di essere molto pratico e arricchirò spesso e volentieri il mio racconto di esempi di codice che vi chiariscano i concetti che esprimo. Cos’è Silverlight in due parole? Silverlight è un plugin per i più comuni browser, Ie, FF, safari e per le più comuni piattaforme, ma si connota più come una piattaforma per lo sviluppo di applicazioni che per semplici scene interattive. (vedere http://www.mscui.net/PatientJourneyDemonstrator/
- #6: Tre modi per accedere alla rete:XmlHttpRequest, API del browser, accesso diretto alle API di networking (bypass)