Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Serveurs Java : Stratégie commerciale pour introduire le support d'OSGI ?

SpringSource dm Server vs. Serveurs JEE Hybrides

Le 3 septembre 2009 à 11:24, par Hikage

21PARTAGES

Voter pour

0

Voter contre

0

Lorsque SpringSource à lancé Dm Server, il y avait une volonté de proposer une alternative plus souple et modulaire que la stack JEE actuelle.

Partant de l'hypothèse que beaucoup d'applications Spring ne nécessitent finalement qu'un simple conteneur de Servlet, Dm Server propose une compatibilité avec les applications de ce type et permet de les déployer sans avoir besoin de modifier celles-ci.
A coté de cela, Dm Server fut le premier serveur à proposer le déploiement de Bundle OSGi.
Mais par contre les applications dites entreprise ( EAR ) ne sont pas gérées par ce serveur.

Mais depuis, les serveurs concurrents proposent doucement eux aussi un support des Bundle OSGi.
C'est le cas de Glassfish ou encore JOnAS, qui ont comme principal avantage d'être avant tout un serveur JEE, et donc compatible avec toutes les applications déjà développées en entreprise.

Mais mieux encore, ces serveurs proposent une intégration entre ces deux modèles, permettant à des EJB d'accéder à des services OSGi, ou même de déployer un EJB en tant que service OSGi !

N'est-ce pas une meilleure solution pour attirer du monde vers OSGi, en permettant une transition plus facile ? Qu'en pensez vous ?

Liens

SpringSource Dm Server
Déploiement JEE et OSGi avec Jonas
Déploiement OSGi avec Glassfish v3

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

Commenter Signaler un problème

clement.escoffier

Futur Membre du Club

Le 15/09/2009 à 9:23

Bonjour,

Oui, le modele de developpement proposé par JOnAS est tres interessant et ouvre vraiment de nouvelles perspectives.

En fait, ce post rebondi a la suite d'une analyse faite par Eric Newcomer (http://searchsoa.techtarget.com/news...365017,00.html

I should add that when talking about OSGi, people sometimes conflate OSGi-enabled middleware (in which a product uses OSGi internally but does not expose the OSGi programming model to the developers) and the "native" use of the OSGi framework. Using the OSGi programming model directly for enterprise applications is where the real benefits will be achieved, but this is also where some challenges still remain. Along with the additional structure of the OSGi programming model, however, comes the additional benefits of improved flexibility and decreased cost. But there is really no single answer that applies to each project.

JOnAS a decide autour de 2005 de choisir le modele OSGi et de ne pas le cacher. Bien qu'a terme des conflits peuvent potentiellement apparaitre (comme ceux illustrés dans la RFC 138 d'OSGi R4.2), il me semble que c'est la marche a suivre.

Une difference majeure avec Spring-DM est la volonté délibérée de ne pas imposer de modele de development. Ainsi, pur-OSGi, iPOJO et EJB peuvent cohabiter et collaborer via le registre de service OSGi, ce qui replace OSGi comme l'Universal Middleware.

Enfin, une autre derniere difference importante est la roadmap de JOnAS. JOnAS vise une grande flexiblité, et donc une adaptation a la volée des capacités (Services techniques) du serveur en fonction des requis. On imagine bien evidement ce genre de fonctionnalités dans des contextes comme le Cloud, les ESB, les passerelles legeres...

Clement

PS: je suis l'auteur du post http://blog.akquinet.de/2009/07/27/j...-jee-and-osgi/

Voter pour

0

Voter contre

0

Membre émérite

Le 15/09/2009 à 10:00

Evidement (je travaille dans l'équipe GlassFish), je pense que l'approche Java EE + OSGi est meilleure. En particulier l'injection avec @Resource (annotation standard Java EE, JSR 250) de Declarative Services OSGi, de Spring Beans, ou de toute autre ressource me parait bien être dans l'esprit de Java EE.

Ce qui différencie GlassFish de dmServer et de JOnAS c'est sa couche HK2 qui permet de changer d'implémentation OSGi (Felix par défaut, mais fonctionne aussi avec Knopflerfish et Equinox) et même de fonctionner sans OSGi (mode "Static"

ce qui peut-être utile pour des cas ou l'on embarque le serveur et qu'on le pilote avec une API (embedded).

Voter pour

0

Voter contre

0

Rédacteur

Le 11/11/2009 à 15:15

Je regarde avec intérêt ce qui se fait autour d'OSGI car dans ma boite, on va vers Java (grosse Banque). Et je ne pense pas que l'approche JEE seule soit une bonne alternative si on compare à ce qui se fait sur mainframe/Cobol/IMS.
Par contre, l'approche "sans JEE" me parait pas bonne pour le moment car effectivement, avec l'existant on aurait un problème.

Une approche hybride JEE/OSGI comme Jonas me parait bien car elle offre les 2 mondes.
Pour vous donner un exemple, ne pas pouvoir avoir d'EJB dans Spring dm Server me parait une erreur car non seulement, il existe des applis avec EJB et on ne va pas les refaire comme ça du jour au lendemain et d'autre part, les EJBs sont parfois le passage obligé d'un point de vu technique comme certains outils de communication avec le mainframe (je vous passe les détails perso de notre SI).

Je sais qu'il y a DOSGI mais je me demande si une intégration avec JEE ne serait pas un bien. Il y a peut être des raisons de puristes à ne pas se lier à JEE mais la réalité de l'entreprise est qu'il y a JEE alors....
Et puis je ne vois pas où est le problème de faire un truc hybride, ça ne fait qu'ajouter à l'intérêt de la solution. Au jour d'aujourd'hui, on ne pourrait pas utiliser dm Server tout simplement parce qu'il manque un conteneur d'EJB, c'est tout aussi simple que cela.

Voter pour

0

Voter contre

0

Membre émérite

Le 11/11/2009 à 20:35

Il y a plusieurs façons d'adopter OSGi. Celle ou tout doit être un bundle me parait trop radicale. Avec GlassFish (v3) nous proposons un environnement qui exécute tous les composants Java EE (bien sûr) et tout bundle OSGi tout en permettant des appels de l'un vers l'autre. Ca ouvre des possibilités intéressantes comme le déploiement d'application Spring dans un conteneur Spring dm (de simples JAR déposés dans GlassFish) qui cohabitent avec un "existant" Java EE. Le blog de Jérôme le détaille ici: http://blogs.sun.com/dochez/entry/glassfish_v3_extensions_part_3. Finalement OSGi reste un détail d'implémentation dans ce cas.

Ensuite il y a ce que certains appellent l'approche "hybride" et en particulier le déploiement WAB.

Ceci dit, indépendamment d'OSGi, tout ce qui est publié dans JNDI (donc les EJBs) est injectable (au moins de 2 manières) dans Spring...

Voter pour

0

Voter contre

0

Rédacteur

Le 12/11/2009 à 7:20

d'accord avec toi.
Pour moi hybride voulait dire ce que tu décris avec GlassFish, pas l'approche WAB.
C'est vrai qu'avec Spring on peut injecter des POJO et des EJB déclarés dans JNDI. Le seul "problème" est l'étanchéité des "bundles" JEE et le déploiement de plein d'applications au sein du même serveur. On peut passer par le déploiement de tout ce qui n'est pas JEE avec Spring et une hiérarchie d'applicationContext mais je ne pense pas que cela soit optimal (en fait je n'ai pas essayé). L'aspect déploiement et dépendance des bundles OSGI me parait intéressante ici

Voter pour

0

Voter contre

0