DE60008555T2

DE60008555T2 - Verfahren und vorrichtung zur effizienten übertragung von daten einer interaktiven anwendung zwischen klienten und server mit hilfe einer markup-sprache

Info

Publication number: DE60008555T2
Application number: DE60008555T
Authority: DE
Inventors: C. David MITCHELL; Ben Walters; Dale Mitchell
Original assignee: Citrix Systems Inc
Current assignee: Citrix Systems Inc
Priority date: 1999-09-07
Filing date: 2000-09-07
Publication date: 2004-08-05
Anticipated expiration: 2020-09-08
Also published as: ES2219393T3; US20050251551A1; HK1046321A1; CA2383849A1; US6356933B2; KR20020085873A; AU7353800A; JP2003509739A; WO2001018691A2; WO2001018691A3; US7596593B2; DE60008555D1; US20010042094A1; US20020116455A1; IL148461A0; US6920480B2; EP1214667B1; EP1214667A2

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft Client-Server-Netze und insbesondere Verfahren und Vorrichtungen zur Fernausführung einer Anwendung und Fernanzeige einer Anwendungsausgabe.
Allgemeiner Stand der Technik
Moderne Computernetze bestehen aus etlichen Computersystemen, welche Knoten genannt werden und mit anderen Computersystemen über Kommunikationsverbindungsleitungen in Verbindung stehen. Normalerweise sind einige der Knoten Client-Knoten, und andere Knoten sind Server-Knoten. Ein Client-Knoten formuliert und übermittelt Abfragen an einen Server-Knoten. Ein Benutzer des Client-Knotens gibt die Abfragen durch eine Benutzerschnittstelle, welche auf dem Client-Knoten funktioniert, ein. Der Server-Knoten wertet die Abfragen aus und übermittelt Antworten an den Client-Knoten zur Anzeige auf der Client-Benutzerschnittstelle.
Normalerweise beherbergen die Server-Knoten eine Vielfalt von Anwendungsprogrammen oder -prozessen, auf welche durch Client-Knoten zugegriffen werden kann und welche durch dieselben ausgeführt werden können. Wenn ein Client-Knoten ein Anwendungsprogramm startet, kann die Ausführung dieses Anwendungsprogramms in Abhängigkeit vom Rechenmodell, dem das Computernetz folgt, entweder am Client-Knoten oder am Server-Knoten erfolgen.
Bei einem clientbasierten Rechenmodell wird das Anwendungsprogramm verdichtet und an den Client-Knoten hinunter gesendet oder in diesem vorinstalliert, wodurch dem Client-Knoten erlaubt wird, die Anwendung unter Verwendung der Betriebsmittel des Client-Knotens ablaufen zu lassen. Diese Lösung weist mehrere Nachteile auf. Erstens muss der Client-Knoten über genügend Speicherkapazität, Festplattenspeicherplatz und Verarbeitungsleistung verfügen, um die Anwendung effektiv auszuführen. Ein verwandtes Problem, das bei Verwenden dieses Modells auftritt, ist, dass die Anzahl von Anwendungen, die ein bestimmter Client ausführen kann, infolge der Betriebsmitteleinschränkungen des Clients begrenzt ist. Außerdem ist es kompliziert, Anwendungen, welche auf diese Weise aufgebaut sind, zu entwickeln und aufrechtzuerhalten, und erfordern normalerweise eine Modifikation oder „Portieren" für alle Arten von unterstützten Client-Computersystemen. Außerdem vergrößert diese Technik die Verwaltungslast auf einem Netzverwalter.
Bei einem serverbasierten Rechenmodell führt der Server-Knoten das Anwendungsprogramm aus, und es wird nur die Steuerinformation für die Client-Benutzerschnittstelle über das Computernetz an den Client-Knoten zur Anzeige übertragen. Bei Verwenden dieser Lösung müssen Benutzerschnittstellenereignisse zwischen dem Client und dem Server hin- und hergeschickt werden, damit die Serveranwendung die Ereignisse verarbeitet. Dies führt zu wahrgenommenen Antwortverzögerungen an der Benutzerschnittstelle. Außerdem muss das Anwendungsprogramm speziell geschrieben oder geändert werden, um die Benutzerschnittstelle am Client-Knoten zu unterstützen. Dies erhöht die Komplexität der Anwendung und verhindert, dass diese Technik für serienmäßig hergestellte Anwendungen brauchbar ist.
Eine Verbesserung des serverbasierten Modells ist, den Gerätetreiber zu ersetzen, an welchen die Anwendung überträgt, um Bildschirm- und Geräteaktualisierungen zwischen dem Client und dem Server hin- und herzuschicken. Diese Lösung vermeidet, dass Anwendungen neu geschrieben werden müssen. Diese Lösung erfordert jedoch, dass Geräteinformation zwischen dem Client und dem Server hin- und hergeschickt wird, um die Client-Anzeige aufrechtzuerhalten, wodurch wiederum eine wahrgenommene Wartezeit in die Schnittstelle eingeführt wird. Außerdem werden serverseitige Verarbeitungsanforderungen erhöht, um der resultierenden Geräteinformation, welche zur Kommunikation mit jedem angeschlossenen Client erforderlich ist, zu genügen.
Eine kürzliche weitere Verbesserung des serverbasierten Modells ist, den Benutzerschnittstellenteil der Anwendung als ein Markup-Sprache-Dokument, wie beispielsweise ein Hypertext-Markup-Sprache-Dokument (HTML nach engl. Hyper Text Markup Language), einzusetzen. Bei Verwenden dieser Lösung jedoch beginnt Information, welche von der Serveranwendung an den Client gesendet wird, unverzüglich zu „altern". Mit anderen Worten, die Information kann sich auf dem Server ändern, aber der Client würde weder automatisch benachrichtigt noch aktualisiert werden. Außerdem erfordert Interaktivität bei dieser Lösung sogar zur Durchführung einfacher Aufgaben kontextbezogenes Umschalten zwischen Seiten.
Die vorliegende Erfindung vermeidet diese Unzulänglichkeiten.
Kurzdarstellung der Erfindung
Die vorliegende Erfindung, wie beansprucht, stellt einen Mechanismus bereit, durch welchen der Benutzerschnittstellenteil der Anwendung entweder auf demselben Gerät, auf dem die Anwendung abläuft, oder auf einem anderen Gerät, welches von den Gerät, das die Anwendung ausführt, entfernt ist, an den Computerbenutzer übermittelt werden kann. Die Erfindung trennt die Benutzerschnittstelle von der zu Grunde liegenden Anwendung, wodurch der interaktive Benutzerteil der Anwendung äußerst einfach sein kann. Die Erfindung ermöglicht es auch, dass der interaktive Benutzerteil in einer großen Auswahl von Client-Hardwareumgebungen eingesetzt wird, ohne dass er die gesamte Logik mit sich bringt, die zum Ausführen der Funktionalität einer bestimmten Anwendung erforderlich ist. Diese Merkmale haben für den Benutzer die Wirkung, dass er mit der ganzen Anwendung direkt kommunizieren kann, selbst wenn der Hauptteil der Anwendung potenziell irgendwo anders abläuft.
Somit überwindet die vorliegende Erfindung viele der Probleme, denen die zuvor umrissenen herkömmlichen Lösungen gegenüberstanden. Die Benutzerschnittstelle, die Ereignisbehandlung und die Bildschirmaufbereitungslogik bleiben auf dem Client, wodurch der Netzverkehr und die Wartezeit enorm reduziert werden. Die gesamte Benutzerschnittstelle und die Art und Weise, wie diese Schnittstelle mit Anwendungskomponenten auf dem Server die Verbindung herstellt, werden als reine Datenbeschreibung (eher als Code) an den Client gesendet. Diese Beschreibung wird durch den Client so „interpretiert", dass er die grafische Benutzerschnittstelle (GUI nach engl. graphics user interface) aufbereitet und die Verbindung mit der Anwendung (durch Zustandsübertragung), welche entweder auf demselben Prozessplatz (demselben Gerät) oder auf dem Server (dem entfernten Gerät) abläuft, herstellt.
Da der Server mit einem bestimmten Anwendungs-Client einfach über eine Datenbeschreibung kommunizieren kann, braucht kein zusätzlicher Code auf dem Client-Gerät installiert zu werden. Ein anwendungsunabhängiger Client-Prozess (AICP nach engl. application-independent client process) liest die Beschreibung und stellt diese Beschreibung dem Benutzer als eine typische Client-Benutzerschnittstelle dar. Daher kann der AICP mit einer unbegrenzten Anzahl von Serveranwendungen mit einer neuen Datendateibeschreibung für jedes Programm (welche je nach Bedarf oder wie durch den Client angegeben automatisch zwischengespeichert werden kann) kommunizieren. Es ist keine anwendungsspezifische Verwaltung zur Ausführung einer AICP-einsetzenden Anwendung, welche diese Lösung verwendet, erforderlich.
Mit dem AICP wird weder zum Aufbereiten des Benutzerschnittstellenabschnitts noch zum Behandeln des GUI-Ereignisabschnitts der Anwendung eine serverseitige Verarbeitung benötigt. Der Server koordiniert jedoch Zustandsinformation, welche an den und vom Client weitergeleitet wird, und sendet diese Information automatisch an die entsprechenden beteiligten Anwendungskomponenten (sowohl vom Client als auch vom Server ausgelöste Datenänderungen).
Bei Verwenden des AICP kann der Entwickler sich in erster Linie auf den Funktions- oder Geschäftslogikteil der Anwendung konzentrieren und die Behandlung der Gesamtheit der Benutzerschnittstellenaufbereitung, Ereignisbehandlung und Verbindung der Benutzerschnittstellensteuerungen mit den zu Grunde liegenden Anwendungskomponenten dem AICP überlassen. Eine Builder-Komponente erlaubt es dem Entwickler, die Benutzerschnittstellenfenster zu gestalten, sowie eine Beziehung zwischen der visuellen Kontrolle und der zu Grunde liegenden Serveranwendungskomponente, mit welcher sie verbunden ist, herzustellen. Bei dem AICP braucht kein anwendungsspezifischer Code an den Client gesendet werden. Nur Benutzerschnittstellensteuerungen müssen nötigenfalls gesendet werden. Selbst wenn kein Code auf dem Client vorhanden ist, ist die Erfahrung des Benutzers mit der Client-Anwendung ähnlich den manuell codierten Clients, welche im clientbasierten Modus vorzufinden sind. In einer Ausführungsform ist der AICP in eine HTML-Browserumgebung eingebunden, welche den Webeinsatz innerhalb einer HTML-Seite ohne die Begrenzung, die mit HTML verbunden ist, möglich macht.
Die vorhergehenden und andere Aufgaben, Merkmale und Vorteile der Erfindung werden aus der folgenden konkreteren Beschreibung der Ausführungsformen der Erfindung, wie in den beiliegenden Zeichnungen veranschaulicht, ersichtlich.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm einer Ausführungsform des Systems der Erfindung;
2 ist ein Blockdiagramm einer Ausführungsform der Speicherkonfiguration eines Servers, welcher gemäß der Erfindung aufgebaut ist;
3 ist ein Funktionsblockdiagramm, welches eine Ausführungsform der Kommunikationen zwischen einem Server und einem Client-Knoten darstellt, welche gemäß der Erfindung aufgebaut sind;
4 ist ein Blockdiagramm einer Ausführungsform der Speicherkonfiguration eines Clients, welcher gemäß der Erfindung aufgebaut ist;
5 ist ein Ablaufdiagramm einer Ausführungsform der Betriebsweise des Servers, welcher gemäß der Erfindung aufgebaut ist; und
6 ist ein Ablaufdiagramm einer Ausführungsform der Betriebsweise des Client-Knoten, welcher gemäß der Erfindung aufgebaut ist.
Ausführliche Beschreibung der Erfindung
Obwohl das Verfahren und die Vorrichtung der vorliegenden Erfindung im Zusammenhang mit einem Webserver- und Webbrowserprozess, welcher über das Internet überträgt, beschrieben werden, ist für die Fachleute zu erkennen, dass die vorliegende Erfindung auch über jede andere Netzwerkart (z. B. Telefon, Kabel, LAN, WAN, drahtlos, Faser) innerhalb desselben physischen Computersystems oder mit Teilen der Erfindung (z. B. dem anwendungsunabhängigen Client-Prozess), welche in einem Internetgerät oder einer Set-Top-Box eines Kabel-TVs laufen, ausgeführt werden kann. Für jene Personen, die mit dem Internet, dem World Wide Web, Webservern und Webbrowsern nicht vertraut sind, wird hier ein kurzer Überblick über diese Konzepte gegeben.
Unter Bezugnahme auf 1 verfügt ein Benutzer, der im Internet 120 auf Information zuzugreifen und Anwendungen auszuführen wünscht, normalerweise über eine Computer-Arbeitsstation 110, welche ein Anwendungsprogramm, das als ein Webbrowser 112 bekannt ist, ausführt. Ein anwendungsunabhängiger Client-Prozess (AICP) 114 gemäß der vorliegenden Erfindung wird in einer Ausführungsform als ein Plug-in zum Webbrowser 112 bereitgestellt. Der Benutzer kommuniziert mit dem Webbrowser 112 und dem AICP 114 über eine Benutzerschnittstelle 116, welche in einer Ausführungsform ein Dateneingabegerät (z. B. eine Tastatur) und ein visuelles Anzeigegerät (z. B. einen Computermonitor) umfasst. Unter der Kontrolle des Webbrowsers 112 sendet die Benutzerarbeitsstation 110 eine Webseitenabfrage 122 über das Internet 120. Webseitendaten können die Form von Text, Grafiken und andere Formen von Information aufweisen. Jedes Webserver-Computersystem 130 im Internet 120 weist eine bekannte Adresse (URL) auf, welche der Benutzer an den Webbrowser 112 liefern muss, um mit dem entsprechenden Webserver 130 die Verbindung herzustellen. Da der Webserver 130 mehr als eine Webseite enthalten kann, gibt der Benutzer in der Adresse auch an, welche konkrete Webseite 124 er auf dem Webserver 130 sehen möchte. Das Webserver-Computersystem 130 führt ein Webserver-Anwendungsprogramm 132, Monitorabfragen und Dienstabfragen, für welche es die Verantwortung hat, aus. Wenn eine Abfrage einen Webserver 130 auswählt, greift das Webserver-Anwendungsprogramm 132 im Allgemeinen auf eine Webseite 124 zu, welche der konkreten Webseitenabfrage 122 entspricht, und überträgt die Webseite 124 an die Benutzerarbeitsstation 110. Die Webseitenabfrage 122 umfasst in einer Ausführungsform auch eine Abfrage zur Ausführung eines Anwendungsprogramms in dem Webserver-Computersystem 130. Ein anwendungsunabhängiger Server-Prozess (AISP nach engl. application-independent server process) 134 empfängt Information, welche. in dieser Abfrage enthalten ist, und antwortet durch Ausführen des gewünschten Anwendungsprogramms und Zugreifen auf Anwendungskomponenten 136, welche durch den AICP 114 benötigt werden.
Im Allgemeinen enthält eine Webseite die visuellen Primärdaten, welche auf der Benutzerschnittstelle 116 der Benutzerarbeitsstation 110 angezeigt werden. Wenn der Webserver 130 eine Webseitenabfrage 122 empfängt, baut er eine Webseite in HTML auf und überträgt sie über das Internet 120 an den abfragenden Webbrowser 112. Der Webbrowser 112 interpretiert die HTML und gibt die Webseite 124 an den Monitor der Benutzerarbeitsstation 10 aus. Die Webseite 124, welche auf dem Bildschirm des Benutzers angezeigt wird, kann Text, Grafiken und Verknüpfungen (welche Adressen anderer Webseite sind) enthalten. Diese anderen Webseiten (d. h. jene, die durch Verknüpfungen dargestellt sind) können auf demselben oder auf anderen Webservern sein. Der Benutzer kann durch Anklicken dieser Querverweise mithilfe einer Maus oder eines anderen Zeigegeräts auf diese anderen Webseiten gehen. Das gesamte System von Webseiten mit Verknüpfungen zu anderen Webseiten auf anderen Servern auf der ganzen Welt ist als das „World Wide Web" bekannt.
Bei der vorliegenden Erfindung ist eine interaktive grafische Benutzerschnittstelle in der Webseite eingebunden und kann als ein getrennter Dialog von der Webseite geöffnet werden. In einer Ausführungsform ist der AICP eine ActiveX-Steuerung, welche in der zuvor erwähnten HTML-Seite eingebunden ist. Die ActiveX-Steuerung interpretiert XML-Daten (nach engl. Extensible Markup Language), welche anschließend in einer Beschreibungsdatei (wird im Folgenden beschrieben) heruntergeladen werden, und bereitet eine grafische Benutzerschnittstelle auf. Diese eingebundene Steuerung ist eine Ausführungsform des AICPs.
Unter Bezugnahme auf 2 befinden sich im Speicher im Serversystem 130 ein Betriebssystem 410, eine Webserveranwendung 132, Anwendungsprogramme 420, Anwendungskomponenten 136, ein Transaktionsprozessor 430, Zustandsinformation, Objektinformation und Daten (nicht dargestellt), sowie eine oder mehr Instanzen eines AISPs 134.
Die Anwendungsprogramme 420 werden durch die zentrale Verarbeitungseinheit CPU (nach engl. central processing unit) des Serversystems 130 unter der Kontrolle des Betriebssystems 410 ausgeführt. Die Anwendungsprogramme 420 können unter Verwendung von Programmdaten als Eingabe, wie beispielsweise jene, die vom AICP 114 empfangen werden, ausgeführt werden. Anwendungsprogramme können auch ihre Ergebnisse als Programmdaten im Speicher ausgeben.
Der Transaktionsprozessor 430 ist ein Programm, welches über eine gemeinsame Netzübergangsschnittstelle (nicht dargestellt) Information von der Webserveranwendung 132 empfängt, die Information interpretiert, um zu bestimmen, ob eine bestimmte Instanz eines AISPs 134 erforderlich ist, und die Instanz AISP 134 startet, um die vom AICP 114 empfangene Abfrage weiter zu verarbeiten.
Unter Bezugnahme auf 3 umfasst die vorliegende Erfindung den AICP 114 und den AISP 134. Der AICP 114 bereitet die grafische Benutzerschnittstelle (GUI), welche dem Benutzer an der Benutzerschnittstelle 116 angezeigt wird, auf. Der AICP 114 erhält auch eine Beziehung zwischen den Steuerobjekten, welche auf der Benutzerschnittstelle 116 angezeigt werden, und den Anwendungskomponenten 136, welche auf dem Webserver 130 aufrechterhalten werden, aufrecht. Der AISP 134 überwacht den Zustand der Anwendungskomponenten 136 zusammen mit den Steuerobjekten, welche auf der Benutzerarbeitsstation 110 angezeigt werden und welche Aktualisierungen dieser Anwendungskomponenten benötigen. Wann immer sich der Zustand auf dem Client (Steuerzustand) oder dem Server (Komponentenzustand) ändert, ergreifen der AICP 114 und der AISP 134 basierend auf der Datenbeschreibung, welche die Beziehung zwischen den GUI-Steuerungen und den Serveranwendungskomponenten 136 (im Folgenden als Serverkomponenten bezeichnet), die sie darstellen, definiert, die entsprechende Maßnahme.
Ebenfalls unter Bezugnahme auf 4 umfasst die Beziehung 446 zwischen den Steuerobjekten 624, welche an der Benutzerschnittstelle 116 der Benutzerarbeitsstation 110 angezeigt werden, und den Serverkomponenten 136, welche auf dem Webserver aufrechterhalten werden, Daten, welche eine deutliche Beziehung zwischen ihren jeweiligen Objektschnittstellen beschreiben. Diese Daten werden im Folgenden als eine Verbindung bezeichnet. Der AICP und der AISP enthalten eine Logik, welche die Verbindungen interpretieren kann, die eine visuelle Kontrolle mit einer Anwendungskomponente in Beziehung bringen.
Eine Bildlaufleistensteuerung ist zum Beispiel repräsentativ für eine Art von Steuerobjekt, welche an der Benutzerschnittstelle 116 der Benutzerarbeitsstation 110 angezeigt werden kann. Die Bildlaufleistensteuerung kann mit dem Wert einer Anwendungskomponente, wie zum Beispiel der Temperatur eines industriellen Prozesses, verbunden werden. Wenn die Serveranwendung eine Temperaturänderung feststellt, wird der Zustand der Anwendungskomponenten 136 geändert, und diese Zustandsänderungen 330 werden an den Client weitergeleitet. Die Bildlaufleiste wird durch den AICP anschließend neu gezeichnet, um den neuen Wert wiederzugeben. Gleichermaßen wird, wenn eine Bildlaufleiste mit einer Anwendungskomponente 136 verbunden ist, welche ein Thermostat steuert, und wenn dann der Benutzer mit der Bildlaufleiste an der Benutzerschnittstelle 116 kommuniziert, die Zustandsänderung an das Webserver-Anwendungsprogramm 132 übertragen, welches den Zustand der entsprechenden Anwendungskomponente 136 ändern würde, welche anschließend das Thermostat einstellen würde.
Obwohl dies ein einfaches Beispiel ist, können Verbindungen Beziehungen (z. B. Datenbeziehungen 446 in 2) zwischen sehr komplexen Objektarten wie zusammengesetzten Komponenten (Komponenten, welche Komponentenreferenzen enthalten), sowie Komponentensammlungen (eine Liste von Komponenten) bilden. Steuerungen können zu komplexen Komponenten oder einer Zusammensetzung aus Steuerungen (gemeinhin als ein Dialog bezeichnet) zusammengefügt (verbunden) werden. Je komplexer die Beziehung 446 (2) ist, umso wortreicher ist die Verbindungsinformation. Verbindungsinformation kann jedoch als eine benannte Entität verdichtet werden, auf welche in einem anderen Kontext Bezug genommen werden kann, so dass eine Wiederverwendung der Verbindung möglich ist.
Es besteht eine physische Verbindung zwischen dem AICP 114 und dem AISP 134. Diese physische Verbindung kann entweder eine netzbasierte (wobei der Server und der Client verschiedene Knoten in einem Netzwerk sind) oder eine speicherbasierte (wobei der Server und der Client in demselben Computersystem sind) sein. Dies bedeutet, dass Steuerobjekte mit Serverkomponenten verbunden werden können, wenn sie beide auf denselben oder verschiedenen physischen Geräten (sowie in demselben Prozess auf demselben Gerät oder in verschiedenen Prozessen auf verschiedenen Geräten) vorhanden sind.
Die Verbindungsinformation kann in einer Beschreibungsdatei in einer Vielfalt von Formaten, wie beispielsweise im XML-Format, wie später erörtert wird, dargestellt werden. Die XML-Daten können auch die GUI-Layoutbeschreibung (d. h. Benutzerschnittstellendaten 448 in 2) umfassen. Wann immer ein Steuerobjekt 624 mit einer Serverkomponente 136 innerhalb eines GUI-Layouts (eines Dialogfensters) verbunden wird, wird die Verbindungsbeschreibung (im Kontext) mit der Layoutinformation aufgenommen. Dies ist die Information, welche der AICP 114 verwendet, um die Anwendung ablaufen zu lassen und die Ergebnisse dem Benutzer anzuzeigen. Sobald ein Dialog über den AICP 114 abläuft, werden Zustandsänderungen, welche auf den Steuerobjekten (Steuerzustände) oder Serverkomponenten (Komponentenzustand, 442 2) auftreten, verdichtet und zwischen dem AICP 114 und dem AISP 134 hin- und hergeschickt. Dies ist eine Zweiwegverbindung, und sie ist asynchron, um die interaktive Wartezeit auf ein Minimum herabzusetzen.
Die Beschreibungsdatei kann in einem XML-Format sein, welches ein praktisches Format für den Einsatz von Daten über ein Netzwerk ist und einer Attributdateistruktur ähnelt, wie zum Beispiel im Anhang dargestellt. Etliche andere geeignete Datenbankformate sind ebenso verfügbar, wie beispielsweise eine lineare Datei, SQL, OODB usw. Das XML-Format besteht aus Name, Art und Wertpaaren, welche es sowohl dem AICP 114 als auch dem AISP 134 erlauben, die Information während der Ablaufzeit in demselben Dateiformat zu durchlaufen und zu interpretieren. Die XML-Datei, welche durch den Client und die AISP zur Ablaufzeit interpretiert wird, kann identisch sein. Die Daten, welche in der XML-Datei enthalten sind, werden durch den AICP 114 und den AISP 134 gemäß den verschiedenen Funktionen, welche auf jeder Seite der Verbindung auszuführen sind, unterschiedlich interpretiert. Obwohl die Beschreibungsdatei hierin so erörtert wird, dass sie sich in denselben Computersystemen wie der AICP 114 und der AISP 134 befindet, ist für die Fachleute zu erkennen, dass sich die Beschreibungsdatei an jedem vernetzten Ort, auf welchen durch den AICP und den AISP zugegriffen werden kann, befinden kann.
Unter Bezugnahme auf 2 und 4 führt der AISP 134 die folgenden Funktionen aus: er sendet den XML-Datenstrom an den AICP 114, liest die Beschreibungsdatei 310 (3) (welche als ein XML-Datenstrom übertragen werden kann), spricht auf Abfragen vom AICP 114 zum Anschluss an Serverkomponenten 136 an, erhält eine zustandsabhängige Verbindung aufrecht und überwacht den Kontext auf dem Webserver 130. Es ist zu erwähnen, dass zu jeder festgelegten Zeit mehrere AISP 134' im Speicher des Webservers 130 vorhanden sein können.
In Verwendung entwirft ein Entwickler unter Bezugnahme auf 5 das Layout der Benutzerschnittstelle 116 (Schritt 710), welche letzten Endes auf der Benutzerarbeitsstation 110 angezeigt wird, und stellt dabei die Beziehungen zwischen den Steuerobjekten 624 (4) und den Serverkomponenten 136 her. Sobald diese Information formuliert ist, wird sie in einer Beschreibungsdatei 310 gespeichert (Schritt 712). Wenn der AICP 114 eine Abfrage zur Ausführung eines Anwendungsprogramms 420 auf dem Webserver 130 überträgt, empfängt der Transaktionsprozessor 430 (2) die Abfrage (Schritt 714), instanziert einen AISP 134 (Schritt 718), welcher mit dem Anwendungsprogramm 420 verbunden ist, wenn im Speicher noch keine Instanz geladen ist, und startet das Anwendungsprogramm 420 (Schritt 720). Sobald der AICP 114 die Beschreibungsdatei 310 empfängt, überträgt er eine Verbindungsabfrage an den AISP 134. Der AISP 134 empfängt die Verbindungsabfrage (Schritt 722) und lädt die Beschreibungsdatei 310, welche mit dem abgefragten Anwendungsprogramm 420 verbunden ist, in den Serverspeicher (Schritt 724).
Die Beschreibungsdatei 310, welche mit dem abgefragten Anwendungsprogramm 420 verbunden ist, wird geladen, um den AICP 114 mit den entsprechenden Serverkomponenten 136 zu verbinden. Die Beschreibungsdatei 310 enthält genügend Information in Bezug auf die Beziehungen zwischen den Steuerobjekten 624 (4) und den Serverkomponenten 136, um zu ermöglichen, dass der AISP 134 die Serverkomponenten verwaltet und der AICP 114 die Steuerobjekte verwaltet.
Beim Laden der Beschreibungsdatei 310 bildet der AISP 134 ein Managerobjekt 452 für jede Serverkomponente 136 (Schritt 726), welche wahrscheinlich an dieser Client/Server-Verbindung beteiligt ist. Zusätzlich wird auch für jede Steuerung, welche auf dem Client instanziert werden könnte, ein eindeutiges Managerobjekt (als das Metaobjekt 454 bezeichnet) erzeugt (Schritt 728). Das Metaobjekt 454 speichert Daten, wie beispielsweise Gliedinformation, Dialoginformation, Verbindungsinformation, Objekt-Objekt-Verbindungsinformation und eine Referenz zu einer Client-Managerkomponente, um die Steuerobjekte 624 effektiv mit den Serverkomponenten 136 zu verbinden.
Die Gliedinformation umfasst Eigenschaften, Funktionen und Ereignisse, welche an der Schnittstelle eines Steuerobjekts verfügbar sind. Diese Information wird verwendet, um einer Verbindungsbehandlungsroutine 450 mitzuteilen, wie sie mit bestimmten Steuerobjekten (sowie Serverkomponenten), die an der Verbindung beteiligt sind, während der Ablaufzeit kommunizieren soll. Die Dialoginformation ist die GUI-Layoutinformation, welche durch den AICP 114 verwendet wird, um die Benutzerschnittstelle 116 auf der Benutzerarbeitsstation 110 aufzubereiten. Die Dialoginformation gibt auch die Art von Steuerobjekt 624 oder Serverkomponente 136, welche an der Verbindung beteiligt sind, an. Die Verbindungsinformation beschreibt die Art und Weise, wie ein bestimmtes Steuerobjekt 624 mit einer bestimmten Serverkomponente 136 verbunden wird. Die Objekt-Objekt-Verbindungsinformation stellt eine Verbindungsbeschreibung bereit, welche eine Verbindung Client-Serverkomponente und eine Verbindung Serverkomponente-Serverkomponente ermöglicht. Dies erlaubt Serverkomponenten, miteinander zu kommunizieren, ohne irgendwelche bestimmten Einzelheiten der Objekte, mit welchen sie verbunden sind, zu kennen.
Die Client-Managerkomponente stellt eine Standardschnittstelle bereit, welche es dem AISP 134 erlaubt, mit dem Back-End-Anwendungsprogramm 420 zu kommunizieren. Der Client-Manager ist eine Komponentenschnittstelle, welche durch das Serveranwendungsprogramm 420 eingebaut werden muss, um das Verhalten des AICPs 114 zu initialisieren. Die Komponentenschnittstelle des Client-Managers umfasst in einer Ausführungsform vier Funktionen: ClientCanConnect(), ClientCanDisconnect(), ClientConnected() und ClientDisconnected(). Diese Funktionen werden abgerufen, wann immer ein neuer AICP 114 mit einem Anwendungsprogramm 420 auf dem Webserver 130 verbunden oder davon getrennt werden möchte.
Wenn ein Dialog im AICP 114 erzeugt wird, wird der AISP 134 benachrichtigt, dass er einen physischen Anschluss zu der relevanten Instanz der Serverkomponente 136 auf dem Server 130 erzeugen muss. Um diesen physischen Anschluss herzustellen, ordnet der AISP 134 die Objektsteuerungen an der Benutzerschnittstelle 116 den Serverkomponenten 136 zu (Schritt 732). Die Dialogbeschreibung der Serverkomponente 136 kann im Metaobjekt 454 gefunden werden. An dieser Stelle erhält der AISP 134 den Namen des Dialogs, welcher auf dem AICP 114 zu erzeugen ist, und erhält Zugriff auf eine Instanz der Serverkomponenten 136. Eine Verbindungsbehandlungsroutine 450 wird für jede Steuerung, welche eine Verbindung mit einem Teil der Serverkomponenteninstanz benötigt, instanziert. Die Verbindungsbehandlungsroutine 450 initialisiert die Verbindung zwischen dem Steuerobjekt 624 und der Serverkomponente 136 und erhält sie aufrecht. Nur Verbindungsbehandlungsroutinen 450, welche als „run on the Server" (laufen auf dem Server) gekennzeichnet sind, würden an dieser Stelle erzeugt werden. Wären sie als „run on the client" (laufen auf dem Client) gekennzeichnet, hätte der AICP 114 bereits eine erzeugt. Der Verbindungsbehandlungsroutine 450 wird ein Identifizierer 618 (4) zugewiesen, welcher mit jenem identisch ist, welcher für das Steuerobjekt 624 des AICPs 114 bereitgestellt wird. Dieser Identifizierer 618 wird verwendet, um die Informationsmeldungen, welche zwischen dem AICP 114 und dem AISP 134 hin- und hergehen, zu synchronisieren.
Ähnlich dem Dialogobjekt, welches im AICP-Abschnitt beschrieben wurde, bildet der Server ein clientseitiges Proxy-Objekt 456 (Schritt 730), welches Meldungen arbitriert, die zwischen der Client-Seite der Serververbindung und dem AICP 114 hin- und hergeschickt werden. Die Verbindungsbehandlungsroutine 450 kommuniziert mit diesem Proxy-Objekt 456, als ob es das Steuerobjekt 624 selbst wäre. Das Proxy-Objekt 456 überträgt einen Wert für das Steuerobjekt 624 an den AICP 114, welcher wiederum das Steuerobjekt 624 an der Benutzerschnittstelle 116 modifiziert. Auf diese Weise kann das Proxy-Objekt 456 Anfangszustandsinformation an den AICP 114 übertragen (734), sowie den AICP 114 mit Zustandsänderungen 330 einer bestimmten Serverkomponenten 136 auf dem Server 130 aktualisieren (Schritt (738). Auf ähnliche Weise wird, wenn sich der Steuerzustand 622 eines Steuerobjekts 624 auf dem AICP 114 ändert, der modifizierte Steuerzustand über das Proxy-Objekt 456 (unter Verwendung des Steuerungsidentifizierers 618, welcher diesem konkreten Steuerobjekt 624 zugewiesen ist) an den AISP gesendet. Sobald der modifizierte Steuerzustand durch das Proxy-Objekt 456 empfangen wurde, benachrichtigt das Proxy-Objekt 456 die Verbindungsbehandlungsroutine 450 davon, dass sich der Zustand des Steuerobjekts geändert hat, so dass der modifizierte Zustand in die entsprechende Serverkomponente 136 eingefügt werden kann.
Ähnlich dem AICP 114 erhält der AISP 134 die Verbindung für die Dauer des Dialogs aufrecht (Schritt 736). Wenn der Dialog durch den Benutzer oder auf irgendeine andere Weise (z. B. eine Benachrichtigung durch eine Serverkomponente, alle damit verbundenen Dialoge zu beenden) beendet wird, entfernt und löscht der AISP 134 jede der Verbindungsbehandlungsroutinen 450, welche mit der Verbindung mit dem Dialog verbunden ist. Außerdem werden auch die Proxy-Objekte 456, welche verwendet werden, um als Vertreter der Steuerobjekte 624 zu übertragen, verworfen.
Der AISP 134 verwendet einen Komponentenmanager (nicht dargestellt), um eine Liste von Komponenten aufrechtzuerhalten, welche an clientseitigen Verbindungen beteiligt sind. Der Komponentenmanager ist über alle Dialoge auf dem Laufenden, welche für die Dauer des Dialogs aktiv an die Serverkomponenten angeschossen sind. Immer wenn auf einem AICP 114 ein Dialog erzeugt wird, wird der Liste, welche durch den Komponentenmanager geführt wird, eine Referenz zu diesem Dialog hinzugefügt. Diese Referenz identifiziert alle serverseitigen Verbindungsbehandlungsroutinen, welche wiederum auf die Steuerungsproxys hinweisen, welche an einer Verbindung beteiligt sind. Wenn ein Dialog beendet wird, konsultiert der AISP 134 diese Liste, um die Dialogverbindungsinformation zu suchen, und entfernt die Dialogreferenz aus der Liste.
Obwohl der AICP 114 und der AISP 134 verschiedene Rollen spielen, ist vieles von ihren jeweiligen Codes identisch. Der Schlüssel dafür, den AICP und den AISP beinahe identisch zu machen, liegt in der Bereitstellung einer Standardobjektschnittstelle, welche die Steuerobjekte 624 auf dem AICP 114 mit den Serverkomponenten 136 auf dem AISP 134 verbindet. Die Interpretierlogik der anwendungsunabhängigen Prozesse kann die jeweiligen Seiten (Client oder Server) auf genau dieselbe Weise (durch eine Standardobjektschnittstelle) miteinander verbinden. Die Tatsache, dass das Steuerobjekt visuell ist, ist nur ein Nebeneffekt der Realisierung des Objekts. Die vorliegende Erfindung kann daher auf etliche Realisierungen angewendet werden, welche keine visuelle Darstellung benötigen.
Unter neuerlicher Bezugnahme auf 4 kann sich der AICP 114 im Speicher der Benutzerarbeitsstation 110 befinden. Der Speicher enthält auch das Betriebssystem 612, welches in der Benutzerarbeitsstation 110 eingebaut ist, und das Webbrowser- Anwendungsprogramm 112, in dem der AICP 114 gestartet wird. Der AICP 114 führt die folgenden Funktionen aus: er liest die Datenbeschreibungsdatei 310, bereitet die Benutzerschnittstelle 116 auf, schließt verbundene Steuerungen an, erhält eine zustandsabhängige Verbindung aufrecht und überwacht den Kontext auf dem Client.
Unter Bezugnahme auf 6 wird ebenfalls zuerst der AICP 114 in der Benutzerarbeitsstation 110 installiert. Das üblichste Installationsverfahren ist die manuelle Installation des AICPs 114 durch die Systeminstallationsprozedur (z. B. beim Betriebsystem von Microsoft Windows unter Verwendung der Funktion „Add/Remove Programs"). Alternativerweise kann der AICP 114 durch ein webbasiertes Plug-In-Protokoll automatisch installiert werden.
Da auf dem Client kein Code vorhanden ist, welcher das Anwendungsprogramm 420 darstellt, unterstützt der AICP 114 etliche Lösungen beim Herstellen der Anfangsverbindung mit dem serverseitigen Anwendungsprogramm 420. Die Information, welche durch den AICP 114 benötigt wird, um mit dem Anwendungsprogramm 420 zu kommunizieren, umfasst: den Namen des auszuführenden Server-Prozesses, den Standort der Beschreibungsdatei 310 auf einem Netzserver, alle Ausgangsargumente, welche bei Verbindung an das Anwendungsprogramm 420 übertragen werden müssen, und die aktuelle Version der Beschreibungsdatei. Diese Information kann in einer Initialisierungsdatei enthalten sein, welche geladen wird, wenn der AICP 114 gestartet wird.
Wenn der AICP 114 gestartet wird, greift er auf die Initialisierungsdatei zu (Schritt 810) und überträgt unter Verwendung der darin enthaltenen Information eine Abfrage zur Ausführung des gewünschten Anwendungsprogramms 420 an den Server 134. Wie bereits erwähnt, sendet der Transaktionsprozessor 430 auf dem Server 130 eine Beschreibungsdatei 310 an den AICP 114, welcher dann den Versionsstempel der Beschreibungsdatei, die er empfängt, mit dem vergleicht, der im lokalen Speicher 610 der Benutzerarbeitsstation 110 enthalten ist (und von einer früheren Transaktion oder während der Installation des AICPs 114 erhalten wurde). Der AICP 114 kann dann bestimmen (Schritt 812), welche Version der Beschreibungsdatei 310 er lädt. Standardmäßig lädt der AICP 114 nur die Beschreibungsdatei 310 vom Transaktionsprozessor 430 herunter, wenn der Versionsstempel der Datei auf dem Server jüngeren Datums ist als eine zwischengespeicherte Datei, welche sich bereits auf dem Client befindet. Die Beschreibungsdatei 310 wird nur durch ein bestimmtes Anwendungsprogramm 420 benutzt.
Sobald die Beschreibungsdatei 310 heruntergeladen (oder von einem Dateizwischenspeicher lokal geladen) ist, versorgt sie den AICP 114 mit der Dialogbeschreibung des Anwendungsprogramms 420. Der AICP 114 nimmt dann die Interpretation der Beschreibungsdaten dieses Dialogs vor (Schritt 814), um die Steuerobjekte 624 aufzubauen, welche innerhalb des Dialogs bestehen, und die Steuerobjekte 624 an der Benutzerschnittstelle 116 zur Darstellung für den Benutzer zu gestalten.
Unterdessen überträgt der AICP 114 eine Abfrage zur Herstellung einer logischen Verbindung mit den Serverkomponenten 36 an den AISP 134 (Schritt 816). Bei erfolgreicher Verbindung mit den Serverkomponenten 136 auf dem Server 130 empfängt der AICP 114 die Dialogsteuerobjekte 624 und besetzt sie anschließend mit der Steuerzustandinformation 622, welche dem Serverkomponentenzustand 442 entspricht (Schritt 818).
Zustandsänderungen für einen bestimmten visuellen Kontext (z. B. einen Dialog) werden aus Optimierungsgründen als ein logisches Paket an den AICP 114 gesendet, obwohl die Struktur des Zustandsänderungspakets ungeachtet dessen, ob eine einzige Zustandsänderung oder eine Mehrzahl von Zustandsänderungen auftritt, identisch ist. An dieser Stelle werden die Steuerobjekte 624 aktiv mit den Serverkomponenten 136 verbunden, so dass Zustandsänderungen auf jeder Seite auf der anderen wiedergegeben werden. Sobald die Steuerobjekte 624 den aktuellen Serverkomponentenzustand 442 wiedergeben, wird dann der Dialog über die Benutzerschnittstelle 116 dem Benutzer angezeigt (Schritt (820).
Die Steuerobjekte 624 werden durch eine Referenzeigenschaft, welche als Teil der Beschreibung des Steuerobjekts 624, der in der gesamten Dialoglayoutbeschreibung enthalten ist, bereitgestellt wird, mit den Serverkomponenten 136 verbunden. Diese Referenz kann der Name, welcher der Verbindungsbeschreibung zugewiesen wurde, und die Art der verbundenen Serverkomponente 136 sein. Ein eindeutiger Steuerungsidentifizierer 618 wird für jedes der Steuerobjekte 624, welche mit den Serverkomponenten 136 verbunden sind, berechnet. Dieser Steuerungsidentifizierer 618 wird verwendet, um die Zustandsänderungen 330 mit dem AISP 134 beim Verbinden mit der entsprechenden Serverkomponenteninstanz, welche diesem Steuerobjekt 624 zugewiesen wird, zu koordinieren. Es ist zu erwähnen, dass viele Steuerobjekte an dieselbe Serverkomponente 136 gebunden werden können.
Da der AICP 114 und der AISP 134 zum Großteil identische Prozesse sind, können sich einige der Verbindungen auf dem Client befinden. Manchmal ist es nützlich, die Verbindungslogik, welche ein Steuerobjekt 624 des Clients an eine Anwendungskomponente 136 des Servers auf dem AICP 114 oder dem AISP 134 bindet, zu instanzieren. Die Wahl dessen, wo die Verbindungslogik instanziert wird, hängt vom Volumen des Informationsflusses, welcher in jede Seite der Verbindung kommt, ab. Wenn zum Beispiel die Belastung auf der Clientseite am stärksten ist, dann ist es besser, die Verbindungsbehandlungsroutine auf dem Client zu instanzieren. Auf diese Weise kann die Bandbreitennutzung basierend auf der Verbindungsart, sowie dem Client und den Serverkomponenten, die beteiligt sind, angepasst werden.
Solange ein Dialog auf einem bestimmten AICP 114 angezeigt wird, erhalten die Verbindungsbehandlungsroutinen 450 eine zustandsabhängige Echtzeitverbindung mit den verbundenen Serverkomponenten 136 aufrecht (Schritt 822). Die Verbindungsbehandlungsroutine 450 spricht entweder auf Zustandsänderungen beim Clientsteuerobjekt 624 oder seiner zugehörigen Serverkomponente 136 an. Die Verbindungsbehandlungsroutine 450 ist auch imstande, die Daten, welche auf einem Satz von Regeln basieren, die durch den Entwickler definiert werden, umzuwandeln. Die Verbindungsbehandlungsroutine 450 ist imstande, den Zustand auf jeder Seite der Verbindung durch Aufrechterhalten von Referenzen zu den Steuerobjekten 624, welche an der Verbindung beteiligt sind, aufrechtzuerhalten (Schritt 822).
Die Verbindungsbehandlungsroutine 450 erhält auch eine zustandsabhängige Verbindung aufrecht, wann immer sich ein Glied einer komplexen Komponente ändert. Dies geschieht, wenn eine Eigenschaft (welche ein Glied einer komplexen Komponente ist, welche einen Wert einer bestimmten Art enthalten oder leer sein kann) einer komplexen Steuerung einem neuen Wert (welcher selbst eine komplexe oder einfache Komponente sein kann) zugewiesen wird. Wenn die Verbindungsbehandlungsroutine 450 eine Eigenschaftsänderung feststellt, führt sie die entsprechende Verbindungsumwandlung aus. Wenn außerdem ein Steuerobjekt 624 an diese Eigenschaft angeschlossen wurde, würde es nicht mit dem neuen Wert verbunden werden. Die beteiligte Verbindungsbehandlungsroutine würde die Referenz zu dem alten Wert entfernen und eine Referenz zu dem neu zugewiesenen Wert (der Eigenschaft) erzeugen. Auf diese Weise werden die Steuerobjekte 624 mit Zustandsänderungen 330, welche vom AISP 134 empfangen werden, aktualisiert (Schritt 824), und die Zustandsänderungen, welche in einem Steuerobjekt 624 auftreten, werden an den AISP 134 übertragen, um die entsprechenden Serverkomponenten 136 zu aktualisieren (Schritt 826).
Eine GUI-Anwendung bringt mehrere Beziehungen mit sich, welche den Benutzerzugriff auf die zu Grunde liegende Anwendung beschreiben. Zum Beispiel kann ein Dialog eine Taste (welche ein Beispiel für ein Steuerobjekt ist) enthalten, die, wenn ausgewählt, einen anderen Dialog einblendet. Es ist für den AICP 114 und den AISP 134 wichtig, diesen Kontext mit den Serverkomponenten 136 aktiv aufrechtzuerhalten. Ein Einblenddialog stellt normalerweise ein komplexes Eigenschaftsglied einer komplexen Komponente dar. Ein anderes Einblendszenarium ist, wenn der Einblenddialog ein Argument für eine Funktion bereitstellt, welche ein Glied einer komplexen Komponente ist. Diese Datenbeziehungen 446 stellen den Anwendungskontext dar, welcher durch den AIP überwacht wird, wodurch der Entwickler davon befreit wird, sie ausdrücklich erzeugen und aufrechterhalten zu müssen.
Der AICP 114 erzeugt ein Container-Objekt für jeden Dialog, welcher auf der Benutzerarbeitsstation 110 erzeugt wird. Dieses Container-Objekt überwacht die Dauer des Dialogs in Bezug auf die Serverkomponente 136. Das Container-Objekt stellt fest, wenn der Dialog durch den Benutzer beendet wird, und ergreift die entsprechende Maßnahme, um die Verbindungsbehandlungsroutinen 450, welche mit den Steuerobjekten 624 innerhalb des Dialogs verbunden sind, abzuschließen. Das Container-Objekt koordiniert auch die Verarbeitung von Zustandsänderungsmeldungen, welche zwischen dem AICP 114 und dem AISP 134 hin- und herfließen. Wann immer das Container-Objekt eine Zustandsänderung 330 vom AISP 134 empfängt, entnimmt es den Steuerungsidentifizierer 618, welcher in der Meldung enthalten ist, lokalisiert die Steuerobjekte 624, welche mit diesem Steuerungsidentifizierer 618 verbunden sind, und verwendet die Komponentenschnittstelle des Steuerobjekts 624, um die Zustandsänderung direkt am Steuerobjekt 624 durchzuführen. Gleichermaßen wird, wenn das Steuerobjekt 624 den Zustand ändert, das Container-Objekt von der Änderung benachrichtigt, und es verdichtet die Zustandsänderungsmeldung und sendet sie an den AISP 134.
Das Container-Objekt sendet Zustandsänderungen an den AISP 134 für die Teile der Schnittstelle des Steuerobjekts, an welchen die Verbindungsbehandlungsroutine 450 interessiert ist. Die Verbindungsbehandlungsroutine 450 ist an den Steuergliedern interessiert, die in der Beschreibungsdatei 310 dargestellt sind und die verwendet wurden, um die Verbindungsbehandlungsroutine 450 zu erzeugen. Das Container-Objekt, welches den Dialog umhüllt, erzeugt auch ein Container-Objekt für jedes Steuerobjekt 624, welches innerhalb des Dialogs instanziert wird, um seine zustandsabhängige Lebensdauer aufrechtzuerhalten.
Sowohl der AICP 114 als auch der AISP 134 weisen Container-Objekte auf, welche den Zustand der Komponenten verwalten, mit welchen sie verbunden sind. Diese Container überwachen den Zustand der Objekte, sowie den Anwendungskontext, in welchem sich diese Objekte befinden. Der Anwendungskontext bezieht sich auf die Art und Weise, auf welche durch den AICP 114 und den AISP 134 auf Objekte Bezug genommen wird. Wenn zum Beispiel ein Dialog mit einer Serverkomponente 136 verbunden wird, erzeugt der AICP 114 einen Container für den Dialog, und der AISP 134 erzeugt einen Container für die Serverkomponente 136. Wenn der Benutzer den Dialog beendet, stellt der Client-Container diese Handlung fest und benachrichtigt den Server-Container. Jeder Container kann basierend auf der Art von Operation die entsprechende Maßnahme ergreifen. Die Beschaffenheit der Container ist hierarchisch, in dem jeder Container basierend auf der Komplexität der Objekte, welche an einer bestimmten Verbindung beteiligt sind, andere Container enthalten kann.
Es gibt zwei Arten von Client-Containern – einen Dialog-Container und einen Steuerungscontainer. Der Dialog-Container verwaltet die Lebensdauer des Dialogs, und der Steuerungscontainer verwaltet den Fluss von Zustandsinformation zur einzelnen Steuerung. Diese Container ermöglichen den Anschluss der Benutzerschnittstellenelemente an serverseitige Objekte und erhalten die Zustandsintegrität während der Lebensdauer der Verbindung aufrecht.
Der Dialog-Container ist ein Objekt, welches für jedes Fenster erzeugt wird, das auf der Benutzerschnittstelle 116 angezeigt wird. Der Dialog-Container wird gemäß der XML-Beschreibung in der Beschreibungsdatei 310 erzeugt. Der Dialog-Container verarbeitet die XML-Beschreibung und erzeugt das Dialoglayout, sowie die Steuerobjekte, welche in der Beschreibung enthalten sind. Außerdem erzeugt der Dialog-Container einen Steuerungscontainer für jede Steuerung, welche mit Daten auf dem Server verbunden ist. Steuerungen, welche nur zu Anzeigezwecken erzeugt werden, brauchen keinen Steuerungscontainer (zum Beispiel eine Etikett- oder eine Bitmap-Ausschmückung).
Der Dialog-Container unterstützt mehrere Funktionen, welche umfassen: Aufbereiten des Fensters selbst, Erzeugen der Steuerungscontainer je nach Bedarf, Benachrichtigen des AISPs 134, wenn der Dialog beendet wird, und Löschen von untergeordneten Steuerungs-Container-Objekten und gegebenenfalls Schließen von Kind-Dialogen, welche von Eltern-Dialogen abhängigen.
Der Steuerungscontainer wird für jedes Steuerobjekt 624, welches an Daten gebunden ist, erzeugt. Der Steuerungscontainer errechnet und enthält einen eindeutigen Steuerungsidentifizierer 618, welcher verwendet wird, um Meldungen an den AISP 134 zu senden und auf die entsprechenden Serverkomponenten 136 zuzugreifen. Wenn der AISP 134 anfänglich Zustandsdaten an den AICP 114 überträgt, stellt der Steuerungscontainer den Zustand am Steuerobjekt 624 während der Initialisierung ein. Der Steuerungscontainer empfängt auch Zustandsänderungsmeldungen während der Verbindungslebensdauer des Steuerobjekts 624 und aktualisiert das Steuerobjekt 624 dementsprechend. Wenn sich der Zustand des Steuerobjekts 624 ändert, stellt der Steuerungscontainer die Änderung fest und sendet eine Zustandsänderungsmeldung über den AISP 134 an das entsprechende Serverelement (unter Verwendung des Steuerungsidentifizierers 618 und eines Identifizierers der AISP-Instanz). Es ist erwähnenswert, dass nur der Steuerungscontainer die Zustandsänderungen verarbeitet, welche an einer Verbindungsbeschreibung beteiligt sind, und dass die meisten Zustandsänderungen am Steuerobjekt 624 die Verbindung nicht einbeziehen, weshalb unnötiger Netzverkehr reduziert wird.
Zusätzlich zu den Steuerungscontainern gibt es zwei Arten von Server-Containern – Komponenten-Container und Glieder-Container. Solange der Client-Dialog geöffnet ist, erhält der Serverkomponenten-Container eine Referenz zu der zu Grunde liegenden Instanz, mit welcher der Client verbunden ist, aufrecht. Der Glieder-Container verwaltet den Fluss von Zustandsinformation über das einzelne Glied der Komponente (ähnlich der Funktion und Eigenschaft). Diese Container ermöglichen den Anschluss der Benutzerschnittstellenglieder an clientseitige Steuerobjekte und erhalten die Zustandsintegrität während der Lebensdauer der Verbindung aufrecht.
Ein Komponenten-Container wird durch den AISP 134 für jede Serverkomponente 136 erzeugt, welche mit einem Client-Dialog verbunden ist. Der Komponenten-Container fügt eine Referenzzählung zur Serverkomponente 136 hinzu, so dass sie während der Lebensdauer des entfernten Client-Dialogs nicht verloren geht. Für jedes Glied der Serverkomponente 136, welches an einer Verbindung mit einem Steuerobjekt 624 beteiligt ist, wird ein Glieder-Container-Objekt erzeugt, welches für die Aufrechterhaltung des Zustands des Gliedes während der Lebensdauer der Verbindung verantwortlich ist. Wenn der Dialog auf dem Client beendet wird, zerstört der Komponenten-Container alle Kind-Glieder-Container, welche verwendet wurden, um die Verbindung dieses Dialogs auf dem Server aufrechtzuerhalten.
Ein Glieder-Container wird für jedes Glied einer Serverkomponente 136 erzeugt, welches an einer Verbindung mit einem Steuerobjekt 624 beteiligt ist. Der Glieder-Container errechnet und speichert einen eindeutigen Steuerungsidentifizierer, welcher verwendet wird, um Meldungen an den AICP 114 zu senden, um auf das korrekte Steuerobjekt 624 zuzugreifen. Der Glieder- Container sendet während der Initialisierung des Dialogs auch Anfangszustandsinformation an das Steuerobjekt 624. Außerdem empfängt der Glieder-Container Datenänderungsmeldungen vom AICP 114 und aktualisiert das entsprechende Glied der Serverkomponente 136 demgemäß.
Wann immer sich der Zustand des Komponentenglieds ändert, stellt der Glieder-Container die Änderung fest und schickt anschließend eine Meldung, welche die Zustandsänderungsinformation enthält, an das entsprechende Steuerobjekt 624 (unter Verwendung des Steuerungsidentifizierers 618 und des Serverinstanzidentifizierers). Es ist erwähnenswert, dass nur der Glieder-Container die Zustandsänderungen verarbeitet, welcher an der Verbindungsbeschreibung beteiligt ist, und dass die meisten Zustandsänderungen auf dem Server nicht an einer Verbindung beteiligt sind, weshalb unnötiger Netzverkehr reduziert wird.
Eine der Fähigkeiten der AIP-Erfindung ist ihr Vermögen, mehreren AICP zu erlauben, an denselben AISP angeschossen zu werden. Das erste Mal, wenn ein Client eine Verbindung mit einem Server anfordert, wird ein AISP instanziert, welcher der Anwendung zugewiesen ist. Der AISP wiederum instanziert das Client-Manager-Objekt für diese Anwendung. Ein anderer Client kann jederzeit anfordern, an dieselbe Anwendungsinstanz auf dem Server angeschlossen zu werden. Anstatt einen anderen AISP für diese Anwendung zu instanzieren, wird dieselbe AIP-Instanz (sowie der Client-Manager, der für sie erzeugt wurde) verwendet. Wenn dann zwei Clients auf dieselbe Serverkomponenteninstanz auf dem Server zugreifen, sind sie imstande, zu kommunizieren und auf denselben Zustand zuzugreifen. Dies erlaubt gemeinsamen Echtzeitzugriff auf einen geteilten Zustand, der mit herkömmlichen Formen des Client-Einsatzes nicht leicht bereitgestellt wird.
Bei gemeinsamem Einsatz wird eine Liste von Dialogen, welche auf einem bestimmten Client ablaufen, mit einem Client-Manager-Objekt verbunden, welches sich auf dem Server befindet. Eine Liste von Client-Managern befindet sich innerhalb des AISPs (welche die aktuelle Anzahl von aktiven Clients wiedergibt, die an dieselbe Serveranwendung angeschlossen sind). Selbst wenn viele Clients dieselbe Information auf dem Server sehen können, haben sie nicht immer genau dieselben Komponenten auf dieselbe Weise zu betrachten. Der Client-Manager kann verschiedene Clients so lenken, dass sie verschiedene Dialogdarstellungen derselben Serverkomponenten aufweisen. Basierend auf der Navigation der Client-Benutzer durch ihre eigenen Dialoginstanzen kann jeder Client-Benutzer zu jeder festgelegten Zeit auch eine völlig verschiedene Information sehen.
Die vorliegende Erfindung kann als ein oder mehr computerlesbare Programme, welche auf oder in einem oder mehreren Fertigfabrikaten enthalten sein können. Das Fertigfabrikat kann eine Diskette, eine Festplatte, eine CD-ROM, eine Flash-Speicherkarte, ein PROM, ein RAM, ein ROM oder ein Magnetband sein. Im Allgemeinen können die computerlesbaren Programme in jeder Programmiersprache verwirklicht werden. Einige Beispiele für Sprachen, welche verwendet werden können, umfassen C, C++ oder JAVA. Die Software-Programme können auf oder in einem oder mehreren Fertigfabrikaten als Objektcode gespeichert werden.
Obwohl die Erfindung insbesondere unter Bezugnahme auf mehrere beispielhafte Ausführungsformen davon dargestellt und beschrieben wurde, versteht es sich für die Fachleute von selbst, dass verschiedene Änderungen in Form und Detail daran vorgenommen werden können, ohne sich vom Rahmen der Erfindung, wie beansprucht, zu entfernen.

Claims

Verfahren zur Übertragung von Daten zwischen einem Client (110) und einem Server (130), welches die folgenden Schritte umfasst: Ausführen durch einen Server-Knoten (130) eines Anwendungsprogramms (132), welches eine Serverkomponente (136), die einem Element der grafischen Benutzerschnittstelle entspricht, beeinflusst; Bereitstellen eines anwendungsunabhängigen Client-Prozesses (114), wobei der anwendungsunabhängige Client-Prozess (114) eine Anzeige eines oder mehrerer Elemente der grafischen Benutzerschnittstelle auf dem Client (110), welcher mit dem Anwendungsprogramm (132) verbunden ist, beeinflusst; Bereitstellen eines anwendungsunabhängigen Server-Prozesses (134), wobei der anwendungsunabhängige Server-Prozess (134) Daten (310) an den anwendungsunabhängigen Client-Prozess (114) überträgt und die übertragenen Daten (310) für eine Änderung einer der Anwendungskomponenten (136), welche durch das Anwendungsprogramm (132) beeinflusst werden, repräsentativ sind; und Aktualisieren durch den anwendungsunabhängigen Client-Prozess (114) eines der Elemente der grafischen Benutzerschnittstelle auf dem Client (110) als Reaktion auf die übertragenen Daten (310).
Verfahren nach Anspruch 1, welches des Weiteren Übertragen von Daten (330) vom anwendungsunabhängigen Client-Prozess (114) an den anwendungsunabhängigen Server-Prozess (134) umfasst, wobei die übertragenen Daten für eine Änderung eines der Elemente der grafischen Benutzerschnittstelle repräsentativ sind.
Verfahren nach Anspruch 1, welches des Weiteren Herstellen eines Kommunikationskanals (120) zwischen dem anwendungsunabhängigen Client-Prozess (114) und dem anwendungsunabhängigen Server-Prozess (134) umfasst.
Verfahren nach Anspruch 3, wobei der Kommunikationskanal (120) asynchron ist.
Verfahren nach Anspruch 1, welches des Weiteren Zugreifen durch den anwendungsunabhängigen Client-Prozess (114) auf eine Beschreibungsdatei (310) umfasst, welche (i) eine Layoutbeschreibung der Elemente der grafischen Benutzerschnittstelle und (ii) eine Verbindungsbeschreibung zwischen den Elementen der grafischen Benutzerschnittstelle und der entsprechenden Anwendungskomponente (136) umfasst.
Verfahren nach Anspruch 5, wobei die Beschreibungsdatei (310) im XML-Format ist.
Verfahren nach Anspruch 1, welches des Weiteren Erzeugen durch den anwendungsunabhängigen Client-Prozess (114) einer Instanz eines Steuerobjekts (624) für jedes Element der grafischen Benutzerschnittstelle umfasst, wobei die Steuerobjektinstanz (624) das Element der grafischen Benutzerschnittstelle darstellt.
Verfahren nach Anspruch 7, bei welchem die Anwendungskomponente (136) ein oder mehrere Glieder umfasst, wobei jedes Glied für ein Attribut der Anwendungskomponente (136) repräsentativ ist, die durch einen Benutzer änderbar oder dem Benutzer anzeigbar ist, und welches des Weiteren Erzeugen einer Instanz von Management-Code (452) durch den anwendungsunabhängigen Server-Prozess (134) umfasst, wobei die Management-Code-Instanz (452) die Korrespondenz zwischen dem Steuerobjekt (624) und dem Anwendungskomponentenglied zuordnet.
Verfahren nach Anspruch 8, welches des Weiteren Erzeugen eines Container-Objekts für jede Anwendungskomponente (136) und jedes Steuerobjekt (624) umfasst.
Verfahren nach Anspruch 9, welches des Weiteren umfasst: Überwachen wenigstens des Anwendungskomponentenglieds oder des Steuerobjekts (624); und Übertragen von Daten als Reaktion einer Zustandsänderung wenigstens des verbundenen Anwendungskomponentenglieds oder des Steuerobjekts (624).
Verfahren nach Anspruch 9, welches des Weiteren umfasst: Erzeugen eines eindeutigen Identifizierers wenigstens für das Anwendungskomponentenglied oder das Steuerobjekt (624); und Speichern des eindeutigen Identifizierers in einer Proxy-Schicht.
System zur Übertragung von Daten zwischen einem Client (110) und einem Server (130), umfassend: einen Server-Knoten (130), welcher umfasst: ein Anwendungsprogramm (132), welches wenigstens eine Anwendungskomponente (136) umfasst; und einen anwendungsunabhängigen Server-Prozess (134) in Kommunikation mit dem Anwendungsprogramm (132), wobei der anwendungsunabhängige Server-Prozess (134) eine Zustandsänderung der Anwendungskomponente (136) feststellt; und einen Client-Knoten (110), welcher umfasst: einen anwendungsunabhängigen Client-Prozess (114) in Kommunikation mit dem anwendungsunabhängigen Server-Prozess (134), wobei der anwendungsunabhängige Client-Prozess (114) als Reaktion auf den Empfang von übertragenen Daten (310) vom anwendungsunabhängigen Server-Prozess (134), wobei die Daten als Reaktion auf die festgestellte Zustandsänderung der Anwendungskomponente (136) übertragen werden, ein Element der grafischen Benutzerschnittstelle auf dem Client-Knoten (110) aktualisiert, wobei das Element der grafischen Benutzerschnittstelle der Anwendungskomponente (136) entspricht.
System nach Anspruch 12, wobei der anwendungsunabhängige Client-Prozess (114) eine Änderung der grafischen Benutzerschnittstelle feststellt und als Reaktion auf die festgestellte Änderung Daten (330) an den anwendungsunabhängigen Server-Prozess (134) überträgt; und wobei der anwendungsunabhängige Server-Prozess (134) als Reaktion auf die empfangenen Übertragungsdaten (330) die Anwendungskomponente (136) aktualisiert.
System nach Anspruch 12, welches des Weiteren einen Kommunikationskanal (120) umfasst, welcher den Server-Knoten (130) mit dem Client-Knoten (110) verbindet, wobei der anwendungsunabhängige Client-Prozess (114) und der anwendungsunabhängige Server-Prozess (134) über den Kommunikationskanal (120) miteinander kommunizieren.
System nach Anspruch 14, wobei der Kommunikationskanal (120) asynchron ist.
System nach Anspruch 12, welches des Weiteren eine Beschreibungsdatei (310) umfasst, welche (i) eine Layoutbeschreibung des Elements der grafischen Benutzerschnittstelle und (ii) eine Verbindungsbeschreibung zwischen dem Element der grafischen Benutzerschnittstelle und der entsprechenden Anwendungskomponente (136) umfasst.
System nach Anspruch 16, wobei die Beschreibungsdatei (310) im XML-Format ist.
System nach Anspruch 12, wobei der anwendungsunabhängige Client-Prozess (114) des Weiteren eine Instanz eines Steuerobjekts (624) für jedes der einen oder mehr Elemente der grafischen Benutzerschnittstelle umfasst und die Steuerobjektinstanz (624) das Element der grafischen Benutzerschnittstelle darstellt.
System nach Anspruch 18, wobei die Anwendungskomponente (136) ein oder mehr Glieder umfasst, wobei jedes Glied ein Attribut der Anwendungskomponente (136) darstellt, die durch den Benutzer änderbar oder dem Benutzer anzeigbar ist; und wobei der anwendungsunabhängige Server-Prozess (134) des Weiteren eine Instanz von Management-Code (452) umfasst und die Management-Code-Instanz (452) die Korrespondenz zwischen dem Steuerobjekt (624) und dem Anwendungskomponentenglied zuordnet.
System nach Anspruch 19, welches des Weiteren ein Container-Objekt für jede Anwendungskomponente (136) und jedes Steuerobjekt (624) umfasst.
System nach Anspruch 20, wobei das Container-Objekt des Weiteren so konfiguriert ist, dass es wenigstens das Anwendungskomponentenglied oder das Steuerobjekt (624), welche mit diesem Container-Objekt verbunden sind, überwacht und als Reaktion auf eine Zustandsänderung wenigstens des verbundenen Anwendungskomponentenglieds oder des verbundenen Steuerobjekts (624) eine Datenübertragung einleitet.
System nach Anspruch 20, welches des Weiteren eine Proxy-Schicht umfasst, um einen eindeutigen Identifizierer für jedes Steuerobjekt (624) zu erzeugen und den eindeutigen Identifizierer in der Proxy-Schicht zu speichern.
Server-Knoten (130) zur Übertragung von Zustandsdaten, umfassend: ein Anwendungsprogramm (132), welches wenigstens eine Anwendungskomponente (136) umfasst; einen anwendungsunabhängigen Server-Prozess (134) in Kommunikation mit dem Anwendungsprogramm (132), wobei der anwendungsunabhängige Server-Prozess (134) eine Zustandsänderung der Anwendungskomponente (136) feststellt und als Reaktion auf eine festgestellte Zustandsänderung der Anwendungskomponente (136) Daten (310) überträgt, wobei die Daten zur Verwendung durch einen Client (110) sind, um ein Element der grafischen Benutzerschnittstelle auf dem Client-Knoten (110) zu aktualisieren, wobei das Element der grafischen Benutzerschnittstelle der Anwendungskomponente (136) entspricht.
Server-Knoten nach Anspruch 23, wobei der anwendungsunabhängige Server-Prozess (134) des Weiteren so konfiguriert ist, dass er die Anwendungskomponente (136) als Reaktion auf die empfangenen Übertragungsdaten (330) aktualisiert, wobei die Daten eine Feststellung einer Zustandsänderung der grafischen Benutzerschnittstelle auf dem Client (110) darstellen.
Server-Knoten nach Anspruch 23, welcher des Weiteren eine Beschreibungsdatei (310) umfasst, welche (i) eine Layoutbeschreibung des Elements der grafischen Benutzerschnittstelle und (ii) eine Verbindungsbeschreibung zwischen dem Element der grafischen Benutzerschnittstelle und der entsprechenden Anwendungskomponente (136) umfasst.
Server-Knoten nach Anspruch 25, wobei die Beschreibungsdatei (310) im XML-Format ist.
Server-Knoten nach Anspruch 23, wobei die Anwendungskomponente (136) ein oder mehrere Glieder umfasst, wobei jedes Glied für ein Attribut der Anwendungskomponente repräsentativ ist, die durch den Benutzer änderbar oder dem Benutzer anzeigbar ist; und wobei der anwendungsunabhängige Server-Prozess (134) des Weiteren eine Instanz von Management-Code (452) umfasst und die Management-Code-Instanz (452) die Korrespondenz zwischen dem Anwendungskomponentenglied und einem Steuerobjekt (624), das sich auf dem Client (110) befindet, zuordnet.
Server-Knoten nach Anspruch 27, welcher des Weiteren ein Container-Objekt für jede Anwendungskomponente (136) umfasst.
Server-Knoten nach Anspruch 28, wobei das Container-Objekt des Weiteren so konfiguriert ist, dass es wenigstens das Anwendungskomponentenglied, welches mit diesem Container-Objekt verbunden ist, überwacht und als Reaktion auf eine Zustandsänderung des verbundenen Anwendungskomponentenglieds eine Datenübertragung einleitet.
Server-Knoten nach Anspruch 28, welcher des Weiteren eine Proxy-Schicht umfasst, um einen eindeutigen Identifizierer für jedes Anwendungskomponentenglied zu erzeugen und den eindeutigen Identifizierer zu speichern.
Client-Knoten (110) zur Anzeige von Anwendungsdaten, welche durch eine Anwendung (132) ausgegeben werden, die auf einem entfernten Server (130) abläuft, wobei der Client-Knoten umfasst: einen anwendungsunabhängigen Client-Prozess (114) in Kommunikation mit dem Server (130), wobei der anwendungsunabhängige Client-Prozess (114) als Reaktion auf den Empfang von übertragenen Zustandsdaten (310), welche eine festgestellte Zustandsänderung der Anwendungskomponente (136) darstellen, ein Element der grafischen Benutzerschnittstelle auf dem Client (110) aktualisiert, wobei das Element der grafischen Benutzerschnittstelle einer Anwendungskomponente (136) der Anwendung (132), welche auf dem Server (130) abläuft, entspricht.
Client-Knoten nach Anspruch 31, wobei der anwendungsunabhängige Client-Prozess (114) des Weiteren so konfiguriert ist, dass er eine Zustandsänderung der grafischen Benutzerschnittstelle feststellt und als Reaktion auf die festgestellte Änderung Daten (330) an den Server (130) überträgt.
Client-Knoten nach Anspruch 31, welcher des Weiteren eine Beschreibungsdatei (310) umfasst, welche (i) eine Layoutbeschreibung des Elements der grafischen Benutzerschnittstelle und (ii) eine Verbindungsbeschreibung zwischen dem Element der grafischen Benutzerschnittstelle und der entsprechenden Anwendungskomponente (136) umfasst.
Client-Knoten nach Anspruch 33, wobei die Beschreibungsdatei (310) im XML-Format ist.
Client-Knoten nach Anspruch 31, wobei der anwendungsunabhängige Client-Prozess (114) des Weiteren eine Instanz eines Steuerobjekts (624) für jedes Element der grafischen Benutzerschnittstelle umfasst und die Steuerobjektinstanz (624) das Element der grafischen Benutzerschnittstelle darstellt.
Client-Knoten nach Anspruch 35, welcher des Weiteren ein Container-Objekt für jedes Steuerobjekt (624) umfasst.
Client-Knoten nach Anspruch 36, wobei das Container-Objekt des Weiteren so konfiguriert ist, dass es das Steuerobjekt (624), welches mit dem Container-Objekt verbunden ist, überwacht und als Reaktion auf eine Zustandsänderung des verbundenen Steuerobjekts (624) eine Datenübertragung einleitet.
Client-Knoten nach Anspruch 36, welcher des Weiteren eine Proxy-Schicht umfasst, um einen eindeutigen Identifizierer für das Steuerobjekt (624) zu erzeugen und den eindeutigen Identifizierer zu speichern.