juillet
2008
Juste pour signaler que j’ai enfin réussi à mettre en place un prototype d’une application client/serveur full-OSGi où le server est un par tournant dans S2AP et le client est une application Eclipse RCP.
Le serveur et le client sont architecturés comme suit:
- Le serveur est un ensemble de bundles OSGi tournant sur S2AP (beta 8) composé comme suit:
- un bundle définissant un PAO
- un bundle définissant l’interface d’un DAO
- un bundle définissant une implémentation du DAO utilisant Spring JDBC, MySQL et Apache DBCP
- un bundle exposant ce DAO pour accès distant via Hessian/Spring
- Le client est une application à base d’Eclipse RCP (3.4) qui est constitué de :
- un bundle définissant un PAO (exactement le même que celui deployé dans le serveur)
- un bundle définissant l’interface d’un DAO (exactement le même que celui deployé dans le serveur)
- un bundle qui importe le DAO distant (toujours via Hessian/Spring) et l’expose en tant que Service OSGi (via Spring DM)
- un plug-in qui définit l’aplication RCP
- un plug-in qui ddéfinit une perspective et une vue affichant la liste des PAOs récupérés par le DAO distant tournant sur le serveur.
Ca m’a pris 2 jours (plus précisément 2 demi-journées et 1 nuit blanche), et même si le résultat est juste un proof-of-concept, sa mise en place etait vraiment douleureuse.
Je compte donc faire partager cette expérience en montrant, captures, explications et sources à l’appui, comment réaliser celà, enfin, si ça intéresse quelqu’un
Par contre, j’hésite encore sur le format : soit une série de billets dans ce blog, ou encore un article en bonne et due forme. Toutefois, ça risque de prendre du temps quand même …
Salut,
La principale source de complexité est du à la jeunesse de la technologie OSGi côté serveur : difficile de trouver de la doc la dessus.
J’ai bloqué principalement sur les points suivants:
– J’ai commencé par utiliser un DriverManagerDataSource pour l’accès à la BD côté serveur … or ça marche pas dans un environnement OSGi en donnant un message d’erreur totalement hors-sujet …
– L’intégration de Spring DM dans Eclipse, mais surtout la mise en place de DI pour les composant Eclipse (ViewPart).
– Déterminer précisément les jars nécessaires (côté client) pour que ça marche : il s’agit prncipalement de try-and-see.
Mais sinon, de par sa nature, le développement OSGi est plus rigoureux et structuré que le développement Java ordinaire, donc, ça prend plus de temps :
– le travail multi-projet : pour un exemple aussi simple que celui que j’ai réalisé, ça nécessite (enfin, pour être vraiement propre) 7 projets
– Question organisation : quoi mettre dans tel ou tel projet, et mêmle dans tel ou tel package, etc.
– Question packaging, et là, ça vient principalement de S2AP où un bug dans le tooling m’empehe de déployer u nPAR depuis Eclipse sur S2AP, m’obligeant à exporter cahcun des bundles en jar, puis les regrouper dans un par (zip en fait).
Idem, je suis tout à fait intéressé. La mise en oeuvre complexe (2 jours pour une application simple) est-elle un frein à une utilisation plus répandue d’OSGI côté serveur et côté client ?
Moi aussi je serais interessé par un article traitant de ce sujet. Merci en tout cas.
Ca m’intéresse aussi un article sur ce sujet. Plutôt sous forme d’article d’ailleurs pour éviter de devoir aller chercher toutes les informations un peu partout.
Ca fait plaisir
Faut juste que je finisse un article en attente depuis trop longtemps déjà, et puis, je vais voir comment je pourrais organiser celà (ce qui risqie d’être un peu délicat, donc, vos propositions sont plus que les bienvenues).
Je serais intéressé par ce genre d’article.