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.