Erweiterte Funktionen

  1. Kompression
  2. Deaktivieren des non-blocking I/O
  3. Remote classloading
  4. EJOE hinter Firewalls: HTTP-Unterstützung
  5. Wechseln der verwendeten Serialisierungsstrategie

Kompression

Bei aktivierter Kompression werden Anfragen mittels GZIP komprimiert. Dies kann insbesondere sehr hilfreich sein, wenn Client und Server textbasierte Daten wie bspw. XML austauschen. Nur wenn Kompression auch im EJServer aktiviert ist, können Clients Kompression benutzen. Aktivierung der Kompression im EJServer:

ejserver.enableCompression();
Aktivierung der Kompression im EJClient:

ejclient.enableCompression(true);

Deaktivierung des non-blocking I/O

Seit Version 0.3.4 benutzt EJOE non-blocking I/O als Standard-I/O-Mechanismus. Werden allerdings sehr große Objekte zwischen Client und Server ausgetauscht kann es Vorteile bringen non-blocking I/O zu deaktiveren. Bei deaktivertem non-blocking I/O muss die serialisierte Form der Objekte nicht in ByteBuffern gepuffert werden, sondern kann direkt geschrieben und gelesen werden.

Deaktiverung des non-blocking I/O im EJServer:

ejserver.enableNonBlockingIO( false );
Die gute Nachricht: Alle EJClients reagieren automatisch auf den gewählten I/O-Mechanismus.

Remote classloading

EJOE unterstützt das sog. Remote Classloading. Beim Remote Classloading werden unbekannte Klassen bei der Deserialisierung von Serverantworten automatisch vom EJServer nachgeladen. Dies erspart die manuelle Verteilung aller verwendeten Klassen auf Clients. Beim Remote Classloading wird ein besonderer Classloader, de.netseeker.ejoe.EJClassLoader, benutzt. Dieser Classloader benutzt interessanterweise intern ebenfalls einen EJClient um Klassen vom Server nachzuladen.

Ja, wir essen unsere eigenen Kost wie man so schön sagt. ;-)

Remote Classloading muss zuerst im EJServer aktiviert werden: 

EJServer myServer = ...;
myServer.enableRemoteClassLoading(true);
Aktivierung des Remote Classloadings im EJClient: 
EJClient myClient = ...;
myClient.enableRemoteClassloading(true);

Bei aktiviertem Remote Classloading ändert EJClient den Kontext-Classloader des aktuellen Prozesses. Normalerweise ergeben sich daraus keine Probleme, da EJClient Klassenanfragen zuerst an den vorherig aktiven Classloader delegiert...

HTTP-Unterstützung

HTTP wird normalerweise benutzt um Daten zwischen einem Browser und einem Webserver auszutauschen. In vielen Firewalls ist HTTP über Port 80 deshalb freigeschaltet, während andere Ports und Protokolle reguliert werden. EJOE kann sich diesen Umstand zu nutze machen, um auch EJClients, die sich hinter derartigen Firewalls befinden zu bedienen.

Zuerst muss die HTTP-Unterstützung im EJServer aktiviert werden: 

EJServer server = new EJServer( ... );
server.enableHttpPackaging( true );

Aktivierung der HTTP-Unterstützung im EJClient: 

EJClient myClient = new EJClient(...);
myClient.enableHttpPackaging( true );

HTTP-Unterstützung kann ausschließlich mit aktiviertem non-blocking I/O (default) benutzt werden!