Quoi de neuf à Osgi 4.2?

Dans la plupart des cas, une version ponctuelle d'OSGI (telle que 4.1-> 4.2) ne change pas vraiment beaucoup de comportement existant. Il est donc prudent de dire que si vous avez une application qui dépend du 4.1, ça va courir sur 4.2 Sans problème. Ce qui est nouveau, c'est que quelques éléments ont été standardisés, ce qui devrait permettre une meilleure interopérabilité entre différents moteurs OSGI (comme Equinox , Felix et Knopflerfish ).

En fait, bien que OSGI 4.2 n'était officiellement disponible officiellement le 16 septembre 2009, les premiers versés ont été disponibles pour que d'autres se réfèrent, de sorte que les versions précédentes des produits (comme Equinox 3.5, Felix 1.8) ont déjà un soutien raisonnable pour la la norme. Comme des produits 802.11n, ils sont conformés aux brouillons antérieurs, mais l'attente est qu'elles seront certifiées entièrement conformes à la version 4.2 dans le futur non trop éloigné.

Alors, quoi de neuf en 4.2?

• crochets de service
• cadre de lancement

  et, dans le Compendium

  • SERVICES REMOTE
  • Bundle Tracker
  • SERVICE PLUBLEPRINT

    crochets de service

    L'API Hook Service vous permet de récupérer des événements qui se produisent à la couche de service. Par exemple, vous pouvez vous connecter lorsqu'un service est demandé lorsqu'un service a fourni un événement livré, etc. Vous pouvez également causer des événements non livrés (par exemple, cacher des événements que vous n'êtes pas autorisé à voir) mais ne peut modifier aucun événement (car cela compliquerait les classes étant livrées). Les crochets de service font partie de la spécification de base, de sorte que toutes les versions OSGI auront besoin que cela soit conforme.

    cadre de lancement

    Bien qu'il soit possible de démarrer de manière programmée une instance OSGI à partir d'une application Java existante, la manière dont vous effectuez cela dépend de laquelle vous utilisez l'exécution OSGI. En particulier, les éléments de configuration (tels que le stockage des données transitoires, quelle que soit la politique de la délégation de démarrage de l'ensemble, etc.) étaient toutes définies de manière spécifique à un moteur. Cela consolide les propriétés qui sont définies sur le cadre par n'importe quel utilitaire de lancement.

    Services distants

    L'API de services à distance permet aux services OGSI de communiquer entre VMS (éventuellement sur différentes machines). Le mécanisme exact de la manière dont ils communiquent (RMI, Webservices, etc.) sont ouverts aux fournisseurs. Il est donc différent de ce que les autres technologies distribuées (telles que corba) dictent spécifiquement sur le format du fil. De toute évidence, les services distribués ont une sémantique différente de celle locale (erreurs de communication, problèmes de sérialisation) et il est laissé aux services individuels à distribuer si nécessaire.

    Bundle Tracker

    J'aime le serviceTracker avant son entrée en 4.1, le BundeLracker peut être utilisé pour garder un œil sur lequel les faisceaux venaient et vont dans le système. Ceci peut être utilisé par des Guis dynamiques pour montrer l'état évolutif du moteur OSGI sans aucune connaissance spécifique de la plate-forme.

    SERVICE DE RLUPHIPT

    Le service de planimint est similaire au ressort, car il fournit un mécanisme d'injection de dépendance pour la configuration des paquets. À certains égards, il est similaire aux services déclaratifs; Mais le service de plans fait les choses de manière différente. En outre, contrairement aux services déclaratifs (qui ne peuvent traiter que des services présents), le service de planimint peut créer un espace porteur proxy à l'avance pour un service qui sera en ligne plus tard. Les appels vers le proxy de service bloqueront ensuite jusqu'à ce que le service puisse être rempli (plutôt que de renvoyer «NULL» à titre de services déclaratifs). Si vous êtes à l'aise ou familiarisé avec le Spring IOC et l'injection de dépendance similaire, le service de planimint sera immédiatement compréhensible.