Evènements

Découvrir l’architecture du www à Devoxx

Publié le : Auteur: Frédéric LEFEBVRE 3 commentaires
evenement

J’ai pu assister le mois dernier à la conférence Devoxx. Elle rassemble quelques 1500 personnes lors de 3 jours de conférences non stop autour de la plateforme Java. Elle est organisée pour la 2ème année par le ParisJug.

En quelques mots Devoxx c’est :

  • 3 jours dans le centre de Paris
  • Pleins de format différents (conférence, quickie, university, tool in action, Bof)
  • 1400 inscrits
  • 180 speakers
  • 74 conférences
  • 6 salles
  • 1 thème : le passé, le présent et le futur

Lors de Devoxx, j’ai découvert le développement d’application web, pas celui des entreprises traditionnelles mais celui des géants du web (Google, Facebook, Twitter) et des startups.
Leurs motivations : faire des applications qui plaisent et répondent à un besoin immédiat avec des outils et techniques simples. Leur plateforme : le web.

WOA, l’architecture orienté Web

Un système d’information moderne supporte des charges transactionnelles lourdes, s’adapte mécaniquement à l’augmentation du nombre d’utilisateurs, surfe sur l’innovation technologique, est totalement ouvert vers l’extérieur tout en étant sécurisé en profondeur, et surtout s’adapte en temps réel à des coûts maîtrisés aux évolutions et contraintes du business. Habib Guergachi

Après cette description idéale, Habib Guergachi durant sa présentation « Web Oriented Architecture, une transmutation des pratiques de construction des SI », a déployé tous ses talents d’orateurs pour nous convaincre que l’approche traditionnelle de développement de SI ne peut pas répondre à la définition d’un SI moderne qu’il donne (paragraphe ci-dessus). Le principal problème qu’il pointe est le désir d’avoir un système surprotégé où tout est fait en sorte que le pire ne puisse arriver.

Exemple de protections typiques d’un SI entreprise :

  • Les composants logiciels tiers (librairies, progiciels, …) sont intégrés dans le SI lui-même, le but recherché étant de garder la maitrise de son environnement
  • Quand une communication est inévitable, on intercale un ensemble d’interfaces entre les logiciels (un ESB par exemple)
  • Le matériel et les couches basses sont conçus pour palier à toute défaillance ou problème
  • Les échanges sont réalisés de manière synchrone et transactionnelle pour être sûr de la bonne exécution avant de poursuivre le traitement
  • On utilise des langages et outils matures (plusieurs années d’existence et validés par la cellule X de l’entreprise)
  • On se méfie de la nouveauté (pas stable)
  • On réalise des déploiements en pré production où des personnes valident des scénarii, pour assurer la bonne marche

En plus de brider la créativité des concepteurs ou celle des utilisateurs, tout ceci a bien entendu des répercussions sur la complexité et les performances du SI. Dans ce SI, les développeurs sont concentrés sur des problématiques techniques et peu sur le fonctionnel. Alors que le fonctionnel est la véritable valeur ajoutée.

D’autant plus que comme le dit la loi de Murphy : « Tout ce qui peut mal tourner, va mal tourner ».

Donc puisque cela va mal tourner, pourquoi autant de précautions ? Pourquoi ne pas simplifier, faire sauter les gardes fous ? Vous me direz oui d’accord mais attention c’est dangereux ! Et vous avez raison, ça comporte des risques. Mais on va pouvoir réduire ces risques grâce à :

  • des solutions simples qui pourront aisément être adaptées
  • des langages et outils productifs
  • un processus de développement rapide et Agile
  • des tests automatisés
  • un déploiement en production le plus fréquent possible
  • l’utilisation de services fournis par des tiers pour gérer les besoins qui ne sont pas votre métier

Pour concevoir un SI moderne, il faut donc oublier nos réflexes habituels. Faire un reset. Pourquoi utiliser Websphere, Weblogic ou Java ou encore JSF ?

Et WOA dans tout ça ? J’y viens, pour relever le challenge on va avoir besoin d’une architecture simple qui puisse gérer la sécurité, la scalabilité et l’interopérabilité avec les autres composants.

Pour concevoir notre architecture, partons dans le sens inverse. Je veux dire du navigateur, le composant principal du web. Dans ce navigateur je dispose :

  • du langage HTML
  • des feuilles de style CSS
  • du langage Javascript
  • du protocole de communication http

Ceci doit être la base de notre système.

N’importe quel système d’information comprend au moins un service métier et une ou plusieurs interface utilisateur.

L’accès aux données et aux services métier

Pour fonctionner l’application utilisera les ressources disponibles sur le réseau d’entreprise ou Internet. Chaque ressource (ex : une fiche client) possède une ou plusieurs représentations (content-type), et est accessible par une URI et pourra être manipulée par REST.

REST est la base de notre architecture WOA. REST peut être vu comme le remplaçant de SOA. Il a l’avantage d’être plus simple et directement utilisable dans le navigateur ou un autre outil comme un shell par exemple.

Exemple d’API REST :

/bookmarks /bookmarks/bookmark/{id}
GET Liste des URI des bookmarks existant (URI = ‘/bookmark/{id}‘) Détails du favori
POST Ajout d’un favori Non
PUT Non Mise à jour du favori
DELETE Réinitialiser la liste Suppression du favori

Tutoriel pour développer une API REST en Javascript : http://naholyr.fr/2011/08/ecrire-service-rest-nodejs-express-partie-1/

Autour de cette base, s’est développé un ensemble de pratiques :

elements_of_woa_big

Ces nouvelles applications ont la particularité d’être ouverte, d’intégrer des données d’autres applications (Data Mashups, Open Data). Il est par exemple courant qu’une application web propose à l’utilisateur de se connecter avec son profil Facebook, affiche un fil Twitter ou une carte Google maps.

Pour en savoir plus sur WOA et plus particulièrement REST, je vous recommande la lecture du blog de Dion Hinchcliffe.

L’interface utilisateur de l’application

L’autre élément important d’une application est l’interface utilisateur. Dans une architecture WOA, elle peut être vue comme une application à part entière et donc être développée par une équipe différente de celle qui réalise le service métier.

On utilise au lieu d’intégrer.

Pour la conception de cette application, on assiste à un changement de paradigme :

les traitements de présentation des écrans s’exécutent de moins en moins coté serveur (JSF) mais sur le client (Javascript). Ainsi l’application peut être hébergée sur un simple serveur Apache. Exit Tomcat, Weblogic, et autres.

mig EE to www

Pour développer des applications riches en Javascript (langage du navigateur) on peut s’appuyer sur de nombreux frameworks dont les plus connus sont :

Conclusion

J’espère que ceux qui travaillent comme moi sur des projets « Entreprise » à base d’EJB et d’Enterprise Server, seront intéressés de découvrir les possibilités et surtout la « simplicité du développement Web ».

Pour réaliser sereinement sa première application web il est nécessaire de bien maîtriser le Javascript (Javascript !== Java). Pour débuter Javascript: The goods parts de Douglas Crockford est bien.

ToDo liste du développeur Java :

  • Apprendre les langages du web (Html 5, CSS 3, Javascript)
  • Comprendre REST
  • Développer un prototype
  • Vincent Hanniet

    Intéressant. Mais les traitements « métier » sur le navigateur c’est pas vraiment une bonne pratique ! > plutôt dans un service à interface REST… Sauf bien sûr si tu veux parler de contrôles de surface pour la saisie…

    • Frédéric Lefebvre

      Merci. Dans une application bien souvent l’écran ainsi que la manière dont il réagit dépend de règles métier (ex: un onglet à afficher, un champ ou un bouton à désactiver en fonction d’un état). Dans une conception traditionnelle le navigateur affiche des pages et soumet des formulaires. La construction des pages se déroule sur le serveur. Mais aujourd’hui et depuis un moment déjà il est possible de réaliser ceci directement dans le navigateur grâce à Ajax et à la manipulation du DOM. Mais cette pratique est pour l’instant peu utilisée en entreprise car le navigateur souffre d’une mauvaise image et est relativement peu outillé. Mais les choses changent, les navigateurs se rapprochent en terme de fonctionnalités et énormément d’outils se développent.