Lösungsweg Client Server Kommunikation Fehlermeldung ausgeben

[0plan]

Hallo,
ich bin gerade dabei, eine Definition eines Interfaces für eine RMI Applikation zu definieren. Mir kommt gerade die Frage, wie ich es am besten löse, wenn der Server eine Aufgabe aufgrund möglicher Umstände nicht umsetzen kann. Der Client muss hierüber ja benachrichtigt werden, wenn z.B. das erstellen eines Tickets (Support System) auf der Datenbank nicht durchgeführt werden konnte.

Soll ich dann für solche Methoden der Server Klasse boolean nehmen, welche dem Client true liefert wenn die Anfrage an den Server erfolgreich war und die Aufgabe abgeschlossen wurde? Oder soll ich ein Nachrichtensystem implementieren, welches den Client nach jedem Methodenaufruf des Servers über den Status der Aktion informiert?


Beispiel:

Client:

public void createTicket(){
      if(server.createTicket()) 
                System.out.println("Ticket wurde erstellt");
      else
            //Gebe Fehlermeldung aus

}

Server:

public boolean createTicket(){

 try{
      //Erstelle ein Ticket
      return true;
 }catch (Exception ieineException)(
     Serverlog.createEvent(new Event(e.getMessage());
}
   return false; //Indikat für Fehler bei der Erstellung

}

Wie macht man sowas am besten?

 

[freez]

Soll ich dann für solche Methoden der Server Klasse boolean nehmen, welche dem Client true liefert wenn die Anfrage an den Server erfolgreich war und die Aufgabe abgeschlossen wurde? Oder soll ich ein Nachrichtensystem implementieren, welches den Client nach jedem Methodenaufruf des Servers über den Status der Aktion informiert?

Das kommt ganz darauf an, ob der Client wissen muss, was schief gelaufen ist und ob mehrere Dinge schief gehen können. Ein boolean zeigt dir ja lediglich JA/NEIN an. Da kannst du keine weiteren Informationen transferieren. Wenn du dem Client aber genau mitteilen willst, was schief gelaufen ist, weil z.B. ein User eine Eingabe verkehrt gemacht hat, dann musst du darüber nachdenken, wie du diese Informationen zum Client transportierst.

Lange Rede, kurzer Sinn: es kommt ganz auf deine Anforderungen an.

 

[0plan]

Danke für deine Antwort. Der Client muss wissen was schief gelaufen ist, zwar nicht gerade irgendwelche SQL-Exceptions aber zumindest das ein Ticket o.ä. nicht erstellt werden konnte.

Da die Clientmethoden ja abfragen ob der server true oder false liefert, kann man die Fehlermeldung ja hardcodiert einfügen. If true -> nichts , else -> (in Methode ticketErstellen()) ticket konnte nicht erstellt werden.

Meine Frage bezieht sich ledeglich darauf, wie man es am besten Lösen kann, entweder in jeder Methode eine hartcodierte Fehlermeldung für die jeweilige Methode z.B. create, update usw oder ein MessageSystem mit Rückgabe von Events welche vom Client ausgelesen werden koennen.

 

[Michael...]

Die Methoden könnten statt eines boolean einen Fehler Code (int) zurückliefern, der auf Clientseite interpretiert werden kann.

 

[0plan]

Das ist eine nette Idee. Ich würde also z.B. eine statische Klasse ErrorMessage erstellen und diese interpretieren?

 

[Michael...]

Die Methoden liefern einen int zurück. z.B:
0 - Methode fehlerfrei durchlaufen
1 - Ticket konnte nicht angelegt werden
2 - fehlende Berechtigung
...
Der Client muss dann eine Liste oder ähnliches haben/kennen die Fehlermeldung zur Zahl enthält. Eine Lösung mittels statischer Klasse wäre da denkbar.

 

[Spacerat]

Also ich halte die Entscheidung immer wie folgt: Wieviele Informationen passen in ein Bit (boolean)? Richtig: Nur zwei. In eine Message passen dagegen viel viel mehr, unter anderem auch "TRUE" und "FALSE". Ergo macht die Rückgabe boolscher Werte nur dann Sinn, wenn zu keiner Zeit (aktuell oder in zukünftigen Erweiterungen) mehr als zwei Werte zustande kommen können, z.B. bei simplen Statusabfragen wie "isRunning()" oder "isActive()". Ich würde daher grundsätzlich von vorneherein erstmal ein Messagesystem verwenden, wenn eine Methode allem anschein nach zukünftig mehr Informationen bereitstellen könnte, wie in deinem Fall.
@Michael: Eine statische Klasse ist schon was... wenn man's übertreiben will, lässt sie sich evt. sogar noch als externer Dienst implementieren, der gestartet wird, sobald er von einer Anwendung benötigt wird und beendet, wenn die letzte Anwendung, die ihn benötigt geschlossen wird. MAW.: Ein Port, der dynamisch für alle laufenden JVMs verfügbar ist und sozusagen einfache Inter-Prozess-Kommunikation ermöglicht. Über so etwas grüble ich schon jahrelang nach.
[EDIT]Das zuletzt von mir erwähnte, führt an dieser Stelle natürlich zu weit, weil es selbst ja bereits eine Client-Server-Komunikation darstellt. Ist mir nur zu spät aufgefallen. [/EDIT]

 

[0plan]

Danke für eure Antworten, ich werde es mit einer statischen Klasse "ErrorMessage" lösen. Thread wird geschlossen.

 

[FArt]

Thread wird geschlossen.

Wieso?

Ich finde das ist eine sehr suboptimale Lösung. Java bietet von sich aus eine sinnvolle Möglichkeit mit Fehlern umzugehen: Exceptionhandling. Warum jetzt davon abweichen? Nur weil zufällig Remote-Kommunikation dazwischen liegt?
Advantages of Exceptions (The Java™ Tutorials > Essential Classes > Exceptions)

Für Fehler sollte es wohldefinierte Ausnahmen, geben, die an passender Stelle behandelt werden.

Ein Punkt kann sein, was in diesem Fehler als Information enthalten ist. Es ist nicht sinnvoll, die Exceptions des Servers als Cause anzuhängen. Es kann sein, dass die Exception auf dem Client als Klasse gar nicht vorhanden ist. Ausserdem ist das immer auch ein Sicherheitsproblem, weil auf der Clientseite zu viele Informationen über die Serverseite zu sehen sind. Hier kann ein Fehlercode durchaus sinnvoll sein, während die komplette Exception auf der Serverseite geloggt wird. Das kann durchaus die statische "ErrorMessage" Klasse Verwendung finden.

 

[tuxedo]

Kann FArt zur zustimmen. Der korrekte weg wäre, am Server dedizierte Exceptions zu werfen. Diese gehören dann zur Interfacebeschreibung und sollten, wie die Interface-Klassen auch, dem Client bekannt sein.

Allerdings stellen Exceptions "Ausnahmen" dar, weswegen man Exceptions nicht für alles benutzen sollte, sondern nur für Ausnahmen. Ein Negativ-Beispiel wäre eine "LoginSuccessfulException" zu werfen wenn der Login geklappt hat.

Bzgl. Fehlercode: Man kann Exceptions auch einen wieder auslesbaren Fehlercode verpassen. Und ja: Tieferliegende Serverexceptions sollte man NICHT an den Client weiterreichen.

- Alex

 

[FArt]

Allerdings stellen Exceptions "Ausnahmen" dar, weswegen man Exceptions nicht für alles benutzen sollte, sondern nur für Ausnahmen.

Ja, das hatte ich noch vergessen. Hier unterscheiden wir uns eben nicht von "normalem" Java Code. Somit gilt es natürlich auch, die gleichen Anti-Pattern zu vermeiden, z.B. Exception-Handling Antipatterns | Java.net

Ausnahme ist eben Log-And-Throw an der Servergrenze.

 

[Spacerat]

@Fart & tuxedo: Euch ist schon klar, dass Exception-Handling nur innerhalb einer Anwendung greift? Der Server stellt einen Fehler bei der Verarbeitung der Anforderung fest, sei es durch Exceptions oder fehlerhafte Rückgabewerte. Irgendwie muss das jetzt dem Clienten mitgeteilt werden und das geht nicht per Exception sondern nur per Übermittlung von Messages oder simplen Fehlercodes. Ob der Client aufgrund einer erhaltenen Fehlerrückmeldung seinerseits 'ne Exception wirft ist dann Sache des Entwicklers. Ich nehme mal an, ich hab' euch in euren Ausführungen nur missverstanden und ihr wolltet blos sagen, dass man Exceptions keinesfalls einfach serialisieren sollte, obwohl sie Serializable implementieren.

 

[tuxedo]

@Spacerat

Im Fall vom RPC/RMI/SIMON/... definiert sich die Schnittstelle zwischen Client und Server durch die "Remote-Interfaces". Diese dürfen sehr wohl Exceptions beinhalten.
Natürlich ist es Blödsinn ein Server-Interface beim Login eine JPA-Irgendwas-Exception an den Client weiterreichen zu lassen. Es spricht aber nix dagegen selbst eine "LoginFailedException" anzulegen und diese im Falle eines fehlgeschlagenen Logins zu werfen und folglich auch dem Client direkt mitzuteilen. Diese Exception ist damit Teil der Schnittstellendefinition zwischen Client und Server. Eben so, wie die Remote-Interfaces auch.

Wer will kann, bleiben wir beim Beispiel Login, noch weitere Exceptions werfen. Ein Beispiel:

LoginProcessFailedException -> Es trat ein Fehler im Server auf, weswegen der Login fehl schlug (Details ggf. in abfragbarem Error-Code). Beispielsweise war der interne LDAP nicht erreichbar oder so.
AuthenticationFailed -> Der angegebene Benutzer konnte nicht authentifiziert werden.
...

Aber in Remote-Verbindungen, welche auf beiden Seiten Java einsetzt, das ganze jetzt ausschließlich auch Error-Codes laufen lassen und vielleicht sogar nicht auf Client-Seite wieder zurück in eine Exception zu übersetzen.. Das ist IMHO Blödsinn.

Wenn man aber kein RMI und Co benutzt, sondern z.B. ein eigenes Protokoll implementiert: Dann wäre ein Error-Code unter Umständen sinnvoller als eine Exception zu serialisieren.

Ausnahmen bilden Libraries die selbst einen RPC Mechanismus darstellen Die kommen i.d.R. nicht drum rum Exceptions in irgend einer Art und Weise zu serialisieren und deserialisieren.

Aber selbst wenn man kein RPC selbst programmiert könnte es sinnvoll sein eigene Exception-Klassen für die Remote-Schnittstelle zu definieren und diese zu serialisieren. Wohlgemerkt: "könnte" ...

- Alex