Discussion :

[Hikage]

SpringSource vient de lancer une nouvelle forme de serveur d'application, fortement modulaire, basé sur OSGi.

Il permet de déployer des applications Web ( WAR ) mais pas les EAR, et EJB. Il n'est pas compatible JEE donc.

Mais étant basé sur OSGi, il possède de nombreux avantages :

• Déploiement à chaud de modules
• Déploiement de plusieurs versions d'un module
• Ne nécessite que les modules qu'ils a réellement besoin, donc utilisation moindre de mémoire

Plus d'informations ici : Billet Blog


Mais le fait qu'il ne soit pas compatible avec JEE risque de nuire à son intégration en entreprise, où OSGi n'est pas encore utilisé en masse.

Mais bon, Spring Framework à prouvé que les standards peuvent être remplacés.

Qu'en pensez vous, ce nouveau type de serveur à de l'avenir comme alternative à JEE ? Ou pas ?

[nicØB]

Salut,

Personnellement j'utilise Osgi depuis quelques mois, et même si au début c'est pas forcément simple à appréhender, je trouve ça génial.
Reste à voir ce qu'apporte réellement ce serveur d'application, par rapport à quelque chose comme ServiceMix (plus précisément, le kernel) qui permet déjà de déployer des bundles, d'utiliser spring dm, etc. Avec l'ajout du service HTTP utilisant jetty, est-ce qu'on aurait pas plus ou moins la même chose finalement ? (je ne connais pas très bien JEE).

Savez-vous si ce serveur d'application est destiné à être gratuit ou bien payant ? (je dirais gratuit mais j'aimerais être sûr). Merci.

[Hikage]

Je pense qu'il y aura deux version ( à confirmer ).

Surement une version community, et une version payante ( avec Support etc ).


En ce qui concerne le serveur Http, c'est basé sur Tomcat ici, et non pas sur Jetty. Personnellement, je ne connais pas bien service Mix, mais ServiceMix est un ESB non ?

[nicØB]

En ce qui concerne le serveur Http, c'est basé sur Tomcat ici, et non pas sur Jetty. Personnellement, je ne connais pas bien service Mix, mais ServiceMix est un ESB non ?

Service Mix est bien un ESB, mais le kernel peut être utilisé comme plateforme pour les applications osgi etc. Il utilise Spring DM.
Je pensais qu'en y ajoutant Jetty (ou autre) on obtenait plus ou moins la même chose que le serveur d'application de Spring. Après avoir lu une partie de la doc, il est clair que non.

Merci pour les précisions concernant les versions. Je vais immédiatement tester la bête qui va surement m'être très très utile.

[lunatix]

apres quelques tests et une bonne lecture des docs disponibles. C'est tres prometteur. Le packaging en Par, et l'utilisation massive de osgi face aux anciennes méthodes de déploiement (war et ear) semblent logiques et bien pensés. On va pouvoir développer en SOA au sein même du conteneur.

apres reste quand même des choses a vérifier. Quid de l'impact de l'utilisation de osgi entre toutes les dependences en terme de perf pour l'application.
la console d'administration reste pour le moment minimaliste, quid du clustering, y aura-t-il une administration centralisée pour un groupe de serveurs etc...

en tout cas, a suivre de tres pres.

[julien.dubois]

Quelques réponses "officielles" au post très complet de djo.mos :
- Pour les formats PAR et libd je suis bien d'accord. Les deux formats sont optionnels et aident simplement la conf (le fichier de conf du format PAR n'est pas utilisé au runtime, par exemple, c'est vraiment pour aider les outils parce que ce n'est pas prévu dans OSGi). On peut donc tout à fait s'en passer, et s'ils doivent un jour être standardisés cela devrait aller vite parce qu'ils sont très simples.
- Pour Jetty : à mon avis c'est peu probable qu'il soit intégré dans le court ou moyen terme. Depuis le rachat de Covalent nous avons des développeurs Tomcat dans l'équipe, ce qui va nous faciliter les choses lorsque nous vendrons du support de prod sur AP. Je précise que nous avons déjà une offre de support de prod sur Tomcat.
- Pour la licence commerciale : ce à quoi tu fais référence est AMS (SpringSource Application Management Suite), que nous proposons déjà à nos clients (c'est inclut dans le support Spring). Il est clair que cette partie sera toujours commerciale, et pour une bonne raison : notre solution est basée sur celle d'Hyperic, et nous payions nous-mêmes une licence à Hyperic pour chaque serveur installé... Donc cela ne change en rien la situation actuelle : si tu n'es pas client, tu n'as pas accès à AMS, et si tu es client tu y as droit gratuitement. Pour le reste, rien n'est encore décidé, mais ce sera affiché clairement sur notre roadmap, et s'il y a d'autres parties commerciales il s'agira uniquement de choses très spécifiques et très avancées, qui n'intéresseront que les grosses entreprises.

[djo.mos]

Oki, Merci beaucoup d'avoir pris le temps de répondre aux points soulevés

[julien.dubois]

Bonjour,

Oui le serveur est destiné à être gratuit, plus exactement Open Source. Il est disponible sous licence GPL 3.0.
Par contre, une fois la phase beta passée, il y aura une version commerciale qui apportera des fonctionnalités en plus par rapport à la version GPL. C'est le même système que MySQL, par exemple.
Je précise que cela ne change rien vis-à-vis du framework, qui lui reste sous licence Apache.

Julien.

[djo.mos]

Bonjour,
Oui, je pense que SpringSource AP pourrait représenter une alternative à Java EE (dans sa totalité, AP utilise les servlets par exemple qui font partie de Java EE), et une alternative alléchante même.

Pour ne pas généraliser, je parlerais juste de l'approche qu'on a pris dans ma boite, où l'on passe systématiquement par un conteneur web (Tomcat, Jetty) pour tout ce qui est applications server-side, et où on évite comme la peste les autres technologies lourdes su Java EE, tel que les EJBs.
On se base presque totalement sur Spring Framework pour lesf onctionnalités telque la gestion des transactions, l'ORM ou simplement JDBC, l'IoC, etc. Bref, Spring MVC est presque le seul composant de Spring qu'on n'utilise pas.
On relie beaucoup aussi sur les alternatives aux standards JavaEE, genre Apache CXF pour les WebServices.
Bon, on utilise quand même JPA ou JSF par exemple : On pèse le pour et le contre, et on n'exclue pas systématiquement tout standard.

Bref, on favorise toujours les alternatives lightweight.

Et justement, nous sommes dans la phase d'étude d'un nouveau projet où l'utilisation d'OSGi côté client (eclipse RCP) a été retenu. On a poussé la chose plus loin encore, et il serait stupide (à mon avis) de ne pas en faire de même côté serveur.
Et là, c'est un domaine encore dans sa jeunesse, sans blueprints ni approche systémique ni d'infrastructure prête à utiliser... et hop, AP est là pour répondre justement à ce besoin
Inutile de préciser que ce nouveau serveur serait le candidat idéal pour remplir le rôle d'infrastructure côté serveur.

Bon, après avoir lu le user-guide et dev-guide de la chose, j'aurais quelques points à émettre:
- Le format PAR: Ca se justifie pleinement, mais l'idéal pour moi (et beaucoup d'autres) serait de standardifier celà, avec la fondation OSGi par exemple (pas avec le JCP, ça risque de prendre des décennies ) ?
- Le format libd: Très intéressant aussi, mais même remarques que pour le point précédent.
- Le choix du conteneur web: Avec SpringDM, il est possible d'utiliser Jetty ou Tomcat. AP utilise Tomcat d'office. Est il envisageable de rendre celà configurable ?
- Je tiens aussi à saluer 'le smart move' que SpringSource a fait en développant en // la Tool Suite qui supporte AP: Très très malin car le tooling est tout simplement essentiel à toute plateforme.
- Les samples: Je sais que c'est encore en phase béta, et que Spring DM 1.1 (qui apporte le support web/serveur) en est à la phase Milestone, mais AMHA, un ensemble bien choisi et développé de samples serait plus que le bienvenu pour guider les développeurs vers ce que l'approche SS-OSGi (Server Side) peut faire ainsi que de fixer quelques blue prints.
- Je ne m'inquiètes pas pour la DOC, car comme c'est l'habitude pour la famille Spring, la qualité n'a jamais posé problème
- Enfin, pour ce qui est de la version commerciale/libre: je ne suis pas un extrémiste et je sais très bien qu'une société doit être en mesure de financer le travail (énorme) qu'elle accomplit, mais j'espère sincèrement que ça ne dérape pas: par exemple, dans le cas de MySQL, la version commerciale apporte surtout le support + quelques outils périphériques, mais les différences ne touchent pas à l'outil principal ou le noyau en terme de fonctionnalités.
Selon ce que j'ai compris, pour l'instant, la version commerciale apporte surtout plus depossiblités de monitoring/profiling via un weaving plus avancé. C'est OK ça, et j'espère sincèrement que ça restera dans cette optique.


Pour finir, j'adresse mes félicitations au travail titanesque de l'equipe de Spring DM et de SpringSource en général