J’essaie de comprendre quel est le but et pourquoi nous avons besoin des différentes vues du client dans EJB. Quelqu’un pourrait-il essayer d’expliquer?
Affichage client distant
Lorsque votre EJB et ses clients seront dans un environnement dissortingbué – 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 WebSphere Application Server et des servlets utilisant des API EJB hébergées sur un serveur Tomcat.
Vue du client local
Uniquement lorsqu’il est garanti que d’autres beans ou clients d’entreprise ne s’adresseront au bean qu’au sein d’une seule JVM. Par exemple, les EJB ainsi que les Servlets déployés sur le même serveur WebSphere.
Vue sans interface
Est presque identique à la vue du client local, mais il y a des différences. Votre classe de bean n’est pas nécessaire pour implémenter les interfaces de vue client dans ce cas. Toutes les méthodes publiques de la classe de haricot sont automatiquement exposées à l’appelant. no-interface view acquiert toujours une référence EJB – tout comme les vues locales ou distantes – soit par injection, soit par recherche JNDI; mais, le type Java de la référence EJB est le type de classe bean plutôt que le type d’une interface locale. Ceci est une commodité introduite dans le cadre de Java EE6.
Différence entre la vue client locale et la vue sans interface
En cas de vue sans interface, le client et le bean cible doivent être empaquetés dans la même application (EAR). En cas de vue locale, le client peut être empaqueté dans une application distincte de celle de l’entreprise. Donc, cela donne plus de flexibilité en termes de granularité de vos composants.
Vous pouvez utiliser la vue client locale ou la vue sans interface en fonction du scénario d’utilisation de votre API. Il est très probable que la vue sans interface reçoive des fonctionnalités flexibles dans les futures spécifications.
Raison
Historiquement ou non, un client souhaitant utiliser les services EJB était censé “rechercher” le bean sur le conteneur (avec certains contextes initiaux). En effet, toutes les invocations sont effectuées via une référence EJB spéciale (proxy) fournie par le conteneur. Cela permet au conteneur de fournir tous les services de beans supplémentaires tels que le pooling, les transactions gérées par conteneur, etc. Ainsi, un client ne peut pas instancier explicitement un EJB avec un new
opérateur. La vue client est fournie via certaines interfaces auxquelles le client aurait access. La réalisation du proxy côté serveur se fait sur la base de ces interfaces. Différentes vues client sont définies pour mettre en œuvre différents scénarios de déploiement, comme mentionné ci-dessus.
Conformément à la section 3.2.2 de la spécification EJB 3.1:
L’access à un bean enterprise via la vue client local doit uniquement être pris en charge pour les clients locaux empaquetés dans la même application que le bean enterprise qui fournit la vue client locale. Les implémentations conformes de cette spécification peuvent éventuellement prendre en charge l’access à la vue client locale d’un bean enterprise à partir d’un client local intégré dans une application différente. Les exigences de configuration pour l’access inter-applications à la vue client locale sont spécifiques au fournisseur et ne relèvent pas de la présente spécification. Les applications reposant sur un access inter-applications à la vue client locale ne sont pas portables.
La vue sans interface est simplement une fonction pratique qui permet à un bean d’exposer une vue client locale sans avoir à déclarer une interface distincte.