Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Fusion BEA / Oracle

Agilité

• Traçabilité

Le coin de la technique

• Maven et Eclipse : la fin du calvaire ?
• Les conseils de Ben Alex, Spring Security, pour sécuriser ses applications
• Retour sur les enumerations avec Joshua Bloch
• Les principes architecturaux de LinkedIn

Actualité éditeurs / SSII

Fusion BEA / Oracle

Le 1er juillet 2008, un webcast public annoncera (enfin) comment seront intégrés les produits BEA dans la suite Oracle Fusion Middleware.

Agilité

Traçabilité

La communauté agile relance le débat sur l’utilité des matrices de traçabilité des exigences dans les projets agiles, à travers ce fil de discussion rapporté par InfoQ :

• Il faut déjà distinguer le besoin de traçabilité et la matrice de traçabilité qui n’est qu’une implémentation.
• Si la traçabilité est demandée, il faut poser les questions : pourquoi faire ? sous quelle forme ? la valeur ajoutée est-elle supérieure au coût ?

Sur l’un de ses projets, Alistair Cockburn raconte qu’après étude du coût de l’installation d’un outil de traçabilité et de sa maintenance, la traçabilité a simplement été enlevée du contrat.

• Ron Jeffries propose de faire les changements et de voir quels tests échouent pour voir les impacts.

La communauté agile est en accord et pose la question : Y’a t-il un réel besoin de traçabilité ? Même si c’est le cas, la matrice de traçabilité est une solution trop coûteuse. Les besoins de traçabilité peuvent être couverts par la pratique du TDD et l’utilisation d’outils simples comme un système de contrôle de versions (SVN), un outil de gestion des bugs/changements (JIRA), un wiki, etc.

La discussion complète est sur Yahoo! Tech groups – Requirement Traceability Matrix and Agile Testing.

Le coin de la technique

Maven et Eclipse : la fin du calvaire ?

Qui n’a jamais râlé à propos de l’intégration Maven dans Eclipse ?

Et bien une page est en train de se tourner, dans le Maven Community News de mois de mai, Arnaud Héritier annonce l’entrée des plugins IAM (Q4E) et M2E (m2Eclipse) dans l’incubateur Eclipse.

Jusqu’à présent, seul Ant disposait d’une intégration fine à Eclipse. Sans la participation ni communication active de la communauté Eclipse, les plugins Maven étaient amenés à effectuer des soudures par leurs propres moyens. Ce qui explique certainement la relative non-fiabilité des plugins existants.

Pour sa prochaine release, Eclipse a finalement changé son fusil d’épaule, relançant de plus belle la compétition entre les deux plugins (cf les scopes IAM et M2E). Nous pouvons espérer la sortie officielle d’un plugin de qualité dans un futur proche.

Les conseils de Ben Alex, Spring Security, pour sécuriser ses applications

Ben Alex, Spring Security (ex Acegi Security), a présenté JavaOne 2008 dans addressing tomorrow’s security requirements in enterprise applications les enjeux de sécurité des applications java. Nous retiendrons ses tuyaux pour les applications d’entreprise :

• Utiliser un framework de sécurité éprouvé plutôt que de réécrire le sien
• Commencer simplement et ajouter incrémentalement la complexité
• Anticiper les besoins d’enregistrement des utilisateurs
• Planifier la fédération des identités, particulièrement avec OpenID [1]
• Pour les applications internes, considérer NTLM et CAS
• Utiliser les techniques de Captcha pour limiter les attaques par déni de service (DoS)
• Préférer les autorisations sur les méthodes Java aux autorisations web sur les URL
• Décrire les métas-données d’autorisation avec des annotations est simple et rapide
• Considérer avec la plus grande attention la sécurité des objets de domaine
• Préférer la Basic authentication sur HTTPS pour les interactions REST
• Utiliser la richesse des standards Web Services Security (WSS) pour les échanges SOAP indépendants du transport (HTTP, JMS, etc)

[1] On se souviendra tout de même des reproches actuellement faits à OpenID (cf. The problem with OpenID, The Identity Corner)

Retour sur les enumerations avec Joshua Bloch

Joshua Bloch, l’auteur d’Effective Java, a rappelé à JavaOne 2008 dans More Effective Java le vaste champ d’application des énumérations. Nous retiendrons :

• Ne pas utiliser ordinal pour porter des données de type entier ; utiliser un champ int
• Ne pas utiliser de bit fields ; utiliser un EnumSet
• Ne pas utiliser ordinal pour pour indexer les tableaux ; utiliser EnumMap
• Ne pas utiliser readResolve pour un singleton serializable ; utiliser une enum
• Simuler l’extensibilité des énumérations avec des interfaces

Nous ne reviendrons pas sur le débat « Les énumérations sont un mauvais pattern car elles empêchent l’extensibilité ». Si ce reproche est parfois justifié, nous retiendrons que Joshua Bloch propose le pattern des interfaces pour maîtriser ce risque et qu’il n’a jamais été aussi facile de refactorer et recompiler une application. Quant à la demande d’évolution « ajouter un troisième sexe en plus de Gender.MALE et Gender.FEMALE« , …

Les principes architecturaux de LinkedIn

La semaine dernière, nous reprenions dans la revue de presse un article sur les grands principes architecturaux de eBay.
Lors du JavaOne 2008, c’est le site communautaire LinkedIn qui s’est dévoilé.
Nous reprenons ici les grandes lignes des 2 présentations suivantes : LinkedIn Communication Architecture et LinkedIn : a professional social network…

Commençons par quelques chiffres. LinkedIn c’est :

• 22 millions de membres
• 4+ millions de visiteurs uniques par mois
• 40 millions de pages vues par jour
• 2 millions de courriels envoyés par jour

Architecture physique

• 100% Java
• Tomcat et Jetty, sur Solaris
• Oracle et MySQL, interrogés directement en JDBC (pas de mapping Objet / Relationnel)
• ActiveMQ comme système de messaging
• Lucene comme base de la fonction de recherche
• Spring pour la communication entre éléments

Pratique intensive de l’Agilité

• Accent fort porté sur le test
• Cycles de développements courts (2 à 4 semaines)
• Découpage des développements en petites unités
• Peu de réunions formelles, utilisation de réunion de type ‘stand-up’
• Plus de 6500 tests unitaires et 500 tests de l’IHM
• Intégration continue avec Hudson, nightly builds
• Utilisation de Mock pour réduire la redondance des tests d’intégration
• Refactoring constant

Architecture orientée service

• La webApp présente l’interface graphique aux utilisateurs mais s’appuie sur une couche de Services.
• Chaque Service utilise sa propre ‘partition’ de base de données (partitionnement ‘fonctionnel’)
• Utilisation de répliques de la DB, et distribution des mises à jour, à partir du master, par l’utilisation d’un bus d’évènements
• Utilisation massive de flux asynchrones
• Découpler au maximum les interactions entre service, ce qui permet de réduire les inter dépendances du code.
• Cette architecture est scalable service par service

Un serveur est dédié à la représentation de l’ensemble du réseau LinkedIn (The Cloud)

• Représentation de la totalité de l’arbre en mémoire (22 millions de noeuds, 140 millions de liens)
• L’arbre consomme 12 Go de RAM sur 40 instances
• La reconstruction du réseau from scratch prend plus de 8 heures
• L’arbre est mis à jour en temps réel par le bus d’évènements
• Ce choix découle directement de la difficulté fonctionnelle à partionner l’arbre

Grands principes de scaling (les points soulignés sont les mêmes que ceux exposés par eBay)

• Partionner par domaines fonctionnels
• Le partitionnement rend difficile l’intégrité référentielle cross domaine
• L’intégrité totale des données n’existe pas
• A grande échelle, les coûts matériels deviennent un problème à prendre en compte
• Les spammers et les ‘voleurs de données’ sont un problème
• Utiliser le cache, même s’il a une efficacité limitée
• Utiliser des traitements asynchrones
• Les tâches d’analyse et de consolidation de rapport doivent être prises en compte dès le design initial
• Prévoir les cas d’échec du système, ils ne manqueront pas de se produire
• Ne sous estimez pas la croissance de votre site

Pourquoi préférer Java

• Avec plus d’1 million de lignes de code, Java permet :
  1. De refactorer en toute confiance
  2. De naviguer facilement dans le code source
  3. De maintenir une vingtaine de branches en parallèle, le compilateur aidant à réaliser la fusion
• Il est facile de faire monter l’équipe en puissance :
  1. Plus de 8 équipes, 50 ingénieurs, en constante augmentation
  2. Il est facile de trouver des développeurs Java de talent
• La communauté Java est grande et active

Conclusion

Comme on peut le voir, l’architecture de LinkedIn a beaucoup de points communs avec celle d’eBay, en particulier lorsque l’on s’intéresse de près aux concepts qui permettent à ces deux sites d’offrir un service performant à des millions d’abonnés. Ces grands principes architecturaux apparaissent donc comme incontournables pour toute application visant à supporter une lourde charge.