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

Dans le billet précédant [step18] nous avons mis en place JPA avec LocalContainerEntityManagerFactoryBean en utilisant JPA/Hibernate et JPA/EclipseLink avec les 2 bases de données H2 et Derby dans un contexte NON OSGi. Dans ce billet nous allons mettre en place JPA dans un contexte OSGi avec LocalContainerEntityManagerFactoryBean en utilisant JPA/Hibernate et JPA/EclipseLink avec les 2 bases de données H2 et Derby.

Notre classe UserServiceImpl du bundle org.dynaresume.services.impl utilisera une interface DAO UserDAO qui dans notre cas est implémenté en JPA. L’implémentation de la DAO UserDAO est renseigné à la classe UserServiceImpl via le mécanisme d’injection de Dépendances en utilisant le registre de services OSGi :

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.

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 [step10]

Dans le billet précédant [step9] nous avons mis en place Spring Remoting, coté serveur dans l’application WEB dynaresume-server. Dans ce billet nous allons mettre en place Spring Remoting coté client dans un Client sans OSGi et un Client OSGi.

Voici un schéma de ce que nous allons effectuer dans ce billet concernant le client OSGi :

Ce schéma montre que nous allons :

• créer le bundle org.dyanresume.remoting.importer.http qui s’occupe de :
  1. récupérer le service UserService exposé par le serveur à l’aide HtppInvoker de Spring remoting. Ceci s’effectue déclarativement dans le fichier XML Spring module-context.xml.
  2. enregistrer dans le registre de services OSGi le service UserService récupéré du serveur. Ceci s’effectue déclarativement dans le fichier XML Spring module-osgi-context.xml.
• créer le fragment org.dynaresume.config.remoting.importer.http qui stocke le fichier client.properties qui permet de configurer les paramètres de connexion au serveur.
• enrichir la Target Platform avec le bundle Spring WEB.

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.

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

Dans le billet précédant [step5] nous avons mis en place les 3 couches Client/Services/Domain découpées en plusieurs Bundles :

• Couche Domain gérée par le bundle org.dynaresume.domain.
• Couche Services gérée par les 2 bundles :
  • API Services org.dynaresume.services qui contient l’interface UserService.
  • Implémentation Services org.dynaresume.services.impl qui exporte UserServiceImpl, l’implémentation de l’interface UserService dans le registre de services OSGi.
• Couche Client qui consomme via le registre de services OSGi, le service UserServiceImpl, géré par le bundle org.dynaresume.simpleosgiclient.

Dans ce billet et le prochain nous allons montrer pas à pas l’interêt d’utiliser Spring Dynamic Module en nous concentrant sur le bundle org.dynaresume.services.impl qui a pour rôle d’enregistrer une instance UserServiceImpl dans le registre de services OSGi. Dans ce billet nous allons utiliser basiquement Spring . Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma montre que :

• La classe ServicesFactory est basée sur un fichier XML Spring applicationContext.xml qui permet de déclarer la classe UserServiceImpl. C’est le conteneur Spring qui s’occupera d’instancier cette classe. Spring joue le rôle dans notre cas de factory de services.
• la Target Platform doit être enrichie pour ajouter tous les bundles Spring.
• le bundle org.dynaresume.services.impl fera référence aux bundle Spring de la Target Platform via les dépendances Import Package.

Le but de ce billet est d’introduire Spring en montrant comment déclarer l’instanciation du service UserServiceImpl via Spring :

• dans un contexte non OSGi. Nous repartirons des projets du billet [step1] et notre factory de services ServicesFactory se basera sur Spring. Nous montrerons qu’il existe 2 manières de déclarer le service UserServiceImpl avec Spring:
  • XML bean : la déclaration s’effectue tout en XML.
  • @Service annotation : la déclaration s’effectue via l’annotation Spring @Service.

  Nous verrons comment configurer Log4j dans un contexte non OSGi.

• dans un contexte OSGi. Nous partirons des projets du billet [step5] et notre factory de services ServicesFactory se basera sur Spring. Nous tenterons d’utiliser les 2 modes de déclarations en mettant en évidence toutes les problématiques de mise en oeuvre de Spring dans un contexte OSGi (problème lié au classloader). Attention, ici nous n’utiliserons pas encore Spring DM, mais uniquement Spring Framework et dans le prochain billet nous verrons comment Spring DM simplifie le code expliqué dans cette section.

  Nous verrons comment configurer Log4j dans un contexte OSGi via un Fragment OSGi.

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

Dans le billet précédant [step1] nous avons mis en place les 3 couches Client/Services/Domaine dans 3 projets Java qui font références entre eux avec le classique Java Build Path. Nous avons vu que ce type de dépendance engendrait les 2 problèmes de classes non protégées et de ClassLoader. Dans ce billet nous allons créer et lancer notre premier Bundle OSGi, autrement dit nous allons transformer le projet Java org.dynaresume.domain en Bundle OSGi et préparer l’environnement OSGI (Target Platform). Dans le prochain billet nous transformerons les 2 autres projets Java en Bundle OSGi et verrons comment OSGi règle les 2 problèmes cités en introduction.

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

Ce schéma met en évidence plusieurs notions :

• Bundle OSGi : le projet Java org.dynaresume.domain devient un Bundle OSGi qui est un projet Eclipse Plug-in.
• Target Platform : ensemble de Bundles OSGi (JARs) nécéssaires au Bundle OSGi que nous créons dans le workspace Eclipse. Dans notre cas nous allons dépendre du Bundle OSGi org.eclipse.osgi qui contient l’API OSGi.
• Conteneur OSGi (Equinox) : hébérge et orchestre les Bundles OSGi (gère leur cycle de vie) provenant de notre workspace Eclipse et de la Target Platform. Nous utiliserons Equinox qui est celui par défaut utilisé par Eclipse.
• Dependances : les dépendances entre les Bundle OSGi s’effectuent via le fichier META-INF/MANIFEST.MF et plus par le Java Build Path classique.
• BundleActivator (classe Activator) : permet d’éxecuter du code lors du lancement/arrêt du Bundle.

Nous nous appuierons sur l’ensemble de plugins PDE (Plug-in Development Environment) qui permet de créer des Plug-ins Eclipse mais aussi des Bundles OSGI (un Plug-in Eclipse est en fait un Bundle OSGI).

Vous pouvez télécharger les projets org.dynaresume_step2.zip présentés dans ce billet.