Gestion d'identifiants d'objets contenus dans une Map qui transite entre 2 bundles [Résolu]

[Laurent.B]

Bonjour,

Pour des problématiques de performances et de sérialisation, j'ai besoin de pouvoir faire transiter des maps d'objets de types simples, tels que des String, Long, ..., entre différents bundles.

Plusieurs objets étant stockés dans une Map, il est donc nécessaire de leur donner à chacun un identifiant, ce qui en général se matérialise par l'utilisation d'un objet de type String. Par exemple :

Code :

map.put("CAR_NAME", car.getName());

De fait, l'utilisation de la chaine "CAR_NAME", codée ici en dur, n'est bien entendu pas très indiquée, puisqu'au moindre besoin de refactoring ou de modification, il ne faudra surtout pas oublier de corriger partout cette chaine qui sert d'identifiant. C'est pourquoi, pour chaque identifiant d'élément de Map, j'ai besoin de créer une constante. Jusque-là rien de plus normal quand on veut éviter les bugs au runtime.

Donc, comme il est dans mon cas nécessaire de rester simple et d'éviter à tout prix de véhiculer par la Map, des objets plus complexes que des String, Long, ..., je dois me contenter de ce moyen pour faire transiter les données entre les bundles.

Concernant l'aspect "identifiant d'objet dans une Map", je ne pense pas qu'il y ait de moyen plus efficace. De fait, la difficulté qui en découle, est de parvenir à définir et à exploiter les identifiants, de manière découplée, entre le bundle producteur de la donnée et le bundle consommateur de la données.
En d'autres termes, il est facile de créer une constante String pour chaque identifiant d'objet de Map mais où place-t-on celles-ci, sans créer de dépendance forte d'un bundle vers un autre et sans créer de redondance ?

A cela je vois deux solutions :

1 - Créer un bundle spécifique qui embarquera seulement une classe avec uniquement les constantes, que les bundles producteur ou consommateur des données devront référencer afin de pouvoir exploiter celles-ci.

2 - Faire en sorte d'avoir physiquement et automatiquement la classe de constantes présente dans chacun des projets des bundles qui la nécessitent, via l'utilisation d'un outil de génération (lequel prendrait en entrée un fichier de définition des constantes). Ainsi, lors de l'exécution de la génération, la classe de constantes est créée puis dupliquée où cela est nécessaire. Le développeur peut alors utiliser les constantes dans le code du bundle sans avoir de problème de compilation.

Voilà, donc actuellement je suis plus pour partir sur la deuxième solution car je ne vois pas la première comme une solution satisfaisante (mais peut-être que je me trompe).

Je ne vois pas trop d'autre possibilité mais je serais content d'avoir des avis ou des suggestions.
Je débute avec OSGi donc il est possible que je ne sois pas encore tombé sur des informations intéressantes à ce sujet...

Pour information, le projet sur lequel je travaille a de fortes contraintes en terme de charge, de traitements temps réel, doit fonctionner dans un mode distribué, en asynchrone, via des WebServices, du JMS et sur 2 sites distincts. Donc les questions d'optimisation se posent dès à présent...

Merci d'avance pour votre aide.

[keulkeul]

Bonjour Laurent,

Dans mon cas, j'applique toujours la solution 1.

J'ai à chaque fois une bundle (plugin) API qui contient toutes les constantes de mon application et tous les API d'échanges (interface et classe pour DTO).

Par conséquent dans ton cas tu auras 3 bundles : bundleA, bundleB et bundleAPI.

De cette façon cette solution résout le problème de dépendance cyclique.

A noter que ce type de décomposition n'est pas nouveau dans le monde Java mais au moins elle est bien cadrée. C'est un pour cela qu'on se retrouve avec un gros sac de noeud dans certaines applications.

Mickael

[Laurent.B]

Le bundle dédié aux constantes et API reste donc préconisé, je le conçois.

Dans mon cas je ne crains pas les dépendances cycliques, c'est simplement que par rapport à des problématiques de déploiement de mises à jour, on est contraint à éviter toute dépendance entre bundles. Donc, les bundles producteur et consommateur de données ne se connaissent pas et la communication se fait par l'intermédiaire d'un Dispatcher (dans un autre bundle) car les requêtes sont transmises de manière asynchrone, ainsi que les résultats. Cela ne remet pas en cause la solution 1 mais par contre ça induit néanmoins une dépendance vers un autre bundle. C'est sans doute gérable via une feature a priori, non ?

La deuxième solution me paraissait de fait intéressante, dans la mesure où il n'y a pas de bundle supplémentaire à ajouter, et donc de dépendance à prendre en compte au moment du déploiement d'une mise à jour.

Bon, sans doute vaut-il mieux rester sur la solution 1 qui est beaucoup plus dans l'esprit de la modularisation...

Merci beaucoup Mickaël pour ton retour.

[azerr]

Bonjour Laurent,

Comme Mickael, je partirais sur la solution 1 (bundle API). Avec cette solution (compare a celle avec generation de code) ca te permettra d'utiliser Ctrl+Shift+G sur les constantes pour retrouver les classes Java consomateurs+producteurs.

Je me dis aussi que ces constantes font parties du modele (bundles qui contient tes Pojo Car, etc...). Au lieu de créer un nouveau bundle API, ces constantes Java pourrait être définis dans ce bundle modele?

Angelo

[Laurent.B]

Envoyé par azerr

ca te permettra d'utiliser Ctrl+Shift+G sur les constantes pour retrouver les classes Java consomateurs+producteurs.

En fait, ce n'est pas incompatible avec la façon dont je vois les choses... Les classes seraient générées dans des répertoires sources de toute manière.

Envoyé par azerr

Je me dis aussi que ces constantes font parties du modele (bundles qui contient tes Pojo Car, etc...). Au lieu de créer un nouveau bundle API, ces constantes Java pourrait être définis dans ce bundle modele?

Dans mon exemple, c'est effectivement une donnée de modèle, lequel se trouve dans un autre bundle. Sauf que ce n'est pas toujours le cas, j'ai aussi des paramètres qui ne sont pas liés directement au modèle et de fait, je ne peux pas les placer dans le même bundle car ça ne serait pas très logique.

Donc ok, vous penchez tous les deux pour un bundle intermédiaire.

Merci de ton intervention également Angelo.

[fxrobin]

Idem que les autres, je ferais un bundle dédié qui ne contiendrait que les constantes.

[Laurent.B]

Bon ben apparemment c'est une évidence donc la solution du bundle s'impose.

Merci fxrobin

[keulkeul]

Bonjour à tous,

Je me dis aussi que ces constantes font parties du modele (bundles qui contient tes Pojo Car, etc...). Au lieu de créer un nouveau bundle API, ces constantes Java pourrait être définis dans ce bundle modele?

Tout dépend de l'importance du projet, parfois j'ai 1 ou 2 bundle(s) en effet. Le bundle API me sert beaucoup pour définir les interfaces liées aux points d'extensions. Il arrive même que je l'appelle bundle framework.

Mickael