CH709007A2 - Service Bus zur Integration verteilter Informations- und Kommunikationsdienste in die Anwendungslandschaft eines kleinen oder mittelständischen Unternehmens. - Google Patents

Abstract

Die Erfindung betrifft einen Service Bus (6) zur Verbindung von Klienten (7) mit Diensten (17) von Dienstanbietern (16) in einem Datenverarbeitungssystem. Sendet ein Klient (7) eine Anfrage ab, wird sie durch eine Schnittstelle (9) decodiert und an den Aufgabenbestand (10) weitergeleitet. Der Arbeiter-Pool (11) entnimmt den Auftrag aus dem Aufgabenbestand (10) und arbeitet sequentiell die konfigurierten Schritte der Prozesskette (12) ab. Im Rahmen der Verarbeitung wird die Anfrage über die Routing-Komponente (13) mit Hilfe von bereitgestellten Meta-Informationen aus dem Cache (14) an den zuständigen Konnektor (15) weitergeleitet. Der Konnektor (15) transformiert die Anfrage in das spezifische Format des Dienstanbieters (16) mit dem gewünschten Dienst (17). Anschliessend sendet der Dienstanbieter (16) das Resultat zum Konnektor (15). Vom Konnektor (15) übernimmt der Arbeiter-Pool (11) das Resultat und stellt dieses in den Aufgabenbestand (10). Die Schnittstelle (9) entnimmt darauf die Antwort, decodiert sie in das klientenspezifische Format und sendet sie an den Klienten (7).

Description

[0001] Die vorliegende Erfindung bezieht sich auf einen Service Bus gemäss Ansprüchen 1 bis 4. Dieser spezielle Service Bus wird im folgenden OpaccServiceBus genannt.

[0002] Mit Enterprise Service Bus (ESB) bezeichnet man in der Informationstechnik eine Kategorie von Softwareprodukten, die die Integration verteilter Dienste in der Anwendungslandschaft eines Unternehmens unterstützen oder teilweise erst ermöglichen.

[0003] Die Anwendungslandschaft einer Organisation unterstützt deren Geschäftsprozesse mit Informationstechnik. Ist sie im Stil einer Serviceorientierten Architektur gestaltet, kann sie in sogenannte Dienste gegliedert werden. Ein Dienst umfasst eine fachlich und/oder technisch zusammengehörende Teilmenge der Funktionalität, mit der IT die Geschäftsprozesse unterstützt.

[0004] Dienstanbieter bieten ihre Funktionalität über Dienstschnittstellen so an, dass sie von Dienstnutzern in der Anwendungslandschaft angesprochen werden können. Je nach Unternehmen und konkreter Gestaltung einer Anwendungslandschaft kommen als Dienstnutzer neben anderen Diensten auch weitere Arten von Elementen einer Anwendungslandschaft in Frage, z. B. Domänen, Anwendungen oder Komponenten.

[0005] Nutzt ein Dienstnutzer den Funktionsumfang eines Dienstanbieters, werden die beiden Elemente voneinander abhängig. Eine Integrationsarchitektur mit einem ESB folgt nun dem Ansatz, dass sowohl Dienstanbieter wie Dienstnutzer über den ESB verbunden werden, wenn nötig mit überbrückenden Elementen.

[0006] Funktionen, die die Integration von verteilten Diensten unterstützen, sind in einem ESB in sog. Integrationsdiensten gekapselt. Das Konzept des ESB geht davon aus, dass Integrationsdienste ähnlich wie Geschäftsdienste in der Anwendungslandschaft verteilt sein können. Es setzt keinen zentralen Knoten voraus, der alle Integrationsdienste anbietet und über den Nachrichten laufen müssen, die diese Dienste nutzen. Die beiden wichtigsten Integrationsdienste sind die Transformations- und die Routingdienste.

[0007] Bekannte ESB-Lösungen haben den Nachteil, dass vor allem kleine und mittelständische Unternehmen in Gefahr laufen, überdimensionierte und zu generische Infrastruktur einzuführen. Für diese Infrastruktur gibt es zum Zeitpunkt der Realisierung keine ausreichenden Geschäftsbedürfnisse. Das führt zu erhöhter Komplexität in verschiedenen Bereichen wie Betrieb, Installation und Lizenzwesen sowie zu starken Abhängigkeiten von Integrationsdiensten. Die Folge davon sind vermeidbare Mehrkosten für das Unternehmen.

[0008] Ein weiterer Nachteil bekannter ESB-Lösungen ist, dass diese aufgrund ihrer Komplexität nicht einfach an die Bedürfnisse der Anwender angepasst werden können. Oftmals ist es sogar der Fall, dass Anwender ihre Geschäftsprozesse den Anforderungen resp. Möglichkeiten der bekannten ESB-Lösungen anpassen müssen.

[0009] Die vorliegende Erfindung stellt sich daher die Aufgabe, eine ESB-Lösung der oben genannten Art derart zu verbessern, dass die erwähnten Nachteile vermieden werden.

[0010] Diese Aufgabe wird durch die Merkmalskombination der Ansprüche gelöst.

[0011] Durch die vorliegende Erfindung wird es kleinen und mittelständischen Unternehmen ermöglicht, einen schlanken Service Bus in ihr Datenverarbeitungssystem einzubauen, der einfach auf ihre Geschäftsprozesse spezifiziert werden kann, modular erweiterbar ist, den Datenfluss optimiert und der Dienste mit unterschiedlichen Technologien und beliebiger Funktionalität in ihr Datenverarbeitungssystem integrieren kann.

[0012] Anhand der beiliegenden schematischen Zeichnungen wird die Erfindung beispielsweise erläutert. Es zeigen: <tb>Fig. 1 :<SEP>schematische Darstellung eines Datenverarbeitungssystems, in welchem die Erfindung gemäss den Ansprüchen implementiert ist <tb>Fig. 2 :<SEP>schematischer Ablaufplan der Methode des operierenden OpaccServiceBus

[0013] Fig. 1 illustriert ein Datenverarbeitungssystem 1, welches aus einer Klient 2-Ebene, dem OpaccServiceBus 3 und einer Dienstanbieter 4-Ebene besteht. Dabei illustrieren die Pfeile den Datenfluss. Bei einem Klienten 2 handelt es sich um eine firmeninterne oder firmenexterne Applikator welche die Funktionalität der Dienste 5 nutzen möchte, welche von einem Dienstanbieter 4 ins Datenverarbeitungssystem 1 implementiert worden sind.

[0014] Der OpaccServiceBus 3 umfasst die Funktionalität, um den Nachrichtenfluss zwischen den Klienten 2 und den Dienstanbietern 4 zu steuern. Die Notwendigkeit des OpaccServiceBus 3 impliziert, dass die Klienten 2 und die verschiedenen Dienste 5 der Dienstanbieter 4 nicht direkt kommunizieren können und der OpaccServiceBus 3 als Mediator zwischen den verschiedenen Ebenen gebraucht wird.

[0015] Dies hat sowohl für Dienstanbieter 4 als auch für Klienten 2 Vorteile: Die Klienten 2 müssen technisch nur mit einer Komponente (dem OpaccServiceBus 3) kommunizieren und können trotzdem auf die ganze Bandbreite der Dienste 5 zugreifen. Die Dienstanbieter 4 müssen ihre Dienste 5 technisch nur einer Komponente zugänglich machen (dem OpaccServicesBus 3). Der OpaccServiceBus 3 übernimmt die Vermittlung zwischen Klienten 2 und Dienstanbietern 4 sowie die Konvertierung der verschiedenen Datenformate.

[0016] Oftmals sind neue Versionen von Diensten 5 nicht kompatibel mit älteren Versionen. Der OpaccServiceBus 3 ermöglicht eine Eingliederung solcher inkompatibler Dienste 5 in ein Datenverarbeitungssystem 1 ohne eine Anpassung der Klienten 2. Dies stellt einen beträchtlichen technischen, zeitlichen und finanziellen Vorteil dar.

[0017] Die drei in Fig. 1 dargestellten Komponenten Klient 2, OpaccServiceBus 3 und Dienstanbieter 4 können drei separate, räumlich getrennte Maschinen, oder als jeweils individuelle Software auf ein und derselben physikalischen Maschine lokalisiert sein.

[0018] Der Klient 2 sendet eine Nachricht zum OpaccServiceBus 3, der diese zum entsprechenden Dienstanbieter 4 mit dem zu nutzenden Dienst 5 weiterleitet. Die Antwort des Dienstanbieters 4 wird dann wiederum über den OpaccServiceBus 3 an den Klienten 2 übermittelt.

[0019] Der OpaccServiceBus 3 ist aus mehreren Komponenten aufgebaut, welche die Anfragen von Klienten 2 steuern und die Antworten von Dienstanbietern 4 behandeln. Im Rahmen des sog. Request Flows des OpaccServiceBus 3 wird die hereinkommende Anfrage zum entsprechenden Dienstanbieter 4 übermittelt. Umgekehrt wird mit dem sog. Response Flow des OpaccServiceBus 3 die Antwort des Dienstanbieters 4 an den ursprünglich anfragenden Klienten 2 übermittelt. In dieser Art und Weise können Klienten 2 und Dienstanbieter 4 trotz vorhandener Inkompatibilität miteinander kommunizieren.

[0020] Fig. 2 zeigt schematisch die verschiedenen Komponenten des OpaccServiceBus 6 sowie die Abarbeitung einer Anfrage eines Klienten 7. Dabei illustrieren die Pfeile den Datenfluss. Durch die Konfiguration 8 wird eingestellt, was für Schnittstellen 9 und Konnektoren 15 aktiv sind und wie diese konfiguriert sind. Sendet ein Klient 7 eine Anfrage ab, wird sie durch ein Schnittstelle 9 entgegengenommen, decodiert und an die Aufgaben bestand 10 weitergeleitet. Der Arbeiter-Pool 11 entnimmt den Auftrag aus dem Aufgaben bestand 10 mit der höchsten Priorität und arbeitet sequentiell die verschiedenen Schritte der Prozesskette 12 ab. Bei den einzelnen Schritten der Prozesskette 12 handelt es sich um eine konfigurierbare Sequenz von Verarbeitungsschritten, wie z. B. der Benutzerprüfung (Authentifikation), der eigentliche Abarbeitung der Anfrage (Verarbeitung) und der Aufzeichnung der Anfrage in ein Logbuch (Protokollierung). Im Rahmen der Verarbeitung wird die Anfrage über die Routing-Komponente 13 an den zuständigen Konnektor 15 weitergeleitet. Der Entscheid der Routing-Applikation 13 wird mit Hilfe von bereitgestellten Meta-Informationen aus dem Cache 14 gefällt. Der Konnektor 15 transformiert darauf die Anfrage in das spezifische Format des Dienstanbieters 16, der die gewünschten Dienste 17 anbietet. Anschliessend sendet der Dienstanbieter 16 das Resultat zum Konnektor 15. Vom Konnektor 15 übernimmt der Arbeiter-Pool 11 das Resultat der Anfrage und stellt dieses in den Aufgabenbestand 10. Die Schnittstelle 9 entnimmt darauf die Antwort, decodiert sie in das klientenspezifische Format und sendet sie an den Klienten 7 weiter.

[0021] Mit dem OpaccServiceBus 6 ist das simultane Verarbeiten von mehreren Anfragen oder von ganzen Anfragesets möglich. In einem Anfrageset können mehrere Anfragen zusammen an den OpaccServiceBus 6 übermittelt werden. Dabei bietet sich die Möglichkeit, Anfragen zu formulieren, die eine Abhängigkeit von Resultaten anderer Anfragen innerhalb desselben Sets aufweisen. Zusammen mit der Verfügbarkeit von Meta-Informationen aus dem Cache 14 beschleunigt dies den Ablauf eines Dialogs via den OpaccServiceBus 6 signifikant. Der OpaccServiceBus 6 optimiert so den Datenflussprozess in einem Datenverarbeitungssystem.

[0022] Das modulare Modell der Schnittstellen 9 und Konnektoren 15 des OpaccServiceBus 6 gewährleistet eine hohe Anpassbarkeit an Kundenbedürfnisse. Durch die Verwendung des OpaccServiceBus 6 wird es einfach, diverse Dienstanbieter 16 mit unterschiedlichen Technologien und beliebiger Funktionalität in ein Datenverarbeitungssystem einzubinden. Insbesondere ermöglicht dies die Zugänglichkeit von neueren Klienten zu Diensten und/oder Dienstanbietern, welche auf älteren Technologien basieren. Damit können Investitionen in Migrations-Projekte vermindert werden.

Claims (4)

1. OpaccServiceBus (6), dadurch gekennzeichnet, dass er im Stile einer Serviceorientierten Architektur gestaltet ist, dass er einen sog. Cache (14) enthält, in dem Meta-Informationen zu Diensten (17) gespeichert werden, dass dessen Module, sog. Schnittstellen (9) und Konnektoren (15), dynamisch eingebunden werden können.

2. OpaccServiceBus (6) nach Anspruch 1, dadurch gekennzeichnet, dass mehrere unabhängige Anfragen gleichzeitig verarbeitet werden können, dass die Verarbeitung von mehreren zusammengenommenen und voneinander abhängigen Anfragen auf einmal, sog. Anfragensets, möglich ist.

3. OpaccServiceBus (6) nach Anspruch 1 und 2, dadurch gekennzeichnet, dass dessen Schnittstellen (9) generisch funktionieren, derart, dass diese Schnittstellen (9) dank durch von den Konnektoren (15) bereitgestellten und im Cache (14) gesammelten Meta-Informationen keine Änderung erfahren müssen, wenn via Konnektoren (15) zusätzliche Dienstanbieter (16) und deren Dienste (17) angebunden werden.

4. OpaccServiceBus nach den vorangehenden Ansprüchen, dadurch gekennzeichnet, dass verschiedene Dienstanbieter (16), die mit unterschiedlichsten Technologien realisiert sind, angebunden werden können.