si vous créez une application OSGi et une application Java classique qui font la même chose et utilisent les mêmes bibliothèques, vous aurez besoin exactement du même jeu de bocaux. La grande différence est d'être capable de définir explicitement vos dépendances (et peut-être produire plus de pots granulaires pour votre application).

il n'y a qu'un seul serveur basé sur OSGi que je connaisse (la Vierge D'Eclipse, précédemment le serveur DM de Spring). Glassfish et Websphere soutiennent OSGi, mais je n'ai pas joué. avec eux donc je ne peux pas dire grand-chose. Ce que je peux dire, c'est qu'ils ont tous besoin d'un conteneur OSGi et c'est généralement L'Equinox D'Eclipse ou le Felix D'Apache.

votre question semble être vraiment sur la fourniture de l'application (trouver ce qui doit être déployé). Je sais que pour Maven 3.0 ils ont fait un tas de choses en travaillant avec le cadre D'approvisionnement P2 D'Eclipse.

pour votre application Déployez-vous une oreille ou une guerre? Pour ces services, votre système de construction sera besoin de produire l'archive avec toutes les dépendances ou il ne fonctionnera pas. C'est un peu confus sur la raison pour laquelle vous avez un problème parce que les gens utilisent Maven parce qu'il fait la gestion transitive des dépendances pour leurs constructions.

Il y a un aspect fondamental de votre question qui n'est pas encore traitée.

Glassfish est en effet un véritable serveur D'applications comme la plupart des serveurs d'applications modernes: ceux-ci vous fournissent un conteneur Web (où vous déploieriez des archives de guerre), a Java EE container (pour déployer les EJB dans les archives JAR et EAR), ainsi que l'intégration d'un conteneur OSGI. La dernière est alors utilisée pour le démarrage interne du serveur d'application mécanisme.

En essence, vous pouvez cible trois conteneurs. Les IDE modernes et les outils de construction vous fournissent des moyens d'emballer votre logique pour cibler l'un de ceux-ci. Alors la question devient: Comment puis-je concevoir mon application avec toutes ces possibilités?

Il y a quelques très important technique questions de ne pas perdre de vue. (Je me concentre ici sur des considérations objectives et factuelles, à l'écart de tout choix subjectif., philosophie, stratégie et autres considérations liées au contexte qui, en fait, peuvent aussi peser beaucoup sur votre décision finale):

1. un conteneur OSGI ne vous fournit pas Implicite ou DéclarativeGestion Des Threads,Persistance, ou gestion des transactions des services comme le web et les conteneurs Java EE. Alors, prévoyez d'analyser ces questions et de produire le code pour gérer vos threads et traiter la transaction propagation sur ces fils par exemple. Bien sûr, OSGi fournit tous les API nécessaires pour traiter ces aspects, mais ne nécessite un codage (où L'AOP peut aider). D'un autre côté, dans les conteneurs web et Java EE, vous vous fiez aux services gérés par conteneur et/ou utilisez les annotations EJB, les descripteurs de déploiement et les objets gérés par serveur comme les pools pour simplement déclarer le nombre de threads que vous voulez en parallèle, les tailles des pools de connexion et les attributs de transaction. Il y a des avantages et les inconvénients dans l'un ou l'autre style (procédural dans OSGi versus déclaratif ou implicite dans Java app. serveur.)
2. OSGI fournit un aide-soignantchargement votre code, gérer dépendances des modules, même traiter avec multiple la coexistence des versions du même module, et ajout/suppression et start/stop soi-disant bundles (unités de déploiement OSGI), à condition en effet que votre paquet contienne la logique Gérer les problèmes de démarrage/arrêt potentiels comme interrompre correctement tous les threads lancés sur un stop -- threads qui auraient pu "se propager" à travers d'autres modules dépendants. D'un autre côté, Java EE et les conteneurs Web embarquent souvent des copies de JAR's dépendants qui peuvent donner des déploiements plus gros à moins que vous ne commenciez à considérer votre serveur d'application chargeur de classe de la hiérarchie et en profiter pour déployer des' bibliothèques partagées ' soit sous forme de pots de POJO simples, soit sous forme de Java EE beans emballés dans JAR. Quoi qu'il en soit, dans les cas ultérieurs, la gestion des dépendances de déploiement devient une préoccupation que vous devrez aborder au moins à construire le temps utilisant des cadres comme Maven en effet. Ensuite, au moment de l'exécution, vous devrez peut-être script start/stop cascades selon les dépendances; sinon, profitez des extensions spécifiques du serveur d'application qui traitent ces dynamique de déploiement problèmes dans les conteneurs web et Java EE (par exemple Weblogic).
3. comme déjà dit, OSGI est maintenant utilisée par la plupart des serveurs d'applications pour gérer leurs propres séquence de démarrage. Avec la complexité croissante des plateformes, la multiplication des API, l'augmentation du nombre d'équipes de développement pour assembler un seul produit final, ainsi que l'utilisation de nombreux composants tiers / open source, OSGI devient un incontournable serveur de démarrage de l'outil pour assurer les versions stables et un ensemble cohérent de versions compatibles de tous les composants. Pensez à L'IDE Eclipse: avec un catalogue de milliers de plug-ins et un taux élevé de nouveautés, cette IDE serait une plateforme très fragile sans OSGI comme base. Les serveurs D'applications modernes sont confrontés au même problème.
4. basé sur les considérations ci-dessus peut être tentant d' calque votre code dans certaines installations que vous pourriez baser dans la couche OSGI, qui à son tour fournit des services de base à une couche Java EE bean hébergement logique d'affaires, puis une couche de servlet Web à l'interface de l'ensemble... mais deux autres questions fusent: (a) Comment faites-vous pour que tous ces éléments communiquent ensemble? OSGI dispose de son propre mécanisme de dépôt et les API jar déployées ne seront pas visibles par les autres modules à moins d'être explicitement publiées dans OSGI. Les conteneurs web et Java EE utilisent une technologie de dépôt complètement différente pour accéder aux interfaces des autres composants, à savoir JNDI. Encore une fois, regardez la documentation spécifique à votre serveur d'application qui peut fournir des moyens d'aborder les haricots Java EE des paquets OSGI et vice-versa (Glassfish par exemple, depuis V3); mais soyez prudent sur la gestion du fil et les portées de transaction. (b) Comment éviteriez-vous d'interférer dans la séquence de démarrage du serveur d'application? OSGI tend à devenir une fonctionnalité de base du système (sous la gouvernance du fournisseur), par rapport aux conteneurs web et Java EE naturellement orienté pour héberger votre code d'application (sous votre gouvernance). La mise à niveau de votre serveur d'application ou l'installation d'une nouvelle version peut interférer avec vos propres déploiements OSGI; vous devrez vérifier le problème et organiser vos scripts de déploiement en conséquence.

la question est riche et son analyse complexe. Un examen plus approfondi doit tenir compte de la nature de la demande de construire. En outre, si vous avez l'intention d'utiliser des cadres de développement comme open source Spring et/ou Camel, ainsi que des cadres spécifiques au fournisseur comme Oracle Fusion SOA composites, JBoss Switchyard,etc. vous aurez de nombreuses autres contraintes techniques à prendre en considération.

il n'y a pas de réponse unique à ces questions et cela justifie essentiellement la pléthore actuelle de technologies qui se chevauchent.

lorsque cette question d'architecture est résolue, alors vous pouvez chercher à optimiser la productivité avec une gestion de configuration et un référentiel de déploiement appropriés.