Ideenfindung: Generische Transportklasse?

[tuxedo]

Hallo zusammen,

zur Zeit bastle ich ein wenig mit dem MINA Framework (http://mina.apache.org/) in Verbindung mit meiner SIMON Implementierung.

Dabei bin ich irgendwie auf eine Hirnblockade gestoßen was die Protokoll-Sache angeht.

Bisher hab ich ein festes Schema wie eine Nachricht die übers Netzwerk geht aussieht:

byte: Simon ID
byte: Paket-Typ
byte: Anfrage ID
int: Länge des folgenden Nachrichtenbodys
x: Nachrichtenbody

In dieser Reihenfolge stecke ich die beschriebenen Datentypen in ein ByteBuffer und jage diesen Übers Netzwerk. Am anderen Ende weiß ich aufgrund des Paket-Typs, wie der Nachrichtenbody "x" aufgebaut ist:

Im Falle eines "Invoke Request" Paketes, sieht der Nachrichtenbody beispielsweise so aus:

String: Name des Remoteobjekts
long: ein HashWert der die aufzurufende Methode identifiziert
class[]: Ein Array das die Methodenargumente für den Aufruf beinhaltet

So. Der Header ist also "fix", nur der Body ändert sich von Paket-Type zu Paket-Typ.

Mit MINA sind gibts jetzt "ProtocolCodec"s die man selbst schreiben kann. Damit sollen POJOs in einen ByteBuffer umgeformt werden (und umgekehrt). Alles noch kein Problem, hab ich auch schon testweise mit einer Dummynachricht hinbekommen.

Mir stellt sich jetzt nur die Frage: Was mach ich mit meinen vielen möglichen (10 an der Zahl) Paket-Typen? Wie bringe ich die so auf einen "POJO-Nenner", dass ich nur einen Encoder/Decoder brauche um alle 10 Pakettypen abzudecken?!

Meine erste Idee war jetzt, eine Paket-Basisklasse zu schaffen die wie folgt aussieht:

byte: Simon ID
byte: Paket-Typ
byte: Anfrage ID
LinkedHashMap<String, Object>: Geordnete Reihenfolge von Key-Value Paaren: 
Key=Name/ID des "Dings" das im Nachrichtenbody vorkommt; Value=Das Objekt aus dem Nachtrichtenbody

Also für das Beispiel "Invoke Request":

byte: Simon ID
byte: Paket-Typ
byte: Anfrage ID
LinkedHashMap<String, Object>: {["remoteObjectName", String-Objekt], ["methodHash", long Wert], 
["methodArgs", class Array]}

Macht sowas Sinn? Ist das "performant"? Möchte möglichst jedes unnötige cast etc. vermeiden...
Fällt jemand spontan ein besserer "Container" für ein generisches Paket ein?

Wobei mir gerade auffällt, dass ich nichtmal eine LinkedHashMap bräuchte, eine LinkedList würde genügen...Type lässt sich ja mit "instance of" erfragen. Oder ist das auch wieder ein "performance no go" ?

Ach ja, eins noch: Ich könnte ja auch alles entsprechend im ProtocolCodec hard-codieren, aber ich möchte SIMON mit der verwendung von MINA erweiterbar halten, so dass man ggf. sein eigenes Protokoll aufsetzen kann. Deshalb die Sache mit dem "gemeinsamen POJO-Nenner" für alle Pakettypen.

- Alex

 

[tuxedo]

Hab gerade gelesen, dass MINA für sowas eine "DemuxingProtocolCodecFactory" besitzt, der man mitteilen kann, dass Objekte der Klasse ABC mit dem Encoder EncABC, bzw. Decoder DecABC bearbeitet werden sollen. Das hat dann zur Folge, dass man nicht einen Encoder/Decoder für alle Nachrichten hat, sondern für jede Nachricht einen eigenen Decoder/Encoder bereitstellen kann der dynamisch gewählt wird. Allerdings hab ich noch keinen Plan wie MINA da bei einem eingehenden Paket entscheidet von welcher Klasse es ist.

Insgesamt hat das auch was für sich. Allerdings bläst sich dann der Aufwand, ein weiteres Protokoll zu unterstützen wieder etwas auf.

Vielleicht kommt ja doch noch "DIE" brilliante Idee auf...Ansonsten werd ich mal das Demux-Beispiel ausprobieren.

- Alex

 

[FArt]

Die Leute von SUN (und auch andere) sind z.B. beim XMLEncoder/XMLDecoder einen ähnlichen Ansatz gefahren:
sie unterstützen nicht POJOs, sonder Beans und bieten dafür Standardmethoden für enkodieren/dekodieren. Mit Callbacks kann man dies aber für bestimmte Objekte ändern.

 

[tuxedo]

Ob POJO oder Bean ist dann ja Geschmacks-/Glaubenssache ;-)

Hab mich da gestern nochmal etwas durch den Source der MINA-Samples gewühlt. Werde das wohl so implementieren.

- Alex