DE602004011610T2

DE602004011610T2 - Web-anwendungsserver

Info

Publication number: DE602004011610T2
Application number: DE602004011610T
Authority: DE
Inventors: Michael Sean San Francisco HILL; Joerg Palo Alto MANN
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2003-05-15
Filing date: 2004-05-07
Publication date: 2009-01-29
Anticipated expiration: 2024-05-08
Also published as: US20040226459A1; ATE385374T1; US7366777B2; DE602004011610D1; EP1625728B1; WO2004105346A1; EP1625728A1

Description

TECHNISCHES GEBIET
Diese Beschreibung betrifft Softwareanwendungen, die ein Webkommunikationsprotokoll, wie Hypertext-Transferprotokoll (HTTP) verwenden, um Kommunikationen über ein Netzwerk zu ermöglichen.
HINTERGRUND
Mit dem Aufkommen des Internets ist die Zahl an Webapplikationen (d. h. Applikationen, die HTTP oder ein ähnliches Netzwerk-Kommunikationsprotokoll verwenden) stark angewachsen. Die Entwicklung von Webapplikationen wurde deshalb zunehmend wichtig für Software-Hersteller, die in dem Internetalter konkurrieren.
Die Webapplikations-Entwicklung unter Verwendung eines Modell-View-Controller-Paradigmas schließt typischerweise Aufgaben bzw. Tasks ein, die durch einen User-Interface-Entwickler und einen Backend-Entwickler ausgeführt werden. Der User-Interface-Entwickler ist der Entwickler der Präsentations- oder View-Logik. Der Backend-Entwickler ist der Entwickler der Kontroll-Logik, die den Code enthält, der es der Webapplikation ermöglicht, Daten von den Backend-Systemen zugänglich zu machen oder zu empfangen, die Daten zu verarbeiten und die verarbeiteten Daten zurück zu den Backend-Systemen zu senden. Die Backend-Systeme schließen Rechner-Systeme ein, die abgefragt werden können, um Daten wie erforderlich zu erhalten, unter Ausführen einer Webapplikation. Solche Daten können zum Beispiel Log-in-Information und Verbraucherdaten einschließen.
Die Webapplikations-Entwicklung kann verzögert werden, weil das Kuppeln und die gegenseitige Abhängigkeit der Aufgaben von dem User-Interface-Entwickler und dem Backend-Entwickler untereinander abhängig sind. Zum Beispiel kann ein User-Interface-Entwickler gezwungen sein, darauf zu warten, dass die Backend-Integration weiter vorangeht, bevor er in der Lage ist, das Entwickeln des User-Interface fortzusetzen.
US 2002/059470A1 offenbart ein Computer-implementiertes Verfahren und ein System für Aufrufverfahren und insbesondere für Aufrufverfahren von einem Server-Objekt über das Internet durch ein Serverprogramm, das ein Server-Computer-System ausführt. Das Serverprogramm empfängt eine Anfrage, die von einem Kundenprogramm gesendet wurde, das ein Shimscript, eine Objektklasse und eine Funktion der Objektklasse identifiziert. In Antwort auf das Empfangen der Anfrage lädt das Serverprogramm und überträgt die Kontrolle zu dem identifizierten Shimscript. Wenn ein Objekt von der identifizierten Objektklasse nicht vorliegt, instanziiert das Shimscript ein Objekt von der identifizierten Objektklasse. Das Shimscript ruft dann die identifizierte Funktion des instanziierten Objekts auf. Die aufgerufene Funktion führt ihr Verhalten aus, erzeugt eine Antwort, die an das Kundenprogramm zu senden ist, und sendet die Antwort einschließlich einer Zustands-Information an das Kundenprogramm. Wenn das Kundenprogramm anschließend eine weitere Anfrage sendet, um eine Funktion der Objektklasse aufzurufen, ist die Zustands-Information in die Anfrage derart eingeschlossen, dass die Funktion ihr Verhalten, basierend auf der Zustands-Information, ausführen kann.
EP 1 261 170 A1 beschreibt ein Verfahren zum Erlauben des Zugriffs auf ein privates Netzwerk von einem mobilen Terminal und insbesondere ein Mobiltelefon. Das mobile Terminal leitet einzigartige Identifizierer zu einem Authentifizierungsserver. Wenn die Identifizierer zu einem Datengangzugang passen, dann wird eine Netzwerkadresse zu einem Serverknoten geschickt. Der mobile Terminal startet dann eine Kommunikationssitzung unter Anwendung der Netzwerkadresse, die zu dem Serviceknoten geschickt wird, und unter Verwendung des Serviceknotens als ein Proxyserver.
Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System bereitzustellen, das die Flexibilität bei der Entwicklung von Anwendungen und insbesondere von Webapplikationen erhöht.
Diese Aufgabe wird durch ein Computer-implementiertes Verfahren und ein Computer-System mit den in Anspruch 1 bzw. 14 offenbarten Merkmalen erfüllt. Bevorzugte Ausführungsformen werden in den abhängigen Unteransprüchen definiert.
KURZDARSTELLUNG
In einem allgemeinen Aspekt schließt ein Computer-implementiertes Verfahren Empfangen einer Anfrage, die einen Aktionsparameter einschließt, und Identifizieren einer Prozedur, die mit dem Wert des Aktionsparameters in Verbindung steht, ein. Wenn eine Prozedur identifiziert ist, wird die identifizierte Prozedur ausgeführt. Wenn eine Prozedur nicht identifiziert ist, wird das Skript, das mit dem Wert des Aktionsparameters verbunden bzw. assoziiert ist, abgesendet.
Die Implementierungen können ein oder mehrere der nachstehenden Merkmale einschließen. Zum Beispiel kann die Anfrage eine Hypertext Transferprotokoll-Anfrage sein. Die Prozedur kann ein Verfahren sein, das einer Objekt-orientierten Programmiersprache oder einer Funktion, die in einer Verfahrensprogrammiersprache verwendet wird, angewendet wird. Nachdem eine identifizierte Prozedur ausgeführt ist, kann ein Skript abgesendet werden, wenn die Ausführung des Verfahrens zu keiner festgelegten Antwort führt.
Unter Identifizieren einer Prozedur, die mit dem Wert des Aktionsparameters verbunden ist, kann das Suchen einer Gruppe von Prozeduren in einem Programm für eine Prozedur, die mit dem Wert des Aktionsparameters verbunden ist, einschließen. Das Suchen einer Gruppe von Prozeduren kann das Suchen einer Gruppe von Prozeduren in einem Programm für eine Prozedur, die einen Namen aufweist, der gleich zu dem Wert des Aktionsparameters ist, einschließen. Das Suchen einer Gruppe von Prozeduren kann das Suchen einer Gruppe von Prozeduren in einem Programm für eine Prozedur, die mit dem Wert des Aktionsparameters verbunden ist, und die den Code einschließt, der die Applikations-Kontroll-Logik implementiert, einschließen. Das Suchen einer Gruppe von Prozeduren kann das Suchen einer Gruppe von Prozeduren in einem Programm für eine Pro zedur, die mit dem Wert des Aktionsparameters verbunden ist, und die den Code einschließt, der Kommunikationen mit Backend-Systemen ermöglicht, einschließen.
Das Suchen einer Gruppe von Prozeduren kann das Suchen einer Gruppe von Verfahren in einer Klasse für ein Verfahren einschließen, das mit dem Wert des Aktionsparameters verbunden ist. Das Verfahren kann in Java^TM programmiert sein.
Das Suchen einer Gruppe von Prozeduren kann das Suchen einer Gruppe von Funktionen in einem Programm für eine Funktion, die mit dem Wert des Aktionsparameters verbunden ist, einschließen. Die Funktion kann in Perl programmiert sein.
Das Absenden an ein Skript, das mit dem Wert des Aktionsparameters verbunden ist, kann Absenden an ein Script, das unter einem File-Namen entsprechend dem Wert des Wirkparameters gespeichert ist, einschließen. Das Absenden zu einem Skript kann Absenden zu einem Skript einschließen, das mit dem Wert des Aktionsparameters verbunden ist, und das Code einschließt, der Präsentations-Logik implementiert. Die Präsentations-Logik kann ein User-Interface implementieren. Das User-Interface kann ein Sprach-User-Interface sein, das operabel ist, um mit einem User von einer Sprach-Kommunikations-Vorrichtung zu kommunizieren. Die Sprach-Kommunikations-Vorrichtung kann ein Festnetztelefon, ein drahtloses Telefon, ein sprachkundiger Personal-Digitalassistent oder ein sprachfähiger Computer sein.
Das Skript, das mit dem Wert des Aktionsparameters verbunden ist, kann den Markup-Language-Code einschließen. Der Markup-Language-Code kann Hypertext-Markup-Language, VoiceXML, SALT oder Markup-Language, die zum Kommunizieren mit drahtlosen Kommunikations-Vorrichtungen verwendet werden, einschließen. Die Markup-Language, die zum Kommunizieren mit drahtlosen Kommunikations-Vorrichtungen verwendet wird, kann drahtlose Markup-Langua-ge einschließen.
In einem weiteren allgemeinen Aspekt schließt ein Computer-System einen Webapplikations-Computer, konfiguriert zum Aufnehmen einer Anfrage, die einen Aktionsparameter einschließt, und konfiguriert zum Identifizieren einer Prozedur, die mit dem Wert des Aktionsparameters verbunden ist, ein. Der Webapplikations-Computer wird weiterhin konfiguriert, um die Prozedur auszuführen, wenn eine Prozedur identifiziert ist und abgeschickt ist zu einem Skript, das mit dem Wert des Aktionsparameters verbunden ist, wenn eine Prozedur nicht identifiziert ist.
Implementierungen können ein oder mehrere der nachstehenden Merkmale einschließen. Zum Beispiel kann der Webapplikations-Computer weiterhin konfiguriert sein, um eine Antwort zu senden. Die Webapplikation kann weiterhin konfiguriert sein, um an das Skript nach Ausführung des Verfahrens abgesendet zu werden, wenn die Ausführung des Verfahrens zu keiner Antwort führt, die festgelegt ist.
Der Webapplikations-Computer kann konfiguriert sein, um an ein Skript, einschließlich Markup-Language, verwendet für Kommunikationen mit einer drahtlosen Kommunikations-Vorrichtung, gesendet zu werden. Die Markup-Language kann drahtlosen Markup-Language-Code einschließen. Der Webapplikations-Computer kann konfiguriert sein, um an ein Skript einschließlich VoiceXML oder SALT-Code gesendet zu werden.
Das Computer-System kann weiterhin einen Gateway-Computer einschließen. Der Gateway-Computer kann konfiguriert sein, um mit einer drahtlosen Kommunikations-Vorrichtung zu kommunizieren. Der Gateway-Computer kann ein drahtloses Applikations-Protokoll-Gateway sein. Der Gateway-Computer kann ein Voice-Gateway, konfiguriert zum Kommunizieren mit einer Voice-Kommunikations-Vorrichtung, sein.
Die Einzelheiten von einer oder mehreren Implementierungen werden für die beigefügten Zeichnungen und die nachstehende Beschreibung angeführt. Weitere Merkmale werden aus der Beschreibung und Zeichnungen und aus den Ansprüchen deutlich.
BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockdiagramm von einem Kommunikations-System unter Verwendung von Webapplikations-Routinglogik, um eine flexible Plattform für Webapplikationen bereitzustellen.
2 ist ein Fließschema von einem Verfahren zum Entwickeln von einer Webapplikation unter Verwendung von Webapplikations-Routinglogik.
3A und 3B sind ein Fließschema von einem Verfahren unter Verwendung von Webapplikations-Routinglogik und der Antwort auf HTTP-Anfragen.
4 ist ein Blockdiagramm von einer Implementierung des Kommunikations-Systems von 1, das Webapplikations-Routinglogik anwendet, um eine flexible Plattform für auf Web basierende Sprachanwendungen bereitzustellen.
5 ist ein Blockdiagramm von einer einzelnen Implementierung von dem Kommunikations-System von 4.
6A und 6B sind ein Fließschema von einem Verfahren zur Verwendung von Webapplikation ohne Routinglogik, um Kommunikationen mit einem User von einer Sprach-Kommunikations-Vorrichtung zu beginnen.
7A und 7B sind ein Fließschema von einem Verfahren zur Verwendung von Webapplikations-Routinglogik, um mit User von einer Sprach-Kommunikations-Vorrichtung zu kommunizieren.
BESCHREIBUNG IM EINZELNEN
Bezug nehmend auf 1 schließt ein Kommunikations-System 100 zur Anwendung in der Webapplikations-Routinglogik, um eine flexible Plattform zur Webapplikations-Entwicklung bereitzustellen, ein Kunden-System 110, ein Netzwerk 120 und ein Webapplikations-System 130 ein. Das Kunden-System 110 ist konfiguriert, um Anfragen zu senden und Antworten aus dem Webapplikations-System 130 zu empfangen. Zum Beispiel kann das Kunden-System 110 Daten unter Anwendung von Hypertext-Transferprotokoll (HTTP) oder einem anderen Protokoll, das Webkommunikationen über ein Netzwerk ermöglicht, empfangen. Die HTTP-Antworten werden verarbeitet, um mit einem User des Kunden-Sys-tems 110 zu kommunizieren. Das Kunden-System 110 schließt eine Vorrichtung 110A ein, die Anweisungen unter dem Befehl eines Controllers 110B ausführen kann. Die Vorrichtung 110A kann ein Allzweckcomputer, wie eine Workstation oder ein PC, ein Personal Digital Assistant (PDA), ein Spezialzweckcomputer, ein intelligentes Mobiltelefon, ein Pager oder eine Settop-Box, sein.
Der Controller 110B befiehlt und richtet Kommunikationen zwischen der Vorrichtung 110A und dem Kunden-System 110B und dem Webapplikations-System 130. Der Controller 110B kann ein oder mehrere Software- und Hardware-Applikationen einschließen, die es einem User des Kunden-Systems 110 ermöglichen, unter Anwendung von HTTP mit dem Webapplikations-System 130 zu kommunizieren. Zum Beispiel kann der Controller 110B eine Browser-Applikation auf einem Personal Computer sein, die HTTP-Anfragen an das Webapplikations-System 130 sendet, HTTP-Antworten aus dem Webapplikations-System 130 em-pfängt und Hypertext-Markup-Language-(HTML)-Code in den HTTP-Antworten verarbeitet, um eine Website oder anderweitiges Kommunizieren mit dem Anwender anzuzeigen. Die Vorrichtung 110A ist mit dem Controller 110B durch einen verdrahteten, drahtlosen oder virtuellen (d. h. wenn der Controller auf der Vorrichtung softwaregängig ist) Datendurchgang 110C, der Daten abgeben kann, verbunden. In einigen Implementierungen ist die Vorrichtung 110B ein Webbrowser, der auf der Vorrichtung 110A, die ein PC ist, läuft.
In einer weiteren Implementierung ist das Kunden-System 110 konfiguriert, um mit einem Gateway (nicht gezeigt) anstatt mit dem Webapplikations-System 130 zu kommunizieren. In dieser Implementierung tauscht das Kunden-System 110 Daten mit dem Gateway, das wiederum mit dem Webapplikations-System 130 unter Anwendung von HTTP kommuniziert. Zum Beispiel kann das Kunden-System 110 eine Sprach-Kommunikations-Vorrichtung, wie zum Beispiel ein Festnetztelefon, das Sprachdaten mit einem Sprach-Gateway austauscht, sein, oder das Kunden-System 110 kann eine drahtlose Vorrichtung, wie zum Beispiel ein drahtloses Te lefon, ein Pager oder ein Radio-Sender-Empfänger, sein, der Daten mit einem Wireless Application Protocol(WAP)-Gateway austauscht.
Das Netzwerk 120 ist konfiguriert, um direkte oder indirekte Kommunikationen zwischen dem Kunden-System 110 und dem Webapplikations-System 130 zu ermöglichen. Beispiele für das Netzwerk 120 schließen das Internet, Wide Area Networks (WANs), Local Area Networks (LANs), analog oder digital verdrahtete oder drahtlose Telefonnetzwerke (zum Beispiel Public Switch Telephone Network (PSTN), Integrated Services Digital Network (ISDN) und Digital Subscriber Line (xDSL)), Radio, Fernsehen, Kabel, Satellit und/oder jeden anderen Abgabe- oder Tunnel-Mechanismus zum Trasport von Daten ein.
Das Webapplikations-System 130 ist ein Computer-System, das zum Empfangen von Anfragen von dem Kunden-System 110 über das Netzwerk 120 konfiguriert ist, Verarbeiten der Anfragen gemäß einer Webapplikation, das Webapplikations-Routinglogik einschließt und entsprechende Antworten auf das Kunden-System 110 sendet. In einer beispielhaften Implementierung werden die Anfragen und Antworten unter Anwendung von HTTP kommuniziert.
In einer weiteren Implementierung empfängt das Webapplikations-System 130 HTTP-Anfragen und sendet HTTP-Antworten zu einem Gateway (nicht gezeigt), das mit dem Kunden-System 110 kommuniziert. In dieser Implementierung kommuniziert das Kunden-System 110 nicht mit dem Webapplikations-System 130 direkt unter Verwendung von HTTP, kommuniziert jedoch anstatt dessen mit dem Gateway, das wiederum mit dem Webapplikations-System 130 unter Anwendung von HTTP kommuniziert. Das Gateway kann zum Beispiel ein Sprach-Gateway sein, das konfiguriert ist, um Voice Extensible Markup Language (VoiceXML), Speech Application Language Tags (SALT) zu verarbeiten und Sprachdaten mit dem Kunden-System 110 auszutauschen. Das Gateway kann auch ein Gateway sein, das konfiguriert ist, um mit drahtlosen Kommunikations-Vorrichtungen zu kommunizieren. Zum Beispiel kann das Gateway ein Webgateway sein, das zum Verarbeiten von Wireless Markup Language (WML) konfiguriert ist und Daten mit dem Kunden-System 110 unter Verwendung von WAP austauscht. Das Gateway kann lokal zu dem Webapplikations-System 130 sein, lokal zu dem Kunden-Sys tem 110 sein oder entfernt von sowohl dem Webapplikations-System 130 als auch dem Kunden-System 110 sein, jedoch kommunikativ mit ihnen über Netzwerk 120 gekoppelt.
Die Webapplikation schließt eine Reihe von Scripten und einen HTTP-Antwort-Algorithmus zum Antworten auf HTTP-Anfragen ein. Die Scripte werden in einer Scriptsprache (zum Beispiel JavaServer Pages^TM (JSP), Active Server Pages^TM (ASP) oder PHP: Hypertext Preprocessor (PHP)) geschrieben und schließen typischerweise Markup-Language-Code (zum Beispiel HTML, VoiceXML, SALT oder WML) ein. Der HTTP-Antwort-Algorithmus schließt die Webapplikations-Routinglogik ein und kann als ein Programm, geschrieben in einer prozeduralen Programmiersprache (zum Beispiel Perl oder C), vorliegen oder kann alternativ als eine Klasse, geschrieben in einer objektorientierten Programmiersprache (zum Beispiel C++, Visual Basic oder Java^TM) implementiert sein.
Die Webapplikation kann unter Verwendung eines Model View Controller-Paradigmas entwickelt werden. In einem Model View Controller-Paradigma steuern die Funktionen des Programms oder die Verfahren der Klasse von Implement-Applikation die Logik. Die Applikations-Steuerlogik koordiniert die Ausführung von Scripten (d. h. die Funktionen oder Verfahren können zu einem oder mehreren Scripten während der Ausführung nicht zusammenpassen), greift zu auf oder empfängt ausgewählte Daten von lokalen oder entfernten Computer-Systemen oder Speicher-Vorrichtungen, verarbeitet die Daten und sendet die verarbeiteten Daten zu lokalen oder entfernten Computer-Systemen oder Speicherungs-Vorrichtungen. Die Scripte implementieren Präsentations-(oder Ansichts-)-Logik. Die Präsentations-Logik liefert ein Anwender-Interface, das einen Anwender in die Lage versetzt, mit dem Kunden-System 110 mit der Webapplikation in Wechselwirkung zu treten.
Der HTTP-Antwort-Algorithmus schließt Webapplikations-Routinglogik ein, die den Wert eines Aktionsparameters in einer empfangenen HTTP-Anfrage prüft, um zu bestimmen, welche Verfahren oder Funktionen und/oder Scripte in Antwort auf die empfangene HTTP-Anfrage ausgeführt werden sollten. Der Aktionsparameter ist ein zusätzlicher Parameter, der in der HTTP-Anfrage enthalten ist, der das Ver fahren, Funktion oder Script, das durch die Webapplikations-Routinglogik ausgeführt werden sollte, identifiziert. Andere Parameter, die in der HTTP-Anfrage enthalten sind, schließen einen Universal Resource Locator (URL), einen Webkontext und einen Webapplikations-Namen ein. Zum Beispiel kann eine HTTP-Anfrage wie nachstehend formatiert werden: http//www.mysite.com/mycontext/myapp?action=welcome. In diesem Beispiel schließt die HTTP-Anfrage einen Universal Resource Locator entsprechend "www.mysite.com", einen Webkontext entsprechend "mycontext", einen Webapplikations-Namen entsprechend "myapp" und eine Aktionsparameterreihe, wie "welcome", ein.
Wenn ein Verfahren oder eine Funktion dem Wert des Aktionsparameters entspricht, dann führt die Routinglogik das Verfahren oder die Funktion aus. Wenn Ausführung des Verfahrens oder Funktion in keiner HTTP-Antwort festgelegt wurde (d. h. eine HTTP-Antwort wird nicht durch das Verfahren oder eine Funktion zur anschließenden Abgabe an das Kunden-System 110 hergestellt bzw. vorbereitet), dann sendet die Webroutinglogik zu einem Script, das dem Wert des Aktionsparameters nach Beendigung der Ausführung des Verfahrens oder der Funktion entspricht. Die Applikation sendet auch zu einem Script, das dem Wert des Aktionsparameters entspricht, wenn die Webapplikations-Routinglogik kein Verfahren oder Funktion findet, das dem Wert des Aktionsparameters entspricht. In einer Implementierung entspricht ein Verfahren, Funktion oder Skript dem Wert des Aktionsparameters, wenn der Wert des Aktionsparameters ein Label oder zum Speichern verwendeter Name ist, Aufruf oder anderer Hinweis des entsprechenden Verfahrens, Funktion oder Skripts. Zum Beispiel entspricht ein Verfahren, das "authen" genannt wird, einem Aktionsparameter, eingestellt auf "authen".
2 zeigt ein Verfahren 200 zum Anwenden von Webapplikations-Routinglogik, um Webapplikations-Entwicklung durch im Wesentlichen Entkoppeln der Aufgaben bzw. Tasks des Anwender-Interface-Entwicklers von jenen des Backend-Entwicklers zu erleichtern. Die Webapplikations-Entwicklung beginnt durch Erzeugen einer Reihe von anfänglichen Scripts und Erzeugen eines Programms oder einer Klasse, die Webapplikations-Routinglogik enthält, und einige oder keine der Funktionen oder Verfahren, die für Wechselwirkungen mit Backend-Systemen (202) notwendig sind. Das anfängliche Script gibt dem Anwender des Kunden- Systems 110 künstliche oder simulierte Ergebnisse der Wechselwirkungen mit Backend-Systemen wieder.
Jedes Script ist mit einem Wert von dem Aktionsparameter 204 verbunden. In einer Implementierung wird das Assoziieren eines Scripts mit einem Wert des Aktionsparameters, einfach durch Einspeichern des Scripts unter einem File-Namen ausgeführt. Der File-Name des Scripts (ausschließlich Extension) ist der Wert des Aktionsparameters, der dem Script entspricht (zum Beispiel wenn das Script als "welcome.jsp" eingespeichert ist, ist der Wert des entsprechenden Aktionsparameters "welcome").
Im Verlauf der Applikations-Entwicklung erzeugt der Anwender-Interface-Entwickler neues Scripte 206 und assoziiert die neuen Scripte mit Werten des Aktionsparameters 208. Der Anwender-Interface-Entwickler braucht nicht auf den Backend-Entwickler zu warten, um die Backend-Integration und die entsprechende Steuerlogik vor dem Erzeugen von Scripts zu beenden. Nachdem ein Anwender-Interface-Entwickler ein neues Script erzeugt, sendet die Webapplikations-Routinglogik in der Klasse oder Programm automatisch zu dem Script, wenn eine HTTP-Anfrage einschließlich eines Aktionsparameters mit einem Wert entsprechend dem neuen Script von dem Kunden-System 110 empfangen wird. Die Webapplikations-Routinglogik entfernt den Bedarf, beim Hinzufügen eines neuen Scripts den Sender zu verändern oder zusätzlichen Code hinzuzufügen.
Wenn die Backend-Integration fortschreitet, erzeugt der Backend-Entwickler neue Funktionen oder Verfahren in der Klasse oder Programm 210 und ermöglicht die Ausführung von den neuen Funktionen oder Verfahren, um die Ausführung von Scripten durch einfaches Labeling, Benennen oder anderweitiges Assoziieren der neuen Verfahren oder Funktionen mit dem Wert des Aktionsparameters, der vorher mit den Scripts 212 assoziiert wurde, zu ersetzen. Die Scripts, die hier künstliche oder simulierte Ergebnisse von Wechselwirkungen mit Backend-Systemen wiedergeben, werden dabei durch neue Verfahren oder Funktionen ersetzt, die durch den Backend-Entwickler entwickelt wurden, die tatsächliche Wechselwirkungen mit den Backend-Systemen ausführen und die denselben oder andere Scripts zu vorliegenden tatsächlichen Ergebnissen der Wechselwirkungen mit den Backend-Systemen der Anwender instruieren. Typischerweise zeigen die anfänglichen Scripts Default-Werte von Variablen, bis sie durch eine neue Funktion oder Verfahren ersetzt werden. Die neue Funktion oder Verfahren tritt mit Backend-Systemen in Wechselwirkung, bezeichnet tatsächliche Werte mit den Variablen und sendet zu den gleichen anfänglichen Scripts, die den Anwendern nun die tatsächlichen anstatt die Default-Werte präsentiert.
Zum Beispiel kann beim Entwickeln einer auf Web basierenden Bank-Applikation ein Script manuell erzeugt werden, das dem Anwender eines künstlichen Bankzugang-Ausgleichs vorliegt, und kann in Antwort auf eine HTTP-Anfrage aus dem Kunden-System 110 ausgeführt werden, was einen Aktionsparameter, eingestellt auf "bankacct.", einschließt. Wenn der Backend-Entwickler das Verfahren oder Funktion beendet, das dem Webapplikations-System 130 Zugang zu tatsächlicher Bankkonto-Information von den Computer-Systemen der Bank (d. h. Backend-Systeme) erlaubt, wird die Ausführung des Scripts, das den künstlichen Bankkonto-Ausgleich wiedergibt, durch Ausführung des Verfahrens oder der Funktion, die die Präsentation von tatsächlichem Bankkonto-Ausgleich dem Anwender zugänglich macht und koordiniert. Das Verfahren oder Funktion, das die Präsentation des tatsächlichen Bankkonto-Ausgleichs für den Anwender zugänglich macht und koordiniert, wird einfach in die Webapplikation eingeschoben und markiert, benannt oder anders mit dem Aktionsparameterwert "bankacct." verbunden. Die Webapplikations-Routinglogik sichert, dass das Verfahren oder die Funktion anstatt des Scripts ausführt, wenn eine empfangene HTTP-Anfrage einen Aktionsparameter, eingestellt auf "bankacct.", einschließt.
Auf diese Weise ermöglicht die Webapplikations-Routinglogik die Anwender-Interfaceentwicklung 206, 208 von einer Webapplikation, im Wesentlichen entkoppelt von der Backendentwicklung 210, 212 von einer Webapplikation. Der Anwender-Interface-Entwickler ist in der Lage, das Anwender-Interface der Webapplikation relativ unabhängig von der Entwicklung der Kontroll-Logik und Backend-Integration zu entwickeln. Der Backend-Entwickler ist in der Lage, die Kontroll-Logik und Backend-Integration zu vervollständigen und glatt die entsprechenden Funktionen und Verfahren in das Programm oder Klasse der Webapplikation ohne wesentliches Modifizieren oder Unterbrechen des Anwender-Interface, das durch den An wender-Interface-Entwickler entwickelt wurde, zu modifizieren oder zu unterbrechen.
3A und 3B zeigen ein Verfahren 300 zur Anwendung von Webapplikations-Routinglogik, um auf die HTTP-Anfragen zu antworten. Der Einfachheit halber werden mit Bezug auf 1 beschriebene besondere Komponenten als ausführend für das Verfahren 300 bezeichnet. Jedoch ähnliche Methodologien können in anderen Implementierungen angewendet werden, wo verschiedene Komponenten verwendet werden, um die Struktur des Systems zu definieren, oder wo die Funktionalität anders unter den Komponenten, die in 1 gezeigt werden, verteilt wird. Weiterhin nimmt Verfahren 300 an, dass der HTTP-Antwort-Algorithmus der Webapplikation als eine Klasse anstatt als ein Programm implementiert ist. Jedoch kann die durch Verfahren 300 offenbarte Methodologie leicht auf Webapplikationen angewendet werden, worin der HTTP-Antwort-Algorithmus als ein Programm implementiert ist.
Das Verfahren 300 nimmt an, dass die Klasse instanziiert (d. h. geladen ist). Im Allgemeinen findet Umschreibung bzw. Instanziierung einer Klasse typischerweise bevor der Webapplikations-Server 130 HTTP-Anfragen bezüglich jener Klasse von dem Kunden-System 110 aufnimmt.
Das Kunden-System 110 sendet eine HTTP-Anfrage zu dem Webapplikations-System 130 (302). Die HTTP-Anfrage schließt einen gleichförmigen Resourcelocator (URL), einen Webkontext, einen Webapplikations-Namen und einen Aktionsparameter ein. Das Webapplikations-System 130 empfängt die HTTP-Anfrage 304 und identifiziert eine Klasse bezüglich des Webkontextes und die Webapplikation, ausgewiesen durch die HTTP-Anfrage 306. In einer Implementierung identifiziert das Webapplikations-System 130 eine Klasse, die mit dem Webkontext und dem Webapplikations-Namen in Beziehung steht, durch Zugreifen auf einen Datenspeicher, der Datensätze enthält mit gespeicherten Namen von Klassen und der indexiert sein kann oder auf den andersartig, basierend auf dem Webkontext und dem Webapplikations-Namen, zugegriffen werden kann.
Das Webapplikations-System 130 führt ein HTTP-Anfrageverfahren in der identifizierten Klasse 308 aus. Das HTTP-Anfrageverfahren ist ein Verfahren, das jederzeit eine HTTP-Anfrage ausführt, die einen Webkontext und einen Webapplikations-Namen, bezogen auf die identifizierte Klasse, die von dem Kunden-System 110 empfangen wird, einschließt. In dieser Implementierung enthält das HTTP-Anfrageverfahren die Webapplikations-Routinglogik. Dem Webapplikations-Entwickler wird typischerweise nicht verboten, die Inhalte des HTTP-Anfrageverfahrens zu editieren.
Das HTTP-Anfrageverfahren ruft (d. h. führt aus) ein Webapplikations-Serviceverfahren 310 auf. Das Webapplikations-Serviceverfahren ist im Gegensatz zu dem HTTP-Anfrageverfahren ein Verfahren, das durch den Webapplikations-Entwickler editiert werden kann. Das Webapplikations-Serviceverfahren wird zu der Zeit ausgeführt, wenn das HTTP-Anfrageverfahren ausgeführt ist (d. h. jederzeit wird eine HTTP-Anfrage einschließlich eines Webkontexts und ein Webapplikations-Name bezüglich der identifizierten Klasse von dem Kunden-System 110 empfangen). In einfachem Beispiel kann der Entwickler das Webapplikations-Anfrage-Verfahren zum Inkrementieren eines Widerspruchs kodieren und dabei die Anzahl von HTTP-Anfragen, die durch das Webapplikations-System 130 empfangen wurden, die einen Webkontext und einen Webapplikations-Namen bezüglich der identifizierten Klasse einschließen, zurückverfolgen.
Wenn das Webapplikations-Serviceverfahren das Ausführen beendet, kehrt das Webapplikations-System 130 zu dem HTTP-Anfrageverfahren zurück und führt die Webapplikations-Routinglogik 312 aus. Die Webapplikations-Routinglogik bestimmt, ob ein Verfahren in der identifizierten Klasse dem Wert des Aktionsparameters entspricht, der in die HTTP-Anfrage 314 enthalten ist. In einer Implementierung entspricht ein Verfahren in der identifizierten Klasse dem Wert des Aktionsparameters, wenn der Name des Verfahrens der gleiche ist wie der Wert des Aktionsparameters.
Wenn kein Verfahren in der identifizierten Klasse dem Wert des Aktionsparameters in der HTTP-Anfrage entspricht, sendet die Webapplikations-Routinglogik zu einem Script entsprechend dem Wert des Aktionsparameters 316. Das Webappli kations-System 130 macht Markup-Language-Code aus dem Script und schließt den Markup-Language-Code in eine HTTP-Antwort 318 ein. Die HTTP-Antwort wird zu dem Kunden-System 110 (324) gesendet.
Wenn ein Verfahren in der identifizierten Klasse dem Wert des Aktionsparameters in der HTTP-Anfrage entspricht, führt die Webapplikations-Routinglogik das Verfahren, das dem Wert des Aktionsparameters 320 entspricht, aus. Nach Beendigung des Verfahrens bestimmt die Webapplikations-Routinglogik, ob eine HTTP-Antwort durch das Verfahren 322 festgelegt war.
Wenn eine HTTP-Antwort durch das Verfahren festgelegt war, dann sendet die Webapplikations-Routinglogik die HTTP-Antwort zu dem Kunden-System 110 (324). Wenn keine HTTP-Antwort durch das Verfahren festgelegt war, dann sendet die Webapplikations-Routinglogik zu einem Script, das dem Wert des Aktionsparameters (316) entspricht. Das Webapplikations-System 130 macht Mark-up-Language-Code aus dem Script und schließt den Markup-Language-Code in eine HTTP-Antwort (318) ein, die dann zu dem Kunden-System 110 (324) gesendet wird.
Das Kunden-System 110 empfängt die HTTP-Antwort (326) und verarbeitet den Markup-Language-Code, um mit einem Anwender (328) zu kommunizieren. In einer weiteren Implementierung sendet ein Gateway anstatt des Kunden-Systems 110 HTTP-Anfragen (302), empfängt HTTP-Antwort (326) und verarbeitet den Markup-Language-Code, um mit einem Anwender des Kunden-Systems 110 (328) zu kommunizieren.
4 zeigt eine Implementierung 400 von dem Kommunikations-System von 1, gerichtet unter Anwendung von Webapplikations-Routinglogik, um eine flexible Plattform für auf Web basierende Sprachentwicklungs-Applikation bereitzustellen. Das Kommunikations-System 400 schließt eine Sprach-Kommunikations-Vorrichtung 410, ein Netzwerk 420, ein Sprach-Applikations-System 430 und ein Sprach-Gateway 440 ein. Die Sprach-Kommunikations-Vorrichtung 410 des Netzwerks 420 und das Sprach-Applikations-System 430 werden vorstehend, bezogen auf 1, weitläufig beschrieben. Insbesondere haben die Sprach- Kommunikations-Vorrichtung 410, das Netzwerk 420 und das Sprach-Applikations-System 430 typischerweise Eigenschaften, die mit jenen, beschrieben bezüglich des Kunden-Systems 110, des Netzwerks 120 und des Webapplikations-Systems 130, vergleichbar sind.
Die Sprach-Kommunikations-Vorrichtung 410 ist eine Vorrichtung, die mit einem Anwender zum Übertragen von Sprachsignalen über ein Netzwerk, wie zum Beispiel ein Festnetztelefon, ein drahtloses Telefon, ein unterstütztes personales digitales Hilfsmittel (PDA) oder ein sprachunterstützender Computer, in Wechselwirkung treten kann.
Das Netzwerk 420 kann ein kreislaufgeschaltetes Sprachnetzwerk, ein paketgeschaltetes Datennetzwerk oder ein beliebiges anderes Netzwerk sein, das Sprachen transportieren kann. Zum Beispiel können im Kreislauf geschaltete Sprachnetzwerke das öffentlich geschaltete Telefonnetzwerk (PSTN) einschließen und paketgeschaltete Datennetzwerke können Netzwerke, die auf Internetprotokoll (IP) oder asynchronen Übertragungsmodus (ATM) basieren, einschließen und können Sprache transportieren unter Verwendung von zum Beispiel Voice-over-IP, Voice-over-ATM oder anderen vergleichbaren Protokollen, die für Sprach-Kommunikationen verwendet werden.
Das Sprach-Applikations-System 430 schließt einen Sprach-Applikations-Server und alle Computer-Systeme ein, die Daten für den Sprach-Applikations-Server abgrenzen und bereitstellen. Das Sprach-Applikations-System 430 ist konfiguriert, um HTTP-Anfragen von dem Sprach-Gateway 440 zu empfangen, die HTTP-Anfragen gemäß einer auf Web basierenden Sprach-Applikation zu verarbeiten, die Webapplikations-Routinglogik einschließt, und schickt entsprechende HTTP-Antworten zu dem Sprach-Gateway 440. Die HTTP-Antworten, die zu dem Sprach-Gateway 440 gesendet wurden, schließen Sprach-Markup-Language-Code, wie zum Beispiel VoiceXML oder SALT-Code, ein, der durch das Sprach-Gateway 440 zum Kommunizieren mit einem Anwender der Sprach-Kommunikations-Vorrichtung 410 erzeugt wurde.
Das Sprach-Gateway 440 ist ein Gateway, konfiguriert, um Anwenderanrufe von Sprach-Kommunikations-Vorrichtungen 410 über das Netzwerk 420 zu empfangen und auf die Anwenderanrufe gemäß der auf Web basierenden Sprach-Applikation zu beantworten. Insbesondere erzeugt das Sprach-Gateway 440 HTTP-Anfragen, die auf einem Anwenderanruf basieren, sendet die HTTP-Anfragen zu dem Sprach-Applikations-System 430, empfängt entsprechende HTTP-Antworten aus dem Sprach-Applikations-System 430 und erzeugt den Sprach-Markup-Language-Code in den HTTP-Antworten, um mit dem Anrufer zu kommunizieren.
5 zeigt ein Kommunikations-System 500 ähnlich zu dem Kommunikations-System 400, jedoch unter genauerer Erläuterung einer Implementierung von dem Sprach-Applikations-System 430 und dem Sprach-Gateway 440. Das Kommunikations-System 500 schließt eine Sprach-Kommunikations-Vorrichtung 510, ein Netzwerk 520, ein Sprach-Applikations-System 530 und ein Sprach-Gateway 540 ein. Die Sprach-Kommunikations-Vorrichtung 510, das Netzwerk 520, das Sprach-Applikations-System 530 und das Sprach-Gateway 540 werden vorstehend breit mit Bezug auf 4 beschrieben. Insbesondere haben die Sprach-Kommunikations-Vorrichtung 510, das Netzwerk 520, das Sprach-Applikations-System 530 und das Sprach-Gateway 540 typischerweise Eigenschaften, die mit jenen bezüglich der Sprach-Kommunikationsrichtung 410, dem Netzwerk 420, dem Sprach-Applikations-System 430 und dem Sprach-Gateway 440 von 4 vergleichbar sind.
Das Sprach-Applikations-System 530 schließt einen Sprach-Applikations-Server 532 ein, der mit dem Sprach-Gateway 540, einer Datenspeicherung 534 und einem oder mehreren Backend-Systemen 536 kommuniziert. Der Sprach-Applikations-Server 532 stellt die Ausführungsumgebung für das Verarbeiten von auf Web basierender Sprach-Applikation bereit. Der Sprach-Applikations-Server 532 empfängt HTTP-Anfragen von dem Sprach-Gateway 540, verarbeitet die HTTP-Anfragen gemäß einer auf Web basierenden Sprach-Applikation, die Webapplikations-Routinglogik einschließt, und sendet entsprechende HTTP-Antworten, die Sprach-Markup-Language-Code zu dem Sprach-Gateway 540 einschließen. Der Sprach-Applikations-Server 532 kann lokal zu dem Sprach-Gateway 540 sein oder kann irgendwo über ein Netzwerk, das durch den Sprach-Gateway 540 zugänglich ist, lokalisiert sein.
Die Datenspeicherung 534 ist eine Speicherungs-Vorrichtung, die Files, die für die Ausführung der auf Web basierenden Sprach-Applikation bzw. Dateien notwendig sind, speichert. Solche Files können Script Files, Prompt-Files, Grammar-Files und Text-to-Speech(TTS)-Text-Files einschließen.
Script Files sind Text-Files, die die Scripts von der auf Web basierenden Sprach-Applikation speichern. Ein Script File schließt eine Reihe von eingebetteten Tags ein. Die Tags zeigen an, welcher Teil von dem Text-File einen Prompt, verwendet zum "Sprechen" zu dem Anrufer, definiert und welcher Teil einen Grammar definiert, der zum "Hören" und Verstehen der gesprochenen Antwort von dem Anrufer verwendet wird. Script-Files enthalten im Allgemeinen auch begrenzte Logik, die die Frequenz steuert, und Regeln dafür, wie auf die Bedingungen zu reagieren bzw. zu antworten ist, wie eine missverständliche Sprache oder ein Mangel von Sprache von dem Anrufer definiert. Die Script-Files werden durch den Sprach-Applikations-Server 532 verarbeitet, um den Sprach-Markup-Language-Code zu erzeugen. Der erzeugte Sprach-Markup-Language-Code wird dann in einer HTTP-Antwort zu dem Sprach-Gateway 540 zum weiteren Verarbeiten durch ein Interpreterprogramm 540b geschickt.
Prompt-, Grammar- und TTS-Text-Files sind durch das Interpreterprogramm 540b von dem Sprach-Gateway 540 zugänglich, wenn der Sprach-Markup-Language-Code verarbeitet wird, der eine HTTP-Antwort von dem Sprach-Applikations-Server 532 empfängt. Beim Ausführen einer Prompt-Anweisung geht das Interpreterprogramm 540b entweder zu einem Prompt-File, der Sprachdaten enthält, der direkt zu dem Anrufer "gesprochen" hat, oder alternativ Zugang zu TTS-Text-File, der zu dem Anwender über die Text-to-Speech-Maschine 540d von dem Sprach-Gateway 540 gesprochen wird. Audiodaten, gespeichert in Prompt-Files, können in WAV- oder andere Audiodatenformate formatiert werden. Beim Ausführen einer Grammar-Anweisung greift das Interpreterprogramm 540 Grammar-Files, die eine Spezifizierung von verschiedenen Wegen enthalten, in welchen ein Anrufer auf ein Prompt reagieren könnte. Grammar-Files können in einem üblichen Format vorlie gen, das spezifisch für die Spracherkennungsmaschine 540e ist, oder können zum Beispiel in Standard JAVA Grammar Specification Format (JGSF) oder Speech Recognition Grammar Specification 1.0 ausdehnbarer Markup-Language (XML) oder vergrößerte Backus-Naur-Formen (ABNF) sein.
Die Datenspeicherung 534 kann extern zu oder innerhalb des Sprach-Applikations-Servers 532 oder des Sprach-Gateways 540 angeordnet sein. Prompt- und Grammar-Files können an dem Gateway 540 zur Senkung der Zugriffszeit gecached bzw. zwischen gespeichert werden. Das Sprach-Gateway 540 kann auch die Prompt- und Grammar-Files von der Datenspeicherung 534 oder von dem Sprach-Applikations-Server 532 empfangen, der dieselben von der Datenspeicherung 534 enthält. Alternativ kann das Sprach-Gateway 540 die Prompt- und Grammar-Files von einem vollständig anderen Webserver empfangen.
Die Backend-Systeme 536 schließen Rechner-Systeme in der Rechnerumgebung des Sprach-Applikations-Servers 532 ein, der durch den Applikations-Server, um Daten zu erhalten, die zur Ausführung einer Sprach-Applikation notwendig sind, abgefragt werden.
Das Sprach-Gateway 540 schließt einen Telefonieservice und Signalverarbeitungs-Komponente 540a, ein Interpreterprogramm 540b, eine Audioplayback-Komponente 540c, eine Text-to-Speech-Erzeugungs-Komponente 540d, eine Spracherkennungsmaschine 540e und eine Kundenservice-Komponente 540f ein.
Hereinkommende Anrufer werden durch Telefonie und Signalverarbeitungs-Komponente 540a von dem Sprach-Gateway 540 beantwortet. Das Sprach-Gateway 540 wird in einer Weise ähnlich zu einem interaktiven Sprach-Antwort-(IVR)-System versorgt und ist gewöhnlich "stromabwärts" von einem privaten Verzweigungsaustausch (PBX) oder automatischen Rufdirektor (ACD) angeordnet. Diese Konfiguration erlaubt Anrufern, Übertragung von einem Live-Operator, wenn sie Wahrnehmungsprobleme haben, anzufragen. Das Sprach-Gateway 540 kann auch an der Verbraucherseite vor dem PBX oder ACD (um zu ersparen, mehrere Ports an dem PBX oder ACD kaufen zu müssen) angeordnet sein oder an den Endgeräten von einem dedizierten Applikations-Service-Provider (ASP).
Das Interpreterprogramm 540b ist für das Senden von HTTP-Anfragen zu und Empfangen von HTTP-Antworten von dem Sprach-Applikations-Server 532 und Verarbeiten von Sprach-Markup-Language-Code zum Kommunizieren mit einem Anrufer verantwortlich. Das Verarbeiten von Sprach-Markup-Language-Code zum Kommunizieren mit einem Anrufer schließt das Erzeugen von heraus gehender Sprache und Prompts unter Anwenden der Audioplayback-Komponente 540c, der Text-to-Speech-Erzeugungs-Komponente 540d von dem Sprach-Gateway 540 und Hören der gesprochenen Antworten von dem Anrufer unter Verwendung der Spracherkennungsmaschinen 540e ein. Der Spracherkennungsmaschine 540e ist ausgestattet mit oder hat Zugang zu Grammars, die die erwarteten Anrufer-Antworten zu einem gegebenen Prompt spezifizieren. Die Prompts, die in Antwort auf die gesprochene Eingabe von dem Anrufer erzeugt werden, variieren in Abhängigkeit von der Anrufer-Antwort und ob oder nicht es mit einem Grammar übereinstimmt. Auf diese Weise ist das Sprach-Gateway 540 in der Lage, eine Umwandlung mit dem Anrufer zu simulieren.
Im typischen Vorgang empfangen die Telefonieservices bzw. Telefoniedienste und Signalverarbeitungs-Komponente 540a von dem Sprach-Gateway 540 einen Ruf von einem Anrufer und erhalten Anrufer-Information. Die Kundenservice-Komponente 540f betrifft die Anrufer-Information (zum Beispiel automatische Nummer-Identifizierungs-(ANI)-Information) zu einem URL, einem Webkontext und einem Webapplikations-Namen und sendet eine HTTP-Anfrage einschließlich dem URL, dem Webkontext und dem Webapplikations-Namen (und gegebenenfalls einem Aktionsparameter) zu dem Sprach-Applikations-Server 532. Der Sprach-Applikations-Server 532 empfängt die HTTP-Anfrage, verarbeitet die HTTP-Anfrage gemäß einer auf Web basierenden Sprach-Applikation und sendet eine HTTP-Antwort, die den erzeugten Sprach-Markup-Language-Code zu dem Sprach-Gateway 540 einschließt. Das Sprach-Gateway 540 parst den empfangenen Sprach-Markup-Language-Code unter Verwendung des Interpreterprogramms 540b. Das Gateway 540 parst den Sprach-Markup-Language-Code durch Suchen und Ausführen von sprachspezifischen Anweisungen. Zum Beispiel kann die erste sprachspezifische Anweisung eine Prompt-Anweisung sein. Die Prompt-Anweisung kann entweder durch Zugreifen und Abspielen eines Audio- Files durch die Prompt-Anweisung oder durch Anwenden der Text-to-Speech-Erzeugungs-Komponente 540d zum Übersetzen und Abspielen von Text, der in der Prompt-Anweisung enthalten ist, ausgeführt werden.
Die nächste sprachspezifische Anweisung in dem Sprach-Markup-Language-Code kann zum Beispiel eine Grammar-Anweisung sein. Das Interpreterprogramm 540b des Gateways 540 verarbeitet die Grammar-Anweisung durch Übergeben der Kontrolle an die Spracherkennungsmaschine 540e, die dem Gateway 540 mitteilt, zu pausieren und auf die gesprochene Eingabe von dem Anrufer zu hören.
Nach Aufnehmen der gesprochenen Eingabe von dem Anrufer bestimmt die Spracherkennungsmaschine 540e, ob die gesprochene Eingabe mit dem Grammar, ausgewiesen durch die Grammar-Anweisung, konsistent ist. Wenn die gesprochene Eingabe mit dem Grammar konsistent ist, kann der Sprach-Markup-Language-Code direkt das Sprach-Gateway 540 zum Ausführen einer Prompt-Anweisung, die auf die Eingabe zugeschnitten ist, richten. Wenn die gesprochene Eingabe nicht mit dem Grammar konsistent ist, kann der Sprach-Markup-Language-Code das Sprach-Gateway 540 richten, um eine andere Prompt-Anweisung auszuführen, die den Anrufer informiert, dass das System den Anrufer nicht versteht.
Das Interpreterprogramm 540b setzt das Parsen und Verarbeiten des Sprach-Markup-Language-Codes auf diese Weise fort. Wenn das Script vollständig ist und die notwendigen Antworten von dem Anrufer gesammelt werden, sammelt der Interpreter 540b dieselben in einer HTTP-Anfrage, die zu dem Sprach-Applikations-Server 532 gesendet wird. Der Sprach-Applikations-Server 532 verarbeitet die HTTP-Anfrage und kann zu dem Sprach-Gateway 540 gesendet werden, was den Sprach-Markup-Language-Code in eine weitere HTTP-Antwort überführt.
6A und 6B zeigen ein Verfahren 600 zum Anwenden von Webapplikations-Routinglogik, um Kommunikationen mit einem Anwender von einer Sprach-Kommunikations-Vorrichtung 510 nach Aufnehmen eines Anrufs von dem Anwender zu beginnen. Zur Vereinfachung werden die einzelnen Komponenten, die be züglich 5 beschrieben sind, als ausführend für das Verfahren 600 bezeichnet. Jedoch können ähnliche Methodologien in anderen Implementierungen angewendet werden, wo andere Komponenten verwendet werden, um die Struktur des Systems zu definieren, oder wo die Funktionalität unter den durch 5 gezeigten Komponenten verschieden verteilt ist. Weiterhin nimmt Verfahren 600 an, dass der HTTP-Antwort-Algorithmus von der auf Web basierenden Sprach-Applikation als eine Klasse anstatt als ein Programm implementiert ist. Jedoch kann die durch Verfahren 600 offenbarte Methodologie ähnlich auf Webapplikationen angewendet werden, worin der HTTP-Antwort-Algorithmus als ein Programm implementiert ist.
Der Anwender der Sprach-Kommunikations-Vorrichtung 510 macht einen Anruf und der Anruf wird zu dem Sprach-Gateway 540 durch einen Telekommunikations-Serviceprovider (602) geroutet. Das Sprach-Gateway 540 nimmt den Anruf an und identifiziert ein URL, einen Webkontext und einen Webapplikations-Na-men, der auf der Anrufer-Information (604) basiert. Die Anrufer-Information kann die Telefonnummer des Anrufers (d. h. die Telefonnummer des Anwenders der Sprach-Kommunikations-Vorrichtung 510), die der Anrufer gewählt hat (zum Beispiel durch gewählte Nummeridentifizierungsdienst (DNIS)) und/oder beliebige Informationen, die durch Zugangsspeicherungen, basierend auf der Telefonnummer des Anrufers, basierend auf anderen ANI-Daten oder basierend auf DNIS-Daten, abgeleitet sein können. Das URL, der Webkontext und der Webapplikations-Name können zum Beispiel durch Zugreifen auf lokale oder entfernte Datenspeicherung bezüglich URL, Webkontexts und Webapplikations-Namen an die Telefonnummern der Anrufer bestimmt werden. Das Sprach-Gateway 540 sendet eine HTTP-Anfrage, die das URL, den Webkontext, den Webapplikations-Namen und gegebenenfalls einen Aktionsparameter zu dem Sprach-Applikations-Server 532 (606) einschließt.
Der Sprach-Applikations-Server 532 empfängt die HTTP-Anfrage (608) und identifiziert eine Klasse, bezogen auf den Webkontext und den Webapplikations-Namen in der HTTP-Anfrage (610). Der Sprach-Applikations-Server 532 bestimmt, ob die Klasse instanziiert ist (612).
Wenn die Klasse noch nicht instanziiert ist, instanziiert der Sprach-Applikations-Server 532 die Klasse (614). Der Sprach-Applikations-Server führt dann ein Initialisierungsverfahren in der Klasse (616) aus. Das Initialisierungsverfahren ist ein Verfahren, das ausgeführt ist, wenn die Klasse instanziiert ist. Das Initialisierungsverfahren lädt typischerweise Ressourcen, wie Logging-Systemressourcen, die zum Beispiel Webapplikations-Log-Information ziehen, und Konfigurations-Systemressourcen, die zum Beispiel Parameter und Eigenschaftswerte, die in der Webapplikation angewendet werden, initialisieren können. Das Initialisierungsverfahren kann auch ein Default-Initialscript einstellen, das unter bestimmten Bedingungen (siehe nachstehende Vorgänge 626 bis 644) zum Erstellen eines Anfangs-Dialogs mit dem Anwender der Sprach-Kommunikations-Vorrichtung 510 verarbeitet wird. In der Implementierung, die in 6A und 6B gezeigt wird, kann das Initialisierungsverfahren das fehlende Anfangsscript durch Zugreifen eines Werts auf einen SetInitialPage-Parameter spezifizieren. Zum Beispiel kann das Initialisierungsverfahren den Wert des "DefaultIndex" zu dem SetInitialPage-Parameter zuweisen. Das fehlende Initialscript ist dann "DefaultIndex.jsp". Dem auf Web basierenden Sprach-Applikations-Entwickler wird typischerweise nicht erlaubt, den Inhalt des Initialisierungsverfahrens zu editieren.
Das Initialisierungsverfahren ruft auch ein Sprach-Applikations-Initialisierungsverfahren (618) auf. Das Sprach-Applikations-Initialisierungsverfahren ist im Gegensatz zum Initialisierungsverfahren ein Verfahren, das durch den auf Web basierenden Sprach-Applikations-Entwickler editiert werden kann. Das Sprach-Applikations-Initialisierungsverfahren wird jederzeit ausgeführt, wenn das Initialisierungsverfahren ausgeführt wird (d. h. jedes Mal, wenn die entsprechende Klasse instanziiert wird). Das Sprach-Applikations-Initialisierungsverfahren kann durch den auf Web basierenden Sprach-Applikations-Entwickler editiert werden, um Login-Systemressourcen und Konfigurations-Systemressourcen zu laden, die spezifisch für die auf Web basierende Sprach-Applikation sind. Der auf Web basierende Sprach-Applikations-Entwickler kann das Sprach-Applikations-Initialisierungsverfahren zu der Veränderung des Werts des fehlenden Initialscripts durch Zuweisen eines neuen Werts zu dem SetInitialPage-Parameter (zum Beispiel kann der SetInitialPage-Parameter dem neuen Wert von "InitialWelcomePage", das dem Initialscript entspricht, genannt "InitialWelcomePage.jsp" zugeordnet werden) editieren.
Nach Beendigung des Sprach-Applikations-Initialisierungsverfahrens führt der Sprach-Applikations-Server 532 ein HTTP-Anfrageverfahren (620) aus. Der Sprach-Applikations-Server 532 führt auch das HTTP-Anfrageverfahren aus, wenn die identifizierte Klasse bereits instanziiert ist. Wie mit Bezug auf Verfahren 300 vorher erörtert, wird das HTTP-Anfrageverfahren jederzeit ausgeführt, eine HTTP-Anfrage wird empfangen. Das HTTP-Anfrageverfahren ruft ein Sprach-Applikations-Serviceverfahren (622) auf. Das Sprach-Applikations-Serviceverfahren ist ähnlich zu dem Webapplikations-Serviceverfahren, jedoch auf die Bedürfnisse und Erfordernisse der Sprach-Applikationen gerichtet.
Wenn das Sprach-Applikations-Serviceverfahren das Ausführen beendet, kehrt der Sprach-Applikations-Server 532 zu dem HTTP-Anfrageverfahren zurück und führt Webapplikations-Routinglogik (624) aus. Die Webapplikations-Routinglogik bestimmt, ob ein Aktionsparameter in die HTTP-Anfrage (626) eingeschlossen ist. Wenn ein Aktionsparameter in die HTTP-Anfrage eingeschlossen ist, dann verläuft das Verfahren 600 zu Vorgängen 720 bis 736, wie in 7A und 7B gezeigt und nachstehend erläutert (628).
Wenn kein Aktionsparameter in die HTTP-Anfrage eingeschlossen war, dann bestimmt die Webapplikations-Routinglogik, ob es ein Verfahren gibt, das "Index" in der Klasse (630) genannt wird. Wenn es kein Verfahren genannt "Index" in der Klasse gibt, sendet die Webapplikations-Routinglogik zu einem Script entsprechend dem Wert des SetInitialPage-Parameters, der in dem Initialisierungsverfahren oder in dem Sprach-Applikations-Initialisierungsverfahren (616 oder 618 vorstehend) (632) angegeben ist. Der Sprach-Applikations-Server 532 macht den Markup-Language-Code von dem Script und schließt den Markup-Language-Code in einer HTTP-Antwort (634) ein, die dann zu dem Sprach-Gateway 540 (640) gesendet wird.
Wenn es ein Verfahren, genannt "Index", in der Klasse gibt, führt die Webapplikations-Routinglogik das Verfahren, genannt "Index", (636) aus. Die Webapplikati ons-Routinglogik erlaubt es somit einem auf Web basierenden Sprach-Applikations-Entwickler, Vorgänge in einem Verfahren, genannt "Index", zu definieren, das bei einer Zeit stattfinden wird, bei der ein neuer Dialog mit einem Anwender von der Sprach-Kommunikations-Vorrichtung 510 gestartet wird. Die Webapplikations-Routinglogik bestimmt, ob eine HTTP-Antwort durch das Verfahren, genannt "Index", (638) festgelegt ist.
Wenn eine HTTP-Antwort durch das Verfahren, genannt "Index", festgelegt war, dann sendet die Webapplikations-Routinglogik die HTTP-Antwort zu dem Sprach-Gateway 540 (640). Wenn keine HTTP-Antwort durch das Verfahren festgelegt war, dann sendet die Webapplikations-Routinglogik zu einem Script, das dem Wert von dem SetInitialPage-Parameter (632) entspricht, macht die Sprach-Markup-Sprache von dem Script (634) und sendet eine HTTP-Antwort zu dem Sprach-Gateway 540 (640).
Der Sprach-Gateway 540 empfängt die HTTP-Antwort von dem Sprach-Applikations-Server 532 (642) und verarbeitet den Sprach-Markup-Language-Code, um einen Dialog mit dem Anwender der Sprach-Kommunikations-Vorrichtung 510 unter Anwendung von Prompts und Grammars (644) herzustellen. Der Anwender der Sprach-Kommunikations-Vorrichtung 510 kommuniziert mit dem Sprach-Gateway durch Reagieren auf die Prompts (646).
7A und 7B zeigen ein Verfahren 700 zum Anwenden von Webapplikations-Routinglogik, um mit einem Anwender von einer Sprach-Kommunikations-Vorrichtung 510 zu kommunizieren. Der Einfachheit halber werden besondere Komponenten, beschrieben bezüglich 5, als ausführend für das Verfahren 700 angeführt. Jedoch ähnliche Methodologien können in anderen Implementierungen angewendet werden, wo verschiedene Komponenten verwendet werden, um die Struktur des Systems zu definieren, oder wo die Funktionalität verschieden unter den durch 5 gezeigten Komponenten verteilt ist. Weiterhin nimmt Verfahren 700 an, dass der HTTP-Antwort-Algorithmus von der auf Web basierenden Sprach-Applikation als eine Klasse anstatt als ein Programm implementiert ist. Jedoch die durch das Verfahren 700 offenbarte Methodologie kann in ähnlicher Weise auf Webapplikationen angewendet werden, worin der HTTP-Antwort-Algorithmus als ein Programm implementiert ist.
Der Anwender der Sprach-Kommunikations-Vorrichtung 510 kommuniziert mit dem Sprach-Gateway 540 durch Reagieren auf Prompts (702). Das Sprach-Gateway 540 sammelt Anwender-Antworten, falls überhaupt gemäß dem Sprach-Markup-Language-Code, der das Sprach-Gateway 540 verarbeitet (704) und eine HTTP-Antwort erzeugt, die ein URL, einen Webkontext, einen Webapplikations-Namen, einen Aktionsparameter und in einigen Implementierungen zusätzliche Parameter entsprechend den Antworten, die vom Anwender der Sprach-Kommunikations-Vorrichtung 510 (706) empfangen werden, enthält. Das Sprach-Gateway 540 sendet dann die HTTP-Anfrage an den Sprach-Applikations-Server 532 (708).
Zum Beispiel kann das Sprach-Gateway 540 durch Sprach-Markup-Language-Code, der von einem Script genannt "getUser.jsp" erzeugt wird, das anfragt, dass der Anwender der Sprach-Kommunikations-Vorrichtung 510 eine Anwenderidentifikation (ID) und ein Anwenderpasswort vorlegt. Der Anwender legt das Anwender-ID (zum Beispiel "sue") und das Anwenderpasswort (zum Beispiel "123") unter Verwendung der Sprach-Kommunikations-Vorrichtung 510 vor und der Sprach-Markup-Language-Code instruiert das Sprach-Gateway 540, die nachfolgende entsprechende HTTP-Anfrage:
http://www.mysite.com/mycontext/myapp?action=authen&user=sue&passwort=12 3, zu generieren und zu dem Sprach-Applikations-Server 532 zu senden.
In diesem Beispiel schließt die HTTP-Anfrage ein URL entsprechend "www.mysite.com", einen Webkontext entsprechend "mycontext", einen Webapplikations-Namen entsprechend "myapp", einen Aktionsparameter eingestellt auf "authen" und zwei zusätzliche Parameter "user" und "password", eingestellt auf "sue" bzw. "123", ein.
Der Sprach-Applikations-Server empfängt die HTTP-Anfrage von dem Sprach-Gateway 540 (710) und identifiziert eine Klasse bezüglich des Webkontexts und des Webapplikations-Namens, der durch die HTTP-Anfrage (712) ausgewiesen ist. In einer Implementierung identifiziert der Sprach-Applikations-Server 532 eine Klasse bezüglich des Webkontexts und des Webapplikations-Namens durch Zugreifen auf einen Datenspeicher, der Daten enthält, die Speichernamen von Klassen aufzeichnen, und der indexiert sein kann oder anders, basierend auf Webkontext und Webapplikations-Namen, zugänglich ist.
Der Sprach-Applikations-Server 532 führt ein HTTP-Anfrageverfahren in der identifizierten Klasse (714) aus. Wie vorstehend mit Bezug auf Verfahren 300 erörtert, wird das HTTP-Anfrageverfahren jedes Mal, wenn eine HTTP-Anfrage empfangen ist, ausgeführt. Das HTTP-Anfrageverfahren ruft ein Sprach-Applikations-Serviceverfahren (716) auf. Das Sprach-Applikations-Serviceverfah-ren ist ähnlich zu dem Webapplikations-Serviceverfahren, jedoch speziell auf Sprache ausgerichtet.
Wenn das Sprach-Applikations-Serviceverfahren das Ausführen beendet, kehrt der Sprach-Applikations-Server 532 zu dem HTTP-Anfrageverfahren zurück und führt die Webapplikations-Routinglogik (718) aus. Das HTTP-Anfrageverfahren ist ein Verfahren, das jedes Mal eine HTTP-Anfrage ausführt, die einen Webkontext einschließt und ein Webapplikations-Name, bezüglich der identifizierten Klasse, wird von dem Kunden-System 110 empfangen. Bei dieser Implementierung schließt das HTTP-Anfrageverfahren die Webapplikations-Routinglogik ein. Dem Webapplikations-Entwickler wird typischerweise nicht erlaubt, den Inhalt von dem HTTP-Anfrageverfahren zu editieren.
Die Webapplikations-Routinglogik bestimmt, ob ein Verfahren in der ausgewiesenen Klasse dem Wert des Aktionsparameters entspricht, der in die HTTP-Anfragen (720) eingeschlossen ist. In einer Implementierung entspricht ein Verfahren in der identifizierten Klasse dem Wert des Aktionsparameters, wenn der Name des Verfahrens der gleiche ist wie der Wert des Aktionsparameters.
Wenn kein Verfahren in der ausgewiesenen Klasse ist, das dem Wert des Aktionsparameters in der HTTP-Anfrage entspricht, sendet die Webapplikations-Routinglogik zu einem Script, das dem Wert des Aktionsparameters (722) ent spricht. Der Sprach-Applikations-Server 532 erzeugt Markup-Language-Code aus dem Script und schließt den Markup-Language-Code in eine HTTP-Antwort (724) ein. Die HTTP-Antwort wird zu dem Sprach-Gateway 540 (730) geschickt.
Wenn ein Verfahren in der identifizierten Klasse dem Wert des Aktionsparameters in der HTTP-Anfrage entspricht, führt die Webapplikations-Routinglogik das Verfahren aus, das dem Wert des Aktionsparameters (726) entspricht. Nach Beendigung des Verfahrens bestimmt die Webapplikations-Routinglogik, ob eine HTTP-Antwort durch das Verfahren (728) festgelegt ist. Wenn eine HTTP-Antwort durch das Verfahren festgelegt war, dann sendet die Webapplikations-Routinglogik die HTTP-Antwort zu dem Sprach-Gateway 540 (730). Wenn keine HTTP-Antwort durch das Verfahren festgelegt war, dann sendet die Webapplikations-Routinglogik zu einem Script, das dem Wert des Aktionsparameters (722) entspricht. Der Sprach-Applikations-Server 532 erzeugt Markup-Language-Code aus dem Script und schließt den Markup-Language-Code in eine HTTP-Antwort (724) ein, die dann zu dem Sprach-Gateway 540 (730) geschickt wird.
Das Sprach-Gateway 540 empfängt die HTTP-Antwort (732) und verarbeitet den Sprach-Markup-Language-Code, um einen Dialog mit dem Anwender der Sprach-Kommunikations-Vorrichtung 510 unter Anwendung von Prompts und Grammars (743) fortzusetzen. Der Anwender der Sprach-Kommunikations-Vorrichtung 510 kommuniziert mit dem Sprach-Gateway 540 durch Antworten auf die Prompts (736).
In einer Implementierung der Verfahren 600 und 700 werden die Scripte unter Anwendung von Java-Server-Pages und VoiceXML geschrieben und der HTTP-Antwort-Algorithmus wird in Java^TM als eine Klasse geschrieben, die eine Grundklasse ausdehnt, die wiederum die javax.servlet.http.HttpServlet-Klasse ausdehnt. Die Klasse schließt das Sprach-Applikations-Initialisierungsverfahren, das Sprach-Applikations-Serviceverfahren und Verfahren, definiert durch den auf Web basierenden Sprach-Applikations-Entwickler, ein. Die Grundklasse schließt das Initialisierungsverfahren und das HTTP-Anfrageverfahren ein. Das Initialisierungsverfahren ist das Init-Verfahren von dem javax.servlet.http.HttpServlet mit Modifizierungen, die zum Laden von Ressourcen und zum Einstellen der anfangs fehlenden Seite dienen. Das HTTP-Anfrageverfahren ist das Serviceverfahren von dem javax.servlet.http.HttpServlet mit Modifizierungen, die zum Implementieren der Webapplikations-Routinglogik dienen. Die Klasse wird typischerweise durch den auf Web basierenden Sprach-Applikations-Entwickler codiert. Aufgrund des Codierens der Basis bleibt die Klasse konstant zwischen der auf Web basierenden Sprach-Applikation (d. h. die Webapplikations-Routinglogik bleibt die gleiche ungeachtet der auf Web basierenden Sprach-Applikation, worin sie angewendet wird). Die Grundklasse kann mit dem auf Web basierenden Sprach-Applikations-Entwickler durch einen dritten Teil bereitgestellt werden.
Eine Vielzahl von Implementierungen wurde beschrieben, trotzdem wird es verständlich sein, dass verschiedene Modifizierungen erfolgen können. Zum Beispiel kann die Webapplikations-Routinglogik zum Koordinieren der Ausführung von allgemeinen Prozeduren in einem Programm angewendet werden und ist nicht auf das Koordinieren der Ausführung von nur Verfahren und Funktionen begrenzt. Folglich liegen andere Implementierungen innerhalb des Umfangs der nachstehenden Ansprüche.

Claims

Computer implementiertes Verfahren für einen Webapplikations-Computer (130) mit: Empfang einer Anfrage, die einen Aktionsparameter (304) enthält; Identifizieren bzw. Erkennen einer Prozedur, die mit dem Wert des Aktionsparameters (314) in Verbindung steht; wenn eine Prozedur identifiziert ist, Ausführen der identifizierten Prozedur (320); und wenn eine Prozedur nicht identifiziert ist, Senden zu einem Script (316), das mit dem Wert des Aktionsparameters in Verbindung steht.
Verfahren nach Anspruch 1, wobei die Prozedur ein Verfahren in einer Objekt-orientierten Programmiersprache ist.
Verfahren nach Anspruch 1, wobei die Prozedur eine Funktion ist, die in einer prozeduralen Programmiersprache eingesetzt wird.
Verfahren nach Anspruch 1, wobei Identifizieren einer Prozedur, die mit dem Wert des Aktionsparameters in Verbindung steht, Durchsuchen einer Gruppe von Prozeduren in einem Programm nach einer Prozedur, die mit dem Wert des Aktionsparameters in Verbindung steht, umfasst.
Verfahren nach Anspruch 4, wobei das Durchsuchen einer Gruppe von Prozeduren in einem Programm das Durchsuchen einer Gruppe von Prozeduren in einem Programm nach einer Prozedur, die einen Namen gleich dem Wert des Aktionsparameters aufweist, umfasst.
Verfahren nach Anspruch 4, wobei das Durchsuchen einer Gruppe von Prozeduren das Durchsuchen einer Gruppe von Verfahren in einer Klasse nach einem Verfahren, das mit dem Wert des Aktionsparameters in Verbindung steht, umfasst.
Verfahren nach Anspruch 6, wobei das Durchsuchen einer Gruppe von Prozeduren das Durchsuchen einer Gruppe von Verfahren in einer Klasse nach einem Verfahren, das mit dem Wert des Aktionsparameters in Verbindung steht, und welches in Java^TM programmiert ist, umfasst.
Verfahren nach Anspruch 4, wobei das Durchsuchen einer Gruppe von Prozeduren das Durchsuchen einer Gruppe von Funktionen in einem Programm nach einer Funktion, die mit dem Wert des Aktionsparameters in Verbindung steht, umfasst.
Verfahren nach Anspruch 8, wobei das Durchsuchen einer Gruppe von Prozeduren das Durchsuchen einer Gruppe von Funktionen in einem Programm nach einer Funktion, die mit dem Wert des Aktionsparameters in Verbindung steht, und in Perl programmiert ist, umfasst.
Verfahren nach Anspruch 1, wobei das Senden zu einem Script, das mit dem Wert des Aktionsparameters in Verbindung steht, das Senden zu einem Script, gesichert bzw. gespeichert unter einem Dateinamen, entsprechend dem Wert des Aktionsparameters, umfasst.
Verfahren nach Anspruch 1, wobei das Identifizieren einer Prozedur das Durchsuchen einer Gruppe von Prozeduren in einem Programm nach einer Prozedur, die mit dem Wert des Aktionsparameters in Verbindung steht, und Code enthält, der Applikationssteuerlogik implementiert, umfasst.
Verfahren nach Anspruch 1, wobei das Identifizieren einer Prozedur das Durchsuchen einer Gruppe von Prozeduren in einem Programm nach einer Prozedur, die mit dem Wert des Aktionsparameters in Verbindung steht, und Code enthält, der Kommunikationen mit Backend-Systemen ermöglicht, umfasst.
Verfahren nach Anspruch 1, wobei das Senden zu einem Script das Senden zu einem Script, das mit dem Wert des Aktionsparameters in Verbindung steht, und Code enthält, der Präsentations-Logik implementiert, umfasst.
Computer-System, umfassend: einen Webapplikations-Computer (130), konfiguriert zum: Empfang einer Anfrage, die einen Aktionsparameter (304) enthält, Identifizieren einer Prozedur, die mit dem Wert des Aktionsparameters in Verbindung steht (314); Ausführen der Prozedur, wenn eine Prozedur identifiziert ist (320); und Senden zu einem Script, das mit dem Wert des Aktionsparameters in Verbindung steht, wenn eine Prozedur nicht identifiziert ist (326).
Computer-System nach Anspruch 14, wobei der Webapplikations-Computer außerdem zum Senden einer Antwort konfiguriert ist.
Computer-System nach Anspruch 14, außerdem umfassend einen Gateway-Computer, der ein Gateway enthält, konfiguriert zur Kommunikation mit einer drahtlosen Kommunikationsvorrichtung.
Computer-System nach Anspruch 16, wobei der Gateway-Computer ein drahtloses Applikations-Protokoll-Gateway ist.
Computer-System nach Anspruch 14, außerdem umfassend einen Gateway-Computer, der ein Sprach-Gateway enthält, konfiguriert zur Kommunikation mit einer Sprach-Kommunikationsvorrichtung.
Computer-System nach Anspruch 14, wobei der Webapplikations-Computer zum Senden zu einem Script, einschließlich einer Markup-Sprache, verwendet zur Kommunikation mit einer drahtlosen Kommunikationsvorrichtung, konfiguriert ist.
Computer-System nach Anspruch 14, wobei der Webapplikations-Computer weiterhin konfiguriert ist zum Senden zu dem Script, nach Ausführung der Prozedur, wenn eine Ausführung der Prozedur nicht zu einer Antwort führt, die entsendet wurde.