SpringSource Application Platform – une alternative à JEE ?

Après de nombreux mois de développement secret, SpringSource a annoncé Mercredi dernier (30 avril) la sortie de la version Beta de SpringSource Application Platform : une plateforme d’hébergement d’applications orientée OSGi à 100%. (Rod Johnson considère que l’appeler un serveur d’application serait un peu réducteur 😉 : cf : http://java.dzone.com/news/interview-rod-johnson-springso )

Si la plupart des serveurs d’application JEE du marché passe à OSGi pour gérer le coeur de leur serveur, il ne semble pas que leur objectif soit de proposer sa puissance directement aux applications qu’ils hébergent. Avec S2AP, c’est tout le contraire : l’objectif est bien de développer et déployer des applications d’entreprises basées sur OSGi ; l’implémentation des specs JEE n’a pas été une contrainte (même si le profil web des specs JEE 6 sera certainement supporté).

Côté techno, au coeur de S2AP, on trouve SpringSource Dynamic Module Kernel (DMK) un noyau se basant sur Equinox (le containeur OSGi de la fondation Eclipse) et l’étendant pour fournir les bases de la plateforme. Un module Tomcat permet d’exposer des applications web.
Le tout étant bien sûr supporté par les frameworks Spring et Spring Dynamic Module for OSGi (Spring-DM)
La version 1.0 permet de déployer facilement trois types d’applications :
– les WAR standards
– des WAR allégés : où les dépendances sur les librairies sont spécifiés via les mécanismes OSGi plutôt que d’être inclus dans le répertoire WEB-INF/lib
– les PAR : Platform Archive : qui sont un ensemble de bundle OSGi formant un tout logique. Nouveauté par rapport à du OSGi standard : les PAR forment un scope application qui isole les éléments de chaque PAR des éléments des autres PAR.

Les ear ne sont pas supportés.
Pour faciliter la gestion des dépendances sur le mode OSGi, la plateforme maintient un repository de bundles OSGi.
Tout bundle OSGi standards peut être placé dans le repository est ainsi être disponible pour toutes les applications déployées.
SpringSource héberge un repository central où de nombreuses librairies open-source ont été OSGi-ifiées.

Pour faciliter l’utilisation de la plateforme, il est fortement conseillé d’utiliser les mécanismes de Spring Dynamic Modules pour créer les différents modules OSGi. Il suffit en particulier de placer les descripteurs d’assemblage Spring dans le répertoire /META-INF/spring/ du module et d’y utiliser le namespace osgi pour importer les services OSGi nécessaires au bundle ou exporter les services qu’il propose.

Les guide d’utilisateur et du programmeur de la plateforme :
http://static.springsource.com/projects/s2ap/1.0.0.beta/user-guide/html/
http://static.springsource.com/projects/s2ap/1.0.0.beta/programmer-guide/html/
bien que relativement courts, sont bien écrits et constituent de très bonne intro à l’utilisation de S2AP.

Je pense qu’il faudra regarder la doc de Spring DM en détail pour pouvoir utiliser tout le potentiel de la plateforme.

La plateforme s’installe facilement et est directement opérationnel.
Un effort particulier a été fait sur la gestion des logs du serveur (ils appellent ça la serviceability). Le log principal contient uniquement les stades importants du démarrage et du déploiement.
Tandis que des fichiers de traces logguent avec énormément de détail les actions réalisés sur les différents modules.
Une console d’admin est disponible. Mais pour le moment elle est limitée au déploiement/redéploiement des applications. (On notera qu’un répertoire pickup permet aussi les déploiements automatiques )

Les options du script de démarrage permettent d’activer facilement le support de JMX. Les nombreux MBeans de tomcat sont ainsi exposés. Pour le moment, les Mbeans spécifiques à S2AP sont liés au déploiement et à l’arrêt de la plateforme.

Une note d’implémentation sympa : S2AP privilégie le format JSON au format XML.
Ainsi la configuration est au format JSON et les dumps de diagnostique générés en cas d’erreur par S2AP sont aussi en JSON.

SpringSource fournit un plugin Eclipse pour faciliter le développement sur sa plateforme.
Le plugin Application Platform Tools est disponible librement, il peut s’installer sur un Eclipse 3.3 classique équipé de WTP et de Spring IDE 2.0.5 Beta. (Il n’est donc pas obligatoire d’utiliser SpringSource Tool Suite : la version d’Eclipse spécialement customisée par SpringSource)

L’intégration d’Eclipse avec S2AP est alors correct.
Un serveur S2AP peut être configuré dans Eclipse ce qui permet les déploiements automatiques depuis Eclipse (le redéploiement à chaud automatique est configuré par défaut à la moindre modification d’un élément d’un module)

Comme un projet OSGi classique développé sous Eclipse, le classpath est automatiquement mis à jour sur la base des différents imports OSGi spécifiés dans le manifest. Mais dans ce cas, le classpath référence les bundles installés dans le repository de l’installation de S2AP plutôt que les bundles du container Equinox inclu dans Eclipse.

Un wizard est disponible pour créer les projets destinés à être déployé sur S2AP.
Malheureusement il ne semble pas offrir d’assistance (pour le moment ?) pour la manipulation des entrées du manifest spécifiques au déploiement sur S2AP.
En particulier, même si le wizard de création d’un bundle S2AP demande le type de module (Web uniquement pour le moment) et le context path sous lequel le déployer : les entrées associées ne sont pas générées dans le manifest …

Le forum mis en place pour l’évaluation de cette version beta (http://www.springsource.com/beta/s2ap/ après enregistrement) commence à bouger.
Les développeurs de S2AP viennent d’annoncer une version de PetClinic OSGi-ifé et d’autres samples pour Mardi prochain …
Avec une vrai application, il sera plus simple de se faire une meilleur idée sur les capacités de la plateforme.

Alors et vous ? qu’en pensez-vous ?
OSGi est encore relativement confidentiel au sein de la communité. Pensez-vous que S2AP va marquer le début de l’expansion de OSGi pour les appli d’entreprises ?
L’hégémonie de JEE va-t-elle en prendre un coup ?

Qq pointeurs supplémentaires :

Le poste de Rob Harrop pour plus de détail : http://blog.springsource.com/main/2008/04/30/introducing-the-springsource-application-platform/.

Deux intros sur OSGi et Spring-DM :
http://www.javaworld.com/javaworld/jw-03-2008/jw-03-osgi1.html
http://www.javaworld.com/javaworld/jw-04-2008/jw-04-osgi2.html

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

Une réflexion au sujet de « SpringSource Application Platform – une alternative à JEE ? »

  1. Intérressant. Je ne connaissais pas OSGi.

    Dans la même logique que ton article, une autre initiative orientée "modularité/archi ouverte" marche aussi sur les plates-bandes J2EE: le projet Apache Tuscany, l'implémentation officielle de la norme SCA (spécification de l'open OASIS pour le packaging/assemblage/environnement d'exéc d'applis SOA – initiative soutenue par les acteurs majeurs du marché – RedHat, WebLo, IBM, SAP…). Tuscany propose justement, pour sa version 1.2, une implém' OSGi de sa plateforme (http://apache-tuscany.blogspot.com/2008/04/apache-tuscany-sca-java-11-released.html).

    SCA, c'est: un mode d'assemblage "récursif" de services, une ouverture à différents langages d'implém' (javascript, java, python, BPEL), des modes de transport interchangeables (JSon, WService, EJB, JMS), un accès unifié aux données (SDO), des services d'infra "comme les grands" (sécu, transac, archi répartie, logs, monitoring, synchrone/asynchrone). C'est d'la bombe de balle, bébé !

    Des implém's de plateforme SCA sont en Beta ou en distrib optionnelle chez certains gros (IBM, WebLo), des boites ont déjà commencé à mettre Tuscany en environnement d'exéc, il reste encore à valider/terminer des specs… Bientôt un appServer parfum SCA ? Qui sait ?

    Pour revenir à OSGi/Spring, un white-paper de l'open-soa (http://www.osoa.org/download/attachments/250/Power_Combination_SCA_Spring_OSGi.pdf?version=3) mets en exerge le trio SCA/Spring/OSGi comme solution complète pour déployer, exécuter et maintenir des applications orientées "service". OSGi viendrait sous la couche SCA, offrir des "extensions" (versionning/déploiement à chaud j'imagine). On se demande même pourquoi on n'y avait pas pensé plus tôt, on espère bien sûr que cette archi de rêve soit "poussée", grâce au support de la norme SCA, dans le monde des "grands" serveurs applicatifs, et qu'on puisse enfin arrêter de blinder nos sources de code qui n'a rien à voir avec du business.

Laisser un commentaire

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


*