Services in OSGi Declarative Services deklarieren

Sie können eine gesonderte XML-Datei verwenden, um alle Services innerhalb eines Bundles zu deklarieren.

Informationen zu diesem Vorgang

Die DS-Unterstützung (Declarative Services) wird für deklarierte Komponenten bereitgestellt, von denen jede durch eine XML-Datei im Bundle definiert wird. Wenn ein Bundle, das Komponentendeklarationen enthält, zum Framework hinzugefügt wird, liest DS jede Komponentendeklaration und registriert die bereitgestellten Services in der Service-Registry. DS steuert anschließend den Lebenszyklus der Komponente basierend auf einer Kombination der deklarierten Attribute und erfüllte Abhängigkeiten.

Die XML-Beschreibung von Komponenten ermöglicht DS, Serviceabhängigkeiten aufzulösen, ohne dass die Komponente instanziiert werden muss oder ihre Implementierungsklassen geladen werden müssen. Das vereinfacht das späte und verzögerte Laden von Ressourcen und hilft, den Serverstart zu verbessern und den Speicherbedarf der Laufzeit zu reduzieren.

Die XML-Dateien, die die Komponenten beschreiben, sind in der Datei MANIFEST.MF des Bundles im Service-Component-Header aufgelistet und befinden sich gemäß Konvention im Verzeichns /OSGI-INF des Bundles.

Es gibt eine Reihe von Tools, mit denen die erforderliche XML generiert werden kann. Die folgenden Beispiele zeigen die XML selbst.

Dieser Artikel beschreibt ein einfaches OSGi-Bundle, das XML für die Deklaration von Komponenten in DS verwendet.

Vorgehensweise

  1. Identifizieren Sie die Komponente über ihren Implementierungsklassennamen.
    <component>
      <implementation class="com.example.bundle.HelloComponent"/>
    </component>
  2. Deklarieren Sie den Service, indem Sie den Namen der Schnittstelle referenzieren, die ihn bereitstellt. Dies ist der Name, der beim Start des Bundles von DS in der Service-Registry veröffentlicht wird.
    <component>
      <implementation class="com.example.bundle.HelloComponent"/>
      <service>
         <provide interface="com.example.HelloService"/>
      </service>
    </component>
  3. Benennen Sie die Komponente. Der Komponentenname fungiert auch als "persistente Identität" (oder PID) des Service, die verwendet wird, um dem Service Konfigurationseigenschaften zuzuordnen. Konfigurationseigenschaften mit einer übereinstimmenden PID werden bei Aktivierung oder Aktualisierung in die Komponente injiziert.
    <component name="HelloService">
      <implementation class="com.example.bundle.HelloComponent"/>
      <service>
        <provide interface="com.example.HelloService"/>
      </service>
    </component>
    Anmerkung: In Liberty kann ein Benutzer das folgende Element der Konfigurationsdatei server.xml hinzufügen, und die Eigenschaften werden in die Klasse HelloComponent injiziert.
    <HelloService firstKey="firstValue" secondKey="secondValue" />
  4. Packen Sie die XML-Datei in das Bundle.
    Beispiel: Die XML-Datei befindet sich an der Position OSGI-INF/HelloService.xml, und Sie fügen der Bundlemanifestdatei MANIFEST.MF einen Header hinzu, damit DS die Datei lokalisieren kann:
    Service-Component: OSGI-INF/HelloService.xml
    Wenn mehrere Komponenten im selben Bundle gepackt werden, müssen die entsprechenden XML-Dateien wie eine durch Kommas getrennte Liste eingegeben werden. Beispiel:
    Service-Component: OSGI-INF/HelloService.xml, OSGI-INF/GoodbyeService
  5. Die Java™-Implementierung der HelloService-Komponente sieht folgendermaßen aus:
    package com.example.bundle;
    
    import com.example;
    import org.osgi.service.component.ComponentContext;
    
    /*
     * Diese Klasse muss öffentlich sein und einen öffentlichen Standardkonstruktur haben,
     * damit sie von DS genutzt werden können. Diese Klasse muss nicht aus dem Bundle exportiert werden.
     */
    public class HelloComponent implements HelloService {
    	/**
    	 	 * Optional: DS-Methode zur Aktivierung dieser Komponente. Wenn diese Methode vorhanden ist,
      * wird sie bei Aktivierung der Komponente aufgerufen. Bewährtes Verfahren: Diese Methode
      * muss als geschützte Methode verwendet werden, darf also nicht öffentlich oder privat sein.
    	 * 
    	 * @param properties
    	 	 *            : Zuordnung mit Service- und Konfigurationseigenschaften,
    	 *              die von der Konfigurationsverwaltung bereitgestellt wurden
    	 */
    	protected void activate(ComponentContext cContext, Map<String, Object> properties) {
    		modified(properties);
    	}
    
    	/**
    	 	 * Optional: DS-Methode zur Inaktivierung dieser Komponente. Wenn diese Methode vorhanden ist,
      * wird sie bei Inaktivierung der Komponente aufgerufen. Bewährtes Verfahren: Diese Methode
      * muss als geschützte Methode verwendet werden, darf also nicht öffentlich oder privat sein.
    	 * 
    	 	 * @param reason
    	 	 *            Grund für das Stoppen der Komponente wird als Integer dargestellt.
    	 */
    	protected void deactivate(ComponentContext cContext, int reason) {
    	}
    
    	/**
    	   * Optional: DS-Methode zum Ändern der Konfigurationseigenschaften. Die Methode kann
      * von mehreren Threads aufgerufen werden: Aktualisierungen der Konfigurationsverwaltung
    	 * können asynchron verarbeitet werden. Der Aufruf erfolgt über die Methode "activate"
      * oder auf andere Weise, wenn die Konfigurationseigenschaften geändert werden, während
      * die Komponente aktiviert wird.
    	 * 
    	 * @param properties
    	 */
    	public synchronized void modified(Map<String, Object> properties) {
    				// Konfigurationseigenschaften hier verarbeiten
    	}
    
    	/**
    	 	 * Servicemethode, die von der Schnittstelle com.example.HelloService definiert wird
    	 */
    		public void sayHello() {
    				System.out.println("Hello");
    	}
    }

Symbol das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 01.12.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=twlp_declare_services_ds
Dateiname: twlp_declare_services_ds.html