Die RemotingHandler

Fertig einsetzbare RemotingHandler sind bereits in EJOE enthalten. Ihr Einsatz macht die Implementierung eines eigenen ServerHandlers überflüssig, entbindet jedoch nicht in allen Fällen von weiteren serverseitigen Anpassungen, da insbesondere in komplexen Serverarchitekturen notwendige Funktionalität oftmals nicht einfach ohne weiteres über Reflection bedient werden kann.

Die Benutzung der RemotingHandler erfordert zusätzliche Informationen über auf dem Server verfügbare Klassen und Methoden in der Clientimplementierung. RemotingHandler benötigen eine erweiterte Parameterliste, da Sie im Gegensatz zu spezifischen ServerHandlern selbst kein Wissen über externe Anwendungslogik(en) besitzen. RemotingHandler benötigten im Detail Informationen über:

  • die zu benutzende Entität
  • die innerhalb dieser Entität anzusprechende Operation
  • die für die anzusprechende Operation benötigen Argumente
Auf Java bzw. Reflection bezogen bedeutet dies, dass Packagepfad und Name der Zielklasse (=Entität), Methoden- oder Konstruktorname (=Operation) sowie ggf. die Argumente für die aufzurufende Methode bzw. den aufzurufenden Konstruktor benötigt werden. Für Client-Anfragen stellt EJOE deshalb einen besonderen Anfragecontainer, den RemotingRequest, bereit. Der RemotingRequest dient sowohl als Container für oben genannte Daten als auch als Erkennungszeichen auf dem Server, dass es sich bei einer Anfrage um eine Anfrage des Typs "RemoteReflection" handelt, welche ausschließlich von RemotingHandlern bearbeitet werden.
import de.netseeker.ejoe.EJClient;
import de.netseeker.ejoe.request.RemotingRequest;
...
{
	EJClient ejClient = new EJClient( "192.168.1.21", 80 );
	List result = null;
	try
	{
		RemotingRequest request = new RemotingRequest( "com.who.AddressManagement",		
			"listAddressesByName", new Object[]{ "Mustermann" } );
		result = (List)ejClient.execute(request );
	}
	catch(RemoteException re)
	{
		//EJServer did return an Error
	}
	catch(IOException e)
	{
		//connection or serialization issues maybe?
	}
	...
}
Remoting-Anfragen müssen immer in einen RemotingRequest gekapselt werden!

Sicherheitsaspekte

RemotingHandler sind theoretisch von Natur aus eine gefährliche Sache: Clients könnten via RemotingRequest alle möglichen Funktionen des Servers anzapfen. EJOE steuert diesem Aspekt entgegen, indem es von vornherein erst einmal alle Reflectionaufrufe ablehnt, es sei denn, die Zielklasse ist in einer speziellen Konfigurationsdatei eingetragen.

EJOE sucht auf dem Classpath nach einer Datei mit dem Namen "ejoe-reflectionconf.properties". Wird diese gefunden, werden Reflectionaufrufe für alle eingetragenen Klassen bzw. Packages gestattet. Wird allerdings keine solche Datei gefunden, wird die sehr restriktive Standardkonfiguration aus dem Pfad "META-INF/ejoe-reflection-conf.properties" verwendet.

#############################################################################################
# This is the default configuration for remote reflection in EJOE.
# EJOE handles received reflection requests by clients VERY restrictive:
# Only packages/classes which are listed in this file
# can be used for remote reflection.
# To overwrite the reflection settings, provide a customized
# ejoe-reflection-conf.properties on the classpath.
#############################################################################################
de.netseeker.ejoe.test.*

Die rekursive Freigabe aller Klassen eines Packages sowie aller Sub-Packages und deren Klassen erfolgt durch Angabe des Stern-Symbols:

package.path.*

Die gezielte Freigabe einzelner Klassen erfolgt durch die vollständig qualifizierte Angabe von Packagepath und Klassennamen:

package.path.MyClass