Quelles sont les différences fondamentales entre OSGi et Java EE?

J'ai donc pris un peu de temps cet après-midi pour enfin s'asseoir et de commencer à lire sur le mystérieux et insaisissable "OSGi" et sa soi-disant bundles.

OK, donc je pense je l'obtenir. Un OSGi "bundle" est en fait un POT avec quelques informations sur le manifeste. Et, au lieu de déploiement d'une application normale du serveur (ou autre récipient), vous pouvez la déployer sur un serveur OSGi comme Apache Felix. Il exécuter, puis fournit les services aux utilisateurs/clients.

Comment est-ce différent d'une OREILLE normale en cours de déploiement sur un serveur d'application???

OSGi semble être à la hausse (je continuer à courir dans la!) mais pour la vie de moi je ne comprends pas ce qu'il offre (fonctionnalité-sage) sur tout ce que vous pouvez faire avec real-deal enterprise server comme GlassFish ou au Printemps.

Je sais que le monde n'est pas devenu fou, donc je suis évidemment manque quelque chose. N'ont tout simplement pas été en mesure de comprendre quoi. Merci pour toute aide ou des connaissances!

  • Je pense que si c'était libellée comme "Quelle est la différence fondamentale entre OSGi et Java EE" puis ce serait plus utile et moins "avis"basée sur la
  • À quel point l'on peut dire... OSGi est principalement conteneur qui fait quoi CDI essaie de le résoudre (injection de dépendance et de résolution), mais n'a généralement pas l'empêcher de s'exécuter quand il y a des erreurs. Il fournit une interface [généralement par le biais de la ligne de commande] qui permettrait de bugs lors de l'exécution. Java EE aurait besoin d'un déploiement à résoudre les problèmes. Java EE est une application de la pile, si elle fournit des services de conteneurs, c'est seulement dans le cadre de l'application (bien que peut obtenir des injections à partir d'un serveur) Note bien que les gros serveurs Java EE sont construites sur OSGi maintenant.
InformationsquelleAutor IAmYourFaja | 2011-09-20
  1. 22

    Un bundle OSGi est plus un "module logiciel" que d'un "pot", "guerre", ou "l'oreille" du fichier. Bundles OSGi rarement offrir des avantages si elles regroupent un ensemble de l'application; cependant, ils sont très bénéfiques dans l'automatisation et la bonne gestion de l'accrocher beaucoup de bibliothèques.

    Donc considérer le problème OSGi a tenté de résoudre, et vous permettra de mieux comprendre où il se situe. C'est la Java équivalent de la "diamond héritage" modèle à partir de C++. Elles comprennent deux bibliothèques, qui ont chacun besoin d'une bibliothèque de journalisation commune, mais dans ce cas, il n'est pas à cause de l'héritage multiple, c'est à cause de multiples inclure des déclarations.

    Si les deux bibliothèques travaillent tous les deux avec la même version de la commune de la bibliothèque de journalisation, vous avez de la chance. S'ils ne le font pas, pour obtenir à chaque bibliothèque de fonctionner correctement de manière indépendante, vous avez besoin de charger deux copies de la même bibliothèque, chaque qui utilise probablement les mêmes espaces de nom (et souvent les mêmes noms de classe).

    OSGi est un moyen de regroupement qui permet à deux versions de la même bibliothèque à charger qui utilisent les mêmes espaces de nom, les mêmes noms de classes, mais ont été créés à des moments différents. Il a également crochets jusqu'à la "bonne" version de la "droite" bundle OSGi, la prévention d'un bundle de l'aide de la "mauvaise version" de la "droite" de la bibliothèque.

    Java EE fait beaucoup, mais ce n'est pas quelque chose que Java EE même adresse. Au mieux, le projet Jigsaw travaillait sur le même problème. Où Java EE /OSGi confusion vient jouer, c'est que la plupart des adopteurs précoces d'OSGi regroupement ont été ceux qui ont mis en œuvre des fonctionnalités similaires à certains des librairies Java EE. Cela dit, le conteneur de-connexion-cadre (OSGi) n'avait rien à voir avec le logiciel fonctionnalité (bien que certains de la découverte a été structurellement modifiés pour se conformer avec OSGi groupement des exigences).

    • Ne serait pas transitive dépendance gestionnaires tels que Maven ou Apache Ivy résoudre ce "POT de l'enfer" sur leur propre? Si mon application dépend de 2 bibliothèques de L1 et de L2 et L1 dépend joda-time-1.1.jar et L2 dépend de joda-time-1.2.jar Lierre, résoudre cela pour moi, et tant que j'ai les deux versions de joda-time dans mon classpath lors de l'exécution, je suis bon pour aller. Toujours pas voir la forêt à travers les arbres ici...
    • Ivy pouvez télécharger les deux fichiers jar, mais quand il est temps de le compiler, Java ne permet pas de deux différentes classes définies dans la même classe loader avec le même nom. Si vous mettez sur le chemin de classe, le premier qui répond le nom de la classe sera le retour de la classe, peu importe si c'est la bonne ou la mauvaise version. Si vous avez besoin du chargeur de classe des arbres dépend spécifiquement les "faisceaux" de l'appel de la classe. Ce qui signifie que vous besoin d'un moyen de suivre ce que le faisceau de besoins, d'où les fichiers manifest et, éventuellement, un "cadre" alias Jigsaw ou OSGi.
    • Ok....donc OSGi vise essentiellement l'espace de noms problèmes en offrant une gamme de chargeurs de classes spécialisées. Donc, si vous êtes assez chanceux pour avoir un graphe de dépendance où aucun des deux libs dépendre sur le même pot (ou même jar versions différentes), alors vous n'avez pas besoin d'OSGi. Otherise, il semble comme une jolie outil essentiel. Est-ce une bonne évaluation. Aussi, si OSGi est seulement maintenant juste à la hausse, comment avez-Java EE et applications existaient pour ce long sans s'attaquer à ce problème? C'est une sorte de grands!
    • Dans le passé, JEE implémentations soit géré à l'adresse au comité une API standard de l'interface (et ont de multiples implémentations de ladite interface standard) ou des bibliothèques réussi à avoir des rôles différents (de sorte qu'ils n'entrent pas en conflit en raison de nom d'espacement), ou à la bibliothèque des écrivains de ne pas devenir paresseux avec rétro-compatibilité. Il n'est pas trop souvent que vous avez besoin (pour vérifier la fonctionnalité correcte) 1.0.5 et 1.0.7 de la même bibliothèque est chargé en même temps (à la satisfaction de deux autres bibliothèques dépendances); mais, si vous incluez assez de trucs 3ème partie, finalement il ne se passera.
    • juste une petite remarque à mentionner où Java fonctionne encore sans avoir besoin d'un OSGi solution. Si tous les 3e partie les bibliothèques ont la même version de la même bibliothèque, alors vous avez la garantie d'un travail sans rien de "plus" dans la classe Java chargeur. OSGi traite de la "les deux bibliothèques ont besoin de la même classe, à différentes versions de" problème, pas le "deux personnes ont besoin de la même classe de problème, au même version" problème.
    • Quelques autres choses OSGi offre en outre l'isolement service de la découverte et de la dynamique de rechargement de services individuels (sans redémarrage de l'application). Il y a aussi un tas d'installations supplémentaires décrites dans le OSGi Compendum (configuration standard, gestion des interfaces, etc.)
    • Java EE fournit cette "fonctionnalité" au moment de l'exécution implicitement, par classloading hiérarchies.. Weblogic, comme les 3 couches de où vous pouvez charger la même bibliothèque, et dites à votre "module" ou de l'application ou de la botte ou de l'oreille ou que ce soit celui qui à la charge au moment de l'exécution, de sorte que votre claime que java ee n'a rien pour remédier à ce problème, c'est faux, même au moment de l'écriture, parce que les fonctionnalités dont je parle ont été disponibles au moins depuis 2008, et probablement plus tôt.
    • Désolé de vous dire cela, mais JEE chargement des classes de la hiérarchie s'arrêtera dès que la classe est trouvé. Les hiérarchies il n'y a pas de hiérarchies construit ainsi une "déclaration" peut tirer dans une version de la bibliothèque, tandis qu'un autre "include" tire dans une autre version de la bibliothèque.

    InformationsquelleAutor Edwin Buck
  2. 3

    Comparant Java EE avec OSGi, c'est comme comparer des pommes et des oranges avec le bonus supplémentaire de ne pas savoir ce qui est quoi.

    Java EE accent est mis sur évolutif multi-tier entreprise applications en environnement hétérogène et l'échelle de l'entreprise d'intégration de systèmes d'information.

    OSGi a commencé au coin de la rue par l'intégration de plusieurs bases de code dans une JVM (veuillez excusez-moi pour le extrêmement bref).

    Bien sûr certains problèmes (par exemple, le déploiement à chaud) sont communs aux deux environnements, mais à un degré variable.

    Bien sûr, vous pouvez mettre à niveau, de la rétrogradation et de races croisées deux à la fois et ils vont se rencontrer quelque part au milieu.

    Donc la question ne devrait pas être "Quel est le bénéfice d'Un plus B", mais quelque chose comme "Dans ce domaine Un a des avantages indéniables par rapport à B et vice-versa?" Permettez-moi de reformuler: "Quand dois-je besoin d'un marteau et quand dois-je besoin d'une scie?"

    • Si c'est la question, quelle est votre réponse? 😉
    InformationsquelleAutor A.H.
  3. 2

    Je suis désolé, mais TOUTES les réponses ici sont complètement risible. La dépendance de version problèmes résolus avec OSGi? Pooooohlease.... Jamais entendu parler de la classe loader politiques en application des serveurs?

    OSGi semble comme une idée de conserver de la vente de nouveaux livres et de la formation, alors que les besoins fonctionnels ont été couverts pendant des éons par le POT de l'OREILLE/emballage & déploiement en JEE. Ceux qui achètent en il n'y a jamais eu de comprendre comment ils sont manipulés. Il y a aussi une question de tendances de la mode. I. e. non ce sont des considérations techniques qui sont une honte pour cette industrie.

    Réinventer la roue est rentable car il y a des tonnes de fous là-bas. Malheureusement, il ya des tonnes de type gestion des crédules qui veulent être sur le "à la pointe de la technologie" qui se fera un plaisir de financer leurs employés des cours, d'absorber la courbe d'apprentissage, et ensuite de payer par le nez en "re-engineering" de choses qui n'avaient rien de mal avec eux pour commencer.

    Ce n'est pas une question de "suis-je utiliser un tournevis, un marteau". C'est plus une question de "hey boss, il y a cette chose de nouveau là-bas appelé HEMMAR, et c'est vraiment cool!". "N'est-il pas un MARTEAU?", "Non, non, c'est waaaaay mieux, c'est un HEMMAR, c'est pour la conduite des clous dans des planches, il va révolutionner le monde".

    • Alors que sorta hors sujet (fonctionnellement) c'est la meilleure et la plus correcte réponse ici, la différence étant que vous soit point pour une jee "conteneur" ou de télécharger et d'installer un "gratuit" dans votre org et apprendre à l'utiliser correctement.
    • Les applications de l'entreprise par la nature évoluer. Vous ne produisent pas d'applications d'entreprise sur le jour 1. JEE classloading des politiques un vrai cauchemar à gérer quand vous avez 1000 de modules et ils ont tous de travailler ensemble. JEE module ne peut être un EJB, MDB. RAR ou WEB que sur un seul BOCAL? Comment sur les temps d'arrêt si vous souhaitez mettre à jour, même pour un seul module...Aucun progressive! Donc Pooooohlease JEE n'est pas une façon proche de ce OSGi est à résoudre!
    InformationsquelleAutor Tomasz Jankowski
  4. 2

    La plupart des grands avantages, au moins les raisons que nous avons d'utiliser OSGi, sont énumérées à http://karaf.apache.org/, notamment les deux premiers.

    En outre, l'OSGi alliance a une longue liste d'avantages: https://www.osgi.org/developer/benefits-of-using-osgi/.

    • Il est intéressant d'ajouter qu'un bundle OSGi n'est pas un "plein" de l'application, mais plutôt un sous-composant qui peut être utilisé par toute autre bundle, la collection qui composent une application.
    InformationsquelleAutor Tony