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