80 votes

Qu'est-ce qu'une vue locale/à distance et sans interface dans EJB ?

J'essaie de comprendre le but et la raison pour laquelle nous avons besoin des différentes vues du client dans EJB. Quelqu'un pourrait-il m'expliquer ?

127voto

ring bearer Points 8369

Vue du client distant

Lorsque votre EJB et ses clients se trouvent dans un environnement distribué - ce qui signifie que les EJB et les clients résideront sur des machines virtuelles Java distinctes. Exemple : des EJB hébergés sur un serveur d'application WebSphere et des servlets qui consomment des API d'EJB hébergés sur un serveur Tomcat.

Vue du client local

Uniquement lorsqu'il est garanti que les autres beans d'entreprise ou les clients ne s'adresseront au bean qu'au sein d'une seule JVM. Exemple, les EJBs ainsi que les Servlets déployés sur le même serveur WebSphere.

Vue sans interface

C'est presque la même chose que la vue client locale, mais il y a des différences. Votre classe de haricot n'est pas tenue d'implémenter des interfaces de vue client dans ce cas. Toutes les méthodes publiques de la classe de haricot sont automatiquement exposées à l'appelant. La vue sans interface acquiert toujours une référence EJB - tout comme les vues locales ou distantes - soit par injection, soit par consultation JNDI ; mais le type Java de la référence EJB est le type de la classe de haricot plutôt que le type d'une interface locale. Il s'agit d'une commodité introduite dans le cadre de Java EE6.

Différence entre la vue client local et la vue sans interface

En cas de vue sans interface, le client et le haricot cible doivent être empaquetés dans la même application (EAR). Dans le cas de la vue locale, le client peut être packagé dans une application distincte de l'application d'entreprise. Ainsi, cela donne plus de flexibilité en termes de finesse de vos composants.

Vous pouvez utiliser la vue client local ou la vue sans interface en fonction de votre scénario d'utilisation de l'API. Il est très probable que la vue sans interface recevra des fonctionnalités flexibles dans les futures spécifications.

Raison

Historiquement ou non, un client souhaitant utiliser les services EJB était censé "chercher" le bean dans le conteneur (avec certains contextes initiaux). En effet, toutes les invocations sont effectuées par le biais d'une référence EJB spéciale (proxy) fournie par le conteneur. Cela permet au conteneur de fournir tous les services supplémentaires du bean tels que le pooling, les transactions gérées par le conteneur, etc. Ainsi, un client ne peut pas explicitement instancier un EJB avec la fonction new opérateur. La vue du client est fournie via certaines interfaces auxquelles le client a accès. La réalisation du proxy côté serveur se fait sur la base de ces interfaces. Différentes vues client sont définies pour répondre aux différents scénarios de déploiement mentionnés ci-dessus.

6 votes

Je me demande si c'est vraiment le cas, qu'une vue client locale puisse être utilisée entre différentes applications d'entreprise. Dans la spécification EJB 3.2, section 3.2.2, il est indiqué que l'invocation de beans de différentes applications par le biais de vues client locales est spécifique au fournisseur et peut ne pas être prise en charge dans les conteneurs. Vous aviez un serveur d'applications spécifique en tête ?

0 votes

Qu'est-ce qui se passe ? Si nous "renouvelons" un EJB (cela peut arriver si le client et l'EJB restent dans la même application).

2 votes

Si vous utilisez new vous finissez par obtenir une nouvelle instance. C'est tout. Cette nouvelle instance ne bénéficiera d'aucun "support" de la part du conteneur en termes de pooling, de définition de son contexte, etc. Vous vous débrouillez tout seul.

3voto

Melad Ezzat Points 813

Conformément à la section 3.2.2 de la spécification EJB 3.1 :

L'accès à un module d'entreprise par la vue du client local n'est que uniquement pour les clients locaux intégrés dans la même application que le bean d'entreprise qui fournit la vue du client local. local. Les implémentations conformes à cette spécification peuvent facultativement prendre en charge l'accès à la vue client locale d'un enterprise bean à partir d'un d'un haricot d'entreprise à partir d'un client local empaqueté dans une application différente. Les exigences de configuration configuration requise pour l'accès inter-applications à la vue du client local sont spécifiques au fournisseur et sont en dehors de la portée de cette spécification. Les applications qui s'appuient sur l'accès inter-applications à la vue du client local locale ne sont pas portables.

La vue sans interface est juste une fonctionnalité pratique qui permet à un bean de d'exposer une vue client locale sans avoir à déclarer une interface séparée. séparée.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X