A mon avis (et je suis d'accord avec toi), l'age des serveurs d'applications monolithiques et lourd est en train de se terminer.
Si l'on prend du recul, JOnAS fait, lui aussi, parti d'un ensemble plus grand: OW2.
Meme si OW2 n'est pas une entreprise, les projets OW2 peuvent former les pieces d'une plateforme SOA (Portal avec eXo, JBI avec PEtALS, ...)
La suite est peut-etre plus polemique, entre partisans Spring/Java EE :)
L'ennui avec une approche SpringSource, c'est l'absence de standard. Ils piochent a droite à gauche ce qui les interresse.
A y regarder de plus pret, à force de rajouter des trucs dans Spring, on se retrouve avec un serveur d'application complet (transaction, persistence, connexion DB, ...) packagé dans une webapp ! Le tout sans support des standard alors qu'ils existent.
En quoi Java EE c'est le mal ? Les EJB2 et le XML partout c'est fini ! Si vous suivez les nouvelles specifications Java EE, c'est bien la modularité et la légereté qui s'imposent (EJB3.1 lite, Java EE Web Profile pour n'en citer que deux).
L'approche JOnAS est la suivante: JOnAS est un socle sur lequel deployer les services techniques dont vos applications ont besoin. Et seulement ceux requis! En bref, si seuls les servlets et un support transactionnel sont necessaire pour vos applications, JOnAS peut etre configuré pour n'installer que le conteneur web (Tomcat) et JOTM. Et la on se rapproche du triplet magique Tomcat/OSGi/Conteneur leger (en meme temps on peut mettre Jetty si on veut)...
C'est peut etre moi, j'ai passé la doc du PAR en revue tres rapidement...
C'est possible que le par modifie les bundles qu'il contient en rajoutant des metadonnées qui vont empecher d'autres bundles d'utiliser les packages.
Pour le coup du "datasource provider" generic, c'est une facon de faire. Une autre serait d'avoir une ManagedServiceFactory (http://www.osgi.org/javadoc/r4/org/osgi/service/cm/ManagedSe(...) par type de Datasource (MySQL, Oracle, ...) et d'utiliser ConfigAdmin (http://www.dynamicjava.org/articles/osgi-compendium/configur(...) pour creer les DataSources. Ca a l'avantage d'etre du pur service OSGi et aussi de marcher sur les plateformes ou les fragments sont pas supportés :)
D'ailleurs, dans Felix, le support des fragments est partiel, pas inexistant.
La ce sont deja des projets plus comparables: ce sont 2 serveurs d'applications certifiés Java EE 5.
Les différences viennent des a-cotés: modularité et flexibilité, solution de clustering, console d'administration, facilités de dévelopement sont quelqu'uns des points forts de JOnAS.
Certains diront aussi que la communauté JOnAS est plus sympathique et réactive, mais je suis biaisé ;)
Un de nos objectifs est aussi de pouvoir fabriquer des serveurs à la demande.
C'est à dire dans le serveur, il n'ya que ce dont l'application a besoin: une appli web qui envoit des mails ? ne seront installés (et présents en mémoire) que les services nécessaires.
De plus si les besoins de l'application evoluent (on rajoute des EJBs par exemple), on peut rajouter les services à la volée. Voire meme les enlever si le besoin s'en fait sentir.
Bref, on optimise la gestion des resources en s'adaptant aux applications.
Lol, on voit le connaisseur OSGi ;)
Non sans rire, C'est faisable. j'en veux pour preuve le conteneur EJB3 EasyBeans qui fonctionne à la fois sur Felix et Equinox.
Les features de service-mix ayant repris le nom des features eclipse :)
En ce qui concerne les Par, il n'y a pas isolation totale. D'apres la doc, ca tourne toujours avec 1 seul framework, donc pas de possibilité de faire tourner indépendament l'une de l'autre 2 versions IDENTIQUES du meme bundle.
Par contre c'est tout à fait faisable d'avoir, de maniere colocaliser 2 versions differentes du bundle, si les import/export sont bien gérés, il est possible de bien isoler les applications. Et ca, ce n'est pas le PAR qui t'apporte ca, ce sont tes metaddonnées OSGi. Donc avec nos deployment plan on peut faire pareil: il n'y a qu'a declarer des versions DIFFERENTES de chaque bundle et le tour est joué...
Dans l'ordre:
* Pour le moment, seul Felix est supporté comme framework OSGi, néanmoins les adhérences à une implémentation particuliere sont extremement limitées et donc le support d'un autre framework est possible relativement simplement.
* Le support des WAR avec meta-données OSGi est une chose que l'on veut faire. De maniere générale, supporter tous les types d'archives Java EE comme bundles OSGi
* Pour les PAR, coté JOnAS nous avons des deployment-plan. Ce sont des fichiers XML qui permettent de regrouper des bundles ou modules Java EE afin de les deployer/undeployer ensemble.
Tomcat est un conteneur de Servlet/JSP, il ne sait donc pas gerer les EJBs par exemple (la specification Java EE est beaucoup plus etendue que seulement l'etage web).
JOnAS lui est un server Java EE complet, il supporte donc l'ensemble de la stack standard (EJB, Webservices, Resources, Persistence, Application Client Container, ...).
[^] # Re: l'avenir ?
Posté par Guillaume Sauthier . En réponse à la dépêche JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !. Évalué à 2.
Si l'on prend du recul, JOnAS fait, lui aussi, parti d'un ensemble plus grand: OW2.
Meme si OW2 n'est pas une entreprise, les projets OW2 peuvent former les pieces d'une plateforme SOA (Portal avec eXo, JBI avec PEtALS, ...)
La suite est peut-etre plus polemique, entre partisans Spring/Java EE :)
L'ennui avec une approche SpringSource, c'est l'absence de standard. Ils piochent a droite à gauche ce qui les interresse.
A y regarder de plus pret, à force de rajouter des trucs dans Spring, on se retrouve avec un serveur d'application complet (transaction, persistence, connexion DB, ...) packagé dans une webapp ! Le tout sans support des standard alors qu'ils existent.
En quoi Java EE c'est le mal ? Les EJB2 et le XML partout c'est fini ! Si vous suivez les nouvelles specifications Java EE, c'est bien la modularité et la légereté qui s'imposent (EJB3.1 lite, Java EE Web Profile pour n'en citer que deux).
L'approche JOnAS est la suivante: JOnAS est un socle sur lequel deployer les services techniques dont vos applications ont besoin. Et seulement ceux requis! En bref, si seuls les servlets et un support transactionnel sont necessaire pour vos applications, JOnAS peut etre configuré pour n'installer que le conteneur web (Tomcat) et JOTM. Et la on se rapproche du triplet magique Tomcat/OSGi/Conteneur leger (en meme temps on peut mettre Jetty si on veut)...
[^] # Re: Passerelle Apache Felix?
Posté par Guillaume Sauthier . En réponse à la dépêche JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !. Évalué à 1.
C'est possible que le par modifie les bundles qu'il contient en rajoutant des metadonnées qui vont empecher d'autres bundles d'utiliser les packages.
Pour le coup du "datasource provider" generic, c'est une facon de faire. Une autre serait d'avoir une ManagedServiceFactory (http://www.osgi.org/javadoc/r4/org/osgi/service/cm/ManagedSe(...) par type de Datasource (MySQL, Oracle, ...) et d'utiliser ConfigAdmin (http://www.dynamicjava.org/articles/osgi-compendium/configur(...) pour creer les DataSources. Ca a l'avantage d'etre du pur service OSGi et aussi de marcher sur les plateformes ou les fragments sont pas supportés :)
D'ailleurs, dans Felix, le support des fragments est partiel, pas inexistant.
[^] # Re: vs Tomcat
Posté par Guillaume Sauthier . En réponse à la dépêche JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !. Évalué à 2.
Les différences viennent des a-cotés: modularité et flexibilité, solution de clustering, console d'administration, facilités de dévelopement sont quelqu'uns des points forts de JOnAS.
Certains diront aussi que la communauté JOnAS est plus sympathique et réactive, mais je suis biaisé ;)
[^] # Re: Passerelle Apache Felix?
Posté par Guillaume Sauthier . En réponse à la dépêche JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !. Évalué à 2.
C'est à dire dans le serveur, il n'ya que ce dont l'application a besoin: une appli web qui envoit des mails ? ne seront installés (et présents en mémoire) que les services nécessaires.
De plus si les besoins de l'application evoluent (on rajoute des EJBs par exemple), on peut rajouter les services à la volée. Voire meme les enlever si le besoin s'en fait sentir.
Bref, on optimise la gestion des resources en s'adaptant aux applications.
[^] # Re: Passerelle Apache Felix?
Posté par Guillaume Sauthier . En réponse à la dépêche JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !. Évalué à 1.
Non sans rire, C'est faisable. j'en veux pour preuve le conteneur EJB3 EasyBeans qui fonctionne à la fois sur Felix et Equinox.
Les features de service-mix ayant repris le nom des features eclipse :)
En ce qui concerne les Par, il n'y a pas isolation totale. D'apres la doc, ca tourne toujours avec 1 seul framework, donc pas de possibilité de faire tourner indépendament l'une de l'autre 2 versions IDENTIQUES du meme bundle.
Par contre c'est tout à fait faisable d'avoir, de maniere colocaliser 2 versions differentes du bundle, si les import/export sont bien gérés, il est possible de bien isoler les applications. Et ca, ce n'est pas le PAR qui t'apporte ca, ce sont tes metaddonnées OSGi. Donc avec nos deployment plan on peut faire pareil: il n'y a qu'a declarer des versions DIFFERENTES de chaque bundle et le tour est joué...
[^] # Re: Passerelle Apache Felix?
Posté par Guillaume Sauthier . En réponse à la dépêche JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !. Évalué à 2.
* Pour le moment, seul Felix est supporté comme framework OSGi, néanmoins les adhérences à une implémentation particuliere sont extremement limitées et donc le support d'un autre framework est possible relativement simplement.
* Le support des WAR avec meta-données OSGi est une chose que l'on veut faire. De maniere générale, supporter tous les types d'archives Java EE comme bundles OSGi
* Pour les PAR, coté JOnAS nous avons des deployment-plan. Ce sont des fichiers XML qui permettent de regrouper des bundles ou modules Java EE afin de les deployer/undeployer ensemble.
[^] # Re: vs Tomcat
Posté par Guillaume Sauthier . En réponse à la dépêche JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !. Évalué à 2.
JOnAS lui est un server Java EE complet, il supporte donc l'ensemble de la stack standard (EJB, Webservices, Resources, Persistence, Application Client Container, ...).