Gesicherte Zustellung für B2B-Web-Services: Punkt-zu-Punkt-Verwendungsmuster
Bei diesem Verwendungsmuster verkauft ein Hersteller seine Produkte über ein Netz verbundener Händlerunternehmen. Dieser Hersteller hat ein Pilotprojekt erstellt, um die IT-Integration zwischen seiner eigenen Einzelhandelsorganisation und einem halben Dutzend der größten und wichtigsten Händler zu verbessern.
Vorhandene technische Lösung
Früher wurde B2B-"e-commerce" (Business-to-Business) über elektronischen Datenaustausch (EDI, Electronic Data Interchange) durchgeführt. EDI ist eine Gruppe von Standards für den Inhalt und die Formatierung von B2B-Nachrichten. Beispiele für diese Standards und Nachrichten finden Sie auf der Webseite United Nations Directories for Electronic Data Interchange.
Wenn die Identitäten der DFV-Partner bekannte sind und sich nicht ändern, ist der Einsatz von Nachrichtendefinitionen gemäß Branchenstandard nicht zwingend erforderlich. Obwohl andere XML-basierte Standards für die Durchführung von B2B-E-Commerce (z. B. die OASIS-Spezifikationen Electronic Business using eXtensible Markup Language (ebXML)) verfügbar sind, hat sich der Hersteller dafür entschieden, den Einsatz von Web-Service-Technologien zu untersuchen, und verwendet WSDL-Dokumente aus einer Reihe von Quellen, um die Serviceschnittstellen zu definieren.
Die Interaktionen zwischen dem Hersteller und seinen Händlern für das erste Pilotprojekt können in zwei Kategorien eingeteilt werden:
- Informationsanforderungen. Die Interaktion ist insofern bidirektional, dass eine Anforderungsnachricht gesendet wird, in der bestimmte Informationen angefordert werden, und eine Antwortnachricht in die andere Richtung gesendet wird, die die angeforderten Informationen enthält. Ein Beispiel für eine Informationsanforderung von einem Händler an den Hersteller ist "getOrderStatus".
- Aktualisierungsanforderungen. Diese Interaktionen sind insofern unidirektional, dass der Sender einer Aktualisierungsanforderung nicht vom Empfang einer Antwort abhängig ist, um mit anderen Arbeiten fortzufahren. Ein Beispiel für eine Aktualisierungsanforderung vom Händler an den Hersteller ist "placeOrder". Ein Beispiel für eine Aktualisierungsanforderung vom Hersteller an den Händler ist "deliveryConfirmed".
Der Hersteller verwendet WebSphere Application Server, um Informationsanforderungen mit SOAP over HTTP und SOAP over JMS zu implementieren. Die Händler sind in der Wahl ihrer Implementierungstechnologie frei. Sie müssen WebSphere Application Server nicht verwenden.
Der Hersteller implementiert Aktualisierungsanforderungen auf zwei unterschiedliche Arten:
- Über SOAP over HTTP. In diesem Fall wird der Service als Anforderung- und Antwortinteraktion dargestellt, die als erfolgreich betrachtet wird, wenn der Anforderer eine Antwort empfängt. Die Services müssen so implementiert werden, dass doppelte Anforderungen erkannt und erfolgreich beantwortet werden (dies wird als idempotente Operation bezeichnet), und der Client muss so implementiert werden, dass die Operation wiederholt wird, wenn die Kommunikation unterbrochen wird, nachdem die Anforderung gesendet, aber bevor die Antwort empfangen wurde.
- Um die genannten Einschränkungen zu umgehen, verwendet der Hersteller auch die SOAP-Over-JMS-Unterstützung von WebSphere Application Server und WebSphere MQ. In diesem Fall wird die Anforderung als unidirektionaler Service dargestellt, und die Nachrichten werden zuverlässig zugestellt. Der Hersteller verwendet WebSphere MQ als JMS-Provider und stellt diese Lösung allen Händlern zur Verfügung, die auch WebSphere Application Server und WebSphere MQ verwenden. Es ist nicht erforderlich, dass der Händler und der Hersteller verbunden sind, damit die Nachricht gesendet wird.
Die Nachrichten werden über virtuelle private Netze (VPNs) gesendet, um die Integrität und Vertraulichkeit von Nachrichten zu gewährleisten, die zwischen den beiden Geschäftspartnern übertragen werden, und die Identität des Senders zu etablieren.
Geschäftsbezogene Problemstellung
Obwohl der Hersteller und seine Händler mit der Implementierung der Informationsanforderungsservices zufrieden sind, gibt es bei der Aktualisierungsanforderung eine Reihe von Problemen:
- Über SOAP over HTTP:
- Für den Hersteller ist die Implementierung idempotenter Services kompliziert und produziert deshalb höhere Entwicklerkosten. Die Wahrscheinlichkeit von Codierungsfehlern nimmt zu, was die Stabilität der Lösung beeinträchtigt und die Möglichkeit kostenintensiver gelöschter oder doppelter Aufträge erhöht.
- Für Händler ist die Implementierung der Wiederholungslogik ähnlich komplex, kostenintensiv und fehlerträchtig.
- Für den Hersteller und die Händler ist die Voraussetzung, dass beide Parteien für den Aufruf des Service verfügbar sein müssen, ein Problem. Dies gilt insbesondere für die siebentägige Verfügbarkeit der Systeme. Während das Wochenende für den Hersteller die ideale Zeit zum Übermitteln von Preisaktualisierungen an die Händler ist, sind die Systeme vieler Händler am Wochenende nicht hochgefahren. Auch die Unfähigkeit, Bestellungen zu platzieren, wenn die die Konnektivität zwischen Händler und Hersteller nicht verfügbar ist, stellt ein echtes Geschäftsproblem dar.
- Über SOAP over JMS:
- Obwohl die Verwendung von WebSphere Application Server und WebSphere MQ für die aktuelle Gruppe von Händlern möglicherweise akzeptabel ist, können mit der Erweiterung des Projekts andere Partner hinzukommen, die nicht bereit oder nicht in der Lage sind, eine gemeinsame Softwareplattform zu verwenden.
Lösung mit WS-ReliableMessaging
Mit der Unterstützung für WS-ReliableMessaging in WebSphere Application Server kann der Hersteller seine vorhandenen Lösungen mit wiederholter Zustellung für ein zuverlässiges unidirektionales Messaging durch das unidirektionale Messaging über SOAP over HTTP ersetzen. Das Entfernen der Logik für wiederholte Zustellung aus der Anwendung vereinfacht den Anwendungscode und ermöglicht eine einfachere und schnellere Anwendungsentwicklung.
Wenn WS-ReliableMessaging eingesetzt wird, müssen Händler und Hersteller nicht verbunden sein, um Nachrichten zu senden.
Der Standard WS-ReliableMessaging bietet eine höhere Zuverlässigkeit für das Messaging über SOAP over HTTP und macht die Verwendung von SOAP over JMS nahezu überflüssig.
Da WS-ReliableMessaging mit SOAP over HTTP ein interoperabler Standard ist, muss das Händlernetz keine gemeinsame Softwareplattform verwenden.