Extension de produit

Vous pouvez étendre la capacité de Liberty en écrivant des extensions de produit.

Vous pouvez écrire vos propres fonctions Liberty et les installer sur un serveur Liberty existant ou les conditionner pour les distribuer à vos utilisateurs.

Liberty met à disposition diverses interfaces de programmation de système (SPI) que vous pouvez utiliser pour étendre l'environnement d'exécution ; vous pouvez aussi utiliser des fonctions plus avancées telles que l'exécution du serveur Liberty depuis vos applications Java™ à l'aide d'un programme.

Extension de produit

Une extension de produit est un répertoire sur le disque qui est structuré comme le répertoire d'installation de Liberty ${wlp.install.dir}. Elle est définie dans l'installation Liberty à l'aide d'un fichier qui se trouve dans le répertoire ${wlp.install.dir}/etc/extensions et qui s'appelle nom-extension.properties. Le contenu du répertoire d'extension de produit est ensuite utilisé pour étendre Liberty. Plusieurs extensions de produit peuvent être installées ensemble mais elles doivent avoir des noms uniques ; ce principe est appliqué par la convention de dénomination des fichiers de propriétés. L'emplacement de l'extension de produit par défaut, ${wlp.user.dir}/extension, ne requiert pas de fichier de propriétés ; le contenu qui figure à cet emplacement est détecté automatiquement et l'environnement d'exécution le reconnaît en tant qu'extension de produit "usr".

En général, les extensions de produit contiennent une ou plusieurs fonctions Liberty. Toutefois, elles peuvent comporter tout type de contenu étendant l'environnement Liberty, par exemples des scripts ou des ressources.

Pratiques recommandées : Installez vos extensions de produit dans des répertoires qui ne sont pas affectés par les mises à jour de l'environnement Liberty. Pour plus d'informations, voir Quels sont les éléments susceptibles d'être modifiés par l'application d'une mise à jour ou en cas de mise à niveau ?.
Figure 1. Diagramme illustrant une installation Liberty avec deux fonctions, "Supergui" et "App Services"
Ce fichier d'extension de propriétés possède les propriétés suivantes :
com.ibm.websphere.productId=your_product_id
com.ibm.websphere.productInstall=absolute_or_relative_file_path
Remarque : Lorsqu'un chemin d'accès relatif au fichier est utilisé, il doit s'agir d'un homologue de la valeur ${wlp.install.dir}.
Exemple :
com.ibm.websphere.productId=org.acme.supergui
com.ibm.websphere.productInstall=supergui/wlp-ext

Fonction

Une fonction Liberty se compose d'un fichier de définition (manifeste de la fonction) et d'une collection de bundles OSGi qui fournissent des classes et des services correspondant à une capacité particulière dans l'environnement d'exécution Liberty.

Scénarios d'utilisation d'une fonction Liberty à la place d'une application classique

L'implémentation d'une fonction en tant que fonction Liberty et non en tant qu'application peut être appropriée dans divers scénarios. La liste suivante décrit certains des avantages de l'utilisation d'une fonction :
  • Les fonctions sont contrôlées par le biais de la configuration du gestionnaire de fonctions ; par conséquent, ils sont distincts de la gestion des applications utilisateur.
  • Le code de fonction a accès à l'interface de programmation de système Liberty, qui permet une intégration plus profonde à l'environnement d'exécution.
  • Les fonctions peuvent admettre une configuration spécifiée par l'utilisateur dans le fichier server.xml et exposer leurs paramètres de configuration dans les outils de développement sans qu'il ne soit nécessaire de changer les outils.
  • Les fonctions peuvent facilement exposer des classes et des services entre eux ainsi qu'à des applications utilisateur.
  • Les fonctions peuvent être extrêmement légères sans dépendance de conteneur d'application.
  • Les fonctions peuvent être utilisées pour étendre un modèle de programmation particulier. Par exemple, une fonction utilisateur peut ajouter la prise en charge de gestionnaires d'espace de nom Blueprint personnalisés ou d'annotations Blueprint au modèle de programmation d'application OSGi.
Remarque : Les fonctions ne sont généralement pas portables directement vers d'autres serveurs d'application. Si la portabilité est une considération importante, utilisez des applications conformes à la spécification.

Utilisation d'une fonction sur le serveur

Pour pouvoir utiliser une fonction rédigée par un utilisateur sur le serveur Liberty, vous devez l'installer dans un répertoire d'extension de produit. Il peut s'agir de l'emplacement d'"extension de produit utilisateur" prédéfini ou d'une extension qui se trouve hors du répertoire d'installation de Liberty. Ensuite, vous pouvez ajouter le nom de la fonction à la configuration de serveur.

L'extension de produit utilisateur est un répertoire prédéfini dans lequel le serveur recherche des fonctions supplémentaires. Le fichier .mf de définition de fonction doit être copié dans le répertoire ${wlp.user.dir}/extension/lib/features et les fichiers .jar de bundle dans le répertoire ${wlp.user.dir}/extension/lib.

Les fonctions rédigées par l'utilisateur sont ajoutées à la configuration de serveur de la même façon que s'il s'agissait de fonctions du produit. Pour éviter les conflits de nom avec des fonctions d'autres fournisseurs, les fonctions qui font partie d'une extension de produit doivent être préfixées avec le nom de l'extension. Pour les fonction qui se trouvent dans le répertoire usr/extension/lib, le préfixe par défaut est usr:.

Par exemple, si vous avez installé une fonction appelée simple-1.0 dans le répertoire ${wlp.user.dir}/extension/lib, vous devez configurer cette fonction dans le fichier server.xml comme suit :
<featureManager>
    <feature>usr:simple-1.0</feature>
</featureManager>
Si vous avez installé une fonction appelée myFeature dans votre propre emplacement, et défini une extension de produit dans le fichier ${wlp.install.dir}/etc/extensions/myExt.properties, vous devez configurer cette fonction dans le fichier server.xml comme suit:
<featureManager>
    <feature>myExt:myFeature</feature>
</featureManager>

Lorsque vous démarrez le serveur, la fonction est détectée par le gestionnaire de fonctions et les bundles sont installés dans l'infrastructure OSGi et démarrés.

Voir aussi Ajout et suppression de fonctions Liberty et Gestion des fonctions.

Utilisation d'une fonction à l'aide d'un programme à partir des applications

Les fonctions peuvent fournir des classes et des services aux applications.

Pour fournir des classes Java en vue de leur utilisation par une application, vous devez répertorier les packages de classes dans l'en-tête IBM-API-Package dans le manifeste de la fonction. Le fait de répertorier les packages de classes dans l'en-tête IBM-API-Package rend les classes visibles pour les chargeurs de classe des applications. La visibilité des packages d'API dépend du type de visibilité de l'API. Voir Spécification de packages d'API et de SPI pour un projet de fonction Liberty.

Pour que des services puissent être utilisés par des applications OSGi, vous devez les répertorier dans l'en-tête IBM-API-Service dans le manifeste de la fonction. Une fonction fournit des services OSGi pour que vous puissiez référencer ces services par programmation à partir de vos applications.

Les services doivent être enregistrés dans le registre de services OSGi pour que les applications (ou d'autres fonctions) puissent les localiser. Les applications OSGi et les autres fonctions peuvent procéder à une recherche directe dans le registre de services ou utiliser des capacités telles que Blueprint ou les services déclaratifs OSGi pour injecter leurs dépendances de service. Les applications Java EE localisent les services plutôt via JNDI ; dans Liberty, il existe une fédération du registre de services et de JNDI qui permet aux applications Java EE d'utiliser JNDI afin de localiser des services dans le registre de services. Pour plus d'informations, voir Utilisation du registre de services OSGi.

Exposition d'une fonction en tant qu'application Web

Pour présenter une fonction Liberty en tant qu'application Web, vous pouvez publier les bundles OSGi dans la fonction en tant que bundles d'application Web (WAB). En plus des en-têtes OSGi requis par un bundle, vous pouvez spécifier le chemin de contexte de l'application Web en utilisant l'en-tête Web-ContextPath.

Exemple :

Web-ContextPath: myWABapp
Bundle-ClassPath: WEB-INF/classes

Traitement et injection de configuration

L'un des avantages majeurs que présente l'utilisation de fonctions est qu'ils peuvent être configurés facilement par l'utilisateur dans le fichier server.xml (et les fichiers inclus). Les fichiers de configuration sont surveillés et analysés par le noyau Liberty et les ensembles résultants de propriétés peuvent être injectés dans le composant pertinent à chaque fois qu'ils changent.

La configuration Liberty est gérée par le service d'administration de la configuration OSGi dans le noyau et est accessible selon cette spécification. Des ensembles de propriétés de configuration sont identifiés par une identité persistante (PID) qui est utilisée pour associer l'élément dans le fichier server.xml au composant enregistré pour la réception des propriétés.

Par exemple, si vous enregistrez votre fonction auprès du service d'administration de la configuration avec l'identité persistante com.acme.console, un utilisateur peut spécifier la configuration suivante dans le fichier server.xml :
<com.acme.console color="blue" size="17"/>
And your feature will receive the properties:
  • color="blue"
  • size="17"

You can optionally provide metadata that describes your configuration properties by using OSGi Metatype descriptors. The use of descriptors causes your configuration metadata to be included in the configuration schema that is generated by Liberty and is used by the Developer Tools, so your configuration properties are automatically presented to application developers as they configure their server.

For more details on receiving and describing configuration properties, see Activation d'un service pour la réception des données de configuration.

Declarative Services in Liberty

Larger or more complex features often benefit from the use of OSGi Declarative Services (DS) to enable the feature to be composed of multiple services, and to manage the injection of dependencies and configuration properties. The use of DS allows lazy activation of services, deferring the loading of Java classes until the service is used, and ordering the activation of services based on dependencies. Most of the features in the Liberty product are managed by DS.

See also Composition de fonctions complexes à l'aide des services déclaratifs OSGi.


Icône indiquant le type de rubrique Rubrique de concept

Nom du fichier : cwlp_prod_ext.html