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? Sollen Sie Remote-Schnittstellen verwenden, wenn Sie davon ausgehen, dass Ihre Anwendung unterschiedliche Komponenten auf unterschiedlichen Servern hat? Und verwenden Sie lokale Schnittstellen, wenn sich Ihre Anwendung nur auf einem Server befinden soll?

Wenn meine obigen Annahmen richtig sind, wie würden Sie entscheiden, ob Sie lokale oder Remote-Schnittstellen für eine neue Anwendung verwenden möchten, bei der Sie sich nicht sicher sind, wie hoch das Verkehrsaufkommen sein würde? Beginnen Sie mit der Verwendung lokaler Schnittstellen und führen Sie gegebenenfalls ein schrittweises Upgrade auf Remote-Schnittstellen durch?

Danke für jede Klarstellung und Anregungen.

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 wurde angenommen, dass EJBs entfernte Komponenten sind, und die einzige Möglichkeit, sie aufzurufen, bestand darin, einen entfernten Aufruf durchzuführen, wobei RMI-Semantik und der gesamte damit verbundene Overhead verwendet wurden (ein Netzwerkaufruf und Objektserialisierung für jede Methodenaufruf). EJB-Clients mussten diese Leistungseinbuße bezahlen, selbst wenn sie sich in derselben virtuellen Maschine wie der EJB-Container befanden.

Später erkannte Sun, dass die meisten Geschäftsanwendungen EJBs eigentlich nicht auf einer anderen Ebene verteilten, und sie korrigierten die Spezifikation (in EJB 2.0), indem sie das Konzept der lokalen Schnittstellen einführten, sodass Clients, die sich in derselben virtuellen Maschine mit dem EJB-Container befinden, EJBs aufrufen können direkter Methodenaufruf, der die RMI-Semantik (und den damit verbundenen Overhead) vollständig umgeht.

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 skalieren, was aber nicht unbedingt bedeutet verteilen Komponenten. Sie können eine Web+EJB-Anwendung auf einem Cluster ausführen, ohne die Webschicht und die EJB-Schicht zu trennen.

Sollen Sie Remote-Schnittstellen verwenden, wenn Sie davon ausgehen, dass Ihre Anwendung unterschiedliche Komponenten auf unterschiedlichen Servern hat? Und verwenden Sie lokale Schnittstellen, 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).

(…) Beginnen Sie mit lokalen Schnittstellen und erweitern Sie gegebenenfalls schrittweise auf Remote-Schnittstellen?

Ich würde wahrscheinlich mit der Verwendung lokaler Schnittstellen beginnen. Und wie bereits angedeutet, ist das Umschalten auf Remote-Schnittstellen nicht immer zwingend (man kann a zusammengestellt Struktur).

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

Ressourcen

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

Während ich mit den meisten der oben geschriebenen Aussagen übereinstimme, möchte ich die „Wie fange ich an“-Ideen ein wenig verfeinern.

Mein Vorschlag an Sie ist, niemals je direkt in EJB-Schnittstellen innerhalb Ihres Codes programmieren. Verwenden Sie immer eine reguläre, geschäftsorientierte Schnittstelle, programmieren Sie darauf (dh lassen Sie Ihren Code Methoden auf der geschäftsorientierten Schnittstelle aufrufen) und stellen Sie den EJB-„Klebe“-Code als austauschbare Implementierung bereit. Ihr Programm sollte sich auf die Geschäftslogik konzentrieren und nicht auf Implementierungsdetails wie EJB.

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

Ein besonderer Hinweis zum Umschalten von lokal auf remote: Beachten Sie, dass es einige semantische Unterschiede zwischen den beiden gibt. Beispielsweise führt der Aufruf einer EJB-Methode über ihre „Remote-Schnittstelle“ dazu, dass Argumente als Wert übergeben werden, während der Aufruf über die „lokale Schnittstelle“ dazu führt, dass Argumente als Referenz übergeben werden. Das ist ein Haupt Unterschied; Wenn Sie also “mit lokal beginnen”, stellen Sie sicher, dass Sie Ihr System so entwerfen, dass es auch die “entfernte” Semantik berücksichtigt.

Wenn Ihr Design auf EJB-Methoden angewiesen ist, die übergebene Objekte ändern, wäre 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 beides sein lokal oder Fernbedienung. Eine Geschäftsschnittstelle kann nicht gleichzeitig lokal und remote sein.

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

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

Die wichtigsten Dinge, die Sie beachten sollten, sind also:

1. Wenn eine Bean-Klasse die @Remote Anmerkung, dann müssen alle implementierten Schnittstellen remote sein.
2. Wenn eine Bean-Klasse keine Annotation enthält oder wenn die @Local Anmerkung 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. Das Release 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 Ihr Enterprise Java Bean eine Remote-Client-Ansicht, wenn Sie beabsichtigen, das Bean in verteilten Umgebungen zu verwenden. Dies sind insbesondere die Fälle, in denen sich der Client, der damit arbeiten wird, in einer anderen Java Virtual Machine (JVM) befindet. Im Fall einer Remote-Client-Ansicht wird das Aufrufen einer beliebigen Methode von der Remote-Home-Schnittstelle und/oder der Remote-Komponentenschnittstelle über Remote Method Invocation (RMI) gehandhabt.

Ein EJB kann die lokale Client-Ansicht nur verwenden, wenn wirklich sichergestellt ist, dass andere Enterprise-Beans oder Clients das Bean nur innerhalb einer einzigen JVM ansprechen. Wenn dies der Fall ist, wird ein solcher Zugriff mit direkten Methodenaufrufen anstelle von RMI durchgeführt.

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