Qu'est-ce que la vue locale / distante et sans interface dans EJB?
J'essaie de comprendre quel est le but et pourquoi nous avons besoin des différentes opinions des clients dans EJB. Quelqu'un pourrait-il essayer d'expliquer?
Vue client à distance
Lorsque votre EJB et ses clients seront dans un environnement distribué - ce qui signifie que les EJB et les clients résideront sur des machines virtuelles distinctes Java. Exemple: EJB hébergés sur un serveur d'applications WebSphere et servlets qui consomment des API EJB hébergées sur un serveur Tomcat.
Vue client locale
Ce n'est que lorsqu'il est garanti que les autres beans ou clients d'entreprise n'adresseront le bean que dans une seule machine virtuelle Java. 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 existe des différences. Dans ce cas, votre classe de bean n'est pas requise pour implémenter des interfaces de vue client. Toutes les méthodes publiques de la classe bean 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 recherche JNDI; mais, Java de la référence EJB est le type de classe bean plutôt que le type d'une interface locale. C'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 conditionné dans une application distincte de l'application d'entreprise. Ainsi, cela donne plus de flexibilité en termes de grain fin de vos composants.
Vous pouvez utiliser la vue client locale vs 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 reçoive des fonctionnalités flexibles dans les spécifications futures.
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 bean supplémentaires tels que le regroupement, les transactions gérées par conteneur, etc. Ainsi, un client ne peut pas instancier explicitement un EJB avec l'opérateur new. La vue client est fournie via certaines interfaces auxquelles le client aurait 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 prendre en charge 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'accès à un bean entreprise via la vue client locale doit uniquement être pris en charge pour les clients locaux empaquetés dans la même application que le bean entreprise qui fournit la vue client locale. Les implémentations conformes de cette spécification peuvent éventuellement prendre en charge l'accès à la vue client locale d'un bean entreprise à partir d'un client local empaqueté dans une application différente. Les exigences de configuration pour l'accès inter-applications à la vue client locale sont spécifiques au fournisseur et n'entrent pas dans le cadre de cette spécification. Les applications reposant sur l'accès inter-applications à la vue client locale ne sont pas portables.
La vue sans interface n'est qu'une fonctionnalité pratique qui permet à un bean d'exposer une vue client locale sans avoir à déclarer une interface distincte.