Arten der Message-Übermittlung

Synchrone Kommunikation

Die synchrone Kommunikation kann bei Funktionsaufrufen eingesetzt werden, die die sofortige Rückgabe von Daten an das Sendersystem erfordern.

Der Client schickt eine Message an den Server und wartet, bis er von diesem eine Antwort erhält. Die synchrone Kommunikation arbeitet mit einem einmaligen Funktionsaufruf. Dies setzt voraus, dass zum Zeitpunkt des Aufrufs auch das Empfängersystem aktiv ist und den Aufruf sofort entgegennehmen und weiterverarbeiten kann. 

Nachteil der synchronen Kommunikation ist es, dass sichergestellt werden muss, dass beide Systeme aktiv und ansprechbar sind. Andernfalls kann es zu Störungen der Prozessabläufe kommen. Probleme können insbesondere dann entstehen, wenn das Empfängersystem aus Wartungsgründen, beispielweise im Zuge eines System-Upgrades, über einen längeren Zeitraum nicht verfügbar ist.

Bei der synchronen Kommunikation wird das Request ResponseMessage Exchange Pattern (MEP) verwendet. Der Client setzt einen Request ab und wartet auf eine Antwort vom Provider. Während dieser Zeit ist der Client blockiert. Er kann keine weiteren Aufrufe starten. Eine Transportgarantie wird bei synchronen Methoden nicht angeboten, da der Client durch die Response eine indirekte Bestätigung bekommt, dass der Aufruf erfolgreich durchgeführt wurde. Auch die Transaktionalität ist bei synchronen Methoden nicht gegeben. Dies bedeutet, dass jeder einzelne Aufruf direkt an den Provider gesendet und dort konvertiert wird. Aufrufe werden nicht zuerst gesammelt und gemeinsam abgesetzt. Nachfolgende Aufrufe werden blockiert. Aus diesem Grund wird auch keine Sicherheit der Reihenfolge der Aufrufe gewährleistet.

Wenn es wichtig ist, dass eine synchrone Methode genau ein Mal ausgeführt wird, muss sie als idempotenter (IDP) Web-Service gesendet werden. Bei idempotenten Services speichert der Provider eine Message, die als Response für einen eingehenden Aufruf erstellt wird, bevor die Response tatsächlich an den Consumer geschickt wird. Die Response wird von der Request-Message-ID identifiziert. Für jeden eingehenden Request kann der Provider daher feststellen, ob der Request bereits verarbeitet wurde. Wenn bereits eine Response vorhanden ist, wird sie erneut an den Consumer zurückgesendet, ohne dass die Message ein zweites Mal verarbeitet wird.

Funktionen synchroner Methoden:

Asynchrone Kommunikation

Bei der asynchronen Kommunikation muss das Empfängersystem nicht verfügbar sein, wenn ein Funktionsaufruf vom Sendersystem abgesetzt wird. Das Empfängersystem kann den Aufruf auch zu einem späteren Zeitpunkt entgegennehmen und verarbeiten.

Ist ein System beispielsweise wegen eines Upgrades längere Zeit nicht aktiv, kann es die zwischenzeitlich gesendeten Daten auch zu einem späteren Zeitpunkt verarbeiten, ohne dass die Prozesse im Sendersystem gestört werden. Funktionsaufrufe werden in die Ausgangsqueue des Sendersystems gestellt. In regelmäßigen Abständen wird der Aufruf von hier wiederholt, bis er vom Empfängersystem verarbeitet werden kann.

Wird eine Bestellung an ein Lieferantensystem gesendet, hat das Sendersystem keinen Einfluss auf die Verfügbarkeit des Empfängersystems. Ist das Empfängersystem nicht verfügbar, kann das Versenden der Bestellung solange wiederholt werden, bis das Lieferantensystem wieder ansprechbar ist. Asynchrone Kommunikation sollte für Prozesse, die eine sofortige Rückantwort an das Sendersystem verlangen, nicht verwendet werden.

Bei asynchronen Methoden arbeitet der Client nach dem Absetzen eines Service-Aufrufs weiter, ohne mit einer Blockierung auf die Antwort zu warten. Eine Antwort gibt es bei asynchronen Methoden nicht, da das OneWayMessage Exchange Pattern verwendet wird. Dadurch benötigt der Client allerdings die Sicherheit, dass seine Aufrufe beim Provider ankommen. Daher wird bei asynchronen Methoden die Transportgarantie angeboten.

Des Weiteren erfolgen die Aufrufe auf der Client-Seite transaktional. Dies bedeutet, dass alle Aufrufe einer Transaktion bis zum Abschluss derselben gesammelt werden. So kann verhindert werden, dass Teile einer Transaktion bereits auf Provider-Seite persistiert werden, obwohl der Rest nicht mehr gesendet werden konnte. Da jeder Aufruf separat an den Provider gesendet wird, kann es vorkommen, dass Message b vor Message a eintrifft.

Um dies auszugleichen, wird Web Services Reliable Messaging eingesetzt. Eine Sequenz umschließt alle Aufrufe einer LUW und versieht sie mit Nummern. Diese werden auf der Provider-Seite ausgewertet. Dadurch wird sicher gestellt, dass Messages einer Sequenz in der richtigen Reihenfolge verarbeitet weden und es nicht zu Fehlern kommt, weil eine Aktion eine andere voraussetzt, die noch nicht eingetreten ist.

Funktionen asynchroner Methoden: