DE60218160T2

DE60218160T2 - Verfahren und systeme zur datenübertragung über ein netz

Info

Publication number: DE60218160T2
Application number: DE60218160T
Authority: DE
Inventors: Mohan Union City SANKARAN; Volodymyr San Jose BUTSKY; C. Sridhar Fremont KORITALA; Zhenyu Fremont TANG
Original assignee: Informatica LLC
Current assignee: Informatica LLC
Priority date: 2001-06-15
Filing date: 2002-06-14
Publication date: 2007-10-31
Anticipated expiration: 2022-06-15
Also published as: CA2450869A1; EP1400086A2; US7162643B1; DE60218160D1; ES2281515T3; CA2450869C; EP1400086B1; WO2002103984A2; ATE354242T1; WO2002103984A3

Description

GEBIET
Die Offenbarung betrifft im Allgemeinen Computersystemnetze und insbesondere die Sicherung von schneller, zuverlässiger und privater Kommunikation zwischen vernetzten Computern in einer Mehrfach-Data-Warehouse-/analytischen Anwendungsumgebung. Die Offenbarung betrifft ein Verfahren und System zur Bereitstellung von Übertragung von analytischen Anwendungsdaten über ein Netz.
HINTERGRUND
Computer werden zur Durchführung einer großen Vielfalt von Anwendungen in unterschiedlichen Gebieten wie Finanzen, traditionelle und elektronische kommerzielle Transaktionen, Fertigung, Gesundheitspflege, Telekommunikation usw. eingesetzt. Die meisten dieser Anwendungen umfassen normalerweise Eingabe oder elektronischen Empfang von Daten, Verarbeiten der Daten nach einem Computerprogramm, dann Speichern der Ergebnisse in einer Datenbank und unter Umständen Übertragen der Daten zu einer anderen Anwendung, einem Messaging-System oder einem Client in einem Computernetz. Computer werden leistungsfähiger, schneller und vielseitiger, und gleichzeitig nimmt der Umfang der Daten zu, die verarbeitet werden können.
Leider existieren die in Betriebsdatenbanken gefundenen Rohdaten oft als Reihen und Spalten von Zahlen und Codes, die, wenn sie von Personen betrachtet werden, als verwirrend und unverständlich erscheinen. Zudem sind der Umfang und das Ausmaß der in einer modernen Datenbank gespeicherten Rohdaten überwältigend für einen beiläufigen Betrachter. Daher wurden Anwendungen entwickelt, um beim Interpretieren, Analysieren und Zusammenstellen der Daten zu helfen, damit sie schnell und einfach von Menschen verstanden werden. Dies erfolgt durch Durchsuchen, Sortieren und Zusammenfassen der Rohdaten, bevor sie für Anzeige, Speicherung oder Übertragung präsentiert werden. Dadurch können Personen die Daten jetzt interpretieren und auf ihrer Grundlage wichtige Entscheidungen fällen.
Extrahieren von Rohdaten aus einer oder mehreren Betriebsdatenbanken und ihre Umwandlung in nützliche Informationen (z. B. Daten-„Warehouses" und Daten-„Marts") ist die Funktion von analytischen Anwendungen. In Daten-Warehouses und Daten-Marts sind die Daten strukturiert, um Rollen bei der Entscheidungsunterstützung anstelle von Betriebserfordernissen zu unterstützen. Ein Daten-Warehouse verwendet ein Geschäftsmodell, um Betriebsdaten zu kombinieren und zu verarbeiten und sie in einer konsistenten Weise verfügbar zu machen. Bevor die Daten in das Daten-Warehouse geladen werden, werden die korrespondierenden Ausgabedaten aus einer Betriebsdatenbank gefiltert, um überzählige und fehlerhafte Einträge zu entfernen; kryptische und in Konflikt stehende Einträge werden aufgelöst; Rohdaten werden in etwas Aussagekräftigeres übersetzt; und zusammengefasste Daten, die für Entscheidungsunterstützung, Trendanalyse und Modellbildung oder andere Anforderungen von Endbenutzern nützlich sind, werden im Voraus berechnet. Ein Daten-Mart ist ähnliche einem Daten-Warehouse mit dem Unterschied, dass es eine Teilmenge von Unternehmensdaten für einen einzelnen Geschäftsaspekt wie Finanzen, Vertrieb, Lagerbestand oder Personal enthält.
Schließlich umfasst das Daten-Warehouse oder Daten-Mart eine „analytische" Datenbank, die äußerst große Datenmengen enthält, die nützlich sind für direkte Entscheidungsunterstützung oder zur Verwendung in Anwendungen, die zur anspruchsvollen statistischen oder logischen Analyse der umgewandelten Betriebsrohdaten imstande sind. Durch Daten-Warehouses und Daten-Marts werden nützliche Informationen zur Verfügung von Entscheidungsträgern und Benutzern von analytischen Anwendungen gehalten und können in einem vernetzten System an Daten-Warehouse-Server verteilt werden. Zusätzlich können Entscheidungsträger-Clients analytische Daten, die in einem entfernten Daten-Warehouse-Server gespeichert sind, über ein Computersystemnetz abrufen.
Ein Beispiel des Unternehmenstyps, der Daten-Warehousing verwenden würde, ist ein Online-Intemet-Buchvertrieb, der Millionen von Kunden in aller Welt hat, deren Buchvorlieben und -käufe verfolgt werden. Durch Verarbeitung und Warehousing dieser Daten können Führungskräfte des Buchvertriebs auf die verarbeiteten Daten aus dem Daten-Warehouse zugreifen, die für komplizierte Analyse und zum Fällen von wichtigen Entscheidungen, wie die Anforderungen ihrer Kunden in aller Welt besser erfüllt werden können, genutzt werden können.
Durch die schnelle Zunahme der Nutzung von Netzsystemen wie Weitbereichsnetze (WAN), das World Wide Web und das Internet wird die Fähigkeit bereitgestellt, Betriebsdaten in Datenbankanwendungen zu übertragen und Daten gemeinsam zu nutzen, die in Datenbanken enthalten sind, die sich in disparaten vernetzten Servern befinden. Beispielsweise werden ständig große Mengen von Währungstransaktionsdaten durch elektronischen Handel zwischen Unternehmen und Kunden und zwischen Untemehmen und Unternehmen, der über das Internet erfolgt, erzeugt. Diese Transaktionsdaten werden routinemäßig in Betriebsdatenbanken zur Speicherung, Verarbeitung und Verteilung an Datenbanken in vernetzten Servern erfasst und gesammelt.
Die erweiterte Nutzung von „Messaging-Systemen" und dergleichen erhöht die Fähigkeit von Netzen zur Übertragung von Daten und Bereitstellung von Interoperabilität zwischen disparaten Datenbanksystemen. Messaging-Systeme sind Computersysteme, die es gestatten, logische Elemente von unterschiedlichen Anwendungen nahtlos miteinander zu verknüpfen. Messaging-Systeme ermöglichen außerdem die Lieferung von Daten über einen großen Bereich von Hardware- und Software-Plattformen und gestatten es Anwendungen, trotz Unterschieden in zgrundeu liegenden Protokollen, Systemarchitekturen, Betriebssystemen und Datenbankdiensten über Netzverbindungen zusammenzuarbeiten. Messaging-Systeme und die kützliche Entwicklung von Internetzugang über drahtlose Vorrichtungen wie dazu fähigen Zellulartelefonen, Zweiwege-Funkrufempfängem und Handheld-Personal-Computern unterstützen die Verbesserung der Datenübertragung und -speicherung und der Interoperabilität von disparaten Datenbanksystemen.
In der gegenwärtigen Daten-Warehouse-/Daten-Mart-Netzwerkumgebung betrifft eine allgemeine Besorgnis das bloße Volumen der Daten, die zu handhaben sind. Oft sind massive Datendateien von mehreren Terabyte an verschiedenen Serverstandorten von Daten-Warehouses oder in Betriebsdatenbanken gespeichert. Übertragung dieser massiven Datenmengen über WANs oder das Internet ist eine schwierige Aufgabe. Die zum Bewegen der Daten erforderliche Zeit ist beträchtlich, und die Wahrscheinlichkeit, dass die Daten einen während der Übertragung verursachten Fehler enthalten, nimmt zu. Außerdem sind die Daten anfällig gegenüber Abfangen durch eine nicht berechtigte Partei. Wenn die Verbindung während des Prozesses der Übertragung der Daten über ein Netzwerk verloren geht, besteht weiterhin oft das Erfordernis, große Datenmengen neu zu übertragen, die bereits vor dem Verbindungsverlust übertragen wurden, wodurch die Zeit zum Verlagern der Daten weiter erhöht wird.
Das US-Patent 5689566 beschreibt ein Computersystem und ein Verfahren zum Übertragen von Daten über ein Computernetz. Es betrifft die Anpassung des Sicherheitsniveaus auf der Grundlage der Art der Kommunikation.
Folglich besteht ein Bedarf an einem zuverlässigen, sicheren, authentifizierten, überprüfbaren und schnellen System und/oder Verfahren zur Übertragung von gewaltigen Datenmengen wie Daten in einem Daten-Warehouse/-Mart über Netzwerken wie WANs oder das Internet. Die vorliegende Erfindung stellt eine neue Lösung für diesen Bedarf bereit.
ZUSAMMENFASSUNG DER ERFINDUNG
Ein erster Aspekt der Erfindung stellt ein Verfahren zum Übertragen von Daten gemäß dem hieran angefügten Anspruch 1 bereit.
Ein zweiter Aspekt der Erfindung stellt ein Verfahren zum Empfangen von Daten gemäß dem hieran angefügten Anspruch 10 bereit.
Ein dritter Aspekt der Erfindung stellt eine Computervorrichtung gemäß dem hieran angefügten Anspruch 18 bereit.
Ein vierter Aspekt der Erfindung stellt eine Computervorrichtung gemäß dem hieran angefügten Anspruch 19 bereit.
Die vorliegende Erfindung befriedigt einen gegenwärtig nicht erfüllten Bedarf in einer vernetzten Daten-Warehouse-/analytischen Anwendungsumgebung zur Bereitstellung eines Verfahrens und Systems, die ein zuverlässiges, sicheres, authentifiziertes, überprüfbares und schnelles System und Verfahren zur Übertragung von großen Datenmengen über ein Netzwerk (z. B. Betriebsdaten und umgewandelte Daten in einem Daten-Warehouse/Daten-Mart) bietet. Die Daten können von einer Quelle zu einem Ziel (z. B. von einem Server zu einem Client oder von einem Client zu einem Server) in dem Computersystemnetz bewegt werden. Die Quelle repräsentiert jede zentralisierte Quelle in dem Netzwerk, während das Ziel eine entfernt angeordnete Vorrichtung (z. B. an einem Kundenstandort) oder eine lokale Vorrichtung (z. B. eine Vorrichtung in Kommunikation mit der Quelle über ein lokales Netz) repräsentieren kann.
In einer Ausführungsform wird in einem Quellen-Computersystem (z. B. Server) eine eingehende Anforderung von einem Ziel (z. B. Client) für eine große Datenmenge (z. B. eine Datendatei), die beispielsweise in einem Massenspeichergerät in dem Server vorhanden ist, empfangen. Die eingehende Anforderung wird authentifiziert und wird dann verwendet, um einen Sitzungs-Thread zwischen dem Server und dem Client hervorzubringen. Die eingehende Anforderung enthält einen Befehl, der in einer Ausführungsform Extensible Markup Language (XML) verwendet. Der Befehl wird analysiert und in einen Satz von Aufgaben übersetzt, die von dem Server als Teil des Sitzungs-Threads ausgeführt werden können.
In einer Ausführungsform werden die Daten in Blöcke aufgeteilt und jeder Block wird der Reihe nach komprimiert und verschlüsselt und dann zu dem Client übertragen. In einer Ausführungsform werden die Blöcke parallel verarbeitet, wodurch Zeit eingespart wird. Die Übertragung der Daten zum Client wird überprüft um zu gewährleisten, dass sie vollständig und richtig ist.
An der Clientseite wird der Sitzungs-Thread zwischen dem Server und dem Client als Reaktion auf eine Nachricht von dem Server hervorgebracht. Die komprimierten und verschlüsselten Datenblöcke werden von dem Server empfangen, dekomprimiert, entschlüsselt und zu den angeforderten Daten zusammengesetzt.
Die vorliegende Erfindung stellt einen Wiederherstellungsmechanismus für automatische oder manuelle Wiederherstellung einer Verbindung zwischen dem Server und dem Client bereit, wenn die Verbindung unterbrochen wurde. Als Bestandteil des Wiederherstellungsmechanismus wird die Datenübertragung wieder an dem Punkt aufgenommen, an dem sie bei der Unterbrechung der Verbindung beendet wurde, so dass vorher übertragene Daten nicht erneut übertragen werden müssen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird als Beispiel und nicht durch Beschränkung in den Figuren der beigefügten Zeichnungen dargestellt, in denen sich ähnliche Bezugsnummern auf ähnliche Elemente beziehen und von denen:
1A ein schematisches Blockdiagramm eines beispielhaften Client/Server-Computersystemnetzes zeigt, in dem Ausführungsformen der vorliegenden Erfindung implementiert werden können.
1B ein beispielhaftes Computersystem zeigt, in dem Ausführungsformen der vorliegenden Erfindung ausgeführt werden können.
2A ein allgemeines funktionales Blockdiagramm eines Computersystemnetzes nach einer Ausführungsform der vorliegenden Erfindung zeigt.
2B ein detaillierteres funktionales Blockdiagramm des Computersystemnetzes zeigt, das allgemein in 2A dargestellt ist.
3A Datenfluss durch eine erste Ausführungsform eines Ausgabekanals der vorliegenden Erfindung zeigt.
3B Datenfluss durch eine erste Ausführungsform eines Eingabekanals der vorliegenden Erfindung zeigt.
4A Datenfluss durch eine zweite Ausführungsform eines Ausgabekanals der vorliegenden Erfindung zeigt.
4B Datenfluss durch eine zweite Ausführungsform eines Eingabekanals der vorliegenden Erfindung zeigt.
5 Datenfluss durch eine Ausführungsform eines Sitzungs-Threads nach der vorliegenden Erfindung zeigt.
6A, 6B und 6C Wiederherstellung der Datenübertragung nach einem Ausfall einer Netzverbindung nach einer Ausführungsform der vorliegenden Erfindung zeigen.
7A ein Ablaufdiagramm der Schritte in einem serverseitigen Prozess zur Übertragung von Daten über ein Netzwerk nach einer Ausführungsform der vorliegenden Erfindung zeigt.
7B ein Ablaufdiagramm der Schritte in einem clientseitigen Prozess zur Übertragung von Daten über ein Netzwerk nach einer Ausführungsform der vorliegenden Erfindung zeigt.
AUSFÜHRLICHE BESCHREIBUNG
Jetzt wird detailliert Bezug genommen auf die bevorzugten Ausführungsformen der Erfindung, von denen Beispiele in den beigefügten Zeichnungen dargestellt sind. Während die Erfindung in Verbindung mit den bevorzugten Ausführungsformen beschrieben wird, wird verstanden werden, dass sie nicht vorgesehen sind, um die Erfindung auf diese Ausführungsformen zu beschränken. Im Gegenteil ist die Erfindung vorgesehen, Alternativen, Abwandlungen und Äquivalente, die im Geist und Rahmen der Erfindung, wie durch die beigefügten Patentansprüche definiert, sein können, abzudecken. Weiterhin werden in der folgenden ausführlichen Beschreibung der vorliegenden Erfindung zahlreiche spezifische Details dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung zu vermitteln. Es wird jedoch für Durchschnittsfachleute des Fachgebiets offensichtlich sein, dass die vorliegende Erfindung ohne diese spezifischen Details ausgeführt werden kann. In anderen Fällen wurden gut bekannte Verfahren, Prozeduren, Komponenten und Schaltungen nicht ausführlich beschrieben, um Aspekte der vorliegenden Erfindung nicht unnötigerweise schwer verständlich zu machen.
Einige Abschnitte der folgenden ausführlichen Beschreibungen werden in Form von Prozeduren, logischen Blöcken, Verarbeitung und anderen symbolischen Repräsentationen von Operationen mit Datenbits in einem Computerspeicher dargestellt. Diese Beschreibungen und Repräsentationen sind die Mittel, die von Fachleuten auf dem Gebiet der Datenverarbeitung verwendet werden, um die Substanz ihrer Arbeit wirksam an andere Fachleute zu übermitteln. In der vorliegenden Anwendung wird eine Prozedur, ein logischer Block, ein Prozess oder dergleichen als eine folgerichtige Sequenz von Schritten oder Befehlen angesehen, die zu einem gewünschten Ergebnis führen. Die Schritte sind diejenigen, die physikalische Manipulation von physikalischen Quantitäten erfordern. Gewöhnlich, aber nicht notwendigerweise, nehmen diese Quantitäten die Form von elektrischen oder magnetischen Signalen an, die in einem Computersystem gespeichert, übertragen, kombiniert, verglcihen oder anderweitig manipuliert werden können. Es hat sich manchmal als praktisch erwiesen, hauptsächlich aus Gründen der normalen Verwendung, sich auf diese Signale als Sitzungen, Objekte, Blöcke, Teile, Threads oder dergleichen zu beziehen.
Es muss jedoch bedacht werden, dass sämtliche dieser und ähnlicher Begriffe mit den entsprechenden physikalischen Quantitäten assoziiert werden müssen und lediglich praktische Etiketten sind, die auf diese Quantitäten angewandt werden. Wenn nicht speziell anders angegeben, wird, wie aus den folgenden Diskussionen ersichtlich, durch die vorliegende Erfindung davon ausgegangen, dass Diskussionen, die Begriffe wie „Erstellen", „Ausgeben", „Authentifizieren", „Herstellen", „Übertragen", Akkumulieren" Wiederherstellen" Wiederaufnehmen" Übersetzen" Speichern" Ausführen" Empfangen" Schreiben" Komprimieren" Dekomprimieren" Verschlüsseln" Entschlüsseln" „Senden", „Überprüfen" oder dergleichen verwenden, sich auf Aktionen und Prozesse (z. B. Prozesse 700 und 705 von 7A bzw. 7B) eines Computersystems oder einer ähnlichen elektronischen Rechenvorrichtung beziehen. Das Computersystem oder die ähnliche elektronische Rechenvorrichtung manipuliert und wandelt Daten um, die als physikalische (elektronische) Quantitäten in den Speichern, Registern oder anderen derartigen Informationsspeicher-, -übertragungs- oder -anzeigevorrichtungen repräsentiert werden. Die vorliegende Erfindung ist gut geeignet für die Verwendung von anderen Computersystemen.
1A zeigt ein Blockdiagramm des Client/Server-Computersystemnetzes 100, auf dem Ausführungsformen der vorliegenden Erfindung ausgeführt werden können. Dieses Client/Server-System 100 besteht aus dem Server-Computersystem 110 (z. B. Unix- oder NT-Servercomputer), dem Client-Computersystem 102 und entfernten Computersystemen 103–105 (z. B. Personal-Computer, Laptop-Computer, Workstations, Endgeräte usw.), die für den Zugriff auf die Informationen, die für das Server-Computersystem 110 verfügbar sind, verwendet werden können. Der Server 110 kann jede zentralisierte Quelle in dem Netzwerk 100 repräsentieren, während der Client 102 und die entfernten Computersysteme 103–105 eine entfernt angeordnete Vorrichtung (z. B. an einem Kundenstandort) oder eine lokale Vorrichtung (z. B. eine Vorrichtung, die über ein lokales Netz mit dem Server 110 in Kommunikation ist) repräsentieren können.
Jedes entfernte Computersystem 103–105 hat sein eigenes physikalisches Speichersystem (z. B. Festplatte, Direktzugriffsspeicher, Nur-Lese-Speicher usw.) zum Speichern und Manipulieren von Daten. Das Client-Computersystem 102, das Server-Computersystem 110 und die entfernten Computersysteme 103–105 sind durch den Netzwerkbus 107 für Interkommunikation und Übertragung von Daten verbunden. Es ist jedoch ersichtlich, dass diese Vorrichtungen stattdessen in einem drahtlosen Netzwerk verkoppelt sein können.
Das Server-Computersystem 110 ist an die Server-Massenspeichervorrichtung 112 gekoppelt, die durch den Netzwerkbus 107 direkt zugänglich durch das Client-Computersystem 102 und die Computerendgeräte 103–105 ist oder nicht. Das Clientsystem 102 verfügt außerdem über seine eigene Client-Massenspeichervorrichtung 170. Die vorliegende Erfindung enthält Threads und Objekte in der Anwendungssoftware, die vom Server-Computersystem 110 und/oder Clientsystem 102 ausgeführt werden, um Daten dazwischen zu übertragen (siehe 2B unten).
In der Massenspeichervorrichtung 112 befindet sich die Betriebsdatenbank 116a, die die aktuellen Rohdaten für ein Daten-Mart oder Daten-Warehouse empfängt und speichert. Empfangene Rohdaten, die in der Betriebsdatenbank 116a gespeichert sind, werden von einer analytischen Anwendung in Informationen umgewandelt, die aussagekräftiger für Entscheidungsunterstützung sind. Daten-Marts/-Warehouses 113a, die sich in der Massenspeichervorrichtung 112 befinden, enthalten umgewandelte Daten, die von der analytischen Anwendung verarbeitet wurden. Es ist wichtig herauszustellen, dass die Daten-Marts/-Warehouses 113a und die Betriebsdatenbank 116a jeweils in getrennten Massenspeichervorrichtungen gespeichert sein könnten und dass jede Massenspeichervorrichtung über den Netzwerkbus 107 mit einem separaten Server verbunden sein könnte.
Eine Datendatei 120 ist eine Datei, die entweder in der Betriebsdatenbank 116a, in der Datenbank des Daten-Warehouses/Daten-Marts 113b oder woanders in der Server-Massenspeichervorrichtung 112 gespeichert ist. Nach der vorliegenden Erfindung wird die Datendatei 120 sicher, schnell und zuverlässig über den Netzwerkbus 107 an das Client-Computersystem 102 oder die entfernten Computersysteme 103–105 zur Anzeige oder Speicherung in diesen Systemen oder zur Verwendung in analytischen Anwendungen, die in diesen Systemen residieren, übertragen. Die Datendatei 120 ist eine große Datei, die beispielsweise Betriebsdaten wie Kundendaten oder Daten einer dritten Partei enthält. Die Datendatei 120 kann stattdessen Daten enthalten, die nach einer analytischen Anwendung umgewandelt wurden. Es ist ersichtlich, dass die vorliegende Erfindung auch verwendet werden kann, um einen Datenstrom vom Server-Computersystem 110 zu einer Zielvorrichtung (z. B. Client-Computersystem 102 oder an die entfernten Computersysteme 103–105) zu übertragen.
Die Betriebsdatenbank 116b und das Daten-Warehouse 113b sind auch als in der Client-Massenspeichervorrichtung 170 gespeichert dargestellt. Eine Datendatei 120 ist auch als in der Client-Massenspeichervorrichtung 179 gespeichert dargestellt, um die Übertragung und den Empfang der Datendatei, wie im vorstehenden Absatz erwähnt, zu repräsentieren. Es ist ersichtlich, dass die vorliegende Erfindung gleichermaßen verwendet werden kann, um eine Datendatei (oder einen Datenstrom) vom Client 102 an den Server 110 oder von diesen Vorrichtungen an jede andere Vorrichtung im Netzwerk 100 zu übertragen. Allgemein ausgedrückt, kann die vorliegende Erfindung verwendet werden, um eine Datendatei oder einen Datenstrom von einer Quellvorrichtung zu einer Zielvorrichtung zu übertragen. Zur Vereinfachung der Diskussion wird die vorliegende Erfindung im Kontext einer Übertragung einer Datendatei von einem Server an einen Client beschrieben.
Jetzt wird Bezug genommen auf 1B, die ein beispielhaftes Computersystem 1090 darstellt, auf dem Ausführungsformen der vorliegenden Erfindung ausgeführt werden können. Das Computersystem 1090 veranschaulicht den Server 110, den Client 102 und die entfernten Computersysteme 103–105 von 1A.
Im Allgemeinen umfasst das Computersystem 1090 von 1B Bus 1000 zur Übertragung von Informationen, einen oder mehrere Prozessoren 1001, die an den Bus 1000 gekoppelt sind, zur Verarbeitung von Informationen und Befehlen, Direktzugriffsspeicher (flüchtig) (RAM) 1002, der an den Bus 1000 gekoppelt ist, zur Speicherung von Informationen und Befehlen für Prozessor 1001, Nur-Lese-Speicher (nicht flüchtig) (ROM) 1003, der an den Bus 1000 gekoppelt ist, zur Speicherung von statischen Informationen und Befehlen für Prozessor 1001, Datenspeichervorrichtung 1004 wie eine magnetische oder optische Platte und ein Plattenlaufwerk, das an den Bus 1000 gekoppelt ist, zur Speicherung von Informationen und Befehlen, eine optionale Benutzerausgabevorrichtung wie Anzeigevorrichtung 1005, die an den Bus 1000 gekoppelt ist, zur Anzeige von Informationen für den Computerbenutzer, eine optionale Benutzereingabevorrichtung wie eine alphanumerische Eingabevorrichtung 1006 einschließlich von alphanumerischen und Funktionstasten, die an den Bus 1000 gekoppelt ist, zur Übertragung von Informationen und Befehlsauswahlen an Prozessor 1001, und eine optionale Benutzerausgabevorrichtung wie Cursorsteuerungsvorrichtung 1007, die an den Bus 1000 gekoppelt ist, zur Übertragung von Eingabeinformationen und Befehlsauswahlen an Prozessor 1001. Weiterhin wird eine optionale Eingabe-/Ausgabe-(E/A)-Vonichtung 1008 verwendet, um das Computersystem 1090 an beispielsweise ein Netzwerk zu koppeln.
Die Anzeigevorrichtung 1005, die vom Computersystem 1090 verwendet wird, kann eine Flüssigkristallvorrichtung, eine Kathodenstrahlröhre oder eine andere Anzeigevorrichtung sein, die geeignet ist, um grafische Bilder und alphanumerische Zeichen zu erzeugen, die für den Benutzer erkennbar sind. Die Cursorsteuerungsvorrichtung 1007 gestattet es dem Computerbenutzer, dynamisch die zweidimensionale Bewegung eines sichtbaren Symbols (Zeiger) auf einem Anzeigebildschirm der Anzeigevorrichtung 1005 zu signalisieren. Viele Implementierungen der Cursorsteuerungsvorrichtung sind im Fachgebiet bekannt, einschließlich eines Trackballs, einer Maus, eines Joysticks oder von Spezialtasten auf der alphanumerischen Eingabevorrichtung 1006, die imstande sind, die Bewegung einer gegebenen Richtung oder einer Weise der Verlagerung zu signalisieren. Es ist ersichtlich, dass die Cursorsteuerung 1007 auch durch Eingabe von der Tastatur unter Verwendung von Spezialtasten und Tastenfolgebefehlen gelenkt und/oder aktiviert werden kann. Alternativ kann der Cursor über Eingabe von einer Zahl von speziell angepassten Cursorlenkvorrichtungen gelenkt und/oder aktiviert werden.
2A zeigt ein funktionales Blockdiagramm einer Ausführungsform des Client/Server-Computersystemnetzes 100 von 1A nach einer Ausführungsform der vorliegenden Erfindung. In dieser Ausführungsform, auch unter Bezug auf 1A, stellt die vorliegende Erfindung einen sicheren Datenstrom 118 bereit, der die Datendatei 120 vom Server-Computersystem 110 zum Client-Computersystem 102 überträgt. Die Datendatei 120 ist ursprünglich im Daten-Warehouse 113a oder in der Betriebsdatenbank 116a in der Server-Massenspeichervorrichtung 112 gespeichert und wird zur Client-Massenspeichervorrichtung 170 übertragen.
Zur Vereinfachung der Diskussion wird Kommunikation als vom Server 110 zum Client 102 erfolgend dargestellt; es ist jedoch ersichtlich, dass Kommunikation gleichermaßen vom Client 102 zum Server 110 erfolgen kann. In diesem letztgenannten Fall würden die Pfeile, die die Richtung des Datenflusses angeben, in die entgegen gesetzte Richtung zeigen, der „Ausgabekanal" würde sich auf den Kanal am Client 102 beziehen und der „Eingabekanal" würde sich auf den Kanal am Server 110 beziehen.
2B zeigt ein funktionales Blockdiagramm, das zusätzliche Details des Client/Server-Computersystemnetzes 100 nach einer Ausführungsform der vorliegenden Erfindung vermittelt. Das Listenerobjekt 130a ist vorgesehen, um eine eingehende Verbindungsanforderung zu empfangen und einen Sitzungs-Thread 140a als Reaktion darauf hervorzubringen (genauer ausgedrückt, ruft Listenerobjekt 130a das Sitzungsmanagerobjekt 138a auf, um den Sitzungs-Thread 140a zu erzeugen). Das Server-Listenerobjekt 130a empfängt an einem gut bekannten Port 132 eine eingehende Anforderung 134 vom Client-Computersystem 102. In der vorliegenden Ausführungsform wird die Anforderung 134 in dem auf dem Client 102 ausgeführten Sitzungs-Thread 140b erzeugt. Die Anforderung 134 ist eine Anforderung zur Herstellung einer Client-Socket-Verbindung 136 und zur Übertragung von Daten von der Server-Massenspeichervorrichtung 112 (z. B. Datendatei 120) zum Client-Computersystem 102.
Eine Anforderung 134 kann von einer entfernten Vorrichtung im Netz 100 oder von einer lokalen Vorrichtung empfangen werden. Das heißt, dass eine Anforderung 134 beispielsweise über das Internet von einer Vorrichtung empfangen werden kann, die sich außerhalb einer Firewall oder eines Unternehmens-Intranets (z. B. ein lokales Netz) befindet, oder die Anforderung 134 kann von einer lokalen Vorrichtung innerhalb des Unternehmens-Intranets stammen. Anstatt zu versuchen, die Quelle der Anforderung 134 zu bestimmen, werden in der vorliegenden Ausführungsform jedoch alle Anforderungen in verschlüsselter Form geliefert/empfangen.
In der vorliegenden Ausführungsform werden alle Computer im Netzwerk 100 als unsicher angesehen. Alle Schlüssel werden in verschlüsselter Form gespeichert, wobei ein Kennwort-basierender Entschlüsselungsalgorithmus zur Entschlüsselung und Verschlüsselung von Schlüsseln verwendet wird.
Alle registrierten Benutzer, die den Datenabrufprozess der vorliegenden Erfindung implementieren möchten, haben ihr eigenes Konto. Schlüssel für jedes Konto werden in separaten Dateien gespeichert. Jede Datei hat den Namen des Kontos und wird unter Verwendung des Kontenkennworts verschlüsselt. Alle registrierten Kontenschlüsseln werden in einem zentralen Verzeichnis gespeichert (nicht dargestellt) und werden unter Verwendung eines Verzeichniskennworts verschlüsselt. In der vorliegenden Ausführungsform wird das Verzeichnis mit einem einzelnen Kennwort initialisiert, das durch ein Administratorkennwort verborgen und gesichert ist. Das Verzeichniskennwort wird für alle gesicherten (verschlüsselten) Objekte verwendet.
Das zentrale Verzeichnis ist im Hauptspeicher des Servers 110 gespeichert (und gleichermaßen ist ein zentrales Verzeichnis im Hauptspeicher des Clients 102 gespeichert). Das zentrale Verzeichnis verfügt über die Fähigkeit zur Verschlüsselung jedes gespeicherten Objekts unter Verwendung von Kennwort-basierender Verschlüsselung. In einer Ausführungsform fragt das zentrale Verzeichnis das Objekt, ob es Verschlüsselung benötigt.
In der vorliegenden Ausführungsform gibt es drei Verzeichnis-Objektarten: ein Objekt zur Repräsentation eines Kontos, ein Objekt, das ein Verzeichniskennwort für das administrative Konto repräsentiert, und ein Objekt zur Repräsentation jeder Sitzungsinstanz für Wiederherstellungszwecke. Das Objekt, das ein Konto repräsentiert, enthält einen Schlüssel (oder ein Kennwort), der verwendet wird, um eine sichere Verbindung zwischen dem Client 102 und dem Server 110 der 2A und 2B herzustellen. Das Objekt, das das Verzeichniskennwort für das administrative Konto repräsentiert, wird verwendet, um Zugang zu allen Verzeichnisobjekten zu erhalten, und ist durch ein Administratorkonto-Kennwort gesichert. Das Objekt, das jede Sitzungsinstanz repräsentiert, enthält alle Informationen, die für Sitzungswiederherstellung benötigt werden (siehe 6A, 6B und 6C unten).
Wieder mit Bezugnahme auf 2B, ist das Listenerobjekt 130a in der vorliegenden Ausführungsform Bestandteil einer Mehrfach-Thread-Software-Anwendung, die zur parallelen Ausführung in Koordination mit anderen Threads der vorliegenden Erfindung fähig ist. Ein „Thread" ist ein Bestandteil der Anwendung, der unabhängig von den anderen Teilen, die unter Umständen gleichzeitig in diesem Parallelmodus ausgeführt werden, ausgeführt werden kann. Parallele Ausführung von Threads wird in dieser Ausführungsform der vorliegenden Erfindung erreicht, indem so viel wie möglich der Anwendungsausführung zwischen den verschiedenen Threads geteilt wird. Eine derartige Mehrfach-Threading-Ausführungsform erhöht die Geschwindigkeit der Datenübertragung in der vorliegenden Erfindung.
Das Listenerobjekt 130a stellt eine Client-Socket-Verbindung 136 an dem gut bekannten Port 132, die vom Client-Computersystem 102 angefordert wurde, am Server-Computersystem 110 her. Wenn eine Benutzer-Anforderung 134 empfangen wird, ruft der Listener-Thread 130a das Sitzungsmanagerobjekt 138a auf, um einen neuen Sitzungs-Thread zu erzeugen und die Handhabung der Benutzeranforderung zu beginnen. Nach der Ausführung dieser Aufgaben kehrt das Listenerobjekt 130a zurück zur Aufgabe, auf eine andere eingehende Benutzeranforderung zu horchen (z. B. eine andere Anforderung vom Client-Computersystem 102 oder von einem anderen Computersystem im Netzwerk 100 von 1A).
In der vorliegenden Ausführungsform bringt das Sitzungsmanagerobjekt 138a von 2B den Sitzungs-Thread 140a hervor, der einen Befehl von der Verbindung liest, die vom Listenerobjekt 130a hergestellt wurde, den Befehl analysiert und ihn ausführt (siehe auch 5 unten). Das Sitzungsmanagerobjekt 138a enthält (verfolgt) Informationen hinsichtlich aller laufenden Sitzungen.
Eine Sitzung 140a enthält ein Kanalobjekt mit mehreren Threads (z. B. Kanal 139a), über den die Daten tatsächlich übertragen werden. Das Kanalobjekt 139a ist vorgesehen, um Daten in einer sicheren Weise zu übertragen. Zusätzliche Informationen in Bezug auf das Kanalobjekt 139a werden unten in Verbindung mit den Figwen 3A, 3B, 4A und 4B gegeben.
Bezug nehmend auf 2B, wird aus Sicherheitsgründen nur Clients, die zum Zugriff auf das Daten-Warehouse 113a und die Betriebsdatenbank 116 befugt sind, gestattet, die Datendatei 120 zu empfangen. Ein in der vorliegenden Erfindung inkorporiertes Protokoll ist zur Authentifizierung vorgesehen, dass die eingehende Anforderung 134 von einem Client-Computersystem 102 stammt, das zum Empfang der Datendatei 120 befugt ist. Authentifizierungsprotokolle können Kennwörter, intelligente Token oder andere gut bekannte Techniken enthalten.
In der vorliegenden Ausführungsform stellt das Sitzungsmanagerobjekt 138a die Anwendungsprogrammschnittstellen (APIs) zur Überwachung und Verwaltung von Sitzungen bereit. Ein Objekt ist ein Anwendungsdatenelement, das Befehle für die mit ihm durchzuführenden Operationen enthält. Nachdem das Listenerobjekt 130a eine Benutzeranforderung 134 empfängt, empfängt das Sitzungsmanagerobjekt 138a einen Aufruf vom Listenerobjekt 130a zum Erzeugen und Starten eines Sitzungs-Threads 140a zur Verarbeitung von Benutzerbefehlen. In dieser Ausführungsform bringt das Sitzungsmanagerobjekt 138a den Sitzungs-Thread 140a hervor.
Das Sitzungsmanagerobjekt 138a stellt die Funktionalität zur Erzeugung einer eindeutigen Identifizierung (ID) für eine Sitzung und zur Verwaltung von Sitzungsprotokollen für Wiederherstellungszwecke bereit. Die vom Sitzungsmanagerobjekt 138a bereitgestellten APIs enthalten eine API zum Erzeugen einer Sitzung, eine API zum Ausführen der Sitzung, eine API zum Anhalten der Sitzung durch Übergabe der Sitzungs-ID, eine API zum Aktualisieren des Status der Sitzung durch Übergabe der Sitzungs-ID, eine API zum Abfragen von Sitzungsinformationen und eine API zum Wiederherstellen einer fehlgeschlagenen Sitzung.
In der vorliegenden Ausführungsform weist das Sitzungsmanagerobjekt 138a, nachdem es eine neue Sitzung erzeugt hat, dieser Sitzung eine eindeutige ID zu. Das Sitzungsmanagerobjekt 138a speichert (z. B. in einer internen Hash-Tabelle) ein Sitzungsinformationenobjekt. Das Sitzungsmanagerobjekt 138a übergibt bei der Erzeugung einer neuen Sitzung seinen eigenen Verweis als einen Initialisierungsparameter an die Sitzung. Die Sitzung verwendet diesen Verweis dann in Kombination mit ihrer eindeutigen Sitzungs-ID zum Aufrufen einer Sitzungsmanager-Callback-Funktion zur Bereitstellung einer Aktualisierung ihrer Statusinformationen für das Sitzungsmanagerobjekt 138a.
Damit empfängt das Listenerobjekt 130a des Servers 110 in der vorliegenden Ausführungsform der vorliegenden Erfindung eine eingehende Verbindungsanforderung vom Client 102 und leitet die eingehende Verbindungsanforderung weiter an das Sitzungsmanagerobjekt 138a. Das Sitzungsmanagerobjekt 138a des Servers 110 bringt den Sitzungs-Thread 140a hervor, der den Befehl von der Verbindungsanforderung 134 liest (z. B. einen Befehl, der Übertragung der Datendatei 120 von 2A anfordert). Der Befehl enthält alle Informationen, die erforderlich sind, um die Datendatei 120 zu öffnen und die Datendatei 120 durch eine Verbindung zwischen dem Client 102 und dem Server 110 zu senden. Die Sitzung 140a analysiert den Befehl und erzeugt und initiiert ein Kanalobjekt 139a (mit seinen Threads) und führt den Kanal aus. Das Kanalobjekt 139a wird mit der gegenwärtig eingerichteten Netzverbindung zwischen dem Server 110 und dem Client 102 initialisiert.
Das Kanalobjekt 139a repräsentiert den Satz von Objekten, die zum Senden und Empfangen einer Datei (z. B. Datendatei 120) erforderlich sind. In der vorliegenden Ausführungsform enthält dieser Satz von Objekten die Lese-, Komprimierungs-, Verschlüsselungs-, Dekomprimierungs-, Entschlüsselungs- und Schreibobjekte, die in Verbindung mit den 3A–3B und 3A–4B beschrieben werden.
An der Clientseite empfängt das Listenerobjekt 139b die eingehende Verbindung vom Server 110 und leitet diese Verbindung weiter an den Verbindungsmanager 138b. Der Verbindungsmanager 138b bringt eine Sitzung 140b hervor. Die Sitzung 140b liest den Befehl von der Verbindung. Dieser Befehl enthält alle Informationen, die erforderlich sind, um die Verbindung mit dem Server 110 herzustellen, die Datendatei 120 zu lesen und die Datendatei 120 zum Client 102 übertragen zu lassen. Die Sitzung 140b analysiert den Befehl und führt das Folgende aus: Herstellen einer Verbindung mit dem Server 110, Senden des Befehls zum Starten der Übertragung der Datendatei 120 und Initialisieren und Ausführen des Kanals.
3A zeigt den Datenfluss durch eine Ausführungsform eines Ausgabekanalobjekts 139a nach der vorliegenden Erfindung. In dieser Ausführungsform umfasst der Ausgabekanal 139a vier Datenumwandlungs-Threads oder -Objekte: Lesekanalobjekt 142a, Komprimierungskanalobjekt 146, Verschlüsselungskanalobjekt 156 und Schreibkanalobjekt 152a. Die Datenumwandler (Lesekanalobjekt 142a, Komprimierungskanalobjekt 146, Verschlüsselungskanalobjekt 156 und Schreibkanalobjekt 152a) können parallel arbeiten (z. B. können sie jeweils ihre eigenen Threads haben). Der Ausgabekanal 139a umfasst außerdem das Blockmanagerobjekt 154a.
Das Blockmanagerobjekt 154a enthält mehrere Datenblöcke (z. B. Vektoren von Datenblöcken). Ein Datenblock ist ausgeführt, um Byteanordnungen zwischen Umwandlungen zu speichern. In der vorliegenden Ausführungsform ist jeder Datenblock mit einem Datenumwandlungsobjekt assoziiert, und nur dieses Objekt kann in den Datenblock schreiben; ein Datenumwandlungsobjekt kann jedoch mit mehreren Datenblöcken assoziiert sein. Eine Größe eines Datenblocks kann variieren, so dass, wenn ein Datenumwandlungsobjekt feststellt, dass es Ausgabedaten nicht in dem Datenblockpuffer unterbringen kann, das Datenumwandlungsobjekt einen neuen (größeren) Puffer erzeugen kann, der den alten (kleineren) Puffer ersetzt. Außerdem kann beispielsweise ein Datenblock, der komprimierte Daten enthält, kleiner sein als einer, der unkomprimierte Daten enthält.
Das Blockmanagerobjekt 154a steuert die Gesamtzählung von Datenblöcken für jedes Datenumwandlungsobjekt; das heißt, das Blockmanagerobjekt 154a verfügt über einen Parameter, der die Zahl der Datenblöcke pro Datenumwandlungsobjekt begrenzt. Im Allgemeinen werden etwa vier Datenblöcke pro Datenumwandlungsobjekt spezifiziert. Wenn ein Datenumwandlungsobjekt einen Datenblock anfordert, aber die Zahl der verfügbaren Datenblöcke gleich dem für das Umwandlungsobjekt zulässige Maximum ist (das heißt, dass keine freien Datenblöcke vorhanden sind), warten das Blockmanagerobjekt 154a und das Datenumwandlungsobjekt, bis ein Datenblock freigegeben wird.
Weiterhin Bezug nehmend auf 3A, liest in der vorliegenden Ausführungsform das Lesekanalobjekt 142a einen Teil der Datendatei 120 und schreibt diesen Teil in einen ersten Datenblockpuffer im Hauptspeicher des Server-Computersystems 110. Die Datendatei 120 ist normalerweise eine große Datei. Indem nur ein Teil der Datei gelesen wird, können nachgeordnete Umwandlungen hinsichtlich Komprimierung und Verschlüsselung parallel ablaufen, während anschließende Teile der Datendatei 120 gelesen und in den ersten Datenblockpuffer geschrieben werden.
Das Komprimierungskanalobjekt 146 liest die Daten in dem ersten Datenblockpuffer, wandelt sie um (komprimiert sie) und schreibt die komprimierten Daten in einen zweiten Datenblockpuffer. Das Komprimierungskanalobjekt 146 codiert die in der Datendatei 120 enthaltenen Daten in einer Weise, die sie kompakter machen.
Das Verschlüsselungskanalobjekt 156 liest die komprimierten Daten aus dem zweiten Datenblockpuffer, verschlüsselt sie und schreibt sie in einen dritten Datenblockpuffer.
Das Schreibkanalobjekt 152a liest den verschlüsselten Datenblock und schreibt ihn in den Netzwerk-Socket-Strom (in den Eingabekanal 139b; 3B).
In der vorliegenden Ausführungsform funktioniert der Ausgabekanal 139a wie folgt: Der Ausgabekanal 139a empfängt die Datendatei 120. Die Datendatei 120 kann vom Ausgabekanal 139a in ihrer Gesamtheit empfangen und dann in kleinere Datenblöcke aufgeteilt werden, oder jeweils ein Abschnitt der Datendatei 120 kann aus der Massenspeichervorrichtung 112 (1A) gelesen werden.
Das Lesekanalobjekt 142a fordert einen freien Datenblock an. Das Blockmanagerobjekt 154a sucht nach einem freien Datenblock, und wenn kein derartiger Block vorhanden ist, erzeugt das Blockmanagerobjekt 154a einen neuen Block, kennzeichnet ihn als freigegeben und weist ihn dem Lesekanalobjekt 142a zu. Das Lesekanalobjekt 142a schreibt Daten aus der Datendatei 120 in den Datenblock und kennzeichnet die Daten als bereit zur Verschlüsselung. Das Komprimierungskanalobjekt 146 empfängt diesen Datenblock vom Blockmanagerobjekt 154a und fordert einen freien Datenblock an (für seine Ausgabe). Das Blockmanagerobjekt 154a erzeugt einen neuen Datenblock, kennzeichnet ihn als freigegeben und weist ihn dem Komprimierungskanalobjekt 146 zu.
Parallel dazu fordert das Lesekanalobjekt 142a einen anderen Datenblock an, und der Blockmanager 154a erzeugt, wie oben beschrieben, einen neuen Block, kennzeichnet ihn als freigegeben und weist den neuen Datenblock dem Lesekanalobjekt 142a zu. Das Lesekanalobjekt 142a kann dann einen anderen Abschnitt der Datendatei 120 in diesen Block schreiben und ihn als bereit zur Komprimierung kennzeichnen.
In der Zwischenzeit komprimiert (codiert) das Komprimierungskanalobjekt 146 die in seinem jeweiligen Datenblock enthaltenen Daten, kennzeichnet sie als bereit zur Verschlüsselung und gibt seinen jeweiligen Datenblock frei. Das Verschlüsselungskanalobjekt 156 empfängt diesen (komprimierten) Datenblock vom Blockmanagerobjekt 154a und fordert einen freien Block für seine Ausgabe an. Das Blockmanagerobjekt 154a erzeugt einen neuen Datenblock, kennzeichnet ihn als freigegeben und weist ihn dem Verschlüsselungskanalobjekt 156 zu.
Das Verschlüsselungskanalobjekt 156 verschlüsselt die in seinem jeweiligen Datenblock enthaltenen Daten, kennzeichnet sie als bereit zum Schreiben und gibt seinen jeweiligen Datenblock frei. Das Schreibkanalobjekt 152a empfängt den codierten (komprimierten) und verschlüsselten Datenblock vom Blockmanagerobjekt 154a und schreibt in den Netzwerk-Socket-Ausgabestrom 307.
Der oben beschriebene Prozess wird wiederholt, bis das Lesekanalobjekt 142a den letzten Datenblock in der Datendatei 120 liest. Jeder Datenblock wird durch den Ausgabekanal 139a geleitet, wobei Datenblöcke erzeugt und freigegeben werden, wie es von den jeweiligen Umwandlungsobjekten erfordert wird. In dieser Weise kann die Zahl der Datenblöcke reduziert werden, so dass Speichenessourcen nicht unnötigerweise verbraucht werden.
In dieser Ausführungsform der vorliegenden Erfindung werden Mittel, die Durchschnittsfachleuten im Fachgebiet gut bekannt sind, eingesetzt, um zu gewährleisten, dass die Datendatei 120 vollständig und richtig an den Client 102 übertragen wurde.
Damit werden die Ziele der vorliegenden Erfindung erreicht. Eine Datendatei 120 wird auf Anforderung vom Server-Computersystem 110 an mindestens ein Computersystem, das sich entfernt vom Server-Computersystem 110 befindet (z. B. Client 102), gesandt. Die Datenübertragung wird sicher, schnell und zuverlässig durchgeführt.
3B zeigt den Datenfluss durch eine Ausführungsform eines Eingabekanals 139b der vorliegenden Erfindung. Wie in den 2B und 3B gezeigt, können in einem anderen Aspekt der vorliegenden Erfindung die Operationen des Server-Computersystems 110 im Client-Computersystem 102 gespiegelt werden. Ein Netzwerkstrom von komprimierten/verschlüsselten Datenblöcken 307 wird vom Server-Computersystem 110 durch das Client-Computersystem 102 empfangen und wird entschlüsselt, dekomprimiert und schließlich in die Datendatei 120 zusammengesetzt. Alternativ können die Datenblöcke vom Server 110 als Ganzes durch den Client 102 empfangen werden.
An der Clientseite liest das Lesekanalobjekt 142b formatierte (verschlüsselte und komprimierte) Daten vom Netzwerk-Eingabestrom 307. Ein Entschlüsselungskanalobjekt 164 liest Daten aus einem Datenblock in Blockmanagerobjekt 154b, entschlüsselt die Daten und schreibt die Daten in einen Datenblock in Blockmanagerobjekt 154b.
Ein Dekomprimierungskanalobjekt 158 liest Daten aus einem Datenblock in Blockmanagerobjekt 154b, dekomprimiert (decodiert) die Daten und schreibt die Daten in einen Datenblock in Blockmanagerobjekt 154b. Das Schreibkanalobjekt 152 schreibt die Daten in den Ausgabestrom für Datendatei 120 in beispielsweise die Massenspeichervorrichtung 170 (2A).
Die Datenumwandler (Lesekanalobjekt 142b, Entschlüsselungskanalobjekt 164, Dekomprimierungskanalobjekt 168 und Schreibkanalobjekt 152) funktionieren ähnlich wie die, die oben in Verbindung mit 3A beschrieben wurden. Mittel, die Fachleuten gut bekannt sind, können eingesetzt werden, um zu gewährleisten, dass die Datendatei 120 vollständig und richtig übertragen wurde.
Damit werden die Ziele der vorliegenden Erfindung auch in der clientseitigen Ausführungsform der vorliegenden Erfindung erreicht. Eine Datendatei 120 wird auf Anforderung des Client-Computersystems 102 vom Server-Computersystem 110 an das Client-Computersystem 102 gesandt. Die Datenübertragung wird sicher, schnell und zuverlässig durchgeführt.
Die vorstehende Diskussion veranschaulicht ein „Ziehen" von Daten vom Server-Computersystem 110 durch das Client-Serversystem 102. Wie erkennbar ist, könnte die Datenübertragung in einem anderen Aspekt der vorliegenden Erfindung durch „Schieben" von Daten vom Server-Computersystem 110 erfolgen, wobei das Server-Computersystem 110 ein „horchendes" Client-Computersystem 102 anweisen würde, Daten zu empfangen. Geeignete Socket-Verbindungen, Threads und Objekte würden nach der vorliegenden Erfindung erzeugt werden und Daten würden über das Computernetz vom Server-Computersystem 110 zum Client-Computersystem 102 übertragen werden.
Die 4A und 4B zeigen alternative Ausführungsformen des Ausgabekanals 139a und des Eingabekanals 139b der 3A und 3B (die alternativen Ausführungsformen sind als Ausgabekanal 122 und Eingabekanal 124 bezeichnet). Die Operation und Funktion der nummerierten Elemente in den 4A und 4B ist die gleiche wie die von gleich nummerierten Elementen in den 3A bzw. 3B.
In der Ausführungsform von 4A wird ein Streaming-Mechanismus zum Komprimieren der Datendatei 120, Verschlüsseln der Datendatei 120 und dann Senden der Datendatei 120 über das Netzwerk zum Client 102 oder einer anderen entfernten Vorrichtung verwendet. Anstatt dass die Datei in Blöcke aufgeteilt wird, wie oben in Verbindung mit 3A beschrieben, und jeder Block als eine kleine Datei behandelt wird, kann die Datei dadurch stattdessen als eine zusammenhängende Datei behandelt werden.
Das Komprimierungskanalobjekt 164 und das Verschlüsselungskanalobjekt 156 können eine Ausgabe erzeugen, die sich in der Größe von ihrer Eingabe unterscheidet. Die Stufenausgabeströme 186 und 188 schreiben Daten in einen Ausgabedatenblockpuffer, bis dieser Block voll ist oder bis keine Daten zum Schreiben mehr vorhanden sind. Wenn der aktuelle Ausgabedatenblock voll ist, geben die Ausgabeströme 186 und 188 an, dass der aktuelle Block bereit zum Lesen durch das nächste Umwandlungsobjekt ist, und fragen das Blockmanagerobjekt 154a nach dem nächsten verfügbaren Datenblock. Durch Akkumulation von Streaming-Teilen der Datendatei 120 vom Komprimierungskanalobjekt 146 und Verschlüsselungskanalobjekt 156 kann ein besseres Management von Datenblockpuffern durch das Blockmanagerobjekt 154 realisiert werden.
Beispielsweise kann das Komprimierungskanalobjekt 146 zu einem Komprimierungsverhältnis von 10:1 fähig sein. Anstatt eine Ausgabedatenblockpuffer-Größe gleich einem Zehntel der Größe des Eingabepuffers zu spezifizieren, kann eine bessere Nutzung der Datenblockpuffer erreicht werden, indem zehn Teil von komprimierten Datenblöcken in dem Stufenausgabestrom 186 akkumuliert werden, bevor in den Ausgabedatenblockpuffer geschrieben wird, so dass der Ausgabepuffer die gleiche Größe wie die Eingabepuffergröße aufweist.
In 4B akkumulieren, ähnlich der obigen Diskussion, der Stufenausgabestrom 190 und der Stufenausgabestrom 192 Daten für das Entschlüsselungskanalobjekt 164 bzw. das Dekomprimierungskanalobjekt 158. Zusätzlich wird der Stufeneingabestrom 194 im Eingabekanal 124 vorgesehen, um den gesamten Strom von komprimierten Datenblöcken zu empfangen, bis das Ende der Datendatei 120 erreicht ist, weil das Dekomprimierungskanalobjekt 168 unter Umständen eine vollständige komprimierte Datendatei 120 zur Operation benötigt.
5 zeigt den Datenfluss durch eine Ausführungsform eines Sitzungs-Threads 140a in einem Server-Computersystem 110 (2B) nach der vorliegenden Erfindung. Es ist erkennbar, dass ein ähnlicher Datenfluss durch einen Sitzungs-Thread 140b in einem Client-Computersystem 102 (2B) stattfindet. Die Sitzungs-Threads 140a und 140b werden unter der Führung der Sitzungsmanagerobjekte 138a bzw. 138b ausgeführt (siehe 2B).
Bezug nehmend auf 5, wird ein Sitzungs-Thread 140a für jede eingehende Anforderung 134 erzeugt. Anforderungen können Befehle wie Statusbefehle, Befehle zum Senden einer oder mehrerer Dateien (z. B. Datendatei 120) an eine oder mehrere entfernte Vorrichtungen (z. B. Client 102 und Befehle zum Empfangen einer oder mehrerer Dateien von einer entfernten Vorrichtung enthalten. In einer Ausfülhrungsform verwenden die Befehle in Anforderung 134 die Extensible Markup Language (XML).
In dieser Ausführungsform überprüft das Protokoll 174 die eingehende Anforderung 134 und leitet sie zum XML-Befehlsübersetzer 173. Das Protokoll 174 wird verwendet, um Befehle in verschlüsselter Form zu senden und zu empfangen, und wird für Benutzerauthentifizierung verwendet. Das Protokoll 174 wird von der Channel Factory 182 verwendet, um einen Kommunikations-Socket für einen Kanal zu öffnen (z. B. Eingabekanäle 139b oder 124 oder Ausgabekanäle 139a oder 122 der 3B, 4B, 3A bzw. 4A).
Fortfahrend unter Bezugnahme auf 5, analysiert das XML-Befehlsübersetzerobjekt 173 die eingehende Anforderung 134, erzeugt optimierte Tasks niedriger Stufe und setzt die Tasks mit assoziierten Parametern in die Task-Tabelle 176 ein. Jeder Parameter wird unter Verwendung der Task „Deklarieren" (nachstehend erwähnt) an alle Tasks übergeben, die ihn benötigen, so dass, wenn ein Parameter deklariert wird, er an mehreren Stellen und in mehreren Tasks gemeinsam genutzt wird, wenn er benötigt wird.
Die eingehende Anforderung 134 wird in eingehende Tasks niedriger Stufe übersetzt, weil die Zahl dieser Tasks begrenzt werden kann, während die Zahl von XML-Befehlen in der eingehenden Anforderung 134 groß sein könnte. Die XML-Befehle können jedoch in interne Tasks niedriger Stufe übersetzt werden, um die Implementierung zu erleichtern und um die Implementierung umfangreicher zu machen. Außerdem erleichtert die Verwendung von internen Tasks niedriger Stufe anstelle von XML-Befehlen die parallele Verarbeitung und vermeidet das Erfordernis nach redundanten Verarbeitungsschritten.
Die internen Tasks niedriger Stufe umfassen folgende, sind aber nicht darauf beschränkt:
Verbinden: zum Herstellen einer Verbindung zwischen zwei Vorrichtungen (z. B. Server 110 und Client 102), zum Erstellen und Initialisieren des Protokolls 174 und zum Weiterleiten eines Initialisierungsbefehls an das Sitzungsmanagerobjekt 138a;
Kanal erzeugen: zum Erzeugen und Initialisieren eines Kanals;
Kanal ausführen: zum Durchführen der Dateiübertragung;
Extern ausführen: zum Ausführen eines externen Befehls an der lokalen Vorrichtung;
Sitzungsstatus holen: zum Erhalten eines Statusberichts zu einer oder mehr Sitzungen;
Sitzung anhalten: zum Anhalten einer Sitzung;
Deklarieren: zum Einfügen einer Reihe in einen separaten Variablenvektor, der von Taskabwickler 178 verwaltet wird (der Variablenvektor stellt einen Mechanismus bereit, um Objekte in mehreren Tasks gemeinsam zu nutzen);
Warten: zum Warten, bis ein Kanal die Übertragung einer Datei oder von Dateien abgeschlossen hat;
Beenden: zum Beenden einer Sitzung;
Konto einrichten: zum Einrichten eines neuen Kontos;
Konto bearbeiten: zum Bearbeiten eines bestehenden Kontos; und
Konto entfernen: zum Entfernen eines bestehenden Kontos.
Der XML-Befehlsübersetzer 173 setzt diese Tasks zur Ausführung durch den Taskabwickler 178 in die Task-Tabelle 176 ein. Die Task-Tabelle 176 ist ein Speicherobjekt und umfasst eine Hash-Tabelle der Tasks.
Der Taskabwickler 178 führt die Tasks aus der Task-Tabelle 176 in einer gegebenen Reihenfolge aus. Der Taskabwickler 178 verwendet eine API des Sitzungsmanagerobjekts 138a (2B) zum Ausführen der Tasks. Der Taskabwickler 178 vollführt die Ausführung in einer Schleife durch die Task-Tabelle 176, bis der Befehl Beenden gefunden wird. Nachdem der XML-Befehlsübersetzer 173 eine Task-Tabelle 176 für einen Befehl 141 erzeugt, übernimmt der Taskabwickler 178 die Steuerung des Sitzungs-Threads und beginnt mit der Ausführung der Tasks in dem Sitzungs-Thread. Der Taskabwickler 178 aktualisiert außerdem die Sitzungsstatistik für die Wiederherstellungsoption, die nachstehend in Verbindung mit den 6A, 6B und 6C beschrieben wird.
Bezug nehmend auf 5, wird ein Kanalobjekt (z. B. Kanalobjekt 139a und auch Kanalobjekt 122 von 4A) durch eine Channel Factory 182 erzeugt und initialisiert. In der vorliegenden Ausführungsform initialisiert die Channel Factory 182 das Kanalobjekt 139a mit Eingabe- und/oder Ausgabeströmen.
Fortfahrend unter Bezugname auf 5, repräsentiert Kanalobjekt 139a den Satz von Datenumwandlungsobjekten, die zum Senden und Empfangen einer Datei (z. B. Datendatei 120) benötigt werden. In der vorliegenden Ausführungsform enthält der Satz von Datenumwandlungsobjekten die Lese-, Komprimierungs-, Verschlüsselungs-, Dekomprimierungs-, Entschlüsselungs- und Schreibobjekte, die in Verbindung mit den 3A–3B und 4A–4B beschrieben wurden. Das Protokoll 174 leitet ausgeführte Tasks zu einer entfernten Sitzung 184.
Die 6A, 6B und 6C veranschaulichen einen anderen Aspekt der vorliegenden Erfindung hinsichtlich der Wiederherstellung der Datenübertragung nach einem temporären Verlust und/oder Ausfall einer Netzverbindung. Da nach der vorliegenden Erfindung große Datenmengen übertragen werden, ist Wiederherstellung eine wichtige Überlegung. In der vorliegenden Ausführungsform werden zwei Wiederherstellungsmodi in Betracht gezogen: automatische Wiederherstellung der Netzverbindung und manuelle Sitzungswiederherstellung.
Automatische Wiederherstellung der Netzverbindung bedeutet, dass sowohl der Eingabekanal 139b als auch der Ausgabekanal 139a (2B) ausgeführt werden, aber die Netzverbindung verloren wurde oder ausgefallen ist. In diesem Fall kann die Netzverbindung automatisch wiederhergestellt werden.
Wenn eine Netzverbindung ausfällt, werden beide Kanäle über eine „Ausnahme" benachrichtigt. Wenn ein Kanal eine Ausnahme empfängt, ruft er die API für seinen jeweiligen Sitzungsmanager (z. B. Sitzungsmanagerobjekt 138a oder 138b von 2B) auf, um die Verbindung wiederherzustellen. Die API gibt einen neuen Sitzungs-Thread für die Verbindung zurück, wenn die Verbindung wiederhergestellt werden kann, oder eine NULL, wenn die Verbindung nicht wiederhergestellt werden kann.
Bezug nehmend auf die 6A, 6B und 6C, sind zwei Sitzungs-Threads an dem Wiederherstellungsprozess beteiligt. In 6A erzeugt Sitzungsmanagerobjekt 138a (2B) die Sitzung 1 (z. B. Sitzungs-Thread 140a) im Server-Computersystem 110 und initiiert die Verbindung mit dem Client-Computersystem 102. Das Sitzungsmanagerobjekt 138b (2B) empfängt die Anforderung zum Starten einer Sitzung und erzeugt Sitzung 1 (z. B. Sitzungs-Thread 140b) im Client-Computersystem 102.
In 2B ist die Verbindung verloren gegangen. In 6C sendet das Sitzungsmanagerobjekt 138a, nachdem die Verbindung verloren gegangen ist und der initiierende Sitzungsmanager (Sitzungsmanagerobjekt 138a in Server 110) aufgerufen wird, um die Sitzung wiederherzustellen, eine Anforderung an den Client 102 (Sitzungsmanagerobjekt 138b), um die Netzverbindung für Sitzung 1 wiederherzustellen. Wenn der Client 102 (speziell Sitzungsmanagerobjekt 138b) die Anforderung vom Server 110 empfängt, bringt er einen zweiten Sitzungs-Thread (Sitzung 2, z. B. Sitzungs-Thread 140c) hervor. Die Sitzung 2 übergibt die Verbindung an die wartende Sitzung 1 im Client 102. Sobald die Verbindung wiederhergestellt ist, fahren beide Kanäle (Ausgabekanal 139a und Eingabekanal 139b) fort, Daten ab dem Punkt, an dem sie angehalten haben, zu übertragen.
Informationen über eine Sitzung werden in den Sitzungsmanagerobjekten 138a im Server 110 gespeichert. Der Sitzungsmanager 138a speichert alle Sitzungsparameter und die Zählung der Bytes von Daten, die vor dem Ausfall in Sitzung 1 geschrieben wurden. Folglich kann der Lesevorgang das Lesen von dem richtigen Byteversatz starten, und der Schreibvorgang kann fortfahren, indem er die Datenblöcke anfügt, die erzeugt, aber nicht übertragen wurden.
Im Wiederherstellungsmodus enthält die Task-Tabelle 176 (5) dieselben Tasks, aber bei der Ausführung werden einige der Tasks abhängig von den Ergebnissen der vorherigen Taskausführung und den Einstellungen unter Umständen übersprungen.
Manuelle Sitzungswiederherstellung wird eingesetzt, wenn einer der Kanäle ausfällt. Die Wiederherstellung erfolgt normalerweise nicht automatisch, weil es wünschenswert ist, zuerst die Ursache des Ausfalls zu ermitteln und zu beheben.
7A zeigt ein Ablaufdiagramm der serverseitigen Schritte in einem Prozess 700 zum Übertragen von Daten über ein Netzwerk 100 (1A) nach einer Ausführungsform der vorliegenden Erfindung. In dieser Ausführungsform wird der Prozess 700 durch ein Server-Computersystem 110 (1A ), veranschaulicht durch Computersystem 1090 (1B), als computerlesbare Befehle, die in einem Speichergerät (z. B. ROM 1003, RAM 1002 oder Datenspeichervorrichtung 1004 von 1B) gespeichert sind, implementiert und durch einen Prozessor (z. B. Prozessor 1001 von 1B) ausgeführt. Es ist jedoch ersichtlich, dass einige Aspekte von Prozess 700 im Server-Computersystem 110 implementiert sein können und andere Aspekte des Prozesses 700 im Client-Computersystem 102 (1A) ausgeführt werden.
In Schritt 702 von 7A empfängt der Server 110 eine Anforderung 134 (2B) für eine Datendatei, die in einem Massenspeichergerät im Server gespeichert ist (z. B. Datendatei 120, die in der Massenspeichervorrichtung 112 von 1A gespeichert ist). In einer Ausführungsform horcht ein Listenerobjekt 130a (2B) nach einer derartigen Anforderung. In der vorliegenden Ausführungsform enthält die Anforderung 134 Befehle; siehe 5. In einer Ausführungsform verwendet die Anforderung 134 XML.
In Schritt 704 von 7B wird die Anforderung authentifiziert, um zu gewährleisten, dass die Anforderung von einem autorisierten Benutzer stammt. In einer Ausführungsform überprüft das Protokoll 174 (5) die eingehende Anforderung 134.
In Schritt 706 von 7B wird ein Sitzungs-Thread (z. B. Sitzungs-Thread 140a) als Reaktion auf die Benutzeranforderung 134 (2B) hervorgebracht. In einer Ausführungsform ruft das Listenerobjekt 130a (2B) das Sitzungsmanagerobjekt 138a (2B) auf, und das Sitzungsmanagerobjekt 138a erzeugt den Sitzungs-Thread 140a und weist ihm eine eindeutige ID zu. Der Sitzungs-Thread 140a liest den Befehl (die Befehle), der (die) in der Benutzeranforderung 134 enthalten ist (sind), und übersetzt die Anforderung 134 in einen Satz von eingehenden Tasks niedriger Stufe, die für den Sitzungs-Thread 140a auszuführen sind (siehe 5). Der Sitzungsmanager 138a sendet außerdem eine Nachricht an den Client 102, um ihn anzuweisen, einen Sitzungs-Thread (z. B. Sitzungs-Thread 140b) hervorzubringen. Ein Kanalobjekt 139a wird auch erzeugt und stellt den Satz von Datenumwandlungsobjekten bereit, die zum Senden und Empfangen der Datendatei 120 benötigt werden; siehe die 3A und 4A.
In Schritt 708 von 7A werden die Daten in der Datendatei 120 aus der Server-Massenspeichervorrichtung 112 (1A) gelesen und komprimiert, wie in Verbindung mit 3A oder 4A beschrieben.
In Schritt 710 von 7B werden die komprimierten Daten verschlüsselt, wie in Verbindung mit 3A oder 4A beschrieben.
In Schritt 712 von 7A werden die Daten an die anfordernde Vorrichtung gesandt (z. B. an Client 102 über den Netzwerkbus 107 in Netzwerk 100 von 1B) und vollständige und richtige Datenübertragung werden überprüft.
Die Schritte 708, 710 und 712 werden parallel für verschiedene Teile der Datendatei 120 ausgeführt.
7B zeigt ein Ablaufdiagramm der clientseitigen Schritte in einem Prozess 750 zum Übertragen von analytischen Daten über ein Netzwerk nach einer Ausführungsform der vorliegenden Erfindung. In dieser Ausführungsform wird der Prozess 750 durch das Client-Computersystem 102 (1A), veranschaulicht durch Computersystem 1090 (1B), als computerlesbare Befehle, die in einem Speichergerät (z. B. ROM 1003, RAM 1002 oder Datenspeichervorrichtung 1004 von 1B) gespeichert sind, implementiert und durch einen Prozessor (z. B. Prozessor 1001 von 1B) ausgeführt. Es ist jedoch ersichtlich, dass einige Aspekte von Prozess 750 im Client-Computersystem 102 implementiert sein können und andere Aspekte des Prozesses 750 im Server-Computersystem 110 ausgeführt werden.
In Schritt 752 von 7B gibt eine anfordernde Vorrichtung (z. B. Client 102 von 1A) eine Anforderung 134 (2B) für eine Datendatei 120 (1A) an einen Server (z. B. Server 110 von 1A) aus.
In Schritt 754 von 7B empfängt der Client 102 eine Nachricht vom Server 110 (speziell vom Sitzungsmanagerobjekt 138a von 2B), die den Client 102 anweist, einen Sitzungs-Thread (z. B. Sitzungs-Thread 140b von 2B) hervorzubringen.
In Schritt 756 von 7B empfängt der Client 102 verschlüsselte und komprimierte Datenblöcke, die die Datendatei 120 repräsentieren, vom Server 110, siehe 3B oder 4B.
In Schritt 758 von 7B werden die Daten entschlüsselt, wie von 3B oder 4B beschrieben.
In Schnitt 760 von 7B werden die Daten dekomprimiert, wie von 3B oder 4B beschrieben.
Die Schritte 756, 758 und 760 werden parallel für verschiedene Teile der Datendatei 120 ausgeführt.
Zusammengefasst stellt die vorliegende Erfindung ein zuverlässiges, sicheres, authentifiziertes, überprüfbares und schnelles System und Verfahren für die Übertragung von großen Datenmengen, wie die in einer analytischen Anwendung verwendeten Daten (z. B. Betriebsdaten und umgewandelte Daten in einem Daten-Warehouse/Daten-Mart), über ein Netzwerk bereit.
Die vorstehenden Beschreibungen von spezifischen Ausführungsformen der vorliegenden Erfindung wurden für Zwecke der Veranschaulichung und Beschreibung präsentiert. Sie sollen nicht umfassend sein oder die Erfindung auf die genauen offenbarten Formen beschränken, und offensichtlich sind angesichts der obigen Lehre viele Abwandlungen und Variationen möglich. Die Ausführungsformen wurden ausgewählt und beschrieben, um die Grundsätze der Erfindung und ihre praktische Anwendung am besten zu erläutern, um dadurch andere Fachleute in die Lage zu versetzen, die Erfindung und verschiedene Ausführungsformen mit verschiedenen Abwandlungen, wie für die vorgesehene besondere Verwendung geeignet, am besten zu nutzen. Es ist beabsichtigt, dass der Rahmen der Erfindung durch die hieran beigefügten Patentansprüche und ihre Äquivalente definiert wird.

Claims

Verfahren zur Datenübertragung in einer multithreadingfähigen analytischen Data-Warehousing-Anwendung, die von einem Ausgangscomputersystem ausgeführt wird und zur gleichzeitigen Ausführung von mehreren Sitzungs-Threads imstande ist, das Verfahren umfassend: Empfangen (702) einer Pluralität von eingehenden Anforderungen nach analytischen Daten, die in einer Massenspeichereinheit des Ausgangscomputersystems resident sind; Authentifizieren (704) der eingehenden Anforderungen; Hervorbringen (706) einer Pluralität von Sitzungs-Threads, wobei jeder Thread konfiguriert ist zum Lesen und Analysieren eines Befehls, der über die eingehenden Anforderungen empfangen wurde, wobei der Befehl zum Senden der Daten an ein zweites Computersystem vorgesehen ist; und gleichzeitiges (708, 710, 712) Ausführen einer Pluralität von Datentransformations-Threads innerhalb jedes Sitzungs-Threads, wobei jeder Sitzungs-Thread mit einem ersten, einem zweiten und einem dritten Datenblockpuffer assoziiert ist, jeder der Sitzungs-Threads umfassend einen Leser-Thread, der Daten liest und zumindest einen Teil der Daten in den ersten Datenblockpuffer schreibt; einen Komprimierungs-Thread, der den Teil der Daten in dem ersten Datenblockpuffer zu einem komprimierten Datenblock komprimiert und den komprimierten Datenblock in den zweiten Datenblockpuffer schreibt; und einen Verschlüsseler-Thread, der den komprimierten Datenblock in dem zweiten Datenblockpuffer zu einem verschlüsselten und komprimierten Datenblock verschlüsselt und den verschlüsselten und komprimierten Datenblock in den dritten Datenblockpuffer schreibt; und einen Schreiber-Thread, der den verschlüsselten und komprimierten Datenblock in dem dritten Datenblockpuffer liest und den verschlüsselten und komprimierten Datenblock an das zweite Computersystem sendet.
Verfahren nach Anspruch 1, weiter umfassend: Überprüfen, dass die Datenübertragung an das zweite Computersystem vollständig ist; und Überprüfen, dass die Datenübertragung an das zweite Computersystem ohne Fehler ist.
Verfahren nach Anspruch 1, wobei das Ausgangscomputersystem und das zweite Computersystem über das Internet vernetzt sind.
Verfahren nach Anspruch 1, wobei die Daten Daten umfassen, die von einer analytischen Anwendung verarbeitet wurden.
Verfahren nach Anspruch 1, wobei die eingehenden Anforderungen Extensible Markup Language (XML) verwenden.
Verfahren nach Anspruch 1, wobei Hervorbringen (706) jedes Sitzungs-Threads weiter umfasst: Übersetzen des Befehls in eine Pluralität von Aufgaben; Speichern der Aufgaben in einer Aufgabentabelle in einer gegebenen Reihenfolge; und Ausführen der Aufgaben der Reihe nach, bis eine Aufgabe, die den Sitzungs-Thread beendet, gefunden wird.
Verfahren nach Anspruch 1, wobei der erste Datenblockpuffer und der zweite Datenblockpuffer in der Größe im Wesentlichen gleich sind und wobei ausreichend komprimierte Datenblöcke akkumuliert werden, um den zweiten Datenblockpuffer zu füllen, bevor der Komprimierer-Thread in den zweiten Datenblockpuffer schreibt.
Verfahren nach Anspruch 1, wobei der zweite Datenblockpuffer und der dritte Datenblockpuffer in der Größe im Wesentlichen gleich sind und wobei ausreichend verschlüsselte und komprimierte Datenblöcke akkumuliert werden, um den dritten Datenblockpuffer zu füllen, bevor der Verschlüsseler-Thread in den dritten Datenblockpuffer schreibt.
Verfahren nach Anspruch 1, weiter umfassend: Wiederherstellen einer Verbindung mit dem zweiten Computersystem, wenn eine bestehende Verbindung ausfällt; und Wiederaufnehmen der Datenübertragung zu dem zweiten Computersystem an dem Punkt in den Daten, an dem die bestehende Verbindung ausgefallen war.
Verfahren zum Empfangen von Daten, die von einem Ausgangscomputersystem in einer ersten multithreadingfähigen analytischen Data-Warehousing-Anwendung, die von einem Zielcomputersystem ausgeführt wird und zur gleichzeitigen Ausführung von mehreren Sitzungs-Threads imstande ist, übertragen sind, das Verfahren umfassend: Ausgeben (752) einer Pluralität von Anforderungen nach Daten an das Ausgangscomputersystem, in dem die Daten residieren, wobei das Ausgangscomputersystem eine zweite multithreadingfähige analytische Anwendung ausführt; Hervorbringen (754) einer Pluralität von Sitzungs-Threads als Reaktion auf Nachrichten von dem Ausgangscomputersystem; Empfangen (756) mindestens eines verschlüsselten und komprimierten Datenblocks der Daten von dem Ausgangscomputersystem; gleichzeitiges (756, 758, 760) Ausführen einer Pluralität von Datentransformations-Threads innerhalb jedes Sitzungs-Threads, wobei jeder Sitzungs-Thread mit einem ersten, einem zweiten und einem dritten Datenblockpuffer assoziiert ist, jeder der Sitzungs-Threads umfassend einen Lese-Thread zum Schreiben des verschlüsselten und komprimierten Datenblocks in den ersten Datenblockpuffer; einen Entschlüsseler-Thread zum Entschlüsseln des verschlüsselten und komprimierten Datenblocks in dem ersten Datenblockpuffer in einen komprimierten Datenblock und Schreiben des komprimierten Datenblocks in einen zweiten Datenblockpuffer; und einen Entkomprimierungs-Thread zum Entkomprimieren des komprimierten Datenblocks in dem zweiten Datenblockpuffer und Schreiben eines resultierenden Datenblocks in einen dritten Datenblockpuffer.
Verfahren nach Anspruch 10, weiter umfassend: Überprüfen, dass die Datenübertragung von dem Ausgangscomputersystem vollständig war.
Verfahren nach Anspruch 10, weiter umfassend: Überprüfen, dass die Datenübertragung von dem Ausgangscomputersystem ohne Fehler war.
Verfahren nach Anspruch 10, wobei das Zielcomputersystem und das Ausgangscomputersystem über das Internet vernetzt sind.
Verfahren nach Anspruch 10, wobei die Daten Daten umfassen, die von einer analytischen Anwendung verarbeitet wurden.
Verfahren nach Anspruch 10, wobei eine Pluralität von verschlüsselten und komprimierten Datenblöcken akkumulieren, bevor der Entschlüsseler-Thread ausgeführt wird.
Verfahren nach Anspruch 10, wobei eine Pluralität von komprimierten Datenblöcken akkumulieren, bevor der Entkomprimierer-Thread ausgeführt wird.
Verfahren nach Anspruch 10, weiter umfassend: Wiederherstellen einer Verbindung mit dem Ausgangscomputersystem, wenn eine bestehende Verbindung ausfällt; und Wiederaufnehmen der Datenübertragung von dem Ausgangscomputersystem an dem Punkt in den Daten, an dem die bestehende Verbindung ausgefallen war.
Ausgangscomputersystem, umfassend: einen Bus (1000); eine Speichereinheit (1002, 1003, 1004), die an den Bus (1000) gekoppelt ist; eine multithreadingfähige analytische Data-Warehousing-Anwendung, die in der Speichereinheit gespeichert ist, und umfassend: ein Hörer-Objekt (130a) zum Empfangen einer Pluralität von eingehenden Anforderungen nach Daten, die in einer Massenspeichereinheit in dem Ausgangscomputersystem residieren; Protokoll zum Authentifizieren der eingehenden Anforderungen; ein Sitzungsmanager-Objekt (138a) zum Hervorbringen einer Pluralität von Sitzungs-Threads, wobei jeder Thread konfiguriert ist zum Lesen und Analysieren eines Befehls, der über die eingehenden Anforderungen empfangen wurde, wobei der Befehl zum Senden der Daten zu einem zweiten Computersystem vorgesehen ist; ein Leserkanal-Objekt (142a) zum Lesen von Daten und Schreiben von mindestens einem Teil der Daten in einen ersten Datenblockpuffer; ein Komprimierungskanal-Objekt (146), das den Teil der Daten in dem ersten Datenblockpuffer in einen komprimierten Datenblock komprimiert und den komprimierten Datenblock in einen zweiten Datenblockpuffer schreibt; ein Verschlüsselerkanal-Objekt (156) zum Verschlüsseln des komprimierten Datenblocks in dem zweiten Datenblockpuffer in einen verschlüsselten und komprimierten Datenblock und Schreiben des verschlüsselten und komprimierten Datenblocks in einen dritten Datenblockpuffer; und ein Schreiberkanal-Objekt (152a) zum Lesen des verschlüsselten und komprimierten Datenblocks in dem dritten Datenblockpuffer und Senden des verschlüsselten und komprimierten Datenblocks an das zweite Computersystem, wobei jeder Sitzungs-Thread das Leserkanal-Objekt, das Komprimierungskanal-Objekt, das Verschlüsselerkanal-Objekt und das Schreiberkanal-Objekt gleichzeitig ausführt; und einen Prozessor (1001), der an den Bus gekoppelt ist, wobei der Prozessor zum Ausführen der multithreadingfähigen analytischen Data-Warehousing-Anwendung konfiguriert ist.
Zielcomputersystem, umfassend: einen Bus (1000); eine Speichereinheit (1002, 1003, 1004), die an den Bus gekoppelt ist; eine multithreadingfähige analytische Data-Warehousing-Anwendung, die in der Speichereinheit gespeichert ist, und umfassend: eine erste Pluralität von Sitzungs-Threads (140b) zum Ausgeben von Anforderungen nach Daten an ein Ausgangscomputersystem, in dem die Daten residieren; ein Sitzungsmanager-Objekt (138b) zum Hervorbringen einer zweiten Pluralität von Sitzungs-Threads als Reaktion auf Nachrichten von dem Ausgangscomputersystem; ein Hörer-Objekt (130b) zum Empfangen mindestens eines verschlüsselten und komprimierten Datenblocks von dem Ausgangscomputersystem; ein Leserkanal-Objekt (142b) zum Lesen von Daten und Schreiben von mindestens einem Teil der verschlüsselten und komprimierten Daten in einen ersten Datenblockpuffer; ein Entschlüsselerkanal-Objekt (164) zum Entschlüsseln des verschlüsselten und komprimierten Datenblocks in einen komprimierten Datenblock und Schreiben des komprimierten Datenblocks in einen zweiten Datenblockpuffer; und ein Entkomprimierungskanal-Objekt (158) zum Entkomprimieren des komprimierten Datenblocks in dem zweiten Datenblockpuffer und Schreiben eines resultierenden Datenblocks in einen dritten Datenblockpuffer, wobei jeder Sitzungs-Thread das Leserkanal-Objekt, das Entschlüsselerkanal-Objekt und das Entkomprimierungskanal-Objekt gleichzeitig ausführt; und einen Prozessor, der an den Bus gekoppelt ist, wobei der Prozessor zum Ausführen der multithreadingfähigen analytischen Data-Warehousing-Anwendung konfiguriert ist.