Help-Webservice: serverseitiges Interface

[flaite]

Hi,

die Methode CREATETICKET(java.lang.String STRUSER, java.lang.String STRPROBLEM) gibt nicht einfach Ticket.ID zurück sondern ein Konstrukt der Art
Ticket.ID + "(" + errorCode + ")".
sieht ca. so aus:
EFG2347E (errCode:0)

Das erschwert eigentlich die Arbeit am Client.
Es wäre viel besser, wenn es ein ganzes Ticket zurückgeben würde und errorCode ein property wäre,
d.h. eigentlich noch besser errorCode wäre ein i18n Schlüssel für eine Klartextfehlermeldung in den verschiedenen Sprachen.

Ansonsten müsste ich den Rückgabewert erst einmal parsen. Es ist in my not so humble opinion viel besser, das Objektorientiert zu machen. Das heisst ein ganzes Ticket-Objekt wird zurückgeliefert. Ich kann dann einfach so abfragen:

Code

if (ticket.errorCode != 0) {
  throw new ServerException (AppUtils(listErrorKeys(ticket.errorCode)); 
}

oder noch besser (mit i18N Schlüssel): 
if (ticket.errorKey != "") {
 throw new ServerException (AppUtils.get(ticket.errorKey); 
}

String AppUtils.get(String key) ist mein i18n Mechanismus. Mit Nümmernchen müßte auf dem Client nochmal eine extra-Liste aufgebaut werden, die die Nümmernschen zu den i18n-Schlüsseln mappt.

So haben wir eine viel klarere Nachricht. Mit der jetzigen Lösung führen wir da eine Datenstruktur, die extra wieder low-level geparsed werden müßte. Nicht das ich das nicht könnte. Das oben beschriebene ist aber wesentlich einfacher, übersichtlicher und erweiterbarer.

Das ist letztlich ein großer Vorteil von OO.
Die Nachricht dokumentiert sich letztlich selbst.
Die Teilinfos der Nachricht stehen in den Properties des Objekts und müssen nicht aus einer proprietären Struktur rausgeparsed werden.

Gruß Axel

[eknori]

Ticket.ID + "(" + errorCode + ")".

Da bin ich davon ausgegangen, daß der Consumer das durch simple Stringzerlegung in die Bestandteile TicketID und RetCode zerlegt, um mit diesen Infos weiter zu arbeiten.

Ich glaube, ich muss mich davon lösen, so zu denken.

Es wäre viel besser, wenn es ein ganzes Ticket zurückgeben würde und errorCode ein property wäre,

Genau das ist dann die logische Konsequenz.

Dann könnte man auch gleich mit dem Ticket weiterarbeiten ...

[flaite]

Rein technisch ist es nicht so schwierig damit umzugehen.
Nur ist es deutlich einfacher mit einem zurückgegebenen Objekt.
Die Objekte müßten dann jeweils ein Feld Error_msg enthalten.

Gemäß best practices für SOA (Service Oriented Architecture) sollten Fehlermeldungen eigentlich im Header der Nachricht stehen, also von den eigentlichen Rückgabewerten getrennt sein.
Weiss aber nicht, wie man das mit Lotus Webservices machen soll.

Solche Konventionen mögen oft ein bischen übertrieben erscheinen, aber sie machen oft Sinn. Ich hoffe, dass Lotus das blickt. Der Vorteil von SOAP gegenüber konkurrierenden Technologien ist ja, dass sich Toolhersteller auf gewisse Standards verlassen können. Codegenerierung kann hierdurch sicher erleichtert werden.
Z.B. erfordert rein auf der Swing-Seite das Binding Framework von Karsten Lentzsch auch gewisse Konventionen in den Objekten, die Daten halten. Nur konnte ich nach dessen Einführung in die Codebase massig Zeilen löschen und dabei hab ich das alles noch nicht voll verstanden.

Gruß Axel

[eknori]

Weiss aber nicht, wie man das mit Lotus Webservices machen soll.

Die Stelle habe ich leider auch noch nirgendwo gefunden ...

[flaite]

Yup. Ich auch nicht. Aber zumindest können wir die Punkte identifizieren. Dies ist auch nicht so schlimm. Die zurückgesendeten Objekte können beispielsweise ein Feld error_msg enthalten, dass im Client jedesmal abgefragt wird. Bei Rückgabewerten, die kein eigenes Objekt sind, sondern ein SOAP-Typ (String, int, etc) ist das natürlich nicht so schön.
... und jetzt habe ich verstanden, warum im SOAP error-Informationen im header stehen sollen. 
... und wenn wir das alles gut durchdacht haben, können wir uns an Notes.net wenden oder sogar irgendwie zielgerichteter an irgendwelche Lotus Leute herankommen.

Ein wenig allgemeinere Information über den Stand der Dinge:

Ich bin zur Zeit mit Swing Features beschäftigt. Und auch mit dem Adaptieren von Scott Delaps Ideen. Es ist schon teilweise sehr schön. Nur manchmal kapiere ich das eben nicht richtig.
So Ideen wie:
- builder für die Gui Masken
- eine Art anwendungsglobale Benachrichtigungszentrale für Ereignisse aus dem Backend an die GUI
- Carsten Lentzschs Binding & Validation Frameworks

revolutionieren aber geradezu mein Verständnis für GUI-Programmierung. Deshalb sehe ich das als keine vertane Zeit an.
Vieles von dem kann man sehr sicher auch für Eclipse RCP (Hannover), J2ME (java auf mobile) oder Applets in Notes nutzen.
Es benutzt eine ziemlich weite Batterie von Java-Möglichkeiten:
1 Event-Handler steht z.B. als innere Klasse in einer abstrakten Klasse und die den jeweils initialisierenden konkreten Subklassen schiessen einen spezifischen Methoden Namen in den Constructor, der dann in einer Methode des Eventhandlers per Reflection ausgelesen wird.
Und das sensationelle ist: Es macht Sinn 

Ich werd mich bemühen, das irgendwann alles mal zu beschreiben.
Probleme macht zur Zeit v.a. ein Gui Feature:
Wenn ein neues Ticket erstellt wird, soll dieses Ticket in den GUI-Navigatoren sofort vorhanden sein und dort auch ausgewählt sein.
Scheint nicht so einfach zu sein.
Was bereits funktioniert (und Notes hat das nicht): Wenn ein Ticket in z.B. dem View Navigator Tickets-nach-Status ausgewählt wird, dann wird es im Hintergrund auch in allen anderen View Navigatoren ausgewählt.
Swing ist insgesamt ein sehr mächtiges und damit auch nicht ganz leicht zu beherrschendes Framework.
Endgültig werde ich spätestens am nächsten Wochenende (ja, ich weiss), das erste alpha auf sourceforge uploaden. Mark Teichmann hat inzwischen Dev-Rechte auf das Projekt und wir seinen RCP-Eclipse code wohl schon vorher uploaden.


Mir gehts v.a. auch darum, nicht einfach einen look-mummy-its-with-webservice Typ von Beispiel zu erstellen, sondern eine wirkliche Erweiterung von help. Ich habs ja im Wiki geschrieben, dass so Dinge wie die Integration von "globalen Domino-Services" wie Locking und Security in der Praxis die wirkliche Arbeit machen. Aber das ist eben der kreative und software-engineering Teil der Arbeit.

Gruß Axel

[flaite]

Der Webservice für die I18n Daten in Help kann einfach durch Arrays gelöst werden:
http://www-128.ibm.com/developerworks/xml/library/ws-tip-coding.html
(man braucht nur 1 Sprache auf dem Client.
1 Sprache = 2 Arrays. Keys und der Wert der jeweiligen Sprache des Clients. Wenn er eine andere Sprache haben will, muß diese Sprache runtergeladen werden.

Das, was ich hier (http://eknori.dyndns.org/wiki.nsf/pages/GlosSar) als Konfigurationsdaten bezeichnet habe Geschichte, da es hier Bäume an Objekten gibt.
Wär gut, wenn das doc/lit style einfach geht. Ich bin mir nicht sicher.

[eknori]

Gary Devendorf hat bzgl security hier etwas gepostet. Jetzt müsste man nur noch an den Code für den web service herankommen 

[flaite]

you can down load the demo from www.msdomino.net.
... und da ist kein .nsf dabei 

[eknori]

Ich maile Gary einfach mal an ...

[Mark³]

Mark Teichmann hat inzwischen Dev-Rechte auf das Projekt und wir seinen RCP-Eclipse code wohl schon vorher uploaden.

die Hoffnung stirbt zuletzt...

Im Moment komme ich leider nicht dazu, schließlich muss ich vor einem Upload noch ein paar Anpassungen machen. Aber ich werde es auf jeden Fall irgendwann hochladen.

[flaite]

Schmeiss bei dem ibm Beispiel mit doc/lit erst einmal das Handtuch.
Es lässt sich mit den Eclipse-Automatisierungsmethoden von mir erstmal nicht in den Griff bekommen und ich arbeite erstmal mit soap/enc weiter.

[flaite]

Mark Teichmann hat inzwischen Dev-Rechte auf das Projekt und wir seinen RCP-Eclipse code wohl schon vorher uploaden.

noch ein paar Anpassungen machen.

Meinst du das externalsieren von User, Password, Proxy-User, Proxy-Passwort und URL des Webservices?
Einfach in dem generierten Code:
ca. Zeile 27 von WsTicketServiceLocator
// Use to get a proxy class for Domino
    private java.lang.String Domino_address = null;
Ulrichs Adresse entfernen (auf null setzen).
Die restlichen Dinge hast du selber gesetzt. Das weisst du besser als ich.
Das auch alles auf null setzen.
Ich kann das dann ergänzen.
Benutze aber zur Zeit noch ein eigenes und ziemlich blödsinniges Konstrukt, mit der ich diese Dinge einschiesse. Fand das Axis-Zeugs unterdokumentiert.
Wenn jemand Vorschläge zu org.apache.axis.EngineConfiguration hat, immer her damit. Ich bin inzwischen soweit, dass ich nächste Woche die große Analyse-Runde im Source-Code vom Springframework starte, weil die das in ihren remoting Paketen irgendwie gelöst haben.

Du solltest auf jeden Fall alles auf null setzen bevor du eincheckst, da in cvs die alten Versionen nicht gelöscht werden, es sei denn ich bitte sourceforge.net explizit da drum. Ich darf das selbst als Projekt-Admin nicht selbst machen.

Gruß Axel

[flaite]

Hier gibt es übrigens eine Menge hochwertige Information von Sun zu Webservices:
http://www.javapassion.com/webservices/