J'ai lu sur Wikipedia et d'autres sites sur OSGi , mais je ne vois pas vraiment la situation dans son ensemble. Il indique qu'il s'agit d'une plate-forme basée sur les composants et que vous pouvez recharger les modules au moment de l'exécution. L '"exemple pratique" donné partout est également le plugin Eclipse.

Mes questions sont:

1. Quelle est la définition claire et simple de l'OSGi?

2. Quels problèmes communs résout-il?

Par «problèmes courants», j'entends les problèmes auxquels nous sommes confrontés tous les jours, comme «Que peut faire OSGi pour rendre nos tâches plus efficaces / amusantes / simples?

quels avantages le système de composants d'OSGi vous offre-t-il?
Eh bien, voici 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 éléments internes aux autres offres groupées et communiquent via des services bien définis. Cacher les internes signifie plus de liberté pour changer plus tard. Cela réduit non seulement le nombre de bogues, mais rend également les bundles plus simples à développer car les bundles de taille correcte implémentent une fonctionnalité via des 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 prêts à l'emploi.

Monde réel -Le cadre OSGi est dynamique. Il peut mettre à jour les bundles à la volée et les services peuvent aller et venir. Les développeurs habitués à Java plus traditionnel 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 peuvent aller et venir font que les services correspondent parfaitement à de nombreux scénarios du monde réel. Par exemple, un service peut modéliser un appareil dans le réseau. Si l'appareil 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 réels qui correspondent à ce modèle de service dynamique. Les applications peuvent donc réutiliser les puissantes primitives du registre de services (s'inscrire, obtenir, lister avec un langage de filtrage expressif et attendre que les services apparaissent et disparaissent) dans leur propre domaine. Cela permet non seulement d'économiser du code, mais également une visibilité globale, des outils de débogage et plus de fonctionnalités que ce qui aurait été implémenté 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 en prennent le plus, sinon la totalité, de la douleur.

Déploiement facile - La technologie OSGi n'est pas seulement une 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'un shell de commande, un pilote de protocole de gestion TR-69, un pilote de protocole OMA DM, une interface de cloud computing pour Amazon EC2 ou un système de gestion IBM Tivoli. L'API de gestion normalisé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 bundles peuvent être installés, démarrés, arrêtés, mis à jour et désinstallés sans arrêter l'ensemble du système. De nombreux développeurs Java ne croient pas que cela puisse ê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 et réduit considérablement les temps de déploiement.

Adaptatif - Le modèle de composant OSGi est conçu de A à Z pour permettre le mélange et l'appariement des composants. Cela nécessite que les dépendances des composants soient spécifiées et les composants doivent vivre dans un environnement où leurs dépendances facultatives ne sont pas toujours disponibles. Le registre de services OSGi est un registre dynamique où les bundles peuvent enregistrer, obtenir et écouter des services. Ce modèle de service dynamique permet aux offres groupées de découvrir 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 modifications.

Transparence - Les offres groupées et les services sont des citoyens de première classe dans l'environnement OSGi. L'API de gestion permet d'accéder à l'état interne d'un bundle ainsi qu'à la manière dont il est connecté à d'autres bundles. Par exemple, la plupart des frameworks fournissent un shell de commande qui montre cet état interne. Certaines parties des applications peuvent être arrêtées pour déboguer un certain problème, ou des ensembles de diagnostics peuvent être ajoutés. Au lieu de regarder des millions de lignes de sortie de journalisation et de longs temps de redémarrage, les applications OSGi peuvent souvent être déboguées avec un shell de commande en direct.

Versioning - La technologie OSGi résout l'enfer JAR. L'enfer JAR 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, tous les bundles sont soigneusement versionnés et seuls les bundles pouvant collaborer sont câblés ensemble dans le même espace de classe. Cela permet aux bundles 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 versionnage, cela peut parfois vous sauver la vie.

Simple - L'API OSGi est étonnamment simple. L'API de base est un seul package et moins de 30 classes / interfaces. Cette API principale est suffisante pour écrire des ensembles, 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é. Il y a très peu d'API qui fournissent autant de fonctionnalités pour si peu d'API.

Petit - Le cadre OSGi version 4 peut être implémenté dans un fichier JAR d'environ 300 Ko. Il s'agit d'une petite surcharge pour la quantité de fonctionnalités qui est ajoutée à une application en incluant OSGi. OSGi fonctionne donc sur une large gamme d'appareils: du très petit au petit, en passant par les mainframes. Il ne demande qu'une machine virtuelle Java minimale à exécuter et en ajoute très peu.

Rapide - L'une des principales responsabilités du framework OSGi est de charger les 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 faisceaux et sait pour chaque paquet exactement quel paquet fournit la classe. Ce manque de recherche est un facteur d'accélération important au démarrage.

Paresseux - Le logiciel paresseux est bon 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 bundles peuvent être démarrés avec impatience, mais ils peuvent également être configurés pour ne démarrer que lorsque d'autres bundles 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 fois pour permettre ce type de scénarios paresseux qui peuvent réduire les coûts d'exécution énormes.

Sécurisé - Java a un modèle de sécurité à grain fin très puissant en bas mais il s'est avéré très difficile à configurer dans la pratique. Le résultat est que la plupart des applications Java sécurisées s'exécutent avec un choix binaire: pas de sécurité ou des capacités très limitées. Le modèle de sécurité OSGi exploite le modèle de sécurité à grain fin, mais améliore la convivialité (ainsi que le durcissement du modèle d'origine) en demandant au développeur de l'ensemble de spécifier les détails de sécurité demandés sous une forme facilement auditée tandis que l'opérateur de l'environnement reste pleinement en charge. Dans l'ensemble, OSGi fournit probablement l'un des environnements d'application les plus sécurisés qui soit 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 machine virtuelle sans que l'OSGi ne les restreigne. La meilleure pratique dans OSGi est d'é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 comme un service OSGi. Cette stratégie facilite le port du code d'application vers un autre environnement.

Fonctionne partout - Eh bien, cela dépend. Le but initial de Java était de fonctionner 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. Une machine virtuelle dans un téléphone mobile ne prendra probablement pas en charge les mêmes bibliothèques qu'un ordinateur central 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 bundle 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é pris en charge 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 classe.
• Chaque plug-in dépend à la fois des fichiers JAR spécifiques qu'il contient et également d'autres plug-ins versionnés spécifiques.
• En raison du contrôle de version 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 dépend d'une version d'un plug-in et qu'un autre dépend d'une autre version, ils peuvent tous deux être chargés en même temps.

Avec cela, vous pouvez structurer votre application comme un 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 build afin qu'il soit reproductible et défini par un ensemble de versions spécifiques d'artefacts par lesquels il est créé, OSGi vous aide à le faire au moment de l'exécution.

Je ne me soucie pas trop de la connectivité à chaud des modules OSGi (au moins actuellement). C'est plus la modularité imposée. Ne pas avoir à tout moment des millions de classes "publiques" sur le chemin de classe protège bien des dépendances circulaires: vous devez vraiment penser à vos interfaces publiques - pas seulement en termes de construction du langage java "public", mais en termes de votre bibliothèque / module: Quels sont (exactement) les composants que vous souhaitez mettre à disposition des autres? Quelles sont (exactement) les interfaces (des autres modules) dont vous avez vraiment besoin pour implémenter vos fonctionnalités?

C'est bien, ce hotplug est livré avec, mais je préfère redémarrer mes applications habituelles que de tester toutes les combinaisons de hotplug ...

• Vous pouvez, de façon analogique, changer le moteur de votre voiture sans l'éteindre.
• Vous pouvez personnaliser des systèmes complexes pour les clients. Découvrez la puissance 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 basées sur des 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 égaux, mais dans différentes versions, sans compromettre l'application. OSGi résout le problème Jar Hell.
• Avec OSGi, vous développez la réflexion pour concevoir des systèmes avec CBD

Il y a beaucoup d'avantages (je l'ai rappelé juste maintenant), disponibles pour tous ceux qui utilisent Java.

édité pour plus de clarté. La page OSGi a donné une meilleure réponse simple que la mienne

Une réponse simple: une plate-forme de service OSGi fournit un environnement informatique normalisé et orienté composants pour coopérer avec les services en réseau. Cette architecture réduit considérablement la complexité globale de la création, de la maintenance et du déploiement d'applications. La plate-forme de service OSGi fournit les fonctions pour changer la composition de manière dynamique sur le périphérique d'une variété de réseaux, sans nécessiter de redémarrage.

Dans une structure d'application unique, par exemple l'IDE Eclipse, ce n'est pas un gros problème de redémarrer lorsque vous installez un nouveau plugin. En utilisant complètement l'implémentation OSGi, vous devriez pouvoir ajouter des plugins au moment de l'exécution, obtenir les nouvelles fonctionnalités, mais ne pas avoir à redémarrer du tout eclipse.

Encore une fois, ce n'est pas grave pour tous les jours, pour une petite application.

Mais, lorsque vous commencez à regarder les cadres d'applications distribués multi-ordinateurs, c'est là que cela commence à devenir intéressant. Lorsque vous devez disposer d'une disponibilité de 100% pour les systèmes critiques, la possibilité d'échanger des composants ou d'ajouter de nouvelles fonctionnalités au moment de l'exécution est utile. Certes, il y a des capacités pour le faire maintenant pour la plupart, mais OSGi essaie de tout regrouper dans un joli petit cadre avec des interfaces communes.

OSGi résout-il des problèmes courants, je n'en suis pas sûr. Je veux dire, c'est possible, mais les frais généraux peuvent ne pas en valoir la peine pour des problèmes plus simples. Mais c'est quelque chose à considérer lorsque vous commencez à traiter des applications plus grandes et en réseau.

Quelques choses qui me rendent fou sur OSGi:

1) Les implentations et leurs chargeurs de contexte ont beaucoup de bizarreries et peuvent être quelque peu asynchrones (nous utilisons felix à l'intérieur de la confluence). Comparé à un ressort pur (pas de DM) où [main] fonctionne à peu près tout par synchronisation.

2) Les classes ne sont pas égales après une charge chaude. Disons, par exemple, que vous avez une couche de cache tangosol en veille prolongée. Il est rempli de Fork.class, en dehors de la portée OSGi. Vous chargez un nouveau pot à chaud et Fork n'a pas changé. Class [Fork]! = Class [Fork]. Il apparaît également lors de la sérialisation, pour les mêmes causes sous-jacentes.

3) Regroupement.

Vous pouvez contourner ces problèmes, mais c'est une douleur majeure majeure et donne à votre architecture un aspect défectueux.

Et à ceux d'entre vous qui font de la publicité pour le branchement à chaud. Le client n ° 1 d'OSGi? Éclipse. Que fait Eclipse après le chargement du bundle?

Il redémarre.

OSGi fait votre jet de code NoClassDefFoundErroret ClassNotFoundExceptionsans raison apparente (probablement parce que vous avez oublié d'exporter un package dans le fichier de configuration OSGi); car il a ClassLoaders, il peut com.example.Foone pas être converti en classe com.example.Foocar il s'agit en fait de deux classes différentes chargées par deux chargeurs de classe différents. Il peut faire démarrer votre Eclipse dans une console OSGi après avoir installé un plugin Eclipse.

Pour moi, OSGi n'a fait qu'ajouter de la complexité (parce qu'il a ajouté un modèle mental de plus pour moi), a ajouté des ennuis en raison d'exceptions; Je n'ai jamais vraiment eu besoin de la dynamicité qu'elle "offre". C'était intrusif car il nécessitait la configuration du bundle OSGi pour tous les modules; ce n'était certainement pas simple (dans un projet plus vaste).

En raison de ma mauvaise expérience, j'ai tendance à rester loin de ce monstre, merci beaucoup. Je préférerais souffrir de l'enfer de la dépendance aux jar, car c'est beaucoup plus facile à comprendre que l'enfer du classloader OSGi.

Je ne suis pas encore "fan" d'OSGi ...

J'ai travaillé avec une application d'entreprise dans les sociétés Fortune 100. Récemment, le produit que nous utilisons a été mis à niveau vers une implémentation OSGi.

démarrage du déploiement local de cba ... [18/02/14 8: 47: 23: 727 EST] 00000347 CheckForOasis

enfin déployé et "les bundles suivants seront suspendus 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 fois que le code change ... La version précédente (non OSGi) se déploierait en moins de 5 minutes sur les anciennes machines de développement.

sur une machine avec 16 gig ram et 40 gig free disk et Intel i5-3437U 1.9 GHz CPU

Le «bénéfice» de cette mise à niveau a été vendu comme l'amélioration des déploiements (de production) - une activité que nous faisons environ 4 fois par an avec peut-être 2 à 4 petits déploiements de correctifs par an. Ajoutant 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 de base, la changer est à juste titre (les petits changements ont un impact potentiel important - doivent être communiqués et planifiés avec les consommateurs de toute l'entreprise), une activité monumentale - mauvaise architecture pour OSGi. Si votre application n'est pas une application d'entreprise - c'est-à-dire que chaque consommateur peut avoir son propre module personnalisé, susceptible de frapper son propre silo de données dans sa propre base de données en silo et de fonctionner sur un serveur qui héberge de nombreuses applications, alors peut-être regarder OSGi. Au moins,

Si une application basée sur Java nécessite l'ajout ou la suppression de modules (extension des fonctionnalités de base de l'application), sans arrêter la JVM, OSGI peut être utilisé. Habituellement, si le coût de l'arrêt de la JVM est plus élevé, il suffit de mettre à jour ou d'améliorer les fonctionnalités.

Exemples :

1. Eclipse : fournit une plate-forme pour les plugins pour installer, désinstaller, mettre à jour et inter-dépendre.
2. AEM : application WCM, où le changement de fonctionnalité sera fonction de l'entreprise, qui ne peut pas se permettre des temps d'arrêt pour la maintenance.

Remarque : Spring Framework a cessé de prendre en charge les bundles OSGI Spring, le considérant comme une complexité inutile pour les applications basées sur les transactions ou pour un certain point de ces lignes. Personnellement, je ne considère pas OSGI à moins que cela ne soit absolument nécessaire, dans quelque chose de grand comme la construction d'une plate-forme.

Je travaille avec OSGi depuis près de 8 ans et je dois dire que vous ne devriez considérer OSGi que si vous avez un besoin professionnel de mettre à jour, supprimer, installer ou remplacer un composant lors de l'exécution. Cela signifie également que vous devez avoir un état d'esprit modulaire et comprendre ce que signifie la modularité. Il y a certains arguments selon lesquels OSGi est léger - oui, c'est vrai, mais il existe également d'autres cadres qui sont légers et plus faciles à maintenir et à développer. Il en va de même 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 pot exécutable autonome sans aucun OSGi impliqué.

L'OSGi offre les avantages suivants:

■ Un environnement d'exécution portable et sécurisé basé sur Java

■ Un système de gestion des services, qui peut être utilisé pour enregistrer et partager des services entre les offres groupées et dissocier les fournisseurs de services des consommateurs de services

■ Un système de modules dynamiques, qui peut être utilisé pour installer et désinstaller dynamiquement des modules Java, que OSGi appelle des bundles

■ Une solution légère et évolutive

Il est également utilisé pour apporter une portabilité supplémentaire du middleware et des applications du côté mobile. Le côté mobile est disponible pour WinMo, Symbian, Android par exemple. Dès que l'intégration avec les fonctionnalités de l'appareil se produit, peut se fragmenter.

À tout le moins, OSGi vous fait PENSER à la modularité, à la réutilisation du code, au versioning et en général à la plomberie d'un projet.

D'autres ont déjà décrit les avantages en détail, j'explique par la présente les cas d'utilisation pratiques que j'ai vus ou utilisé OSGi.

1. Dans l'une de nos applications, nous avons un flux basé sur les événements et le flux est défini dans des plugins basés sur la plate-forme OSGi donc demain si un client veut un flux différent / supplémentaire, il lui suffit de déployer un autre plugin, de le configurer à partir de notre console et il a terminé .
2. Il est utilisé pour déployer différents connecteurs Store, par exemple, supposons que nous ayons déjà un connecteur Oracle DB et que demain mongodb doive être connecté, puis écrivez un nouveau connecteur et déployez-le et configurez les détails via la console et à nouveau vous avez terminé. le déploiement des connecteurs est géré par le framework de plugins OSGi.

Il y a déjà une déclaration assez convaincante sur son site officiel, je peux citer

La principale raison du succès de la technologie OSGi est qu'elle fournit un système de composants très mature qui fonctionne réellement dans un nombre surprenant d'environnements. Le système de composants OSGi est en fait utilisé pour créer des applications très complexes comme les IDE (Eclipse), les serveurs d'applications (GlassFish, IBM Websphere, Oracle / BEA Weblogic, Jonas, JBoss), les cadres d'application (Spring, Guice), l'automatisation industrielle, les passerelles résidentielles, téléphones, et bien plus encore.

Quant aux 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 d'aujourd'hui ainsi que pour les petites applications intégrées. La construction de systèmes à partir de modules internes et standard réduit considérablement la complexité et donc les dépenses de développement et de maintenance. Le modèle de programmation OSGi réalise la promesse de systèmes basés sur des composants.

Veuillez vérifier les détails dans Avantages de l'utilisation d'OSGi .