Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step13]

Dans le billet précédant [step12] nous avons initialisé le client RCP qui affiche une liste statique de Users.

Dans ce billet nous allons faire appel au service UserService pour afficher la liste des Users. Un bouton Refresh Users permettra de rappeler le service UserService pour rafraîchir la liste des users :

Pour récupérer le service UserService dans la View, nous utiliserons 2 techniques possibles :

• un ServiceTracker classique OSGi.
• la déclaration XML Spring DM <osgi:reference ou nous montrerons comment passer par injection de dépendance le service UserService à la View.

Nous montrerons aussi comment créer des launch qui permettent de lancer :

• l’application RCP en tant que Client lourd (les services sont dans le même conteneur OSGi que l’application RCP).
• l’application RCP en tant que Client (Serveur) qui fait appel à un serveur pour utiliser les services.

Publicité

Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step11]

Dans le billet précédant [step10] nous avons mis en place Spring Remoting coté client (client avec/sans OSGi) qui fait appel (via Remoting HTTP Invoker) au service UserService exposé par l’application WEB classique dynaresume-server. Dans ce billet nous allons transformer l’application WEB classique en bundle OSGi.

Voici un schéma de ce que nous allons effectuer dans ce billet concernant le bundle OSGi org.dyanresume.remoting.exporter.http qui va remplacer l’application WEB classique dynaresume-server :

Ce schéma montre que nous allons :

• créer le bundle org.dyanresume.remoting.exporter.http qui s’occupe de :
  1. récupérer du registre de services OSGi, le service UserService qui a été enregistré par le bundle org.dynaresume.services.impl. Ceci s’effectue déclarativement dans le fichier XML Spring module-osgi-context.xml.
  2. exposer via Remoting HTTP Invoker le service UserService. Ceci s’effectue déclarativement dans le fichier XML Spring module-context.xml.
• enrichir la Target Platform avec les bundles Spring WEB Extender, Tomcat et/ou Jetty. Le serveur Tomcat/Jetty est un bundle OSGi. Il n’y a pas besoin d’installer un Tomcat ou Jetty classique.

On peut remarquer dans ce schéma que l’implémentation des services ne se trouvent pas dans l’application WEB. Il est récupéré via le registe de services OSGi. Ce procédé permet ainsi d’arrêter/lancer ou d’installer un nouveau bundle qui fournit l’implémentation des services sans arrêter l’application WEB.

Nous verrons ensuite comment utiliser nos différents bundles OSGi à travers des launch (Run) pour avoir :

• une architecture Client / Serveur. Le client appelle les services exportés par le bundle OSGi qui tourne dans un serveur de type :
  • Tomcat. Le launch OSGi DynaResume – Server Tomcat 5.5.launch permettra de déployer le bundle application WEB org.dyanresume.remoting.exporter.http dans un serveur Tomcat.
  • Jetty. Le launch OSGi DynaResume – Server Jetty 6.1.9.launch permettra de déployer le bundle application WEB org.dyanresume.remoting.exporter.http dans un serveur Jetty.

  Le launch OSGi DynaResume – Client (Server).launch permettra de lancer le client qui recherche le services via Remoting HTTP Invoker.

• une architecture Full Client. Tous les bundles client et services (API et Implémentation) se retrouvent dans le même conteneur OSGi. Le launch OSGi DynaResume – Full Client.launch mettra en œuvre cette architecture.

Vous pouvez télécharger org.dynaresume_step11-spring-osgi-remoting.zip qui contient les projets expliqués dans ce billet :

• tous les projets (bundles OSGi + Target Platform créés jusqu’à maintenant) expliqués dans le pré-requis.
• org.dyanresume.remoting.exporter.http, bundle de remoting serveur qui est l’application WEB qui expose les services via Remoting HTTP Invoker.
• le projet spring-target-platform est enrichi :
  • avec les bundles OSGi WEB, serveur Tomcat et Jetty.
  • les launch (Run) des diverses architectures.

Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step8]

Dans le billet précédant [step7] nous avons montré l’interêt d’utiliser Spring Dynamic Modules pour déclarer l’enregistrement des services via <osgi:service. Nous avons vu aussi que le bundle Spring Extender s’occupait de créer les org.springframework.context.ApplicationContext des bundles avec des fichiers de configuration XML de Spring.

Dans ce billet nous allons utiliser Spring Dynamic Modules pour déclarer la consommation du service UserService, effectuée dans le bundle client org.dynaresume.simpleosgiclient via <osgi:reference.

Pour rappel la consommation du service UserService s’effectue dans le bundle org.dynaresume.simpleosgiclient dans le thread FindAllUsersThread.

Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma montre que la consommation du service UserService s’effectue déclarativement avec <osgi:reference. Cette déclaration se trouve dans le fichier XML Spring META-INF/spring/module-osgi-context.xml du bundle client org.dynaresume.simpleosgiclient.

Nous verrons dans ce billet trois techniques pour récupérer l’instance UserService déclarée :

• ServiceTracker – ApplicationContext : cette solution consiste à récupérer via ServiceTracker l’instance ApplicationContext du fichier XML Spring spring/module-osgi-context.xml. La Thread FindAllUsersThread utilise ensuite cette instance pour récupérer le service.
• ApplicationContextAware : cette solution consiste à déclarer la Thread FindAllUsersThread dans un fichier XML Spring. La classe FindAllUsersThread implémente ApplicationContextAwarepour récupérer l’instance ApplicationContext du bundle. La Thread FindAllUsersThread utilise ensuite cette instance pour récupérer le service.
• UserService – Injection de dépendances : cette solution consiste à laisser Spring injecter le service dans le Thread FindAllUsersThread. Cette solution est la plus simple et est indépendante de l’API Spring.

Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step7]

Dans le billet précédant [step6] nous avons introduit Spring pour instancier le service UserServiceImpl déclarativement via un fichier XML Spring de configuration. Nous avons vu que dans un contexte OSGi, la mise en oeuvre de Spring n’est pas tâche facile. Dans ce billet nous allons utiliser Spring Dynamic Module et montrer que ce dernier simplifie grandement l’enregistrement/consommation des services OSGi qui s’effectue déclarativement et plus programmatiquement comme ce que nous avons fait jusqu’à maintenant.

Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma montre que :

• le bundle org.dynaresume.services.impl contient dans son répertoire MANIFEST-MF/spring 2 fichiers XML Spring :
  • module-context.xml qui est le fichier XML Spring de configuration des beans services (identique à celui du fichier applicationContext.xml du billet précédant).
  • module-osgi-context.xml qui est le fichier XML qui indique les services à enregistrer dans le registres de service OSGi. Dans notre cas, il indique que le bean userService déclaré dans le fichier module-context.xml doit être enregistré dans le registre de services OSGi.
• la classe ServicesFactory n’existe plus. L’enregistrement du service ne s’effectue plus programmatiquement dans l’Actvator du bundle org.dynaresume.services.impl mais déclarativement via le fichier module-osgi-context.xml
• le bundle org.dynaresume.services.impl ne fait plus référence aux bundles de Spring.
• la Target Platform est enrichie avec les bundles de Spring DM, notemment par celui du bundle Spring extender org.springframework.osgi.extender (spring-osgi-extender-1.2.0.jar) qui s’occupe de scruter tous les bundles de la Target Platform pour détecter pour chacun d’eux si ils contiennent des fichiers XML de configuration Spring (dans notre cas module-context.xml et module-osgi-context.xml). Pour chaque fichier XML Spring, le bundle Spring extender s’occupe de les charger et d’enregistrer les services déclarés dans le registre de services OSGi.

Dans ce billet nous montrerons comment enregistrer un service OSGi déclarativement via <osgi:service avec :

• XML bean : la déclaration s’effectue tout en XML.
• @Service annotation : la déclaration s’effectue via l’annotation Spring @Service.

Dans le prochain billet nous montrerons comment consommer déclarativement un service via <osgi:reference.