6941562
Abstract
The present invention permits a JavaScript-based Remote Procedure Call (RPC) to be executed from a Web page displayed in a Web browser window, without utilizing browser plug-in, Java Applet, or ActiveX technology. Traditionally, clunky downloads and Web browser plug-ins has been required to enable Web page interactivity, which greatly compromises the performance and reach of the Web page. Based purely on HTML and JavaScript, the present invention utilizes the HTML
Claims
1. A method for executing an RPC (Remote Procedure Call) over HTTP from a Web page within an application window at a client device, the method comprising:
containing, in the application window of the client device, at least one Web page;
transmitting, to a server, an HTTP request initiated by a first HTML element embedded in a main window of the at least one Web page, said first HTML element including a URL;
invoking, at a server, a procedure or a set of program code identified by the URL of said first HTML element;
receiving, at a Web browser from said server in the transmitting action, output of said procedure or program code in the invoking action into a second HTML
2. A method as defined in claim 1, wherein said application window is a Web browser window.
3. A method as defined in claim 2, said first HTML element in the transmitting action and said second HTML element in the receiving action are contained within the same Web page.
4. A method as defined in claim 2, said first HTML element in the transmitting action and said second HTML element in the receiving action are contained within different Web pages, at least one of which is hosted by a different server.
5. A method as defined in claim 1, wherein said first HTML element in the transmitting action is an HTML
6. A method as defined in claim 5, wherein said first HTML element in the transmitting action is the same as the second HTML
7. A method as defined in claim 1, wherein said first HTML element in the transmitting action is an HTML
8. A method as defined in claim 1, wherein said first HTML element in the transmitting action is an HTML
Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to making JavaScript-based remote function calls from a Web page to one or more remote Web server(s).
2. Description of the Related Art
The Internet is a computer network that provides access to the World Wide Web ("the Web"), a vast collection of pages comprised of text, graphical, multimedia elements, and embedded programs ("client-side scripting"). Graphical user interface programs called Web browsers are employed by Internet users to receive, or download, the Web pages from servers and display the pages at their client computers. A Web browser displays Web pages by showing the text and graphical elements on a client display screen, by playing sound files and showing video sequences, and by running the embedded programs.
The rapid increase in the number of Internet users and in the amount of information being downloaded by users has resulted in high volumes of traffic that overload web servers, as well as increasing delays in downloading Web pages. Delays in downloading and displaying pages make an Internet user's browsing experience less enjoyable. This is especially true for Internet users who do not have high-speed access to the Internet. The response time for the transfer and displaying of page elements between servers and clients could be improved if the amount of data traffic passing over the Internet could be reduced, and more server computing tasks could be offloaded to the clients.
To download a Web page, a user at a client machine requests a Web page by sending a Web page address to the corresponding Web server. A Web page address is specified by a uniform resource locator (URL). When the Web server receives the URL request from a client machine, it determines the format and elements of the requested Web page and constructs a text file according to the hypertext mark-up language (HTML) standard. The HTML file specifies the text to be written and the Web page elements, such as URLs for image files that are to be viewed or displayed, and the format in which they should be presented. The server sends the HTML text file to the client machine, along with any corresponding data files specified by the HTML code.
At the client machine, the user's Internet browser receives the HTML code and automatically renders the page elements, displaying the text data, running the embedded programs, and sending further requests for files specified by URLs in the HTML code. The requests for files may include, for example, image files at servers other than the server from which the original HTML code was received. Thus, it should be apparent that displaying a single Web page may involve many different requests for data and numerous transfers of data between the client machine and one or more Web servers.
One contributor to the excessive Internet traffic that is slowing down the Web is the requirement for reloading of Web pages. Typically, each time a user "visits" a Web page by requesting its contents, that user's Web browser must reload the page data by requesting the entire HTML code and the corresponding data elements. Although some Web pages have a large number of elements that change frequently, it is more typical for a page to be largely static. That is, most of the page elements will not change. The download of Web pages could proceed much more smoothly if more elements of a Web page did not need to be transferred from a server each time the page makes a request.
Once a Web page is downloaded to a client computer's browser, there is no connection maintained with the Web server. In order to communicate with the Web server, the browser must refresh the entire page. This greatly limits how Web pages flow and its design, and results in much redundant data transmission.
The limitations of HTML are most pronounced when moving existing client-server applications to an HTML interface. Suddenly the entire user interface must be reengineered to conform to the page-by-page flow of HTML. Specifically, in bringing client-server applications onto the Web, a lot of unnecessary network traffic is added, and servers are burdened with most of the computing tasks. A better way would be to transfer only the necessary data and offload as many repetitive or resource-consuming computing tasks to the client's computer. Currently, however, Web servers must resend entire Web pages, which include the retransmission of many duplicated page components, and carry out mostly all computing tasks.
There is some effort in trying to fix this flawed Web-based client-server model. The Microsoft Corporation has a technology called "Remote Scripting", which uses a Java Applet at the Web page acting as a proxy of communication. Now the Web page can either receive more information from the Web server or send information back by calling a function: RSExecute( ) without refreshing the entire page. For detailed information on Microsoft's Remote Scripting, refer to Microsoft's website: http://msdn.microsoft.com/scripting/default.htm?/scripting/RemoteScripting/default.htm. Even after several years of promotion by Microsoft, Remote Scripting technology has not been widely adopted by Web developers. There are several reasons for this:
- 1. Slow: In order to use Remote Scripting, each Web page must include a Java Applet, acting as the client-side proxy, which must start Java Virtual Machine on the client's computer once the page is loaded. This is a slow process that introduces a 3-8 second delay in displaying the page for most personal computers.
- 2. Limited Server Compatibility: Remote Scripting only supports Microsoft Web server software, such as Internet Information Server, which must run on a Microsoft operating system, such as NT. Most high traffic and established commercial Websites use some variation of the Unix operating system and non-Microsoft Web server software, such as Apache. Therefore, most high traffic and established commercial websites cannot take advantage of Microsoft's Remote Scripting.
- 3. Single Server Access: Remote Scripting can only execute remote function calls back to the Web server that originally served the Web page. It cannot therefore make remote function calls to any other Web servers.
NetGratus, Inc. has already developed several generations of its own Remote Scripting technology that does not require a Java Applet to act as a proxy at the Web page. The previous generation of NetGratus Remote Scripting used a hidden
The previous generation of NetGratus Remote Scripting still had significant limitations. It could not make remote function calls to other Web server except to the Web server from which that Web page originated from. The main reason this is that the
From the discussion above, it should be apparent that there is a need for better means of making remote function calls from a Web page to remote Web servers. The method for remote function calls from a Web page should be easy to use, compatible with most server platforms, small in size (kilobytes), quick to load, and able to make function calls to multiple Web servers of different origins. The present invention fulfills this need.
BRIEF SUMMARY OF THE INVENTION
The invention permits a Web page to make JavaScript-based function calls (or RPC, Remote Procedure Call) from either Netscape or Microsoft Web browsers to remote Web servers of different origins. In accordance with the invention, the browser displays a Web page containing at least one JavaScript library acting as the client-side Web page proxy for the RPC. This client-side proxy essentially uses the
Upon a trigger event, such as a mouse-over or a button click, the Web page will make a remote function call through the client-side proxy. The client-side proxy packages the remote function call into a URL, then sets the
Other features and advantages of the present invention should be apparent and will be better understood by reference to the drawings and the following detailed description, which illustrate, by way of example, the principles of the invention.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING
FIG. 1 shows a system having a Web page on client computer and Web server constructed in accordance with the present invention.
DETAILED DESCRIPTION OF THE INVENTION
Typically, a Web page communicates back to the server when the user clicks the submit button on an HTML form. Once the submit button has been clicked, the browser takes the values from the form fields, builds an HTTP request, and then sends that to the server. The server receives the information, does what it needs to do—querying a database, for example—and then returns some data, usually in the form of a new HTML page. Although this method for data transmission is highly inefficient, because HTTP is a connectionless protocol that reduces the consumption of server resources, this method is still in use today.
Microsoft Java Applet based Remote Scripting, Netgratus ), which simplifies firewall negotiation. Rather than relying on the user clicking on a submit button, all methods of Remote Scripting provide a mechanism to call code on the server (i.e. remote function calls), just as calls are made to client-side functions (i.e. local function calls). This mandates using both a client-side proxy, the client's communication agent, and a server-side proxy, the server's communication agent.
Microsoft's Java Applet-based Remote Scripting uses client-side JavaScript plus a client-side Java Applet as the client-side proxy. On the Web server-side, it uses server-side JavaScript as the proxy. The previous generation of NetGratus Remote Scripting,
This invention,
FIG. 1 shows a system 100 having a Web page on client's computer 101 and one or more Web servers 104(1) and 104(2). Web page 101 includes a client-side proxy 102, which basically is a JavaScript library. Client-side proxy 102 can communicate with multiple Web servers 104(1) and 104(2). On each of those Web servers there is a server-side proxy 110, which handles the URL requests from client-side proxy 102 and dispatches the function calls to different server functions 111. Server functions 111 can access data sources, such as database 112, or access other server functions 111, and return the results to server-side proxy 110. The server-side proxy 110 then packages the results into a format understandable by the client-side proxy 102, and also triggers a call back function at the client-side proxy 102. The client-side proxy 102 then retrieves the data from the server-side proxy 110 and uses it for client-side processes. The next section shows a sample code for implementing the client-side proxy 102. | |
| var _NG_CallingPool=""; |
| var _NG_Busy=false; |
| function getUniqueString() |
| { |
| | var d = new Date(); |
| | var unique = d.getTime() + " + Math.floor(1000*Math.random()); |
| | return unique; |
| } |
| function NGExecute(rspage,callback,func,parms) |
| { |
| | //1. tranlate function to URL |
| | var strFunc=rspage+"?R="+getUniqueString() |
| | strFunc+="&F="+escape(func) |
| | if(callback!=null) |
| | if (parms != null) |
| | { |
| | if (typeof(parms) == "string") |
| | { |
| | strFunc+="&P"+i+"="+escape(parms[i]); |
| | } |
| | } |
| | //2. insert into calling pool |
| | _NG_CallingPool+=strFunc+"$" |
| | URLCall() |
| | if(_NG_CallingPool.length>1 && !_NG_Busy) |
| | { |
| | _NG_Busy=true; |
| | var index=_NG_CallingPool.indexOf('$'); |
| | var src=_NG_CallingPool.substring(0,index) |
| | document.scripts('ng_script').src=src; |
| } |
| function NGTrigger(callback,param,errCode) |
| { |
| | var index=_NG_CallingPool.indexOf('$'); |
| | _NG_CallingPool=_NG_CallingPool.substring(index+1, |
| | _NG_CallingPool.length) |
| | _NG_Busy=false; |
| | var strF=callback+"("+errCode+",'"+param+"')"; |
| | eval(strF); |
The next section shows the sample code for a sample Web page 101:
