Déclaration de vos services auprès des services déclaratifs OSGi

Vous pouvez utiliser un fichier XML distinct pour déclarer chaque service dans un bundle.

Pourquoi et quand exécuter cette tâche

Le support des services déclaratifs fonctionne sur les composants déclarés, qui sont chacun définis par un fichier XML dans le bundle. Lorsqu'un bundle contenant des déclarations de composant est ajouté à l'infrastructure, les services déclaratifs lisent chaque déclaration de composant et enregistrent les services mis à disposition dans le registre de services. Puis, ils gèrent le cycle de vie du composant en le contrôlant en fonction d'une combinaison d'attributs déclarés et de dépendances satisfaites.

La description XML des composants permet aux services déclaratifs de résoudre les dépendances de service sans qu'il ne soit nécessaire d'instancier le composant, ou de charger ses classes d'implémentation. Ainsi, le chargement des ressources tardif et différé est possible, ce qui contribue à l'amélioration du démarrage du serveur et à la diminution de l'encombrement de la mémoire d'exécution.

Les fichiers XML qui décrivent les composants sont répertoriés dans le fichier MANIFEST.MF du bundle avec l'en-tête Service-Component et se trouvent par convention dans le répertoire /OSGI-INF du bundle.

Plusieurs outils peuvent être utilisés pour générer le fichier XML requis ; les exemples ci-dessous illustrent le fichier XML lui-même.

Cette rubrique décrit un bundle OSGi simple qui utilise des éléments XML pour déclarer ses composants aux services déclaratifs.

Procédure

  1. Identifiez votre composant avec son nom de classe d'implémentation.
    <component>
      <implementation class="com.example.bundle.HelloComponent"/>
    </component>
  2. Déclarez le service en référençant le nom de l'interface qu'il met à disposition. Il s'agit du nom qui sera publié dans le registre de services par les services déclaratifs au démarrage du bundle.
    <component>
      <implementation class="com.example.bundle.HelloComponent"/>
      <service>
         <provide interface="com.example.HelloService"/>
      </service>
    </component>
  3. Nommez le composant. Le nom du composant sert également de service d'"identité persistante" ou de PID, qui est utilisé pour associer des propriétés de configuration au service. Les propriétés de configuration dont le PID correspond sont injectées dans le composant lors de son activation et à chaque fois que les propriétés sont mises à jour.
    <component name="HelloService">
      <implementation class="com.example.bundle.HelloComponent"/>
      <service>
        <provide interface="com.example.HelloService"/>
      </service>
    </component>
    Remarque : Sous Liberty, un utilisateur peut ajouter l'élément suivant au fichier de configuration server.xml et les propriétés sont injectées dans la classe HelloComponent :
    <HelloService firstKey="firstValue" secondKey="secondValue" />
  4. Conditionnez le fichier XML dans le bundle.
    Par exemple, le fichier XML se trouve dans OSGI-INF/HelloService.xml, et vous ajoutez un en-tête au fichier manifeste du bundle MANIFEST.MF pour que les services déclaratifs puissent localiser le fichier :
    Service-Component: OSGI-INF/HelloService.xml
    Si plusieurs composants sont conditionnés dans le même bundle, les fichiers XML correspondants doivent être indiqués sous forme de liste et séparés par une virgule. Exemple :
    Service-Component: OSGI-INF/HelloService.xml, OSGI-INF/GoodbyeService
  5. L'implémentation Java™ du composant HelloService est la suivante :
    package com.example.bundle;
    
    import com.example;
    import org.osgi.service.component.ComponentContext;
    
    /*
     * This class must be public and have a public default constructor for it to be 
     * usable by DS. This class is not required to be exported from the bundle.
     */
    public class HelloComponent implements HelloService {
    	/**
    	 * Optional: DS method to activate this component. If this method exists, it
    	 * will be invoked when the component is activated. Best practice: this
    	 * should be a protected method, not public or private
    	 * 
    	 * @param properties
    	 *            : Map containing service & config properties
    	 *            populated/provided by config admin
    	 */
    	protected void activate(ComponentContext cContext,
    			Map<String, Object> properties) {
    		modified(properties);
    	}
    
    	/**
    	 * Optional: DS method to deactivate this component. If this method exists,
    	 * it will be invoked when the component is deactivated. Best practice: this
    	 * should be a protected method, not public or private
    	 * 
    	 * @param reason
    	 *            int representation of reason the component is stopping
    	 */
    	protected void deactivate(ComponentContext cContext, int reason) {
    	}
    
    	/**
    	 * Optional: DS method to modify the configuration properties. This may be
    	 * called by multiple threads: configuration admin updates may be processed
    	 * asynchronously. This is called by the activate method, and otherwise when
    	 * the configuration properties are modified while the component is
    	 * activated.
    	 * 
    	 * @param properties
    	 */
    	public synchronized void modified(Map<String, Object> properties) {
    		// process configuration properties here
    	}
    
    	/**
    	 * Service method defined by com.example.HelloService interface
    	 */
    	public void sayHello() {
    		System.out.println("Hello");
    	}
    }

Icône indiquant le type de rubrique Rubrique Tâche



Icône d'horodatage Dernière mise à jour: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_declare_services_ds
Nom du fichier : twlp_declare_services_ds.html