Ce n'OSGi résoudre?

quels sont les avantages d'OSGi du composant au système de vous fournir?
Eh bien, Ici, est tout à fait une liste:

Réduction de la Complexité - Développement avec la technologie OSGi-dire de développement de faisceaux: les composants OSGi. Les Bundles sont des modules. Ils cachent leurs internes des autres faisceaux et de communiquer à travers des prestations définies. Cacher les éléments internes de la plus grande liberté de changer plus tard. Cela réduit non seulement le nombre de bugs, il fait aussi des faisceaux plus simple à développer correctement de la taille des faisceaux de mettre en œuvre un morceau de fonctionnalités 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 leur processus de développement.

De réutilisation OSGi modèle de composant, il est très facile à utiliser de nombreux composants tiers dans une application. Un nombre croissant de projets open source offrent leurs Pots de prêt à l'emploi pour OSGi. Toutefois, les bibliothèques sont aussi de plus en plus comme des ready-made de faisceaux.

Monde réel - Le framework OSGi est dynamique. Il peut mettre à jour des faisceaux sur la volée et services peuvent aller et venir. Les développeurs ont utilisé plus traditionnelles en Java voyons cela comme une très problématique de la fonctionnalité et de ne pas voir l'avantage. Cependant, il s'avère que le monde réel est très dynamique et ayant des services dynamiques qui peuvent aller et venir rend les services d'un match parfait pour de nombreux scénarios réels. Par exemple, un service peut modéliser un appareil dans le réseau. Si le périphérique est détecté, le service est enregistré. Si l'appareil se met à l'écart, le service est annulé. Il ya un nombre surprenant de scénarios réels qui correspondent à cette dynamique, le modèle de service. Applications peut donc réutiliser le puissant primitives du service de registre (registre, d'obtenir, de la liste avec une force expressive du langage de filtrage, et d'attente pour les services d'apparaître et de disparaître) dans leur propre domaine. Cela permet non seulement d'économiser de l'écriture de code, il fournit également une visibilité mondiale, les outils de débogage, et plus de fonctionnalités qu'aurait mis en place pour une solution dédiée. L'écriture de code dans un environnement aussi dynamique des sons comme un cauchemar, mais heureusement, il y a des cours de soutien et des cadres qui prennent pour la plupart, si pas tous, de la douleur hors de lui.

Facilité de Déploiement - La technologie OSGi n'est pas seulement une norme pour les composants. Il précise également la manière dont les composants sont installés et gérés. Cette API a été utilisé par de nombreux faisceaux de fournir un agent de gestion. Cet agent de gestion peut être aussi simple comme un shell de commande, un TR-69 protocole de gestion de pilote, OMA DM pilote de protocole, cloud computing interface d'Amazon EC2, ou un IBM Tivoli système de gestion. La normalisation de la gestion de l'API, il est très facile à intégrer la technologie OSGi dans des systèmes existants et futurs.

Les Mises à jour dynamiques - OSGi modèle de composant est un modèle dynamique. Les faisceaux peuvent être installés, marche, arrêt, mise à jour, et désinstallé sans ramener le système dans son ensemble. Beaucoup de développeurs Java ne crois pas que cela peut être fait de manière fiable et donc d'abord de ne pas l'utiliser dans la production. Cependant, après l'utilisation de ce développement pendant un certain temps, la plupart commencent à se rendre compte qu'elle fonctionne réellement et significativement réduit le temps de déploiement.

Adaptative - OSGi modèle de composant est conçu à partir du sol pour permettre le mélange et l'appariement des composants. Cela nécessite que les dépendances des composants doivent être spécifiés et il nécessite des composants de vivre dans un environnement où leurs dépendances optionnelles ne sont pas toujours disponibles. OSGi service de registre est une dynamique de registre où les faisceaux peuvent s'inscrire, obtenir et écouter de services. Cette dynamique modèle de service permet de faisceaux pour savoir quelles fonctionnalités sont disponibles sur le système et d'adapter les fonctionnalités qu'ils peuvent offrir. Cela rend le code plus flexible et résilient aux changements.

Transparence - Faisceaux et des services de première classe des citoyens dans l'environnement OSGi. La gestion de l'API permet d'accéder à l'état interne d'un bundle ainsi que la façon dont il est connecté à d'autres bundles. Par exemple, la plupart des cadres de fournir une interface de commande qui montre cet état interne. Les applications peuvent être arrêtés pour résoudre un certain problème de santé, de diagnostic ou de faisceaux peut être introduit. Au lieu de regarder des millions de lignes de sortie de journalisation et à long redémarrage fois, OSGi applications peuvent souvent être corrigés avec un shell de commande.

Les versions de OSGi technologie résout POT de l'enfer. POT de l'enfer est le problème que la bibliothèque fonctionne avec la bibliothèque B;version=2, mais la bibliothèque C ne peut travailler qu'avec B;version=3. En Java standard, vous êtes hors de la chance. Dans OSGi environnement, tous les faisceaux sont soigneusement versionnées et seuls les ensembles qui peuvent collaborer sont câblés ensemble dans la même classe de l'espace. Ceci permet à la fois bundle A et C de la fonction avec leur propre bibliothèque. Bien qu'il n'est pas conseillé pour la conception de systèmes avec cette versioning problème, il peut être un épargnant de vie dans certains cas.

Simple - OSGi API est étonnamment simple. L'API de base n'est qu'un paquet de moins de 30 classes/interfaces. Cette API de base est suffisant pour écrire des faisceaux, d'installation, de démarrage, d'arrêt, de mise à jour, et de les désinstaller et comprend tous les écouteurs et classes de sécurité. Il y a très peu d'Api qui fournissent autant de fonctionnalités pour si peu de l'API.

Petit - OSGi Version 4-Cadre peut être mis en œuvre dans environ 300 KO fichier JAR. C'est une petite surcharge de la quantité de fonctionnalités qui est ajouté à une demande en OSGi. OSGi donc fonctionne sur une large gamme d'appareils: de très petites, petites, mainframes. Il demande seulement pour un minimum de la machine virtuelle Java pour exécuter et ajoute que très peu sur le dessus de cela.

Rapide - l'Une des principales responsabilités de l'OSGi cadre du chargement des classes de faisceaux. En Java traditionnelle, les Pots sont complètement visibles et placés sur une liste linéaire. La recherche d'une classe nécessite la recherche par le biais de ce (souvent très long, 150 n'est pas rare) de la liste. En revanche, OSGi pré-faisceaux de fils et sait pour chaque module exactement qui bundle fournit la classe. Ce manque de recherche est l'une vitesse importante facteur au démarrage.

Paresseux - Paresseux dans le logiciel est bon et la technologie OSGi a beaucoup de mécanismes en place pour faire des choses que lorsqu'ils sont vraiment nécessaires. Par exemple, des paquets peut être démarré avec impatience, mais ils peuvent également être configurés uniquement dans le cas où d'autres faisceaux sont de les utiliser. Les Services peuvent être enregistrés, mais seulement créé quand ils sont utilisés. Les spécifications ont été optimisés à plusieurs reprises pour permettre ce genre de paresseux scénarios qui peuvent enregistrer d'énormes coûts d'exécution.

Sécurisé - Java a un très puissant fine modèle de sécurité dans le fond mais il s'est avéré très difficile à configurer dans la pratique. Le résultat est que la plupart de sécuriser les applications Java sont en cours d'exécution avec un choix binaire: pas de sécurité ou très limitée des capacités. OSGi modèle de sécurité tire parti de la fine modèle de sécurité, mais améliore la facilité d'utilisation (ainsi que le durcissement le modèle d'origine) en ayant le bundle développeur de spécifier la sécurité demandé des détails facilement vérifiés forme, alors que l'opérateur de l'environnement demeure entièrement responsable. Dans l'ensemble, OSGi est susceptible de fournir l'un des plus sûrs d'environnements d'applications qui est encore utilisable à court de matériel protégé des plates-formes informatiques.

Non Intrusive Applications (bundles) dans un environnement OSGi sont laissés à leur propre. Ils peuvent utiliser pratiquement n'importe quel établissement de la VM sans OSGi en les limitant. Les meilleures pratiques dans OSGi est d'écrire Plain Old Java Objects et pour cette raison, il n'y a pas d'interface requis pour les services OSGi, même un Java objet de type String peut agir comme un service OSGi. Cette stratégie permet à l'application d'un code plus port à un autre environnement.

Coule de Partout - eh Bien, ça dépend. L'objectif initial de Java a été de courir n'importe où. Évidemment, il n'est pas possible d'exécuter tout code partout, parce que les capacités des machines virtuelles Java diffèrent. Une machine virtuelle dans un téléphone mobile ne sera probablement pas en charge les mêmes bibliothèques comme un mainframe IBM exécutant une application bancaire. Il y a deux problème pour prendre soin de. Tout d'abord, le OSGi Api ne doit pas utiliser des classes qui ne sont pas disponibles sur tous les environnements. Deuxièmement, un bundle ne devrait pas démarrer si il contient du code qui n'est pas disponible dans l'environnement d'exécution. Ces deux questions ont été prises en charge dans les spécifications OSGi.

Source : http://www.osgi.org/Technology/WhyOSGi

Je ne m'inquiète pas trop sur le hotplugability de modules OSGi (au moins actuellement). C'est plus forcée de la modularité. Ne pas avoir des millions de "public" classes disponible dans le classpath, à tout moment, protège bien de dépendances circulaires: Vous devez vraiment penser à vos interfaces publiques - et pas seulement en termes du langage java construire "public", mais en termes de votre bibliothèque/module: Quel (exactement) sont les composants que vous souhaitez rendre disponible pour les autres? Quel (exactement) sont les interfaces (d'autres modules) vous avez vraiment besoin de mettre en œuvre votre fonctionnalité?

C'est agréable, hotplug vient avec elle, mais je préfère le redémarrage de mes applications habituelles que de tester toutes les combinaisons de hotplugability...

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

Une réponse simple: Un Service OSGi Plate-forme fournit une méthode standardisée, composant orienté environnement informatique pour la coopération des services en réseau. Cette architecture réduit de manière significative la complexité globale de la construction, le maintien et le déploiement des applications.
OSGi Plate-forme de Service fournit les fonctions pour modifier la composition de façon dynamique sur l'appareil d'une variété de réseaux, sans nécessiter un redémarrage.

Dans une seule structure de la demande, dire que l'IDE Eclipse, c'est pas un gros problème pour redémarrer lorsque vous installez un nouveau plugin. À l'aide de l'OSGi mise en œuvre complètement, vous devriez être en mesure d'ajouter des plugins lors de l'exécution, obtenir les nouvelles fonctionnalités, mais ne pas avoir à redémarrer eclipse à tous.

Encore, pas un gros problème pour tous les jours, petite utilisation de l'application.

Mais, lorsque vous commencez à regarder multi-ordinateur, application distribuée cadres, c'est là que ça commence à devenir intéressant. Quand vous devez avoir 100% de disponibilité pour les systèmes critiques, la capacité de hotswap de composants ou d'ajouter de nouvelles fonctionnalités au moment de l'exécution est utile. Accordé, il y a les capacités pour le faire maintenant, pour la plupart, mais OSGi est d'essayer de regrouper le tout dans un joli petit cadre avec des interfaces communes.

Ne OSGi résoudre des problèmes communs, je ne suis pas sûr à ce sujet. Je veux dire, il peut, mais la surcharge ne peut être vaut la peine pour de simples problèmes. Mais c'est quelque chose à considérer lorsque vous commencez à traiter avec les plus grands, en réseau, des applications.

Je suis encore à être "fan" d'OSGi...

J'ai travaillé avec une application d'entreprise dans les entreprises du Fortune 100. Récemment, le produit que nous utilisons a "mis à jour" à une OSGi mise en œuvre.

de départ local de l'abc de déploiement...
[2/18/14 8:47:23:727 EST] 00000347 CheckForOasis

finalement déployée et "les combinaisons suivantes seront mises en pause, puis repris"
[2/18/14 9:38:33:108 EST] 00000143 AriesApplicat je CWSAI0054I: dans le cadre d'une opération de mise à jour pour l'application

51 minutes... chaque fois que des modifications du code... de La version précédente (non-OSGi) se déploie en moins de 5 minutes sur les anciennes machines de développement.

sur une machine avec 16 go de ram et 40 gig de disque et Intel i5-3437U 1,9 GHz CPU

L ' "avantage" de cette mise à niveau a été vendu comme l'amélioration de la production des déploiements - une activité que nous faisons environ 4 fois dans l'année avec peut-être 2-4 petit correctif déploiements d'un an. L'ajout de 45 minutes par jour pour 15 personnes (contrôle de la qualité et développeurs) je ne peux pas imaginer jamais être justifiée. Dans les grandes applications d'entreprise, si votre application est une application de base, puis, changeant, il est, à juste titre (de petits changements ont un potentiel de lourdes répercussions doivent être communiquées et planifiées avec les consommateurs de l'entreprise), les monuments de l'activité de mal architecture OSGi. Si votre application n'est pas une application d'entreprise - c'est à dire chaque consommateur peut avoir leur propre adaptés module susceptibles de frapper leur propre silo de données dans leur propre silo avais de la base de données et en cours d'exécution sur un serveur qui héberge de nombreuses applications, puis peut-être regarder OSGi. Au moins, c'est mon expérience jusqu'à présent.

OSGi rend votre code jeter NoClassDefFoundError et ClassNotFoundException pour aucune raison apparente (probablement parce que vous avez oublié d'exporter un paquet dans OSGi fichier de configuration); car il a les chargeurs de classe, il peut rendre votre classe com.example.Foo ne parviennent pas à être jeté à com.example.Foo puisque c'est en fait deux différentes classes chargées par deux chargeurs de classes. Il peut rendre votre Eclipse démarrage dans une OSGi console après l'installation d'un plugin Eclipse.

Pour moi, OSGi seulement ajouté de la complexité (car il ajouté encore un modèle mental pour moi de grok), ajouté des ennuis à cause des exceptions; je n'ai jamais vraiment besoin de la dynamicité il "offre". Il a été intrusive car elle bundle OSGi configuration de tous les modules; il n'était certainement pas simple (dans un projet plus vaste).

À cause de ma mauvaise expérience, j'ai tendance à rester à l'écart de ce monstre, je vous remercie beaucoup. Je préfère souffrir de pot de dépendance de l'enfer, car c'est plus facilement compréhensible que le chargeur de classe de l'enfer OSGi introduit.

Il est également utilisé pour apporter plus de portabilité de middleware et d'applications sur le côté mobile. Côté Mobile est disponible pour WinMo, Symbian, Android par exemple. Dès que l'intégration avec les fonctions de l'appareil se produit, peut être fragmenté.

D'autres l'ont déjà souligné les avantages en détail, j'ai l'honneur d'expliquer la pratique usecases je n'ai ni vu ni utilisé OSGi.

1. Dans l'une de nos applications, nous avons événement du débit et de l'écoulement est défini dans les plugins basés sur la plate-forme OSGi donc, demain, si un client veut différent/débit supplémentaire alors qu'il suffit de déployer un plus plugin, configurer à partir de notre console et qu'il est fait.
2. Il est utilisé pour le déploiement de magasins différents connecteurs, par exemple, supposons que nous avons déjà Oracle DB connecteur et demain mongodb est nécessaire d'être connecté puis d'écrire un nouveau connecteur et de la déployer et de configurer les détails par le biais de la console et encore vous êtes fait. le déploiement de connnectors est gérée par OSGi plugin cadre.