IBM Lotus Domino, Webservices, Datumswerte und US-Programmierer

[m3]

Webservices sind ja eine tolle Sache. Alles ist genau spezifiziert, das ganze funktioniert plattformübergreifend auf Basis von XML. Soweit zumindest die graue Theorie.

Wahr ist vielmehr ...

Datumswerte werden im Rahmen von Web Services, so die Simple Object Access Protocol (SOAP) 1.1 Spezifikation gemäß der W3C Spezifikation XML Schema Part 2: Datatypes definiert. Man beachte, dass an beiden Spezifikationen IBM-Mitarbeiter beteiligt waren. Ein Übergabewert vom Typ Datum (xsd:date) hat daher das Format "YYYY-MM-DD". Also vier Ziffern für das Jahr, ein Bindestrich (Minus), dann zwei Ziffern für den Monat (01-12), wieder ein Bindestrich (Minus) und dann nochmals zwei Ziffern für den Tag (01-31). Nicht sonderlich schwierig, wenn man den übergebenen Wert auseinanderzwirbeln will -- möchte man meinen.

Wechseln wir mal von der grauen Theorie zu Praxis in der Form von Web Services unter IBMs Lotus Domino 7 Server. Dieser kann ganz wunderbar Web Services anbieten. Ich hab mal ein kleines, primitives geschrieben, um das Problem zu zeigen:

Code

%INCLUDE "lsxsd.lss"

Class i18n
	
	Sub NEW
	End Sub
	
	' Call this webservice twice! Once with a a day > 12 and once with a day <= 12
	' Notice the difference? ;)
	Function GetMonthFromDate(parameter As XSD_DATE) As String
		Dim datetime As NotesDateTime
		
		Set datetime = parameter.GetValueAsNotesDateTime()
		
		Print "Date: " & Cstr(datetime.DateOnly)
		Print "Month: " & Cstr(Month(datetime.DateOnly))
		
		GetMonthFromDate = "Month: " & Cstr(Month(datetime.DateOnly))
		
	End Function
	
End Class

Schnuckelig, oder? Macht im Prinzip nichts anderes, als aus dem Übergebenen Datum den Monat auszulesen. IBM war sogar so nett/klug/vorausschauend, den XSD_DATE Wert als NotesDateTime Wert zurückzuliefern, damit man korrekt mit den Datumswerten arbeiten kann (ich sehe Bernhard gerade vor Freude auf- und ab hüpfen).

Um so größer war dann mein Erstaunen, als ich dieses Webservice dann mit ein paar Werten aufrief.
Ruft man dieses nämlich mit dem (angeblichen) Todestag von Elvis (2007-08-16) auf, so ergibt sich folgende (erwartete) Ausgabe auf dem Server:

Code

16.08.2007 15:47:25   HTTP Server: Agent printing: Date: 16.08.2007
16.08.2007 15:47:25   HTTP Server: Agent printing: Month: 8

Nimmt man allerdings ein einen Tag <= 12, z.B. den Geburtstag von Ian Anderson (2007-08-10), so sieht das etwas seltsamer aus:

Code

16.08.2007 15:49:47   HTTP Server: Agent printing: Date: 08.10.2007
16.08.2007 15:49:47   HTTP Server: Agent printing: Month: 10

Hallo? Da muss man schon sehr bewusst schlecht und falsch programmieren, wenn man diese Konvertierung verhaut, oder?

Und bevor jemand fragt - der INI-Parameter DateOrder hat KEINEN Einfluss auf die Konvertierung im Web Service.


Anbei noch die Demo-DB, ich geh jetzt mal einen ESR bei der IBM aufmachen. Testen lässt sich das ganze recht bequem mit http://www.soapui.org/ , das dazugehörige WSDL gibts unter http://server/pfad/ws_i18n.nsf/i18n?WSDL

[flaite]

Das ist übrigens, was ich an der Eclipse-Strategie mag. Das ist ein nachhaltiger Ansatz. Ansonsten - bei Webservices, der DB2 Integration, den verschiedenen Möglichkeiten der Integration mit Websphere - wars immer groß angekündigt und dann irgendwie halbherzig. Bob Balaban hat selber schon von Modernisierungsbedarf bei der Webservice story gesprochen.

In SOAP habein sich auf jeden Fall document-type und nicht rpc-type Webservices durchgesetzt. Bei Domino bleibts einfach RPC-type.
Bei Document-Type Webservices tauschen Consumer und Producer eigene xml-Dokument-Fragmente mit möglicherweise eigenen DTDs/Schemas aus. Da können sich Consumer und Producer auf ein Datumsformat einigen. 
 
Im übrigen ist Domino - zumindest in meinen Umfeld - viel eher als Webservice Consumer und nicht als Producer gefragt (z.B. auf die gut implementierten SAP Webservices zuzugreifen. Dafür gibts aber nicht. Es sei denn, man kann das selber in Java mit Hilfe von openSource Bibliotheken in Domino Agenten programmieren.

Webservices müssen nicht unbedingt SOAP sein. REST und POX werden in der Praxis auch sehr oft eingesetzt.
Ich hab mich in einem Fall aus guten Gründen (Größe der ausgetauschten Nachrichten, also "Performance") für einen serverseitigen Webservice gegen das Domino Design Element entschieden und hab die entsprechende POX-Infrastruktur selbst an einem Wochenende geschrieben (noch nicht mal für meine damalige Consulting, sondern eine projektbeteiligte Consulting ohne expliziten Auftrag)

Gruß Axel

[m3]

Axel, das mag schon alles stimmen, dass man sich andere DTDs/Schemata aus machen kann, es elegantere Lösungen gibt und das Ganz sowieso einer Überarbeitung bedarf.

Aber warum begreifen die Programmierer in den USA noch immer nicht, dass es unterschiedliche Datumsformate gibt? BZW - was ist so schwer daran, YYYY-MM-DD korrekt zu parsen? Das schafft jeder C(++) Anfänger.

[flaite]

Solche Bugs passieren mir täglich, wenn ich unter Zeitdruck Projekte durchführe (wenn ich in der Umgebung keine Unit-Tests einsetzen kann).
Der Bug ist interessant, weil es so aussieht als hätte da jemand was getürkt.

Code

if (month > 12) {
  date = month;
  month = date;
}

Viel schlimmer find ich, dass das nicht viel früher aufgefallen und gefixt worden ist.
Zeigt aber auch, dass das Design-Element Webservices in Domino nicht so oft eingesetzt wird.

Im Grunde ist die ganze Webservice Story in Domino sowieso hoffnungslos. Intern basiert das auf dem java jakarta Projekt Axis1. Inzwischen gibts aber das völlig neu (zum größten Teil von 2 Entwicklern aus Sri Lanka, btw.) als Axis2. Es gibt interessante benchmarks in denen Axis2 wg. moderneren XML Parsern mehrfach (12 bis 40x) schneller abgeschnitten hat.

Gruß Axel

[datenbanken24]

Martin,
glaubst Du, Elvis lebt ?

[m3]

Das ist keine Frage des Glaubens, ich weiß es!