La technologie OSGi [OSGi05] a été choisie pour l'expérimentation de l'approche Home SOA en raison de ses avantages techniques :
• Modularité et chargement de classes dynamique répondent aux exigences de couplage lâche et de chargement logiciel à la demande exprimées face au défi d'hétérogénéité (Chapitre II.4.3.1) des environnements pervasifs. La modularité du déploiement OSGi offre une délimitation naturelle des parties applicatives pertinentes pour la répartition post-développement (cf. Chapitre II.3.3).
• Le modèle de programmation orienté service parfait la réponse à l'exigence de couplage lâche et offre une base de travail simple pour bâtir une solution de sélection de services dynamique (cf. Chapitre II.5.4)..
• La simplicité du langage de programmation associé, Java, répond au besoin de prototypage rapide et d'évolutivité face à l'ouverture des réseaux pervasifs.
Aussi, le choix se justifie industriellement sur les équipements de réseaux locaux par plusieurs raisons anticipant un déploiement à un terme plus ou moins long selon l'équipement et le réseau visé.
1.1.1 Avantages techniques
Son avantage technique principal est son modèle de développement et de déploiement modulaire par le partage et séparation de code dans des modules applicatifs distincts (bundles). Il permet la structuration des applications en modules applicatifs aux dépendances à grain fin clairement définies par des notions du langage de programmation sous-jacent : le package et la classe Java. Cette correspondance avec des notions de langage permet d'implémenter des garde-fous naturels pour le partage et l'isolation. Les limites de partage sont vérifiées par des politiques données aux chargeurs de classes (classloaders). Chaque bundle possède son propre chargeur de classes. Celui-ci charge les classes déclarées privées et exportées, et référence le chargeur de classes élu par la plateforme sous-jacente pour les packages déclarés importés. Cette flexibilité de partage et d'isolation de parties de code entre entités logicielles semblent uniques parmi les plateformes logicielles existantes. La section Chapitre III.3.3 présente comment les modèles .NET, Linux et MIDP3 n'offrent pas de telles propriétés.
Figure 64 Patron de conception SOA sur la plateforme OSGi
Son second atout, qui peut paraître indépendant à première vue, est le modèle de collaboration à base de service entre les modules applicatifs. La technologie OSGi donne les fondements d'une programmation orientée services. Le standard OSGi applique techniquement le concept de plateforme de services décrit en Chapitre V.2.2. Elle offre le registre de services auprès duquel tout objet peut requérir, enregistrer et retirer des services. Un système de souscription et de notification d'événements lui est associé afin que tout objet puisse être notifié des départs, arrivées et mises à jour des services dans le registre. Home SOA exploite ces fondements en recommandant le suivi de patrons de conception avancés. Quelques autres cadriciels comme Avalon de la communauté Apache (avalon.apache.org) étaient basés sur le patron "Dynamic Service Locator" au moment où l'Alliance OSGi délivrait sa première version de spécification. Mais ces autres tentatives n'étaient pas associées à des mécanismes de déploiement modulaires. La programmation orientée service d'OSGi est en effet liée au partage et l'isolation de code entre bundles puisque ces mécanismes modulaires permettent
• d'une part, aux clients et aux serveurs de partager les mêmes interfaces sans que les clients et serveurs ne partagent d'autres parties de code (cf. Figure 64)
• d'autre part, aux clients de partager la même instance de service sans qu'aucun d'entre eux ne puissent introspecter le code de chacun des autres.
Le chargement de classe Java permet de plus le déploiement de code 'à chaud', utile pour l'installation, la désinstallation, la mise à jour des bundles sans arrêt de fonctionnement des applications de la plateforme (sauf, évidemment, celles qui dépendent de manière obligatoire du module donné). Il est notable que .NET et Java MIDP(3) ne permettent pas cette flexibilité sans pertes importantes sur les propriétés de partage et d'isolation.
1.1.2 Avantages industriels
La technologie OSGi possède des attraits industriels notables. Les serveurs d'applications les plus importants l'ont déjà adopté et d'autres segments montrent quelques succès. Les réseaux mobiles, domestiques et véhiculaires montrent beaucoup de prototypes et de promesses à plus ou moins long terme. Voici les avantages industriels de la technologie :
• son état de standard : OSGi est une technologie poussée par un large consortium presque sans concurrent au-dessus de la technologie Java. Au dessus d'autres langages de programmation, d'autres technologies existent mais n'offrent pas tous avantages techniques d'OSGi. Ceux qui s'en approchent sont de surcroit faibles (Microsoft .NET) ou fragmentés (distributions Linux).
• l'adoption du standard OSGi : la technologie est présente sur des serveurs d'application (IBM Websphere Suite, Jonas 5, Redhat JBoss, Apache Geronimo…), sur le marché SOHO (Imprimantes Canon et Ricoh depuis 2003) et dans l'automobile (BMW depuis 2004), mais demeure balbutiante sur le marché du mobile (applications Nokia à venir) et sur le marché domestique. La technologie OSGi suscite aujourd'hui un intérêt parmi les acteurs de ce dernier marché : NTT, Deutsch Telekom, Telefònica, Samsung, Prosyst, Makewave ont fondé en 2007 le Residential Expert Group avec l'objectif de spécifier une architecture logicielle de référence pour l'administration du réseau domestique.
• l'ouverture du standard OSGi : l'utilisation du standard est libre. Les spécifications ont été rendues disponibles sous 4 versions successives de 1999 à octobre 2005. Une 5ème version est attendue pour l'année 2009. Les plus grands acteurs de la spécification OSGi ont fait une promesse de non-assertion. La propriété intellectuelle est donc a priori délivrée gratuitement. Trois implémentations répandues de la plateforme sont développées et maintenues par des communautés open source importantes : eclipse equinox est soutenue par IBM, Knopflerfish est soutenue par Makewave, et felix est un projet très actif de la grande communauté Apache.
• le nombre de briques (bundles) OSGi existantes : les développements OSGi profitent d'un formidable réservoir de bundles disponibles dû à l'abondance des applications Java et à la maturité du standard tiré par d'importants acteurs (IBM, Nokia, Siemens, etc.) depuis 1999. Le cœur d'OSGi étant une couche intergicielle à l'API simple et d'implémentation légère (par exemple, l’implémentation open source Apache felix représente 300 KB) permettant la modularité au-dessus de Java, toute application Java peut être l'objet d'une modularisation au-dessus de la plateforme OSGi. L'évolution de la spécification OSGi a de plus construit un catalogue de nombreuses spécifications de services applicatifs pouvant fonctionner au-dessus de la plateforme.
1.1.3 Les freins à son adoption
Les freins à son adoption pour sur les réseaux locaux sont aussi d'ordre technique et ont un impact industriel : son principal défaut est d'être associé à la technologie Java, en particulier Java CDC. En effet, cette technologie est coûteuse sur les équipements embarqués. Ce coût provient du besoin en mémoire et en puissance de calcul de la machine virtuelle Java. Ce besoin est plus grand que celui de programme en langage C pour les applications
embarquées. De surcroit, il est plus grand que celui de programmes développés dans la technologie Java CLDC qui vise des environnements embarqués. La principale différence entre les deux plateformes Java concerne les chargeurs de classes qui ne sont disponibles que sur CDC et qui sont le fondement de la modularité d'OSGi. Ce coût en ressources de la plateforme Java sous-jacente semble plus grand que l'avantage d'évolutivité apporté par OSGi dans la plupart des applications embarquées sur les équipements des réseaux locaux.
L'impact industriel est visible : Java n'a de succès véritable que sur les serveurs d'applications, sur les navigateurs Internet et sur les équipements importants des réseaux d'entreprises (imprimantes). Son adoption dans les véhicules est marginale; seul BMW équipe ses voitures avec la technologie Java/OSGi. L'adoption de Java CDC par une plateforme avancée dans le réseau domestique est récente : les lecteurs DVD Blu-ray Sony. La situation du réseau mobile est particulière : Java est déjà adopté sous sa forme CLDC. CDC apporte une véritable rupture technique, le marché ne l'acceptera pas à court terme.