Grundlegende Konzepte

Die veloconnect-Spezifikation geht von folgender Modellsituation aus: Zwischen einem Client (typischerweise das Warenwirtschaftsprogramm eines Einzelhändlers) und einem Server (typischerweise das Warenwirtschaftsprogramm 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 Warenwirtschaftssystemen.

Gegenstand dieser Spezifikation sind die Schichten Nachricht und Geschäftsvorfall. Die Syntax der Daten wird mittels eines XML-Schemas festgelegt. Die Abfolge der Nachrichten wird im Überblick im folgenden behandelt und detailiert. Dort erfolgen auch die Festlegungen zur Schicht Geschäftsvorfall, soweit sie in dieser Spezifikation erforderlich sind. Gerade weil der Datenaustausch über eine veloconnect-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 Missverstä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 als Wurzelelement der Nachricht verwendet wird.

Komplexere Szenarien des Nachrichtenaustauschs, bei denen der Server Zustandsinformationen vorhalten muss, werden als Transaktionen modelliert. Eine Transaktion setzt sich aus mehreren Operationen zusammen, die in genau definierter Weise aufeinanderfolgen. Die Zustandsinformationen auf dem Server, wie z.B. die Daten einer Bestellung oder die Ergebnisse einer Artikelsuche, werden dabei über eine TransactionID referenziert, die von Operation zu Operation weitergegeben wird.

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 oder die Umsetzung einer Operation die Umsetzung von anderen Operationen erzwingt. Ein veloconnect-konformer Server muss eine verbindliche Operation in mindestens einer Bindung implementieren.

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