WebApps gagnées par le temps-réel : un plan sur la Comet ? Par Kadda SAHNINE Publié le | novembre 6, 2009 | En l’espace de quelques années, les applications web se sont imposées comme un référent technologique absolu pour la plupart des systèmes et logiciels informatiques. A partir d’un langage de description de document (X/HTML) associé à un protocole de requête/réponse sans état (HTTP), web designer, développeurs et architectes techniques ont produit de solides applications issues de composants de base en définitive assez élastiques.
Au gré des innovations successives, des frameworks ont permis d’organiser les développements et surtout d’imposer un paradigme de programmation masquant la rusticité induite par les molécules du web : HTML et HTTP. En dépit ce cette rusticité, on assiste depuis quelques années à l’apparition d’applications web intégrant des fonctionnalités temps-réel : messageries instantanées, plateformes sociales ou applications financières en sont des exemples emblématiques. Du polling à Comet Le protocole de Bayeux Code HTML : Après Ajax, le «Reverse Ajax»… et le Grizzly ! - » Encore plus fort ! Ce n’est plus ton browser qui demande de l’information. C’est ton serveur qui lui remonte, lui push de l’information et le tout en technologie web ! » - » oulà, oulà…tu ne serai pas en train de me prendre pour un gars sorti de sa campagne toi ?!
« En fait, si un peu mais pas tant que ca non plus ;-) Le besoin est réel et tend à se démocratiser sur le web : informer l’utilisateur de la modification d’information au niveau du serveur, en (quasi) temps réel. Il existe 3 solutions pour » remonter » de l’information au client L’élément différentiant entre ces solutions reste la fréquence de mise à jour de la donnée et l’importance qu’à la fraîcheur de cette donnée pour le client.
Comet ou le « long polling » In web development, Comet is a neologism to describe a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it Tomcat 6 propose les NIO – advanced IO. Mise en oeuvre… Comet : Se passer de bayeux ? Comet, c'est toute une galaxie en mouvement. Dans un des billets précédents je saluait les avancées qui se faisaient en ce qui concerne le javascript coté serveur notamment pour implémenter du Comet dans nos applis web.Je découvrais également node.js. La façon la plus populaire actuellement de faire du Comet et d'implémenter le protocole de Bayeux. C'est ce que fait la librairie Faye pour Node.js mais ausi ce que fait CometD pour Jetty et autres (cf Sans renier l'énorme potentiel de node.js (c'est tout simplement hallucinant toutes les portes que ca ouvre), je me suis longuement interrogé sur la pertinence du protocole de Bayeux.
J'ai ensuite découvert, toujours grâce au site comet daily, HookboxHookbox’s purpose is to ease the development of real-time web applications, with an emphasis on tight integration with existing web technology. Hoobook n'implémente pas Bayeux... c'est peut être tant mieux ! Bonne lecture. The Bayeux Protocol. Status of this Memo This document specifies a protocol for the Internet community, and requests discussion and suggestions for improvement. This memo is written in the style and spirit of an IETF RFC but is not, as of yet, an official IETF RFC. Distribution of this memo is unlimited. This memo is written in UK English. Copyright Notice Copyright © The Dojo Foundation (2007).
Abstract Bayeux is a protocol for transporting asynchronous messages (primarily over HTTP), with low latency between a web server and web clients. 1.1. The primary purpose of Bayeux is to support responsive bidirectional interactions between web clients, for example using using AJAX, and the web server. Bayeux is a protocol for transporting asynchronous messages (primarily over HTTP), with low latency between a web server and a web client. Server to clientclient to serverclient to client (via the server) By default, publish subscribe routing semantics are applied to the channels. 1.2. 1.3. Client server request response event. Comet | Wiki. Un article de Wikipédia, l'encyclopédie libre. Pour les articles homonymes, voir Comet.
Comet est une nouvelle approche permettant à un serveur web d'envoyer des informations au navigateur web sans que celui-ci l'ait explicitement demandé. Ce canal bidirectionnel est un ensemble de deux connexions duales HTTP non-fermées. Cette approche diffère amplement du modèle classique du web dans lequel toute interaction avec le serveur est initiée par le navigateur. Cette nouvelle approche, parfois comparée à Ajax, ouvre de nouvelles perspectives pour les applications Internet de nouvelle génération.
Les produits suivants implémentent ce concept : L'API Grizzly (fournie entre autres avec GlassFish)Le Framework Open Source ASP.NET SignalR de Microsoft.Le serveur web embarqué Smews (développé par l'équipe 2XS au LIFL) Portail d’Internet. JSON : JavaScript Object Notation | Wiki. JSONJavaScript Object Notation logo du format JSON JavaScript Object Notation (JSON) est un format de données textuelles dérivé de la notation des objets du langage JavaScript. Comme le XML, il permet de représenter de l’information structurée[1]. Créé par Douglas Crockford entre 2002 et 2005[2], la première norme du JSON est ECMA-404 qui a été publiée en octobre 2003[3], il est actuellement décrit par les deux normes en concurrence : RFC 8259 de l’IETF et ECMA-404[4] de l'ECMA.
Des bibliothèques pour le format JSON existent dans de nombreux langages de programmation[6]. Caractéristiques[modifier | modifier le code] Un document JSON comprend[7],[6] : Chacun de ces types peut être utilisé pour constituer un document. Exemple[modifier | modifier le code] Exemple de données au format JSON : Équivalent au format XML : Équivalent au format YAML : menu: id: file value: File popup: menuitem: - value: New onclick: CreateNewDoc() - value: Open onclick: OpenDoc() - value: Close onclick: CloseDoc() Avantages.
SOAP vs REST : choisir la bonne architecture web services. De plus en plus d’entreprises ont besoin de rendre leurs applications accessibles sur le web. Les motivations sont multiples : élargir l’audience des utilisateurs, vendre des services en ligne, faire communiquer des applications existantes ou supporter une interface de type AJAX. Dans ces conditions, quelle architecture choisir ou concevoir ? Quel format utiliser pour échanger des données sur le web ? Et devrait-on utiliser un protocole applicatif existant ou développer un protocole adapté à nos besoins ? Table des matières Introduction Nous parlons ici de mettre en place un protocole applicatif sur le web pour échanger de l’information avec un grand nombre de clients. Le développement de protocoles applicatifs Rendre ses applications accessibles sur le web consiste à définir un protocole applicatif et un format de données.
Nous avons vu que les motivations des entreprises pour déployer des web services aujourd’hui étaient nombreuses. Choisir SOAP ? Alors quel avenir pour SOAP ? Tableau 1. REST : Representational State Transfer | Wiki. Un article de Wikipédia, l'encyclopédie libre. REST (representational state transfer) est un style d’architecture pour les systèmes hypermédia distribués, créé par Roy Fielding en 2000 dans le chapitre 5 de sa thèse de doctorat[1]. REST n’est pas un protocole (tel que HTTP) ou un format. Ce style d'architecture est particulièrement bien adapté au World Wide Web mais n'en est pas dépendant. Les contraintes, telles que définies par Roy Fielding, peuvent s'appliquer à d'autres protocoles d'application que HTTP. Contraintes d'une architecture REST[modifier | modifier le code] Les contraintes sont les suivantes : Client-serveur : les responsabilités sont séparées entre le client et le serveur.
Description de REST[modifier | modifier le code] Confusion entre REST et protocoles[modifier | modifier le code] RPC ainsi que SOAP ne sont pas des styles d'architecture mais des protocoles. Avantages de REST[modifier | modifier le code] Inconvénients de REST[modifier | modifier le code] WSDL : Web Services Description Language | Wiki. Un article de Wikipédia, l'encyclopédie libre. Une représentation des concepts définis par un document WSDL 1.1 WSDL (Web Services Description Language) est une grammaire XML permettant de décrire un service web.
WSDL 1.1 a été proposé en 2001 au W3C pour standardisation. La version 1.1 n'est pas approuvée par le W3C. La version 2.0 a été approuvée le 27 juin 2007 et est désormais une recommandation officielle du W3C. Souvent désigné par WSDL dans les documents techniques (autre prononciation connue : « Whiz-Deul »). Le WSDL décrit une interface publique d'accès à un service web, notamment dans le cadre d'architectures de type SOA (Service Oriented Architecture). Le WSDL sert à décrire : le protocole de communication (SOAP RPC ou SOAP orienté message)le format de messages requis pour communiquer avec ce serviceles méthodes que le client peut invoquerla localisation du service. Le WSDL est principalement soutenu par Ariba, IBM et Microsoft. Articles connexes[modifier | modifier le code] SOAP : Simple Object Access Protocol | Wiki. Un article de Wikipédia, l'encyclopédie libre. Pour l’article homophone, voir S.O.A.P.. SOAP (ancien acronyme de Simple Object Access Protocol) est un protocole de RPC orienté objet bâti sur XML.
Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur. Le transfert se fait le plus souvent à l'aide du protocole HTTP, mais peut également se faire par un autre protocole, comme SMTP. Le protocole SOAP est composé de deux parties : une enveloppe, contenant des informations sur le message lui-même afin de permettre son acheminement et son traitement,un modèle de données, définissant le format du message, c'est-à-dire les informations à transmettre. Le protocole SOAP emploie des métadonnées[2].
SOAP n'est plus un acronyme depuis la version 1.2. Critiques techniques[modifier | modifier le code] Avantages[modifier | modifier le code] Inconvénients[modifier | modifier le code]