Asp.Net Web API,                       SignalR, UX: Futur           Thomas Jaskula       Rui Carvalho             Développ...
About                                Talk                    Work                                                @rhwy    ...
Communautés                  Prochaines rencontres:                  13/02 : Agile.Net beer                  21/02 : Alt.N...
API, REAL TIME & UX
à propos de cette sessionDISCLAIMER
USER EXPERIENCE
(re)Evolutions
Evolutions des réseaux
Un monde connecté
Evolution des usages
Toute l’information, tout de suite
Comment répondre à ces évolutions?
S’adapter aux usages
Mettre en place des API        Standardisées        Au coeur de l’application        Simples, autonomes
Communication temps réel       Fournir de l’information < 1s       Frameworks spécialisés       Travailler ses écrans comm...
http://techdays.servicebus.windows.net/demo/test/ASP.NET WEB API
ASP.NET Web Api     • Qu’est-ce qu’une API Web ?          « Une API Web est une interface programmable d’un système exposé...
ASP.NET Web Api     • Origines des API web                                    8571 !      10000                         07...
ASP.NET Web Api / Introduction REST     • Origines des API web                       Usage des protocoles par API         ...
ASP.NET Web Api     • Architectures, protocoles & styles des API       Web          – RPC API XML-RPC              CORBA D...
ASP.NET Web Api     • Architecture Web          – Pensez « Ressources »                                                   ...
ASP.NET Web Api     • D’une architecture web vers un style       d’architecture…       REST              =     Décrit le w...
ASP.NET Web Api     • Contraintes du style architectural REST                                                             ...
ASP.NET Web Api     • Convivialité du Web / Modèle de maturité                       Hypermédias         Niveau 3         ...
ASP.NET Web Api     • Introduction au Framework               • Pourquoi utiliser ASP.NET Web Api ?               • ASP.NE...
ASP.NET Web Api     • Introduction au Framework                               Principales caractéristiques :              ...
ASP.NET Web Api     • Hosting          – Adaptateurs disponibles (indépendant du Framework)             • WebHost (IIS)   ...
ASP.NET Web Api     • Adaptateur Azure Service Bus Relay                  Windows Azure                 IP Public         ...
ASP.NET Web Api     • Hypérmedias          – Pourquoi construire les applications hypermédias ?          – Media types    ...
ASP.NET Web Api     • Résumé          –   Support technologique          –   Performances, extensibilité et monté en charg...
ASP.NET SIGNALR
SignalR?      Runtime     temps réel      pour .Net
SignalR?    Framework      Client(s)      Serveur
De quoi parle-t-on…LE WEB TEMPS RÉEL?
Le web temps réel       Push Serveur       HTTP Streaming/Comet       WebSockets
L’information tout de suite, oui mais…QUEL EST LE PROBLÈME?
Un seul canal universel !               HTTP
HTTP n’est Pas adapté       Le procole est agé       Il n’a jamais été prévu pour ça       Prévu pour fournir des document...
Les fondamentaux HTTP      Le web est stateless      Uniquement Requêtes/Réponses
HTML5 WebSockets ?      Extension de HTTP      Supporte les proxies      Canaux binaires bi-directionels
HTML5 WebSockets ?      Spécification instable      Support Serveur/Navigateur aléatoire      Protocole applicatif à écrire!
Quelles Alternatives aujourd’hui?        Short polling        Long polling        Forever frame
Short polling                Event
Long polling               Event
Forever frame                            1                            HTTP/1.1 200 OK                            2        ...
Que choisir?       Aucun n’est particulièrement meilleur       Tous       Avantages différents en fonction du navigateur
SignalR !        Il prend en compte toutes ces techniques        S’adapte en fonction du navigateur        Et du serveur a...
One to rule them allSIGNALR
SignalR          Connection suivant le meilleur transport disponible          Abstraction simple          Modèle de progra...
SignalR          Librairie OSS éprouvée          Microsoft.AspNet.SignalR (nov 2012)          Clients toutes plateforme (J...
SignalR Server       Fonctionne dans toute application ASP.NET       Selft Host       Azure       Mono
SignalR API       Persistent Connections       Hubs
SignalR Persistent Connections       API bas niveau       Programmation connection unique       IHttpHandler + route      ...
SignalR Hubs       API de haut niveau       Abstraction au dessus des PersistentConnections       Proxies auto générés dyn...
ça marche vraiment?PERFORMANCES
SignalR Performances       Très rapide, x18 pour la v1.0       Sur 1 serveur:           250k-500k messages /s           70...
SignalR Performances     les performances dépendent du type de transport     Ralentis requêtes html sur le même serveur   ...
As simple asCODE
SignalR Code : Install        Serveur Web + Clients JS        Client .NetPartie Serveur
SignalR Code : Hub     var hub = $.connection.Notifier;       1      [HubName(“Notifier”)]                                ...
SIGNALR
Résumé• SignalR, framework/Runtime temps réel  .Net web• Modele simple et unifié de programmation  avec les Hub• Abstracti...
QUESTIONS?
https://github.com/codedistillers/talks-td2013https://github.com/tjaskula/ASP.NETWebAPI-Techdays2013SOURCES
Keep contact:@RHWY + @TJASKULA
Asp.Net Web.API, SignalR et UX : le futur
Asp.Net Web.API, SignalR et UX : le futur
Prochain SlideShare
Chargement dans…5
×

Asp.Net Web.API, SignalR et UX : le futur

1 623 vues

Publié le

Dans cette session nous allons voir le futur du développement web au sein de l'écosystème ASP.NET, ce que cela change dans les échanges avec le client, y compris au sein des applications Windows 8 consommant des services. Fournir des web services en plus d'une application est devenu une pratique courante depuis des années, mais travailler avec des APIs en est une autre, et, les fournir dans un mode adapté au Http, comme REST, encore une autre. Il est primordial aujourd'hui d'intégrer ces API proches d'HTTP dans nos applications et c'est là le rôle du framework WEB.API dans la plateforme ASP.NET, que nous allons vous présenter en détail dans cette session. Une autre facette importante des applications web qui a émergé ces dernières années, c'est la contrainte du temps réel. C'est une contrainte qu'il faut prendre en compte dès aujourd'hui. Non pas que tout le monde a besoin d'afficher des flux de données en temps réel, mais surtout parce cela change l'expérience utilisateur! Nous allons voir dans ce cadre là SignalR, une librairie open source, supportée officiellement depuis peu par Microsoft.

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 623
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
53
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Intro code / dev
  • Nous sommes des consultantsindépendants au travers de nossociétésArtOfNet et ComposeIT.Nous fournissonsprincipalement :duconseil en développementd’architectures webdu coaching d’équipes de développement.netdes formations surmesuresur les dernieres technologies web et open sourcevouspouvez nous contacter pour toute question:Ruimail : rui@rui.frtel : 06 10 04 70 40twitter : @rhwyThomas mail : thomas@jaskula.frtel : 06 75 60 19 52twitter : @tjaskulad’iciquelquessemainesvouspourrezretrouvernosoffres de formation surcodedistillers.fr
  • Retrouveznosprochainesrencontresdéveloppeurssurmeetup:www.meetup.com/altnetfrwww.meetup.com/ddd-pariswww.meetup.com/paris-software-craftsmanshipwww.meetup.com/agile-net-france
  • Nous sommes donc réunis ici pour parler de web apis, de framework temps réel mais aussi d’expérience utilisateur. Nous allons voir comment tout cela constitue à notre sens les fondations du web de demain et pourquoi il est impératif de comprendre et maitriser ces concepts tout d’abord puis les technologies qui vont avec.
  • Avant d’aller plus loin nous tenons à émettre un petit avertissement.Nous avons à traiter ici 2 sujets qui auraient pu mériter à eux seuls plusieurs sessions, nous allons nous concentrer ici sur la présentation de ces frameworks afin de vous montrer pourquoi ils sont importants et ce qu’ils apportent.
  • Avant d’aller plus loin dans la technique, il me parait important d’essayer de comprendre ce que celle-ci peut nous apporter.Parlons donc un peu d’expérience utilisateur.
  • Le monde change, cen’est pas nouveau et c’est tout cequ’onluisouhaite, mais le monde de l’information change encore plus vite
  • L’informatique et les réseaux de communications sontrelativementjeunes, maisilsont beaucoup évoluédepuisleur apparition.Nous sommespassésd’une infrastructure trèscentralisée non communiquanteàune infrastructure distribuée de la forme client-serveur pour arriver aujourd’huiàune infrastructure globalementconnectée avec internet. La notion de cloud apparait au sens large du termecommeunesorte de médiauniverselsurlequel tout le monde se connecte. De la mêmemanière de plus en plus de types de clients se connectent, cen’est plus uniquement le pc de bureau, maisaussi le laptop en déplacement, le smartphone et dansl’avenir de plus en plus d’objets du quotidienserontconnectés.Nous avonsdoncbesoinaujourd’hui de faire communiquer ensemble des clients complètementhétérogènes. Dansnos applications on ne peut plus uniquement se contenter de fournir des écransd’information et de saisie et cequelquecesoitce type de client
  • Nous sommes donc dans un monde globalement connecté ou l’information doit circuler vite et où les applications doivent savoir s’adapter aux nouveaux clients
  • Nous sommes passé d’applicationsoùl’on se contentait de vouloir lire des documents statiquesà des applications oul’informationestdynamique et continue commeunepluie de données. Les progrestechnologiques nous permettentaujourd’huid’avoiraccèsàcettespontanéitémaiscen’est pas la seule raison. Il s’agitaussi de fluidifier les expériences. Nous n’utilisons pas les choses de la mêmefaçon, ni ne les apprécions de la meme manièresi le résultatd’une action estimmédiatou pas. Par ex, il y a quelquesannées, je me souviens de me parents qui faisaientleurscomptes au jour le jour et confirmaient tout unefois par mois au moment de la réception du relevé de comptes. Aujourd’hui, on peutvérifier en temps réelsur le net l’état de son compte, on a l’informationimmédiatement, du coup gérermanuellementsesdépenses au quotidiensn’est plus unenécessité. Pareil, on lit peutêtremoins de magazines d’informationaujourd’hui car on se ditquel’informationimprimée sera en retard surcequel’onpeutavoirimmédiatementsur le net. Pourquoiattendred’aller en boutique acheter un cd ou film alorsque je peuxl’avoirimmédiatement en streaming.les usages changent…
  • Lesutilisateursveulentdoncavoirleursinformations tout de suite,nous avonsdéja beaucoup d’exemples du quotidien:- les flux d’informations temps réel, twitter, recherchesinstantanéesles cours des actions,les ventes aux enchèresles scores pendant les évènementssportifsLes notifications temps réelles jeuxinteractifsles applications collaboratives…ou meme simplement un nouvel email!
  • Comment répondreàcesévolutions, comment développer des applications qui s’adaptentàce monde qui change, àcesdifférentsterminaux et àcettedynamique de l’information?
  • Tout d’abordilfaut faire attention aux usages, et aux facteursd’interaction, convivialité ausein de l’interfaceutilisateur. Nous pouvons faire autre chose que des pages web, nous pouvonsréfléchirà la meilleuremanière de rendre un service àvaleurajoutée aux utilisateurs. Les besoins sous-jacent de ceux qui exploitent les données issues des saisies ne sont en général pas du tout les memes que les besoins des utilisateurs.
  • Les apisdoiventêtre le plus standard possiblesafin de faciliter les échanges avec le plus grand nombre de clients potentielsellesdoiventêtres au coeur de l’application. Tout comme les tests unitaires, ilconvient de mettre en place les apis, avant meme l’applicationou au moinsconjointement car ilestsouvent impossible de mettreunecoucheapi par dessusune application web existante.Ellesdoiventêtre simples et autonomes, l’exploitant de ces services n’est pas dans le code de votre application, ilfautqu’ilpuisse les exploiter sans se poser de questions.
  • veuilleznotercetteurl qui sera utilisé plus tarddansunedémo web api.
  • Les web services ontétéutilisédans les entreprisesdepuis des années. Ilspermettentrelativementfacilement de partager et réutiliserunelogique commune avec les différent client comme les appareils mobiles, desktop et web applications. Une API web peutêtre accessible par unevaritété des clients comme les navigateursou les appareils mobilesCela différentie les API Web d’un service SOAP traditionnel qui nécessite les clients spéciaux et une infrastructure et qui ne sont pas proche du fonctionnement d’un navigateur.
  • Années 2000 Salesforce, e-Bay2002 Amazon2004 Flickr2005 32 apis Facebook, Google, Twitter, Linkedin, Microsoft etc. etc. (la révolution commence)2008 1000 (Le web n’est plus ignoré dans le design des API) car SCALE est impacte autrement2012 7000Aujourd&apos;hui 8571
  • Les API traditionnelles del’époqueétaient pour la plupartcréées pour assurer l’intégration des systèmes et baséessur SOAP.Ensuite de nouvelles API utilisées POX (Plain Old XML) comme format d’échange des messages et HTTP commeprotocole. Cela a permisd’atteindreune plus grandevariété des clients.A la fin les entreprise ont pris concience qu’elle ne pouvais pas ingorer le web dans le design des api car cela les empecherai de se étendre et de casser un nombre de clients important.
  • - RPC : Comment un client peutexécuter des procéduresdistantesà travers HTTP ?Problématique : problématiqued&apos;intéropérabilitélié aux différents protocols, TCP, firewalls, caching, encodage des datatypes ASCII, UTF, etc.- Message : Comment un client peutenvoyer des commandes, notifications our d’autres information à un système distant à travers HTTP en évitant le couplagedirecte au procédures RPC distantes ?Problématique : problématiqued&apos;intéropérabilité caching- Resource : Comment un client peutmanipuler les donnéesgérées par un système distant, éviter le couplagedirecte aux procéduresdistantes et minimaliser le besoind’une API centréesur un domainespécifique.
  • Web estorientéressourceURI identifieuniquementuneressource, maisuneressourcepeutêtreidentifiée par plusieurs URIResourceFonctionnalitéapplicatif, document, imprimenteréseau, etc.URIChaque resource estadressable par une URI unique. Scheme, Port, Path, Query (attention car non cachable)* RepresentationCopie de l&apos;étatd&apos;uneressourcedans le temps données != ressource. Le format de la copie et le MEDIA-TYPE (Content-type).
  • Intrigué par la rapidité de développement du Web les chercheurs ont commencé à étudier les raisons de son succèsRoy Fielding a écrit une thèse sur REST http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. Il a décrit les interconnections des ressources, le rôle de leurs identifiant, les opérations et leurs sémantique qui permettent de construire une infrastructure solide qui peut supporter n&apos;importe quelle application.
  • Combien de vous étaient du côté du client et que le serveur a changé et le client a été cassé ?Combien de vous voulez upgrader le serveur mais il fallait contacter tous les client pour qu’il ne soit pas cassés ?
  • * Level 0 servicesURI unique servant à transmettre les enveloppe à la SOAP ignorant tous les autres verbs HTTP. XML-RPC, POX. Une seule large ressource qui fait le dispatch* Level 1 servicesBeacoup de URI mais uniquement un verbe HTTP. Les noms d&apos;opérations sont insérées dans URL (URL tunneling). Plusieurs ressources logiques* Level 2 servicesService contient beaucoup de ressources qui sont identifiable avec les URI et les verbs HTTP sont utilisés pour réaliser les opérations les plus souvent CRUD.* Level 3 servicesHATEOAS
  • Pour construire des applications ayant besoin de services communicant par le biais du protocole HTTP.Les applications HTMLLes applications mobilesLes applications desktop client serveur WCF était suffisant dans un environnement contrôlé de l&apos;entreprise mais pas à l&apos;échèle mondiale où le nombre de clients et leurs types ne sont pas connus d&apos;avance.WCF : si l&apos;environnement est contrôlé, si on est limité au framework .NET 3.5, si on a besoin d&apos;exposer les service SOAP. Mais il est possible de faire un service basé sur HTTP.ASP.NET Web API =&gt; investissement de MS sur le protocole HTTP et REST contrairement à WCF où les investissement sont réalisée ailleurs.
  • Pour construire des applications ayant besoin de services communicant par le biais du protocole HTTP.Les applications HTMLLes applications mobilesLes applications desktop client serveur WCF était suffisant dans un environnement contrôlé de l&apos;entreprise mais pas à l&apos;échèle mondiale où le nombre de clients et leurs types ne sont pas connus d&apos;avance.WCF : si l&apos;environnement est contrôlé, si on est limité au framework .NET 3.5, si on a besoin d&apos;exposer les service SOAP. Mais il est possible de faire un service basé sur HTTP.ASP.NET Web API =&gt; investissement de MS sur le protocole HTTP et REST contrairement à WCF où les investissement sont réalisée ailleurs.
  • OOTB : - IIS Hosting (HttpControllerHandler) - Self Hosting (basé sur WCF SELF hosting)La couche de hosting est un « Adaptatrur » entre Web Api architecture et une infrastructure de hosting physique.Responsabilité : - Quand la requête arrive (un callback a été enregistré), transformer la représentation native de la requête provenant de l’infrastructure en HttpRequestMessage - Quand la réponse est générer transformer HttpResponseMessage en la représentation native de la réponse d’infrastructure du hôte.
  • OOTB : - IIS Hosting (HttpControllerHandler) - Self Hosting (basé sur WCF SELF hosting)La couche de hosting est un « Adaptatrur » entre Web Api architecture et une infrastructure de hosting physique.Responsabilité : - Quand la requête arrive (un callback a été enregistré), transformer la représentation native de la requête provenant de l’infrastructure en HttpRequestMessage - Quand la réponse est générer transformer HttpResponseMessage en la représentation native de la réponse d’infrastructure du hôte.
  • Pourquoi construire les applications hypermédias ?Le client n&apos;a pas besoin de mémoriser toutes les ressources possibles et leur emplacement &apos;URL&apos; car le serveur est en charge de les générer.Le serveur peut changer l&apos;emplacement des ses ressources et donc si le client mémorise l&apos;URL celle-ce ne sera plus valide.Le serveur contrôle le workflow et l&apos;enchainement de ressources car il génère le liens disponibles vers d&apos;autres ressources en fonction de l&apos;état actuel de la ressource. Si par exemple le bon de commande a un état &apos;Annulé&apos; alors le client ne devrait pas pouvoir valider ce bon de commande (le lien ne sera pas présent).Media typesles plus populaires sont JSON et XML mais présente quelques limitations pour répresenter les liens et les forms comme HTML.Il es possible de définir ses propres liens et form mais le client doit comprendre la sémantique pour les interpréter.XHTML et ATOM HAL (http://stateless.co/hal_specification.html) étend JSON et XML pour exprimer les liens vers les ressourceset les forms ?Pour Json il y a une specification non officielle peu supportée http://json-schema.org.
  • Performance : Il y a meilleurs protocoles que HTTP qui est basé sur le text, synchrone, et requête/réponse comportement. MAIS HTTP = application sémantics(GET = caching, latence réduite, extensibilité horisentale)Faible couplage: Web n’embarque pas dans son stack architectural et technologique les notions comme : QOS, consistance de donnée, transactions, intégrité référentielle, statefulness, etc. Le progres peut se faire par le biais de HttpCodesWorkflow métier: pas besoin de BPEL ou WS-Choreography
  • Notes : pas de énormément de commentaires pour la partiesignalrmais beaucoup de slides en compensation ;-)
  • - Le client lance unerequêteàintervalesréguliésdéfinisle serveurrépondimmédiatementàcetterequetesiévènement arrive sur le serveur entre deuxrequetesildoit la garder en mémoire pour la renvoyerà la prochainerequête.
  • - On lance unerequêteLe serveur ne répondquequandil a unedonnéeàrenvoyeroualors au bout d’un temps définisiil ne s’estrien passéle client relanceunerequêtedèsqu’ilreçoit la connection du serveurLimite le traffic maiscelaconsomme des ressources de connection et de cpu (mêmesiellessont plus limitées en async)
  • on place uneiframedans la page avec laquelle on souhaitecommuniquerle source de cetteiframeest un fichier qui sera interprétécomme du javascriptle code javascriptestlu par le client et executé au fur et àmesure de son téléchargementle serveur ne vajamais dire au client qu’illuienvoie la fin du fichierilpousserachaquefoisqu’il aura besoin les donnéesnécédessaires sous forme de code javascriptOblige àgarderune connection active
  • Asp.Net Web.API, SignalR et UX : le futur

    1. 1. Asp.Net Web API, SignalR, UX: Futur Thomas Jaskula Rui Carvalho Développeur Développeur Compose IT ArtOfNet @tjaskula @rhwyCode / Développement
    2. 2. About Talk Work @rhwy @tjaskula ArtOfNet FormationsBlog codedistillers.fr En> www.codedistillers.com skill-track.fr Fr > www.rui.fr
    3. 3. Communautés Prochaines rencontres: 13/02 : Agile.Net beer 21/02 : Alt.Net Frameworks .Net oss 26/02 : Vue d’ensemble du DDD 27/02 : Alt.Net Coding breakfast Paris Software Craftsmanship xx/05 : Web.Net conf Paris ! Community www.meetup.com /ALTNETFR /DDD-Paris /paris-software-craftsmanship /AGILE-NET-FRANCE
    4. 4. API, REAL TIME & UX
    5. 5. à propos de cette sessionDISCLAIMER
    6. 6. USER EXPERIENCE
    7. 7. (re)Evolutions
    8. 8. Evolutions des réseaux
    9. 9. Un monde connecté
    10. 10. Evolution des usages
    11. 11. Toute l’information, tout de suite
    12. 12. Comment répondre à ces évolutions?
    13. 13. S’adapter aux usages
    14. 14. Mettre en place des API Standardisées Au coeur de l’application Simples, autonomes
    15. 15. Communication temps réel Fournir de l’information < 1s Frameworks spécialisés Travailler ses écrans comme de vrais applications
    16. 16. http://techdays.servicebus.windows.net/demo/test/ASP.NET WEB API
    17. 17. ASP.NET Web Api • Qu’est-ce qu’une API Web ? « Une API Web est une interface programmable d’un système exposé sur HTTP et accessible par des méthodes HTTP standard ».Code / Développement
    18. 18. ASP.NET Web Api • Origines des API web 8571 ! 10000 07/02/2013 8000 6000 4000 2000 0 2001 2008 2000 2002 2003 2004 2005 2006 2007 2009 2010 2011 2012 2013 *source : http://www.programmableweb.comCode / Développement
    19. 19. ASP.NET Web Api / Introduction REST • Origines des API web Usage des protocoles par API 5% 2% REST 24% SOAP JavaScript 69% XML-RPC *source : http://www.programmableweb.com 07/02/2013Code / Développement
    20. 20. ASP.NET Web Api • Architectures, protocoles & styles des API Web – RPC API XML-RPC CORBA DCOM WSDL – Message API SOAP POX – Ressource API ATOM RESTCode / Développement
    21. 21. ASP.NET Web Api • Architecture Web – Pensez « Ressources » Représentation XHTML Content-Type : application/xhtml+xml URI Représentation JSON http://api.demo/order/1234 Content-Type : application/json http://api.demo/order/1234.js p Représentation PDF Content-Type : application/pdf Ressource urn:api.demo:order:1234 Représentation TEXT Content-Type : text/plain ftp://demo/order/1234.txtCode / Développement
    22. 22. ASP.NET Web Api • D’une architecture web vers un style d’architecture… REST = Décrit le web comme une application ressources laquelle les représentations hypermédia liées communiquent en échangent les de ressources. distribuée dans http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htmCode / Développement
    23. 23. ASP.NET Web Api • Contraintes du style architectural REST Vous obtenez ces REST Contrainte Vous n’adhérez pas Bénéfice bénéfices si vous à ça… Et vous n’aurez pas utilisés HTTP Client - Server ça ! - Portabilité UI - Serveur simplifié Si vous ne faites comme protocole depas ça… votre Stateless - - Serveur simplifié Extensibilité application - Fiabilité Optional non-shared caching - - Latence réduite Efficacité Sous-contraintes: - Extensibilité Uniform interface - Visibilité - identification des ressources - Evolution Indépendante - Implémentation découplée - Manipulation via représentations - Messages auto-descriptifs Layered system - - Cache partage Clients simplifiés - Hypermédias - Load balancing et extensibilité Code-on-demand - - Clients simplifiés ExtensibilitéCode / Développement
    24. 24. ASP.NET Web Api • Convivialité du Web / Modèle de maturité Hypermédias Niveau 3 HTTP Niveau 2 URI Niveau 1 Niveau 0 Leonard Richardson http://www.crummy.com/writing/speaking/2008-QCon/Code / Développement
    25. 25. ASP.NET Web Api • Introduction au Framework • Pourquoi utiliser ASP.NET Web Api ? • ASP.NET Web Api vs. ASP.NET MVC • Et le WCF dans tout ça ?Code / Développement
    26. 26. ASP.NET Web Api • Introduction au Framework Principales caractéristiques : - Support complet HTTP - Content-negotiation - Tests unitaire - Indépendance de hostingCode / Développement
    27. 27. ASP.NET Web Api • Hosting – Adaptateurs disponibles (indépendant du Framework) • WebHost (IIS) • SelfHost (Process Windows) – Adaptateurs personnalisés • Azure • In-Memory • OWINCode / Développement
    28. 28. ASP.NET Web Api • Adaptateur Azure Service Bus Relay Windows Azure IP Public Service Bus Nom DNS Public Relay API Host Client API NAT Firewall IP Privé Pas de nom DNSCode / Développement
    29. 29. ASP.NET Web Api • Hypérmedias – Pourquoi construire les applications hypermédias ? – Media types • XML / JSON • XHTML / ATOM • HALCode / Développement
    30. 30. ASP.NET Web Api • Résumé – Support technologique – Performances, extensibilité et monté en charge – Faible couplage – Workflow métierCode / Développement
    31. 31. ASP.NET SIGNALR
    32. 32. SignalR? Runtime temps réel pour .Net
    33. 33. SignalR? Framework Client(s) Serveur
    34. 34. De quoi parle-t-on…LE WEB TEMPS RÉEL?
    35. 35. Le web temps réel Push Serveur HTTP Streaming/Comet WebSockets
    36. 36. L’information tout de suite, oui mais…QUEL EST LE PROBLÈME?
    37. 37. Un seul canal universel ! HTTP
    38. 38. HTTP n’est Pas adapté Le procole est agé Il n’a jamais été prévu pour ça Prévu pour fournir des documents liés
    39. 39. Les fondamentaux HTTP Le web est stateless Uniquement Requêtes/Réponses
    40. 40. HTML5 WebSockets ? Extension de HTTP Supporte les proxies Canaux binaires bi-directionels
    41. 41. HTML5 WebSockets ? Spécification instable Support Serveur/Navigateur aléatoire Protocole applicatif à écrire!
    42. 42. Quelles Alternatives aujourd’hui? Short polling Long polling Forever frame
    43. 43. Short polling Event
    44. 44. Long polling Event
    45. 45. Forever frame 1 HTTP/1.1 200 OK 2 1 2 3 <script>eval(“{id:’1’}”)</script> 3 <script>eval(“{id:’2’}”)</script> Event Event [ . . .]
    46. 46. Que choisir? Aucun n’est particulièrement meilleur Tous Avantages différents en fonction du navigateur
    47. 47. SignalR ! Il prend en compte toutes ces techniques S’adapte en fonction du navigateur Et du serveur automatiquement Abstraction de programmation
    48. 48. One to rule them allSIGNALR
    49. 49. SignalR Connection suivant le meilleur transport disponible Abstraction simple Modèle de programmation unique
    50. 50. SignalR Librairie OSS éprouvée Microsoft.AspNet.SignalR (nov 2012) Clients toutes plateforme (JS, .Net, WinRT, iOS,…) Server + WebSockets IIS8
    51. 51. SignalR Server Fonctionne dans toute application ASP.NET Selft Host Azure Mono
    52. 52. SignalR API Persistent Connections Hubs
    53. 53. SignalR Persistent Connections API bas niveau Programmation connection unique IHttpHandler + route Limité aux messages Le protocole doit être défini
    54. 54. SignalR Hubs API de haut niveau Abstraction au dessus des PersistentConnections Proxies auto générés dynamiques (JS ou .NET) Routes automatiques (/signalr/hubs) Tout types d’échanges, riches
    55. 55. ça marche vraiment?PERFORMANCES
    56. 56. SignalR Performances Très rapide, x18 pour la v1.0 Sur 1 serveur: 250k-500k messages /s 70k connections simultannées
    57. 57. SignalR Performances les performances dépendent du type de transport Ralentis requêtes html sur le même serveur Attention au traitement (Cpu)
    58. 58. As simple asCODE
    59. 59. SignalR Code : Install Serveur Web + Clients JS Client .NetPartie Serveur
    60. 60. SignalR Code : Hub var hub = $.connection.Notifier; 1 [HubName(“Notifier”)] public class MyHub : Hub { $.connection.hub.start().done(function () { public void Notify(string message) $(#btn).on(click,function(){ 2 { hub.server.notify( Clients.Others.notified(message); $(#messageInput).val()); } }) } 3 }); hub.client.notified = function (message) { alert(message.Content); RouteTable.Routes.MapHubs(); }; Client ServerPartie Cliente
    61. 61. SIGNALR
    62. 62. Résumé• SignalR, framework/Runtime temps réel .Net web• Modele simple et unifié de programmation avec les Hub• Abstraction du transport• Tous types de clients
    63. 63. QUESTIONS?
    64. 64. https://github.com/codedistillers/talks-td2013https://github.com/tjaskula/ASP.NETWebAPI-Techdays2013SOURCES
    65. 65. Keep contact:@RHWY + @TJASKULA

    ×