DE69832406T2

DE69832406T2 - Kombiniertes internet-und datenzugangssystem

Info

Publication number: DE69832406T2
Application number: DE69832406T
Authority: DE
Inventors: E. Charles JESKE
Original assignee: Intervoice LP
Current assignee: Intervoice LP
Priority date: 1997-09-26
Filing date: 1998-09-23
Publication date: 2006-08-03
Anticipated expiration: 2018-09-24
Also published as: EP1025507A4; EP1025507A1; WO1999017216B1; ATE310279T1; US5974443A; AU9403598A; DE69832406D1; WO1999017216A1; CA2303861A1; EP1025507B1

Description

Hintergrund der Erfindung
In bestehenden Technologien wird ein Zugang zu Information typischerweise zu Terminalvorrichtungen bzw. Endgeräten, wie Telefonen, Faxmaschinen, ADSI Telefonen und Datenmodems durch das Telefonnetzwerk von Informationsservern zur Verfügung gestellt. Die Informationsserver könnten einen Zugriff auf bzw. zu Information zur Verfügung stellen, die in einer Datenbank gespeichert ist, durch Verwendung von DTMF Protokollen, POSI Protokollen, Sprache usw. Derartige Systeme umfassen bzw. enthalten E-Mail-Server, Faxserver, ADSI Server, Sprachserver, Datenbankserver und Computer-Telefon-Integration (CTI) Server. Da das Internet vorherrschend wurde, entstand ein weiteres Verfahren zum Verteilen von Information, welches der HTTP Server ist. Jedoch ist der Informationsfluß in HTTP Servern typischerweise im HTML Format, jedoch kann es in anderen Formaten, wie JAVA, XTML, PDF usw. sein. Diese Formate, die durch den HTTP Server verwendet werden, sind unterschiedlich von den anderen Arten von Servern. Darüber hinaus waren HTTP Server historisch gesehen selbstständige bzw. unabhängige Vorrichtungen dahingehend, daß sie normalerweise nicht auf Information zugreifen, die in anderen Arten von Informationsspeicher-Vorrichtungen gespeichert ist bzw. war. Folglich gibt es ein Problem, wenn die Information, die der HTTP Server verteilen soll, nicht auf dem HTTP Server vorliegt, sondern in einer anderen Art von Server angeordnet ist. Aufgrund des Unterschieds in dem Format und ihrer unabhängigen Art haben HTTP Server Schwierigkeiten beim Zu greifen auf Daten, die in anderen, nicht HTTP orientierten Wirten bzw. Hosts gespeichert sind. Dieses Problem wird für Informationsverteilungszentren vergrößert, welche häufig mehr als einen HTTP Server besitzen würden, um die Antwort auf ein großes Volumen von Anfragen und/oder Informationsfluß zu erlauben.
Eine Lösung gemäß dem Stand der Technik für dieses Problem ist, daß jede Art von Servern mit dem HTTP Server über einen spezifischen Satz von Hardware und Software zu verbinden war, welche nicht für die anderen Arten von Servern arbeiten würden. Jedoch ist diese Lösung dahingehend problematisch, daß sie inflexibel ist, da jede Art von Server, die mit dem HTTP Server verbunden ist, gesondert konfiguriert werden muß, da es für den HTTP Server schwierig ist, auf Daten auf verschiedenen Informationsservern zuzugreifen, wenn sie alle voneinander unterschiedlich sind. Auch wird die gesamte Be- bzw. Verarbeitung, die mit der Informationsentnahme von den anderen Servern involviert ist, durch den HTTP Web-Server ausgeführt, was ineffizient ist, da die Zeitverzögerung zum Senden von Antworten auf Browseranfragen erhöht wird. Darüber hinaus werden derartige Verbindungen nicht handhabbar bzw. managbar, wenn versucht wird, mehrere HTTP Web-Server in das System zu verbinden.
Daher besteht ein Erfordernis in der Technik, ein Interface bzw. eine Schnittstelle zu haben, welches) es dem HTTP Server erlaubt, leicht mit anderen Arten von Informationsservern zu kommunizieren, insbesondere für den HTTP Web-Server, damit Informationsanfragen zu den anderen Servern geroutet bzw. geführt werden, und für den HTTP Server, um Antworten von diesen Servern zu empfangen. Darüber hinaus besteht ein Erfordernis in der Technik, ein Interfacesystem zu haben, welches fähig ist, mehrere HTTP Web-Server mit mehreren Interfaceknoten zu verbinden.
EP 0 747 840 A beschreibt ein Verfahren zum Erfüllen von Anforderungen eines Web-Browsers. Programmierbare Funktionen werden an dedizierten Verteilungs-Integrations-Lösungs- (DIS) Servern bei Empfang eines Befehls von einem Steuer- bzw. Regelprogrammagenten ausgeführt, der in einem Web-Server vorliegt.
Zusammenfassung der Erfindung
Diese und andere Ziele bzw. Gegenstände, Merkmale und technische Vorteile werden durch ein System und ein Verfahren erzielt, welches ein Zugriffswerkzeug verwendet, um den HTTP Server mit den anderen Arten bzw. Typen von Servern zu interfacen bzw. zu verknüpfen. Spezifisch stellt dieses Zugriffswerkzeug den Zugriff von dem HTTP Server zu einer Agentenplattform zur Verfügung, welche wiederum mit den anderen Servern verbunden ist. Das Zugriffswerkzeug ist zwischen dem Web- bzw. Netz-Server und der Agentenplattform verbunden bzw. angeschlossen. Das Zugriffswerkzeug formatiert Informationsanfragen von dem HTTP Server in Anwendungen neu, welche die angefragte bzw. geforderte Information von der geeigneten bzw. entsprechenden Datenbank entnehmen. Die entnommene Information wird dann in ein HTML Dokument verschmolzen und zurück zu dem Web-Server gesandt zur Übertragung über das Internet zu dem Browser, welcher ursprünglich die Anfrage gestellt hat.
Mehrere Web-Server können mit mehreren Agentenplattformen verbunden sein bzw. werden, um ein Multiknoten-Informa tionssystem zur Verfügung zu stellen. Das Mehrfach- bzw. Multiknotensystem würde einen Sitzungs-Manager verwenden, um die unterschiedlichen Anfragesitzungen zu überwachen, welche durch das System gehandhabt sind bzw. werden, ebenso wie eine Steuerung bzw. Regelung, welche Anfrage durch welche Agentenplattform gehandhabt ist. Der Sitzungs-Manager ist in einer der Agentenplattformen angeordnet.
Das Zugriffswerkzeug stellt die Fähigkeit zur Verfügung, dieselbe Geschäftslogik oder denselben Code, die bzw. der auf einem HTTP Server läuft, aufzuweisen, erlaubt jedoch auch dem System, dieselbe Geschäftslogik für Zugriffshosts, Datenbanken, E-Mail, CTI und andere Datenlager- bzw. -verwaltungssysteme zu verwenden. Daher wird dieselbe Geschäftslogik, welche für einen Internetzugang bzw. -zugriff läuft, auch einen Zugang durch das Telefonnetzwerk zur Verfügung stellen.
Das Vorhergehende hat eher grob die Merkmale und technischen Vorteile der vorliegenden Erfindung umrissen, damit die detaillierte Beschreibung der Erfindung, welche folgt, besser verstanden werden kann. Zusätzliche Merkmale und Vorteile der Erfindung werden nachfolgend beschrieben, welche den Gegenstand der Ansprüche der Erfindung bilden. Es sollte durch den Fachmann erkannt werden, daß das Konzept und die spezifische Ausbildung, die geoffenbart sind, leicht als eine Basis zum Modifizieren oder Ausbilden bzw. Entwerfen von anderen Strukturen zum Ausführen derselben Zwecke, wie die vorliegende Erfindung verwendet werden könnten. Es sollte auch durch den Fachmann realisiert werden, daß derartige äquivalente Konstruktionen nicht vom Rahmen der Erfindung abweichen, wie sie in den beiliegenden Ansprüchen ausgeführt ist.
Kurze Beschreibung der Zeichnungen
Für ein kompletteres Verständnis der vorliegenden Erfindung und die Vorteile davon wird nun auf die folgende Beschreibung Bezug genommen, die im Zusammenhang mit den beiliegenden Zeichnungen gegeben ist, in welche:
1 das erfindungsgemäße Zugriffswerkzeug zeigt bzw. darstellt, das einen Browser mit einer Agentenplattform verbindet;
2 eine schematische Ansicht des Datengateways des erfindungsgemäßen Zugriffswerkzeugs zeigt;
3A und 3B eine Mehrfachknotenimplementierung des erfindungsgemäßen Zugriffswerkzeug zeigen; und
4 eine URL zeigt, die in dem erfindungsgemäßen Zugriffswerkzeug verwendet wird.
Beschreibung der bevorzugten Ausbildungen
Das erfindungsgemäße Zugriffswerkzeug erlaubt dynamische Informationsbildung bzw. Generierung dynamischer Information für Web-Server. Das Zugriffswerkzeug ist die Kommunikationsverbindung zwischen einem Hyper Text Transfer Protocol (HTTP) Server und anderen Arten von Servern, wie E-Mail, Wirt bzw. Host, Main-Frame bzw. Großrechner, Datenbank und CTI Servern. Das Zugriffswerkzeug verbindet auch HTTP Server mit Standardtelefonnetzwerken.
Ein Benutzer greift über einen Browser 101 zu dem World Wide Web (WWW oder Web) zu und sendet eine Informationsanfrage. Das Zugriffsprotokoll, das durch den Browser verwendet wird, ist HTTP 112, jedoch kann ein unterschiedliches Protokoll verwendet werden. Die Mittel für einen Transport der Daten sind das Internet 113. Die unterschiedlichen Dokumente, Medien und Netzwerkservices auf dem Internet 113 sind bzw. werden mittels des Uniform Resource Locator (URL) angeordnet, welcher ein standardisiertes Verfahren zum Adressieren der Inhalte des Internets 113 ist. Der URL, der durch den Browser 101 generiert ist, ist im wesentlichen eine Adresse für ein spezifisches Dokument, Medien oder Service auf dem Internet 113. Mit anderen Worten würde ein Browser URL auf einen Web-Server zeigen, welcher eine spezielle Adresse definiert. Die HTTP Anfrage geht zu einem Web-Server 102. Der Web-Server 102 ist typischerweise eine physikalische Entität, z.B. ein Personal Computer, auf welchem die Web-Server-Software HTTPd 103 läuft.
Einem Beispiel eines Verfahrens von Kommunikationen in dem System ist es, das gemeinsame bzw. übliche Gateway Interface (CGI) 111 zu verwenden. Es gibt auch andere Zugriffsverfahren, beispielsweise NSAPI (NetScape Application Programming Interface) und ISAPI (Internet Server Application Programming Interface). Beide sind Mittel zum Kommunizieren zwischen der Web-Server-Software und einem anderen Programm oder einer dynamischen Verbindungsbibliothek bzw. Link Library (DLL). In der bevorzugten Ausbildung ist CGI 111 zu verwenden, welches ein Industriestandardverfahren eines Kommunizierens zwischen einem Web-Server und einem anderen Programm ist. HTTPd 103 initiiert das CGIG Verfahren (Common Gateway Interface Gateway) 104, welches eine Programmkomponente ist, welche einen Zugriff zu der Agentenplattform 105 zur Verfügung stellt. Es ist festzuhalten, daß mehr als ein CGIG 104 auf dem Web-Server 102 laufen kann, mit einem CGIG pro gleichzeitiger Browseranfrage. Die Agentenplattform oder der Knoten ist mit den verschiedenen Servern, wie E-Mail, Wirt, Großrechner bzw. Mainframe und CTI, verbunden. Der Web-Server stellt Information betreffend die Anfrage, welche der Browser getätigt hat, durch das CGI Interface 111 zur Verfügung. CGI verwendet Rohre und Umgebungsvariablen auf dem Web-Server 102, um die Information zwischen der Web-Server-Software und dem CGIG Verfahren 104 zu erhalten.
Die Information, die der Browser oder der Benutzer zu entnehmen versuchen könnte, ist ein Kontenabgleich bzw. ein Kontostand, daher kann einige Information von dem Benutzer erforderlich sein, d.h. seine Kontonummer oder PIN Nummer. Alle Information wird über das Internet zu dem Web-Server und dann durch CGI zu dem System zur Verarbeitung übertragen. Der CGIG 104 kommuniziert mit der Agentenplattform über die TCP/IP Sockel bzw. Buchsen 110, über eine physikalische Verbindung, wie ein LAN 114. Das Verfahren, welches auf der Agentenplattform oder dem Knoten 105 läuft, wird ein Datengateway bzw. -portal oder DG 106 genannt. Der Datengatewayprozeß auf der Agentenplattform wartet auf Anfragen von der CGIG 104. Sobald eine Anfrage einfangt, übersetzt sie die Information, die über den Sockel kommt, in Postkarten bzw. Postcards 109. Postkartennachrichten 109 ist ein InterVoice spezifisches Interprozeß-Nachrichtenkommunikationsverfahren, welches die Fähigkeit zur Verfügung stellt, Nachrichten an andere zu einem Postkartenbenachrichtigen befähigte Einheiten bzw. Entitäten zu übersenden. Es ist festzuhalten, daß dieses System auch mit anderen Interprozeß-Nachrichtensystemen arbeiten würde. Postkarten stellen eine Verbindung zwischen dem Datengateway und der virtuellen Anwendung 107 zur Verfügung.
Die virtuelle Anwendung 107 ist die Geschäftslogik, welche die Anfrage interpretiert, die von dem Browser erhalten ist, und auf Host- bzw. Wirts- oder Datenbankserver zugreift. Der Wirts- oder Datenbankserver ist typischerweise ein externes System 108. Die Anwendung würde auf den Wirts- oder Datenbankserver zugreifen, die Information entnehmen, die erforderlich bzw. angefordert ist, um die Anfrage zu verarbeiten, und dann die Antwort den gesamten Weg zu dem Web-Browser 101 zurücksenden. Die virtuelle Anwendung 107 benutzt bzw. verwendet Postkarten 109, um die Information zu dem Datengateway 106 zurückzusenden, welche Sockel 110 verwendet, um sie zu CGIG 104 zu bringen, und dann gibt die CGIG 104 sie zu dem Web-Server 102 weiter und der Web-Server sendet die Antwortinformation zurück zu dem Browser.
Die dynamische Fähigkeit dieses Systems ist, daß die virtuelle Anwendung 107 ein HTML Template File definiert. Ein HTML Schablonen bzw. Template File ist ein HTML Dokument, welches spezifische Bereiche in dem Dokument definiert hat, welche dynamisch ausgefüllt werden. Beispielsweise gibt es Plätze in dem Dokument, welche Kontenabgleiche, Daten, Zeiten oder Namen enthalten werden. Diese Positionen sind klar in dem Template File markiert, so daß sie durch diese dynamischen Daten bevölkert werden können. Das Template File liegt auf der Agentenplattform oder dem Knoten. Somit werden jegliche dynamische Daten, welche von dem Wirt oder der Datenbank kommen, durch das Datengateway 106 mit dem Template File bzw. der Schablonendatei verschmolzen und dann zurück zu dem Browser gesandt. Beispielsweise, wenn hier eine Bankmitteilung in dem Template File ist, und dort eine Zeile des Template File ist, die definiert ist, um auszuführen "Hier ist das Datum, hier ist die Überprüfungsnummer, hier ist, zu wem es abging, hier ist die Wertgröße, und hier ist der Abgleich nachher". Diese Merkmale bzw. Werte können alle als eine Zeile definiert werden, und dann würde die virtuelle Anwendung 107 gehen und die Information entnehmen, die für jedes Merkmal verfügbar ist, selbst wenn jedes Merkmal bzw. jeder Wert in einer unterschiedlichen Quelle oder Datenbank gefunden wird. Das Datengateway würde dann alle Information verschmelzen und eine Antwort bilden, basierend auf der dynamischen Information, welche entnommen wurde.
Das erfindungsgemäße System könnte sich auch mit einem Telefonsystem kombinieren lassen. Der Unterschied zwischen Telefonanrufen und Internetanrufen ist, daß die Vorderend-Logik, welche einen Telefonanruf handhabt, eine gesonderte Anwendung sein würde und spezifisch für einen Telefonanruf geschrieben sein würde. Dies deshalb, da ein Telefonanruf von HTML Browser Anfragen unterschiedlich sind. Ein Telefonanruf hat einen definierten Beginn- und Endpunkt. Das HTTP Protokoll ist zustandslos, was bedeutet, daß eine Anfrage von einem Browser vollständig unabhängig von irgendeiner anderen ist. Ein Browser, wenn er zu einer HTML Seite geht bzw. gelangt, wird das Dokument entnehmen, und im Inneren des Dokuments sind Bezüge auf mögliche Bilder oder andere Dokumente. Die Browser würden dann gehen und zahlreiche Anfragen für die unterschiedliche Referenzen bzw. Bezugnahmen machen. Diese Anfragen sind nicht in irgendeiner Weise miteinander verbunden, da eine Anfrage unabhängig von der anderen ist. Somit hat für ein Sitzungsmanagement das Zugriffswerkzeug die Fähigkeit, Sitzungen zu definieren.
Der Uniform Resource Locator (URL) ist ein standardisierter Weg, unterschiedliche Dokumente, Medien und Netzwerkser vices im Web zu adressieren, und beschreibt, wohin die Benutzeranfrage von dem Web-Browser 101 zu senden ist. Die Gebiete in dem URL werden verwendet, um Sitzungsinformation zu definieren. Die Information wird von dem Web-Browser 101 zu dem Web-Server 102 und dann zu der CGIG 104 weitergegeben. 4 zeigt eine URL für das erfindungsgemäße Zugriffswerkzeug. Die URL 400 hat eine stellenspezifische Information 401, welche definiert, welches Domainprotokoll zu verwenden ist, und den Ort des Wirts. Das nächste Feld 402 definiert den Namen des Verzeichnisses, wo die CGIG Files bzw. Dateien angeordnet sind, und ist spezifisch für die Art des Web-Servers 102, der verwendet wird. Das nächste Feld definiert den Namen des CGIG ausführbaren Files 403 und ist spezifisch für die Art des Betriebssystems, das verwendet wird. App Klasse 404 ist der Name des zentralen Anwendungsverzeichnisses. Da die Agentenplattform 105 mehrere Anwendungen aufweisen kann, erlaubt dies, einen Weg zu identifizieren, mit welcher der speziellen Anwendungen, die in der Agentenplattform 105 laufen, der Browser 102 zu kommunizieren wünscht.
Das nächste Feld ist die Sitzungsidentifizierung 405, welche ein Schlüssel oder eine Sequenz von Buchstaben bzw. Zeichen ist, welche zu jedem Browserbenutzer gesandt werden, wenn sie sich einloggen. Dieser Schlüssel wird für eine Transaktionsverifizierung verwendet. Somit wird jeder, der sich in das System unter Verwendung des Zugriffswerkzeugs einloggt, eine unterschiedliche Sitzungsidentifizierung bzw. Sitzungsidentifikationskennung erhalten. Die Sitzungsidentifizierung kann verwendet werden, um Information betreffend einen speziellen Benutzer zu speichern, da das System die Sitzungsidentifizierung als einen Schlüssel in eine Datenbank verwenden kann, um die Infor mation wieder aufzurufen, auf die der Benutzer vorher zugegriffen hat. Dies würde es ermöglichen, daß eine lange Sitzung in mehrere kleinere Sitzungen aufgebrochen bzw. unterteilt wird. Beispielsweise könnte, wenn die Sitzung eine lange Überwachung bzw. Überprüfung ist, dann die Sitzungsidentifikation bzw. -identifizierung verwendet werden, um es dem Benutzer zu ermöglichen, die Überwachung in Stücken statt sämtliche bei derselben Sitzung auszufüllen. Das Sy- stem kann sich erinnern, wo der Benutzer es verlassen hat, und es wieder an dem Browser anzeigen, wenn der Benutzer die Überwachung bzw. Suche wieder startet. Somit umfaßt die Sitzung mehrere Anfragen von dem Browser 101. Jede Sitzung würde wenigstens eine zugewiesene virtuelle Anwendung besitzen und einen entsprechenden Bearbeitungsthread für jede Anfrage in der Sitzung besitzen. Es ist festzuhalten, daß eine Sitzung nur eine virtuelle Anwendung besitzen könnte, und wenn sie zwei nicht-konkurrierende Anfragen umfaßt, würde die Sitzung zwei Verarbeitungswege besitzen.
Das nächste Feld ist das Anwendungsbezugskennzeichen bzw. -tag 406. Im Inneren der Anwendung gibt es üblicherweise mehrere Anfragen, die in einer Anwendung getätigt werden. Beispielsweise kann, wenn der Browser eine Bankanwendung ist, die erste Frage eine Einlogg-Anfrage bzw. -Anforderung sein, die zweite Frage kann es sein, einen Kontostand zu bestimmen, und die dritte Frage kann es sein, eine Rechnung zu zahlen. Das Tag bzw. Kennzeichen 406 definiert die spezielle Anfrage oder einen speziellen Punkt in der Anwendung, welche der Benutzer wünscht. Das letzte Feld ist das optionale bzw. fakultative Feld 407, welches andere URL codierte Information enthält, welche verwendet werden kann, um Information von einer Anfrage zur nächsten Anfrage weiterzuleiten.
Das erfindungsgemäße Zugriffswerkzeug lädt soviel wie möglich der Bearbeitung von dem Web-Server 102 zu der Agentenplattform herunter. Dies befreit den Web-Server, um andere Aufgaben durchzuführen, wie ein Breitstellen von Dokumenten zu anderen Benutzern. CGIG 104 leitet die Information in einer Anfrage an die DG 106 weiter, welche alle HTTP Protokollcodierungen ausstreift bzw. entfernt. Die Information, welche Namen-Wert-Paare umfaßt, ist in einer Nachricht verkapselt, welche ausführt "Hier ist eine Anfrage, hier sind alle Namen-Wert-Paare, und verarbeite sie". Namen-Wert-Paare sind der Feldname und der Feldwert einer Anfrage. Die HTML Form definiert Namen-Wert-Paare und die CGIG 104 führt diese Information zu dem Datengateway 106 weiter.
2 zeigt das Datengateway 106 des Zugriffswerkzeugs. Der Verarbeitungsthread 201 hört auf dem DG TCP/IP Port oder Sockel. Wenn eine Anfrage von der CGIG einkommt, führt der Serverthread die Anfrage zu einem neuen Verarbeitungsthread weiter. Es ist festzuhalten, daß mehrere Verarbeitungswege bzw. -threads zur selben Zeit vorliegen können. Nach Abgeben der Anfrage zu dem Bearbeitungsthread kehrt der Serverthread zum Hören an dem Port zurück.
Der Verarbeitungsthread 202 wirkt ein Router, Ressourcenmanager und Datenwandler bzw. -konverter. Der Verarbeitungsthread 202 erleichtert die gesamte Kommunikation zwischen dem CGIG Verfahren und der Anwendung. Der Verarbeitungsthread routet bzw. leitet die Anfragen zu der korrekten Anwendung und er kann mehrere Anwendungen managen. Es ist festzuhalten, daß die Anwendungen bereits vorliegen, in der Anzahl beschränkt sind und daß sie ausgebildet sind, um bestimmte Aufgaben durchzuführen. Der Bearbeitungsthread interpretiert die Information und liest dann die Namen-Wert-Paare. Die genannten Wert-Paare werden in dem Verarbeitungsthread gespeichert und zu der Anwendung 107 in einer spezifischen Reihenfolge gesandt.
Die spezifische Reihenfolge ist wichtig, da die Anwendung 107 die Information verstehen muß, die sie erhält bzw. empfängt. Somit wandelt der Bearbeitungsthread 202 die Namen-Wert-Paare in geordnete Nachrichten unter Verwendung von Postkarten um. Der Name von jedem der Felder in dem HTML Form hat ein spezifisches Format. Das Format, das durch die DG 106 erhalten ist, des Namens des Namen-Wert-Paars ist X.Y.Z. X ist die Postkartennummer. Da eine Anwendung zahlreiche Postkarten empfangen kann, identifiziert X jede Postkarte. Y ist die Parameterzahl, die sich auf einen spezifischen Parameter bezieht, da es mehrere Parameter im Inneren einer Postkarte geben kann. Beispielsweise können fünf Parameter in einer Postkarte sein. Es ist festzuhalten, daß ein einziger Bearbeitungsthread mehrere Benutzer handhaben kann, jedoch nicht gleichzeitig. Z ist der Name des Gebiets. Es wird durch den Anwendungsprogrammierer oder Entwickler verwendet, beispielsweise X.Y. pin_number.
Der Bearbeitungsthread erhält alle dieser Namen-Wert-Paare und formatiert sie entweder in eine einzige Postkarte oder mehrere Postkarten, in Abhängigkeit von den Namen-Wert-Paaren und sendet sie in der korrekten numerierten Reihenfolge zu der virtuellen Anwendung 107. Die virtuelle Anwendung 107 geht dann und kommuniziert mit den dynamischen Datenquellen 108, welche Datenbankserver oder Hostsystemserver sind. Sobald die virtuelle Anwendung 107 die Information aus dem geeigneten Server entnommen hat, formatiert sie sie neuerlich in Postkarten und sendet sie zurück zu dem Bearbeitungsthread 202. Somit verwendet die DG 106 dasselbe Postkarten-Benennungsformat für Information, die zu und aus der virtuellen Anwendung 107 geht.
Der Verarbeitungsthread übersetzt die Postkarten von der virtuellen Anwendung in eine HTTP Antwort. Der Verarbeitungsthread führt die Transformation durch Verwendung eines HTML Template File aus. Das Format des Template File erlaubt die Erzeugung eines HTML Dokuments mit der Information von den Wirts/Datenbankservern. Das HTML Template File weist einen Erklärungsblock auf, welcher die Ausgabefelder in der Schablone definiert. Die Ausgabefelder sind dort, wo die Anwendungsdaten eingesetzt werden. Die Eingabefelder sind Teil der HTML Form, beispielsweise Teil der HTML Spezifikation. Eingaben bzw. Einträge in dem Erklärungsblock haben drei Attribute. Das erste ist das Tag. Das Tag markiert den Ausgabefeldort in dem Template File. Jeder Bezug des Tags wird durch Daten durch den Verarbeitungsthread ersetzt. Das Namen-Attribut definiert die Reihenfolge, in welcher Daten zwischen der virtuellen Anwendung und DG transferiert werden. Das Namen-Attribut folgt dem X.Y.Z. Format, das oben in bezug auf die Postkarten diskutiert wurde. Das Art-Attribut definiert die Feldart, entweder String oder vlist. String ist ein ASCII String und vlist ist eine vertikale Liste, welche analog zu einer Tabellenspalte ist.
Sobald der Verarbeitungsthread alle Informationen enthält, den Template File-Namen und die dynamischen Daten, beginnt der Thread die Information zu verarbeiten. Er beginnt durch Entnehmen des Template File als einen File- bzw. Dateinamen und öffnet das Template File. Er liest den Erklärungsblock, um zu lernen, wieviel Information von der Anwendung er wartet wird. Wie oben erwähnt, definiert der Erklärungsblock die Postkarteninformation, oder die Anzahl von Postkarten und die Anzahl von Parametern für jede Postkarte, welche er empfangen wird. Somit kann der Verarbeitungsthread sicherstellen, daß er alle erforderlichen Informationen besitzt. Als nächstes liest er die Postkarten und überprüft, daß alles gültig ist. Der Verarbeitungsthread verschmilzt bzw. vereinigt dann die dynamischen Daten von den Postkarten mit der Schablone bzw. dem Template, um ein HTML File auszubilden. Dieses HTML File wird dann über das LAN 114 unter Verwendung der TCP/IP Sockel 110 zurück zu dem CGIG Prozeß 104 gesandt. Dann hat CGIG eine vollständig formatierte HTML Antwort und alles, was sie tun muß, ist es, diese Antwort durch den Web-Server 102 über das Internet 113 und zu dem Browser 101 zu senden. Wenn das Verfahren auf dem Web-Server ein CGI Verfahren ist, sendet es auf der Standardausleitung aus.
Die verbleibenden Elemente von 2 funktionieren wie folgt. Der Anwendung-Bereit-Thread 205 verarbeitet spezifische Postkarten von der virtuellen Anwendung, spezifisch die Bereit- und Sitzungspostkarten. Die Bereit-Postkarte detailliert, wenn eine Anwendung verfügbar und bereit zum Laufen ist, und wird zu dem DG Verarbeitungsthread über die Datenbank 206 gesandt. Diese Postkarte stellt auch ein Reihungsverfahren zur Verfügung, so daß das System durch die Anwendungen durch Notieren, welche Anwendungen gereiht werden, laufen kann. Die Sitzungs-Postkarte erlaubt die Befestigung einer Identifikation, welche die URL Identifikation 405 ist, an einem speziellen Verarbeitungsthread.
Das Datengateway hat auch eine Anwendungsdatenbank 206, welche für alle Information ein Depot ist, die DG für ein Funktionieren erfordert. Die Datenbank 206 speichert Information, betreffend welche Anwendung für ein Laufen verfügbar ist, welche ihre Postkartenadressen usw. sind. Dies erlaubt die Assoziation einer Anfrage zu einer verfügbaren ausführenden bzw. Ausführungsanwendung. Der Benutzer-Interface-Thread 207 stellt ein Interface zur außerhalb liegenden Welt zur Verfügung, daß Systemoperatoren Information zur Verfügung stellen und von dem DG erhalten können. Dieser Thread erlaubt es auch den Operatoren, die DG nach oben und unten zu bringen, und stellt andere Interface-Fähigkeiten zur Verfügung.
3A und 3B bezeichnen die Mehrfachknoten-Fähigkeiten des Zugriffswerkzeugs. 3A stellt den Knoten oder die Agentenplattform dar, die den Sitzungs-Manager besitzt. Diese Anordnung erlaubt es mehreren Web-Servern, mit mehreren Agentenplattformen zu kommunizieren. Der Sitzungs-Manager 301 steuert bzw. regelt die Aktivitäten des Zugriffswerkzeugs 300. Es gibt nur einen Sitzungs-Manager 301 pro System und er liegt auf einem der Knoten oder Agentenplattformen. Das Datengateway 302 ist ähnlich zu DG 106 und enthält die Elemente, die in 2 dargestellt sind, obwohl sie nicht in 3A dargestellt sind. Es ist festzuhalten, daß es ein Datengateway 302 pro Agentenplattform 317 gibt, und daß es mehrere Agentenplattformen 317, 318 pro System gibt. Die zwei Verarbeitungsthreads 303 und 304 sind ähnlich zu dem Verarbeitungsthread 202 in ihrer Funktionalität und ihren Fähigkeiten. Ein Voice- bzw. Stimm-Manager oder VM 312 beschränkt die Anzahl von gleichzeitigen Anfragen pro Agentenplattform, die zu einer Zeiteinheit betätigt bzw. bearbeitet werden können. Der festgelegte Sicherheitsschlüssel erlaubt es nur autorisiertem Personal, die Nummer, die in VM 312 gespeichert ist, zu verändern.
Ein Beendigungsthread 305 verfolgt die Beendigung einer Anwendung, sobald ihr zugehöriger Verarbeitungsthread nicht länger die Anwendung 306 benötigt. Eine Beendigung könnte durch die Vervollständigung einer Sitzung, Zeitende bzw. Time out einer Sitzung, Prozeß- bzw. Verfahrensfehler usw. bekannt werden. Die Anwendung 306 ist ähnlich zur Anwendung 107. Die virtuellen Anwendungen 306 werden gestartet oder dynamisch generiert bzw. erzeugt, wenn Anfragen hereinkommen, was bedeutet, daß die Anwendung nicht existieren muß, bevor die Anfrage hereinkommt. Somit erlaubt dies eine effizientere Verwendung von Systemressourcen.
Nachdem der Knoten 318 gewählt ist, um die Anfrage von einem Web-Server-A 315 handzuhaben, können dann nachfolgende Anfragen von dem Web-Server-A 315 über CGIG 307 zu dem Knoten 318 gesandt werden. Die Anfragen können auch zu dem Knoten 317 gesandt werden, wenn der Sitzungs-Manager bestimmt, daß der Knoten 317 besser fähig ist, die Anfragen handzuhaben. Wenn der Web-Server-B eine Anfrage über CGIG 307 sendet, wird der Sitzungs-Manager entscheiden, welcher Knoten sie handhaben wird. Wie dies in 3B gezeigt ist, hat der Sitzungs-Manager entschieden, daß der Knoten 317 die Anfrage von dem Web-Server B 316 handhaben wird. Der Sitzungs-Manager kann alle überlaufenden bzw. zusätzlichen Anfragen zu den anderen Knoten weiterleiten. Somit verteilt der Sitzungs-Manager 301 die Anfragelast über die unterschiedlichen Knoten, welche in dem System verfügbar sind.
Bearbeitungsthreads 303 und 304 kommunizieren mit einem Anwendungsmodul 313 über eine spezifische Postkarte, die eine Anrufaufzeichnung bezeichnet ist, welche spezifische Information bezüglich der Ausführung einer Anwendung, enthaltend den Anmeldungsnamen, Status, Anfrage- bzw. Anrufdauer usw.
enthält. Eine Anrufaufzeichnung triggert das Anwendungsmodul 313, eine Anwendung 306 zu starten. Sie kommuniziert mit dem virtuellen Anwendungsmodul 314 und sagt ihm, daß es eine spezielle Anwendung 306 erzeugen muß. Das Anwendungsmodul 313 speichert Information betreffend die unterschiedlichen Arten von Anwendungen und in Abhängigkeit von der Anrufaufzeichnung wird sie eine spezielle Anwendung erzeugen, um eine spezielle Anfrage handzuhaben. Nachdem sie erzeugt wurde, wird dann die virtuelle Anwendung 306 eine Kommunikation mit dem Verarbeitungsthread 303 in einer Art ähnlich zu jener beginnen, die in 2 gezeigt ist. Die Information wird zwischen dem Verarbeitungsthread 303 und der virtuellen Anwendung 306 übertragen, ist ähnlich zu jener zwischen 202 und 107. Die Information ist in dem Postkartenformat.
CGIG 307 ist ähnlich in der Funktionalität und den Fähigkeiten zu CGIG 104. CGIG 307 kommuniziert mit dem Sitzungs-Manager 301, um zu bestimmen, wohin die Anfragen zu senden sind, die von dem Browser 101 über die Web-Server 315, 316 empfangen sind. Wenn eine Anfrage von einem der Web-Server 315, 316 hereinkommt bzw. einlangt, wird die CGIG 307 mit dem Sitzungs-Manager-Verarbeitungsthread 308 kommunizieren, um zu bestimmen, wo die Anwendung laufen soll. Der Sitzungs-Manager-Verarbeitungsthread 308 hört auf dem DG TCP/IP Port oder Sockel. Es können mehrere unterschiedliche Knoten 317, 318 vorliegen, die verfügbar sind, so daß der Sitzungs-Manager-Bearbeitungsthread 308 die Datenbank 309 konsultieren wird, um zu bestimmen, welche Knoten verfügbar sind, welche Anwendungen gegenwärtig auf jedem der Knoten ausgeführt werden, welche Anwendungen verfügbar sind, um auf jenen Knoten zu laufen (nicht jede Anwendung kann auf jedem Knoten laufen), und irgendeine Information, die zum Treffen einer Entscheidung nötig ist. Beispielsweise kann der Sitzungs-Manager entscheiden, daß ein spezieller Knoten der beste ist, aufgrund eines Verteilungsalgorithmus, welcher als erster verfügbar ist. Sobald der Knoten gewählt ist, sendet der Sitzungs-Manager die Information zur CGIG 307. Die CGIG 307 verbindet mit dem Datengateway 302 wie in 2.
Der Sitzungsklärungs- bzw. -reinigungsthread 310 löscht Sitzungen, die abgelaufen sind. Da es mehrere. Knoten gibt und Anfragen für eine spezifische Sitzung zu irgendeinem Knoten laufen können, hat dann der Sitzungs-Manager die Sitzungen zu verfolgen, um ihre Vervollständigung sicherzustellen. Wenn eine der Sitzungen zeitlich abgelaufen ist, d.h. eine vorbestimmte Wartezeit übersteigt, dann wird der Klärungsthread 310 die Sitzung schließen, indem eine Sitzungszeitablaufnotiz zu einer Anwendung gesandt wird, welche initiieren wird, welche Reinigung bzw. Löschung notwendig ist, um diese Sitzung zu beenden, beispielsweise Entfernen von Einträgen in eine Datenbank oder Schließen einer Hostverbindungen. Die Anwendung, die mit der Sitzung assoziiert ist, wird sich dann selbst beenden. Der Anwendungs-Beendigungs-Thread 305 würde dann eine Bestätigung erhalten, daß die Anwendung beendet wurde. Dies konserviert die Systemressourcen. Wenn der Browser, der die Sitzung initiiert hat, versucht fortzusetzen, wird ein neuer Verarbeitungsthread aus einem Pool bzw. Vorrat von verfügbaren Threads bzw. Wegen gewählt, und wird Information betreffend die vorhergehende Sitzung enthalten, welche in der Datenbank 309 gespeichert ist. Der Sitzungsreinigungsthread 310 wird nach bzw. bei einem Bestimmen, daß eine Sitzung zeitlich abgelaufen ist, eine Beendigungsanfrage tätigen. Es ist festzuhalten, daß der Reinigungsthread 310 nur für Sit zungs-Zeitabläufe arbeitet, Anwendungen, die ihre Aufgaben vervollständigt haben, beendigen selbstständig, nachdem eine Antwort zurück zu der CGIG 307 gesandt wurde.
Der Sitzungs-Manager-Überwachungs-Thread 311 ist für jeden der unterschiedlichen Datengatewayknoten des Systems eingerichtet bzw. aufgebaut. Dieser Thread überwacht die Betätigung bzw. den Betrieb der unterschiedlichen Knoten und verständigt den Sitzungs-Manager, wenn ein spezieller Knoten unten ist. Somit wird der Sitzungs-Manager nicht länger Anfragen zu dem unten bzw. unten liegenden Knoten zuweisen, und wird einen Wiederherstellungsmechanismus initiieren, um jegliche anhängigen Anfragen auf dem unten liegenden Knoten zu den verbleibenden Knoten zuzuweisen. Neue Verarbeitungsthreads würden aus einem Vorrat von verfügbaren Threads gewählt werden und würden die Daten enthalten, die in der Datenbank 309 gespeichert sind. Die Verarbeitungsthreads würden neue virtuelle Anwendungen 306 in den verbleibenden Knoten ablegen, um die Information zu entnehmen, die für ein Bilden von Antworten auf die anhängige Anfrage erforderlich ist. Somit ist dieses System fehlertolerant mit der Ausnahme, daß, wenn der Knoten, der den Sitzungs-Manager aufnimmt, nach unten geht bzw. abschaltet, das gesamte System nach unten gehen wird bzw. versagen bzw. abschalten wird.
Obwohl die vorliegende Erfindung und ihre Vorteile im Detail beschrieben wurde, sollte verstanden werden, daß verschiedene Veränderungen, Substitutionen und Änderungen daran gemacht werden können, ohne vom Rahmen der Erfindung abzuweichen, wie sie durch die anhängigen Ansprüche definiert ist.

Claims

System (100) zum Verteilen von Information zwischen wenigstens einer Datenbank (108) und wenigstens einem globalen Netzwerkserver (102), wobei das System (100) umfaßt: eine Mehrzahl von Plattformen, die jeweils zwischen wenigstens einer Datenbank (108) und wenigstens einem globalen Netzwerkserver (102) verbunden bzw. angeschlossen sind; einen Sessions- bzw. Sitzungs-Manager (301), der auf nur einer Plattform (105) der Mehrzahl von Plattformen vorliegt bzw. vorhanden ist, um einen lnformationsfluß zwischen wenigstens einer Datenbank (108) und wenigstens einem globalen Netzwerkserver (102) zu managen bzw. zu verwalten; und eine Mehrzahl von Datengateways bzw. -portalen bzw. -verbindungen (302), wobei wenigstens ein Datengateway auf jeder Plattform (105) der Mehrzahl von Plattformen vorliegt, um eine Informationsanfrage neu zu formatieren, die von dem wenigstens einen globalen Netzwerkserver (102) erhalten ist, die neu formatierte Informationsanfrage auf die wenigstens eine Datenbank (108) zu lenken, eine Antwort von der wenigstens einen Datenbank (108) neu zu formatieren, und die neuformatierte Antwort auf den wenigstens einen globalen Netzwerkserver (102) zu leiten.
System (100) nach Anspruch 1, weiters umfassend: Mittel zum Beschränken einer Anzahl von Anfragen, welche jede Plattform (105) aktiv pro Zeiteinheit aufweisen kann.
System (100) nach Anspruch 1, wobei der Sitzungs-Manager (301) umfaßt: einen Manager-Leitfaden bzw. eine Manager-Verkettung (308) zum Bestimmen, welche aus der Mehrzahl von Plattform bei der Informationsanfrage arbeiten wird und als eine bearbeitende Plattform (105) bezeichnet ist.
System (100) nach Anspruch 3, wobei der Sitzungs-Manager (301) weiters umfaßt: eine Datenbank (108) zum Aufrechterhalten von Information betreffend den Status der Mehrzahl von Plattformen, Arten von Anfragen, welche jede Plattform (105) handhaben kann, und Information betreffend jede Anfrage, welche gegenwärtig auf jeder Plattform (105) arbeitet bzw. bearbeitet wird; wobei der Manager-Leitfaden (308) die Datenbank (108) beim Bestimmen konsultiert, welche aus der Mehrzahl von Plattformen die Informationsanfrage bearbeiten wird.
System (100) nach Anspruch 3, wobei: der Manager-Leitfaden (308) temporär mit dem wenigstens einen globalen Netzwerkserver (102) verbunden ist.
System (100) nach Anspruch 1, wobei der Sitzungs-Manager (301) umfaßt: einen Lösch- bzw. Reinigungs-Leitfaden (310), um eine Session bzw. Sitzung zu löschen, welche die Anfrage umfaßt, welche eine vorbestimmte Leerlaufzeitdauer überschritten hat.
System (100) nach Anspruch 1, wobei der Sitzungs-Manager (301) umfaßt: einen Plattform-Leitfaden (308) zum Überwachen eines Betriebsstatus von jeder der Plattformen der Mehrzahl von Plattformen, wobei der Plattform-Leitfaden (308) über den Sitzungs-Manager (301) über den Betriebsstatus eines Datengateways (302) verständigt, das auf jeder Plattform (105) vorliegt.
System (100) nach Anspruch 1, weiters umfassend: ein Anwendungsmodul (314) zum Ausbilden einer Anwendung basierend auf der Anfrage, wobei die Anwendung auf die wenigstens eine Datenbank (108) zugreift und die Information entnimmt.
System (100) nach Anspruch 8, wobei das wenigstens eine Datengateway (302), das auf der Betriebsplattform (105) vorliegt, umfaßt: einen Prozeß- bzw. Verarbeitungs-Leitfaden (303), welcher die Anfrage von dem wenigstens einen globalen Server erhält und das Anwendungsmodul aufruft.
System (100) nach Anspruch 9, wobei: der Verarbeitungs-Leitfaden (303) die Anfrage in ein Format übersetzt, das durch die Anmeldung verwendbar ist.
System (100) nach Anspruch 10, wobei: der Ver- bzw. Bearbeitungs-Leitfaden (303), der auf dem einen Datengateway (302) vorliegt, welches auf der zugewiesenen bzw. bezeichneten arbeitenden bzw. Betriebsplattform (105) vorliegt, ein dynamisches Musterfile entnimmt und die Information verwendet, die von der wenigstens einen Datenbank (108) entnommen ist, um das Vorlage- bzw. Musterfile zu populieren bzw. zu füllen, um die Antwort auszubilden, und die Antworten auf den wenigstens einen globalen Netzwerkserver (102) leitet.
System (100) nach Anspruch 11, wobei: das Musterfile bzw. die Musterdatei ein HTML-Musterfile ist.
System (100) nach Anspruch 8, wobei das wenigstens eine Datengateway (302), das auf der Betriebsplattform (105) vorliegt, umfaßt: einen Anwendungs-Leitfaden (305), welcher einen Status der Anwendung verfolgt und den Sitzungs-Manager (301) informiert, wenn die Anmeldung bzw. Anwendung abgeschlossen ist.
System (100) nach Anspruch 2, wobei die limitierende Anzahl von Anfragen einstellbar ist.
System (100) nach Anspruch 2, wobei die Mittel zum Beschränken weiters umfassen: einen Sicherheitsschlüssel bzw. eine Sicherheitstaste, um den Zugriff zu den Mitteln zu steuern, um es nur autorisierten Personen zu ermöglichen, die begrenzende bzw. limitierende Anzahl zu verändern.
System (100) nach Anspruch 11, wobei das Musterfile einen Erklärungsblock umfaßt, wobei der Erklärungsblock wenigstens ein Ausgabefeld definiert.
System (100) nach Anspruch 16, wobei das wenigstens eine Ausgabefeld ein zugewiesenes bzw. assoziiertes Tag bzw. eine Identifizierung aufweist, wobei jeder Bezug des zugewiesenen Tags durch Daten ersetzt ist, die durch den Bearbeitungs-Leitfaden entnommen sind.
Verfahren zum Verteilen von Information zwischen wenigstens einer Datenbank (108) und wenigstens einem globalen Netzwerkserver (102) mit einer Mehrzahl von Plattformen, wobei jede Plattform (105) zwischen wenigstens einer Datenbank (108) und wenigstens einem globalen Netzwerkserver (102) zwischengeschaltet bzw. verbunden wird, einem Sitzungs-Manager (301), welcher auf irgendeiner Plattform (105) der Mehrzahl von Plattformen vorliegt, und einer Mehrzahl von Datengateways bzw. -portalen bzw. -verbindungen, wobei wenigstens ein Datengateway (302) auf jeder Plattform (105) der Mehrzahl von Plattformen vorliegt, wobei das Verfahren die Schritte umfaßt eines: Erhaltens einer Informationsanfrage von wenigstens einem globalen Netzwerkserver (102); Bestimmens durch den Sitzungs-Manager (301), welche der Mehrzahl von Plattformen die Anfrage betreffend bzw. nach Information bearbeiten wird und als eine arbeitende bzw. Betriebsplattform (105) bezeichnet wird; Routens bzw. Leitens der Anfrage zu der Betriebsplattform (105); Neuformatierens durch das wenigstens eine Datengateway (302), das auf der Betriebsplattform (105) vorliegt, der Anfrage, die von dem wenigstens einen globalen Netzwerkserver (102) erhalten wird; Leitens durch das wenigstens eine Datengateway (302), das auf der Betriebsplattform (105) vorliegt, der neu formatierten Informationsanfrage auf die wenigstens eine Datenbank (108); Neuformatierens durch das wenigstens eine Datengateway (302), das auf der Betriebsplattform (105) vorliegt, einer Antwort von der wenigstens einen Datenbank (108), Leitens durch das wenigstens eine Datengateway (302), das auf der Betriebsplattform (105) vorliegt, der neu formatierten Antwort auf den wenigstens einen globalen Netzwerkserver (102); und Bearbeitens bzw. Managens durch den Sitzungs-Manager (301) von Informationsfluß zwischen der wenigstens einen Datenbank (108) und dem wenigstens einen globalen Netzwerkserver (102).
Verfahren nach Anspruch 18, weiters umfassend den Schritt eines: Begrenzens einer Anzahl von Anfragen, welche pro Zeiteinheit aktiv sein können.
Verfahren nach Anspruch 18, weiters umfassend die Schritte eines: Beibehaltens von Information betreffend den Status der Mehrzahl von Plattformen-Arten von Anfragen, welche jede Plattform (105) handhaben kann, und Information betreffend jede Anfrage, welche gegenwärtig auf jeder Plattform (105) arbeitet bzw. bearbeitet wird; und Verwendens der beibehaltenen Information in dem Schritt eines Bestimmens, welche der Mehrzahl von Plattformen die Anfrage nach Information bearbeiten wird.
Verfahren nach Anspruch 18, weiters umfassend den Schritt eines: Löschens bzw. Beendens einer Sitzung, welche die Anfrage beinhaltet, die eine vorbestimmte Leerlaufzeitdauer überschritten hat.
Verfahren nach Anspruch 18, weiters umfassend den Schritt eines: Überwachens eines Betriebsstatus von jeder der Plattformen der Mehrzahl von Plattformen; und Verständigens des Sitzungs-Managers (301) über den Betriebsstatus eines Datengateways (302), das auf jeder Plattform (105) vorliegt.
Verfahren nach Anspruch 18, wobei der wenigstens eine globale Netzwerkserver (102) (102) eine Mehrzahl von globalen Netzwerkservern (102) ist, von welchen jeder mit jeder Plattform (105) der Mehrzahl von Plattformen verbunden ist, und das Verfahren weiters den Schritt umfaßt eines: Managens bzw. Bearbeitens durch den Sitzungs-Manager (301) des Informationsflusses zwischen wenigstens einer Datenbank (108) und jedem globalen Netzwerkserver (102) (102) der Mehrzahl von globalen Netzwerkservern.
Verfahren nach Anspruch 18, weiters umfassend die Schritte eines: Verbindens des wenigstens einen globalen Netzwerkservers (102) mit der Betriebsplattform (105); und Leitens der Informationsanfrage zu dem wenigstens einen Datengateway (302), das auf der Betriebsplattform (105) vorliegt.
Verfahren nach Anspruch 24, weiters umfassend die Schritte eines: Ausbildens bzw. Erzeugen durch ein Anwendungsmodul einer Anwendung basierend auf der Anfrage; und Zugreifens durch die Anwendung auf die wenigstens eine Datenbank (108) und Entnehmens der Information.
Verfahren nach Anspruch 25, weiters umfassend die Schritte eines: Empfangens durch einen Bearbeitungs-Leitfaden (303), der auf dem wenigstens einen Datengateway (302) der Betriebsplattform (105) vorliegt, der Anfrage von dem wenigstens einen globalen Server (102); und Aufrufens durch den Bearbeitungs-Leitfaden (303) des Anwendungsmoduls (314).
Verfahren nach Anspruch 26, weiters umfassend den Schritt eines: Übersetzens durch den Bearbeitungs-Leitfaden (303) der Anfrage in ein Format, das durch die Anwendung verwendbar ist.
Verfahren nach Anspruch 25, weiters umfassend die Schritte eines: Empfangens durch den Bearbeitungs-Leitfaden (303) eines dynamischen Musterfiles; Populierens bzw. Füllens durch den Bearbeitungs-Leitfaden (303) des Musterfiles bzw. der Musterdatei mit der Information, die von der wenigstens einen Datenbank (108) entnommen ist, um die Antwort zu bilden; und Leitens durch den Bearbeitungs-Leitfaden (303) der Antwort auf den wenigstens einen globalen Netzwerkserver (102).
Verfahren nach Anspruch 28, wobei: das Musterfile ein HTML-Musterfile ist.
Verfahren nach Anspruch 25, weiters umfassend die Schritte eines: Verfolgens durch einen Anwendungs-Leitfaden (305), welcher auf dem wenigstens einen Datengateway (302) der Betriebsplattform (105) vorhanden ist, eines Status der Anwendung; und Informierens durch den Anwendungs-Leitfaden (305) des Sitzungs-Managers (301), wenn die Anwendung beendet ist bzw. wird.