# Remote-Objekt-Server : Alternative Methodenaufruflogik zu Reflection und hart codiert



## DougUndPizza (10. Dez 2011)

Hallo allerseits,

dies ist mein erster Thread. Ich lese hin und wieder in diesem netten Forum und kam bisher meistens durch die Suchfunktion und die Themen und Antworten von Euch allen weiter. Danke dafür.


Da ich gerade dabei bin, den Netzwerkzugriff für ein bestimmtes Objekt zu implementieren, kam mir die Idee, den Server möglichst allgemein zu halten, sodass beliebige Objekte im Konstruktor übergeben und damit übers Netzwerk erreicht werden können.


- Der Server hat eine Instanz des Objekts, das manipuliert werden soll. Dieses wird wahrscheinlich im Konstruktor übergeben
- Das Objekt hat einen Zustand und Methoden, um diesen Zustand zu manipulieren. Darüber hinaus gibt es Methoden, die Rückgabewerte haben und nicht den Zustand des Objektes betreffen.

Die Kommunikation ist bis jetzt soweit, dass Methodenaufrufobjekte mit Parametern vom Proxy zum Server gesentet werden können(mit ID) und der Server entsprechende RückgabeObjekte(mit gleicher ID) zurücksenden kann. Das ganze funktioniert in beide Richtungen mit serialisierten Objekten und eigenen "Codecs" fürs De-/Serialisieren.

Nun bin ich an dem Punkt, wo auf der Serverseite aus den "MethodenAufrufObjekten" konkrete Methodenaufrufe werden müssen.

1. Das Erste, was mir dazu einfiel, war Reflection.

```
...
Object meineInstanz;

public Object reflectionMethodenAufruf(MethodenAufrufObject methodenAufruf)
{  
    return Class.forName(meineInstanz.getClass().getName()).getMethod(methodenAufruf.getMethodenName(), methodenAufruf.getParameter());
    
}
...
```

- Das bringt mich aber nicht weiter, da Reflection für jeden Methodenaufruf ein neues Objekt erzeugt, und ich damit keine vorhande Instanz benutzen kann. Damit könnte ich also nicht den Zustand meiner konkreten Instanz manipulieren (korrigiert mich, wenn ich hier falsch liege)

2. Hart codierte Methodenaufruflogik à la

```
public Object methodenAufruf(MethodAufrufObject methodenAufrufObject)
{
    if(methodenAufrufObject.getMethodenName().equals"tuWasMethode")
    {
        return meineInstanz.tuWasMethode();
    }
    if...
}
```

3. Konkrete Instanz des Objektes zusammen mit entsprechender Methodenaufruflogik an den Server übergeben (Strategy Pattern). - Also "2." auslagern. 
Dadurch bliebe der Server dynamisch für beliebige Objekte.


Was besseres ist mir bisher nicht eingefallen. :noe:

Habt ihr vielleicht eine andere/elegantere Lösung? :toll:


P.S. Die Codeschnipsel sind nur zum Verdeutlichen der Ideen und funktionieren nicht.


----------



## Marcinek (10. Dez 2011)

Wieso das rad neu erfinden?

Nutze rmi oder ejb dafür


----------



## DougUndPizza (10. Dez 2011)

Marcinek hat gesagt.:


> Wieso das rad neu erfinden?
> 
> Nutze rmi oder ejb dafür




Hab ich vergessen oben dazu zu schreiben: In dem Fall geht es mir quasi darum, das Rad neu zu erfinden.

- ich möchte möglichst wenig Overhead im Netzwerkverkehr haben. - Daher die eigenen Serialisierungsvorschriften und nicht die Java Objectinput-/ObjectOutputStreams (die glaub ich bei RMI genutzt werden).
- der Methodenaufruf soll auf Serverseite möglichst schlank und schnell sein (auch aus dem Grund ungern Reflection)
- es geht mir um den Lerneffekt


----------



## Kr0e (10. Dez 2011)

Hi!

Hab da mal was vor einiger Zeit angefangen doch aufgrund von Zeitknappheit zur Zeit eingestellt.

Hier:

Eigenes RMI Protokoll:

foxnet-rmi - Fast and efficient remote method invocation - Google Project Hosting

Eigene, ziemlich schnelle Serialisireung:

foxnet-codec - A lightweight and easy to use yet fast Java Serialization API - Google Project Hosting


Die beiden Projekte sind noch nicht fertig und im Umbruch... Aber da kannt du mal reinschauenn wenn du Source brauchst. Mein RMI Projekt untersützt ziemlich viel davon, was auch RMI kann. Also Callbacks etc.


Gruß,

Chris

PS: Das was du brauchst nennt sich Dynamic Proxy API. DArauf basiert RMI in jeder Hinsicht... RMI ist ansich wirklcih leicht zu implementieren, dank der Dynamic PRoxy API kann mans selbst machen und muss nicht das unflexbile RMI von Java einsetzen..


----------



## tuxedo (13. Dez 2011)

Wenn hier schon Werbung gemacht, dann bitte vollständig:

Eine weitere RMI Alternative: SIMON (siehe auch meine Signatur)

Das ganze ist ebenfalls recht schlank und performant (siehe: SIMON Performance)

Zur Serialisierung allgemein:
Wie wär's mit Externalize? Schlanker und performanter geht's nicht. Du musst nur in allen zu übertragenden Objekten zwei Methoden implementieren. Sowohl RMI als auch SIMON berücksichtigen das. Einfach "implements Externalizable" in die Klassensignatur einfügen und die hinzukommenden Methoden implementieren. In den Methoden dann die notwendigen Instanzvariablen in den Stream schreiben, bzw. lesen. Fertig. Übrigens: Je flacher deine Objektstruktur, desto schneller wird die Standard Serialisierung in Java.
Hast du allerdings eine große/tiefe Objektstruktur und kannst auf das letzte Quäntchen Performance verzichten, macht die Wahl einer schnellen Serialisierungsimplementierung Sinn. 

Gruß
Alex


----------



## Kr0e (13. Dez 2011)

DAs war keine WErbung, er will es lernen und da dachte mir, bevor er sich alles bei google zusammen sucht kann er ja mal reinschauen.. Ich habe sowieso kaum noch Zeit aufgrund meiner Arbeit =(


----------

