3 septembre 2009
Après Tomcat qui rentrait cet été de plain-pied dans l’univers du Java Platform as a Service avec le mariage de SpringSource à VMWare et à CloudFoundry, c’est au tour de l’autre moteur léger de servlets, Jetty/Webtide, de s’adosser à un acteur du Cloud Computing, Intalio, pour développer son offre.
Une reconnaissance méritée
C’est une très belle opportunité pour Jetty qui était jusqu’à présent beaucoup plus embarqué que Tomcat par des grands projets de Cloud Computing (Google App Engine, Hadoop, Gigaspace XAP, etc) mais n’avait pas constitué sa propre offre.
Sur les pas d’Amazon ?
Le mariage d’Intalio avec Webtide est assez différent de celui de SpringSource avec VMWare et Cloud Foundry. Alors que la deuxième union concerne des spécialistes de l’infrastructure, Intalio est lui issu de l’univers des applications CRM et s’étend vers les infrastructures de Cloud Computing comme l’a fait Amazon auparavant.
Des serveurs J2EE lourds absents
Nous remarquerons à l’occasion que les serveurs J2EE heavyweight se font très discrets dans cette période d’avalanche d’annonces sur Java Platform as a Service, on peut s’attendre à ce qu’ils répondent sur cette tendance qui va bouleverser les modes de fonctionnement dans les data centers et menacer leurs parts de marché.
Ils en parlent
19 août 2009
SpringSource continue à dérouler son plan de Java Platform As A Service avec le rachat de Cloud Foundry, le spécialiste de plate-forme Apache / Tomcat / MySQL sur Amazon EC2.
Rod Johnson annonce dans SpringSource Launches Enterprise Java Cloud que SpringSource offrira à ses clients non seulement la possibilité de déployer sur le cloud public Amazon EC2 mais aussi et surtout sur des clouds privés.
Il s’agira vraisemblablement de la mutualisation de nos plates-formes Java actuelles avec un chef d’orchestre Hyperic et des serveurs tc Server (Tomcat augmenté de fonctionnalités d’administration) ; la JVM sera Sun HotSpot et l’OS de prédilection sera RehHat Enterprise Linux (RHEL) même si Windows, Solaris et MacOSX seront proposés (détails ici).
Il ne nous faudra que quelques minutes pour déployer de nouvelles applications web ou pour ajuster les ressources CPU et mémoire allouée à une application par l’ajout ou la suppression de nœuds dans un cluster.
Techniquement, il n’y a pas de rupture par rapport à ce qu’offrent depuis longtemps les serveurs JEE « lourds » (IBM WebSphere, Oracle/BEA Weblogic, RedHat JBoss App Server ou Sun Glassfish).
Cependant, les mentalités ont changé, les esprits sont marqués par la simplicité d’exploitation des Public Clouds. Les équipes d’exploitation sont en train de se transformer, les processus s’allègent et l’offre lightweight de SpringSource tombe à point nommé.
Et la virtualisation matérielle dans tout ça ? Rod Johnson nous dit que la Tomcat Platform As A Service s’exécutera « aussi sur vSphere », le produit phare de son récent acquéreur VMWare. La nuance est forte entre « aussi sur » et « principalement sur ».
Nous le verrons à l’usage, le duo RHEL / Sun JVM sera la couche d’abstraction suffisante pour exécuter la plupart de nos applications Java. Le renfort de la virtualisation matérielle ne se justifiera que dans un nombre limité de cas comme les serveurs J2EE s’avèrent rarement nécessaire face aux simples Tomcat, Jetty ou Glassfish V3 …
17 août 2009
Pourquoi VMWare a racheté SpringSource dont le métier et la culture sont si différents ? Pourquoi un tel prix ?
Mon analyse est que VMWare a racheté SpringSource parce que le cloud computing de forme Platform As A Service (PaaS) à la Google App Engine va bientôt mieux répondre que la virtualisation matérielle aux besoins d’optimisation des data centers Java. Selon l’adage « Si quelqu’un scie la branche sur laquelle je suis assis, mieux vaut que ce soit moi », VMWare s’est dotée de l’expertise de SpringSource sur Tomcat et Hyperic.
Je parlerai des applications Java légères (Servlets, JDBC, JPA et JMS) qui sont aujourd’hui largement majoritaires dans nos data centers Java. Billy Newport, IBM WebSphere, reconnait qu’elles représentent 80% des cas, SpringSource aurait sûrement des chiffres plus élevés.
Lire la suite de cet article »
7 mai 2009
Depuis le rachat de Covalent en Janvier 2008, SpringSource est le premier contributeur au projet Apache Tomcat avec plus de 80% des commits ; Mark Thomas et Philip Thomas en sont les principaux acteurs.
Tomcat est la pierre angulaire de l’offre middleware de SpringSource aujourd’hui composée de tc Server, une version professionnelle Open Source de Tomcat et dm Server, un serveur OSGi (le format d’assemblage que SpringSource préfère aux classiques .war).
Mark Thomas a présenté lors de SpringOne 2009 : Securing Apache Tomcat For Your Environment les points essentiels sur ce sujet qui se décompose en trois thèmes : la confidentialité, l’intégrité et la disponibilité.
Lire la suite de cet article »
5 mai 2009
Une conférence est l’occasion de discuter avec les ingénieurs des difficultés que nous rencontrons à utiliser leurs produits. J’ai profité de ma participation à SpringOne 2009 pour échanger avec Mark Thomas sur le suivi de l’adresse IP des internautes dans les logs d’audit d’applications web. Mark Thomas est des principaux committer du projet Tomcat et de SpringSource tc Server.
Le problème se présente lorsqu’un serveur Tomcat est précédé d’un reverse proxy (e.g. mod_proxy, Squid Cache, etc) ou d’un load balancer (Nortel Alteon, F5 Big-IP, etc) : La méthode HttpServletRequest.getRemoteAddr() ne retourne plus l’adresse IP de l’internaute mais celle du composant réseau qui précède le serveur Tomcat.
Cette perte d’information a été compensée par les reverse-proxy en ajoutant un header http X-Forwarded-For à toutes les requêtes qu’ils font transiter. Bien que ce header ne soit pas standard (son nom commence d’ailleurs par « X- »), il est devenu un standard de facto utilisé par la très grande majorité des reverse proxy et load balancers (paramètre xforward=enable pour les Alteon d’après Command Reference ; propriété Insert XForwarded For de la GUI du profile http ou règle when HTTP_REQUEST { HTTP::header insert "X-Forwarded-For" [IP::client_addr] } pour les Big-IP d’après F5 Dev Central : Using « X-Forwarded-For » in Apache or PHP ).
Cependant, les implémentations de l’API Servlet ne sont pas tenues de prendre en compte ce paramètre dans la méthode request.getRemoteAddr() dont la javadoc stipule bien Returns the Internet Protocol (IP) address of the client or last proxy that sent the request. . Tomcat est d’ailleurs autant concerné que ses concurrents Websphere ou Weblogic, pour ne citer qu’eux.
Toutes les couches sont impactées : l’Access Log Tomcat dont les patterns common et combined utilisent le remote host name (%h) et les frameworks de sécurité et d’audit comme Spring Security (cf WebAuthenticationDetails.getRemoteAddress()) ou CAS Inskektr ClientInfo).
Lire la suite de cet article »
22 septembre 2008
Spring Source a publié l’information sous la forme d’une modification sibylline de la note d’Enterprise Maintenance Policy : Seuls les clients commerciaux bénéficieront des patchs publiés après les trois mois qui suivent le lancement d’une version majeure des projets majeurs Spring (framework, security, web flow, etc). L’objectif annoncé de Spring Source est de réduire les coûts de maintenance des anciennes versions de ses projets en incitant les utilisateurs à migrer vers les versions récentes.
Concrètement, les utilisateurs non commerciaux du framework seraient limités aux versions 2.0.1 (contre 2.0.8 pour les clients commerciaux) et 2.5.3 (contre 2.5.5) [1]. Une telle limitation serait bloquante pour la plupart des projets.
Au delà de l’objectif annoncé, on peut y voir la tentative de créer un modèle de monétisation de l’open source : « payer pour les mises à jour ».
Ce qui est sûr, c’est que cette annonce, au delà des sempiternels débats stériles que nous offre internet (Cf. : TSS), laisse quelques questions en suspens.
Lire la suite de cet article »
20 mai 2008
Paris JUG reçoit mercredi à 18h45 Patrick Curran, président du Java Community Process pour une table ronde autour de l’ouverture du JCP.
Des membres français du JCP participeront au débat : Guillaume Laforge (spec lead de la JSR 241: The Groovy Programming Language), Cedric Thomas (CEO d’OW2 – ObjectWeb), Eric Samson (CTO de Data Service) et Antonio Goncalves (membre des JSR Java EE 6, EJB 3.1 et JPA 2.0).
Deux ans après l’appel d’IBM et BEA à ouvrir la plateforme Java, à l’heure de la controverse OSGI versus Java Module System, du large succès de Flash face à JavaFX, des relations délicates entre Sun et la Fondation Apache et de l’émergence de SCA/SDO, c’est l’occasion de comprendre les enjeux que la plateforme Java rencontre aujourd’hui et peut être d’assister à l’inflexion de la gouvernance de Java.
Cette table ronde s’adresse aux experts Java autant qu’aux managers qui définissent des stratégies de Système d’Information.
Tous les détails de la soirée Paris JUG – Table ronde : l’ouverture du JCP.
1 mai 2008
L’annonce de SpringSource a des allures de schisme. Après des années à critiquer la complexité et le monolithisme de Java Enterprise Edition (Java EE), les équipes de Rod Johnson ont franchi le Rubicon et proposent un serveur d’applications Java qui ne reposera pas sur la monolithique spécification Java EE.
SpringSource Application Platform se limite à quelques fragments de cette spécification (principalement Servlet et JPA) assemblés dans un conteneur OSGI augmenté de quelques particularités Spring. Les applications web ne seront plus assemblées sous forme de WAR avec un fichier web.xml mais sous forme de plusieurs bundles OSGI avec des fichiers de configuration Spring.
Lire la suite de cet article »
17 décembre 2007
Une nouvelle approche des ESB
SpringSource vient d’annoncer le lancement de Spring Integration, une implémentation légère des Enterprise Integration Patterns. Le lendemain, le projet Apache ActiveMQ annonçait la sortie de sa version 5 qui ajoute le support de ces mêmes Enterprise Integration Patterns grâce à l’intégration d’Apache Camel, un framework léger de routage et de médiations utilisable soit par configuration XML Spring, soit par un Domain Specific Language (DSL) Java. Ces deux approches open source se caractérisent dans le monde des ESB par :
- Une grande légèreté : on ne parle plus de conteneur, d’APIs sophistiquées de connecteurs, de registre de services, de structures de données complexes mais de simples messages composés d’un body souvent sous forme de Plain Old XML (POX) et de headers en mode clef/valeur.
- L’éloignement des standards chers aux grand éditeurs (Java Business Integration – JBI et Service Component Architecture – SCA) pour se cantonner à des Plain Old Java Objects (POJO). On notera tout de même que ces nouveaux frameworks de routage utilisent massivement les API Java EE pour les connecteurs et les transactions (JDBC, JMS, JCA, JTA, etc).
Lire la suite de cet article »
15 octobre 2007
La haute disponibilité des bases de données est un sujet de plus en plus fréquent chez nos clients et le choix de la solution est lourd d’impacts, non seulement financiers mais aussi sur l’architecture des applications.
Si un consensus se dégage autour de clusters actif-actif pour la haute disponibilité des applications Java, la solution pour les bases de données fait encore débat entre deux approches radicalement différentes : les clusters actif-actif (e.g. Oracle RAC) ou les cluster actif-standby (e.g. IBM DB2 HADR et Oracle DataGuard). Derrière des mots très proches de sens se cachent des complexités et des coûts totalement différents.
Lire la suite de cet article »
