EJB 3.1 @LocalBean vs aucune annotation

Je comprends la différence entre la vue locale, la vue à distance et la vue sans interface. Je ne comprends tout simplement pas quelle est la différence entre une vue “sans vue” (sans annotation) et une vue sans interface. Et aussi pourquoi devrais-je annoter mon interface avec @Local ? Et si je n’annotais pas l’interface du tout, y a-t-il une différence?

Les règles sont (de mémoire):

  1. Bean a une annotation @LocalBean -> le bean a une vue sans interface
  2. Bean a une annotation @Local -> bean a une vue locale
  3. Bean a une annotation @Remote -> bean a une vue distante
  4. Bean n’a pas d’annotations de vue, mais implémente directement une interface avec une annotation @Local -> bean a une vue locale
  5. Bean n’a pas d’annotations de vue, mais implémente directement une interface avec une annotation @Remote -> bean a une vue distante
  6. Bean n’a pas d’annotations de vue, mais implémente directement une interface sans annotations de vue -> bean a une vue locale
  7. Bean n’a pas d’annotations de vue et n’implémente aucune interface -> le bean a une vue sans interface

Donc, utiliser @LocalBean et ne pas utiliser d’annotation du tout sont les deux manières d’obtenir une vue sans interface. Si vous voulez simplement une vue sans interface, la chose la plus simple est de ne pas annoter. Pourvu que vous n’implémentiez pas non plus d’interfaces.

Une partie de la raison @LocalBean laquelle @LocalBean existe pour append une vue sans interface à un bean qui a également une vue d’interface. J’imagine que le scénario le plus important dans l’esprit des auteurs était celui où l’on a un haricot comme:

 @Stateless public class UserPreferences { public Ssortingng getPreference(Ssortingng preferenceName); public Map getPreferences(); } 

Où vous souhaitez exposer les deux méthodes localement, mais uniquement les getPreferences() à grain plus grossier à distance. Vous pouvez le faire en déclarant une interface distante avec cette méthode, puis en @LocalBean simplement @LocalBean sur la classe du bean. Sans elle, il vous faudrait écrire une interface locale inutile pour simplement exposer les deux méthodes localement.

Ou, pour le regarder d’une autre manière, le @LocalBean existe car il existe une vue sans interface, et l’option sans annotation existe en tant que raccourci pratique.

  • EJB distants: accessibles à partir de clients distants (clients exécutés sur une machine virtuelle Java différente, tels que les clients Swing ou JavaFX exécutés sur la machine utilisateur)
  • EJB locaux: ne peuvent être accessibles qu’à partir d’autres “composants” s’exécutant sur la même JVM, par exemple, des serveurs Web frontaux, d’autres EJB
  • Vue sans interface: identique à Local mais sans spécification de l’interface métier
  • Pas d’annotation: un simple POJO mais pas un EJB

Les vues locales / non-interface sont plus efficaces que les EJB distants, car les références aux objects peuvent être transmises.

Je pense que la confusion que vous / nous ressentons est le résultat d’une histoire / compatibilité avec le passé (pour ainsi dire). Je ne peux distinguer aucune différence (sauf que la spécification nécessite des implémentations pour créer une interface si nous utilisons une vue locale)

La vue sans interface a le même comportement que la vue locale EJB 3.0. Par exemple, elle prend en charge des fonctionnalités telles que la sémantique des appels et la propagation des transactions et de la sécurité. Cependant, une vue sans interface ne nécessite pas d’interface distincte, c’est-à-dire que toutes les méthodes publiques de la classe du bean sont automatiquement exposées à l’appelant. Par défaut, tout bean de session comportant une clause implémentation vide et ne définissant aucune autre vue client locale ou distante, expose une vue client sans interface.

Oracle Blog avant la sortie d’EJB 3.1

Si vous êtes intéressé par plus de détails techniques, laissez-moi vous dire ce qui se passe vraiment … Vous n’avez pas directement access à un object EJB, cela signifie que vous n’avez pas la référence (adresse) de l’object EJB réel. Lorsque vous recherchez ou injectez votre EJB, le conteneur fournit un object en tant que client pour cet EJB (nous pouvons appeler proxy ou Wrapper) et vous appelez vos méthodes professionnelles sur cet object proxy. (C’est pourquoi vous ne devriez pas utiliser un nouveau mot clé pour créer un object de classe EJB)

Maintenant, pour chaque type d’annotation, le conteneur génère différents types de proxy avec différentes méthodes et fonctionnalités.

@LocalBean (ou pas d’annotation) Votre object proxy a:

  • setOptionalLocalIntfProxy()
  • getSerializableObjectFactory()

@Local Votre object proxy utilise l’appel local et le type de com.sun.proxy Il a donc:

  • getSerializableObjectFactory()
  • isProxyClass()
  • getProxyClass()
  • getInvocationHandler()
  • newProxyInstance()

@Remote object @Remote You Wrapper utilise l’appel à distance et il a:

  • readResolve()
  • writeReplace()
  • getStub()
  • getBusinessInterfaceName()