Help Webservices: clientseitiges Interface

[flaite]

Hi,

weiteres Vorgehen:
Ich baue nun MySQL als lokalen Cache für den Client ein.
D.h: Man kann auch ohne Verbindung zum Server mit den Tickets arbeiten.
Für spätere Versionen kann dann die MySql mit einem einfacheren RDBMS System ersetzt werden.

Relativ bald werde ich Andreas Schmidt eine Beschreibung schicken wie er auf seinem Rechner eine Version zum Laufen bekommt. Theoretisch ist das sehr einfach und ich versuche alles, um dieses Aufsetzen des Projekts noch einfacher zu machen.
Grundsätzlich sind es 3 Schritte:
1. Code aus sourceforge.net in Eclipse runterladen (ist weitgehend automatisiert, man muß nur in der Team-Umgebung von Eclipse ein paar Einstellungen machen).
2. Datenbank in MySQL einrichten: Dafür wird es ein Skript geben. Das Script befindet sich im Projekt von Sourceforge, das in Schritt 1) runtergeladen wurde.
3. Zusätzliche serverseitige Komponenten der !!!Help!!! Datenbank kopieren. Diese Zusatz-Gestaltungselemente werden als .nsf im sourceforge Projekt sein und müssen in die eigene !!!Help!!! Version kopiert werden (notes mässig).

Zumindest möchte ich das erstmal mit jemanden ausprobieren, den ich persönlich kenne.

Ich werde aus eigenem Interesse versuchen, Partizipation auch für Leute ohne großartige Java-Kenntnisse irgendwie zu ermöglichen. Das kann in den serverseitigen notes-Webservices liegen oder in übersichtlichen aber nicht-total-langweiligen Abschnitten der Anwendung.

Technologisch interessante Punkte sind:
- es werden moderne Frameworks und eine zentrale Event-Management Architektur für Java-Desktop Anwendungen eingesetzt (Binding & Validation Frameworks, Frameworks für Swing-Thread Handling)
- es wird Hibernate für die Persistenz in eine RDBMS als lokaler cache benutzt.
- es wird sich Gedanken über die Implementierung von Service Oriented Architecture Ideen in eine Anwendung gemacht, in der Domino als Producer von Soap/Enc Webservices  fungiert.
- die ewigen Fragen bzgl. eines effizienten architektonischen sowie design- und codemäsigen Aufbaus.

Sobald sich etwas neues tut, werde ich es in diesen Thread posten.

Zumindest bis zur cebit, werde ich jobmässig sehr viel zu tun haben, aber ich versuch das Projekt bis dahin auf Andreas Schmidt seinen Rechner bringen.

Bezüglich der grundsätzlichen Machbarkeit bin ich optimistisch und ich commite eigentlich immer mal wieder gegen das code Repository auf sourceforge.

Gruß Axel

[flaite]

Ich baue jetzt Replizier - und Client-Offline Fähigkeit mit der lokalen Datenbank ein. Das war noch ein bischen frickliger. Jedenfalls scheint es zu funktionieren.
Auf dem Client gibt es ein lokales RDBMS. Zur Zeit MySql. Wird aber später mit vermutlich Derby ersetzt. Derby und HQL sind extra dafür gebaut. So abwegig ist die Idee mit dem lokalen RDBMS also nicht.  Und nein. Der Anwender merkt davon gar nichts.
Danach integriere ich noch die Todos. Auch ein bischen fricklig.
Und die Anhänge runterladen wird auch nicht ganz so langweilig.
Ok. Dem Client die Regeln des Notes-Locking Mechanismus beizubringen wird auch nicht super-einfach.

Integration von Konfiguration & I18n Daten sehe ich dann aber eher als Fleissaufgaben. Und dann muss ich noch alle Felder der BugReports holen.

Natürlich noch das ganze ein bischen rund machen.

Hibernate rocks 

Gruß Axel

[Mark³]

das hört sich ziemlich kewl an

mit RPC wäre das vermutlich alles etwas einfacher, aber als Swing-Client ist die Programmierung sicher aufregender.

P.S. ich hatte mal probiert ins sourceforge-Projekt was hochzuladen, aber in dem ganzen Kram mit SSH und putty etc bin ich irgendwann steckengeblieben. Hab im Moment praktisch null Zeit dafür.

[flaite]

mit RPC wäre das vermutlich alles etwas einfacher, aber als Swing-Client ist die Programmierung sicher aufregender.

Tja. Als Suleimanist.

'we just rewrote everything using this shiny object we found on the street!' noise

Hmmm. Bin momentan der Meinung, dass "simplicity" von neuen frameworks/plattformen tendentiell stark überhyped wird. Swing ist nicht so kompliziert. Kompliziert bin ich, wenn ich tagelang ein shiny nice feature implementieren will, das vielleicht gar nicht so wichtig ist.
Und OO...
... ist keine "natürliche Abbildung" der Realität ...
... und komplex...
... aber gut.

Was ist Replizierung?
2 Datenbestände tauschen nur die Datensätze aus, die sich verändert haben. Hab natürlich keine Feld-Replizierung, sondern Datensatz/Dokumentreplizierung. Und das ist nicht so schwierig. 

P.S. ich hatte mal probiert ins sourceforge-Projekt was hochzuladen, aber in dem ganzen Kram mit SSH und putty etc bin ich irgendwann steckengeblieben. Hab im Moment praktisch null Zeit dafür.

Wenn es einmal konfiguriert ist, braucht man da nix mehr einstellen. Je nach tages- oder nachtform schmeisst sourceforge manchmal gerne broken-pipe-exceptions oder so ähnlich. Aber das ist nicht so schlimm.

Gruß Axel

[flaite]

Und nun:
Diese ganze Replizierlogik stellt sich als ein praktisch 100% offensichtlicher Einsatzfall für Aspektorientierte Programmierung (AOP) heraus.
 
Ich habe eine Menge an Remote Calls.
Die Replizierlogik ist immer gleich.
Ich copy-und-paste die Replizierlogik in jeden dieser Remote Calls.

Ich werd das jetzt copy und pasten, weil ich zu wenig Erfahrung mit AOP habe.
Und später mit AOP ersetzen.
Damit kann ich den copy-und-pasted code in einen Aspekt packen.

Yee-Ha

Axel

Ranch Hand
www.Javaranch.com