OSGi peut aider à réduire la complexité?

Question

J'ai vu beaucoup de présentations sur OSGi et je pense que cela semble prometteur pour appliquer une meilleure modularisation. Apparemment « hotdeployment » et « en cours d'exécution différentes versions de x en parallèle » sont des points de vente maire aussi.

Je me demande si ce OSGi promet de résoudre un problème est même ...? Cela m'a rappelé les premiers jours de OO lorsque des demandes similaires ont été bonne:

Lorsque OO était nouveau, le grand argument était réutilisabilité. Il a été largement affirmé que lors de l'utilisation OO, on ne doit « écrire une fois » et pourrait alors « utiliser partout ».

Dans la pratique, je ne voyais que ce travail pour quelques exemples de niveau assez bas. Je pense que la raison est que l'écriture de code réutilisable est difficile. Pas techniquement mais d'un point de vue de la conception de l'interface. Vous devez anticiper comment les futurs clients voudront utiliser vos classes et prendre les bons choix à l'avant. Cela est difficile, par définition, et donc le bénéfice potentiel de réutilisabilité souvent échoué à livrer.

Avec OSGi , je le soupçon que là encore, nous pourrions tomber des promesses, des solutions possibles pour les problèmes que nous n'ont pas vraiment. Ou si nous les avons, nous ne les avons pas en quantité assez grande et la gravité qui justifierait d'acheter en OSGi aide. « Hotdeployment », par exemple d'un sous-ensemble de modules est certainement une excellente idée, mais comment souvent vraiment travail? Combien de fois non pas parce qu'il est avéré que vous avez obtenu la modularisation mal pour la question particulière? Que diriez-vous des entités modèles qui sont partagées entre plusieurs modules? Est-ce que ces modules doivent tous être modifiés en même temps? Ou avez-vous aplatissez vos objets primitifs et utiliser uniquement les en communication inter-module, afin d'être en mesure de garder les contrats d'interface?

Le problème le plus difficile lors de l'application OSGi est, je présume, pour obtenir le modularisation "droit" . Semblable à obtenir les interfaces de vos classes en plein OO, avec OSGi, le problème reste le même, à plus grande échelle cette fois, le paquet ou même niveau de service.

Comme vous l'avez deviné, je suis en train d'essayer d'évaluer OSGi à utiliser dans un projet. Le principal problème que nous avons, augmente la complexité que le code de base se développe et je voudrais briser le système en modules plus petits qui ont des interactions moins et plus définies.

• Etant donné aucun cadre ne peut jamais aider à décider ce modularisation, a OSGi jamais payé au large pour vous?
• a-t-il rendu votre vie plus facile lorsque vous travaillez en équipe?
• a-t-il contribué à réduire du nombre de bugs?
• Avez-vous déjà avec succès "hotdeploy" les principaux composants?
• Est-ce que l'aide OSGi pour réduire la complexité au fil du temps?
• Est-ce que OSGi tenir ses promesses?
• At-il répondu à vos attentes?

Merci!

Answer 1

OSGi est payante car elle applique modularisation à l'exécution, quelque chose que vous n'avez pas auparavant, causant souvent la conception et la mise en œuvre sur papier à la dérive. Cela peut être une grande victoire au cours du développement.

Il contribue certainement le rendre plus facile à travailler en équipe, si vous laissez les équipes se concentrent sur un seul module (peut-être un ensemble de faisceaux), et si vous obtenez votre droit de modularisation. On pourrait faire valoir que l'on peut faire la même chose avec un outil de construction comme Ant + Ivy ou Maven et dépendances, la granularité des dépendances qui OSGi utilise est à mon avis bien supérieur, ne provoquant pas le typique « glisser dans tout, plus l'évier de cuisine » que les dépendances de niveau JAR cause.

Code modulaire avec moins de dépendances tend à conduire à un code plus propre et moins, à son tour, conduit à moins de bugs qui sont plus faciles à tester et résoudre. Elle favorise également la conception de composants aussi simple et directe que possible, tout en ayant en même temps la possibilité de brancher des implémentations plus complexes, ou l'ajout d'aspects tels que la mise en cache en tant que composants séparés.

Déploiement à chaud, même si vous ne l'utilisez pas à l'exécution, est un très bon test pour valider si vous Modularized correctement votre application. Si vous ne pouvez pas démarrer vos paquets dans un ordre aléatoire à tous, vous devriez chercher à savoir pourquoi. , Il peut aussi faire de votre cycle de développement beaucoup plus rapide si vous pouvez mettre à jour un faisceau arbitraire.

Tant que vous pouvez gérer vos modules et dépendances, les grands projets restent gérables et peuvent être facilement évolué (vous permettant d'économiser du sans doute mauvais « réécriture complète »).

L'inconvénient de OSGi? Il est un cadre très bas niveau, et tandis qu'il résout les problèmes, il est destiné à bien, il y a des choses que vous devez toujours vous résoudre. Surtout si vous venez d'un environnement Java EE, où vous obtenez fil gratuit et la sécurité d'autres concepts qui peuvent être très utiles si vous avez besoin, vous devez trouver des solutions à ces problèmes dans OSGi vous.

Une erreur courante est de ne pas utiliser des abstractions au-dessus de OSGi pour rendre cela plus facile pour le développeur moyen. Ne jamais les laisser jouer avec ServiceListeners ou ServiceTrackers manuellement. Examiner attentivement ce que les faisceaux sont et ne sont pas autorisés à le faire. Êtes-vous prêt à donner aux développeurs l'accès au BundleContext ou cachez-vous tout cela d'eux en utilisant une certaine forme de modèle déclaratif

Answer 2

J'ai travaillé avec OSGi depuis quelques années (bien que dans le cadre d'un projet d'éclipse, et non pas dans un projet web). Il est clair que le cadre ne vous dispense pas de penser comment modularisation. Mais il vous permet de définir les règles.

Si vous utilisez des paquets et définit (Dans un document de conception? Verbale?) Que certains emballages ne peuvent pas accéder à des cours dans d'autres emballages, sans application de cette contrainte, il sera cassé. Si vous embaucher de nouveaux développeurs, ils ne connaissent pas les règles. Ils vont briser les règles. Avec OSGi, vous pouvez définir les règles dans le code. Pour nous, ce fut une grande victoire, car il nous a permis de maintenir l'architecture de notre système.

OSGi ne réduit pas la complexité. Mais il contribue certainement à gérer.

Answer 3

J'utilise OSGI depuis plus de 8 ans, et chaque fois que je plonge dans un projet non OSGI J'ai l'impression sur survitesse sans ceintures de sécurité sur. OSGI facilite la configuration du projet et le déploiement plus difficile, et les forces que vous réfléchissiez à la modularisation dès le départ, mais vous donne la facilité d'esprit de l'application des règles à l'exécution. Prenez chameau Maven comme un exemple. Lorsque vous créez un nouveau projet Maven et ajoutez chameau apache comme une dépendance, les applications semble avoir toutes ses dépendances, et vous ne remarquerez les ClassNotFoundExceptions lors de l'exécution, ce qui est mauvais. Lorsque vous exécutez dans un conteneur OSGI et de charger les modules de chameau apache, les modules avec des dépendances non satisfaites ne sont pas commencé, et vous savez dès le départ ce que le problème est.

Je l'utilise aussi le déploiement à chaud tout le temps, et mettre à jour les parties de ma demande à la volée sans avoir besoin d'un redémarrage.

Answer 4

J'utilisé OSGI dans un projet (je l'avoue - pas beaucoup). Il fournit de bonnes promesses, mais comme l'a dit @Arne, vous devez toujours penser à votre façon dont vous modulariser.

OSGI fait aider notre projet, car il a fait l'architecture plus stable. Briser la modularisation est plus « difficile », afin que les décisions que nous avons fait en ce qui concerne la façon de modularisation resté valable pour une durée plus longue.
Pour le dire autrement - sans OSGI, et sous la pression du temps pour fournir, parfois vous ou vos membres de l'équipe font des compromis, des raccourcis et autres hacks, et l'intention originale de l'architecture est perdue

.

OSGI n'a pas réduit la complexité en soi, mais il protégé de plus en plus au fil du temps inutilement. Je suppose que c'est une bonne chose:)

Je ne l'ai pas utilisé la fonction de déploiement rapide, donc je ne peux pas commenter à ce sujet.

Pour répondre à votre dernier point, il a répondu à mes attentes, mais il fallait une courbe d'apprentissage et une adaptation, et le gain est seulement pour le long terme.

(comme une note de côté, votre question me rappelle un peu l'adage selon lequel "Maven est le AWT des systèmes de construction")

Answer 5

OSGi ne paie pas. Le fait est OSGi est pas facile à utiliser et à la fin de la journée ou de l'année en fonction de combien de temps il vous faut pour faire fonctionner les choses, il n'ajoute pas de valeur:

• Votre demande ne sera pas plus globale modulaire, au contraire, elle finit d'être plus exposés et non isolé d'autres applications, car il est tout part au lieu de voûte de rien partager.
• Versioning est poussé plus loin sur la pile, vous luttez avec dépendances transitif Maven seulement pour faire à nouveau lors de l'exécution dans OSGI.
• La plupart des bibliothèques sont conçus pour fonctionner en tant que bibliothèques dans le classloader d'application non comme des faisceaux avec leur propre classloader.
• Peut-être approprié pour les architectures de plugins où les développeurs tiers doivent être sandbox ou il est peut-être juste EJB2.0 tout recommencer.

J'ai ajouté les diapositives suivantes et je vais suivre avec code d'exemple pour montrer comment travailler avec succès OSGi si elle est forcée sur vous. http://www.slideshare.net/ielian/tdd-on-osgi

Answer 6

Non, OSGI vous fera tôt gris.