Blog

EJAPP Top 10 Countdown: #2 - Unnötige Fernwartung

Vincent Partington

Aktualisiert Oktober 23, 2025

4 Minuten

Um das Tempo zu erhöhen und sicherzustellen, dass ich den Countdown beende, bevor ich zur JavaOne fahre ;-), gehe ich schnell zu Nr. 2 des EJAPP Top 10 Countdowns über.... Während Remoting in Enterprise Java-Anwendungen häufig verwendet wird, weil andere Systeme und Anwendungen aufgerufen werden müssen, ist unnötiges Remoting eine wichtige Ursache für schlecht funktionierende Enterprise Java-Anwendungen.

Daher kann sich dieses Problem auf verschiedene Weise manifestieren:

Aufruf einer EJB aus der Ferne , wenn ein lokaler Aufruf verfügbar ist (auch ein Fall von falscher Verwendung von Java EE).
Aufrufen einer externen Anwendung, obwohl die Funktionalität in Java selbst verfügbar ist. Der folgende Code wurde in einem Produktions-Quellcode entdeckt:
```
Runtime.getRuntime().exec("d:\path\to\bin\sleep.exe " + nbSecond);
```
Die gleiche Funktionalität hätte man auch mit einer einfachen:
```
Thread.sleep(nbSecond * 1000);
```
SOAP verwenden, wenn RMI ausreichen würde. SOAP-Aufrufe sind in der Regel 10 bis 20 Mal langsamer als der entsprechende RMI-Aufruf, abhängig vom verwendeten SOAP-Framework, der Netzwerkgeschwindigkeit und der Zeit, die die aufgerufene Methode selbst auf dem Server benötigt. Siehe Comparison of performance of web services, WS-security, RMI, and RMI-SSL von Juric, Rozman, Brumen, Colnaric, and Hericko für eine wissenschaftliche Fallstudie. In jedem Fall kann die Verwendung von SOAP zu einer unnötigen Verwendung von XML führen, was wiederum eine übermäßige Speichernutzung zur Folge hat.
Viele kleine Methodenaufrufe(feinkörnig) anstelle eines großen Methodenaufrufs(grobkörnig), wodurch der Overhead des Remote-Methodenaufrufs mehrfach anfällt. Das Transfer Object Pattern wurde erfunden, um dieses Problem in JavaEE zu lösen, wo es vor allem in EJB 1.x Entity Beans auftrat.

In manchen Fällen wird eine Architektur mit eingebautem Remoting für einen erwarteten zukünftigen Bedarf entworfen, der nie eintritt. Ein Kollege von mir hatte zum Beispiel eine Anwendung, die in zwei Projekte aufgeteilt war: eine Serviceschicht (die den Zugriff auf einen Mainframe ermöglichte), die für mehrere Front-Ends konzipiert war, auf die über eine SOAP-Schnittstelle zugegriffen werden konnte, und eine Webschnittstelle, die die Serviceschicht aufrief. Letztendlich wurden keine weiteren Front-Ends entwickelt und das gesamte System wurde in einem Anwendungsserver-Cluster eingesetzt. Die Vorteile des Remotings wurden nicht genutzt, aber die Leistungseinbußen waren immer noch vorhanden. Ein typischer Fall von YAGNI!Das Gleiche gilt für frühere Versionen von J2EE. In EJB 1.x gab es nur Remote Beans, da dies die Möglichkeit bot, durch Clustering die Verfügbarkeit und Leistung zu verbessern, auch wenn dies nicht immer erforderlich war. Auch von WSRP kann ich nicht wirklich begeistert sein; mir graut es vor der Leistung eines Portals (ohnehin keine meiner Lieblingstechnologien), das seine Portlets über eine SOAP-Schnittstelle aufruft. Wie auch immer, manchmal muss man einfach mit Remoting arbeiten. In diesem Fall können diese Tipps Ihnen helfen, den Schaden zu begrenzen:

Stellen Sie zunächst sicher, dass Sie Remoting wirklich benötigen.
Wählen Sie Ihre Remoting-Technologie mit Bedacht. Verwenden Sie nicht SOAP, nur weil alle coolen Kids es tun ;-) Ziehen Sie Alternativen wie Hessian (ein effizientes binäres Protokoll), Burlap (eine XML-Version von Hessian), Spring's HTTP Invokers (ein rein Java-basiertes binäres Protokoll) oder RMI in Betracht. Schreiben Sie einen Benchmark für Ihre Situation, um Ihnen die Entscheidung zu erleichtern.
Vermeiden Sie es, feinkörnige Methoden aus der Ferne aufzurufen. Verwenden Sie das Facade-Muster, um sie zu grobkörnigen Methoden zusammenzufassen.
Wenn Sie Remoting nur für einen Teil Ihrer Anwendungsfälle benötigen, sollten Sie in Erwägung ziehen, Ihre Geschäftsfunktionalität mithilfe anderer Technologien zu veröffentlichen. Das Spring-Framework ermöglicht es beispielsweise, Funktionen durch einen Java-Methodenaufruf aufzurufen, während dieselben Funktionen auch durch einen Exporter als Dienst bereitgestellt werden.

Remoting hat seinen Nutzen und seine Vorteile, aber seien Sie sich der Auswirkungen auf die Leistung Ihrer Anwendung bewusst!