web-dev-qa-db-fra.com

EJB 3.1 @LocalBean vs pas d'annotation

Je comprends la différence entre la vue locale, la vue distante et la vue sans interface. Je ne comprends tout simplement pas quelle est la différence entre "pas de vue" (pas d'annotation) et pas de vue d'interface. Et aussi pourquoi devrais-je annoter mon interface avec @Local? Et si je n'annote pas l'interface du tout, y a-t-il une différence?

javajava-eeejb
73
VaclavDedik

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

  1. Le bean a une annotation @LocalBean -> le bean a une vue sans interface
  2. Le bean a une annotation @Local -> le bean a une vue locale
  3. Le bean a une annotation @Remote -> le bean a une vue distante
  4. Bean n'a pas d'annotations de vue, mais implémente directement une interface qui a une annotation @Local -> bean a une vue locale
  5. Bean n'a pas d'annotations de vue, mais implémente directement une interface qui a 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 -> bean n'a pas de vue d'interface

Donc, utiliser @LocalBean Et ne pas utiliser d'annotation du tout sont les deux moyens 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 d'interfaces.

Une partie de la raison @LocalBean Existe pour ajouter une vue sans interface à un bean qui possède également une vue d'interface. J'imagine que le scénario le plus important dans l'esprit des auteurs de spécifications était celui où vous avez un haricot comme celui-ci:

@Stateless
public class UserPreferences {
    public String getPreference(String preferenceName);
    public Map<String, String> getPreferences();
}

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

Ou, pour le regarder autrement, le @LocalBean Existe parce qu'il existe une vue telle qu'une vue sans interface et que l'option sans annotation existe sous la forme d'un raccourci pratique.

133
Tom Anderson
  • EJB distants: accessibles depuis des clients distants (clients s'exécutant sur une machine virtuelle différente, telle que les clients Swing ou JavaFX s'exécutant sur la machine utilisateur).
  • EJB locaux: l'accès ne peut être effectué qu'à partir d'autres "composants" s'exécutant sur la même machine virtuelle, par exemple. Frontaux Web, autres EJB
  • Vue sans interface: identique à Local mais sans spécifier l'interface professionnelle
  • Pas d'annotation: un simple POJO mais pas un EJB

Les vues locales/sans interface sont plus efficaces que les EJB distants, car les références aux objets peuvent être échangées.

15
Puce

Je pense que la confusion que vous/nous ressentons est le résultat d’une incompatibilité historique/rétrograde (pour ainsi dire). Je ne peux pas dicerner de différence (sauf que la spéc. Nécessite des implémentations pour créer une interface si on utilise la 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 passés par référence et la propagation de transaction et de sécurité. Toutefois, une vue sans interface ne nécessite pas d'interface distincte, c'est-à-dire que toutes les méthodes publiques de la classe de bean sont automatiquement exposées à l'appelant. Par défaut, tout bean de session contenant une clause vide implements et ne définissant aucune autre vue client locale ou distante expose une vue client sans interface.

Blog Oracle avant la sortie d'EJB 3.1

6
esej

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

Désormais, pour chaque type d'annotation, le conteneur génère différents types de mandataires avec différentes méthodes et fonctionnalités.

@LocalBean (Ou pas d'annotation) Votre objet proxy a:

  • setOptionalLocalIntfProxy()
  • getSerializableObjectFactory()

@Local Votre objet proxy utilise l'appel local et le type de com.Sun.proxy. Il a donc:

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

@Remote Votre objet Wrapper utilise un appel distant et il a:

  • readResolve()
  • writeReplace()
  • getStub()
  • getBusinessInterfaceName()
0
A. Parvini