Publié par

Il y a 11 ans -

Temps de lecture 11 minutes

Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Agilité

RIA

SOA

Le coin de la technique

Agilité

L’enfer de Scrum !

Kelly Waters aborde ici les difficultés rencontrées par certains ScrumMasters qui essaient d’implémenter Scrum avec des équipes qui n’en ont jamais fait.
Il donne quelques conseils pour appréhender cette situation, à commencer par garder son backlog en ordre. Il faut aussi résister à l’envie de changer la méthode pendant les premières itérations. Ce point peut sembler anti-agile mais comme l’a écrit Ken Schwaber, avant d’adapter une méthode il faut d’abord la comprendre et pour ça il faut l’appliquer telle quelle. Il démontre ces propos en se basant sur les étapes du développement d’une équipe de Bruce Tuckman :

  • Formation : comportement individualiste des membres de l’équipe, le chef doit se montrer dirigiste.
  • Confrontation : les membres s’affirment et confrontent leurs points de vue. Continuer à appliquer Scrum efficacement pendant cette étape difficile est ce que Kelly appelle l’enfer de Scrum. Les membres doivent faire preuve de maturité pour passer cette étape.
  • Normalisation : les membres ajustent leur comportement entre eux, ils apprennent à travailler ensemble.
  • Production : l’énergie de l’équipe est canalisée sur la tâche à réaliser. Les membres sont compétents, autonomes et capables de prendre les décisions sans supervision.

L’équipe doit persévérer pour atteindre la dernière étape, nécessaire pour devenir une équipe auto-organisée.

RIA

RIA et le référencement

Les technologies RIA rencontrent de plus en plus d’adhésion, mais l’un des problèmes majeurs de ces technologies est le référencement. Dans cet article de Francois Le Droff, celui-ci nous présente quelques solutions:

  • La première consiste à mettre en place une page HTML « miroir » afin que les moteurs de recherche puissent indexer le contenu de celle-ci. Avec l’aide d’un script Javascript, il est ensuite possible de rediriger les internautes arrivés via le moteur de recherche vers la version Flash du site. La librairie Javascript SWFObject permet également d’inclure du contenu SWF dans une page HTML très facilement.
  • Une autre est la fonctionnalité de deeplinking. Cette fonctionnalité permet de créer des points d’entrées dans l’application. Cette solution est proche de l’approche REST.
  • Enfin il y a l’exposition des données en premier. Cette technique s’appuie sur le support XSL des navigateurs. La technique consiste à avoir une page HTML ne contenant que des données et le SWF est injecté par transformation XSL. Cette technique est notamment utilisée dans Flex Directory.

Apparemment cette dernière technique fonctionne assez bien, car les sites utilisant cette solution sont bien référencés sur Internet.

Google héberge les librairies AJAX

Excellente initiative de Google, qui a décidé d’héberger les librairies AJAX les plus connues via l’API AJAX libraries.

L’idée extrêmement simple est de centraliser l’hébergement de librairies telles que prototype ou jQuery. Lorsqu’un internaute accède pour la première fois au site A, qui utilise la librairie jQuery hébergée chez Google, il télécharge la librairie. Lorsqu’il accède ensuite au site B, qui utilise la même librairie dans la même version, également hébergée chez Google, il n’a pas besoin de re-télécharger la librairie, et le chargement de la page est donc plus rapide.

Les headers HTTP sont également correctement positionnés afin d’optimiser la gestion en cache des librairies par le navigateur.
Google a travaillé en accord avec les différentes équipes éditant les librairies (aujourd’hui jQuery, prototype, script.aculo.us, dojo et mootools), et d’autres librairies seront prochainement également hébergées.

SOA

Tuscany devient un Top Level Project de la fondation Apache

Le framewok Apache Tuscany devient un Top Level Project de la fondation Apache 6 mois après la sortie de sa version 1.0. Nous annoncions le mois dernier la promotion de CXF c’est apparemment la saison des promotions. Quel sera le prochain projet à sortir de l’incubateur : les paris sont ouverts !

Tuscany propose l’implémentation d’un runtime SCA (Service Componant Architecture) visant à simplifier la création et la composition de services (indépendamment de leur implémentation) dans le cadre d’Architectures Orientées Service (SOA). Pour plus d’informations sur ce sujet, nous vous laissons consulter l’introduction à SCA que nous avions publiée l’année dernière.

Profitons de cette occasion pour rappeler que SCA n’est pas un concurrent direct à OSGI. OSGI permet de gérer les dépendances et version de services, SCA décrit les interactions entre composants à un niveau plus élevé (QOS policies / network protocols). Il est donc tout à fait possible d’utiliser OSGI avec SCA.

Enterprise Integration Patterns for Security

La sécurité des échanges est souvent un parent pauvre de l’intégration d’applications et des approches SOA. Eric Newcomer, IONA, nous propose ses Enterprise Integration Patterns for Security des approches pour gérer les problèmes de propagation des identités et de la confidentialité lors des changements de transports (SOAP/HTTPS -> CORBA/CSI_v2, etc) :

  • Message Protection : à la différence du Transport Protection qui sécurise le « tuyau » (https, middleware de message, etc), c’est le contenu du message lui même qui est protégé. Seuls le service provider et le service consumer ont accès au message (lecture et écriture) ; les intermédiaires sont aveugles.
  • Token Propagation : les intermédiaires transmettent sans les modifier les tokens associés au message (signature, etc).
  • Token Mediation : les intermédiaires enrichissent/modifient les tokens associés au message.

Gardons tout de même en mémoire que si ces patterns sont utiles dans des environnements très sécurisés (transactions financières, non répudiation, etc), la simple sécurisation du transport (https + basic authentication) est le plus souvent suffisante.

Le coin de la technique

Rod Johnson présente la stratégie de Spring Source

Après la sortie surprise de Spring Source Application Platform (s2AP) le mois dernier et la mini polémique liée à l’utilisation d’une licence GPLv3, Rod Johnson présente la stratégie de Spring Source dans Open Source, Open Strategy: The SpringSource Manifesto. Les points essentiels :

  • Spring Source se lance dans l’édition de middleware avec S2AP qui est destiné à concurrencer des leaders comme Websphere et Weblogic. Sur ce domaine, Spring Source a décidé de protéger ses investissements en utilisant une licence open source business unfriendly (GPL v3) destinée à empêcher d’autres acteurs de monétiser ces technologies sans en partager les fruits avec Spring Source.
  • Cette nouvelle activité d’éditeur ne change rien à l’implication de Spring Source dans les frameworks open source qui conserveront leur licence business friendly Apache. La contribution de Spring Source sur ce domaine n’a d’ailleurs jamais été aussi intense grâce aux levées de fond qui permettent de salarier les contributeurs.

Configuration Spring : XML, annotations ou code java ?

Rod Johnson présente dans Configuring the Spring Container (pdf) les avantages et inconvénients des différentes techniques de configuration offertes par Spring Framework. Nous retiendrons synthétiquement :

  • Le XML classique est riche, facile à comprendre et externalisé du code mais verbeux et peu propice au refactoring
  • Les Namespaces XML améliorent la compacité et la compréhension. Cependant, la création de nouveaux namespaces est plutôt destinée aux éditeurs qu’aux équipes d’informatique de gestion qui auront elles intérêt à limiter cette possibilité aux composants réutilisé extrêmement souvent.
  • La configuration par annotations est très compacte et refactoring-friendly mais devient délicate lorsqu’on utilise des qualifiers (cf @Qualifier) et est inadaptée à l’utilisation de placeholders (${…} ) comme à l’intégration de jars qui n’ont pas été annotés.
  • La Configuration Java, toujours en version beta, apporte l’héritage des configurations et la gestion de la visibilité des beans en plus d’être refactoring-friendly mais déroute par l’utilisation de méthodes abstraites et rencontrera l’hostilité des défenseurs de la séparation entre le code et la configuration.

eBay expose les grands principes d’une architecture dimensionnable

Randy Shoup, architecte en chef de l’infrastructure de recherche d’eBay, révèle sur InfoQ les grands principes d’achitecture qui permettent au site d’enchères de gérer des centaines de millions d’utilisateurs, des petabytes de données, et plus de 2 milliards de pages vues par jour.

1. Partitionner par pan fonctionnel
Au niveau du code, c’est un réflexe que la majorité des développeurs possède : découpage en packages, jars, bundles… eBay applique ce principe au niveau des serveurs d’application : chaque fonctionnalité (enchères, ventes, gestion de utilisateurs…) est déployée sur un pool de serveurs. Celà permet une meilleure gestion des dépendences et un dimensionnement en fonction de la consommation en ressources des différents pools.
Au niveau de la base de données, le même principe de segmentation est appliqué : eBay utilise plusieurs ensembles de databases, regroupés par pan fonctionnel (utilisateurs, enchères, produits…).

2. Monter en charge de manière horizontale
Au niveau des serveurs d’application, le design Stateless d’eBay rend l’exercice trivial, par l’utilisation de simple load balancers.
Le réel enjeu se situe au niveau de la base de données, où les données sont splittées selon leur chemin d’accès primaire (par exemple, les utilisateurs peuvent être répartis sur 20 instances, chacune contenant 1/20ème des utilisateurs). Il existe plusieurs stratégie de partitionnement : modulo sur la clé primaire, par plage de valeur, par table d’indirection, ou une combinaison de plusieurs de ces méthodes.

3. Eviter les transactions distribuées
Les transactions distribuées (two-phase commit) sont proscrites chez eBay. Dans la majorité des cas, chaque opération sur la base est auto commitée. Ce principe repose sur une vision optimiste de l’architecture, en admettant que la majorité des composants du système sont disponibles au temps T.
La consistance des données est garantie par diverses techniques : séquencement ordonné et réfléchi des opérations sur la base, système de recovery asynchrone, batch de réconciliation et de correction.
La consistance des données ne doit pas être vue comme ‘tout ou rien’, mais doit être ajustée en fonction de la criticité des opérations et des données.

4. Découpler les fonctionnalités de manière asynchrone
En utilisant des processus asynchrones, on peut facilement découpler certaines fonctionnalités et par là même découpler leur dimensionnement.
Ce principe vaut aussi au niveau du découpage entre composant : décomposer chaque traitement en étapes ou en phases, enchainées de manière asynchrone est un élément clé d’une architecture scalable.

5. Déporter les traitements lourds du coté asynchrone
Maintenant que les fonctionnalités sont découplée de manière asynchrone, il faut déporter les traitements les plus lourds du coté asynchrone.
Ainsi, l’utilisateur obtient rapidement une demande à sa requête, alors que le backend continue ses traitements. « Tout ce qui peut attendre doit attendre ».
L’utilisation de l’asynchronicité permet aussi de gommer la notion de pic de charge, et de dimensionner son architecture pour absorber une charge moyenne (le pic de charge est étalé dans le temps).

6. Utiliser un maximum de couches d’abstraction
Par exemple, la base de données est « virtualisée » par l’utilisation d’un framework O/R « maison ». Ainsi, la complexité de l’organisation des données est masquée.
De la même façon, le moteur de recherche, complexe (requêtes multi bases, agrégation…) est abstrait.
Cela permet non seulement de simplifier le travail des développeurs, mais aussi aux équipes opérationnelles d’intervenir de manière complètement indépendante des développements, en cas d’ajout d’infrastructure ou de réorganisation physique des données.

7. Mettre en cache à bon escient
Ce principe est moins universel que les précédents, car fortement lié à la nature des données manipulées.
Chez eBay, les seules données cachées sont les données ayant de faibles probabilités de changement : métadonnées, configuration, données statiques. Les données transiantes, les données en lecture/écriture subissant des changements rapides, sont volontairement laissées hors du scope du cache, et ce au profit d’une plus grande disponibilité.
Il faut cependant noter que certains sites ont choisi une stratégie inverse et s’en sortent de manière tout à fait honorable.
Dans tous les cas, la stratégie de mise en cache doit être adaptée à la situation, et permettre de maximiser les performances globales, sans sacrifier la disponibilité.

Kohsuke Kawaguchi à temps plein sur Hudson

Le principal (et originel) développeur d’Hudson vient d’annoncer que son employeur (Sun) lui a demandé de travailler désormais à plein temps sur Hudson, le serveur d’intégration continue qui monte (voir le post d’Eric Lefevre sur des statistiques récentes de téléchargement d’Hudson et CruiseControl).

Au delà des corrections d’anomalies, Kohsuke réfléchit à de nouvelles fonctionnalités, afin de compléter la compilation et les tests. Il aimerait par exemple permettre au développeur d’être notifié lors d’un souci sur les tests unitaires, afin de lui permettre de se connecter avec un debugger à distance sur Hudson, ce qui lui éviterait de reproduire le problème en local…

Kohsuke y passait déjà ses nuits, il va maintenant y passer ses journées ET ses nuits!

Publié par

Publié par Xebia France

Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 15 ans, nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.