Die Erfindung betrifft Web-Services, die den Clients des Internet bereitgestellt werden, und betrifft insbesondere ein Verfahren zum Umleiten der Clientanforderungen an den Web-Service, wenn sich dessen Adresse geändert hat.

Es ist allgemein bekannt, dass ein Zugriff auf immer mehr Services im Internet möglich ist. Die Internet-Benutzer sind demnach daran interessiert, Informationen zu Onlineservices im Internet und zum Anfordern dieser Services zu erhalten. Die Onlineservices werden in der Regel von Anwendungsservice-Providern bereitgestellt, aber es gibt auch domänenorientierte Services wie die Serviceanforderungen im Bereich der Life Sciences.

Heutzutage ist es einem Client möglich, angeforderte Informationen mit Hilfe von "Web-Services" abzurufen, bei denen es sich um eine spezielle Geschäftsfunktionalität handelt, die von einem Unternehmen üblicherweise über eine Internet-Verbindung zugänglich gemacht wird, um einem Kunden, einem Unternehmen oder einem Programm die Möglichkeit zu geben, den Service zu verwenden. Web-Services werden zu einem Eckpfeiler für den elektronischen Handel und den Austausch mit den Anwendungsservice-Providern.

Ein Service-Provider, der öffentlich zugängliche Web-Services im Internet bereitstellt, muss sämtliche Informationen bezüglich des Web-Service beschreiben. Hierzu kann er eine mit dem Web-Service verknüpfte WSDL-Datei (Web Service Definition Language) zur Verfügung stellen. Eine WSDL ist hilfreich zum Beschreiben der Schnittstelle (Methoden, Parameter usw.) und der Laufzeit (Bindungen, Adressen usw.) des Service. Aus Sicht des Clients enthält eine WSDL-Datei alle erforderlichen Informationen für den Aufbau der Clientstruktur. Normalerweise würde ein Client die WSDL-Datei nur während der Build-Time und nicht während der Laufzeit verwenden.

Es steht fest, dass sich eine WSDL in einem normalen Produktionsmodell aufgrund neuer funktionaler oder Laufzeitanforderungen weiterentwickelt. Wenn ein Service-Provider einen Web-Service und die zugehörige WSDL-Datei aktualisieren möchte, besteht die Hauptschwierigkeit in der Benachrichtigung aller Web-Service-Clients. Im Fall eines öffentlich zugänglichen Web-Service sind dem Service-Provider die Web-Service-Clients nicht bekannt und er kann diese daher nicht über eine Änderung benachrichtigen.

Einige Vorgehensweisen für Änderungen an der Schnittstelle eines Web-Service werden bereitgestellt. Somit muss eine Änderung an der Schnittstelle immer mit deren früheren Versionen kompatibel sein. Beispielsweise ist das Einfügen neuer Methoden in eine WSDL-Datei zulässig, aber das Entfernen dieser Methoden nicht.

Allerdings hat der Service-Provider keine Möglichkeit, alle Web-Service-Clients zu benachrichtigen, wenn sich die Endpunktadresse eines seiner öffentlich zugänglichen Web-Services ändert. Die Gründe hierfür sind, dass er weder einen Reverse-Proxyserver noch ein Web-Service-Gateway einsetzt und den Web-Service von einem ersten Host auf einen anderen, leistungsfähigeren Host übertragen möchte, oder dass er eine Lastverteilungslösung, ein Web-Service-Gateway bzw. einen sicheren Proxy-Server vor dem Web-Service einfügen möchte, oder dass er den Domänennamen ändern muss.

Für das als Transportprotokoll verwendete HTTP-Protokoll existiert bereits eine Lösung, die HTTP-Statuscodes der Klasse 3xx verwendet. Ein Client-Browser, der einen HTTP-Antwortcode der Klasse 3xx empfängt, erkennt, dass sich die Position des benötigten Dokuments geändert hat, und der Browser generiert automatisch eine neue HTTP-Anforderung für die im HTTP-Antwortcode der Klasse 3xx angezeigte Position. Diese Lösung lässt sich jedoch aus zwei Gründen nicht auf Web-Services anwenden, die das Simple Object Access Protocol (SOAP) als Protokoll für den Nachrichtenaustausch verwenden. Erstens werden die Codes der Klasse 3xx nicht automatisch von Laufzeitkomponenten verarbeitet, die die Bindung zwischen SOAP und HTTP herstellen. Zweitens ist HTTP nicht das ausschließliche Übertragungsprotokoll für die SOAP-Nachrichten, da die SOAP-Nachrichten auch über andere Transportprotokolle wie SMTP, JMS usw. gesendet werden können, und die für die Umleitung vorgesehenen HTTP-Statuscodes der Klasse 3xx sind für diese Protokolle nicht verfügbar.

Im Dokument GB-A-2333617 von IBM wird ein Umleitungsmechanismus für XML-Dokumente beschrieben, der das HTTP-Protokoll verwendet.

Aus diesem Grund ist es Aufgabe der Erfindung, ein Verfahren zu realisieren, um einen Web-Service-Client im Falle einer Laufzeitänderung an eine neue Endpunktadresse umzuleiten.

Die Erfindung betrifft deshalb ein Verfahren, um eine Web-Service-Anforderung in einem Datenübertragungsnetz wie dem Internet als Reaktion auf eine von einem Host eines Clients an einen Web-Service-Provider gesendete Anforderung umzuleiten, wobei dieser eine auf dem SOAP-Protokoll für den Nachrichtenaustausch basierende WSDL-Datei in einem Transportprotokoll wie HTTP bereitstellt. Dieses Verfahren umfasst folgende Schritte: Senden einer ersten Anforderung vom Client an eine alte Adresse des Web-Service, Antworten an den Client von dem mit der alten Adresse verknüpften Web-Service-Punkt durch das Zurücksenden einer Nachricht, in welcher der Header, der das Protokoll für den Nachrichtenaustausch verwendet, die Umleitung zur neuen Adresse des angeforderten Web-Service enthält, und Senden einer zweiten Anforderung vom Client an die neue Adresse des Web-Service.

Gemäß einem weiteren Aspekt betrifft die Erfindung ein System, das in der SOAP-Laufzeitkomponente des Service-Providers ein Prüfprogramm umfasst, das so beschaffen ist, dass es prüft, ob eine aus der SOAP-Laufzeitkomponente eines Clients an den Service-Provider gesendete Anforderung an eine neue Punktadresse umgeleitet werden muss, und die neue Punktadresse, an welche die Anforderung gesendet werden muss, bereitstellt, wobei diese neue Punktadresse in einer SOAP-Antwortnachricht von dem Service-Provider an der alten Punktadresse an die SOAP-Laufzeitkomponente des Clients gesendet wird, und das in der SOAP-Laufzeitkomponente des Clients ein Prüfprogramm umfasst, das so beschaffen ist, dass es prüft, ob die SOAP-Antwortnachricht die neue Punktadresse enthält, und die gleiche Anforderung neu generiert und an die neue Punktadresse sendet.

Das Vorangegangene sowie weitere Aufgaben, Merkmale und Vorteile der Erfindung werden aus der folgenden spezifischeren Beschreibung der Erfindung verständlicher, die in Verbindung mit den beigefügten Zeichnungen zu lesen ist. Es zeigen:

1 ein schematisches Diagramm, welches das erfindungsgemäße Verfahren darstellt;

2 ein Blockdiagramm, welches das erfindungsgemäße System darstellt;

3 ein Ablaufdiagramm, das die Schritte des Verfahrens darstellt, welches in der mit der alten Web-Service-Adresse verknüpften SOAP-Laufzeitkomponente implementiert wird;

4 ein Ablaufdiagramm, das die Schritte des Verfahrens darstellt, das in der SOAP-Laufzeitkomponente des Clients implementiert wird.

In 1 wird davon ausgegangen, dass ein auf dem SOAP-Protokoll für den Nachrichtenaustausch basierender Web-Service-Client 10 auf die von einem Service-Provider bereitgestellten Web-Services zugreifen möchte. In einem solchen Fall wird eine erste Anforderung von dem Host 10 an die aktuelle Web-Service-Adresse gesendet, bei welcher es sich um die alte Punktadresse 12 handelt, da der Benutzer nicht weiß, dass die Adresse des Web-Service geändert wurde. Die alte Punktadresse 12 antwortet dem Host 10, indem sie, wie später noch beschrieben wird, die Umleitung im Header der Antwortnachricht bereitstellt. Mit der Umleitung, die in der von der alten Punktadresse empfangenen SOAP-Nachricht enthalten ist, kann der Host 10 anschließend eine zweite Anforderung an die neue Web-Service-Adresse 14 senden, um eine Antwort auf diese Anforderung zu erhalten. Es ist anzumerken, dass der Host so programmiert werden kann, dass er die Umleitung protokolliert, damit weitere SOAP-Anforderungen direkt an die neue Punktadresse gerichtet werden.

Eine Implementierung des erfindungsgemäßen Verfahrens ist in 2 veranschaulicht. Die Web-Service-Clientstation 10 enthält normalerweise zwei Funktionalitäten: eine Clientanwendung 18 und eine SOAP-Laufzeitkomponente mit einem Prüfprogramm 22, welches eine Komponente ist, die prüft, ob der Header einer empfangenen SOAP-Nachricht eine Umleitung enthält. Falls dies der Fall ist, generiert das Prüfprogramm die gleiche SOAP-Anforderung erneut für die neue Punktadresse, die, wie oben erwähnt, im Header zur Verfügung gestellt ist, und protokolliert optional die Umleitung, um Codeänderungen in der Clientanwendung zu ermöglichen, damit die zukünftigen Anforderungen an die richtige Adresse geleitet werden. Es ist anzumerken, dass das Prüfprogramm 22 im Allgemeinen eine Routine innerhalb der Laufzeitkomponente ist, es aber auch eine unabhängige Komponente sein könnte, auf welche die Client-Laufzeitkomponente bei jedem Empfang einer SOAP-Nachricht zugreift.

Der Web-Service-Provider 24 enthält für gewöhnlich einen ersten HTTP-Server 26 und eine SOAP-Laufzeitkomponente wie die des Client. Die Laufzeitkomponente ist für den Zugriff auf Web-Services wie die Web-Services WS 1, WS 2 und WS 3 eingerichtet. Wie für den Client steht der SOAP-Laufzeitkomponente 28 des Service-Providers ein Prüfprogramm 30 zur Verfügung, bei dem es sich um eine Software als Teil der Laufzeitkomponente oder um eine unabhängige Komponente handeln kann, auf die beim Empfang einer SOAP-Nachricht zugegriffen wird. Es gilt zu beachten, dass statt HTTP ein beliebiges anderes Transportprotokoll, beispielsweise SMTP, verwendet werden könnte. Würde Letzteres verwendet, wäre der Server 26 ein SMTP-Server.

Bei jedem Empfang einer SOAP-Anforderung von einem Client 10 wird das Prüfprogramm 30 dafür eingerichtet, zu prüfen, ob die Adresse des angeforderten Web-Service die richtige Adresse ist oder eine alte Adresse, weil der Web-Service auf ein anderes System oder eine andere Adresse übertragen wurde und seine Adresse nicht mehr aktuell ist. Hierzu hat das Prüfprogramm 30 Zugriff auf eine Komponente 32, welche die nicht mehr aktuellen Web-Services und die neue Adresse kennt, wenn der angeforderte Service nicht mehr aktuell ist. Anschließend wird das Prüfprogramm dafür eingerichtet, der Laufzeitkomponente die neue Adresse bereitzustellen, damit diese in den Header der an den Client zurückgesendeten SOAP-Nachricht eingefügt wird.

Das Einfügen der neuen Adresse in den Header der SOAP-Nachricht erfolgt durch das Erstellen einer SOAP-Headerkennung mit dem Namen „Redirect", die in der SOAP-Spezifikation enthalten ist, um sicherzustellen, dass alle von den Clients und Service-Providern genutzten SOAP-Laufzeitkomponenten die Kennung verstehen. Nichtsdestotrotz ist die Einfügung des Headers in die SOAP-Spezifikation nicht zwingend erforderlich. Es könnte sich bei ihm auch um eine nur von einigen Laufzeitkomponenten unterstützte SOAP-Erweiterung handeln, was bei den Clients und Service-Providern, die diese Laufzeitkomponenten nutzen, zu einer höheren Servicequalität führen würde.

Ein Beispiel für einen solchen Header in einer SOAP-Antwortnachricht ist der folgende XML-Code:

Das Verhalten des SOAP-Laufzeitservers, der die Web-Services bereitstellt, ist in 3 veranschaulicht. Zu Beginn wartet die SOAP-Laufzeitkomponente auf eine SOAP-Anforderung (Schritt 40). Wie bereits erwähnt, hat die SOAP-Laufzeitkomponente Zugriff auf die im Allgemeinen in XML geschriebene Eigenschaftsdatei, welche die Liste der nicht mehr aktuellen Web-Services enthält. Jedem der nicht mehr aktuellen Web-Services wird eine neue Punktadresse zugeordnet. Nach dem Empfang einer SOAP-Anforderung ruft das Prüfprogramm daher den nicht mehr aktuellen Web-Service aus dieser Liste ab (Schritt 42) und prüft, ob es sich bei dem vom Client angeforderten Web-Service um einen nicht mehr aktuellen Web-Service handelt (Schritt 44). Wenn der Web-Service in dieser Liste nicht mehr aktueller Web-Services enthalten ist, versucht die SOAP-Laufzeitkomponente nicht, den Web-Service zu kontaktieren, sondern sendet eine SOAP-Antwort mit dem SOAP-Umleitungsheader zurück (Schritt 46). Wie bereits erläutert, enthält dieser Header die von der Eigenschaftsdatei bereitgestellte neue Punktadresse. Der SOAP-Body wird mit exakt dem vom Client empfangenen SOAP-Body gefüllt, damit in der SOAP-Laufzeitkomponente des Clients die gleiche SOAP-Anforderung an die neue Punktadresse ausgeführt werden kann.

Wenn der Web-Service in der Liste der nicht mehr aktuellen Web-Services nicht aufgeführt ist, führt die SOAP-Laufzeitkomponente weiter ihre normale Arbeit aus, d. h. sie sendet die SOAP-Anforderung an den entsprechenden Web-Service (Schritt 48). In jedem Fall wird der Prozess wieder zum Startschritt des Wartens auf eine SOAP-Anforderung (Schritt 40) zurückgeschleift.

Das Verhalten der SOAP-Laufzeitkomponente des Clients ist in 4 veranschaulicht. Zu Beginn wartet die Laufzeitkomponente auf eine SOAP-Antwort (Schritt 50). Anschließend prüft das Prüfprogramm der Laufzeitkomponente, ob diese Antwort einen Umleitungsheader enthält (Schritt 52). Ist dies der Fall, generiert die SOAP-Laufzeitkomponente eine neue SOAP-Anforderung für die neue Punktadresse, die im Nachrichtenheader enthalten ist (Schritt 54). Die SOAP-Laufzeitkomponente erhält außerdem den SOAP-Body aus der SOAP-Antwort und fügt diesen in die neue SOAP-Anforderung ein. Optional kann die SOAP-Laufzeitkomponente die Umleitung auch protokollieren, um künftige Änderungen am Clientcode und dadurch den direkten Zugriff auf die neue Adresse zu ermöglichen, ohne die Umleitung anfordern zu müssen (Schritt 56). Wenn die SOAP-Antwortnachricht keinen Umleitungsheader enthält, führt die SOAP-Laufzeitkomponente weiter ihre normale Arbeit aus, d. h. sie sendet die SOAP-Antwort an den Client (Schritt 58). In jedem Fall wird der Prozess wieder zum Startschritt des Wartens auf eine SOAP-Antwort (Schritt 50) zurückgeschleift.

Obwohl in den unabhängigen Ansprüchen die Verwendung des Simple Object Access Protocol (SOAP) beschrieben ist, ist anzumerken, dass statt SOAP unabhängig vom verwendeten Transportprotokoll ein beliebiges anderes Protokoll für den Nachrichtenaustausch verwendet werden kann.