EJB - quand utiliser les interfaces distantes et / ou locales?

181

Je suis très nouveau sur Java EE et j'essaie de comprendre le concept d'interfaces locales et d'interfaces distantes. On m'a dit que l'un des grands avantages de Java EE est qu'il est facile à mettre à l'échelle (ce qui, je pense, signifie que vous pouvez déployer différents composants sur différents serveurs). Est-ce là qu'interviennent les interfaces distantes et locales? Êtes-vous censé utiliser des interfaces distantes si vous vous attendez à ce que votre application ait différents composants sur différents serveurs? Et utiliser les interfaces locales si votre application ne résidera que sur un serveur?

Si mes hypothèses ci-dessus sont correctes, comment feriez-vous pour choisir d'utiliser des interfaces locales ou distantes pour une nouvelle application, où vous n'êtes pas sûr du volume de trafic? Commencez par utiliser les interfaces locales et effectuez une mise à niveau progressive vers les interfaces distantes, le cas échéant?

Merci pour toute clarification et suggestions.

java  jakarta-ee  ejb 
— Brian DiCasa
source

Réponses:

186

Je suis très nouveau sur Java EE et j'essaie de comprendre le concept d'interfaces locales et d'interfaces distantes.

Dans les versions initiales de la spécification EJB, les EJB étaient "supposés" être des composants distants et la seule façon de les appeler était de faire un appel distant, en utilisant la sémantique RMI et toute la surcharge que cela implique (un appel réseau et une sérialisation d'objets pour chaque appel de méthode). Les clients EJB ont dû payer cette pénalité de performances même lorsqu'ils étaient colocalisés dans la même machine virtuelle avec le conteneur EJB.

Plus tard, Sun a réalisé que la plupart des applications métier ne distribuaient en fait pas les EJB sur un niveau différent et ils ont corrigé la spécification (dans EJB 2.0) en introduisant le concept d'interfaces locales afin que les clients colocalisés dans la même machine virtuelle avec le conteneur EJB puissent appeler des EJB en utilisant invocation directe de méthode, contournant totalement la sémantique RMI (et la surcharge associée).

On m'a dit que l'un des grands avantages de Java EE est qu'il est facile à mettre à l'échelle (ce qui, je pense, signifie que vous pouvez déployer différents composants sur différents serveurs)

Java EE peut évoluer, mais cela ne signifie pas nécessairement distribuer des composants. Vous pouvez exécuter une application Web + EJB sur un cluster sans séparer le niveau Web et le niveau EJB.

Êtes-vous censé utiliser des interfaces distantes si vous vous attendez à ce que votre application ait différents composants sur différents serveurs? Et utiliser les interfaces locales si votre application ne résidera que sur un serveur?

Je le formulerais comme ceci: utilisez des interfaces distantes si le client n'est pas dans la même JVM (cela ne signifie pas utiliser un seul serveur / JVM).

(...) Commencez par utiliser les interfaces locales et effectuez une mise à niveau progressive vers les interfaces distantes le cas échéant?

Je commencerais probablement par utiliser les interfaces locales. Et comme déjà indiqué, le passage aux interfaces distantes n'est pas toujours obligatoire (vous pouvez regrouper une structure colocalisée ).

Je suggère de vérifier les ressources mentionnées ci-dessous (les 2 premières sont assez anciennes mais toujours pertinentes, les 2 autres sont plus récentes).

Ressources

— Pascal Thivent
source
2
J'ai trouvé cette question intéressante. Qu'entendez-vous par "le passage aux interfaces distantes n'est pas absolument obligatoire"? Cela signifie-t-il que lorsque vous ajoutez un nouveau client en dehors de la même JVM, vous n'avez pas besoin de créer une interface distante?
— mohamida
2
@Josek Merci, heureux que vous l'aimiez @mohamida J'ai fait un léger changement dans le libellé. Ce que je voulais dire, c'est que vous pouvez regrouper une structure colocalisée.
— Pascal Thivent
1
Merci pour la réponse et les ressources supplémentaires, elles ont été très utiles. Il semble qu'il existe plusieurs façons de mettre à l'échelle une application Web ... c'est-à-dire de distribuer les composants (ce que je considère comme une division des différents niveaux sur différentes JVM?) Ou d'utiliser l'équilibrage de charge (ce qui consisterait à avoir l'ensemble de l'application sur nombreux serveurs?) et je suppose que vous pourriez utiliser une combinaison des deux? Connaissez-vous par hasard de bons livres sur ce sujet? Merci encore!
— Brian DiCasa
2
@Brian It seems like there are a couple ways of scaling a web application (...) and I suppose you could use a combination of both?Oui, c'est exactement ça. Do you, by chance know of good books on this topic?Malheureusement, non, je ne connais pas la ressource absolue "ZE", s'il y en a une. J'ai cependant ajouté plus de ressources avec quelques références.
— Pascal Thivent
le premier lien de ressources est mort
— Viacheslav Dobromyslov
48

Bien que je sois d'accord avec la plupart de ce qui est écrit ci-dessus, je voudrais affiner un peu les idées «comment démarrer».

Je vous suggère de ne jamais programmer directement sur les interfaces EJB dans votre code. Utilisez toujours une interface régulière, orientée métier, programmez-la (c'est-à-dire faites appel à vos méthodes d'appels de code sur l'interface métier) et fournissez le code «glue» EJB comme une implémentation enfichable. Votre programme doit être axé sur la logique métier et non sur les détails d'implémentation tels que l'EJB.

De cette façon, vous pouvez facilement basculer entre les implémentations distantes et locales - et si vous utilisez un conteneur IoC tel que Spring, vous pouvez le faire uniquement par configuration.

Une note spéciale sur le passage du local au distant: notez qu'il existe quelques différences sémantiques entre les deux. Par exemple, l'appel d'une méthode EJB via son «interface distante» entraîne la transmission d'arguments par valeur, tandis que l'appel via «l'interface locale» entraîne la transmission d'arguments par référence. C'est une différence majeure ; donc si vous "commencez par local", assurez-vous de concevoir votre système de manière à ce qu'il prenne également en compte la sémantique "distante".

Si votre conception repose sur des méthodes EJB changeant les objets transmis, alors il serait difficile pour vous de "passer à distant" plus tard; peut-être même impossible.

Bonne chance.

— Isaac
source
2
sonne comme une autre raison de minimiser la mutabilité par java efficace. cela aiderait-il à la flexibilité de "passer à distance" pour l'interface de type RMI avec les EJB?
— Thufir
20

Selon EJB Spec 3.2, un EJB peut être local ou distant . Une interface métier ne peut pas être à la fois locale et distante.

@Local Les beans annotés ne sont accessibles que s'ils se trouvent dans la même application.

@Remote Les beans annotés sont accessibles sur différentes applications, résidant dans différents jvms ou sur des serveurs d'applications.

Les choses importantes à garder à l'esprit sont donc:

  1. Si une classe de bean contient l' @Remoteannotation, toutes les interfaces implémentées doivent être distantes.
  2. Si une classe de bean ne contient aucune annotation ou si l' @Localannotation est spécifiée, alors toutes les interfaces implémentées sont supposées être locales.
  3. Toute interface explicitement définie pour un bean qui ne contient aucune interface doit être déclarée comme @Local.
  4. La version EJB 3.2 tend à fournir plus de granularité pour les situations où les interfaces locales et distantes doivent être explicitement définies.
— Pritam Banerjee
source
1
Question: Pouvez-vous utiliser @Localpour appeler un EJB dans une autre application (JAR, WAR, EAR), mais la même JVM?
— Carlitos Way
@PritamBanerjee Toute idée sur le Carlitos Wa, je suis également confronté au même problème. EJB est dans un cluster différent et l'application de servlet client est dans un autre.
— Govi S
@GovindaSakhare Je n'en suis pas tout à fait sûr. Désolé :(
— Pritam Banerjee
7

Cela peut répondre à vos préoccupations:

En règle générale, votre Enterprise Java Bean aura besoin d'une vue client à distance dans les cas où vous prévoyez d'utiliser le bean dans des environnements distribués. Plus précisément, ce sont les cas où le client qui travaillera avec lui sera dans une autre machine virtuelle Java (JVM). Dans le cas d'une vue client à distance, l'appel de n'importe quelle méthode à partir de l'interface du domicile distant et / ou de l'interface du composant distant sera géré via l'invocation de méthode distante (RMI).

Un EJB ne peut utiliser la vue client locale que s'il est vraiment garanti que d'autres beans ou clients d'entreprise n'adresseront le bean que dans une seule JVM. Si tel est le cas, cet accès sera effectué avec des appels de méthode directs, au lieu de RMI.

Source: http://www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page=last&x-showcontent=text

— Abdulaziz
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.