IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

OGSi Java Discussion :

Dm Server versus Serveur Hybride JEE/OSGi [Débat]


Sujet :

OGSi Java

  1. #1
    Rédacteur
    Avatar de Hikage
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    1 177
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2004
    Messages : 1 177
    Points : 6 301
    Points
    6 301
    Par défaut Dm Server versus Serveur Hybride JEE/OSGi
    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

  2. #2
    Futur Membre du Club
    Inscrit en
    Septembre 2009
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : Septembre 2009
    Messages : 4
    Points : 5
    Points
    5
    Par défaut
    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/

  3. #3
    Membre émérite
    Avatar de alexismp
    Homme Profil pro
    Inscrit en
    Janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 1 503
    Points : 2 777
    Points
    2 777
    Par défaut
    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).

  4. #4
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2004
    Messages : 1 883
    Points : 3 510
    Points
    3 510
    Billets dans le blog
    2
    Par défaut
    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.

  5. #5
    Membre émérite
    Avatar de alexismp
    Homme Profil pro
    Inscrit en
    Janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 1 503
    Points : 2 777
    Points
    2 777
    Par défaut
    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/gl...ensions_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...

  6. #6
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2004
    Messages : 1 883
    Points : 3 510
    Points
    3 510
    Billets dans le blog
    2
    Par défaut
    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

Discussions similaires

  1. Dm Server versus Serveur Hybride JEE/OSGi
    Par Hikage dans le forum Spring
    Réponses: 0
    Dernier message: 03/09/2009, 11h24
  2. [sql server 2K] serveur lié AD
    Par MALAGASY dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 19/06/2006, 14h16
  3. [FTP] [FileZilla Server] Configuration Serveur FTP
    Par bestdomdom dans le forum Serveurs (Apache, IIS,...)
    Réponses: 2
    Dernier message: 02/06/2006, 07h00
  4. [sql server]Ajouter serveur actif
    Par liliprog dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 26/01/2006, 09h42
  5. Réponses: 3
    Dernier message: 01/09/2005, 16h24

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo