[EJB3] Intérêt du Pattern Service Locator ?

Intérêt du Pattern Service Locator ?

Bonjour,

je travail sur une migration d'une application en EJB2 vers EJB3.
Cette application un mis en place le Design Pattern Service Locator.

Dans le cadre des Ejb2 je trouve ce pattern intéressant, en revanche pour les ejb3 je ne vois plus trop son utilité.

Je me demande s'il était intéressant de le supprimer ?

qu'en pensez vous ?
Avez vous déjà rencontré ce problème ?

merci

L'apparition des annotations en EJB3(@EJB, @resource) qui permet l'injection des ressources et services de manière transparente, et la disparition des "EJB Home" suppriment totalement l'interet du ServiceLocator.

merci, c'est justement ce que je pensais, mais il n'y a donc vraiment aucun avantage particulier à le mettre en place pour les ejb3 ?

pour le moment je fais comme si on allait le conserver mais ça alourdi les ejb3 du coup car on est obliger de référencer les beans dans le ServiceLocator.xml ce qui à mon gout fait perdre tout l'intérêt des annotations.

j'ai trouvé cet article qui m'interroge beaucoup, c'est en anglais je ne suis donc pas sur d'avoir tout saisi

http://www.javalobby.org/articles/service-locator/

qu'en pensez vous ?
Cet article confronte justement les ejb3 et le ServiceLocator, et l'auteur nuance le fait que ce pattern reste intéressant même pour les ejb3.

Donc je suis face à un dilemme qui nécessite réflexion :(

merci

Pour synthétiser :
Le ServiceLocator est un pattern qui sert à contourner certain défauts lié à l'usage d'un annuaire JNDI.
Typiquement dans une appli J2EE, les EJB, les datasources sont référencés dans cet annuaire et donc un utilisateur qui souhaite utiliser ces composants, historiquement n'avait pas d'autre choix d'interroger explicitement cet annuaire.
Cela avait quelques défauts :
1) Chaque serveur d'appli a une politique de nommage différent pour les composants de son annuaire donc récupérer un objet dans un annuaire de weblogic est répertorié différemment que dans un annuaire JBOSS.
2) En EJB 2.1 et avant, pour qu'un client puissent avoir une référence d'EJB, il fallait initialiser le context JNDI, demander systématiquement un Home à JNDI en connaissant le nom de l'EJB, faire des cast bizarres (narrow) dans le cas des Remote et ensuite appeler le create pour avoir l'instance donc à priori beaucoup de lignes code avec toute la panoplie de gestion d'exception.
3) L'appel d'un objet dans un annuaire n'est pas typé statiquement donc il y a des risques de class CastException lors de l'exécution du programme.
4) Un annuaire JNDI est un composant distant donc ses appels sont reseau et donc ont un "coût".

- Les problèmes de nommages de composants selon les serveurs sont en partie réglés car dans les descripteurs de déploiement EJB, il est possible d'indiquer un nom logique pour une resource. Ensuite le code java utilise ce nom logique qui ne change jamais.
C'est juste le nommage physique qui sera changé en cas de besoin mais c'est transparent dans le code.
Cela introduit tout de même une limitation qui est que pour accéder à une ressource, il faut passer par l'EJBContext.
Ce n'est pas un problème dans un EJB mais c'est plus problématique dans une classe "Helper" et dans ce cas il faut donner à cette classe une instance d'EJBContext depuis l'EJB.
Au final on peut se retrouver avec beaucoup de classe Helper/Pojo/Delegate qui dépendent de L'EJB context.
- Le coté verbeux du code avant un appel EJB est totalement réglé pour certain composants grâce à l'injection depuis les Annotations. Par contre il demeure en partie pour d'autre type d'objet non "managé".
- Le problème numéro 3 est un faux problème quand on est un peu organisé
- Concernant la pénalisation des performances lors d'un appel à l'annuaire JNDI je demande à voir ce qu'il en est concrètement en 2008.
Les machines sont plus rapides, ont plus de mémoire, les implémentations de serveur J2EE sont mieux optimisés, et parallèlement les architectes suggèrent parfois de nombreuses couches (pas toujours utiles) pour réaliser les applications.
Entre l'instrumentation de code, le mapping objet-relationnel, les archis distribuées, les empilements de couches je ne suis pas sure que l'usage dans certain cas d'un annu JNDI plombent les performances.
En faisant un test, récupérer une implémentation d'interface d'un EJB local en passant explicitement par JNDI prend sur mon serveur JBoss sur mon PC de bureau 0 millisecondes.
Dans le cas des Remote c'est parfois un peu plus long et encore si on se retrouve dans un cas d'appli de stress réclamant un grand nombre d'EJB en simultané on sera beaucoup plus limité par la capacité du pool d'EJB que par la latence d'un appel JNDI.

En conclusion je pense que le ServiceLocator ne doit pas être systématiquement utilisé en EJB3.
Si on accès à l'injection par Annotation c'est même un Anti pattern d'utiliser le pattern ServiceLocator.
Dans les autres cas je ne suis pas non plus convaincu de l'usage du ServiceLocator tel qu'il est décrit historiquement par Sun.

En EJB3 une instance d'EJB sans injection se réupère comme suit :
Code:

1 2 3 4 Context ctx = new InitialContext(); // Eventuellement on peut passer une map ou appeler d'autres méthodes avant ou après pour finir l'initialisation du context dans le cas des remotes. MonEJBRemote businessEjb = (MonEJBRemote) ctx.lookup("MonEJBBean/remote"); // le nommage de l'EJB dans l'annuaire est totalement standardisé donc portable entre serveur d'appli. /* Plus les catch des Exceptions */
Donc c'est très trivial. Si on souhaite que le code client n'ait pas à s'occuper de Context JNDI.
Il suffit de faire un ServiceLocator "Light"
Code:

1 2 3 MonServiceLocator locator = MonServiceLocator.getInstance(); MonEJBRemote businessEjb = (MonEJBRemote) locator.getService("MonEJBBean/remote");
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 class MonServiceLocator { // code de singleton private MonServiceLocator() { ctx = new InitialContext(); } public Object getService(String normalizedJndiName){ Object res = null; try { Object res = ctx.lookup(normalizedJndiName); }catch(Exception e){ .... } return res; } }

Merci beaucoup pour cette synthèse, cela conforte ce que je pensais.
Je te remercie pour ton avis.

je pense que je vais faire sans ce Service Locator mais tout de même créer une couche entre l'appel jndi et mon BusinessAdapter.

Car mon BusinessAdapter faisait appel à un ServiceLocator auparavant et comme on ne veut pas que le BusinessAdapter se charge du lookup je vais donc mettre en place une facade entre l'Adapter et l'appel JNDI.

merci