SIMON

Hallo zusammen (ich hoffe das liest jemand),

ich hab vor ein paar Tagen auf java-forum.org eine Diskussion gestartet wie man SIMON noch einfach handhabbar machen kann.

Ergebnis bis dato:

1) Das Markerinterface "SimonRemote" stört etwas.

Durch dieses Interfave muss man gegebene Strukturen für die Benutzung mit Simon anpassen und unnötig Sourcecode ändern

2) "throws SimonRemoteException" muss weg

Es scheint wenig Sinn zu machen jeden Remote-Call mit einem try/catch zu umzingeln und zu versuchen auf Fehler zu reagieren. In den allermeisten Fällen kann man 'eh nicht individuell darauf reagieren und es bleibt einem nichts anderes übrig als die Verbindung komplett zu aufzubauen.

Zur Umsetzung:

Fangen wir mit 2) an:
Die Umsetzung ist recht einfach und sollte keine kompatibilitätsprobleme mit sich bringen: Ich ändere die Exception von "Exception" auf "RuntimeException". Somit ist man nicht mehr gezwungen die Exception zu fangen. Damit das Interface "sauber" bleibt und man nicht an jede Methode "throws SimonRemoteException" schreiben muss, wird der check für diesen Signaturteil noch entfernt.

Wer individuell auf die Exception reagieren will kann nach wie vor ein try/catch drum rum setzen. Zum zentralen erkennen eines Verbindungsabbruchs gibts in der Klasse Simon die Methoden "addClosedListener" und "removeClosedListener", mit denen man einen Listener für genau dieses Event registrieren kann.

Zu 1):

Nun, hier wird's schon komplexer. Ich dachte eigentlich ich könne auf diese "Markierung" komplett verzichten. Aber dem scheint nicht so. Grund: Jedem Remote-Call kann man prinzipiell wieder ein Remote-Objekt mitgeben, das das Gegenüber für "Callbacks" benutzen kann. Nun. Fällt diese Markierung - die "normale" Objekte von "remote objekten" unterscheidet - weg, dann ist das Chaos vorprogrammiert. Man überlege nur was was passiert wenn ein simples Containerobjekt übermittelt wird und der Gegenüber mit getter und setter Methoden versucht operationen auf diesen Container auszuführen. Simon wäre nicht mehr in der Lage zu unterscheiden ob es sich um ein "übertragenes" Objekt handelt, welches nun lokal vorliegt, oder um ein Remote-Objekt, welches nun auf der anderen Seite lebt und dessen Methoden auch dort aufgerufen werden müssen. Allein schon um die Remote-Kommunikation auf's wesentliche zu reduzieren sollte vorher bekannt sein ob es ein RemoteObjekt ist oder ein lokales.

Und hier dran knabbere ich zur Zeit. Alternative zum Marker-Interface ist eine Annotation. Aber auch die muss ins Interface womit wieder Code angepasst werden muss.

Die eine oder andere Idee hab ich jedoch:

Idee 1: Ähnlich wie bei Spring Remoting könnte man in einer XML deklarieren welche Klasse ein RemoteObjekt sein kann.
Idee 2: Simon müsste eine Art "register remote object" Methode anbieten mit der man das RemoteObjekt als solches "anmelden" kann

Bin mir noch nicht ganz im klaren darüber welches die Beste Variante ist und ob es noch bessere gibt. Aber meistens fällt mir beim "runterschreiben" meiner Ideen noch was besseres ein (heute ausnahmsweise mal nicht :-( ).

Auch weiß ich noch nicht wie ich das mit der Rückwärtskompatibilität mache: Mache ich gleich ein neues Major-Release das inkompatibel zum letzten ist? Dann würde ich mir evtl. die Updater vergraulen. Oder biete ich einfach eine zweite/dritte Alternative Möglichkeit an und lasse die bestehende Funktionalität so wie sie ist?

Ihr seht schon... Das ist hier mehr ein Brainstorming :-)

Wer noch weiter Ideen hat: Nur her damit.

Gruß
Alex