Avec la sortie enfin officielle, sûrement retardée avec la fusion Oracle / BEA, de la nouvelle version de Weblogic (WLS 10.3), Oracle a décidé d’offrir gratuitement l’outil de développement associé depuis longtemps avec la suite Weblogic Platform: Workshop. Jusqu’à la version 8.1, cet outil écrit en Swing était propriétaire et extrêmement fermé. Suite au rachat en 2005 de la société M7, BEA avait complètement refondu WorkShop 9 en l’intégrant à la plateforme Eclipse. Cet outil était décomposé en 2 :

un ensemble de plugins qui permettait de gérer le serveur d’application Weblogic Server (gratuit) sous WTP
un ensemble de plugins qui apportait des fonctions avancées de développement, extrêmement efficace mais payant.

Dans un monde ou les outils gratuits sont légions, Workshop avait peu à peu perdu du terrain et commençait à disparaitre. Avec sa gratuité, Oracle espère sûrement devenir (enfin) un acteur majeur du développement Java/JEE. Il reste cependant une question: Quid de JDevelopper ?

Agilité

Vaincre la résistance au changement

Mark Levinson raconte sur InfoQ une session animée par Dave Nicolette et Lasse Koskela lors de la conférence Agile 2008 : Overcoming Resistance to Change.
Quand on rencontre une résistance au changement, la colère et la frustration prédominent : les résistants sont stupides, bornés, etc. Dave propose d’être un peu plus constructifs en se mettant à la place des « résistants » comme le fait Dale Emery dans Rewriting the story of Resistance.
La résistance au changement n’est pas toujours infondée, et dans tous les cas il est important de la comprendre. Les participants ont essayé le jeu de Dale Emery, Resistance as a Resource Game, pour trouver des idées pour répondre à cette résistance au changement.

Les raisons de résistance au changement peuvent être classées en 3 types :

Cognitif : je ne comprends pas ce qui devrait changer, les bénéfices ou comment le changer
Emotionnel : est-ce que je peux faire ça ? Est-ce que je vais aimer ça ? Est-ce que je me sens menacé ?
Comportemental : je refuse qu’on me dise quoi faire

Afin de surmonter la résistance, Dave et Lasse conseillent de n’utiliser que les trois premières des six approches du changement de Kotter et Schlesinger :

Facilitation : aider les employés à gérer leurs craintes pendant la période de transition
Education : communiquer/informer en amont sur l’effort de changement pour aider les employés à voir la logique de cet effort
Participation : impliquer les employés dans l’effort de changement

Johanna Rothman ajoute avec sagesse que lorsqu’on voit de la résistance, il s’agit peut-être du reflet de notre propre résistance.

RIA

FireFox Just In Time Compilateur

Firefox annonce la sortie de TraceMonkey (son JIT JavaScript compiler), inclus dans la version 3.1 du navigateur. La réduction des temps d’exécution de code JavaScript dans les navigateurs web est indispensable avec l’utilisation croissante des frameworks du type Ajax.

Les benchmarks effectués par Mozilla parlent d’eux même : par exemple plus de 6 fois plus rapide pour la manipulation de matrice ou d’image entre Firefox 3.0 et 3.1
C’est ce type de renforcement qui permettrait aux applications Web utilisant les navigateurs comme environnement d’exécution (framework de type Ajax) de se relancer dans le combat des RIA face aux plugins comme Flex et SilverLight.

Le coin de la technique

Tuning et optimisation de Tomcat : mod_jk est mort ! Longue vie à mod_proxy_http !

Mark Thomas, Spring Source, présente dans Optimising and Tuning Apache Tomcat (pdf) les éléments clefs pour assurer la haute performances d’applications déployées sur Tomcat.

Le point probablement le plus surprenant de cette présentation est la technique dorénavant préconisée pour connecter Tomcat à Apache HTTP : le couple extrêmement répandu mod_proxy_http / mod_proxy_balancer est dorénavant préconisé pour connecter Tomcat à Apache HTTP. Le protocole HTTP est aujourd’hui plus fiable que l’historique AJP (Apache JServ Protocol) et les modules mod_proxy_http et mod_proxy_balancer sont sensiblement plus robustes que leur prédécesseur mod_jk (et que son portage mod_proxy_ajp). Plus de détails dans Connectivity Between the Web Server and Application Server – What are Your Options? (vidcast plus étoffé et son viewer) par Jim Jagielski et Filip Hanik, SpringSource/Covalent.

Par ailleurs, nous avons retenu :

Les erreurs récurrentes du troubleshooting Tomcat sont les mêmes que pour les autres applications :
– Optimisation inutile de code avant d’avoir réellement identifié la cause problème.
– Tests insuffisants par volume de données ou charge des tests insuffisants.
– Absence d’objectif clairs de performances.
– Trouver au pifomètre les points de contention.
– Correction du symptôme plutôt que de la cause (ajout de mémoire plutôt que de corriger une fuite de mémoire, etc).
Les outils clefs pour identifier les points de contention sont les logs (applicatives, valve AccessLog tomcat, jvm, sgbd, serveur web, etc) et les profilers (YourKit, etc).
Pour la haute disponibilité, en plus de load balancing, Tomcat propose de la réplication de sessions. Cependant, nous noterons que Mark Thomas ne s’attarde pas sur ce point très délicat et nous remarquerons que les mécanismes de réplication de session de tomcat sont rarement cités pour des architectures de production.
Pour l’exploitation, Tomcat est scriptable avec des tâches Ant ou en JMX grâce à l’application tomcat-manager; nous noterons tout de même que cet outillage est pour le moment moins étoffé que celui des serveurs J2EE open source et commerciaux.

Les pires pratiques des systèmes distribués

… ou comment s’assurer d’obtenir une application non scalable. Nous avons déjà abordé les bonnes pratiques mises en avant par Ebay ou Linked In. Pour InfoQ, Brian Zimmer revient au contraire sur une collection de mauvaises pratiques qui handicaperont la croissance et l’adaptabilité de vos applications.

Ne pas utiliser les middle tiers / API / Pattern à bon escient. Ce n’est pas parce que vous avez un marteau que tous vos problèmes doivent ressembler à des clous.
Surexploiter les ressources partagées. Sur les systèmes massivement distribués, les problématiques de temps d’accès et de disponibilités sont démultipliées et ne peuvent plus être gérées « à courte vue »
Ne pas gérer correctement ses dépendances. Impossible alors de gérer correctement les évolutions des librairies tierces et d’adresser les problèmes de retro compatibilité.
Packager son application en mode « tout ou rien ». C’est s’exposer à avoir une application fourre tout (voire sac de noeuds) qui rend impossible un déploiement modulaire ou une vision orientée service.
Oublier de gérer les timeouts. Dans un système distribué, il est capital d’allouer des timeouts aux différents appels inter systèmes pour prévenir les engorgements.
Le syndrome du chevalier blanc. Il est indispensable de s’appuyer sur une équipe qui est capable de comprendre et maintenir le système en production, et non pas de se reposer sur les épaules d’une seule personne qui ‘connaîtrait’ l’ensemble de l’architecture. Là encore, c’est l’idée de modularité, même dans les ressources humaines, qui doit être mise en avant.
Négliger l’automatisation. Toutes les tâches qui peuvent l’être (build, déploiement) doivent être automatisées, afin d’être reproductibles, et ne pas reposer entièrement sur une seule personne (voir le point précédent).
Sacrifier la supervision. Pouvoir détecter et diagnostiquer un éventuel goulot d’étranglement est la clé de voûte des architectures distribuées efficaces.

Evènements de notre communauté en France et à l’étranger

Des nouveaux JUG !

Developpez.com annonce la création d’un Java User Group (JUG) Breton : le BreizhJug.
Inauguration prévue le lundi 15 septembre avec une soirée GWT. Il sera devancé de peu par le Nantes-JUG qui ouvrira avec une rencontre sur l’Intégration Continue le 11 septembre.
Souhaitons leur autant de succès que le Paris JUG !

Published by Publicis Sapient Engineering

Voir ses Articles

Commentaire

7 réponses pour " Revue de Presse Xebia "

Published by Alexis MP , Il y a 15 ans

JDeveloper est l’offre qui perdure chez Oracle. Heureusement.
Published by Philippe De Oliveira , Il y a 15 ans

En effet, mod_proxy est plus que préconisé depuis un moment. Merci donc à Mark Thomas d’avoir enfoncé cette porte ouverte. Pour ce qui est du tomcat-manager, il est certes moins étoffé que d’autres serveur J2EE (quoi que Tomcat ne soit pas J2EE hein…) mais couvre bien souvent les besoins.
Concernant les sessions partagés, le mécanisme de Tomcat n’est en effet jamais retenu dans les architectures de production (contrairement aux solutions JBoss par exemple. Sauriez-vous pourquoi ? Avez-vous des retours d’expérience sur ce point ?
Published by Cyrille Le Clerc , Il y a 15 ans

Bonjour Philippe,

Pour la réplication de sessions, je note tout d’abord que le failover de session est un besoin très rare car la probabilité d’arrêt/panne d’un noeud d’un cluster est très faible et on peut la plupart du temps demander aux quelques internautes pénalisés de recommencer leur acte de gestion sur un autre noeud. Toutes les applications ne lancent pas des missiles nucléaires :-)

Ensuite, l’approche lightweight de Tomcat plutôt que de recourir a un serveur Java EE complet est souvent antinomique avec la réplication de sessions.

Enfin, les caches distribués sont des technologies assez récentes encore en pleine maturation.

J’ai l’impression que cette conjonction de raisons explique que le mécanisme de réplication de sessions fourni avec Tomcat (le SimpleTcpCluster) est pour le moment rudimentaire (broadcast systématique des données sur tous les noeuds du cluster) et pas vraiment production ready.

Il est de plus intéressant de constater que le serveur d’application Apache Geronimo a peu de synergies avec le projet Tomcat sur ce sujet. Geronimo semble plus intéressé par WADI qui est toujours dans l’incubateur (cf Geronimo Clustering – Initial discussion). L’activité autour de WADI est pour le moment limitée (cf wadi commit log) et on peut douter de la sortie d’une version mature dans l’année à venir.

Pour les caches plus éprouvés, Terracotta semble très bien positionné avec une une tenue à la charge réputée, une intégration à Tomcat bien documentée (cf. Terracotta Tomcat Integration) et du support commercial (Terracotta Tech, SpringSource/Covalent).

JBossCache semble en retrait avec notamment une documentation sensiblement moins étoffée et une communauté moins active que Terracotta dont c’est le coeur de métier.

Quant à Oracle Coherence et IBM Websphere eXtreme Scale, ce sont avant tout des Data Grids au champs beaucoup plus vaste que de la réplication de sessions et il semble plus naturel de les retrouver sur des serveurs Java EE complets.

Cyrille
Published by Julien Dubois , Il y a 15 ans

Bonjour Philippe & Cyrille,
Tout d’abord, et c’est une évidence, il vaut mieux essayer de ne pas répliquer ses sessions. Quand c’est nécessaire, Tomcat propose effectivement une solution simple, mais qui peut convenir pour un environnement qui n’a pas trop de noeuds (si vous n’avez que 2 noeuds, par exemple). Nous avons plusieurs clients en France qui ont choisi ce type de solution.
Je sais également que nous travaillons en interne sur l’amélioration de ce mécanisme : je ne travaille pas dessus moi-même, j’ai juste entendu parlé de Apache Tribes (http://tomcat.apache.org/tomcat-6.0-doc/tribes/introduction.html ) mais je ne peux pas plus m’avancer.
Sinon, comme le dit Cyrille, il y a d’excellentes solutions commerciales, par exemple celle de Terracotta (dont nous sommes effectivement revendeurs). Dans un autre style, Gigaspaces fait également des choses très intéressantes, et nous avons aussi de très bonnes relations avec eux. Bref, si vous avez plus que 2 ou 3 noeuds, je vous conseillerai plutôt l’une de ces solutions, d’autant que vous pouvez avoir un support commercial complet.
Published by Arnaud Héritier , Il y a 15 ans

Le Tours JUG devrait ouvrir le 10 Septembre : http://toursjug.org/

Revue de Presse Xebia

Actualité éditeurs / SSII

Oracle BEA Workshop 10.3 gratuit