SpringSource Application Platform : la brèche dans Java EE
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.
Révolution ou évolution ?
L’utilisation d’OSGI pour assembler des applications Java n’est pas une nouveauté.
On le retrouve déjà dans les internes des serveurs d’applications Java (Websphere, Weblogic et maintenant Glassfish). L’ESB Service Mix va même plus loin en nous annonçant que dans sa version 4, nous déploierons nos médiations et transformations sous forme de bundle OSGI : pour la première fois, les développeurs d’informatique de gestion allaient assembler leur code métier avec OSGI.
Cependant, OSGI restait utilisé dans des domaines pour lesquels les spécifications Java n’avaient pas ‘légiféré’. La grande rupture de SpringSource Application Platform est de proposer OSGI en alternative à un standard utilisé par tous. C’est en cela qu’on peut percevoir cette initiative comme schismatique.
La fin des standards ?
Le monde unipolaire dans lequel seul le Java Community Process gouverné par Sun décidait des standards de l’écosystème Java a vécu.
Nous assistons aujourd’hui à l’émergence d’un monde multi-polaire avec l’arrivée d’autres organismes de standardisation incontournables comme OSGI Alliance, Open SOA (SCA) et l’OASIS Group (SOAP, WS-*). On peut voir dans cette évolution l’influence d’IBM et BEA qui ont appelé en vain Sun à partager la gouvernance de Java.
Cependant, Spring Source a apporté des extensions propriétaires au standard OSGI (problèmes de load-time weaving JPA, etc). La fragmentation qu’apporte Spring Source peut donc causer un recul de la standardisation de l’écosystème Java.
Une rupture irréversible avec Java EE ?
Les directions prises par Spring Source et Java EE semblent conciliables. Il faudra pour cela que le Java Community Process accorde un rôle de premier ordre à OSGI dans la spécification Java Module System qui définit actuellement l’assemblage de composants de bas niveau. Si on a pu douter de cette reconnaissance, le récent support d’OSGI par Sun dans GlassFish laisse espérer un dénouement rapide.
On observe par ailleurs que Spring Source veille à ne pas couper les ponts avec le Java Community Process : Rod Johnson participe à plusieurs comités de spécifications Java EE 6 et Spring Source annonce que sa plateforme sera très vraisemblablement conforme à la spécification Java EE 6 Web Profile. On peut voir dans la démarche de Rod Johnson le souhait d’influencer les futures standards Java EE.
Un nouveau modèle économique pour Spring Source
Le lancement d’un serveur d’application est pour SpringSource un changement sensible de modèle économique.
L’ancien éditeur proposait une offre difficile à monétiser : un framework à licence open source business-friendly (Apache).
Aujourd’hui, Spring Source s’engage sur un modèle connu pour être monétisable : un middleware à licence duale (open source business-unfriendly GPL et commerciale) avec du support et des outils d’administration réservés aux clients commerciaux.
On s’amusera à remarquer que ce modèle ressemble à s’y méprendre au modèle de Marc Fleury et JBoss avec qui SpringSource a des relations tendues.
Adopter SpringSource Application Platform immédiatemment ?
Le pari de SpringSource est ambitieux, la plateforme est en version beta, et les équipes de supports sont sans doute encore limitées, il faudra de plus former les équipes de développement.
Si l’utilisation en production n’est pas pour demain, une phase d’évaluation a tout son sens.
Billets sur le même thème :
- Ce que vous avez peut-être raté au second trimestre 2008
- Conférence Open Source Exchange
- Nouvelle politique de maintenance de Spring : La très périlleuse route de la monétisation de l’open source
- Java Platform As A Service : SpringSource accélère
- Spring Integration – L’avènement des ‘lightweight ESB’ ?
Votre message est une bonne synthèse mais pourquoi ce titre alors que comme vous le dîtes, SpringSource Application Platform sera probablement certifié Java EE 6 ?
Pour ce qui est de l’utilisation d’OSGi, là encore vous le dîtes, la plupart des serveurs d’applications l’intègre ou sont en passe de le faire donc j’ai plutôt l’impression que l’on se dirige vers un nouveau consensus plutôt que vers un schisme.
Certes l’intégration d’OSGi dans SpringSource Application Platform est plus poussée car on peut déployer directement des bundles, toutefois le format WAR reste supporté. Du côté des serveurs d’applications, il me semble que JOnAS 5 propose déjà la possibilité de déployer des bundles OSGi.
Le sujet qui reste effectivement délicat est l’attitude de Sun par rapport à OSGi, mais si la raison l’emporte, tout cela sera bon pour Java.
Bonjour Cyrille,
J’ai toujours du mal à entendre que le JCP est « gouverné par Sun »
SpringSource, BEA, IBM, Oracle, Eclipse et tous les autres sont soit au board soit dans les groupes d’experts.
OpenSCA ne normalise pas, c’est OASIS qui le fait. Quant à OSGi c’est un périmètre limité et de toute façon intégré dans le JCP au travers du JSR 291.
Bonjour Cyrille,
Après la réponse de Sun, voici celle de SpringSource
Tout d’abord merci pour ce billet, ça fait plaisir de voir l’intérêt que les gens apportent à notre plateforme.
SpringSource AP est bien une révolution par rapport au modèle JEE traditionnel : notre plateforme ne se borne pas à utiliser OSGi en interne (ce que je te l’accorde d’autres personnes font déjà très bien), mais à en proposer toute la puissance aux développeurs. Et ce n’est pas quelque chose de simple : en effet, la plupart des librairies habituellement utilisées (par exemple pour la persistance) n’ont pas du tout été prévues pour êtres utilisées dans un mode OSGi. Certes, on peut faire un gros bundle OSGi et tout mettre dedans, mais ce n’est pas d’un grand intérêt.
Ce que nous proposons c’est d’utiliser ces librairies dans un contexte OSGi, ce qui nous a forcés à créer notre propre repository : http://www.springsource.com/repository/
Les librairies qui y sont présentes (plus de 300) fonctionnent toutes en mode OSGi, et sont validées par notre équipe.
Je pense que cela permet de bien mieux voir le travail titanesque qu’il y a derrière S2AP.
Concernant le JCP je ne peux qu’aller dans le sens d’Alexis. Nous sommes membres du JCP sur JEE 6.
D’ailleurs je précise que la plateforme a pour but d’être certifiée sur les profils A et B de JEE 6, c’est à dire l’essentiel de ce que les gens utilisent.
Quand à JEE 5, étant donné que la plateforme inclut un Tomcat 6, on peut bien entendu déployer des WAR, mais pas des EAR. De toute manière il y a très peu de gens qui font du Spring et des EJBs en parallèle…
Ceci dit, notre plate-forme va continuer à proposer « plus » que le standard, par exemple il est probable qu’elle intègre Spring Batch dans la prochaine version : c’est quelque chose que le standard ne prévoit pas, mais que nos clients nous demandent. Et nous avons une tendance naturelle à écouter nos clients en priorité!
Julien Dubois.
A propos de décomposer un WAR en bundles…
Quel est le framework minimal pour gérer un WAR composé de bundles OSGi, dans Tomcat?
Julien,
Personne ne doute qu’il y ait du travail derrière S2AP mais la remarque suivante « la plupart des librairies habituellement utilisées (par exemple pour la persistance) n’ont pas du tout été prévues pour êtres utilisées dans un mode OSGi », est un peu trop mise en avant à mon goût car faire fonctionner Hibernate ou TopLink sur Equinox n’est pas difficile du tout. Si on se place au niveau des spec OSGi c’est effectivement une lacune mais l’implémentation OSGI d’Equinox apporte la solution.
De même, dire que mettre 300 librairies sous-forme de bundle OSGi représente un travail ‘titanesque’ n’est pas très crédible : un bundle c’est un jar avec plus de lignes dans le fichier manifeste… Le travail qui serait titanesque ça serait de modifier le code de toutes ces librairies pour leur faire exploiter la notion de service d’OSGi ce qui aurait un impact sur leur code.
Je ne cherche pas du tout la polémique, je suis vraiment convaincu de la pertinence de S2AP, mais je résume mon ressenti à la lecture des différents billets sur S2AP. De mon point de vue pour faire la promotion de S2AP je pense qu’il faut mieux bien expliquer ce que les développeurs vont gagner à utiliser OSGi plutôt que d’expliquer à quel point c’était difficile de mettre au point S2AP (même si sur certains points c’est vrai).
Bonjour Bruno,
Si Spring Source App Server (S2AP) sera très vraisemblablement certifié Java EE 6, l’esprit de ce serveur est de quitter, entre autre, le standard d’assemblage par WAR au profit de son format propriétaire : Platform Archive (PAR). Ce format n’est reconnu ni par le JCP ni par l’OSGI Alliance. Les applications développées pour S2AP (ie dans son esprit avec un PAR) ne seront donc pas exécutables sur d’autres serveurs d’application, pas même sur Tomcat ; nous arriverons à une situation de Vendor Lock In.
Déployer des WAR sur S2AP apportera peu de plus value par rapport à un déploiement sur Tomcat ; la promesse de valeur de S2AP concerne l’assemblage sous forme de bundles OSGi (classiques ou enrichis avec PAR).
Une standardisation par le JCP ou par l’OSGI Alliance du format d’assemblage PAR permettrait de lever ce « Vendor Lock In » et ramènerait les utilisateurs sur le modèle de portabilité inter-vendeurs ( »run everywhere ») que nous connaissons aujourd’hui avec les WAR. Cependant, cette standardisation semble improbable à court terme. Le JCP comme l’OSGi Alliance ont déjà engagés des travaux sur les assemblages server side (notamment la JSR Java Module System pour le JCP et l’Enterprise Expert Group pour l’OSGi Alliance) et la convergence de ces travaux avec les choix de SpringSource demandera du temps et des concessions de des différents acteurs. On notera sur ce point que Spring Source était jusqu’à présent plus habitué à faire cavalier seul qu’à obtenir des consensus dans des organismes multi-parties.
Le contournement des organismes de standardisation pour proposer une approche propriétaire là où nous avions auparavant un standard nous amènent à utiliser les termes de schisme et de brèche.
C’est un choix stratégique ambitieux qui, quel que soit la réussite de S2AP, entérinera un tournant dans le paysage des serveurs d’applications Java.
Cyrille (Xebia).
Bonjour Alexis,
Quand je parlais de Gouvernance Exclusive de Sun sur le Java Community Process (JCP), je pensais en particulier au « Project Management Office (PMO) », exclusivement composé d’employés de Sun Microsystems, dont le rôle est d’administrer le JCP et de diriger l’Executive Committe (EC).
Extrait du JCP 2: Process Document :
Program Management Office (PMO): The group within Sun Microsystems that is responsible for administering the JCP and chairing the EC.
Executive Committee (EC): The Members who guide the evolution of the Java technologies. The EC represents a cross-section of both major stakeholders and other Members of the Java Community.
Cyrille (Xebia)
Bonjour,
Pour répondre à Bruno : je vous assure que faire fonctionner correctement ces librairies dans un contexte OSGi n’est pas une tâche facile. Cela a nécessité beaucoup de travail et des gens très compétents. J’ai passé du temps avec eux et j’ai vu les ai vus bosser. Une explication de cette complexité est sur notre blog : http://blog.springsource.com/main/2008/05/02/running-spring-applications-on-osgi-with-the-springsource-application-platform/
Pour répondre à Cyril sur le format PAR : je n’aime pas trop le terme de propriétaire, on a l’impression que c’est une extension comme IBM, BEA, JBoss ou Oracle en proposent sur leurs serveurs d’applications
A nouveau nous restons dans l’Open Source, il n’y a là rien de caché, et nous poursuivons ce que nous avons toujours fait : si le standard ne nous paraît pas bon, nous proposons autre chose. Ceci dit le format PAR est très simple, et on peut tout à fait déployer des bundles OSGi « normaux » dans S2AP sans utiliser le PAR. Il est parfaitement optionnel. D’ailleurs, personnellement, je ne l’utilise pas sur l’application que je développe en ce moment!
Julien.
Salut Cyrille,
chair != diriger
administration = administratif (paperasse)
Le rôle de Sun dans le JCP est moins hégémonique que certains veulent le faire croire.
Alexis (Sun)
Bonjour Julien,
J’ai noté des documentations de S2AP que PAR est le format recommandé (plutôt que WAR ou raw OSGi) pour déployer des applications [1]. Par ailleurs, je retrouve dans le fichier de configuration PAR with Web Personality Module des directives très similaires à celles que nous connaissons dans le fichier standard web.xml ( »Web-Servlets », « Web-FilterMappings », etc).
Pouvez vous nous indiquer si des concepts similaires à l’assemblage Platform Archive, au « Web Personality Module » ou à l’instruction « Import-Library » sont à l’étude chez OSGi Alliance ?
Cela ouvrirait la voie à une standardisation de ces apports à OSGi.
Un autre chemin pourrait être de devenir un standard ‘de facto’ comme l’ont été Struts 1 et Spring Core. cela pourrait être accompli seul ou en ralliant d’autres acteurs majeur comme les conteneur OSGi Eclipse Equinox ou Apache Felix mais la licence Open Source Business Unfriendly (GPL) serait à changer (Eclipse comme Apache utilisent des licence open source business friendly).
Quant aux extensions propriétaires qu’IBM, JBoss ou Oracle-BEA ont apporté à web.xml, elles illustrent la difficulté de suivre un standard et concernaient le plus souvent des aspects mineurs. On notera que ces extensions n’ont pas empêché des frameworks web comme Spring MVC d’être portable
Cyrille (Xebia)
[1] : The PAR format is the recommended approach for packaging and deploying applications for the Platform in Introducing S2AP de Rob Harrop
Bonjour Alexis,
Autant pour moi, WordReference traduit « to chair » par présider
Et je vous rejoins sur le fait que le Java Community Process est un lieu de débat, que Sun n’est pas le seul à y prendre la parole, et qu’on peut lui reconnaître la transparence de laisser chacun exprimer ses divergences, notamment par le biais des commentaires lors des votes.
Cyrille (Xebia)
[...] du Paris JUG. Nous avions relaté en mai dernier la sortie du serveur hybride OSGI-Tomcat dans SpringSource Application Platform : la brèche dans Java EE. L’événement avait fait grand bruit, The Server Side avait lancé la polémique avec S2AP – [...]
[...] de continuer à utiliser la “business friendly” Apache Software License (Cf. : “SpringSource Application Platform : la brèche dans Java EE“). Rod Johnson avait adouci sa méthode de communication en expliquant sa stratégie dans [...]
[...] de son produit anciennement appelé S2AP (SpringSource Application Platform) annoncé depuis mai dernier dont les versions bêta se sont succédées cet été. Le produit a été renommé en dmServer lors [...]