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

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.

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

• Sous le capot du clustering J2EE par Wang Yu
• Mise à l'échelle de vos applications Java EE par Wang Yu
• Mise à l'échelle de vos applications Java EE - Partie 2 par Wang Yu

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.

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.

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