Dans la lignée du dossier proposé par 01 Informatique, il est donc intéressant de dresser un petit point sur quelques aspects du Cloud Computing.

Sur la maturité des développeurs et architectes Cloud

Les composants des applications Cloud restent dans l’ensemble similaires à ceux des applications Web traditionnelles : les développeurs techniques peuvent donc généralement monter en compétences rapidement sur les solutions PaaS. Cet aspect est renforcé par le fait que les plateformes Cloud proposent des services techniques classiques : persistance des données, hébergement de l’application, authentification et droits des utilisateurs, intégration…

Le manque de recul concerne en général davantage l’intégration d’une application Cloud dans le SI : par exemple, c’est une chose d’envisager l’externalisation d’une application, mais il faut également être prêt à externaliser ses données. En pratique, c’est plus facile à envisager pour des services annexes ou transverses que pour des services au cœur du métier de l’entreprise. Sans oublier les aspects juridiques largement évoqués dans la presse spécialisée…

Sur les difficultés de mise en œuvre

Développement

Cela varie en fonction des solutions. La solution PaaS de Google, App Engine, par exemple, nous affranchit de nombreuses difficultés côté environnements de développement et déploiement puisqu’on utilise Eclipse et des plugins qui permettent de créer des projets et de les déployer dans l’environnement de test local ou dans les nuages en quelques clics. Par contre, l’environnement de test local est très différent de l’environnement de production, ce qui ne facilite pas les tests et la détection de problèmes en amont.

Et surtout, cette solution implique des changements dans la façon de concevoir l’architecture des applications : par exemple, le datastore nécessite d’implémenter les relations entre les objets et les transactions différemment de nos applications relationnelles traditionnelles. Sans oublier les restrictions sur l’utilisation des ressources : délai maximal de 30 secondes par traitement, récupération d’au plus 1000 entrées par requête dans le datastore…

L’offre IaaS d’Amazon, EC2, à l’inverse, permet la mise en œuvre d’architectures plus classiques mais requiert la manipulation de machines virtuelles sur lesquelles sont déployées les applications.

D’où l’intérêt de surveiller le nouvel arrivant dans la course, Cloud Foundry, de Spring (récemment acquis par VMware). Cette offre PaaS, reposant à l’heure actuelle sur Amazon EC2, se veut justement rendre transparente la manipulation des machines virtuelles tout en permettant des développement plus traditionnels que ceux imposés par Google App Engine.

Entre les différentes solutions, IaaS ou PaaS, le match ne fait donc que commencer. Et le manque de portabilité entre elles ne va pas faciliter le combat !

Exploitation

Le dimensionnement est le premier problème majeur. Derrière l’image de l’opérateur de service à qui on confie l’hébergement de l’application avec la garantie du bon fonctionnement même quand d’importantes montées en charge sont nécessaires, on occulte souvent la nécessité – et la difficulté – de déterminer précisément la quantité de ressources dont on a besoin : en termes de requêtes HTTP entrantes ou sortantes, requêtes en base de données, accès au cache, etc. L’estimation de ces métriques n’est pas simple et ne doit pas être négligée : on délègue certaines tâches d’exploitation, mais celle-ci reste à notre charge.

La seconde problématique majeure (et inhérente) est la tarification : de simples tableaux associant des coûts à des quantités de ressources nous sont présentés mais comment les exploiter si on n’est pas en mesure de dimensionner nos besoins ?

Sur le Cloud et son écosystème

Emergence du Cloud Computing

Deux types d’applications ont largement contribué à l’émergence du Cloud Computing : d’abord les RIA (Rich Internet Applications), applications client/serveur sans déploiement sur les postes client et aux interfaces utilisateurs ergonomiques. Puis les applications Mobiles, sur des appareils comme iPhone ou Android. Le succès de l’App Store d’Apple, impressionnant et grandissant encore, ouvre la voie à des applications utilisées par des dizaines ou centaines de milliers d’utilisateurs à travers le monde, il est donc intéressant de pouvoir bénéficier d’hébergements scalables à moindre coût pour les services métier.

Cloud Computing et SOA

A l’instar de cette excellente image humoristique, j’ai lu plusieurs fois que « le Cloud avait remplacé SOA» . Au niveau marketing, peut-être… Mais aux niveaux opérationnel et technique, le Cloud ne remplace pas SOA, il peut au contraire reposer sur la collaboration entre applications et services.

Sur la notion de service

La définition de la notion de service fait rarement l’unanimité est c’est là le point de départ des incompréhensions autour de SOA. Je choisirai donc ici une définition que je rencontre souvent :

« un service est un ensemble d’opérations mises à disposition par un fournisseur à l’attention d’un consommateur. Ce fournisseur exécute les traitements invoqués par le client consommateur» 

Cette définition présente plusieurs lacunes. Celle qui m’intéresse dans le cadre de cet article est l’absence de référence à la notion de contrat de service. En effet, dans le cadre d’une démarche SOA, la notion de service n’est pas dissociable de la notion de contrat de service car il est nécessaire de formaliser le lien entre fournisseur et consommateur pour faciliter la mise en œuvre du service et sa réutilisation.

Soyons plus optimiste, on trouve parfois dans les définitions de la notion de service une référence à cette notion de contrat de service, formulée de la manière suivante :

« le contrat de service décrit les opérations invocables du service» 

Cette définition floue est heureusement parfois complétée par des précisions intéressantes :

« le contrat de service décrit les opérations invocables du service, c’est-à-dire la signature de ces opérations et les protocoles réseau utilisables» 

Cette dernière définition a beau être plus claire, elle n’en est pas pour autant complète.

Sur la notion de contrat de service

La notion de contrat de service est – et doit être – bien plus précise. En fait, la signature des opérations et les protocoles réseau ne sont que deux aspects d’un contrat. J’aime assez la décomposition suivante d’un contrat, en cinq aspects :

• Sémantique : signification des opérations et de leurs valeurs de retours, pré-conditions, post-conditions…
• Syntaxe : nom et signature des opérations, c’est-à-dire format des paramètres en entrée et en sortie
• Protocoles réseau : ensemble des protocoles réseau utilisables pour invoquer les opérations
• Protocole de conversation : ordre dans lequel les opérations doivent être invoquées
• Niveau de qualité : Qualité de Service (QoS) et Service Level Agreement (SLA), c’est-à-dire garanties en matière de sécurité, fiabilité, disponibilité, performance…

Maintenant que nous avons clarifié la composition d’un contrat de service, qu’en fait-on ?

Sur la formalisation du contrat de service

Un contrat de service peut être formalisé. Un formalisme commun facilite la mise en place et la réutilisation de services. Il existe différentes formes de formalisation et toutes ne sont pas standardisées mais certaines permettent d’automatiser la prise en charge d’un ou plusieurs aspects du contrat. Par exemple :

• Syntaxe et Protocoles réseau : la formalisation de ces aspects peut être exploitée pour générer les stubs côté client. C’est le cas du WSDL pour les Web Services WS-* ou du WADL pour les Web Services REST (enfin, pour ceux qui ne sont pas contre l’utilisation du WADL dans REST, mais ceci est un autre débat !)
• Protocole de conversation : le BPM, grâce à la formalisation standard BPEL, est un excellent exemple d’exploitation automatisée de cet aspect

Notons que les ESB permettent d’exploiter de manière automatisée l’ensemble de la formalisation de contrats, même si l’aspect Niveau de qualité (voir par exemple les couches concernées de la stack WS-*) est plus difficile à exploiter de manière automatisée et l’aspect Sémantique (voir par exemple UDDI) l’est encore plus.

Idée n°1 : Pourquoi l’iPhone n’est pas qu’un énième gadget

L’iPhone a avant tout représenté une curiosité technologique : malgré une sortie officielle en juin 2007, il a alimenté toutes sortes de mystères sur Internet dès la fin de l’année 2005.

L’iPhone n’est pas le premier appareil ayant permis une connexion Internet Edge puis 3G. Mais il est l’initiateur de l’ère des forfaits de données illimités : ces forfaits ont ouvert la voie à de nouvelles applications réellement connectées.

L’iPhone n’est pas non plus le premier appareil ayant proposé un appareil photo/caméra, une puce WiFi, une puce GPS, un accéléromètre et une boussole. Mais l’iPhone est un bijou technologique car son système d’exploitation, iPhone OS, a défini de nouveaux standards en matière de design et d’ergonomie des applications qui exploitent tous ces composants électroniques. Le Multi-Touch en est l’un des éléments essentiels.

C’est ce qui a fait qu’aujourd’hui, après seulement quelques mois, plusieurs millions de personnes utilisent un iPhone au quotidien.

Idée n°2 : Pourquoi l’iPhone n’intéresse pas que le grand public

Au-delà des intérêts techniques que nous venons de mettre en avant, il suffit de jeter un œil aux statistiques pour se rendre compte de l’impact de l’iPhone : plus de 50 millions d’iPhone, iPhone 3G, iPhone 3GS et iPod Touch ont été vendus dans le monde. Rappelons au passage que l’iPod Touch est également équipé de l’iPhone OS.

Les statistiques de l’App Store, seulement lancé en juin 2008, parlent également d’elles-mêmes :

• 77 pays
• 90 000 applications
• 120 000 développeurs
• Plus de 2 000 000 000 téléchargements dont le dernier quart en moins de 3 mois.

Ces chiffres sont uniques, les plateformes Android et Blackberry par exemple ne connaissent pas (encore ?) une telle croissance. Et ces chiffres ne font que croître. Fait significatif, l’App Store supporte parfaitement cette croissance. Cette impressionnante scalabilité de l’App Store en fait une plateforme internationale redoutable.

Un autre chiffre est significatif : 75% des applications présentes sur l’App Store sont payantes. Ce n’est pas le cas sur les plateformes Android et Blackberry, respectivement autour de 25% et 55%.

De là, il n’y a qu’un pas pour qu’une entreprise souhaite distribuer des applications sur l’App Store, pour des raisons marketing et business. Et quand on sait qu’il suffit d’un seul clic sur l’iPhone pour télécharger une application ou un contenu/service additionnel, gratuit ou payant…

Idée n°3 : Comment les entreprises ont fait leur entrée sur l’App Store

La première année d’existence de l’App Store a vu fleurir des applications de deux types :

• Applications de tous genres réalisées par des entreprises ou des particuliers, qui représentent pour la plupart des adaptations Mobiles d’applications Desktop ou Internet classiques : gestionnaires de tâches, viewers de fichiers, lecteurs de flux RSS, jeux, etc.
• Applications vitrines : souvent très (trop ?) simples, il s’agit d’applications réalisées par des entreprises qui ont simplement souhaité être visibles sur l’App Store. A la manière des sites Web à l’époque de la bulle Internet, où une entreprise se devait d’être présente sur le Web afin d’être visible et « dans le coup» .

L’effet vitrine est très important : lors de nos projets, nos clients nous expliquent souvent qu’ils souhaitent être présents sur la plateforme iPhone mais que pour des raisons de coût, ils préfèrent réaliser une application Web customisée pour iPhone pour ensuite voir s’ils passeront à une application native (en cas de succès de cette première étape). La différence de coût est effectivement souvent justifiée car la réalisation d’une application Web nécessite des compétences techniques souvent déjà maîtrisées dans les équipes : il s’agit des compétences Web classiques, HTML, JavaScript et CSS. Alors qu’une application native nécessite des environnements Apple, une connaissance de Cocoa et d’Objective-C, une licence, etc.

Cependant cette séquence « application Web puis éventuellement application native » n’est pas à considérer de manière logique systématiquement : les applications natives sont plus rapides, plus simples et plus réactives que les applications Web, dont l’IHM et les comportements sont bien souvent une pâle imitation de ceux des applications natives. En outre, les applications natives peuvent bénéficier de toutes les caractéristiques de l’appareil, ce qui n’est pas le cas des applications Web. Or toutes ces différences concernent justement l’essentiel des raisons qui font le succès de l’iPhone : le design et l’ergonomie. Les utilisateurs sont donc très exigeants sur ces domaines. Le choix entre développement d’une application native et d’une application Web doit donc être considéré sous cet angle et pas uniquement sous l’angle du coût.

Et le temps accentue cette tendance. Depuis quelques mois, l’App Store voit fleurir des applications qui exploitent pleinement les capacités de l’appareil : connectivité, géolocalisation, réalité augmentée… L’iPhone n’est plus une simple prolongation de nos ordinateurs de bureau, mais une vraie plateforme à part entière avec ses propres innovations.

Idée n°4 : Pourquoi les entreprises ne sont pas obligées de passer par l’App Store pour distribuer des applications

Il s’agit là d’un point essentiel, sur lequel nous sommes souvent questionnés :

• L’App Store est publique : est-il possible de distribuer des applications dans un cadre plus restreint ?
• L’App Store est soumis à des règles strictes et des contraintes : la principale en est la procédure de review par Apple des applications soumises, qui repose sur des critères ergonomiques, fonctionnels et techniques établis mais pas toujours maîtrisables par le non initié, et qui impose des délais légèrement croissants (il faut compter entre une et deux semaines d’attente pour la validation d’une nouvelle version d’une application).

En fait, pour développer des applications sur iPhone, il y a deux étapes.

La première consiste à s’enregistrer auprès d’Apple comme Registered iPhone Developer. Cela vous permet de :

• Accéder à l’iPhone Developer Center, point d’accès central à toutes les ressources nécessaires : SDK, documentation et ressources
• Développer des applications
• Les tester sur le simulateur fourni : attention, pas même sur votre propre iPhone !

C’est tout mais c’est gratuit ! En particulier : à l’issue de cette étape, vous ne pouvez pas distribuer d’application.

La seconde étape consiste à devenir iPhone Development Program Member. Cela vous permet de développer, tester et distribuer des applications, via un portail dédié et intégré dans l’iPhone Developer Center. En fonction du type de licence que vous choisissez, trois modes de distribution s’offrent alors à vous :

• Distribution App Store : déploiement sur une plateforme internationale et publique d’applications gratuites ou payantes
• Distribution Ad-hoc : déploiement sur une flotte constituée de 100 appareils au maximum, référencés
• Distribution In-house : déploiement sur une flotte constituée de 500 appareils au minimum, au sein d’une entreprise.

Et voici les types de licences :

• Licence Standard : 99$ / an
  • Distribution : App Store ou ad-hoc
  • Peut concerner un individuel (1 développeur) ou une société (une équipe de développeurs)
• Licence Enterprise : 299$ / an
  • Distribution : in-house ou ad-hoc

Plusieurs modes de distribution s’offrent donc à vous. Attention à bien choisir la licence adéquate !

Idée n°5 : Attention, réaliser une application iPhone, ce n’est pas « que » faire du développement logiciel

Les développeurs familiers avec les langages comme C++, C# ou Java arriveront à se familiariser avec l’Objective-C. Mais le développement d’une application iPhone requiert d’autres attentions. L’aspect technique est important, mais les deux aspects suivants le sont tout autant, voire plus :

• le marketing : afin de rendre visible l’application
• l’ergonomie : il y a des règles strictes à respecter afin de passer la phase de validation d’Apple puis de satisfaire les utilisateurs, devenus exigeants en la matière. Il ne s’agit plus seulement de créer une application utilisable, mais de créer une application qui propose une réelle expérience utilisateur. La maxime d’Apple « The ’same old’ is not an option anymore»  est de plus en plus d’actualité.

En effet, nombre d’applications aux traits fonctionnels et techniques irréprochables n’ont pas connu le succès escompté tout simplement car les aspects ergonomie et marketing ont été sous-estimés. Notez que j’entends par « succès»  le fait de rendre riche les développeurs de rendre heureux les utilisateurs.

Cette idée pourrait faire l’objet d’un article à part entière, nous n’irons donc pas plus loin (pour l’instant). En attendant, où en êtes-vous de votre côté ?

Principes de base de HTML 5

Jusqu’ici, les langages HTML et XHTML étaient deux langages distincts et définis par leur syntaxe.

La spécification HTML 5 définit un langage unique nommé HTML 5. Ce langage :

• est défini par sa structure DOM (Document Object Model, qui permet de représenter un document par une structure arborescente) et donc indépendamment de la syntaxe ;
• peut être écrit par une syntaxe HTML ou une syntaxe XML : il ne s’agit donc que de deux sérialisations possibles parmi d’autres.

Cette spécification définit de nouveaux éléments, attributs et API plus adaptés aux applications Web, ainsi que des consignes afin d’encourager des implémentations interopérables.

Notez que HTML 5 est conçu pour être compatible avec ses anciennes versions : les navigateurs qui implémenteront la spécification HTML 5 devront toujours être capables d’interpréter les documents HTML plus anciens.

Apports « basiques » de HTML 5

Sémantique

Des éléments ont été ajoutés afin de donner plus de structure aux documents : section, article, aside, header, footer et nav, notamment. Leur nom est explicite quant à leur utilisation.

Ainsi, on utilisera ces éléments natifs plutôt que de donner de la sémantique à des div (par exemple) en leur attribuant des identifiants ou classes CSS particuliers :

<div id="header">

devient :

<header>

L’article http://www.alistapart.com/articles/previewofhtml5 vous fait une excellente présentation de ces éléments.

HTML 5 fournit également un élément dialog pour représenter une discussion, ainsi qu’un élément figure permettant d’ajouter un titre à un élément donné (une image, par exemple).

Contrôles

Plusieurs nouveaux contrôles sont prévus.

Champs de saisie

L’élément input est doté de nouvelles valeurs pour sa propriété type. Essentiellement :

• datetime
• date
• month
• week
• time
• number
• range
• email
• url
• search
• color

Ainsi les navigateurs pourront proposer nativement l’interface utilisateur adéquate comme par exemple, un sélecteur de dates.

Les navigateurs prendront également en charge l’envoi au serveur non pas de la valeur saisie, mais d’une valeur formatée. On retrouve ici un principe largement mis en œuvre dans la plupart des frameworks : si on reprend notre exemple du sélecteur de dates, l’utilisateur pourra choisir des dates qui lui seront présentées au format local (JJ/MM/AAAA pour la France) mais les données envoyées au serveur pourront être toujours de la forme AAAA/MM/JJ, après avoir été validées.

Justement, l’attribut required permettra nativement de valider qu’un champ a bien été renseigné.

La page http://html5doctor.com/designing-a-blog-with-html5/ vous donne quelques exemples.

Combo-boxes

La combo-box fait son apparition dans le langage HTML ! L’élément datalist permet en effet de bénéficier d’une combo-box native, et donc de s’affranchir des frameworks qui nous le fournissaient, sous le nom « auto-complete » ou « suggest » :

Langue :

<input list="langues">

<datalist>

   <option>Francais</option>

   <option>English</option>

   <option>Deutsch</option>

</datalist>

Datagrids

La datagrid fait également son apparition dans le langage HTML. Elle permet de représenter et manipuler des arbres, des listes et des tableaux.

Une datagrid est initialisée à partir d’un élément HTML :

<datagrid>

   <table>

      <tr><td>1</td><td>Item 1</td></tr>

      <tr><td>2</td><td>Item 2</td></tr>

      <tr><td>3</td><td>Item 3</td></tr>

   </table>

</datagrid>

Dans cet exemple, la datagrid est peuplée à partir d’un tableau. Mais on aurait également pu utiliser un élément select afin de peupler la datagrid à partir d’une liste. Et même un ensemble d’éléments HTML, chacun représentant une ligne de la datagrid.

Il faut bien comprendre l’intérêt de la datagrid par rapport aux éléments HTML traditionnels : les éléments table et select ne sont pas manipulables par l’utilisateur, ils ne servent qu’à présenter des informations. La datagrid permet à l’utilisateur de les manipuler : sélectionner des lignes, des colonnes, des cellules, éditer des cellules, supprimer des lignes, des colonnes, trier les données, etc. Elle propose également une API qui permet de la manipuler programmatiquement. Là encore, le but est de fournir nativement ce que les frameworks nous apportent.

Menus

HTML définit un élément menu qui permet de définir des menus et des barres d’outils.

Voici un exemple de barre d’outils :

<menu>

   <li>

      <menu label="File">

         <button>New...</button>

         <button>Open...</button>

         <button>Save</button>

         <button>Save as...</button>

      </menu>

   </li>

   <li>

      <menu label="Edit">

         <button>Copy</button>

         <button>Cut</button>

         <button>Paste</button>

      </menu>

   </li>

</menu>

Pour créer un menu contextuel il suffirait de modifier l’attribut type du menu de toolbar à context. Les éléments peuvent alors référencer ce menu contextuel grâce à un nouvel attribut contextmenu.

Les éléments de ce menu peuvent être d’autres éléments menu (comme dans l’exemple ci-dessus), des séparateurs ou des commandes : une commande peut être représentée par un élément a, button, input, option, ou command.

Ce dernier élément command est apparu avec HTML 5. Il permet une sémantique plus fine :

<command label="Undo" />

Barres de progression

L’élément progress permet de présenter la progression d’une tâche :

Progress: <progress><span>0</span>%</progress></p>

<script>

   var progressBar = document.getElementById('p');

   function updateProgress(newValue) {

      progressBar.textContent = newValue;

   }

</script>

Notez que l’appel à cette fonction updateProgress() devra être fait manuellement.

Dans le même esprit, un élément meter est également prévu, pour afficher des mesures : pourcentages de votes, utilisation d’espace disque…

Multimédia

Vu la pauvreté du HTML 4 en la matière, le Flash Player est la référence de facto dans le domaine de la diffusion audio/vidéo embarquée dans les pages Web, avec sa compatibilité multi-navigateurs et ses API de manipulation.

HTML 5 fournit deux éléments video et audio dont l’objectif est de supporter nativement l’intégration et le contrôle des médias dans les pages Web :

<video src="video.mp4"></video>

<script>

   var video = document.getElementById("video");

</script>

<button>Play</button>

<button>Pause</button>

<button>Rewind</button>

Il sera donc possible de personnaliser l’interface utilisateur de manipulation des médias. Si ce n’est pas souhaité, l’attribut controls permettra d’indiquer au navigateur que c’est à lui de fournir cette interface.

Ce sera aux navigateurs de choisir les bons codecs. Il sera possible de spécifier différents formats via l’élément source :

<video>

   <source src="video.ogv">

   <source src="video.mp4">

</video>

L’élément audio est prévu pour fonctionner d’une manière similaire :

<audio>

  <source src="audio.oga">

  <source src="audio.mp3">

</audio>

Là encore, l’objectif est donc de fournir nativement ce que les solutions RIA nous ont proposé via des frameworks ou plugins.

Compléments

Les frames disparaissent ! Les éléments frame, frameset et noframes ne sont pas dans la spécification HTML 5 car leur utilisation a rendu difficiles l’expérience utilisateur et l’accessibilité.

Beaucoup d’attributs de présentation ont également été retirés afin d’inciter l’utilisation des équivalents CSS, bien plus adéquate : align, bgcolor, border, cellpadding, cellspacing, width, height…

Apports « avancés » de HTML 5

Drag and drop et copier/coller

Le « drag and drop », ou « glisser/déposer », est aujourd’hui un besoin courant dans les applications Web riches. Il est donc aujourd’hui largement proposé par la plupart des frameworks RIA. Il semblerait donc presque banal qu’il soit défini dans la spécification HTML 5.

Cependant, il faut savoir que dans les navigateurs actuels, qui implémentent HTML 4, les opérations « drag » sont limitées : vous ne pouvez lâcher des éléments qu’à l’intérieur de la fenêtre du navigateur. Si cela n’est pas gênant dans beaucoup de cas, il s’agit là d’une limitation importante, qui vous empêche de partager des données d’une application Web à une autre d’une manière conviviale.

HTLML 5 a pour objectif de casser cette limitation en proposant des interfaces DragEvent et DataTransfer :

interface DragEvent : MouseEvent {

   readonly attribute DataTransfer dataTransfer;

}

De manière assez traditionnelle pour ce genre de problématiques, les événements suivants sont gérés au fur et à mesure du drag and drop : dragstart, drag, dragenter, dragleave, dragover, drop, dragend. Lors de l’événement dragstart, l’objet DataTransfer est initialisé à une valeur qui pourra être récupérée lors de l’événement drop. Cette valeur pourra contenir des informations concernant l’objet déplacé. Cet objet doit être marqué comme étant déplaçable (attribut draggable).

Voici un exemple très simple permettant de déplacer un élément div d’un conteneur à un autre :

<div>

   <div

        draggable="true"

        ondragstart="return dragStart(event)"

        ondragend="return dragEnd(event)">

      Item ‘draggable’

   </div>

</div>

<div

     ondrop="return dragDrop(event)"

     ondragover="return dragOver(event)">

</div>

On notera l’utilisation de nouveaux attributs dont le rôle est assez explicite. Voici le code des fonctions JavaScript qui traitent les événements générés :

<script>

   function dragStart(event) {

      ev.dataTransfer.setData(
         "ElemId",
         event.target.getAttribute('id')
      );

      return true;

   }

   function dragOver(event) {

      // Ici on peut aussi retourner ‘true’
      // si on souhaite empêcher le dépôt
      // sur l’élément survolé

      return false;

   }

   function dragEnd(event) {

      ev.dataTransfer.clearData("ElemId");

      return true;

   }

   function dragDrop(event) {

      var elemId = ev.dataTransfer.getData("ElemId");

      event.target.appendChild(
         document.getElementById(elemId)
      );

      // On empêche la propagation de l’événement

      ev.stopPropagation();

      return false;

   }

</script>

Petite particularité : la notion de drag and drop n’est pas définie explicitement dans la spécification, elle reste ouverte. Cela ouvre la voie à de nombreuses possibilités, comme celle d’effectuer des « copier/coller ».

Le site http://html5demos.com/drag vous propose quelques démonstrations.

Géolocalisation

Cet aspect n’est pas directement inclus dans la spécification HTML 5 mais il y est souvent lié. Une API de Géolocalisation est également en cours de spécifications : http://www.w3.org/TR/geolocation-API/.

Son objectif est de permettre l’accès à la latitude et la longitude du périphérique sur lequel est exécuté le navigateur. Ces informations sont déterminées par analyse de diverses sources d’information : GPS, adresse IP, RFID, WiFi, Bluetooth, GSM…

Voici un exemple d’utilisation de cette API :

function traiterPosition(position) {

   // Utilisation des coordonnées
   // (ex : affichage d’une carte)

   // position.coords.latitude,
   // position.coords.longitude

}

navigator.geolocation.getCurrentPosition(
   traiterPosition
);

Cet exemple montre un appel unique à l’API : celle-ci propose un mécanisme de cache configurable en cas de besoin d’appels répétés.

Là encore vous pourrez effectuer des tests vous-mêmes sur le site http://html5demos.com/geo. Les plus inquiets pourront constater que le navigateur vous demande votre permission avant de récupérer vos coordonnées.

Graphisme 2D

HTML 5 définit un élément canvas qui permet de faire du dessin en JavaScript : formes, graphes, retouches photographiques, et même animations.

<canvas width="150" height="150"></canvas>

Les dessins se font en travaillant sur des rendering contexts. Nous resterons ici dans le cadre du contexte 2D, mais il existe également un contexte 3D (en cours de spécification, basé sur Open GL ES). Voici le code permettant de dessiner un rectangle bleu :

<script>

   var canvas = document.getElementById("monCanvas");

   if (canvas.getContext) {

      var ctx = canvas.getContext("2d");

      ctx.fillStyle = "rgb(0,0,255)";

      ctx.fillRect (10, 10, 50, 50);

   }

</script>

Cet exemple est très simple mais cette API propose de nombreuses possibilités : rectangles, lignes droites, arcs de cercle, courbes cubiques et quadratiques, intégration d’images, translations, homothéties, rotations, gestion de la transparence, dégradés, ombres, animations, interactions avec la souris…

Pour en savoir plus, vous pouvez par exemple consulter le site de Mozilla : https://developer.mozilla.org/en/Canvas_tutorial.

Gestion du Content-Type et de l’encodage des caractères

HTML 5 définit de nouveaux algorithmes de détection du Content-Type et de l’encodage des caractères. Du côté des développeurs, spécifier l’encodage utilisé devrait être bien plus simple. On retiendra les deux méthodes suivantes :

• Renseigner l’entête Content-Type des requêtes HTTP
• Renseigner un élément meta de la page avec l’attribut charset comme suit :

<meta charset="UTF-8">

Plus besoin, donc, de la traditionnelle syntaxe verbeuse suivante :

<meta http-equiv="Content-Type"
   content="text/html; charset=UTF-8">

Cette syntaxe sera cependant toujours supportée, toujours dans un souci de rétro-compatibilité.

Gestion de l’historique et du bouton « Back »

HTML 5 définit la notion de browsing contexts : il s’agit d’environnements dans lesquels les objets Document sont présentés aux utilisateurs. Ainsi, une fenêtre possède un browsing context, tout comme un onglet, une iframe ou une frame…

L’ensemble des documents d’un browsing context est nommé session history. Des objets History sont ainsi constitués, empilant les URL (ou des objets représentant un état) associées aux documents.

Cet historique est manipulable via une API dédiée :

interface History {

  readonly attribute long length;

  void go(optional in long delta);

  void back();

  void forward();

  void pushState(
     in any data,
     in DOMString title,
     optional in DOMString url
  );

  void clearState();

};

Ainsi l’appel suivant suffit à revenir à l’état précédent de l’historique :

window.history.back();

Cette API ressemble fortement à celle qui existait auparavant. Elle devrait cependant être plus poussée grâce à cette notion d’état, qui facilitera la gestion de l’historique dans les applications AJAX, de la même manière que l’ont proposé les frameworks.

Historique d’annulations

Il s’agit là d’une nouveauté qui n’est pas encore prête : la spécification nous indique que plusieurs points pourraient bien être à revoir, nous allons donc en rester à une présentation brève.

L’idée de cette API nommée UndoManager est d’associer un historique d’annulations à chaque document. Cet historique sera manipulable et composé d’une liste d’éléments, pouvant être de deux types :

• DOM changes : il s’agit d’objets représentant des modifications de la structure DOM opérés suite à une manipulation utilisateur (changement du contenu d’un nœud ou de la valeur d’un de ses attributs) ;
• Undo objects : il s’agit d’objets représentant des informations de plus haut niveau (état avant une action utilisateur ou l’envoi d’une requête au serveur, par exemple).

Mode offline

HTML 5 est accompagné de la spécification Offline Web Applications : http://www.w3.org/TR/offline-webapps/.

Cette spécification a pour objectif de permettre le développement d’applications Web utilisables en mode déconnecté, ou offline. Pour ce faire, elle apporte deux éléments :

• une base de données embarquée dans le navigateur et manipulable via une API reposant sur des requêtes SQL ;
• un cache applicatif permettant de stocker dans le navigateur les réponses des requêtes HTTP effectuées.

Base de données

La base de données locale supporte les transactions. Elle sera manipulable de la manière suivante :

var db = openDatabase(
   "notes", "", "The Example Notes App!", 1048576);

function renderNotes() {

   db.transaction(

      function(tx) {

         tx.executeSql(

            'CREATE TABLE IF NOT EXISTS Notes(
               title TEXT, body TEXT
            )',

            []

         );

         tx.executeSql(‘SELECT * FROM Notes’, [],
            function(tx, rs) {

               for(var i=0; i<rs.rows.length; i++) {

                  // Traitement de la note :
                  // rs.rows[i]

               }

            }
         );

      }

   );

}

function insertNote(title, text) {

   db.transaction(

      function(tx) {

         tx.executeSql(

            'INSERT INTO Notes VALUES(?, ?)', 

            [ title, text ],

            function(tx, rs) {

               // …

            },

            function(tx, error) {

               // Traitement

            }

         );

      }

   );

}

Cette API s’inspire donc très fortement du plugin Google Gears. Sauf qu’au lieu d’un plugin, cette base de données sera fournie nativement par les navigateurs.

Cache applicatif

Ce cache reposera sur l’attribut manifest de l’élément html, qui pointe vers l’URI d’un fichier nommé « manifest ».

Ce fichier indique simplement la liste des fichiers à mettre en cache (section CACHE MANIFEST), ainsi que ceux qui ne doivent pas être mis en cache (section NETWORK) :

CACHE MANIFEST

index.html

help.html

style/default.css

images/logo.png

images/backgound.png

NETWORK:

server.cgi

La spécification prévoit d’autres moyens de définir le cache, via un préfixe par exemple. Elle prévoit également une API permettant aux scripts d’ajouter et retirer dynamiquement des fichiers du cache.

Aspects communs

Pour déterminer si le client est connecté ou non, il suffira d’invoquer :

var isOnline = navigator.onLine;

Web workers

Cet aspect non plus n’est pas directement inclus dans la spécification HTML 5 mais souvent lié. Une API est également en cours de spécifications : http://www.whatwg.org/specs/web-workers/current-work/.

Cette spécification définit une API pour exécuter des scripts en tâche de fond, donc indépendamment des scripts de l’interface utilisateur.

Elle permet ainsi l’exécution de scripts « longs » :

• sans interruption par des scripts de traitement d’actions utilisateur (clics par exemple) ;
• sans besoin de mécanisme permettant de conserver une page réactive.

Mais cette API est très claire : les Workers sont lourds et sont à utiliser avec parcimonie, et uniquement si réel besoin.

Voici un exemple très simple issu de la spécification : la tâche de fond est ici un algorithme naïf de recherche de nombres premiers :

The highest prime number discovered so far is:

<output></output>

<script>

   var worker = new Worker('worker.js');

   worker.onmessage = function (event) {

      var result = document.getElementById('result');
      result.textContent = event.data;

   };

</script>

Voici le contenu du fichier worker.js :

var n = 1;

search: while (true) {

  n += 1;

  for (var i = 2; i <= Math.sqrt(n); i += 1)

    if (n % i == 0)

     continue search;

  // found a prime!

  postMessage(n);

}

La spécification regorge d’exemples variés, à complexité et intérêt croissants.

Web sockets

HTML 5 introduit l’API Web Sockets, qui permettra de communiquer avec le serveur de manière bi-directionnelle à la manière de Comet et AJAX, mais avec les deux avantages suivants :

• cette API sera native ;
• elle ne nécessitera qu’une seule connexion avec le serveur, au lieu de deux dans le cas de Comet et AJAX.

En effet, Comet et AJAX reposent sur le protocole HTTP donc nécessitent une connexion pour envoyer des données et une autre pour en récupérer du serveur.

Cette API n’est pas encore détaillée dans la spécification HTML 5.

Cross-document messaging

Un des grands soucis avec AJAX était jusqu’ici l’impossibilité d’interactions entre des scripts de documents situés sur des domaines différents, pour des raisons de sécurité. Même si cette sécurité est justifiée, cela empêche des pages de communiquer même si elles ne sont pas dangereuses.

La spécification HTML 5 définit un système de communication entre documents à base de messages. Ce, quelque soit leur domaine, tout en conservant un niveau de sécurité optimal.

Voici un cas concret provenant de la spécification :

• un document A contient une iframe contenant un document B ;
• un script du document A invoque une certaine fonction window.postMessage() sur le document B ;
• Un événement message est alors déclenché sur le document B : ce message est marqué comme provenant de l’objet Window du document A.

Voici le code qui correspond à cet exemple (script du document A) :

var docB = document.getElementsByTagName('iframe')[0];

docB.contentWindow.postMessage(
   'Hello world',
   'http://url/'
);

Et voici le script nécessaire dans le document B afin de surveiller l’arrivée de tels messages :

window.addEventListener('message', receiver, false);

function receiver(e) {

   if (e.origin == 'http://url/') {

      if (e.data == 'Hello world') {

         e.source.postMessage('Hello', e.origin);

      }

      else {

         alert(e.data);

      }

   }

}

Comme en AJAX, il est essentiel de vérifier que le domaine d’origine est celui attendu.

Petit bilan

Nous venons de dresser une synthèse des apports essentiels de la spécification HTML 5. Ces apports sont nombreux et ont pour objectifs de :

• rendre HTML plus adapté aux problématiques actuelles des applications Web ;
• casser la dépendance du Web vis-à-vis des frameworks propriétaires, comme Flash, Flex, ou Silverlight.

Où en est HTML 5 aujourd’hui ?

Les éléments que nous avons abordés dans cet article ne sont pas figés puisque la spécification est une version de travail. Certains exemples ne sont même peut-être plus d’actualité !

Les navigateurs ont déjà commencé à implémenter HTML 5, mais deux problèmes se posent :

• les implémentations dans les différents navigateurs sont hétérogènes et n’avancent pas à la même vitesse ;
• il est en outre très difficile de savoir où en sont les navigateurs dans cette implémentation : les sites Web des éditeurs des navigateurs ne sont guère bavards sur le sujet, et si le Web regorge de pages de qui traitent le sujet, les informations qu’on trouve sont parfois contradictoires.

En résumé, pour celui qui souhaite savoir si la version X du navigateur Y implémente déjà la caractéristique Z de HTML 5, il vaut mieux jeter un œil sur le Web et surtout effectuer des tests !

Côté outils de développement et de débogage, rien de particulier pour le moment : gardez sous le coude vos outils HTML habituels !

Cette spécification précise qu’elle ne sera finalisée que lorsqu’au moins deux implémentations complètes en auront été réalisées, afin de s’assurer de son adéquation avec les besoins des développeurs d’applications Web et les contraintes des éditeurs de navigateurs. Ian Hickson, co-rédacteur de la spécification, nous précise dans une interview (http://blogs.techrepublic.com.com/programming-and-development/?p=718) que cela arrivera en … 2022 ! Le planning est donc long, à cause de l’historique et des objectifs à atteindre.

En effet, le travail est considérable : la spécification en est consciente et tente de ne pas reproduire les erreurs du passé. Ainsi, elle sépare clairement les requirements à destination des développeurs de ceux à destination des éditeurs de navigateurs. De même, au lieu de donner des définitions abstraites comme dans les versions précédentes, elle donne des définitions impératives afin de favoriser l’interopérabilité entre les implémentations. La « bataille » entre navigateurs ayant repris de plus belle, il s’agit là d’une problématique très importante. Ce planning ne serait-il pas trop long, tout de même ?

HTML 5, « killer » de Flex et Silverlight ?

Ce titre vous surprendra peut-être, mais on peut lire plusieurs articles sur Internet qui présentent HTML 5 comme le langage qui va conquérir le monde des RIA. Pourquoi ? Parce que les apports de HTML 5 comblent plusieurs manques de HTML vis-à-vis de ces technologies : vidéo, audio, mode offline, drag and drop…

Sauf que ces technologies sont déjà disponibles, plus évoluées et largement mises en œuvre pour certaines. Le Flash Player, après plus de 10 ans, est présent sur 99% des navigateurs. HTML 5 est « plus RIA » que HTML 4, oui. Rattrape-t-il son retard sur Flex ou Silverlight ? Non. D’autant plus que lorsque HTML 5 sera finalisé en 2022, le monde des RIA aura largement eu le temps d’évoluer ! Le planning semble donc trop long. Mais il est primordial que le W3C définisse des normes adéquates aux problématiques actuelles afin de limiter le recours à des technologies non natives et propriétaires.

Cette comparaison entre HTML 5 et les autres technologies RIA a été mise en avant lors de l’annonce officielle de Google Wave : l’application Web de Google Wave, impressionnante, repose sur certains apports de HTML 5 et Google a largement communiqué sur ce sujet.

Quelques liens pour approfondir

Sites officiels de la spécification :

http://www.w3.org/TR/html5/

http://www.w3.org/TR/html5-diff/

Deux pages qui synthétisent l’état d’avancement de l’implémentation par les navigateurs :

http://a.deveria.com/caniuse/

http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML_5%29#Web_Applications_1.0

On constate deux approches distinctes :

• Beaucoup se focalisent sur Java 7 : les discussions font rage sur les évolutions qui pourraient composer cette nouvelle version
• D’autres considèrent que Java, avec sa spécification de 600 pages, est devenu trop complexe : qu’il ne pourrait donc plus apporter de réelle révolution et qu’il faudrait donc réfléchir à son digne successeur.

Complexité ?

Nous sommes bien d’accord, cette notion de complexité est relative : par exemple, tout le monde ne se sent pas obligé de mettre en œuvre et pousser les Generics jusqu’à leurs retranchements !

Tout le monde n’a pas été convaincu par la pertinence des nombreux débats  « langages statiques contre langages dynamiques ». Ces débats ont malgré tout ouvert la voie à de nouveaux paradigmes de développement rapide et flexible.

Certains se sont donc consacrés à la création d’un langage « état de l’art » afin de répondre aux problématiques actuelles avec plus de simplicité et de productivité, tout en conservant les principes qui ont fait le succès de Java. Finalement, comme Java, qui avait en quelques sortes détrôné le roi de l’époque, C++.

Cet article est consacré à Scala, l’un de ces langages. Scala a été démarré en 2001 par Martin Odersky, Professeur à l’EPFL qui travaille également pour Sun à la production de l’implémentation de référence de javac. C’est lui qui est à l’origine de l’implémentation des Generics Java.

Je dois avouer que je fais partie des nombreuses personnes qui ont été impressionnées par ce langage dès le premier contact. Par exemple, James Strachan, le créateur du langage dynamique Groovy, a lui aussi été séduit par Scala :

“Though my tip though for the long term replacement of javac is Scala. I’m very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy”

Et InfoQ nous présente d’autres « mordus » de Scala.

Langage statique ou langage dynamique ?

On peut lire beaucoup de débats passionnés sur ce sujet. Mais pour le profane, il n’est pas facile d’y participer car la terminologie associée n’est pas si triviale. Commençons donc par quelques éclaircissements.

Qu’est-ce qu’un langage statique ?

Déjà, il faut savoir que « langage statique » est un abus de langage pour « langage à typage statique ».

J’aime assez la définition suivante, proposée dans le livre Programming Scala de Dean Wampler et Alex Payne (O’Reilly) :

“in static typing, a variable is bound to a particular type for its lifetime. Its type can’t be changed and it can only reference type-compatible instances”

Ainsi, une variable de type A ne pourra être réaffectée plus tard qu’à des types compatibles avec le type A (dans un langage orienté objets, les types compatibles avec un type A sont A lui-même et les sous-classes de A). En fait, la notion de type est rattachée aux variables, non aux valeurs.

On pourrait compléter cette définition informelle, mais dans notre contexte elle nous suffira amplement.

Java et C++ sont des exemples de langages statiques.

Et un langage dynamique ?

Le même livre nous donne la définition suivante du typage dynamique :

“In dynamic typing, the type is bound to the value, not the variable”

Ainsi, une variable qui référence une valeur de type A peut très bien être réaffectée plus tard à des valeurs de n’importe quel type, même non compatible avec le type A. Dans ce cas, la notion de type est rattachée aux valeurs, non aux variables.

C’est pour cette raison que l’on parle de typage dynamique : le type des variables est évalué lors de l’exécution de l’application, et non lors de la compilation comme c’est le cas du typage statique.

Ruby, Python, Groovy et JavaScript sont des exemples de langages dynamiques.

Le débat

Peut-être qu’en lisant ces définitions, compte tenu de votre expérience personnelle, vous tendez naturellement vers une de ces deux approches.

Ainsi on entend souvent les arguments suivants :

• « Les langages dynamiques, plus flexibles, permettent un gain de temps sur le choix des types» 
• « Les langages statiques peuvent davantage exploiter la notion de type, ce qui facilite la création d’outils d’aide au développement comme l’auto-complétion et d’outils d’optimisation du code» 
• « Les langages dynamiques retardent la détection de certaines erreurs à l’exécution alors que les langages statiques permettent de lever ces erreurs dès la compilation» 
• « Une batterie de tests unitaires permet aux langages dynamiques de s’affranchir de la détection d’erreurs par un compilateur» 

Et bien d’autres… Ces simples exemples suffisent à vous faire imaginer l’intensité des polémiques, dans un sens comme dans l’autre ! Sans rentrer dans les détails de ces exemples, essayons de dépasser le débat.

Un peu de recul…

On constate deux faits intéressants :

• Premier constat, les langages dynamiques séduisent beaucoup de monde de par leur flexibilité et leur souplesse : le succès des langages Ruby et Python, pour ne citer qu’eux, en témoigne. Les aficionados de ces langages trouvent souvent les langages statiques trop verbeux et ils apprécient d’avoir moins de code à écrire
• Second constat, beaucoup ne sont pas séduits par ces langages… Car cette flexibilité et cette souplesse font peur ! Après tout, écrire moins de lignes de code n’augmente pas nécessairement la productivité : il faut également que ce code soit fonctionnel, lisible, maintenable, etc.

Il est clair qu’il y a une réelle demande de langages succincts et flexibles pour gagner en productivité. Mais diminuer la quantité de code n’est pas un objectif en soi : il ne s’agit pas simplement d’une histoire de trop grande verbosité ou taille du code, mais de profiter davantage de l’inférence de type, c’est-à-dire éviter d’écrire ce que le compilateur peut deviner.

Les grandes lignes de Scala

Un langage statique

Scala est un langage statique qui permet une syntaxe succincte, flexible et même élégante. Pourtant son système de typage est sophistiqué.

Pour quelles raisons ? J’aime beaucoup la façon dont le débat habituel est dépassé dans le livre Programming in Scala, qu’il a co-écrit avec Lex Spoon et Bill Venners (Artima). Il nous rappelle en effet que :

• Oui, un compilateur ne permet de détecter que de simples erreurs : il ne vous dira pas que certaines fonctions ne se terminent pas ou que votre cahier des charges n’est pas respecté
• Oui, des tests unitaires permettent d’avoir une couverture plus poussée

Mais il nous invite à envisager le débat sous un autre angle :

• Un système de typage statique ne peut pas remplacer les tests unitaires, mais il peut en réduire le nombre
• L’inverse n’est pas vrai : les tests unitaires ne peuvent remplacer un système de typage statique. En effet, des tests ne peuvent que nous prouver la présence d’erreurs et non leur absence. Alors qu’un typage statique nous donne des garanties simples mais réelles (opérations entre types incompatibles, accès externe à des membres privés, etc.)
• Enfin, le typage statique facilite les refactorings de code et la mise à jour des documentations.

Un langage  concis

Scala est donc un langage statique. Pourtant, James Strachan nous explique – à juste titre – que Scala est un langage dont la concision rappelle les langages dynamiques :

“Scala seems to hit the perfect sweet spot between the consise feel of a dynamic language, while actually being completely statically typed”

En fait, Scala repose sur de nombreuses techniques permettant de minimiser la syntaxe inutile : il s’agit essentiellement de l’inférence de type que nous évoquions précédemment. Ces techniques dépassent largement le cadre de cet article, nous nous contenterons d’un exemple très simple.

La ligne suivante de code Java :

List<String> list = new ArrayList<String>();

Peut être écrite en Scala :

val list : List[String] = new List[String]

Ou même :

val list = new List[String]

Cette dernière ligne de code semble provenir de langages dynamiques mais ici le typage est statique : il est inutile de préciser le type de la variable car le compilateur est capable de le déterminer seul. C’est l’inférence de type.

L’introduction à Scala sur le site officiel évoque ainsi une diminution du volume du code d’un facteur 2 à 3.

Encore une fois, le but n’est pas de produire moins d’effort de typage, mais de produire moins d’effort de lecture et de compréhension donc de réduire le nombre d’erreurs possibles. L’exemple suivant est simple mais il illustre cette idée.

Voici un code classique de création d’une classe en Java :

class Point {
   private int x;
   private int y;

   public Point(int x, int y) {
      this.x = x;
      this.y = y;
   }
}

Voici l’équivalent Scala :

class Point(x : Int, y : Int)

Note : en toute rigueur, dans ce code Scala, les variables d’instances seront final. Ceci dit, l’idée de cet exemple est simplement de vous faire prendre conscience de la concision de Scala.

En outre, Scala propose :

• L’utilisation de caractères non alphanumériques dans les noms des méthodes : cela permet un équivalent de la surcharge d’opérateurs
• Les closures, qui manquent souvent aux développeurs Java qui connaissent Ruby et Python.

Voici un exemple illustrant la notion de closure et son intérêt. Voici une simple méthode Java qui retourne la liste des items achetés par un utilisateur :

public List<Item> getBoughtItems(User user) {
   List<Item> result = new ArrayList();
   for (Item item : items) {
      if (user.bought(item)) {
         result.add(item);
      }
   }
   return result;
}

Voici l’équivalent Scala, basé sur une closure :

def getBoughtItems(user: User) =
   items.filter(user bought)

En fait, l’expression user bought désigne un prédicat. Ce prédicat prend un paramètre en entrée, qui est omis car unique.

Un langage mixte

Martin Odersky connaissant bien la Programmation Orientée Objets et la Programmation Fonctionnelle, a créé Scala comme une synthèse du meilleur de ces deux mondes :

• La Programmation Orientée Objets permet la construction de systèmes complexes, structurés et flexibles
• La Programmation Fonctionnelle permet de répondre rapidement et de manière concise à certaines problématiques.

Scala est un donc un langage dit « mixte ». Et c’est ce mélange, avec ses nouveaux design patterns et son style concis, qui le rend « scalable ». Car oui, le nom « Scala » est issu de la contraction de « scalable language ».

Un langage « scalable » ?

Je vous prie de m’excuser car j’emploierai parfois le terme anglais « scalable » au lieu de son équivalent français « évolutif », car cela rappelle bien les objectifs de ce langage.

Ce langage se veut évolutif car conçu pour évoluer avec la demande des utilisateurs. Comme nous l’a présenté Martin Odersky à la conférence JavaOne 2008 :

« A language is scalable if it is suitable for very small as well as very large programs» 

Le livre Programming in Scala nous explique la démarche derrière Scala : il ne s’agit pas de fournir le langage parfait qui contient « tout» , mais de donner des outils que l’on peut étendre et adapter.

Un langage pour la machine virtuelle Java

Scala s’inspire d’un nombre impressionnant de langages (il suffit de lire la page 20 du livre précédent pour s’en rendre compte).

Mais le compilateur Scala produit du bytecode pour la JVM, ou machine virtuelle Java. En effet, durant ces 14 ans :

• Beaucoup d’optimisations ont été apportées à la JVM : il est donc intéressant de profiter des performances obtenues d’entrée de jeu
• Les développeurs ont acquis beaucoup de compétences et produit de nombreux frameworks et applications : il serait donc dommage de ne pas profiter de toute cette richesse.

Il est ainsi possible d’invoquer du code Java depuis du code Scala, et inversement.

Un langage orienté objets

Un langage orienté objets à 100%

Scala est un langage orienté objets à 100%, construit autour du slogan « everything is an object» .

En effet, chaque valeur est un objet et toute opération est un appel de méthode. Ainsi, Scala élimine les déviations de Java :

• Il n’y a pas de type primitif
• Il n’y a pas de membre statique (qui rappelons-le, ne sont par définition rattachés à aucune instance) : des singletons sont utilisés à la place
• Les tableaux ne sont pas gérés via une syntaxe spéciale : il existe une classe Array comme les autres.

Ces déviations ne paraissent pas si gênantes, mais elles compliquent les choses et limitent la « scalabilité » du code.

Un système de type sophistiqué

Scala permet la définition des types classiques : classes, héritage, types abstraits… Mais son système de type est sophistiqué :

• Il étend celui de Java (même s’il repose beaucoup dessus en interne)
• Les Generics sont plus flexibles
• Plus de constructions sont possibles grâce à l’inférence de type

On notera en particulier les deux apports suivants :

• La notion de traits : les traits ressemblent aux interfaces Java, sauf qu’on peut en fait y définir des propriétés et y implémenter certaines méthodes. Les traits apportent de nouveaux design patterns que nous pourrons aborder dans un autre article
• La notion de composition mixin, qui permet de réutiliser des membres spécifiques à une classe fille (par rapport à sa classe mère) lors de la définition d’une nouvelle classe : cette notion, que vous pouvez rapidement découvrir sur le site officiel, permet ainsi d’ajouter de l’état et du comportement à des classes (ou même des objets), ce qui était possible en C++ par de l’héritage multiple mais que partiellement en Java via des approches de type AOP (Programmation Orientée Aspects).

Voici un exemple simple, proposé sur le site officiel :

abstract class AbsIterator {
   type T
   def hasNext : Boolean
   def next : T
}

// Ici le mot-clé « trait » indique que cette
// classe pourra être utilisée comme mixin
trait RichIterator extends AbsIterator {
   def foreach(f : T => Unit) {
      while (hasNext) f(next)
   }
}

class StringIterator(s: String) extends AbsIterator {
   type T = Char
   private var i = 0
   def hasNext = i < s.length()
   def next = { val ch = s charAt i; i += 1; ch }
}

// Combinons les fonctionnalités des deux classes par
// composition mixin
object StringIteratorTest {
   def main(args: Array[String]) {
      class Iter extends StringIterator(args(0))
         with RichIterator
      val iter = new Iter
      iter foreach println
   }
}

Dans ce cas, on dit que la classe Iter est construite par composition mixin des classes StringIterator et RichIterator. La première est son « parent» , la seconde son « mixin» .

En fait, cela permet à Scala de proposer une nouvelle approche orientée modules : les composants sont des classes ou des traits, et on peut les composer par mixin.

Et… Un langage fonctionnel !

Scala est également un langage de programmation fonctionnelle.

Une petite présentation de la programmation fonctionnelle

Pour la petite histoire, ce type de langages est plus ancien que les langages orientés objets, mais ils étaient jusqu’ici cantonnés à des laboratoires de recherche. Si vous souhaitez en savoir plus sur l’histoire de ces langages, consultez par exemple le livre Programming in Scala.

Dans ce type de langages, les fonctions sont des valeurs de premier ordre (comme les int, string, etc. dans nos langages habituels) : on peut assigner des fonctions à des variables, passer des fonctions en arguments d’autres fonctions, déclarer des fonctions comme valeur de retour d’autres fonctions, etc. Autrement dit, toujours dans la lignée du « everything is an object », en Scala les fonctions sont des objets comme les autres. A titre d’illustration, cela va plus loin que les pointeurs de fonctions du C++ (qui ne sont que des valeurs de second ordre). Nous pourrions là-encore pousser le sujet bien plus loin, mais restons dans le cadre de cet article.

L’immutabilité comme principe de base

Les fonctions prennent en entrée des valeurs qu’elles ne modifient pas : ces données sont dites « immutables ». Les fonctions sont « sans effet de bord », ou « référentiellement transparentes » : dans un fragment de code, on peut remplacer un appel à une fonction par son résultat, c’est-à-dire sa valeur de retour.

Ce principe est fondamental et il peut faire peur puisque la programmation orientée objets ne le respecte pas nécessairement. En fait, cette partie de Scala s’intègre parfaitement avec la partie orientée objets : elles ne s’opposent pas, elles s’améliorent mutuellement.

Quel en est l’intérêt ?

Ce type de langages permet de simplifier plusieurs problèmes de design. Un bon exemple en est la programmation concurrente.

Ce sujet est de plus en plus d’actualité avec la prolifération des processeurs multi-core, qui distribuent les calculs sur différents threads. Or il s’agit souvent d’un vrai casse-tête !

Le modèle de Java en matière de programmation concurrente repose sur l’accès synchronisé à des ressources mutables et partagées : il est donc complexe et source d’erreurs. La gestion des locks est difficile, surtout pour des systèmes qui grandissent en taille et en complexité. En effet, comme nous le rappelle judicieusement le livre Programming in Scala, les deadlocks ne se voient souvent qu’une fois en production et non pendant les tests.

Scala apporte une solution élégante à ce problème : l’API Actors, qui repose sur le modèle du même nom, issu du langage Erlang. Elle repose sur les principes suivants :

• On appelle « acteurs » des entités logicielles indépendantes
• Les acteurs ne partagent pas d’information d’état entre eux, ils communiquent en échangeant des messages asynchrones (chacun dispose d’une queue) : on n’a donc pas besoin de synchroniser l’accès à des données mutables partagées.

Sur ce sujet, je vous invite à étudier cet exemple du livre Programming Scala, ainsi que la page suivante du site officiel.

Les closures, que nous avons présentées précédemment, proviennent directement de la programmation fonctionnelle.

Je vous invite également à jeter un œil au Pattern Matching, sorte de switch/case avancé. Là encore nous pourrons aborder ce point spécifique dans un article ultérieur, car cela va bien plus loin qu’un simple switch/case !

Scala en pratique

Nous venons de présenter Scala, sur le papier. Qu’en est-il en pratique ?

Scala est déjà mis en œuvre dans des projets en production, comme nous l’indique le site officiel. On y découvre que Twitter, Siemens et même une filiale d’EDF (EDF Trading) ont mis en œuvre Scala de manière plus que significative afin d’améliorer la productivité, la « scalabilité»  et la fiabilité générale de projets concrets.

Côté performances, le site officiel se veut catégorique :

“The Scala compiler is mature and proven highly reliable by years of use in production environments, The compiler was written by Martin Odersky who also wrote the Java reference compiler and co-authored the generics, used by millions of Java programmers today. You can be confident his implementation of the Scala compiler produces byte code that performs every bit as good as comparable Java code”

Côté outils, il existe déjà des plugins pour les outils de développement traditionnels (Eclipse, IntelliJ IDEA, NetBeans) et pour les outils de build (Ant, Maven).

Notez enfin que Scala est même disponible pour .NET et sa machine virtuelle (CLR).

Enfin, la communauté autour de Scala est déjà organisée : la distribution de Scala est téléchargée 5000 fois par mois, et des frameworks Scala voient déjà le jour. On notera par exemple le framework Web nommé Lift. Une conférence dédiée a même déjà été lancée : http://www.scalaliftoff.com/.

Conclusion (temporaire)

J’espère vous avoir transmis mon intérêt pour Scala ! Scala n’est pas une amélioration de Java : il s’agit d’un langage qui se veut plus simple et plus élégant que Java, tout en produisant du bytecode pour la machine virtuelle Java. Scala pourrait donc bien être un digne successeur de Java. Mais il ne faut pas pour autant jeter aux orties les autres langages comme Ruby, Groovy ou Python : n’oublions pas que chaque situation a ses besoins et ses contraintes, et donc ses solutions. A suivre…

Notion d’Adressabilité

Il s’agit d’une notion assez simple à appréhender. On peut d’abord définir l’Adressabilité de la manière suivante, comme Leonard Richardson et Sam Ruby dans leur excellent ouvrage RESTful Web Services : une application adressable est une application qui présente ses informations « intéressantes»  en tant que Ressources. En effet, alors, chacune de ces informations possède un URI, et cet URI la rend accessible.

On ne le rappellera jamais assez : peut être une ressource tout objet assez important pour être référencé en tant que tel. La capacité d’une Ressource à être référencée la rend « adressable» . Dans quel but ? Le document URIs, Addressability, and the use of HTTP GET and POST du Technical Architecture Group du W3C nous donne une réponse typiquement dans la lignée de la philosophie RESTienne :

« we can refer to things [...], access them, describe them, and share them. Providing a URI for a resource affords many advantages, including: linking, bookmarking, caching» 

A force d’en profiter quotidiennement dans le Web qu’on connaît – et parfois, de manière transparente, ces apports peuvent avoir l’air banal mais ils sont fondamentaux. Plus généralement, référencer des Ressources par de simples identifiants permet de s’affranchir des différences entre langages et plateformes. C’est là que le « U»  de « URI» , pour « Uniform»  , prend tout son sens :

« Great multiplicative power of reuse derives from the fact that all languages use URIs as identifiers: This allows things written in one language to refer to things defined in another language. [...] In this finding, the term ‘URI addressability’ means that a URI alone is sufficient for an agent to carry out a particular type of interaction.» 

Il devient en effet facile de créer des liens vers ces identifiants afin d’opérer des actions sur les Ressources référencées. Cette simplicité est l’un des facteurs clés du succès du Web que nous connaissons.

Notion d’URI

On peut définir simplement un URI comme étant à la fois le nom et l’adresse d’une Ressource. En effet, comme nous l’indique Roy Fielding dans sa thèse où il définit REST :

« Resource identifier [allows] to identify the particular resource involved in an interaction between components» 

En effet, rappelons la définition de Ressource que nous avons donnée dans le post précédent : peut être une ressource tout objet assez important pour être référencé en tant que tel. Dans cette optique, l’URI d’une Ressource est justement le moyen de référencer cette Ressource.

Un URI identifie une Ressource donc n’est rattaché qu’à cette seule Ressource. Mais une Ressource peut être rattachée à plusieurs URI. En pratique, on essaie tout de même de limiter le nombre d’URI rattachés à une Ressource afin de ne pas réduire leur valeur.

Et voilà, à ce stade, nous pourrions presque terminer ce post. Mais nous constatons souvent des confusions autour de cette notion qui est bien plus complexe qu’elle ne paraît, en particulier dans ce qui caractérise la relation entre un URI et sa Ressource.

Persistance des URI

Voici un premier sujet de confusions. La recommandation « Architecture of the World Wide Web, Volume One» du W3C, co-rédigée par Roy Fielding, nous explique l’importance de la notion de persistance des URI, dont elle donne une définition :

« the term URI persistence is used to describe the desirable property that, once associated with a resource, a URI should continue indefinitely to refer to that resource» 

Cette règle est simple : les URI doivent être affectés durablement.

Ce principe est cependant parfois mal compris. Ainsi, on peut parfois lire ou entendre qu’il y a un cas intéressant de non respect de cette règle :

• l’URI http://www.aeon-consulting.fr/an-application/1.0 pointe vers la Ressource « Version 1.0 de l’application ‘an application’»  de manière définitive
• l’URI http://www.aeon-consulting.fr/an-application/last pointe vers la Ressource « Dernière version de l’application ‘an application’» , qui peut correspondre de manière temporaire à la Ressource précédente (tant que la version 1.0 de l’application est la version la plus récente).

Il s’agirait là d’une utilisation pertinente d’un URI non persistant. Cette vision est erronée car la Ressource « Dernière version de l’application ‘an application’»  n’est pas la même que la Ressource « Version 1.0 de l’application ‘an application’»  : il s’agit de deux objets distincts. La confusion vient simplement du fait que temporairement, ces deux URI permettent de récupérer deux représentations identiques.

Notons que si nécessaire, le protocole HTTP fournit les mécanismes de redirection qui permettent d’indiquer aux agents que l’URI d’une Ressource a changé (via les codes 3XX des réponses HTTP).

Signification des URI

Signification des URI et état des Ressources

Utilisation d’URI significatifs, ou transparents

Dans le Web que nous utilisons tous les jours, on trouve fréquemment des URI significatifs : en effet, la connaissance de l’URI d’une Ressource parente nous permet (presque !) de retrouver les URI des Ressources filles qui nous intéressent. Il est donc naturel de suggérer pour nos Ressources des URI structurés, significatifs et descriptifs, voire même prévisibles.

Voici à titre d’exemple l’URI d’un article de ce blog, très significatif pusqu’il porte la date et le titre de l’article :

http://…/blog/2009/07/08/comprendre-rest-partie-1-ressource/

Utilisation d’URI non significatifs, ou opaques

La même recommandation du W3C nous indique qu’un URI n’est pas nécessairement significatif :

« The choice of syntax for global identifiers is somewhat arbitrary, it is their global scope that is important» 

Il s’agit du principe d’opacité des URI : un URI est un identifiant, il sert uniquement à identifier une Ressource pour permettre de la référencer. Il ne doit pas servir à donner des informations sur l’état de la Ressource, ce sont les Représentations de la Ressource qui jouent ce rôle, comme nous l’indique ce même document :

« It is tempting to guess the nature of a resource by inspection of a URI that identifies it. However, the Web is designed so that agents communicate resource information state through representations, not identifiers» 

Nous reviendrons ultérieurement sur la notion de Représentation. Voici à titre d’exemple une version opaque de l’URI de notre article de blog :

http://…/blog/126/

Cet URI est opaque car il porte un identifiant technique et non plus la date et le titre de l’article (qui sont des informations sur l’état de la Ressource article, qui peuvent en outre évoluer et donc violer la règle de persistance énoncée précédemment).

Un peu de recul…

Mais alors, que choisir entre URI significatifs et URI opaques ? En fait REST n’interdit pas l’utilisation d’URI significatifs, la contrainte est uniquement dans le fait qu’une Ressource doit avoir un identifiant. Le choix entre opacité et transparence des URI est et restera un sujet subjectif. Bien souvent, c’est la sémantique que l’on souhaite mettre en place dans la construction des URI qui permettra de faire un choix.

Signification des URI et format de Représentation des Ressources

Un URI ne doit pas servir à donner des informations sur le format de représentation de la Ressource :

« In general, one cannot determine the type of a resource representation by inspecting a URI for that resource. For example, the ‘.html’ at the end of ‘http://example.com/page.html’ provides no guarantee that representations of the identified resource will be served with the Internet media type ‘text/html’. The publisher is free to allocate identifiers and define how they are served» 

En effet, ce rôle est notamment assuré par la Négociation de contenu, qui fera l’objet d’un post ultérieur. Cette règle très importante n’est pas intuitive car elle n’est pas respectée par la plupart des URI que l’on manipule quotidiennement sur le Web.

Signification des URI et actions opérées sur les Ressources

De la même manière, un URI ne doit pas servir à donner des informations sur les actions opérées sur les Ressources : c’est la méthode HTTP qui joue ce rôle, comme nous le verrons dans un post ultérieur dédié à la notion d’Interface uniforme. Là encore, cette règle très importante n’est pas intuitive car elle non plus n’est pas respectée par la plupart des URI que l’on manipule quotidiennement sur le Web.

Syntaxe des URI

Sur ce point, REST n’impose rien explicitement. Cependant, les règles suivantes de syntaxe sont souvent mises en œuvre :

• utilisation du caractère ‘/’ pour aller du niveau le plus général au niveau le plus spécifique : /Dossier1/Fichier2 par exemple
• utilisation du caractère ‘,’ pour indiquer des éléments ordonnés : /coordonnees/43.55197,1.489613 par exemple
• utilisation du caractère ‘;’ pour indiquer des éléments non ordonnés : /couleurs/bleu;vert par exemple
• utilisation des caractères ‘?’ et ‘&’ pour indiquer des paramètres, souvent pour des Ressources générées dynamiquement : /search?q=aeon&hl=fr

Ajoutons que la limitation de la taille des URI à 256 caractères est loin derrière nous : les serveurs ont aujourd’hui des limitations de quelques milliers de caractères.

Mais au fait, quel est le lien entre URI et URL ?

Le terme URI fait penser à un terme bien connu dans le Web que nous utilisons tous les jours : URL (Uniform Resource Locator).

Quelle est donc la différence entre ces deux termes très proches, souvent amalgamés ? La RFC 2396, qui définit la syntaxe des URI, nous donne une réponse explicite :

« A URI can be further classified as a locator, a name, or both. The term « Uniform Resource Locator»  (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network « location» ), rather than identifying the resource by name or by some other attribute(s) of that resource» 

Les puristes REST auront peut-être repéré que dans cet article, on a davantage évoqué « REST appliqué à HTTP»  que « REST tout court» . Il s’agit d’un choix volontaire : d’une part, rappelons que le Web est une application des principes REST (et non l’inverse). HTTP 1.1 a été conçu afin de permettre cette application. D’autre part, cela permet de donner un aspect pragmatique à ces explications, dont le but est de clarifier les caractéristiques de REST.

Depuis son apparition il y a 9 ans, et plus particulièrement ces toutes dernières années, REST en intéresse plus d’un : beaucoup de monde en parle et déclare « en faire» .  Mais en pratique, beaucoup d’interrogations demeurent sur ce qu’est réellement REST et sur ce que ce n’est pas. Plutôt que de s’appuyer comme d’habitude sur un unique article qui deviendrait vite volumineux et difficile à appréhender, j’ai choisi de vous présenter REST en une dizaine de notions que nous allons aborder de manière incrémentale et pragmatique. Ces articles n’ont pas vocation à être exhaustifs mais simplement à mettre en lumière de manière structurée les caractéristiques essentielles de REST en essayant de faire disparaître la plupart des incompréhensions.

Ce premier article est consacré à la notion de « Ressource» .

Notion de Ressource

Une Ressource ? Mais tout le monde sait ce que c’est !

Peut-être serez-vous surpris de découvrir que le premier article de cette série concerne la notion de Ressource. Après tout, il s’agit d’un mot banal, bien ancré dans le jargon quotidien de l’informaticien. Et bien justement, ce mot est tellement employé qu’il est devenu difficile de savoir sa définition précise, dans le cadre de REST notamment. Lors de mes missions, on me demande parfois cette définition, ce qui m’amène à chaque fois à commencer ma réponse par le sondage suivant : « Comment définiriez-vous une Ressource ?» 

Et cela ne rate jamais, les réponses sont divisées en deux groupes :

• certains pensent qu’une Ressource correspond à un objet métier manipulé par l’application : par exemple, des contrats, des clients, etc. Généralement, l’idée associée est qu’un service REST correspond à un simple service de type CRUD sur ces objets métier (je ne m’attarde pas sur ce point précis qui fera l’objet d’un prochain article)
• d’autres pensent à une Ressource comme quelque chose de flou, tournant autour de tout et de rien : naturellement, cette définition peu précise contribue largement aux incompréhensions autour de REST. Cependant, nous allons le voir, elle n’est paradoxalement pas si loin de la vérité…

Commençons donc par la base : qu’est-ce qu’une Ressource (dans le contexte REST) ?

Définition d’une Ressource

Dans sa fameuse thèse, Roy Fielding nous donne une définition large et ouverte :

« Any information that can be named can be a resource: a document or image, a temporal service (e.g. « today’s weather in Los Angeles» ), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource« 

Autrement dit : peut être une ressource tout objet assez important pour être référencé en tant que tel.

La recommandation « Architecture of the World Wide Web, Volume One»  du W3C, co-rédigée par Roy Fielding, est très explicite sur l’ouverture volontaire de cette définition :

« We do not limit the scope of what might be a resource» 

Rappelons au passage que le Web est une application des principes REST (et non l’inverse). Il est donc essentiel de bien comprendre son architecture.

Et voilà, c’est aussi simple que cela. Vous l’aurez peut-être deviné, le prochain article de cette série sera consacré à la notion d’URI.

Nos consultants aiment partager leurs découvertes, expériences et savoir-faire : les pages de nos Carnets de Vol seront postées dans ce blog au fur et à mesure et ces articles seront l’occasion d’échanger avec vous sur des sujets variés, techniques ou non.

Bonne lecture !