Discussion :

[antoine.roux]

Bonjour,
Après m'en être éloigné quelques temps, je reviens vers Java pour un projet et je suis en train d'évaluer les différentes briques (frameworks, serveurs...) que je vais être amené à mettre en place. J'aurais besoin de vos conseils pour le choix de technos me permettant de facilement mettre en place un système de plugins.

Mon application va essentiellement exposer des web services. Il y aura aussi une interface web, mais celle-ci ne m'inquiète pas trop (ce n'est pas le coeur de l'application, juste le management).

Je voudrais qu'une grande partie des fonctionnalités de l'application puissent être modulables grâce à un système de plugins. Du point de vue de l'utilisation, l'utilisateur final aurait simplement à déposer le plugin dans un dossier sur le serveur, éventuellement à cliquer sur un bouton dans l'interface, et les nouveaux plugins seraient ajoutés. Ca peut se faire différemment, mais je souhaiterais que ça ne dépasse pas ce niveau de complexité. Cette action ajouterait de nouvelles fonctionnalités (de nouveaux web services, une nouvelle page à l'interface d'admin...). Idéalement, il n'y a pas de redémarrage de l'application ni de mise en production compliquée.

Enfin je voudrais garder cela léger dans le sens où je veux garder un temps de réponse faible lors d'un appel à un web service. Je préfèrerais donc éviter de sérialiser et désérialiser 50 fois mes appels de fonction pour faire communiquer les objets entre eux à l'intérieur de l'application

Par rapport à ce besoin, j'ai deux questions :

• Quel framework ou brique logicielle permettrait d'arriver à ce type de système de plugin ? J'ai entendu parler d'OSGi, j'ai vu aussi que Spring pourrait éventuellement aider...
• Une fois un plugin mis sur le serveur, comment l'application principale trouverait-elle le plugin (ou l'inverse) et comment communiqueraient-ils ensembles (RMI, web services...).

J'aurais simplement besoin d'être pointé sur les bonnes technos. J'ai déjà regardé pas mal de chose, mais le monde Java est dense et rempli de choix, ce n'est pas toujours facile de choisir :o)

[Patriarch24]

Si tu veux faire du déploiement de plugins à chaud, OSGI semble une bonne solution, qui permet une communication inter-plugins et avec l'application principale (beaucoup de serveur JEE 5 sont basé sur OSGI).

[antoine.roux]

Merci beaucoup pour ton retour.

Est-ce que tu as déjà utilisé OSGi ? De ce que j'ai vu ça a l'air un peu lourd à gérer. Comment l'as-tu ressenti ?
J'ai vu ce tutoriel qui a l'air vraiment intéressant : http://t-templier.developpez.com/tut...va/osgi/osgi1/

En termes d'implémentation d'OSGi, y en a-t-il une plus intéressante ? Par exemple, est-ce que Equinox peut être utilisée facilement pour autre chose qu'Eclipse ? Et y a-t-il une intégration à Eclipse ?

[djo.mos]

Salut,

Merci beaucoup pour ton retour.

Est-ce que tu as déjà utilisé OSGi ? De ce que j'ai vu ça a l'air un peu lourd à gérer.

Lourd ? je n'en serais pas si sûr avant de l'avoir testé
Non, c'est pas lourd du tout. Le problème majeur vient des bibliothèques qui ont été conçus sans OSGi dans l'esprit, et donc celle qui usent (et abusent) des Class.forName et co (principalement Hibernate).

En termes d'implémentation d'OSGi, y en a-t-il une plus intéressante ? Par exemple, est-ce que Equinox peut être utilisée facilement pour autre chose qu'Eclipse ? Et y a-t-il une intégration à Eclipse ?

Du moment qu'elles implémentent tous le même standard, je crois pas que ça ferait une grande différence.
Le critère du choix serait alors les extension s'il y'en a et la communauté. Equinox et Felix sont de bons candidats.

Pour ce qui est d'Equinox, je peux affirmer qu'il fonctionne très bien en dehors d'Eclipse.
Je l'ai utilisé comme noyau d'un serveur à base de Tomcat ou Jetty + Spring DM.

Une fois un plugin mis sur le serveur, comment l'application principale trouverait-elle le plugin (ou l'inverse) et comment communiqueraient-ils ensembles (RMI, web services...).

Une fois le plugin installé et démarré, il devient accessible par le reste de l'application. C'est à toi de coder quoi faire quand ça arrive, en ajoutant un listener sur les bundles au démarrage par exemple.

Avec Spring DM par exemple, tu peux même faire la même chose d'une façon transparente. En important la liste de toutes les implémentations d'une interfaces donnée (depuis le registre des services OSGi), Spring DM te retourne un proxy qui est mis à jour au fur et à mesure que des plugins sont ajoutés/enlevés.

Pour la communication inter bundles, y'a pas 36 chemins :
- Import/Export de packages
- Import/Export de services

Pas besoin du remoting en local, mais ça marche très bien pour des clients distants : On a un client Eclipse RCP qui invoque par remoting des traitements distants sur le serveur OSGi que j'ai décrit.

[antoine.roux]

Super ! Je n'avais pas vu que Spring DM existait. Je comptais partir sur Spring, donc ça s'intègre du coup encore plus simplement.
Du coup, quand un nouveau bundle arrive, l'application principale en est avertie et je peux éventuellement lancer des actions.

Je crois que j'ai toutes les infos qu'il me faut pour aller plus loin par moi-même. Merci beaucoup pour votre aide !

[lunatix]

moué., autant j'aime bien OSGI, autant la, tu va refaire ce qui existe deja dans un serveur d'application.

deployer des web services a la volée, utiliser une partie "metier" commune. en gros, c'est des ejbs et du jax-rs / jax-ws.

je suis pas sur que sur ce coup, ca soit une bonne idée que de tout refaire

[antoine.roux]

Merci beaucoup pour cette réaction, je vais considérer les EJB de plus près.
Cela dit, dans un premier temps j'ai préféré regarder les solutions autres que les EJB. D'une part, j'ai besoin de relativement peu de services fournis par les serveurs d'application. Du coup je trouvais dommage de m'emcombrer obligatoirement d'un serveur d'application complet alors qu'un Tomcat/Jetty et quelques composants qui vont bien (Axis...) pourraient suffire. D'autre part, un plugin au sens où je l'imagine correspond à plusieurs EJB. Donc je crains que ça complexifie le déploiement, sauf à utiliser une surcouche (comme au OSGi ?).
C'est pourquoi j'étais parti sur l'idée de commencer sans EJB, quitte à en rajouter plus tard si ça devient nécessaire.

Mais je fais peut-être fausse route dans mon raisonnement ? Il est clair que les EJB sont capables de se trouver facilement les uns les autres via JNDI.