Que résout OSGi?
J'ai lu sur Wikipedia et d'autres sites sur OSGi , mais je ne vois pas vraiment la grande image. Il indique qu'il s'agit d'une plate-forme à base de composants et que vous pouvez recharger des modules lors de l'exécution. L'exemple pratique donné partout est également le plug-in Eclipse.
Mes questions sont:
Quelle est la définition claire et simple de OSGi?
Quels problèmes communs cela résout-il?
Par "problèmes courants", je veux dire les problèmes auxquels nous sommes confrontés tous les jours, tels que "Que peut faire OSGi pour rendre notre travail plus efficace/plus amusant/plus simple?"
Quels sont les avantages du système de composants OSGi?
Eh bien, voici toute une liste:
Complexité réduite - Développer avec la technologie OSGi signifie développer des bundles: les composants OSGi. Les bundles sont des modules. Ils cachent leurs composants internes aux autres offres groupées et communiquent via des services bien définis. Cacher les éléments internes signifie plus de liberté pour changer plus tard. Cela réduit non seulement le nombre de bogues, mais facilite également le développement des ensembles, car des ensembles correctement dimensionnés implémentent une fonctionnalité par le biais d'interfaces bien définies. Il y a un blog intéressant qui décrit ce que la technologie OSGi a fait pour son processus de développement.
Réutilisation - Le modèle de composant OSGi facilite l'utilisation de nombreux composants tiers dans une application. Un nombre croissant de projets open source fournissent leurs fichiers JAR prêts à l'emploi pour OSGi. Cependant, les bibliothèques commerciales deviennent également disponibles sous forme de bundles tout faits.
Monde réel - Le cadre OSGi est dynamique. Il peut mettre à jour des ensembles à la volée et les services peuvent aller et venir. Les développeurs habitués à plus traditionnels Java voient cela comme une fonctionnalité très problématique et ne voient pas l’avantage. Cependant, il s'avère que le monde réel est très dynamique et que les services dynamiques qui vont et viennent rendent ces services parfaitement compatibles avec de nombreux scénarios du monde réel. Par exemple, un service peut modéliser un périphérique sur le réseau. Si le périphérique est détecté, le service est enregistré. Si l'appareil disparaît, le service n'est pas enregistré. Il existe un nombre surprenant de scénarios du monde réel correspondant à ce modèle de service dynamique. Les applications peuvent donc réutiliser les puissantes primitives du registre de services (enregistrer, obtenir, répertorier avec un langage de filtrage expressif et attendre que les services apparaissent et disparaissent) dans leur propre domaine. Cela enregistre non seulement le code d'écriture, mais offre également une visibilité globale, des outils de débogage et davantage de fonctionnalités que celles qui auraient été implémentées pour une solution dédiée. Écrire du code dans un environnement aussi dynamique ressemble à un cauchemar, mais heureusement, il existe des classes de support et des frameworks qui simplifient presque tout le travail.
Déploiement facile - La technologie OSGi n'est pas une simple norme pour les composants. Il spécifie également comment les composants sont installés et gérés. Cette API a été utilisée par de nombreux bundles pour fournir un agent de gestion. Cet agent de gestion peut être aussi simple qu'une commande Shell, un pilote de protocole de gestion TR-69, un pilote de protocole OMA DM, une interface de cloud computing pour EC2 d'Amazon ou un système de gestion IBM Tivoli. L'API de gestion standardisée facilite l'intégration de la technologie OSGi dans les systèmes existants et futurs.
Mises à jour dynamiques - Le modèle de composant OSGi est un modèle dynamique. Les ensembles peuvent être installés, démarrés, arrêtés, mis à jour et désinstallés sans mettre tout le système hors service. De nombreux développeurs Java ne croient pas que cela peut être fait de manière fiable et ne l'utilisent donc pas initialement en production. Cependant, après avoir utilisé cela en développement pendant un certain temps, la plupart commencent à se rendre compte que cela fonctionne réellement et réduit considérablement les temps de déploiement.
Adaptatif - Le modèle de composant OSGi est conçu à partir de la base pour permettre le mélange et la mise en correspondance des composants. Cela nécessite que les dépendances des composants soient spécifiées et que les composants résident dans un environnement où leurs dépendances facultatives ne sont pas toujours disponibles. Le registre de services OSGi est un registre dynamique dans lequel les ensembles peuvent enregistrer, obtenir et écouter des services. Ce modèle de service dynamique permet aux offres groupées de déterminer les fonctionnalités disponibles sur le système et d'adapter les fonctionnalités qu'elles peuvent fournir. Cela rend le code plus flexible et résilient aux changements.
Transparence - Les offres groupées et les services sont des citoyens de premier ordre dans l'environnement OSGi. L'API de gestion fournit un accès à l'état interne d'un ensemble ainsi qu'à la façon dont il est connecté à d'autres ensembles. Par exemple, la plupart des infrastructures fournissent un shell de commande indiquant cet état interne. Certaines parties des applications peuvent être arrêtées pour résoudre un problème donné ou des ensembles de diagnostics peuvent être importés. Au lieu de regarder des millions de lignes de sortie de journalisation et des temps de redémarrage longs, les applications OSGi peuvent souvent être déboguées avec une commande en direct Shell.
Gestion des versions - La technologie OSGi résout l'enfer de JAR. JAR Hell est le problème que la bibliothèque A fonctionne avec la bibliothèque B; version = 2, mais la bibliothèque C ne peut fonctionner qu'avec B; version = 3. En Java standard, vous n'avez pas de chance. Dans l'environnement OSGi, toutes les offres groupées sont soigneusement versionnées et seules les offres pouvant collaborer sont câblées ensemble dans le même espace de classe. Cela permet aux ensembles A et C de fonctionner avec leur propre bibliothèque. Bien qu'il ne soit pas conseillé de concevoir des systèmes avec ce problème de version, cela peut parfois vous sauver la vie.
Simple - L'API OSGi est étonnamment simple. L'API principale est constituée d'un seul package et de moins de 30 classes/interfaces. Cette API principale est suffisante pour écrire des lots, les installer, les démarrer, les arrêter, les mettre à jour et les désinstaller, et inclut toutes les classes d'écoute et de sécurité. Très peu d'API fournissent autant de fonctionnalités pour si peu d'API.
Petit - Le framework OSGi Release 4 peut être implémenté dans un fichier JAR d'environ 300 Ko. Cela représente un léger surcoût pour la quantité de fonctionnalités ajoutées à une application en incluant OSGi. OSGi fonctionne donc sur une large gamme de périphériques: du plus petit au plus petit, en passant par le mainframe. Il ne demande qu'un minimum de Java VM à exécuter et ajoute très peu au-dessus.
Rapide - L'une des principales responsabilités du framework OSGi est le chargement des classes à partir de bundles. En Java traditionnel, les fichiers JAR sont complètement visibles et placés sur une liste linéaire. La recherche dans une classe nécessite une recherche dans cette liste (souvent très longue, 150 n'est pas rare). En revanche, OSGi pré-câble les ensembles et sait exactement pour chaque ensemble quel ensemble fournit la classe. Ce manque de recherche est un facteur d'accélération significatif au démarrage.
Fainéant - La fainéantise dans les logiciels est bonne et la technologie OSGi a de nombreux mécanismes en place pour faire les choses uniquement quand elles sont vraiment nécessaires. Par exemple, les ensembles peuvent être lancés rapidement, mais ils peuvent également être configurés pour ne démarrer que lorsque d'autres ensembles les utilisent. Les services peuvent être enregistrés, mais créés uniquement lorsqu'ils sont utilisés. Les spécifications ont été optimisées à plusieurs reprises pour permettre ce type de scénarios paresseux qui permettent de réduire les coûts d'exécution.
Secure - Java possède un modèle de sécurité très puissant à la fine pointe de la technologie, mais il s’est avéré très difficile à configurer en pratique. Le résultat est que les applications les plus sécurisées Java s'exécutent avec un choix binaire: aucune sécurité ou des capacités très limitées. Le modèle de sécurité OSGi exploite le modèle de sécurité à granularité fine, mais améliore la convivialité (ainsi que le renforcement du modèle d'origine) en permettant au développeur du bundle de spécifier les détails de sécurité demandés sous une forme facilement vérifiable, tandis que l'opérateur de l'environnement reste entièrement responsable. Dans l’ensemble, OSGi fournit probablement l’un des environnements d’application les plus sécurisés encore utilisable, à l’exception des plates-formes informatiques protégées par du matériel.
Non intrusif - Les applications (bundles) dans un environnement OSGi sont laissées à elles-mêmes. Ils peuvent utiliser pratiquement toutes les installations de la VM sans que l'OSGi ne les limite. La meilleure pratique d'OSGi consiste à écrire Plain Old Java Objects et, pour cette raison, aucune interface spéciale n'est requise pour les services OSGi. Même un objet Java String peut agir en tant que service OSGi. Cette stratégie facilite le portage du code d'application vers un autre environnement.
Fonctionne partout - Eh bien, cela dépend. Le but initial de Java était de s'exécuter n'importe où. De toute évidence, il n'est pas possible d'exécuter tout le code partout car les capacités des machines virtuelles Java diffèrent. Un VM dans un téléphone mobile ne prendra probablement pas en charge les mêmes bibliothèques qu'un grand système IBM exécutant une application bancaire. Il y a deux problèmes à régler. Premièrement, les API OSGi ne doivent pas utiliser de classes qui ne sont pas disponibles dans tous les environnements. Deuxièmement, un ensemble ne doit pas démarrer s'il contient du code qui n'est pas disponible dans l'environnement d'exécution. Ces deux problèmes ont été traités dans les spécifications OSGi.
Source: www.osgi.org/Technology/WhyOSGi
J'ai trouvé les avantages suivants d'OSGi:
- Chaque plugin est un artefact versionné qui a son propre chargeur de classes.
- Chaque plugin dépend à la fois des fichiers JAR spécifiques qu’il contient et d’autres plug-ins versionnés spécifiques.
- En raison des versions et des chargeurs de classe isolés, différentes versions du même artefact peuvent être chargées en même temps. Si un composant de votre application repose sur une version d'un plug-in et qu'une autre dépend d'une autre version, ils peuvent être chargés en même temps.
Avec cela, vous pouvez structurer votre application en tant qu'ensemble d'artefacts de plug-in versionnés qui sont chargés à la demande. Chaque plugin est un composant autonome. Tout comme Maven vous aide à structurer votre construction de manière à ce qu'elle puisse être répétée et définie par un ensemble de versions spécifiques d'artefacts par laquelle elle est créée, OSGi vous aide à le faire au moment de l'exécution.
Je me moque bien de la connectabilité à chaud des modules OSGi (du moins pour le moment). C'est plus la modularité forcée. Ne pas avoir des millions de classes "publiques" disponibles sur le classpath protège à tout moment des dépendances circulaires: vous devez vraiment penser à vos interfaces publiques - pas seulement en termes de la construction de langage Java " public ", mais en termes de bibliothèque/module: quels sont (exactement) les composants que vous souhaitez rendre disponibles aux autres? Quelles (exactement) sont les interfaces (des autres modules) dont vous avez réellement besoin pour implémenter vos fonctionnalités?
C'est sympa, hotplug vient avec, mais je préfère redémarrer mes applications habituelles que de tester toutes les combinaisons de hotplugability ...
- Vous pouvez, par analogie, changer le moteur de votre voiture sans l'éteindre.
- Vous pouvez personnaliser des systèmes complexes pour les clients. Voir le pouvoir d'Eclipse.
- Vous pouvez réutiliser des composants entiers. Mieux que de simples objets.
- Vous utilisez une plate-forme stable pour développer des applications à base de composants. Les avantages de ceci sont énormes.
- Vous pouvez créer des composants avec le concept de boîte noire. Les autres composants n'ont pas besoin de connaître les interfaces cachées, ils ne voient que les interfaces publiées.
- Vous pouvez utiliser dans le même système plusieurs composants identiques, mais dans des versions différentes, sans compromettre l'application. OSGi résout le problème de Jar Hell.
- Avec OSGi, vous développez une réflexion sur les systèmes architecturaux avec CBD
Il y a beaucoup d'avantages (je les ai seulement rappelés maintenant), disponibles pour tous ceux qui utilisent Java.
édité pour plus de clarté. La page OSGi a donné une réponse plus simple que la mienne
Une réponse simple: une plate-forme de services OSGi fournit un environnement informatique normalisé et orienté composant pour les services en réseau coopérants. Cette architecture réduit considérablement la complexité globale de la création, de la maintenance et du déploiement d'applications. OSGi Service Platform fournit les fonctions permettant de modifier la composition de manière dynamique sur le périphérique de nombreux réseaux, sans nécessiter de redémarrage.
Dans une structure d'application unique, disons l'EDI Eclipse, ce n'est pas un gros problème de redémarrer lorsque vous installez un nouveau plugin. En utilisant complètement la mise en œuvre OSGi, vous devriez pouvoir ajouter des plugins au moment de l'exécution, bénéficier de la nouvelle fonctionnalité, sans avoir à redémarrer Eclipse.
Encore une fois, ce n’est pas un problème pour tous les jours, l’utilisation de petites applications.
Cependant, lorsque vous commencez à vous pencher sur les infrastructures d'application distribuées sur plusieurs ordinateurs, c'est là que ça commence à devenir intéressant. Lorsque vous devez disposer de 100% de disponibilité pour les systèmes critiques, il est utile de pouvoir échanger des composants par transfert à chaud ou d'ajouter de nouvelles fonctionnalités au moment de l'exécution. Certes, la plupart du temps, il existe des capacités pour le faire, mais OSGi tente de tout regrouper dans un petit framework Nice avec des interfaces communes.
OSGi résout-il des problèmes courants, je ne suis pas sûr de cela. Je veux dire, c’est possible, mais les frais généraux ne valent peut-être pas la peine pour des problèmes plus simples. Mais vous devez en tenir compte lorsque vous commencez à traiter de plus grandes applications en réseau.
Quelques choses qui me rendent dingue sur OSGi:
1) Les implémentations et leurs chargeurs de contexte ont beaucoup de bizarreries et peuvent être quelque peu asynchrones (nous utilisons felix dans confluence). Comparé à un ressort pur (sans DM) où [principal] fonctionne quasiment à travers tout le processus de synchronisation.
2) Les classes ne sont pas égales après une charge à chaud. Disons, par exemple, que vous avez une couche de cache tangosol en veille prolongée. Il est rempli avec Fork.class, en dehors du périmètre OSGi. Vous chargez un nouveau pot à chaud et Fork n’a pas changé. Classe [Fourchette]! = Classe [Fourche]. Il apparaît également lors de la sérialisation, pour les mêmes causes sous-jacentes.
3) le regroupement.
Vous pouvez contourner ces problèmes, mais il s’agit d’une douleur majeure et donne à votre architecture un aspect imparfait.
Et à ceux d’entre vous qui font de la publicité pour le hotplugging. Le client n ° 1 d’OSGi? Éclipse. Que fait Eclipse après avoir chargé le paquet?
Cela redémarre.
Je ne suis pas encore "fan" d'OSGi ...
Je travaille avec une application d'entreprise dans les entreprises Fortune 100. Récemment, le produit que nous utilisons a été mis à niveau vers une implémentation OSGi.
démarrage du déploiement de cba local ... [2/18/14 8: 47: 23: 727 EST] 00000347 CheckForOasis
a finalement été déployé et "les ensembles suivants seront mis au repos, puis redémarrés" [18/02/14 9: 38: 33: 108 EST] 00000143 AriesApplicat I CWSAI0054I: dans le cadre d'une opération de mise à jour pour l'application
51 minutes ... à chaque changement de code temporel ... La version précédente (non OSGi) se déployait en moins de 5 minutes sur des machines de développement plus anciennes.
sur une machine avec 16 Go de RAM et 40 Go de disque disponible et un processeur Intel i5-3437U à 1,9 GHz
Le "bénéfice" de cette mise à niveau a été vendu comme une amélioration des déploiements (de production) - une activité que nous faisons environ 4 fois par an avec peut-être 2 à 4 déploiements de petites corrections par an. Ajout de 45 minutes par jour à 15 personnes (QA et développeurs) Je ne peux pas imaginer être jamais justifié. Dans les applications de grande entreprise, si votre application est une application principale, sa modification l’est donc à juste titre (les modifications mineures peuvent avoir un impact considérable - doivent être communiquées et planifiées avec les consommateurs de l’ensemble de l’entreprise), activité monumentale - mauvaise architecture pour OSGi. Si votre application n’est pas une application d’entreprise, c’est-à-dire que chaque consommateur peut disposer de son propre module personnalisé, qui va probablement frapper son propre silo de données dans sa propre base de données silo et s’exécutant sur un serveur hébergeant de nombreuses applications, puis peut-être regarder OSGi. Au moins, c'est mon expérience jusqu'à présent.
Si une application Java nécessite l'ajout ou la suppression de modules (étendre les fonctionnalités de base de l'application), sans arrêter la machine virtuelle, OSGI peut être utilisé. Habituellement, si le coût de la fermeture de JVM est plus élevé, juste pour mettre à jour ou améliorer les fonctionnalités.
Exemples:
- Eclipse: Fournit une plate-forme permettant aux plug-ins d'installer, de désinstaller, de mettre à jour et de s'interdépendre.
- AEM : application WCM, dans laquelle les modifications de fonctionnalité seront dictées par les activités commerciales, ce qui ne peut permettre des temps d’entretien insuffisants.
Note: Spring Framework a cessé de prendre en charge les ensembles de ressorts OSGI, considérant qu'il s'agit d'une complexité inutile pour les applications transactionnelles ou pour un point quelconque de ces lignes. Personnellement, je ne considère pas l'OSGI à moins que ce ne soit absolument nécessaire, par exemple dans la construction d'une plate-forme.
OSGi force votre code à lancer NoClassDefFoundError et ClassNotFoundException sans raison apparente (probablement parce que vous avez oublié d'exporter un package dans le fichier de configuration OSGi); comme il a ClassLoaders, il peut rendre votre classe com.example.Foo échoue à être jeté sur com.example.Foo puisqu'il s'agit en fait de deux classes différentes chargées par deux chargeurs de classes différents. Cela peut faire démarrer votre Eclipse dans une console OSGi après l’installation d’un plugin Eclipse.
Pour moi, OSGi n'a fait qu'ajouter à la complexité (car il m'a ajouté un modèle mental de plus à ajouter), a ajouté des ennuis à cause d'exceptions; Je n'ai jamais vraiment eu besoin de la dynamicité qu'il "offre". C'était intrusif car il nécessitait la configuration de l'ensemble OSGi pour tous les modules; ce n'était vraiment pas simple (dans un projet plus vaste).
En raison de ma mauvaise expérience, j'ai tendance à rester à l'écart de ce monstre, merci beaucoup. Je préférerais souffrir de la dépendance à jar, car c'est bien plus compréhensible que le chargeur de classe introduit par OSGi.
L'OSGi offre les avantages suivants:
■ Un environnement d’exécution portable et sécurisé basé sur Java
■ Un système de gestion de services, qui peut être utilisé pour enregistrer et partager des services entre des ensembles et découpler des fournisseurs de services des consommateurs de services
■ Un système de module dynamique, qui peut être utilisé pour installer et désinstaller de manière dynamique Java, lesquels OSGi appelle des ensembles
■ Une solution légère et évolutive
D'autres ont déjà décrit les avantages en détail. J'explique par la présente les cas d'utilisation pratique que j'ai vus ou que j'ai utilisé OSGi.
- Dans l'une de nos applications, nous avons un flux événementiel et le flux est défini dans des plugins basés sur la plate-forme OSGi. Ainsi, si un client souhaite un flux différent/supplémentaire, il lui suffit de déployer un plugin supplémentaire, de le configurer à partir de notre console et il a terminé. .
- Par exemple, supposons que nous possédions déjà un connecteur de base de données Oracle et que mongodb doive être connecté, puis écrire un nouveau connecteur et le déployer, puis configurer les détails via la console, puis vous avez terminé. le déploiement de connnectors est géré par le framework de plugin OSGi.
Au minimum, OSGi vous fait penser à la modularité, à la réutilisation du code, au versioning et en général à la plomberie d'un projet.
Il y a déjà une déclaration assez convaincante sur son site officiel, je peux citer comme
Si la technologie OSGi connaît un tel succès, c’est qu’elle fournit un système de composants très très mature qui fonctionne dans un nombre surprenant d’environnements. Le système de composants OSGi est en fait utilisé pour créer des applications très complexes telles que des IDE (Eclipse), des serveurs d’applications (GlassFish, IBM Websphere, Oracle/BEA Weblogic, Jonas, JBoss), des frameworks d’application (Spring, Guice), l’automatisation industrielle, des passerelles résidentielles, téléphones, et bien plus encore.
En ce qui concerne les avantages pour le développeur?
DÉVELOPPEURS: OSGi réduit la complexité en fournissant une architecture modulaire pour les systèmes distribués à grande échelle et les petites applications intégrées. La construction de systèmes à partir de modules internes et standard réduit considérablement la complexité et, par conséquent, les frais de développement et de maintenance. Le modèle de programmation OSGi réalise les promesses des systèmes à base de composants.
Veuillez vérifier les détails dans Avantages de l’utilisation d’OSGi .
Je travaille avec OSGi depuis près de 8 ans et je dois dire que vous ne devez envisager OSGi que si vous avez un besoin commercial de mettre à jour, de supprimer, d’installer ou de remplacer un composant à l’exécution. Cela signifie également que vous devez avoir une mentalité modulaire et comprendre ce que signifie la modularité. Certains arguments tendent à dire qu'OSGi est léger - oui, c'est vrai, mais il existe également d'autres frameworks légers, faciles à maintenir et à développer. Même chose pour sécuriser Java blah blah.
OSGi nécessite une architecture solide pour être utilisé correctement et il est assez facile de créer un système OSGi qui pourrait tout aussi bien être un fichier jar autonome exécutable sans impliquer aucun OSGi.