DE102005013559A1

DE102005013559A1 - Framework zum Generieren und Anpassen einer Benutzer-Oberfläche ohne den Einsatz eines Web-Servers

Info

Publication number: DE102005013559A1
Application number: DE200510013559
Authority: DE
Inventors: Roman Bretz
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2005-03-23
Filing date: 2005-03-23
Publication date: 2006-10-05

Abstract

Die Erfindung betrifft ein Verfahren, eine Vorrichtung und eine Systemanordnung zum Generieren einer Schnittstelle zwischen einer Ziel-Benutzer-Oberfläche (Z) und zumindest einer Computer-implantierten Applikation (A). Mithilfe von HTA-Applikationen kann eine Web-basierte Benutzeroberfläche (B) in eine Ziel-Benutzeroberfläche (Z) für eine Desktop-Applikation umgewandelt werden, ohne dass der Einsatz eines Web-Servers notwendig ist.

Description

Die Erfindung liegt auf dem Gebiet der Benutzer-Oberflächen und betrifft insbesondere ein Verfahren, eine Vorrichtung und eine Systemanordnung zum Generieren einer Schnittstelle zwischen einer Benutzer-Oberfläche und einer computer-implementierten Applikation und Mittel zur Anpassung einer bestehenden Benutzer-Oberfläche an eine weitere Benutzer-Oberfläche. Das heißt, dass die vorliegende Erfindung ein Framework bereitstellt, das ein Generieren der Benutzer-Oberfläche ermöglicht, unabhängig von dem Bereitstellen einer bestimmten Infrastruktur und bestimmter Server.

Besteht die Aufgabe, eine Benutzer-Oberfläche zu entwickeln, so ist man mit den bekannten Werkzeugen aus dem Stand der Technik bisher fast ausnahmslos darauf angewiesen, vorab festzulegen, in welchen informationstechnologischen Umfeld die Applikation laufen soll.

Die Grundlage für das bisherige Vorgehen ist darin zu sehen, dass sich die Mechanismen zur Generierung einer Benutzer-Oberfläche unterscheiden. So werden beispielsweise andere Technologien für die Entwicklung einer Benutzer-Oberfläche für eine Desktop-Applikation eingesetzt, als für die Entwicklung einer web- bzw. HTML-basierten Applikation. Auch besteht ein Problem darin, wenn bereits eine Benutzeroberfläche für eine HTML-basierte Applikation besteht, die Applikation aber nun auch als Desktop-Version verfügbar sein soll. Dann musste bisher eine neue Benutzeroberfläche generiert werden.

Dies hat zur Folge, dass ein und dieselbe Benutzer-Oberfläche für eine Applikation entweder mehrfach entwickelt werden muss, wenn sie auf unterschiedlichen Rechner-Architekturen laufen soll oder, dass ein nicht zu vernachlässigender Aufwand in eine Anpassungsarbeit zwischen unterschiedlichen Oberflächen eingesetzt werden muss. Darüber hinaus ist das bisherige Vorgehen hinsichtlich der verwendeten Ressourcen aufwendiger, insbesondere auch was die weitere Entwicklung und die Pflege der Benutzer-Oberflächen betrifft.

Im Stand der Technik sind zwar Mechanismen bekannt, die eine gewisse Flexibilität bei der Generierung von soft- und/oder hardware-basierten Prozessen bieten, wie insbesondere Java-Applets, Smart-Clients oder ActiveX-Komponenten. Diese Mechanismen können aber die oben aufgezeigten Probleme bei der Generierung von infrastruktur- und/oder web-server-unabhängigen Benutzer-Oberflächen nicht vollständig lösen.

Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, einen Weg aufzuzeigen, mit dem es möglich ist, eine Schnittstelle zwischen einer Benutzer-Oberfläche und einer Applikation zu entwickeln, die unabhängig von einer grundlegenden Rechner-Architektur, der Infrastruktur und dem Einsatz eines Web-Servers ist, und der es weiterhin ermöglicht, eine Adaption einer bestehenden web-basierten Benutzer-Oberfläche an eine weitere Benutzer-Oberfläche, insbesondere an eine Desktop-Oberfläche zu ermöglichen.

Diese Aufgabe wird durch ein Verfahren gemäß dem beiliegenden Verfahrensanspruch gelöst. Des weiteren wird diese Aufgabe durch die nebengeordneten Ansprüche, insbesondere den Vorrichtungs- und dem Systemanordnungs-Anspruch gelöst.

Das vorstehend genannte Problem wird insbesondere durch ein Verfahren zum Generieren einer Schnittstelle zwischen einer Benutzeroberfläche und zumindest einer computer-implementierten Applikation gelöst, wobei das Verfahren folgende Verfahrensschritte umfasst:

– Einlesen einer Befehlsfolge, die zum Generieren einer Benutzeroberfläche bestimmt ist und den Einsatz einer web-basierten Infrastruktur erfordert
– Transformieren der eingelesenen Befehlsfolge in eine Ziel-Befehlsfolge, die dazu bestimmt ist, ein Generieren der Benutzeroberfläche ohne den Einsatz einer web-basierten Infrastruktur über eine Ausführung der Applikation zu instruieren.

In der bevorzugten Ausführungsform umfasst das Verfahren auch noch das Ausführen der Applikation, die über die Ziel-Befehlsfolge gestartet wird.

Ein wesentlicher Vorteil der erfindungsgemäßen Lösung besteht darin, dass eine Benutzeroberfläche für eine Web-Applikation, die bisher stets einen Web-Server umfasst, in einer Benutzeroberfläche für eine andere Web-Applikation oder für eine Desktop-Applikation transformiert werden kann, die keinen Web-Server mehr benötigt.

In der bevorzugten Ausführungsform findet im Vorfeld eine Bestimmung statt, in welcher Umgebung bzw. Infrastruktur die Applikation läuft, für die die Ziel-Benutzer-Oberfläche generiert werden soll. Dies erfolgt vorzugsweise menügesteuert, sodass der Benutzer eine zu bestimmende Rechner-Architektur aus einer Menge von grundsätzlich möglichen Architekturen auswählen kann. Insbesondere kann es sich um eine Client-Server-Architektur und/oder um eine HTTP-basierte bzw. eine web-basierte Architektur handeln, die einen Web-Server umfasst. In anderen Ausführungsformen sind jedoch auch andere Architekturen denkbar.

In einer vorteilhaften Weiterbildung der Erfindung ist es vorgesehen, dass die zu bestimmende Infrastruktur oder Architektur nicht explizit vom Benutzer bestimmt werden muss, sondern dass das Bestimmen der Infrastruktur automatisch erfolgt, indem beispielsweise die Rechner-Infrastruktur kennzeichnende Größen des Betriebssystems erfasst werden, aus denen das Konzept der Rechner-Infrastruktur abgeleitet werden kann.

Wenn die Infrastruktur bestimmt ist, auf der die Applikation läuft, für die die Ziel-Benutzer-Oberfläche generiert werden soll, ist es möglich, die passenden Mechanismen zum Generieren der Ziel-Benutzer-Oberfläche zu bestimmen bzw. anzuwenden.

In einer sich an die Bestimmungsphase anschließenden Generierungsphase wird in einem ersten Schritt eine Befehlsfolge eingelesen, die zum Generieren einer Benutzer-Oberfläche bestimmt ist. Üblicherweise handelt es sich hierbei um eine Oberfläche für eine web-basierte Applikation. Diese Oberfläche kann nun erfindungsgemäß umgewandelt werden, in eine solche, die für eine Desktop-Applikation ausgelegt ist.

Dazu ist es jedoch notwendig, dass die eingelesene Befehlsfolge in eine Ziel-Befehlsfolge transformiert wird. Die Ziel-Befehlsfolge dient als Schnittstelle zu der Applikation und startet diese. Die Applikation wiederum ist zum Generieren der Ziel-Benutzer-Oberfläche – üblicherweise der Desktop-Oberfläche – bestimmt. Anschließend ist es möglich, die Ziel-Befehlsfolge auszuführen. In einer anderen Weiterbildung der Erfindung ist es vorgesehen, die Ziel-Befehlsfolge erst zu einem späteren Zeitpunkt auszuführen. Alternativ ist es auch möglich, nur die Schnittstelle zur Verfügung zu stellen und die Oberfläche nicht zu generieren.

Abhängig von der Rechner-Infrastruktur ist es auch möglich, dass die Ziel-Befehlsfolge nicht auf dem Rechner ausgeführt wird, der die anderen Verfahrensschritte, insbesondere das Transformieren ausführt, sondern auf einem entfernten Rechner. Damit kann die Ziel-Befehlsfolge auch "remote" ausgeführt werden.

Üblicherweise erfolgt dass Einlesen, das Ausführen der Ziel-Befehlsfolge und/oder das Transformieren der eingelesenen Befehlsfolge automatisch. In alternativen Ausführungsformen der Erfindung können diese einzelnen Verfahrensschritte auch durch entsprechende Benutzereingaben halbautomatisch oder ma nuell erfolgen. Damit ist es möglich, weitere Eingaben seitens des Benutzers zu berücksichtigen und das Verfahren insgesamt flexibler zu gestalten.

Das erfindungsgemäße Vorgehen kann zum Einen eingesetzt werden, um eine neue Oberfläche erstmals zu implementieren. Zum anderen kann das Vorgehen eingesetzt werden, um eine bestehende Oberfläche zu adaptieren. Vorzugweise wird eine web-basierte Benutzeroberfläche in eine Benutzeroberfläche für eine Desktop-Applikation umgewandelt, die keine zusätzliche Infrastruktur und nicht zwingend einen Web-Server erfordert. In einer vorteilhaften Weiterbildung der Erfindung wird auch bei dem erfindungsgemäßen Framework ein Web-Server eingesetzt.

Kann man z.B. auf eine bereits existierende Applikation mit einer Web-Oberfläche zurückgreifen, so war es bei den Verfahren nach dem Stand der Technik bisher nicht möglich, diese Oberfläche ohne zusätzlichen Aufwand als Oberfläche z.B. für eine Desktop-Applikation wieder zu verwenden. Für diesen Fall war es bisher notwendig, die gesamte Infrastruktur der Web-Applikation auf dem lokalen Rechner installieren zu müssen. Dies führt nachteiliger Weise zu einem erhöhten Verbrauch von Ressourcen und möglicherweise zu Redundanzen. Erfindungsgemäß ist es nun möglich, die Befehlsfolge für die Web-Oberfläche einzulesen und in eine Befehlsfolge für die Desktop-Applikation zu transformieren und diese dann auf dem lokalen Rechner auszuführen.

Damit ist es auch möglich, das Verfahren nicht zur Neuerstellung einer Benutzer-Oberfläche einzusetzen, sondern sozusagen als Adapter einzusetzen, um eine bestehende Benutzer-Oberfläche in eine andere Ziel-Benutzer-Oberfläche zu transformieren.

Ebenso ist es denkbar, dass bereits eine Benutzer-Oberfläche für eine Desktop-Applikation existiert und diese Oberfläche nun auch auf anderen Rechnern und Geräten benutzbar gemacht werden soll. Erfindungsgemäß ist auch dies ohne zusätzlichen Aufwand möglich, indem die Befehlsfolge für die Benutzer-Oberfläche für die Desktop-Applikation in eine Befehlsfolge für die Ziel-Benutzer-Oberfläche für z.B. eine "Remote"-Applikation zu transformieren. Die transformierte Befehlsfolge dient dann als Startpunkt für den Aufruf und die Ausführung der Applikation.

Mit dem erfindungsgemäßen Verfahren ist es auch möglich, eine Ziel-Benutzer-Oberfläche für eine Applikation zu schaffen, die als Web-Applikation und/oder als lokaler Prozess unter einem Account eines lokalen Benutzers gestartet werden kann.

Durch die erfindungsgemäße Transformation der zugrunde liegenden Befehlsfolgen wird ein hoher Grad an Flexibilität erreicht. Es ist möglich, das Verfahren für eine Erstimplementierung einer Benutzer-Schnittstelle einzusetzen oder auch, um Weiterentwicklungen, Wartung und Pflege von bereits installierten Benutzer-Schnittstellen dynamisch und variabel auszuführen.

In einer bevorzugten Ausführungsform basiert die vorliegende Erfindung auf einer von Microsoft geschaffenen Plattform. Dann wird erfindungsgemäß ein HTML-Dokument in eine HTA-Applikation umgewandelt. HTA (HTA steht für HTML-Application) ist ein von Microsoft geschaffener Mechanismus für Anwendungen, die auf den üblichen Standards von Internetseiten basieren (wie HTML, CSS, JavaScript, DOM, etc.). HTA bietet den Vorteil, dass noch weitere Funktionen unterstützt werden. Üblicherweise erstellt HTA eine selbstlaufende Anwendung.

Die Ausgabe des erfindungsgemäß generierten Codes erfolgt üblicherweise über den CGI-Standard (CGI: Common Gateway Interface). Alternativ ist es jedoch auch möglich, hier eine andere Schnittstelle vorzusehen.

Üblicherweise stimmt der Rechner, auf dem das erfindungsgemäße Verfahren abläuft nicht mit dem Rechner überein, auf dem die Applikation läuft. Es kann jedoch auch sein, diese Funktionen auf demselben Rechner auszuführen.

In der bevorzugten Ausführungsform ist die erfindungsgemäße Vorrichtung mit einer Einleseeinheit und/oder einem Transformator und gegebenenfalls mit einer Ausführungseinheit ausgebildet. In einer alternativen Ausführungsform der Erfindung ist es jedoch vorgesehen, die Vorrichtung ohne die Ausführungseinheit auszubilden, die dann entweder extern oder auf den jeweiligen Geräten ausgebildet sein kann.

Die vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahrens können auch als Computerprogrammprodukt ausgebildet sein, mit einem von einem Computer lesbaren Medium und mit einem Computerprogramm und zugehörigen Programmcode-Mitteln, wobei der Computer nach Laden des Computerprogramms zur Durchführung des oben beschriebenen, erfindungsgemäßen Verfahrens veranlasst wird.

Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computer-implementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.

Zusätzliche, vorteilhafte Ausführungsformen ergeben sich aus den Unteransprüchen.

In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. In dieser zeigen:
1 eine übersichtsartige Darstellung über wesentliche Bauteile gemäß einer bevorzugten Ausführungsform der Erfindung,
2 eine Darstellung der beteiligten Entitäten und deren informationstechnologischer Zusammenhang gemäß einer bevorzugten Ausführungsform der Erfindung,
3 eine Darstellung eines erfindungsgemäßen Datenflusses für eine statisch generierte HTML-Benutzeroberfläche und
4 eine Darstellung eines erfindungsgemäßen Datenflusses für eine dynamisch generierte HTML-Benutzeroberfläche.
In Zusammenhang mit 2 wird das Grundkonzept der erfindungsgemäßen Lösung näher erläutert.
Das Verfahren dient dazu, eine Schnittstelle für eine Benutzer-Oberfläche B und eine Applikation A zu schaffen. Die Applikation A läuft auf einer bestimmten Rechner-Infrastruktur, z.B. einer web-basierten Infrastruktur, die einen Web-Server umfasst.
Grundsätzlich gibt es zwei Hauptanwendungsfelder der vorliegenden Erfindung:

1. Die Erfindung kann angewendet werden, um eine Benutzer-Oberfläche B erstmals neu zu erstellen.
2. Weiterhin kann die Erfindung angewendet werden, um eine bestehende Benutzer-Oberfläche B für eine HTML-Applikation in eine Ziel-Benutzer-Oberfläche Z für eine Desktop-Applikation umzuwandeln.

Wie in den 3 und 4 übersichtsartig gezeigt, ist erfindungsgemäß ein HTA-Framework vorgesehen, das die jeweiligen Requests und Ausgaben für die Generierung der Benutzeroberfläche umleitet und den Web-Server damit zumindest in seinen wesentlichen Funktionen ersetzt.
In 2 sind bei Szenarien angedeutet. Soll eine bereits existierende Benutzer-Oberfläche B an eine Ziel-Benutzer-Oberfläche Z angepasst werden, so wird die existierende Benutzer-Oberfläche B mit einer erfindungsgemäßen Vorrichtung 10 in die Ziel-Benutzer-Oberfläche Z überführt. Wesentlich ist es, dass die erfindungsgemäße Umwandlung unabhängig von der Applikation A und/oder der Rechner-Infrastruktur R ist.
In 2 ist angedeutet, dass die Benutzer-Oberfläche B, die für eine Applikation A' ausgelegt ist, die ihrerseits auf der Rechner-Infrastruktur R' läuft und einen Web-Server umfasst, in eine Ziel-Benutzer-Oberfläche Z überführt werden soll. Die Ziel-Benutzer-Oberfläche Z ist für die Applikation A ausgelegt. Dabei ist es wesentlich, dass die Applikation A auf einer Rechner-Infrastruktur R läuft, die im Unterschied zur Rechner-Infrastruktur R' keinen Web-Server umfasst. Bei der Rechner-Infrastruktur R' kann es sich z.B. um eine HTTP-basierte Infrastruktur und bei der Rechner-Infrastruktur R um eine Client-Server-Infrastruktur handeln.
Soll jedoch nicht eine bestehende Benutzer-Oberfläche B verändert werden, sondern soll eine Ziel-Benutzer-Oberfläche Z erstmals neu generiert werden, so ist es möglich, dass erfindungsgemäß dafür eine Befehlsfolge eingelesen wird. Dies ist mit dem oberen auf die Vorrichtung 10 verweisenden Pfeil in 2 angedeutet.
In Zusammenhang mit 1 werden die wesentlichen Bauteile gemäß der bevorzugten Ausführungsform der Erfindung erläutert. Eine Befehlsfolge für eine Benutzer-Oberfläche B wird über eine Einlese-Einheit 12 eingelesen. Ein Transformator 16 generiert aus den Daten der Einleseeinheit 12 eine Ziel-Befehlsfolge, die dann der Ausführungseinheit 18 zur weiteren Ausführung weitergeleitet werden kann. Die Ausführungseinheit 18 führt die eingelesene Befehlsfolge aus und ruft damit die Applikation A auf, die damit die Ziel-Benutzer-Oberfläche Z auf einem gewünschten System generiert. Es ist jedoch auch möglich, nur eine Schnittstelle zur Verfügung zu stellen und die Ziel-Befehlsfolge nicht auszuführen.
In der bevorzugten Ausführungsform ist das Verfahren auf Mechanismen und Technologien der Firma Microsoft ausgelegt.
Insbesondere wird die HTA-Technologie (HTML-Application-Technology) angewendet. Dies erfordert unter Umständen die Verwendung von 32-Bit-Systemen.
Grundsätzlich ist ein HTML-Dokument in eine HTA-Anwendung umwandelbar, wobei weitere Kennzeichnungen möglich sind. Der Vorteil des Einsatzes von HTA-Anwendungen ist darin zu sehen, dass diese einem geringeren Sicherheits-Standard unterliegen, sodass der Rahmen für Zugriffe auf weitere Programme und Dateien weiter gezogen ist.
Üblicherweise basiert das erfindungsgemäße Verfahren auf dem CGI-Standard (CommonGatewayInterface).
Durch die Verwendung dieser Technologien ist es z.B. möglich, Web-Dialoge, also Interaktionen des Benutzers mit einem web-basierten System, als Desktop-Applikationen ausführbar zu machen, ohne dass ein Web-Server eingesetzt werden muss.
Darüber hinaus ist es möglich, eine neue Ziel-Benutzer-Oberfläche Z zu generieren, für eine Applikation A, die sowohl auf einem PC lokal installiert und als eine Desktop-Applikation ausgeführt werden kann, als auch in Form einer Web-Applikation wiederverwendbar ist. Ein weiterer Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass keine zusätzlichen Anforderungen an das weitere System (Remote-System) gestellt werden müssen. Hier ist es lediglich erforderlich, dass ein HTML-Browser läuft.
Bei der erfindungsgemäß generierten Ziel-Benutzer-Oberfläche Z und/oder bei der Benutzer-Oberfläche B kann es sich um eine dynamisch und/oder um eine statisch generierte HTML-Page handeln.
Eine statische generierte HTML-Seite kennzeichnet sich erfindungsgemäß dadurch, dass die HTML-Seite als Datei lokal bzw. auf der Festplatte gespeichert ist und somit direkt referenziert werden kann.
Im Gegensatz dazu kennzeichnen sich erfindungsgemäß dynamisch generierte HTML-Seiten dadurch, dass eine Referenzierung auf eine Applikation A (und nicht auf eine Datei) erfolgt bzw. von einem Web-Server aufgerufen wird. Das Ergebnis dieser Applikation A wird dann ausgegeben.
Der Inhalt der Applikation A, also z.B. ob es sich um eine statische oder dynamische Benutzeroberfläche handelt, ist dabei völlig unabhängig von der erfindungsgemäßen Lösung. Vorteilhafterweise ist die erfindungsgemäße Lösung damit so ausgebildet, dass sie sowohl statische als auch dynamische Seiten verarbeiten kann.
Falls das erfindungsgemäße Verfahren verwendet wird, um HTML-basierte Benutzer-Oberflächen zu verarbeiten, so werden die von einem Benutzer ausgelösten HTML-Submit-Events (also das Abschicken eines Inhalts des HTML-Formulars) abgefangen und von der Einleseeinheit 12 eingelesen. Die Daten werden dann an die Applikation A zur Ausführung weitergeleitet. Weiterhin werden alle notwendigen Zugriffe ausgeführt, insbesondere auf die Windows-Registry, auf das Dateisystem und/oder auf sonstige System-Ressourcen. Daraufhin können die CGI-Ausgaben gefiltert werden.
Alternativ dazu ist es möglich, dass sie die Daten des Formulars selbständig einliest und diese an eine spezielle Methode (execute-Methode) übergibt, die zur Aufgabe hat, diese Daten als Start-Parameter zu verwenden, um die Applikation A bzw. ein CGI zu starten. Diese alternative Ausführungsform kann das erfindungsgemäße Framework entlasten, da es dann nur die Applikation mit den bereits vorhandenen Parametern starten muss. Im üblichen Fall müssen darüber hinaus die Daten aus dem Formular erst eingelesen, erfindungsgemäß transformiert und dann an die Applikation A übergeben werden.
Nach dem Laden der jeweiligen Seite wird ein sogenannter Event-Handler ausgelöst, auf den die Einleseeinheit 12 reagiert, um die HTML-Seite zu präparieren. Damit wird es mög lich, zu einem späteren Zeitpunkt auf ein Submit-Event reagieren und z.B. die Daten eines Formulars einlesen zu können.
Falls der Benutzer ein Formular abschickt, wird der Inhalt dieses Formulars eingelesen und weiterverarbeitet. Der weiterverarbeitete Formularinhalt wird weitergereicht. Bei dynamisch generierten Seiten kann es notwendig sein, die Ausgabe bzw. den Output der Appliaktion A zu korrigieren bzw. in eine Datei umzuleiten. Dies ist insbesondere dann erforderlich, wenn die Applikation A für eine andere Umgebung und Infrastruktur ausgelegt ist und/oder falls Unterschiede zwischen dem Virtual-Directory des Web-Servers und dem lokalen File-System bestehen. Daran anschließend werden die Referenz-Attribute des HTML-Rahmens auf dem Pfad bzw. die Adresse der CGI-Ausgabedatei gesetzt.
Falls die in HTA implementierte "Execute"-Methode aufgerufen wird, wird eine Batch-Datei erzeugt, um Umgebungs- und/oder infrastrukturelle Parameter zu bestimmen und das CGI auszuführen. Die Ausgabe wird wieder auf eine Datei umgeleitet und falls notwendig werden – wie vorstehend beschrieben – die Pfadangaben in der Datei korrigiert. Anschließend werden, ebenfalls wie vorstehend beschrieben, die Referenz-Attribute des HTML-Rahmens gesetzt.
Vorzugsweise kann die erfindungsgemäße Vorrichtung 10 durch zwei Dateien gebildet werden, insbesondere durch eine HTA-Datei und durch eine reine HTML-Datei.
In der bevorzugten Ausführungsform werden die geänderten Dialog-Daten in Bezug auf die Benutzer-Schnittstelle B und Z gespeichert.
3 zeigt einen erfindungsgemäßen Datenfluss des HTA-Frameworks bei der Generierung von statischen HTML-Seiten. Nach dem Laden einer angeforderten HTML-Seite kann auch ohne den Zugriff auf einen Web-Server die Seite auf dem Browser darge stellt werden. Falls notwendig, wird ein submit-event angefordert.
4 zeigt einen erfindungsgemäßen Datenfluss des HTA-Frameworks bei der Generierung von dynamischen HTML-Seiten. Nachdem dem dem Verschicken eines Formulars durch den Anwender oder durch Aufruf einer execute-Methode über eine Anwender-Interaktion, wird ein Batch-Skript erstellt, um den CGI-Code auszuführen. Dann kann die Batch-Datei gestartet werden. Falls es notwendig ist, können die Adressen bzw. Pfadangaben in der Ausgabe-Datei (output-file) korrigiert oder ersetzt werden. Daraufhin kann die HTML-Seite als Ausgabe in dem Browser geladen werden.
Bei bisherigen Systemen erfolgte das Senden des Requests bzw. der Anfragen und das Senden der HTML-Seite über einen Zugriff auf den Web-Server. Dies ist nun nicht mehr notwendig und das HTA-Framework kann die Funktionalität des Web-Servers ersetzen.

Claims

Verfahren zum Generieren einer Schnittstelle zwischen einer Benutzeroberfläche (B) und zumindest einer computer-implementierten Applikation (A), dadurch gekennzeichnet, dass das Verfahren folgende Verfahrensschritte umfasst: – Einlesen einer Befehlsfolge, die zum Generieren einer Benutzeroberfläche (B) bestimmt ist und den Einsatz einer web-basierten Infrastruktur erfordert – Transformieren der eingelesenen Befehlsfolge in eine Ziel-Befehlsfolge, die dazu bestimmt ist, ein Generieren der Benutzeroberfläche (B) ohne den Einsatz einer web-basierten Infrastruktur über eine Ausführung der Applikation (A) zu instruieren.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die web-basierte Infrastruktur zumindest einen Web-Server umfasst.
Verfahren nach zumindest einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass die Applikation (A) für eine Client-Server-Architektur und/oder eine HTTP-basierte Architektur ausgelegt ist.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Einlesen, das Transformieren und/oder das Ausführen der Applikation (A) automatisch erfolgt.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren zusätzlich folgenden Verfahrensschritt umfasst: – Ausführen zumindest einer Applikation (A), die über die Ziel-Befehlsfolge gestartet wird.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren angewendet wird, um eine bestehende Benutzeroberfläche (B) in eine Ziel-Benut zeroberfläche (Z) zu adaptieren, indem eine Befehlsfolge für die bestehende Benutzeroberfläche (B) eingelesen und so transformiert wird, dass die transformierte Befehlsfolge die Ausführung der Applikation (A) veranlasst, um die Ziel-Benutzeroberfläche (Z) ohne den Einsatz einer web-basierten Infrastruktur zu generieren.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren zumindest eine HTA-Applikation verwendet.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Schnittstelle alle wesentlichen Funktionen eines Web-Servers übernimmt und insbesondere erforderliche Zugriffe auf System-Ressourcen ausführt und Anfragen an den Web-Server und Ausgaben des Web-Servers umleitet und intern abarbeitet.
Vorrichtung zum Generieren einer Schnittstelle zwischen einer Benutzeroberfläche (B) und zumindest einer computer-implementierten Applikation (A), dadurch gekennzeichnet, dass die Vorrichtung folgende in Datenaustausch stehende Module umfasst: – zumindest einer Einleseeinheit (12), die dazu bestimmt ist, eine zum Generieren einer Benutzeroberfläche (8) bestimmte Befehlsfolge, die den Einsatz einer web-basierten Infrastruktur erfordert, einzulesen – zumindest einen Transformator (16), der zum Transformieren der eingelesenen Befehlsfolge in eine Ziel-Befehlsfolge bestimmt ist, wobei die Ziel-Befehlsfolge das Generieren der Benutzeroberfläche (B) ohne den Einsatz einer web-basierten Infrastruktur instruiert.
Vorrichtung nach Anspruch 9, dadurch gekennzeichnet, dass die web-basierte Infrastruktur zumindest einen Web-Server umfasst.
Vorrichtung nach zumindest einem der Ansprüche 9 oder 10, dadurch gekennzeichnet, dass die Applikation (A) für eine Client-Server-Architektur und/oder für eine HTTP-basierte Architektur ausgelegt ist.
Vorrichtung nach zumindest einem der vorstehenden Ansprüche 9 bis 11, dadurch gekennzeichnet, dass die Einleseeinheit (12), der Transformator (16) und/oder eine Ausführungseinheit (18) automatisch arbeiten.
Vorrichtung nach zumindest einem der vorstehenden Ansprüche 9 bis 12, dadurch gekennzeichnet, dass die Vorrichtung zusätzlich zumindest eine Ausführungseinheit (18) umfasst, die zum Ausführen der Ziel-Befehlsfolge bestimmt ist, wobei ein Gerät bestimmt werden kann, auf dem die Benutzeroberfläche (B) erstellt werden soll.
Vorrichtung nach zumindest einem der vorstehenden Ansprüche 9 bis 13, dadurch gekennzeichnet, dass die Vorrichtung auf zumindest eine HTA-Applikation zugreift.
Vorrichtung nach zumindest einem der vorstehenden Ansprüche 9 bis 14, dadurch gekennzeichnet, dass die generierte Schnittstelle zumindest einem Teilbereich eines Web-Servers entspricht und insbesondere erforderliche Zugriffe auf System-Ressourcen ausführt, Anfragen an den Web-Server umleitet und intern abarbeitet und Ausgaben der ausgeführten Applikationen (A) umleitet.
Verwendung der Vorrichtung nach zumindest einem der Ansprüche 9 bis 15 zum Adaptieren einer bestehenden Benutzeroberfläche (B) in eine Ziel-Benutzeroberfläche (Z), indem eine Befehlsfolge für die bestehende Benutzeroberfläche (B) eingelesen und so transformiert wird, dass alle Zugriffe auf einen Web-Server umgeleitet und intern abgearbeitet werden, und indem die transformierte Befehlsfolge es veranlasst, dass die Ziel-Benutzeroberfläche (Z) generiert wird.
Systemanordnung zum Generieren einer Schnittstelle zwischen einer Benutzeroberfläche (B) und zumindest einer computerimplementierten Applikation (A), dadurch gekennzeichnet, dass die Vorrichtung folgende in Datenaustausch stehende Module umfasst: – zumindest einer Einleseeinheit (12), die dazu bestimmt ist, eine zum Generieren einer Benutzeroberfläche (B) bestimmte Befehlsfolge, die den Einsatz einer web-basierten Infrastruktur erfordert, einzulesen – zumindest einen Transformator (16), der zum Transformieren der eingelesenen Befehlsfolge in eine Ziel-Befehlsfolge bestimmt ist, wobei die Ziel-Befehlsfolge das Generieren der Benutzeroberfläche (B) ohne den Einsatz einer web-basierten Infrastruktur instruiert.