Donsez: /* Blueprint */

2014-04-26T05:28:43Z

Blueprint

← Older revision		Revision as of 05:28, 26 April 2014
Line 75:		Line 75:

	===Blueprint===		===Blueprint===

			===SCA===
			NaScCA, Frascati, Tuscani

	===Autres===		===Autres===

Donsez: /* iPOJO */

2014-04-26T05:27:28Z

iPOJO

← Older revision		Revision as of 05:27, 26 April 2014
Line 73:		Line 73:

	Les métadonnées peuvent être décrites de 3 manières possibles: entrée de Manifest, XML et annotations Java 5.0.		Les métadonnées peuvent être décrites de 3 manières possibles: entrée de Manifest, XML et annotations Java 5.0.

			===Blueprint===

	===Autres===		===Autres===

Donsez: Created page with "Précédent Sommaire Suivant ---- ==Modèles de Composants pour OSGi== Rédacteur(s): Didier Donsez, Thomas Calmant ===Introduction=== L'obs..."

2014-04-25T20:34:43Z

Created page with "Précédent Sommaire Suivant ---- ==Modèles de Composants pour OSGi== Rédacteur(s): Didier Donsez, Thomas Calmant ===Introduction=== L'obs..."

New page

[[Chap02|Précédent]] [[Livre|Sommaire]] [[Chap04|Suivant]]
----

==Modèles de Composants pour OSGi==
Rédacteur(s): Didier Donsez, Thomas Calmant

===Introduction===
L'observateur de la section de code précédente est relativement simple car un ServiceListener complet doit traiter les expressions de filtre pour restreindre le nombre de services et prendre en compte les changements de propriétés. Il peut éventuellement agir sur le cycle de vie de l'utilisateur des services si la disparition de ceux-ci empêche un fonctionnement normal. Cette tâche devient ingérable quand le nombre de services utilisés grandit. Le constat est que la prise en charge de la dynamique des services est une tâche très lourde pour le développeur OSGi et qu'elle conduit à un taux élevé d'erreurs de programmation qui peut provoquer un blocage partiel de la plate-forme. Une première réponse à ce constat est la classe utilitaire ServiceTracker (paquetage org.osgi.util.servicetracker)qui comme son nom l'indique suit un service. ServiceTracker est limité par le fait qu'il ne traque qu'un seul service et ne gère pas le cycle de vie de l'objet utilisateur des services en fonction de leurs disponibilités effectives.

===Declarative Service et Service Binder===
Didier (source chapitre ICAR)
http://www2.lifl.fr/icar/Chapters/OSGI/osgi-body.html#tth_sEc7.4.6

Le ''Service Component Runtime} introduit dans la spécification 4, propose un modèle à composants\cite{Szyperski:1998} orienté services qui capture la dynamique des services et assujettit le cycle de vie de l'objet utilisateur en fonction de la présence des services requis obligatoires. Le développement est grandement simplifié par la décription du composant au moyen d'un descripteur déclaratif dans une grammaire XML. Il reprend à son profit les principales idées de ''ServiceBinder}\cite{DBLP:conf/cbse/CervantesH04}\cite{/phd/2004/Cervantes} mais le complète cependant par la possibilité de retarder l'activation des ''bundles} fournisseurs de services jusqu'à la demande de liaison (méthode <code>getService(ServiceReference)</code> de <code>BundleContext</code>.

L'exemple suivant présente deux composants interagissant via un service d'impression.

Le composant fournisseur du service est décrit par par le descripteur suivant. Ce composant enregistre un service comportant une interface fonctionnelle <code>PrintService</code> et une interface technique <code>ConfigMBean</code> \footnote{qui permet la configuration du composant via un agent JMX \cite{jmx} embarquable sur la passerelle}) avec leurs propriétés d'enregistrement. Les propriétés déclarées sont utilisées pour qualifier le service fourni. Le fournisseur de service peut être une fabrique de services (non présenté dans l'exemple) qui délivre des services personnalisés à chaque composant utilisateur au lieu du singleton commun à tous.

<pre>
<component name="printer">
<implementation class="com.hp.printer.deskjet.impl.PrinterComp"/>
<property name="org.device.print.type" value="inkjet" type="String"/>
<property name="location" value="4st floor" type="String"/>
<property name="jmx.objectName"
value="printer.hp:name=DeskJet 930c 4st fl." type="String"/>
<service>
<provide interface="org.device.print.PrintService"/>
<provide interface="com.hp.printer.ConfigMBean"/>
</service>
</component>

</pre>
Le composant utilisateur du service est décrit par le descripteur suivant. Ce composant sera instancié dès qu'un <code>PrintService</code> est disponible et sera détruit dés que le dernier <code>PrintService</code> se désenregistre. L'attribut <code>cardinality</code> indique si la liaison est simple ou multiple. Les méthodes de callback pour le contrôle de la liaison sont décrit par les attributs <code>bind</code> /<code>unbind<~/code>. L'attribut <code>policy</code> indique un service qui disparaît est substituable par un autre équivalent. L'attribut <code>target</code> restreint le courtage à un sous-ensemble de services <code>PrintService<~/code>. Le second élément <code>reference</code> automatise la liaison avec un service optionel de journalisation.

<pre>

<component name="editor">
<implementation class="org.eclispe.texteditor.impl.EditorComp"/>
<reference name="PRINT"
interface="org.device.print.PrintService"
target="(&(location=*)(org.device.print.type=inkjet))"
cardinality="1..n"
policy="dynamic"
bind="bindPrintService"
unbind="unbindPrintService"
/>
<reference name="LOG"
interface="org.osgi.service.log.LogService"
cardinality="0..1"
policy="dynamic"
bind="setLogService"
unbind="unsetLogService"
/>
</component>
</pre>
Les chemins des descripteurs de composants du ''bundle} sont listés dans l'entrée <code>Service-Component</code> du manifeste du ''bundle}.

SCR reprend à son profit les principales idées de ServiceBinder [Cervantes and Hall 2004][Cervantes 2004]. SCR le complète néanmoins par la possibilité de retarder l'instanciation de l'objet de service jusqu'à la demande de liaison effective par un bundle usager. Cette fonctionnalité permet de limiter l'usage des ressources de la machine hôte lorsque de nombreux services sont déployés sans être utilisés. SCR reste cependant un modèle de composants simple et non-hièrarchique qui ne prend pas en charge les aspects non fonctionnels comme la persistance, la sécurité, la distribution, les sessions, etc. Le développeur OSGi doit encore gérer ceux-ci de manière ad-hoc et non transparente.

===Dependency Manager===

===Spring DM===
[http://www.springframework.org/osgi Spring Dynamic Modules] (DM)

Ex Spring/OSGi

===iPOJO===

[http://felix.apache.org/site/ipojo.html iPOJO] s'intéresse à l'ingénierie des conteneurs dynamiques pour les services OSGi par l'utilisation de la programmation orientée aspect ou bien encore par l'injection de code sur des POJOs (Plain Old Java Objects). Le conteneur iPOJO peut être étendu par des handlers (qui peuvent être eux-meme des composants iPOJO).

Les métadonnées peuvent être décrites de 3 manières possibles: entrée de Manifest, XML et annotations Java 5.0.

===Autres===
* Newton
* EasyBeans/OSGi
* Juice/OSGi
* ...

===Conclusion===

OSGi Pas à Pas/Chap03 - Revision history

Donsez: /* Blueprint */

Donsez: /* iPOJO */

Donsez: Created page with "Précédent Sommaire Suivant ---- ==Modèles de Composants pour OSGi== Rédacteur(s): Didier Donsez, Thomas Calmant ===Introduction=== L'obs..."