Choisir entre Impala et OSGi

Question

J'ai enquêté sur OSGi pour le logiciel de mon entreprise, mais j'ai récemment recommandé de jeter un oeil à Impala. Selon sa page Web, Impala est "une structure de module dynamique pour les applications Web basées sur Java, basée sur le framework Spring." En un coup d'œil, et en regardant ce blog post sur les différences, les différences clés que je peux voir sont que Impala est plus simple que OSGi, ne gère pas le versionnage de composants tiers, et est beaucoup moins utilisé/connu (I ne vois pas une seule question à ce sujet sur Stack Overflow). Je me demande si les personnes qui ont une expérience directe avec Impala et OSGi (c.-à-d. Ceux qui l'ont étudié plus profondément que la lecture des articles de blog et des docs en ligne) ont plus d'informations sur les différences pratiques entre les deux. sur quels types de projets chacun peut être plus ou moins adapté.

Éditer: Il peut également être intéressant d'inclure Springsource Slices dans la comparaison, bien que ce soit encore un prototype précoce. En un coup d'œil, il semble fonctionner uniquement dans DM Server.

Answer 1

À mes yeux, il n'y a aucune comparaison. OSGi est un framework mature qui existe depuis 10 ans et qui est à la base de la mise en œuvre de la plupart des conteneurs Java d'aujourd'hui. OSGi a de plus en plus d'adoption, il y a des livres disponibles et, oui, les gens en parlent sur Stack Overflow!

Impala n'a même pas atteint une version stable et semble être un projet à 1 personne, bien qu'il demande maintenant des développeurs supplémentaires.

Donc, cela dépend de vos critères. Si vous étudiez la technologie par intérêt, je ne vois aucun problème à écrire des articles avec Impala. Si vous cherchez à fonder les futurs produits de votre entreprise, alors je pense que ce serait une négligence professionnelle.

Answer 2

L'approche de la modularité d'Impala est très faible en ce qui concerne le partage contrôlé entre les modules. Le problème est que Impala suit toujours l'ancienne approche hiérarchique du style J2EE.

Tout le monde peut écrire un système de module qui restreint la visibilité des classes entre les modules. La partie difficile est de savoir comment réintroduire les dépendances entre les modules de sorte que des classes spécifiques et des interfaces d'un module puissent être vues par un autre module. Dans OSGi, nous faisons cela en exportant et en important des paquets, donc nous avons un graphe de dépendance non-hiérarchique.

Dans Impala, si vous voulez voir les classes dans un autre module, alors votre module doit être un enfant ou un descendant de ce module. Autrement dit, les modules ne peuvent voir que leurs propres classes et celles de leurs ancêtres. Maintenant, si vous voulez partager certaines classes avec votre module frère (par exemple une bibliothèque que vous utilisez tous les deux), vous devez déplacer cette bibliothèque dans le chemin de classe de votre ancêtre partagé. Dans le pire des cas, vous devez le déplacer jusqu'au module racine. Maintenant, la bibliothèque est visible pour TOUS les autres modules, qu'ils le veuillent ou non! En effet, si un autre module voulait utiliser une version différente de la bibliothèque, il serait empêché de le faire.

Si vous disposez simplement d'une copie de la bibliothèque dans chaque emplacement où elle est utilisée, vous empêchez les modules utilisant cette bibliothèque de communiquer entre eux. Ils recevront ClassCastExceptions lorsqu'ils essaieront de passer des objets entre eux.

Un problème similaire est inhérent à J2EE si deux applications Web doivent utiliser la même bibliothèque. Typiquement, les développeurs J2EE copient simplement la bibliothèque, mais cela crée des applications "silo" qui ne peuvent pas communiquer entre elles. Ce n'est tout simplement pas la façon de construire un logiciel modulaire.

Les points de Steven semblent également pertinents. Pour autant que je sache, personne n'utilise Impala en dehors de son auteur.