3. Überblick

Die velo..connect-Spezifikation geht von folgender Modellsituation aus: Zwischen einem Client (typischerweise das Warenwirtschaftsprogramm eines Einzelhändlers) und einem Server (typischerweise das Warenwirtschaftsprogramms eines Großhändlers oder Herstellers) werden Daten ausgetauscht, um bestimmte Geschäftsvorfälle, wie z. B. das Bestellen von Ware, auszulösen. Für die Zwecke dieser Geschäftsvorfälle vertritt der Client den Käufer und der Server den Verkäufer.

Die Kommunikation zwischen Client und Server und die damit ausgelösten "Seiteneffekte" können wir grob in drei Schichten unterteilen:

Transport:
Übermittlung der Daten gemäß etablierter Standardprotokolle, wie z.B. http.
Nachricht:
Syntax der übermittelten Daten; Regeln, in welcher Reihenfolge, welche Daten zu übermitteln sind
Geschäftsvorfall:
Bedeutung der übermittelten Daten; welche Geschäftsvorfälle werden ausgelöst; welche Beziehung haben die übermittelten Daten zu bestehenden Warenwirtschaftssystememen.

Gegenstand dieser Spezifikation sind die Schichten Nachricht und Geschäftsvorfall. Die Syntax der Daten wird mittels eines XML-Schemas festgelegt (Abschnitt 4, „Veloconnect XML-Schema“). Die Abfolge der Nachrichten wird im Überblick im folgenden behandelt und detailiert in Abschnitt 6, „Operationen“, Abschnitt 7, „Transaktion: Order“ und Abschnitt 8, „Transaktion: OrderInOnlineShop“. Dort erfolgen auch die Festlegungen zur Schicht Geschäftsvorfall, soweit sie in dieser Spezifikation erforderlich sind. Gerade weil der Datenaustausch über eine velo..connect-Schnittstelle den Zweck hat, Geschäftsvorfälle in der realen Welt auszulösen, wie z.B. das Bestellen von Ware, ist es nötig stillschweigende Voraussetzungen, die beim Übergang zwischen der Schicht Nachricht und Geschäftsvorfall eine Rolle spielen, explizit zu machen. Ferner wird der Käufer aufgrund der Informationen, die ihm übermittelt werden, Entscheidungen treffen; er sollte also darauf vertrauen können, dass die übermittelten Informationen von hinreichender Qualität und unmißverständlich sind. (Eine beliebte Quelle von Mißverständnissen sind hier Mengen- und Preisangaben.)

Der Nachrichtenaustausch zwischen Client und Server setzt sich aus Operationen zusammen. In einer Operation übermittelt der Client eine Anfrage (Request) an den Server und erhält von diesem eine Antwort (Response). Sowohl Anfrage als auch Antwort werden als XML-Dokumente festgelegt. Genauer: zu jeder Nachricht wird angegeben, welches Element aus dem in der Spezifikation festgelegten XML-Schema (Abschnitt 4, „Veloconnect XML-Schema“) als Wurzelelement der Nachricht verwendet wird. Komplexere Szenarien des Nachrichtenaustauschs werden als Transaktionen modelliert. Eine Transaktion setzt sich aus mehreren Operationen zusammmen, die in genau definierter Weise aufeinanderfolgen (Abschnitt 3.2, „Transaktionen“).

Die Art und Weise wie eine Nachricht übermittelt wird (Transportschicht), wird durch die Bindung festgelegt. Die Bindung legt fest, welches Protokoll zur Übertragung verwendet wird und wie die Nachricht zu serialisieren ist.

Bei jeder einzelnen Operation oder Transaktion wird angegeben, ob diese verbindlich, oder ob diese optional ist. Die Verbindlichkeit kann auch so formuliert sein, dass aus mehreren Operationen oder Transaktionen mindestens eine auszuwählen ist. Ein velo..connect-konformer Server muss eine verbindliche Operation in mindestens einer Bindung implementieren.

Zu den verbindlichen Operationen gehört die GetProfile-Operation (Abschnitt 6.5, „Operation: GetProfile“). Mittels dieser Operation kann ein Client ermitteln, welche Transaktionen und Operationen ein Server mit welchen Bindungen unterstützt.

3.1. Bindungen

Die gegenwärtige Version von velo..connect kennt vier Bindungen:

  • URL
  • URL-S
  • XML-POST
  • XML-POST-S

Regel: Standard-URL.  Ein velo..connect-konformer Server ist unter einer festgelegten Standard-URL zu erreichen. Diese wird dem Kunden (Käufer) zusammmen mit weiteren Zugangsparametern wie z.B. Benutzername und Passwort mitgeteilt. Die GetProfile-Operation wird unter der Standard-URL verarbeitet. Für alle anderen Operationen können abweichende URLs festgelegt sein, die Antwort auf einen GetProfile-Request enthält diese Informationen (Abschnitt 6.5, „Operation: GetProfile“).

Regel: HTTP-Protokoll (Client). Der Client implementiert das HTTP/1.1 Protokoll [8] vollständig (z.B. durch Benutzung einer Standardbibiothek). Die vom Server gelieferte Nachricht wird nur dann gemäß dieser Spezifikation behandelt, wenn die Übertragung gemäß des HTTP-Protokolls erfolgreich abgeschlossen ist. Sofern der Server einen Redirect (HTTP-Status-Code 3xx) vorschlägt, ist diesem zu folgen.

Regel: URL-Bindung.  In der URL-Bindung wird die Anfrage als Folge von Parametern serialisiert, die gemäß des Medientyps application/x-www-form-urlencoded als Zeichenkette kodiert wird. Wie eine Anfrage als Folge von Parametern aufzufassen ist, wird jeweils bei den einzelnen Operationen angegeben. Zur Durchführung der Operation wird entweder vom Client mittels der GET-Methode die URL-Adresse angesteuert, die sich als Verkettung der zur Operation gehörigen URL, dem Zeichen "?" und den kodierten Parametern ergibt, oder der Client überträgt mittels der POST-Methode die kodierten Parameter an die zur Operation gehörige URL. Die Auswahl zwischen GET und POST bleibt dem Client überlassen; d.h. der Server muss beide Varianten implementieren, wenn er die URL-Bindung realisiert. Die Antwort wird als XML-Datei serialisiert und als Inhaltstyp application/xml zurückgeliefert. Die URL-S-Bindung unterscheidet sich von der URL-Bindung nur darin, dass an Stelle von HTTP/1.1 [8] zur Übermittlung das Protokoll "HTTP over TLS" (https, rfc 2818) [9] verwendet wird.

Regel: XML-POST-Bindung.  Bei der XML-POST-Bindung werden sowohl Anfrage als auch Antwort als XML-Datei serialisiert und als Inhaltstyp application/xml übertragen. Die Anfrage verwendet die POST-Methode des HTTP/1.1-Protokolls. Die XML-POST-S-Bindung unterscheidet sich von der XML-POST-Bindung nur darin, dass an Stelle von http zur Übermittlung das Protokoll https verwendet wird.