EJB ' s - quand utiliser des interfaces distantes ou locales ?

Question

Je suis très nouveau pour Java EE et j'essaie de comprendre le concept d'interfaces Locales et de l'interface de commande à Distance. J'ai été dit que l'un des gros avantages de Java EE est qu'il est facile de l'échelle (qui, je crois, signifie que vous pouvez déployer des différents composants sur des serveurs différents). Est que si la Distance et les interfaces Locales? Êtes-vous censé utiliser les interfaces Distantes si vous attendez de votre application afin d'avoir différents composants sur des serveurs différents? Et utiliser les interfaces Locales si votre application ne va résider sur un serveur?

Si mes hypothèses ci-dessus sont correctes, comment vous y prendriez-vous choisir d'utiliser le Local ou à Distance interfaces pour une nouvelle application, où vous n'êtes pas certain de ce que le volume de trafic? Commencer en utilisant les interfaces Locales, et peu à peu mise à niveau à l'interface de commande à Distance le cas échéant?

Merci pour les précisions et suggestions.

Answer 1

Je suis très nouveau pour Java EE et j'essaie de comprendre le concept d'interfaces Locales et de l'interface de commande à Distance.

Dans les premières versions de la spécification EJB, Ejb ont été "supposé" être à distance des composants et la seule façon de les invoquer était de faire un appel à distance, à l'aide de RMI de la sémantique et de tous les frais généraux qu'il implique (un appel du réseau et de la sérialisation d'un objet pour chaque appel de méthode). EJB les clients devaient payer cette pénalité de performances, même lorsque placés dans la même machine virtuelle avec le conteneur d'EJB.

Plus tard, Sun a réalisé la plupart des applications d'entreprise n'ont pas la distribution des Ejb sur un autre niveau et ils ont résolu le spec (EJB 2.0) par l'introduction du concept des interfaces Locales afin que les clients placés dans la même machine virtuelle avec le conteneur d'EJB peut appeler Ejb en utilisant la méthode directe de l'invocation, totalement ignorant RMI sémantique (et les frais généraux associés).

J'ai été dit que l'un des gros avantages de Java EE est qu'il est facile de l'échelle (qui, je crois, signifie que vous pouvez déployer des différents composants sur différents serveurs)

Java EE peut évoluer, mais ce n'est pas nécessairement un gage de la distribution de composants. Vous pouvez exécuter un site Web+application EJB sur un cluster sans les séparer de la couche Web et EJB niveau.

Êtes-vous censé utiliser les interfaces Distantes si vous attendez de votre application afin d'avoir différents composants sur des serveurs différents? Et utiliser les interfaces Locales si votre application ne va résider sur un serveur?

Je voudrais phrase comme ceci: utiliser l'interface de commande à distance, si le client ne sont pas dans la même JVM (cela ne veux pas utiliser un seul serveur/JVM).

(...) Commencer en utilisant les interfaces Locales, et peu à peu mise à niveau à l'interface de commande à Distance le cas échéant?

Je serais probablement commencer en utilisant les interfaces Locales. Et comme déjà mentionné, la commutation de l'interface de commande à distance n'est pas toujours obligatoire (vous pouvez le cluster a regroupé de la structure).

Je suggère de vérifier les ressources mentionnées ci-dessous (les 2 premiers sont assez vieux mais toujours d'actualité, les 2 autres sont plus récents).

Ressources

• EJB 2.0 Spécification de la Version Revue par Tyler Jewell
• Sous le Capot de J2EE Clustering 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

Answer 2

Alors que je suis d'accord avec la plupart de ce qui est écrit ci-dessus, je voudrais affiner le "comment démarrer" idées un peu.

Ma suggestion pour vous est de ne jamais jamais programme directement à des interfaces de l'EJB dans votre code. Utilisez toujours une base régulière, interface orientée métier, programme pour elle (ce qui signifie, vous avez votre code d'appeler les méthodes de l'interface orientée métier) et de fournir de l'EJB "colle" code enfichables à la mise en œuvre. Votre programme doit être axé sur la logique métier, et non pas sur des détails de mise en œuvre tels que EJB.

De cette façon, vous pouvez facilement basculer entre la télécommande et les mises en œuvre locales - et si vous utilisez un conteneur IoC comme le Printemps, vous pouvez le faire par le biais de la configuration.

Une note spéciale sur le changement de local à distance: à noter qu'il existe quelques différences sémantiques entre les deux. Par exemple, l'appel d'un EJB de la méthode par l'intermédiaire de son "interface distante" résultats dans les arguments passés par valeur, tout en appelant à travers le "local de l'interface" résultats dans les arguments passés par référence. C'est une majeure différence; donc, si vous commencer avec un local", assurez-vous de concevoir votre système de manière qu'il faut "à distance" de la sémantique en considération aussi bien.

Si votre conception s'appuie sur les méthodes d'EJB évolution passée des objets, alors il serait difficile pour vous de passer à distance" plus tard; peut-être même impossible.

Bonne chance.

Answer 3

Cela peut répondre à vos préoccupations :

Généralement, votre Entreprise Java Bean aurez besoin d'un client à distance en vue les cas où vous prévoyez d'utiliser la fève dans des environnements distribués. Plus précisément, ce sont les cas où le client va travailler ce sera dans une autre Machine Virtuelle Java (JVM). Dans le cas d'une distance de la vue du client, tout appel de méthode à partir de la télécommande à la maison interface et/ou à distance de l'interface composant va être géré à distance via method invocation (RMI).

Un EJB peut utiliser les locaux de la vue du client que si elle est vraiment garanti que d'autres haricots d'entreprise ou des clients traitera uniquement de la fève à l'intérieur d'un seule JVM. Si c'est le cas, cet accès sera réalisée avec direct les appels de méthode, au lieu de RMI.

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