Subscribe
Follow me on TwitterNachdem es nun doch eine Weile ruhig um EJOE war, ist die Entwicklung für 0.4.0 wieder in vollem Gange. Seit März haben es noch ein paar Features in die Planung geschafft, weswegen derzeit noch 2 Milestones vor der finalen 0.4.0 geplant sind: 0.3.9.1 (Anfang August) und 0.3.9.2. (Mitte September)
Bei den neuen Features sind wahrscheinlich insbesondere die verschiedenen (De)Serialisierungsstrategien sowie Standard Support für Remote Reflection hervorzuheben. Eine komplette Liste gibt es unter http://ejoe.sourceforge.net/todo040.html.
Serialisierungsstrategien
Bisher hat EJOE einfach Objekte clientseitig angenommen, mittels eines Serialisierungs-Adapters serialisiert und an den Server geschickt, nach Verarbeitung des Requests gab der Server Objekte auf dem selben Weg zurück und der Client händigte dem Aufrufer die Response wieder als Objekt aus.
Seit geraumer Weile liegt nun schon eine Implementierung im CVS, die es ermöglicht ByteBuffer direkt auszutauschen ohne die Serialisierung zu benutzen. Dazu ist jetzt noch die Möglichkeit gekommen Objekte (Server-Responses) direkt ohne Deserialisierung zurückzugeben. Dadurch wird es bspw. möglich einen XML-basierten SerializeAdapter zu benutzen und die ServerResponse direkt als XML (innerhalb eines ByteBuffers) abzugreifen und an einen XSLT-Prozessor weiterzureichen.
| EJClient.ADAPTER_STRATEGY_DEFAULT | Standardmodus, (De)Serialisierung wie in den bisherigen EJOE-Versionen | |
| EJClient.ADAPTER_STRATEGY_DIRECT | Direkter ByteBuffer-Austausch zwischen Client und Server | |
| EJClient.ADAPTER_STRATEGY_MIXED | Serialisierung wie üblich, aber die Server-Response wird unserialisiert zurückgegeben |
Remote Reflection
Dieses Feature wird es erlauben per Reflection statische und dynamische Methodenaufrufe im Server vorzunehmen. Um dies zu ermöglichen hält eine neue Familie von vorgefertigten ServerHandlern in EJOE Einzug: Die RemotingHandler. Es wird Handler für Standard-Reflection als auch beschleunigte Aufrufe via serverseitige, dynamische Proxy-Generierung geben.
Java Permissions basierte Sicherheit für diese Aufrufe wird ebenfalls unterstützt werden um den Server sicher zu halten.
Was es nicht geben wird sind definitv clientseitige Stubs. Wer sowas braucht ist bei EJOE ohnehin falsch und sollte RMI oder ein SOAP-Framework mit WSDL2Java-Generierung in Erwägung ziehen.
Mit Annahme dieses Features haben wir uns entschieden eine entsprechende Crispy-Erweiterung auszuliefern und uns dem Trend zu abstrahierten Remote-Services einzureihen.
Wo gibts derzeit noch Probleme?
Ein bisschen schwer tue ich mich bspw. noch mit dem bereits zugesagten, rudimentären Cluster-Support. Das liegt hauptsächlich daran, dass EJOE neben den temporären Contributoren derzeit nur von mir vorangetrieben wird. So wird es leider – wenn nicht noch ein Wunder geschieht – auch die IPC (Interprocess Communication, wenn Client und Server in der selben JVM laufen) nicht in die die Featureliste für 0.4.0 schaffen…
Unsteter Gedankenfluss aus dem Leben eines Projektleiters, Entwicklers, Freizeitautors, eBook-Enthusiasten und last but not least sächsischen Asylschwaben.