EJBs - wann sollten Remote- und / oder lokale Schnittstellen verwendet werden?

Ich bin sehr neu in Java EE und versuche, das Konzept der lokalen Schnittstellen und Remote-Schnittstellen zu verstehen. Mir wurde gesagt, dass einer der großen Vorteile von Java EE darin besteht, dass es einfach zu skalieren ist (was meiner Meinung nach bedeutet, dass Sie verschiedene Komponenten auf verschiedenen Servern bereitstellen können). Kommen hier Remote- und lokale Schnittstellen ins Spiel? Sollten Sie Remote-Schnittstellen verwenden, wenn Sie erwarten, dass Ihre Anwendung unterschiedliche Komponenten auf unterschiedlichen Servern enthält? Und lokale Schnittstellen verwenden, wenn sich Ihre Anwendung nur auf einem Server befinden soll?

Wenn meine obigen Annahmen richtig sind, wie würden Sie vorgehen, um zu entscheiden, ob lokale oder Remote-Schnittstellen für eine neue Anwendung verwendet werden sollen, wenn Sie sich nicht sicher sind, wie hoch das Verkehrsaufkommen sein würde? Beginnen Sie mit der Verwendung lokaler Schnittstellen und aktualisieren Sie gegebenenfalls schrittweise auf Remote-Schnittstellen.

Vielen Dank für jede Klarstellung und Vorschläge.

Ich bin sehr neu in Java EE und versuche, das Konzept der lokalen Schnittstellen und Remote-Schnittstellen zu verstehen.

In den ersten Versionen der EJB-Spezifikation wurden EJBs als Remote-Komponenten "angenommen", und die einzige Möglichkeit, sie aufzurufen, bestand darin, einen Remote-Aufruf unter Verwendung der RMI-Semantik und des damit verbundenen Overheads (Netzwerkaufruf und Objektserialisierung für jeden) durchzuführen Methodenaufruf). EJB-Clients mussten diese Leistungseinbußen auch dann zahlen, wenn sie sich in derselben virtuellen Maschine wie der EJB-Container befanden.

Später stellte Sun fest, dass die meisten Geschäftsanwendungen EJBs tatsächlich nicht auf einer anderen Ebene verteilten, und korrigierte die Spezifikation (in EJB 2.0), indem sie das Konzept lokaler Schnittstellen einführte, sodass Clients, die in derselben virtuellen Maschine mit dem EJB-Container zusammengeschlossen sind, EJBs mithilfe von aufrufen können direkter Methodenaufruf unter vollständiger Umgehung der RMI-Semantik (und des damit verbundenen Overheads).

Mir wurde gesagt, dass einer der großen Vorteile von Java EE darin besteht, dass es einfach zu skalieren ist (was meiner Meinung nach bedeutet, dass Sie verschiedene Komponenten auf verschiedenen Servern bereitstellen können).

Java EE kann skaliert werden, dies bedeutet jedoch nicht unbedingt das Verteilen von Komponenten. Sie können eine Web + EJB-Anwendung in einem Cluster ausführen, ohne die Webschicht und die EJB-Schicht zu trennen.

Sollten Sie Remote-Schnittstellen verwenden, wenn Sie erwarten, dass Ihre Anwendung unterschiedliche Komponenten auf unterschiedlichen Servern enthält? Und lokale Schnittstellen verwenden, wenn sich Ihre Anwendung nur auf einem Server befinden soll?

Ich würde es so formulieren: Verwenden Sie Remote-Schnittstellen, wenn sich der Client nicht in derselben JVM befindet (dies bedeutet nicht, dass nur ein Server / eine JVM verwendet wird).

(...) Verwenden Sie zunächst lokale Schnittstellen und aktualisieren Sie gegebenenfalls schrittweise auf Remote-Schnittstellen.

Ich würde wahrscheinlich mit lokalen Schnittstellen beginnen. Und wie bereits angedeutet, ist das Wechseln zu Remote-Schnittstellen nicht immer obligatorisch (Sie können eine zusammengestellte Struktur gruppieren ).

Ich schlage vor, die unten genannten Ressourcen zu überprüfen (die beiden ersten sind ziemlich alt, aber immer noch relevant, die beiden anderen sind neuer).

Ressourcen

• Unter der Haube von J2EE Clustering von Wang Yu
• Skalieren Ihrer Java EE-Anwendungen von Wang Yu
• Skalieren Ihrer Java EE-Anwendungen - Teil 2 von Wang Yu

Obwohl ich mit den meisten der oben genannten Punkte einverstanden bin, möchte ich die Ideen zum Starten ein wenig verfeinern.

Mein Vorschlag an Sie ist nie zu immer innerhalb des Codes direkt zu EJB - Schnittstellen zu programmieren. Verwenden Sie immer eine reguläre, geschäftsorientierte Schnittstelle, programmieren Sie darauf (dh haben Sie Ihre Code-Aufrufmethoden auf der geschäftsorientierten Schnittstelle) und stellen Sie den EJB-Klebercode als steckbare Implementierung bereit. Ihr Programm sollte sich auf Geschäftslogik konzentrieren und nicht auf Implementierungsdetails wie EJB.

Auf diese Weise können Sie problemlos zwischen Remote- und lokalen Implementierungen wechseln. Wenn Sie einen IoC-Container wie Spring verwenden, können Sie dies nur über die Konfiguration tun.

Ein besonderer Hinweis zum Wechsel von lokal zu fern: Beachten Sie, dass es einige semantische Unterschiede zwischen den beiden gibt. Wenn Sie beispielsweise eine EJB-Methode über ihre "Remote-Schnittstelle" aufrufen, werden Argumente als Wert übergeben, während beim Aufruf über die "lokale Schnittstelle" Argumente als Referenz übergeben werden. Dies ist ein großer Unterschied; Wenn Sie also "mit lokal beginnen", stellen Sie sicher, dass Sie Ihr System so gestalten, dass auch die "entfernte" Semantik berücksichtigt wird.

Wenn Ihr Entwurf auf EJB-Methoden beruht, die übergebene Objekte ändern, ist es für Sie schwierig, später auf "Remote" umzuschalten. vielleicht sogar unmöglich.

Viel Glück.

Gemäß EJB Spec 3.2 kann ein EJB entweder lokal oder remote sein . Eine Geschäftsschnittstelle kann nicht gleichzeitig lokal und remote sein.

@Local Auf kommentierte Beans kann nur zugegriffen werden, wenn sie sich in derselben Anwendung befinden.

@Remote Auf kommentierte Beans kann über verschiedene Anwendungen hinweg zugegriffen werden, die sich in verschiedenen JVMS oder über Anwendungsserver befinden.

Die wichtigsten Dinge, die Sie beachten sollten, sind:

1. Wenn eine Bean-Klasse die @RemoteAnnotation enthält , müssen alle implementierten Schnittstellen remote sein.
2. Wenn eine Bean-Klasse keine Annotation enthält oder wenn die @LocalAnnotation angegeben ist, wird angenommen, dass alle implementierten Schnittstellen lokal sind.
3. Alle Schnittstellen, die explizit für eine Bean definiert sind, die keine Schnittstelle enthält, müssen als @Local deklariert werden.
4. Die Version EJB 3.2 bietet tendenziell mehr Granularität für Situationen, in denen lokale und Remote-Schnittstellen explizit definiert werden müssen.

Dies kann Ihre Bedenken beantworten:

Im Allgemeinen benötigt Ihre Enterprise Java Bean eine Remote-Client-Ansicht, wenn Sie die Bean in verteilten Umgebungen verwenden möchten. Dies sind insbesondere die Fälle, in denen sich der Client, der damit arbeitet, in einer anderen Java Virtual Machine (JVM) befindet. Im Fall einer Remote-Client-Ansicht wird der Aufruf einer Methode von der Remote-Home-Schnittstelle und / oder der Remote-Komponentenschnittstelle über den Remote-Methodenaufruf (RMI) abgewickelt.

Eine EJB kann die lokale Clientansicht nur verwenden, wenn wirklich garantiert ist, dass andere Enterprise-Beans oder Clients die Bean nur innerhalb einer einzelnen JVM adressieren. In diesem Fall wird ein solcher Zugriff mit direkten Methodenaufrufen anstelle von RMI ausgeführt.

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