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.
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. 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.com
Code / Développement
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/2013
Code / Développement
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 REST
Code / Développement
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.txt
Code / Développement
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.htm
Code / Développement
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. 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. 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. ASP.NET Web Api
• Introduction au Framework
Principales caractéristiques :
- Support complet HTTP
- Content-negotiation
- Tests unitaire
- Indépendance de hosting
Code / Développement
27. ASP.NET Web Api
• Hosting
– Adaptateurs disponibles (indépendant du Framework)
• WebHost (IIS)
• SelfHost (Process Windows)
– Adaptateurs personnalisés
• Azure
• In-Memory
• OWIN
Code / Développement
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 DNS
Code / Développement
29. ASP.NET Web Api
• Hypérmedias
– Pourquoi construire les applications hypermédias ?
– Media types
• XML / JSON
• XHTML / ATOM
• HAL
Code / Développement
30. ASP.NET Web Api
• Résumé
– Support technologique
– Performances, extensibilité et monté en charge
– Faible couplage
– Workflow métier
Code / Développement
54. SignalR Persistent Connections
API bas niveau
Programmation connection unique
IHttpHandler + route
Limité aux messages
Le protocole doit être défini
55. 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
64. 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
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
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'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'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'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'étatd'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'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'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'entreprise mais pas à l'échèle mondiale où le nombre de clients et leurs types ne sont pas connus d'avance.WCF : si l'environnement est contrôlé, si on est limité au framework .NET 3.5, si on a besoin d'exposer les service SOAP. Mais il est possible de faire un service basé sur HTTP.ASP.NET Web API => 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'entreprise mais pas à l'échèle mondiale où le nombre de clients et leurs types ne sont pas connus d'avance.WCF : si l'environnement est contrôlé, si on est limité au framework .NET 3.5, si on a besoin d'exposer les service SOAP. Mais il est possible de faire un service basé sur HTTP.ASP.NET Web API => 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'a pas besoin de mémoriser toutes les ressources possibles et leur emplacement 'URL' car le serveur est en charge de les générer.Le serveur peut changer l'emplacement des ses ressources et donc si le client mémorise l'URL celle-ce ne sera plus valide.Le serveur contrôle le workflow et l'enchainement de ressources car il génère le liens disponibles vers d'autres ressources en fonction de l'état actuel de la ressource. Si par exemple le bon de commande a un état 'Annulé' 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