OSGi Pas à Pas/Chap04
Services Standards
Rédacteur(s): Didier Donsez
Il faut ajouter http://www2.lifl.fr/icar/Chapters/OSGI/osgi-body.html#tth_sEc7.5
L'OSGi Alliance a progressivement enrichi les spécifications successives de services standards. Ces services sont assez généraux pour être utilisables dans n'importe quel domaine d'application. Ils sont optionnels par rapport au noyau OSGi qui ne dépend d'aucun d'entre eux (excepté StartLevel). Le développement d'une application ne requiert en général qu'un sous-ensemble des services standards complétés par des services propriétaires.
Cette section débute par un tour d'horizon (non exhaustif) des services standardisés par l'OSGi Alliance.
Tour d'horizon
La première version de la spécification ne comporte que trois services standards. Elle en compte maintenant plus d'une vingtaine dans la version 4. Ces services peuvent se repartir en 3 groupes : les services dédiés à l'administration de la plate-forme, ceux dédiés aux communications et les services utilitaires pour le développeur.
Services d'administration
User Admin Service
Le service User Admin administre des utilisateurs authentifiés de la passerelle. Il s'appuie sur le mécanisme d'autorisation de JAAS introduit dans le J2SE 1.4. Ce service apparait dans l'exemple de la figure osgi:httpadmin
Preferences Service
Le service Preferences s'apparente à un registre de propriétés associés aux bundles et aux utilisateurs. Le nommage des préférences est hiérarchique.
Configuration Admin Service
Le service Configuration Admin permet la configuration des bundles déployés. Un bundle configurable doit enregistrer un service implémentant l'interface ManagedService. Ce service est utilisé par le gestionnaire de configuration de la plate-forme pour configurer ce bundle à partir d'information dépendant de l'environnement local (port série disponible, \ldots).
Permission Admin Service et Conditionnal Permission Admin Service
Le service Permission Admin permet de déployer dynamiquement les permissions REF osgi:securite accordées aux bundles déployés.
Package Admin Service
Le service Permission Admin permet d'administrer la résolution des paquetages partagés entre un ensemble de bundles Il est notamment chargé du rafraîchissement de la résolution REF osgi:bundle.
Start Level Service
La plate-forme OSGi définit plusieurs niveaux de démarrage pour les bundles déployés. Le niveau 0 est celui du bundle System (toujours identifié 0). Le passage d'un niveau vers un niveau supérieur provoque le démarrage des bundles du niveau supérieur. Inversement, le passage vers un niveau inférieur provoque l'arrêt des bundles du niveau courant. Le service Start Level administre ces transitions de niveau.
MetaType
Le service MetaType offre un annuaire d'information structuré d'une manière similaire à celui de LDAP. Ce service peut servir au stockage de la configuration des bundles.
Services de communication
Io Connector Service
Le service Io Connector s'appuie sur l'API d'entrée-sortie de Java 2 Micro Edition. Il offre un service de fabrique de connexion à partir d'URL (par exemple, udp://53 dvb://1.2.3.4, sms://, sms://+3366321456789;expires=no, mms://+3366321456789, mcast://255.0.12.34:5678/prefs/stb.cfg ... Les fabricants effectifs de ces schémas d'URL sont des services livrés dans d'autres bundles). Les fabricants sont liés dynamiquement par la fabrique Io Connector selon le patron de conception Fabrique.
URL Handlers Service
Le cadre architectural URL Handler de la plate-forme Java permet d'ajouter des traitants d'URL. Ce service permet l'installation ou le changement dynamique de ces traitants.
HTTP Service
Le service HTTP permet aux autres bundles de faire servir leurs servlets et sites Web (documents statiques) par un unique serveur HTTP embarqué dans le bundle offrant ce service. Ce service est détaillé dans la section Http.
JINI Device Driver
Jini est une technologie de découverte et de contrôle d'équipements raccordés à un réseau impromptu (ad-hoc). Le service JINI Device à deux objectifs: premièrement, d'enregistrer les services Jini disponible dans le registre de service de la plate-forme OSGi pour les rendre utilisable par les bundles déployés, deuxièmement, exporté des services OSGi comme des services Jini. Le chapitre sur JINI a néanmoins disparu de la spécification 4 d'OSGi.
UPnP Device Driver
UPnP est une autre technologie de découverte et de contrôle d'équipements raccordés à un réseau impromptu (ad-hoc). L'UPnP Device Driver permet à la fois de développer des points de contrôle UPnP et des périphériques UPnP au dessus d'une plate-forme OSGi. Ce service est détaillé dans la section UPnP Base Driver
Wire Admin Service
Le service Wire Admin permet de construire des applications à base de capteurs. Ce service est détaillé dans la section Wire Admin.
Event Admin Service
Le service Event Admin Service offre un modèle de communication événementiel entre les bundles. Ce service est détaillé à la section Event Admin.
Device Access
Le Device Access spécifie comment les pilotes de périphériques matériels peuvent être recherchés, déployés et exposés comme des services OSGi. Ce service définit un processus de raffinement pour rechercher le pilote plus adapté au périphérique détectée. Le périphérique peut être branché par une liaison physique comme une liaison série ou USB ou par une liaison logique comme UPnP ou JINI.
Services utilitaires
Log Service
Le service Log est un service de journalisation de trace a des fins d'audit ou de déverminage. Les implémentations de ce service dans un contexte opérationnel peuvent stocker de manière persistante le journal et permettre sa récupération pour un centre d'administration du parc de passerelle selon des modèles de communication push ou pull.
XML Parser Service
Le service XML Parser décrit comment un bundle peut embarquer un analyseur XML et enregistrer ses fabriques SAXParserFactory et DocumentBuilderFactory pour qu'elles soient utilisées par les autres bundles. Les propriétés d'enregistrement qualifient les caractéristiques de l'implémentation embarquée (validation ou non, ...).
Declarative Service
Le service Declarative définit un modèle de composant déclaratif pour OSGi. Ce modèle a été détaillé dans la section.
Application Admin Service
Ce service introduit par le Mobile Expert Group (MEG), permet de contrôler le cycle de vie d'applications développées selon d'autres modèles d'exécution. Ces applications peuvent être par exemple des Applets, des Midlets, des applications Symbian ou BREW.
DMT Admin Service
Ce service introduit par le MEG, offre une vue logique pour administrer une plateforme OSGi. Cette vue appelé Device Management Tree (DMT) est structurée en arbre de noeuds nommés. Le service DMTAdmin gère l'ajout et le retrait dynamique de protocoles d'accès distant à la vue, de plugins pour exécuter des requêtes sur les noeuds. L'accès à la vue est sessionnelle. Une session peut être transactionnelle sur un ensemble d'opérations réalisées sur les noeuds de l'arbre.
Monitor Admin Service
Ce service introduit par le MEG, permet aux applications et aux services de publier des modifications sur des variables d'état comme la mémoire disponible, le niveau d'énergie de la batterie ou bien le nombre de SMS envoyés. Des services d'administration peuvent découvrir les variables d'état publiées et souscrire à leurs changements. Ce service est fortement rélié au service Event Admin.