DE112013002191B4

DE112013002191B4 - Nachrichtenverarbeitung in einem Datenverarbeitungssystem

Info

Publication number: DE112013002191B4
Application number: DE112013002191.9T
Authority: DE
Inventors: Martin Andrew Ross; Samuel Thomas Massey; Craig Howard Stirling; Daniel James McGinnes
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2012-04-26
Filing date: 2013-03-07
Publication date: 2024-02-22
Anticipated expiration: 2033-03-08
Also published as: GB2501513A; GB2513520B; GB201207277D0; CN104246731A; DE112013002191T5; US9325808B2; US20130290411A1; GB2513520A; CN104246731B; GB201415285D0; WO2013160775A1

Abstract

Verfahren zum Betreiben eines Datenverarbeitungssystems, aufweisend einen Dienstbus, der zwischen einen Client und einen Server geschaltet ist, wobei der Dienstbus eine oder mehrere Anwendungen aufweist, die so angeordnet sind, dass sie einen Nachrichtenfluss zwischen dem Client und dem Server vermitteln, wobei das Verfahren die folgenden Schritte aufweist:Empfangen einer Nachricht von dem Client in dem Dienstbus und Vermitteln der Nachricht in einer Anwendung des Dienstbusses, wobei die Vermittlung ein Hinzufügen von Kopfdaten zu der Nachricht aufweist, wobei die Kopfdaten eine Quelle und eine Bedingung definieren, unter der ein Ziel der Quelle direkt antworten kann, wobei die Quelle entweder den Client oder eine Anwendung des Dienstbusses aufweist und wobei das Ziel entweder eine Anwendung des Dienstbusses oder den Server aufweist.

Description

Gebiet der Erfindung
Diese Erfindung bezieht sich auf ein Verfahren zum Betreiben eines Datenverarbeitungssystems sowie auf das Datenverarbeitungssystem selbst.
Hintergrund
Enterprise Service Bus (ESB) bezeichnet ein Software-Architekturmodell, das verwendet wird, um in einer dienstorientierten Architektur die Interaktion und den Datenaustausch zwischen miteinander interagierenden Software-Anwendungen zu entwerfen und zu realisieren. Als Software-Architekturmodell für die verteilte Datenverarbeitung ist es eine Variante des allgemeineren Client-Server-Software-Architekturmodells und stellt einen nachrichtenorientierten Entwurf für den Datenaustausch und die Interaktion zwischen Anwendungen bereit. Es dient in erster Linie zur Integration verschiedenartiger Datenverarbeitungssysteme.
Bestehende ESB-Realisierungen ermöglichen einen Zwei-Wege-Betrieb. Ein einfaches Beispiel besteht darin, eine Nachricht in einem Anforderungsablauf zu vermitteln, bevor ein Aufruf eines gegebenen Dienstes eingeleitet wird, woraufhin ein Antwortablauf die Antwort von dem gegebenen Dienst zurück an die Client-Anwendung vermittelt. Es ist durchaus üblich, dass ein Antwortablauf keinerlei Aufbereitung, Umformung, Vermittlung oder Überprüfung durchführt, sondern die Antwort ohne Durchführen weiterer Aktionen einfach an die Client-Anwendung zurückgibt, was sowohl mit Blick auf die Prozessor- als auch die Netzwerkauslastung des ESB unwirtschaftlich ist.
Gegenwärtige Lösungen tragen zur Verringerung der Netzwerkauslastung von ESB-Realisierungen bei, indem sie Dienstantworten während einer gegebenen Gültigkeitsdauer zwischenspeichern, wobei dies jedoch nicht auf alle Szenarien anwendbar ist und nicht die zusätzlichen Kosten für das Verarbeiten der Nachricht mindert, mit dem die Antwort lediglich an die Client-Anwendung zurückgegeben wird. Im Sinne dieses Dokuments bezieht sich ein Antwortablauf auf die Prozesse, die daran beteiligt sind, eine Antwort von einem nachgeschalteten Dienst an die Client-Anwendung zu vermitteln. Wenn ein Antwortablauf als leer bezeichnet wird, bedeutet dies, dass die Verarbeitung einer statischen Weiterleitung entspricht, d.h. es findet keine Datenaufbereitung, -umformung, -vermittlung oder-überprüfung statt.
In diesem Kontext existieren bereits Veröffentlichungen: So beschreibt das Dokument US 2012 / 0 042 040 A1 ein Verfahren, ein System und ein Computerprogrammprodukt, welches jeweils durch eine Service-Registry in einem Service-orientierten Architektursystem betreibbar ist. Dabei wird eine Service-Anfrage von einem Service-Anfrager in dem System empfangen. Der Status des Service wird überprüft und als in der Service-Registry registriert eingestuft. Anderenfalls wird eine Anfrage an den Service-Provider geschickt, um einen neuen Service zur Verfügung zu stellen. Weiterhin beschreibt es Dokument DE 699 37 831 T2 Technologien zum Betreiben von Computernetzen, insbesondere die Verwaltung von Client-Anforderungen in Netzwerken auf Client-Server-Basis. Dabei können übermäßige Anforderungen aufgrund vielfacher Client-Anforderungen vermieden werden.
Trotzdem gelingt es bisher nicht, das oben skizzierte Problem umfassend zu adressieren. In der Technik besteht somit ein Bedarf an der Lösung des oben genannten Problems. Dies ist die Aufgabe des hier vorgestellten technischen Konzeptes.
Kurzdarstellung der Erfindung
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Betreiben eines Datenverarbeitungssystems bereitgestellt, das einen Dienstbus aufweist, der zwischen einen Client und einen Server geschaltet ist, wobei der Dienstbus eine oder mehrere Anwendungen aufweist, die so angeordnet sind, dass sie einen Nachrichtenfluss zwischen dem Client und dem Server vermitteln, wobei das Verfahren die Schritte des Empfangens einer Nachricht von dem Client in dem Dienstbus und des Vermitteln der Nachricht in einer Anwendung des Dienstbusses aufweist, wobei die Vermittlung das Hinzufügen von Kopfdaten zu der Nachricht aufweist, wobei die Kopfdaten eine Quelle und eine Bedingung definieren, unter der ein Ziel der Quelle direkt antworten kann, wobei die Quelle entweder den Client oder eine Anwendung des Dienstbusses aufweist und wobei das Ziel entweder eine Anwendung des Dienstbusses oder den Server aufweist.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Datenverarbeitungssystem bereitgestellt, das einen Dienstbus aufweist, der zwischen einen Client und einen Server geschaltet ist, wobei der Dienstbus eine oder mehrere Anwendungen aufweist, die so angeordnet sind, dass sie einen Nachrichtenfluss zwischen dem Client und dem Server vermitteln, wobei der Dienstbus so angeordnet ist, dass er eine Nachricht von dem Client empfängt und die Nachricht vermittelt, wobei die Vermittlung das Hinzufügen von Kopfdaten zu der Nachricht aufweist, wobei die Kopfdaten eine Quelle und eine Bedingung definieren, unter der ein Ziel der Quelle direkt antworten kann, wobei die Quelle entweder den Client oder eine Anwendung des Dienstbusses aufweist und wobei das Ziel entweder eine Anwendung des Dienstbusses oder den Server aufweist.
Gemäß einem dritten Aspekt der vorliegenden Erfindung wird ein Computerprogrammprodukt auf einem computerlesbaren Medium zum Betreiben eines Datenverarbeitungssystems bereitgestellt, das einen Dienstbus aufweist, der zwischen einen Client und einen Server geschaltet ist, wobei der Dienstbus eine oder mehrere Anwendungen aufweist, die so angeordnet sind, dass sie einen Nachrichtenfluss zwischen dem Client und dem Server vermitteln, wobei das Produkt Befehle aufweist, um eine Nachricht von dem Client in dem Dienstbus zu empfangen und um die Nachricht in einer Anwendung des Dienstbusses zu vermitteln, wobei die Vermittlung das Hinzufügen von Kopfdaten zu der Nachricht aufweist, wobei die Kopfdaten eine Quelle und eine Bedingung definieren, unter der ein Ziel der Quelle direkt antworten kann, wobei die Quelle entweder den Client oder eine Anwendung des Dienstbusses aufweist und wobei das Ziel entweder eine Anwendung des Dienstbusses oder den Server aufweist.
Unter einem weiteren Aspekt betrachtet, stellt die vorliegende Erfindung ein Computerprogrammprodukt zum Betreiben eines Datenverarbeitungssystems bereit, das einen Dienstbus aufweist, der zwischen einen Client und einen Server geschaltet ist, wobei der Dienstbus eine oder mehrere Anwendungen aufweist, die so angeordnet sind, dass sie einen Nachrichtenfluss zwischen dem Client und dem Server vermitteln, wobei das Computerprogrammprodukt aufweist: ein computerlesbares Speichermedium, das von einer Verarbeitungsschaltung lesbar ist und Befehle zur Ausführung durch die Verarbeitungsschaltung speichert, um ein Verfahren zum Durchführen der Schritte der Erfindung durchzuführen.
Unter einem weiteren Aspekt betrachtet, stellt die vorliegende Erfindung ein Computerprogramm bereit, das auf einem computerlesbaren Medium gespeichert und in den internen Arbeitsspeicher eines digitalen Computers ladbar ist, welches Softwarecode-Teile umfasst, um bei Ausführung des Programms auf einem Computer die Schritte der Erfindung durchzuführen.
Infolge der Erfindung kann eine verbesserte Datenverarbeitungsleistung und -funktion bereitgestellt werden, die z.B. in einem ESB-Produkt realisiert werden kann und mit der sich eine geringere Verarbeitungs- und Netzwerkauslastung innerhalb des Dienstbusses erzielen lässt. Dabei erkennt der ESB vorzugsweise leere Antwortabläufe bei gegebenen Dienstantworten, sendet ein Steuerpaket an eine Komponente des Dienstbusses, um anzugeben, dass sie umgangen wird, und leitet die Antwortnachricht auf der Grundlage von Daten, die ursprünglich an den Dienst weitergegeben wurden, an das Client-Aufrufsystem weiter. Vorzugsweise weist das Verfahren des Weiteren auf, die vermittelte Nachricht in dem Ziel zu empfangen, zu erkennen, dass die Bedingung in den Kopfdaten der vermittelten Nachricht erfüllt ist, und eine Antwort direkt an die Quelle zu übertragen, wie dies in den Kopfdaten der vermittelten Nachricht definiert ist. Somit ist ein Datenverarbeitungssystem in einer bevorzugten Ausführungsform in der Lage, zu ermitteln, wann ein Antwortablauf leer ist, eine Nachricht direkt an das Client-System weiterzuleiten, wenn der Antwortablauf des Dienstbusses leer ist, Daten der verfügbaren Antwortabläufe dazu zu verwenden, verschiedene Dienstantworten entsprechend weiterzuleiten (z.B. Standardnachrichten/ungültige Antworten/gültige Antworten) und eine teilweise Optimierung und Weitergabe von Daten über mehrere Anwendungen zu ermöglichen, um eine komplexere Analyse und Weiterleitung zu erlauben.
Im Wesentlichen weist das abgeänderte Datenverarbeitungssystem einen Client und einen End-Server auf, zwischen die ein Dienstbus geschaltet ist. Eine Quelle und ein Ziel (wobei in der einfachsten Ausführungsform die Quelle der Client und das Ziel der Server ist) können so angeordnet sein, dass der Dienstbus, wenn von der Quelle eine Nachricht für das Ziel ausgeht, spezifische Umstände definieren kann, unter denen das Ziel Daten direkt an die Quelle übertragen kann, anstelle sie über alle Komponenten des Dienstbusses zurück übertragen zu müssen. In der einfachsten Ausführungsform bedeutet dies, dass der Server unter bestimmten Umständen Daten direkt an die Client-Einheit zurück überträgt, anstelle sie über den Dienstbus zu übertragen. Der Dienstbus fügt Kopfdaten zu der ursprünglichen Nachricht hinzu, die definieren, wann das Ziel Daten direkt an die Quelle übertragen kann. Dies verringert den Verarbeitungsaufwand im Dienstbus auf dem Datenrückweg, da der gesamte oder ein Teil des Dienstbusses umgangen wird, indem das Ziel Daten direkt an die Quelle überträgt.
Vorzugsweise weist das Verfahren des Weiteren das Übertragen einer Nachricht von der Quelle an das Ziel auf, um einen sicheren Empfang der direkten Antwort anzugeben, sowie das Übertragen einer Nachricht von dem Ziel an die nachrichtenvermittelnde Anwendung, um einen sicheren Empfang der direkten Antwort anzugeben. Optional kann das Verfahren des Weiteren auch aufweisen, zu erkennen, dass die direkte Antwort nicht sicher an der Quelle empfangen wurde, und stattdessen eine Antwort an eine Anwendung des Dienstbusses zu übertragen. Das Ziel kann so konfiguriert sein, dass es überwacht, dass die Quelle die direkte Antwort sicher empfangen hat, und das Ziel kann mit dem Dienstbus Daten austauschen, um sicherzustellen, dass eine einwandfreie Transaktionsmethodik befolgt wird. Wenn aus einem wie auch immer gearteten Grund die direkte Nachricht die ursprüngliche Quelle nicht erreicht, oder wenn das Ziel nicht davon überzeugt ist, dass die Nachricht die Quelle erreicht hat, kann das Ziel die Antwort an den Dienstbus übertragen, um sicherzustellen, dass die ursprüngliche Anforderung tatsächlich verarbeitet wird.
Kurzbeschreibung der Zeichnungen
Im Folgenden werden mit Blick auf die folgenden Zeichnungen Ausführungsformen der vorliegenden Erfindung beschrieben, die lediglich als Beispiel zu verstehen sind, wobei:

die 1 und 2 schematische Darstellungen eines Datenverarbeitungssystems nach dem Stand der Technik sind, in dem eine bevorzugte Ausführungsform der vorliegenden Erfindung realisiert sein kann;
3 ein Ablaufplan eines Verfahrens zum Betreiben eines Dienstbusses gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ist;
4 ein Ablaufplan eines Verfahrens zum Betreiben eines Servers gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ist;
5 eine schematische Darstellung eines als Beispiel dienenden Antwortablaufs in einem Dienstbus gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ist; und
6 eine weitere schematische Darstellung eines Datenverarbeitungssystems gemäß einer bevorzugten Ausführungsform der Erfindung ist.

Ausführliche Beschreibung der Zeichnungen
1 veranschaulicht ein Datenverarbeitungssystem, das einen Client 10, einen Server 14 und einen Dienstbus 12 aufweist, der zwischen den Client 10 und den Server 14 geschaltet ist. Der Dienstbus 12 weist eine oder mehrere Anwendungen auf, die so angeordnet sind, dass sie einen Nachrichtenfluss zwischen dem Client 10 und dem Server 14 vermitteln. Aufgrund der Verwendung eines Dienstbusses 12 können der Client 10 und der Server 14 nicht direkt miteinander Daten austauschen und benötigen den Dienstbus 12, um zwischen den beiden unterschiedlichen Komponenten zu vermitteln. In großen Unternehmen sind bestehende Datenverarbeitungssysteme häufig nicht mit neuen Diensten oder Anwendungen verträglich, weshalb der Dienstbus 12 als Zwischenglied benötigt wird.
Die drei Komponenten aus 1 können drei getrennte Maschinen sein, die sich an unterschiedlichen Orten befinden, oder sie können aus einzelnen Software-Umgebungen bestehen, die in ein und derselben physischen Maschine angeordnet sind. Der Client 10 ist eine Anwendung, welche die Funktionalität eines Dienstes nutzen möchte, die von dem Server 14 bereitgestellt wird. Dabei kann der Client 10 aus welchem Grund auch immer Daten nicht direkt an den Server 14 übertragen, sondern muss eine Nachricht an den Dienstbus 12 senden, die der Dienstbus 12 vermittelt, um sie dann letztlich an den Server 14 weiterzuleiten. Auf entsprechende Art und Weise sendet der Server 14 die Antwort an den Dienstbus 12, der die empfangene Antwort dann vermittelt und sie an den Client 10 zurücksendet.
Der Dienstbus 12 besteht aus einer oder mehreren einzelnen Anwendungen, die Anforderungsabläufe und Antwortabläufe von Nachrichten verwalten, die von Clients 10 und Servern 14 empfangen werden. Ein Anforderungsablauf einer Anwendung des Dienstbusses 12 vermittelt eine eingehende Nachricht von einem Client 10. Der Dienstbus 12 sendet die vermittelte Nachricht an den Server 14. Ein Antwortablauf einer Anwendung des Dienstbusses 12 vermittelt die Antwort von dem Server 14, um sie an den ursprünglich anfordernden Client 10 weiterzuleiten. Auf diese Art und Weise können der Client 10 und der Server 14 trotz der offensichtlichen Unverträglichkeit Daten austauschen.
Das Datenverarbeitungssystem aus 1 optimiert die Verarbeitung des Antwortablaufs z.B. bei einer ESB-Realisierung. Dabei ist das Client-System 10 dasjenige System, das die ESB-Realisierung direkt aufruft. Der Dienstbus 12 stellt dem nachgeschalteten Dienst eine Datenweitergabe in Protokollkopfdaten bereit, die von dem Server 14 bereitgestellt werden und Informationen zu dem/den Client-System(en) sowie Informationen zu unterstützten Antworten und zur Gültigkeit einer Optimierung des Antwortablaufs enthalten. Im Wesentlichen vermittelt eine Anwendung des Dienstbusses 12 eine Nachricht, die von einem Client 10 empfangen wird, wobei die Vermittlung das Hinzufügen von Kopfdaten zu der Nachricht aufweist, wobei die Kopfdaten eine Quelle und eine Bedingung definieren, unter der ein Ziel der Quelle direkt antworten kann.
2 veranschaulicht das Konzept auf allgemeinste Art und Weise, wobei der Client 10 eine Nachricht 16 an den Dienstbus 12 überträgt. Eine Anwendung des Dienstbusses 12 vermittelt die Nachricht 16, wobei die Vermittlung das Hinzufügen von Kopfdaten 18 zu der Nachricht 16 aufweist. Die Kopfdaten 18 definieren eine Quelle (den Client 10) und eine Bedingung, unter der ein Ziel (der Server 14) dem Client 10 direkt antworten kann. Zusätzlich zu der normalen durch den Dienstbus 12 erfolgenden Vermittlung fügt der Dienstbus 12 somit der ausgehenden Nachricht die Kopfdaten 18 hinzu, welche die Umstände definieren, unter denen der Server 14 dem Client 10 direkt antworten kann, ohne dem Dienstbus 12 antworten zu müssen.
Das Ziel (der Server 14) empfängt die vermittelte Nachricht 16, und wenn es erkennt, dass die in den Kopfdaten 18 der vermittelten Nachricht 16 genannte Bedingung erfüllt ist, überträgt es eine Antwort direkt an die Quelle (den Client 10), wie dies in den Kopfdaten 18 der vermittelten Nachricht 16 definiert ist. Die normalerweise an den Dienstbus 12 zur Vermittlung und Weiterleitung an den Client 10 gesendete Antwort wird stattdessen direkt an den Client 10 gesendet, so dass der Dienstbus 12 umgangen wird. Abgesehen vom Weiterleiten seiner Antwort auf die Anforderung von dem Client 10, das von den Kopfdaten 18 bestimmt wird, führt der Server 14 alle seine Betriebsschritte wie gewohnt durch.
Wenn der Antwortablauf für eine spezifische Anforderung leer ist, kann der Server 14 dem Client 10 direkt antworten. Daraus ergibt sich, dass der Dienstbus 12 außer dem Weiterleiten der Antwort an den ursprünglichen Client 10 keine Vermittlungs- oder anderweitige Aktion mit Blick auf die Antwort auf diese spezifische Anforderung durchführt. Ein leerer Antwortablauf dient dazu, die Antwort von dem Server 14 im Wesentlichen ohne eine wie auch immer geartete Vermittlung des Dienstbusses 12 an den Client 10 durchzuleiten. Bei einem normalen Betrieb eines Datenverarbeitungssystems, das einen Dienstbus 12 verwendet, ergibt sich daraus eine unwirtschaftliche Nutzung von Verarbeitungs- und Netzwerkressourcen, da Daten unnötigerweise über den Dienstbus 12 geleitet werden.
In 2 findet der Betrieb des Dienstbusses 12 unter Steuerung durch ein Computerprogrammprodukt statt, das von einem computerlesbaren Medium 30 - hier ein CD-ROM 30 - bereitgestellt wird. Das Produkt auf dem Medium 30 weist eine Abfolge von Befehlen auf, welche die Vermittlung der Nachricht 16 steuert, nachdem sie durch den Dienstbus 12 empfangen wurde. Die Befehle definieren den Empfang der Nachricht 16 und die Art und Weise, wie der Dienstbus 12 die Nachricht 16 vermittelt, indem sie die Kopfdaten 18 zu der Nachricht 16 hinzufügen. Die Kopfdaten 18 definieren die Quelle der Nachricht 16 und die Umstände, unter denen das letztendliche Ziel der Nachricht 16 direkt auf die Quelle der Nachricht 16 antwortet.
Das Datenverarbeitungssystem kann ein Verfahren zum Erkennen leerer Antwortabläufe realisieren. So kann das Datenverarbeitungssystem z.B. während der Laufzeit oder der Bereitstellungszeit erkennen, ob leere Antwortabläufe vorhanden sind. Diese Erkennung ist realisierungsabhängig. So ist es z.B. bei einer Realisierung von IBM® WebSphere® Enterprise Service Bus (WESB) möglich, die Verbindungen von Knoten abzufragen, die Antworten von Dienstaufrufen anfänglich verarbeiten, um zu überprüfen, ob etwaige direkte Verbindungen zu einem Knoten bestehen, der das Zurücksenden einer Antwort an die Verbraucher-/Client-Dienstanwendung verarbeitet, oder um die xml-Datei(en) zu untersuchen, in der/denen die Vermittlungsablaufdaten gespeichert sind. Die Informationen zu leeren Antwortabläufen können dann im Cachespeicher oder in Vermittlungsmetadaten gespeichert und Daten können an einen nachgeschalteten Dienst weitergegeben werden. Andere Realisierungen von Dienstbussen können für diese Realisierungen spezifische Verfahren verwenden, um leere Antwortabläufe zu erkennen. IBM und WebSphere sind Handelsmarken der International Business Machines Corporation, die in vielen Ländern weltweit eingetragen sind.
3 zeigt einen Ablaufplan, der veranschaulicht, wie ein Dienstbus 12 funktioniert, der das Merkmal des Optimierens der Netzwerkauslastung realisiert, indem dem Server 14 gestattet wird, nach Empfang einer Nachricht 16 Daten direkt an den Client 10 zu übertragen. In Schritt S3.1 wird überprüft, ob die Optimierung aktiviert ist, da ein Netzwerkadministrator in der Lage sein sollte, das Merkmal zu aktivieren bzw. zu deaktivieren. Falls ja, wird in Schritt S3.2 überprüft, ob irgendwelche Antwortabläufe leer sind. Falls dies der Fall ist, wird in Schritt S3.3 des Weiteren überprüft, ob die Antwortabläufe für eine Optimierung in Frage kommen. Hiermit lässt sich feststellen, ob der Dienstbusrealisierung ein wie auch immer gearteter angepasster Code hinzugefügt wurde, was bedeuten könnte, dass der Dienstbus 12 nicht zwingend davon ausgehen kann, dass ein leerer Antwortablauf bedeutet, dass der spezifische Antwortablauf für eine Optimierung in Frage kommt. Wenn die Antwort in Schritt S3.3 „Ja“ lautet, weist in Schritt S3.4 die Vermittlung durch den Dienstbus das Hinzufügen von Einzelheiten zu dem Client 10 und dem Antwortablauf zu den Kopfdaten 18 der an den Server 14 gesendeten Nachricht auf, welche die Art der Anforderung bestimmen, die in Schritt S3.5 an den Server 14 gesendet wird.
4 ist ein Ablaufplan, der den Betrieb des Servers 14 veranschaulicht. Wie oben beschrieben, werden die von dem Server 14 benötigten Daten in den Kopfdaten 18 der empfangenen Nachricht weitergegeben. In Schritt S4.1 überprüft der Server 14, ob die von ihm bereitgestellte Antwort auf die ursprüngliche Anforderung eine Bedingung in den Kopfdaten 18 erfüllt. Falls dies nicht der Fall ist, fährt der Prozess mit Schritt S4.7 fort, und der Server 14 antwortet dem Dienstbus 12 auf herkömmliche Art und Weise. Falls die Antwort jedoch „Ja“ lautet, wird in Schritt S4.2 eine Benachrichtigung von dem Server 14 an den Dienstbus 12 gesendet, dass eine direkte Antwort auf die ursprüngliche Nachricht an den ursprünglichen Anforderer (den Client 10) gehen wird.
In Schritt S4.3 erhält der Server 14 aus den Kopfdaten 18 der Nachricht Daten, die den Client 10 definieren, wie z.B. eine geeignete Netzwerkadresse für den Client 10, und in Schritt S4.4 werden diese Daten verwendet, um eine Antwort direkt an den Client 10 zu übertragen. In Schritt S4.5 wird überprüft, ob der Client 10 einen sicheren Empfang der Antwort bestätigt hat. Wenn dies nicht der Fall ist, fährt der Prozess mit Schritt S4.7 fort, und der Server 14 antwortet dem Dienstbus 12 auf herkömmliche Art und Weise. Wenn die Antwort dagegen „Ja“ lautet, sendet der Server 14 in Schritt S4.6 eine Benachrichtigung an den Dienstbus 12, um anzugeben, dass die direkte Weiterleitung erfolgreich verwendet wurde.
Schritt S4.5, in dem überprüft wird, ob eine Antwort empfangen wird (der „Handschlag“ zwischen dem Client 10 und dem Server 14, falls auf den ESB 12 verzichtet wird), ist optional, da eine „bestmögliche“ Dienstgüte verwendet werden kann, bei der eine Nachricht unter bestimmten Voraussetzungen verloren gehen kann. In 4, kann - abhängig von der Umgebungskonfiguration, z.B. bei Verwendung einer geringeren Dienstgüte - Schritt S4.4 unter Umgehung von Schritt 4.5 direkt zu Schritt S4.6 führen.
Der Server 14 stellt ein Verfahren bereit, mit dem der ESB-Realisierung 12 mitgeteilt wird, dass der Antwortablauf umgangen wird, und sendet ein Datenpaket an den ESB 12 um anzuzeigen, dass der Ablauf abgeschlossen ist. Der Server 12 analysiert Daten in den Protokollkopfdaten 18, um die Antwortnachricht an das entsprechende Client-System 10 weiterzuleiten. Die Transaktionssteuerung wird an das nachgeschaltete System 14 zurückgegeben, das nun für Daten/Transaktion/Dienstgüte zuständig ist. Der Server 14 verwendet diese Methodik nur dann, wenn er feststellt, dass die in den Kopfdaten 18 genannte Bedingung erfüllt ist. Bei bestimmten Arten von Anforderungen nutzt daher nur ein Teilsatz der möglichen Antworten die direkte Beantwortung der ursprünglichen Quelle der Anforderung.
5 zeigt Einzelheiten eines als Beispiel dienenden Antwortablaufs für den Dienstbus 12. Der Ablauf weist Knoten 20 auf, die über Pfeile 22 miteinander verbunden sind. Jeder Knoten 20 kann so verstanden werden, dass er für eine bestimmte Logik steht, die von dem Dienstbus 12 aufgerufen wird, falls die erforderlichen Bedingungen mit Blick auf eine empfangene Nachricht 16 erfüllt sind. Der Knoten 20 mit der Bezeichnung „Aufrufantwort 1“ bezieht sich auf einen Knoten 20, der aufgerufen wird, wenn eine Antwort von einem Dienst 1 empfangen wird, der von einem Server 14 in Zusammenhang mit einer von einem Client 10 empfangenen Nachricht 16 bereitgestellt wird. Entsprechend beziehen sich „Aufrufantwort 2“ und „Aufrufantwort 3“ auf Dienste 2 bzw. 3 von weiteren Servern 14.
In dem Beispiel aus 5 bezieht sich der Knoten 20 mit der Bezeichnung „Eingabeantwort“ auf Logik, die aufgerufen wird, um eine Nachricht an den ursprünglichen Client 10 zurückzugeben, der den Datenaustausch mit dem Server 14 ausgelöst hat. Eine Antwort von Aufruf 1 oder Aufruf 2 wird zunächst in einen XSLT-Knoten 20 (Extensible Stylesheet Language Transformation) umgeformt, bevor eine Antwort an das Client-System 10 gesendet wird. Allerdings wird eine Antwort von Aufruf 3 direkt an das Client-System 10 gesendet. Eine Fehlerantwort von Aufruf 1 führt zu einem Stopp. Aus dieser Figur ist offensichtlich, dass verschiedene Antworten von ein und demselben Server 14 entsprechend der innerhalb des Dienstbusses 12 definierten Logik auf unterschiedliche Art und Weise verarbeitet werden.
Wenn die Anwendung selbst für die Optimierung des Antwortablaufs in Frage kommt, sind alle gültigen Antworten von Aufruf 3 (die zu einem Aufruf von Aufrufantwort 3 führen) Anwärter für die Optimierung. Wenn in dem Anforderungsablauf Aufruf 3 aufgerufen wird, werden die Daten in den Kopfdaten 18 an den nachgeschalteten Dienst 14 weitergegeben, die angeben, dass eine gültige Antwort direkt an das genannte Client-System 10 weitergeleitet werden soll. Auf diese Weise kann die Logik des Dienstbusses 12 überwacht werden, um zu entscheiden, wann der Server 14 darüber informiert werden sollte, dass eine bestimmte Art von Antwort nicht an den Dienstbus 12 zurückgegeben werden muss, sondern direkt an den Ursprungs-Client 10 gehen kann.
Bei manchen Realisierungen von Dienstbussen wie z.B. IBM WebSphere ESB können einzelne Anwendungen 24 des Dienstbusses 12 über Importe 26 und Exporte 28 verbunden sein, wie in 6 gezeigt wird. Bei dieser Art der Realisierung kann das Client-System für die ESB-Anwendung 24, das letztlich den nachgeschalteten Dienst 14 aufruft, eine andere Anwendung 24 innerhalb des Dienstbusses 12 sein. Obwohl die Nachrichtenkette in dem Datenverarbeitungssystem „Client-Dienstbus-Server“ lautet, sind die Quelle und das Ziel, welche die Antwortweiterleitung optimieren, nicht notwendigerweise die beiden Endpunkte der Kette (der Client 10 und der Server 14). Vielmehr kann die Quelle der Client 10 und das Ziel eine Anwendung 24 des Dienstbusses 12 sein, oder die Quelle kann eine Anwendung 24 des Dienstbusses 12 und das Ziel der Server 14 sein.
In dem Beispiel aus 6 verfügt die Anwendung App2 über Informationen, welche Antworten auf Anwendung App 1 die Bedingungen für die Optimierung erfüllen, wobei diese wiederum in den Protokollkopfdaten an den nachgeschalteten Dienst 14 weitergegeben werden. Abhängig von Entwurf und Funktionalität der Antwortabläufe für App 1 und App 2 kann der nachgeschaltete Dienst 14 somit eine Antwort an App 2 senden, die dann eine Antwort an App 1 sendet, die wiederum dem Client-System direkt antwortet (keine Optimierung), oder die eine Antwort an App 2 senden kann, die dann App 1 übergehen und dem Client-System 10 direkt antworten kann (Teiloptimierung), oder die sowohl App 2 als auch App 1 übergehen und eine Antwort direkt an das Client-System senden kann (vollständige Optimierung).
Das von der Optimierung verkörperte Hauptprinzip besteht darin, dass der Dienstbus 12 teilweise oder als Ganzes umgangen wird und dass dies durch Kopfdaten erreicht wird, die der ausgehenden Nachricht hinzugefügt werden und die einer Komponente weiter abwärts in der Kette die Umstände angeben, unter denen eine direkte Weiterleitung stattfindet, sowie, an wen die direkte Weiterleitung gerichtet sein soll. Da der Client 10 eine Anforderung an den Server 14 stellen kann, die dazu führt, dass viele Megabytes an Daten an den Client 10 übertragen werden, spart jede Optimierung der Weiterleitung einer derartigen Antwort beträchtliche Verarbeitungs- und Netzwerkressourcen ein. Der Server 14 bzw. die Anwendung 24, die das Ziel der Optimierung bilden, reagieren auf eine Komponente weiter zurück in der Kette, bei der es sich nicht um die Komponente handelt, die den Server 14 bzw. die Anwendung 24 ursprünglich aufgerufen hat.
Der Fachmann weiß, dass Aspekte der vorliegenden Erfindung als ein System, Verfahren, Computerprogrammprodukt oder Computerprogramm ausgeführt werden können. Entsprechend können Aspekte der vorliegenden Erfindung in Gestalt einer vollständig in Hardware realisierten Ausführungsform, einer vollständig in Software realisierten Ausführungsform (z.B. Firmware, residente Software, Mikrocode usw.) oder in Gestalt einer Ausführungsform vorliegen, die Software- und Hardware-Aspekte vereint, welche zusammenfassend als „Schaltung“, „Modul“ oder „System“ bezeichnet werden können. Des Weiteren können Aspekte der vorliegenden Erfindung in Gestalt eines Computerprogrammprodukts vorliegen, das in einem oder mehreren computerlesbaren Medien ausgeführt ist, auf denen computerlesbarer Programmcode enthalten ist.
Dabei kann eine beliebige Kombination aus einem oder mehreren computerlesbaren Medien genutzt werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann z.B. ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem bzw. eine entsprechende Vorrichtung oder Einheit oder aber eine beliebige geeignete Kombination der vorgenannten Elemente sein, ohne jedoch auf diese beschränkt zu sein. Konkretere Beispiele des computerlesbaren Speichermediums würden Folgendes beinhalten (wobei dies eine nicht vollständige Liste darstellt): eine elektrische Verbindung mit einem oder mehreren Leitern, eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), einen löschbaren, programmierbaren Nur-Lese-Speicher (EPROM- oder Flash-Speicher), einen Lichtwellenleiter, einen tragbaren CD-ROM, eine optische Speichereinheit, eine magnetische Speichereinheit oder eine beliebige geeignete Kombination der vorgenannten Elemente. In Verbindung mit diesem Dokument kann ein computerlesbares Speichermedium jedes physische Medium sein, das ein Programm enthalten oder speichern kann, welches von oder in Zusammenhang mit einem der Befehlsausführung dienenden System, einer Vorrichtung oder Einheit verwendet wird.
Ein computerlesbares Signalmedium kann ein weitergeleitetes Datensignal mit darin enthaltenem computerlesbarem Programmcode enthalten, z.B. als Basisband oder als Teil einer Trägerwelle. Ein derartiges weitergeleitetes Signal kann eine beliebige Form von unterschiedlichen Formen annehmen, darunter, ohne darauf beschränkt zu sein, eine elektromagnetische Form, eine optische Form oder auch jede geeignete Kombination hiervon. Ein computerlesbares Signalmedium kann ein beliebiges computerlesbares Medium sein, das kein computerlesbares Speichermedium ist und das ein Programm übermitteln, weiterleiten oder übertragen kann, welches für die Nutzung durch oder in Verbindung mit einem/einer der Befehlsausführung dienenden System, Vorrichtung oder Einheit vorgesehen ist.
Auf einem computerlesbaren Medium enthaltener Programmcode kann unter Verwendung eines beliebigen geeigneten Mediums übertragen werden, darunter, ohne darauf beschränkt zu sein, drahtlose, drahtgebundene, Lichtwellenleiterkabel-, HF- und andere Medien oder eine beliebige Kombination derselben.
Computerprogrammcode für das Ausführen von Arbeitsschritten für Aspekte der vorliegenden Erfindung kann in einer beliebigen Kombination von einer oder mehreren Programmiersprachen geschrieben sein, darunter eine objektorientierte Programmiersprache wie Java@, Smalltalk, C++ oder ähnliche sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder aber vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. Im letztgenannten Szenario kann der entfernt angeordnete Computer über eine beliebige Art von Netzwerk, unter anderem ein lokales Netz (LAN) oder ein Weitverkehrsnetz (WAN), mit dem Computer des Benutzers verbunden sein, oder die Verbindung kann mit einem externen Computer (z.B. über das Internet unter Verwendung eines Internet-Dienstanbieters) hergestellt werden. Java und alle Handelsmarken und Logos auf der Grundlage von Java sind Handelsmarken oder eingetragene Handelsmarken von Oracle und/oder seinen Tochtergesellschaften.
Im Folgenden werden Aspekte der vorliegenden Erfindung unter Bezugnahme auf Darstellungen von Ablaufplänen und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Dabei dürfte klar sein, dass jeder Block der Ablaufplan-Darstellungen und/oder Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplan-Darstellungen und/oder Blockschaubildern durch Computerprogrammbefehle realisiert werden kann/können. Diese Computerprogrammbefehle können einem Prozessor eines Universalcomputers, Spezialcomputers oder einer anderweitigen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Befehle, die über den Prozessor des Computers oder der anderweitigen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, ein Mittel erzeugen, mit dem die Funktionen/Handlungen realisiert werden können, die in dem Block bzw. den Blöcken des Ablaufplans und/oder Blockschaubilds angegeben werden.
Diese Computerprogrammbefehle können auch auf einem computerlesbaren Medium gespeichert werden, das einen Computer, eine anderweitige programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten anweisen kann, auf eine bestimmte Art und Weise zu funktionieren, so dass die auf dem computerlesbaren Medium gespeicherten Befehle einen Gegenstand hervorbringen, der Befehle aufweist, mit denen die in dem Block bzw. den Blöcken des Ablaufplans und/oder Blockschaubilds angegebene Funktion/Handlung realisiert wird.
Die Computerprogrammbefehle können zudem in einen Computer, eine anderweitige programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten geladen werden, um zu veranlassen, dass eine Reihe von Betriebsschritten auf dem Computer, der anderweitigen programmierbaren Datenvorrichtung oder den anderen Einheiten ausgeführt wird, so dass die Befehle, die auf dem Computer oder der anderweitigen Datenverarbeitungsvorrichtung ausgeführt werden, Prozesse bereitstellen, mit denen die in dem Block bzw. den Blöcken des Ablaufplans und/oder Blockschaubilds angegebenen Funktionen/Handlungen realisiert werden.
Der Ablaufplan und die Blockschaubilder in den Figuren veranschaulichen die Architektur, Funktionalität und den Betrieb möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. Somit kann jeder Block der Ablaufpläne oder Blockschaubilder ein Modul, Segment oder einen Code-Teil darstellen, der einen oder mehrere ausführbare Befehle aufweist, mit denen sich die angegebene(n) logische(n) Funktion(en) realisieren lässt/lassen. Zu beachten ist ferner, dass bei manchen alternativen Ausführungsformen die in dem Block erwähnten Funktionen in einer anderen Reihenfolge als der in den Figuren genannten auftreten können. So können zwei aufeinanderfolgend dargestellte Blöcke tatsächlich im Wesentlichen gleichzeitig stattfinden, oder die Blöcke können mitunter in umgekehrter Reihenfolge ausgeführt werden, wobei dies abhängig von der betreffenden Funktionalität ist. Ebenfalls erwähnenswert ist, dass jeder Block der Blockschaubilder und/oder der Ablaufplan-Darstellung sowie Kombinationen von Blöcken in den Blockschaubildern und/oder der Ablaufplan-Darstellung durch Spezialsysteme auf der Grundlage von Hardware, welche die angegebenen Funktionen oder Handlungen oder Kombinationen hiervon ausführen, oder durch Kombinationen von Spezial-Hardware- und Computerbefehlen realisiert werden kann/können.
Zur Klarstellung ist der Begriff „aufweisend“, wie er hier in der Beschreibung und den Ansprüchen verwendet wird, nicht im Sinne von „bestehend ausschließlich aus“ zu verstehen.

Claims

Verfahren zum Betreiben eines Datenverarbeitungssystems, aufweisend einen Dienstbus, der zwischen einen Client und einen Server geschaltet ist, wobei der Dienstbus eine oder mehrere Anwendungen aufweist, die so angeordnet sind, dass sie einen Nachrichtenfluss zwischen dem Client und dem Server vermitteln, wobei das Verfahren die folgenden Schritte aufweist: Empfangen einer Nachricht von dem Client in dem Dienstbus und Vermitteln der Nachricht in einer Anwendung des Dienstbusses, wobei die Vermittlung ein Hinzufügen von Kopfdaten zu der Nachricht aufweist, wobei die Kopfdaten eine Quelle und eine Bedingung definieren, unter der ein Ziel der Quelle direkt antworten kann, wobei die Quelle entweder den Client oder eine Anwendung des Dienstbusses aufweist und wobei das Ziel entweder eine Anwendung des Dienstbusses oder den Server aufweist.
Verfahren nach Anspruch 1, des Weiteren aufweisend ein Empfangen der vermittelten Nachricht in dem Ziel, ein Erkennen, dass die Bedingung in den Kopfdaten der vermittelten Nachricht erfüllt ist, und ein Übertragen einer Antwort direkt an die Quelle, wie dies in den Kopfdaten der vermittelten Nachricht definiert ist.
Verfahren nach Anspruch 2, des Weiteren aufweisend ein Übertragen einer Nachricht von der Quelle an das Ziel, um einen sicheren Empfang der direkten Antwort anzugeben.
Verfahren nach Anspruch 3, des Weiteren aufweisend ein Übertragen einer Nachricht von dem Ziel an die nachrichtenvermittelnde Anwendung, um einen sicheren Empfang der direkten Antwort anzugeben.
Verfahren nach Anspruch 2, des Weiteren aufweisend ein Erkennen, dass die direkte Antwort nicht sicher an der Quelle empfangen wurde, und stattdessen das Übertragen einer Antwort an eine Anwendung des Dienstbusses.
Verfahren nach einem beliebigen vorangegangenen Anspruch, wobei der Dienstbus eine Mehrzahl von Anwendungen aufweist und die Quelle eine erste Anwendung in dem Dienstbus aufweist und das Ziel eine zweite Anwendung in dem Dienstbus aufweist.
Datenverarbeitungssystem, aufweisend einen Dienstbus, der zwischen einen Client und einen Server geschaltet ist, wobei der Dienstbus eine oder mehrere Anwendungen aufweist, die so angeordnet sind, dass sie einen Nachrichtenfluss zwischen dem Client und dem Server vermitteln, wobei der Dienstbus so angeordnet ist, dass er eine Nachricht von dem Client empfängt und die Nachricht vermittelt, wobei die Vermittlung das Hinzufügen von Kopfdaten zu der Nachricht aufweist, wobei die Kopfdaten eine Quelle und eine Bedingung definieren, unter der ein Ziel der Quelle direkt antworten kann, wobei die Quelle entweder den Client oder eine Anwendung des Dienstbusses aufweist und wobei das Ziel entweder eine Anwendung des Dienstbusses oder den Server aufweist.
Verfahren nach Anspruch 7, wobei das Ziel so angeordnet ist, dass es die vermittelte Nachricht empfängt, erkennt, dass die Bedingung in den Kopfdaten der vermittelten Nachricht erfüllt ist, und eine Antwort direkt an die Quelle überträgt, wie dies in den Kopfdaten der vermittelten Nachricht definiert ist.
System nach Anspruch 8, wobei die Quelle so angeordnet ist, dass sie eine Nachricht an das Ziel überträgt, um einen sicheren Empfang der direkten Antwort anzugeben.
System nach Anspruch 9, wobei das Ziel so angeordnet ist, dass es eine Nachricht an die nachrichtenvermittelnde Anwendung überträgt, um einen sicheren Empfang der direkten Antwort anzugeben.
System nach Anspruch 8, wobei das Ziel des Weiteren so angeordnet ist, dass es erkennt, dass die direkte Antwort nicht sicher an der Quelle empfangen wurde, und stattdessen eine Antwort an eine Anwendung des Dienstbusses überträgt.
System nach einem der Ansprüche 7 bis 11, wobei der Dienstbus eine Mehrzahl von Anwendungen aufweist und die Quelle eine erste Anwendung in dem Dienstbus aufweist und das Ziel eine zweite Anwendung in dem Dienstbus aufweist.
Computerprogrammprodukt zum Betreiben eines Datenverarbeitungssystems, aufweisend einen Dienstbus, der zwischen einen Client und einen Server geschaltet ist, wobei der Dienstbus eine oder mehrere Anwendungen aufweist, die so angeordnet sind, dass sie einen Nachrichtenablauf zwischen dem Client und dem Server vermitteln, wobei das Computerprogrammprodukt aufweist: ein computerlesbares Speichermedium, das von einer Verarbeitungsschaltung lesbar ist und Befehle zur Ausführung durch die Verarbeitungsschaltung speichert, um ein Verfahren gemäß einem beliebigen der Ansprüche 1 bis 6 durchzuführen.
Computerprogrammprodukt, das auf einem computerlesbaren Medium gespeichert ist und in den internen Speicher eines digitalen Computers ladbar ist, welches Softwarecode-Teile umfasst, die, wenn das Programm auf einem Computer ausgeführt wird, das Verfahren nach einem beliebigen der Ansprüche 1 bis 6 durchführen.