Patent Publication Number: US-6665860-B1

Title: Sever-based method and apparatus for enabling client systems on a network to present results of software execution in any of multiple selectable render modes

Description:
FIELD OF THE INVENTION 
     The present invention pertains to execution of software applications in a distributed network environment. More particularly, the present invention relates to using a server system to provide multiple, selectable rendering modes of a given software application, for use by client systems on a network. 
     BACKGROUND OF THE INVENTION 
     Significant attention has been focused recently on developing software applications for use in distributed network environments, such as the Internet. In particular, there has been great interest in enabling the user of client system to access and execute a software application that resides on a remote server on the Internet. Technology currently exists to allow such a software application to be constructed as a set of hypertext markup language (HTML) pages with an associated set of executable components, such as Java applets. These applets may be used, for example, to perform functions such as generating grids, charts, and tables, which appear within an HTML page when displayed by a web browser. While such applications are now commonly available, they have various shortcomings. 
     Because the Internet is not a homogeneous network, the many computer systems and other machines which form the Internet have a variety of different hardware and software configurations. As a result, these machines have widely varying capabilities. These capabilities may determine, among other things, how a particular client system on Internet can present a software application to the user. That is, different client systems on Internet may have different rendering capabilities. For example, some client systems may be capable of rendering output of a software application by executing Java applets, while others may not. Some client machines may be capable of rendering a software application using interactive HTML, while others may not. Various other differences in capabilities may also be encountered. 
     To accommodate such differences, developers of Internet applications have resorted to writing separate versions of a given software application for each different type of client rendering capability the software application is expected to support. This process tends to be time-consuming and labor-intensive and can therefore add to the cost of developing and using software. 
     SUMMARY OF THE INVENTION 
     The present invention includes a method and apparatus for enabling software to be presented in any of a plurality of render modes. A logic definition of any software application is maintained in a server system on a network. The logic definition is for use with each of multiple selectable render modes for presenting the software application on a client system on the network. In the server system, one of a plurality of render modes is selected based on, and in response to, a signal from the client system, and the logic definition of the software application is used to cause the output of the software to be rendered to the client system in the selected render mode. 
     In certain embodiments, the server maintains a number of render modules, each corresponding to a different one of the render modes. The signal from the client may be a user-initiated request to execute the software application and may include a render parameter for specifying the render mode. 
    
    
     Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows. 
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
     FIG. 1 illustrates a network arrangement by which a server system provides a client system with access to hypermedia pages; 
     FIG. 2 is a block diagram of a computer system that may represent a server system or a client system such as described herein; 
     FIG. 3 is a block diagram of a server coupled to a client, in which the server maintained a set of render modules corresponding to multiple rendering modes; 
     FIG. 4 is a flow diagram illustrating a server-implemented process for providing hypermedia documents to a client for a selected rendering mode; and 
     FIG. 5 is a flow diagram illustrating a server-implemented process for reassembling a hypermedia page for a selected render mode. 
    
    
     DETAILED DESCRIPTION 
     A method and apparatus are described for enabling software to be executed in any of a plurality of render modes in a client system on a network. As will be described in greater detail below, a set of hypermedia pages and associated executable components maintained in a server system on the network collectively form logic definition of a software application, which can be essentially any type of software application. The server maintains a number of render modules, each corresponding to a different one of multiple render modes. Each of the render modules is for use with the same application definition of the software application. In the server system, one of the render modules is selected based on, and in response to, a signal from the client system. The signal representing a user-initiated request to execute the software application. The signal represents a Uniform Resource Locator (URL) that may include a render parameter specifying a render mode. The server uses the logic definition of the software application and an appropriate one of the render modules to provide information to the client system, to enable the client system to present the software application to the user in the selected render mode. Importantly, the same application definition is used for all of the multiple render modes. 
     Note that in this description, references to “one embodiment” or “an embodiment” mean that the feature being referred to is included in at least one embodiment of the present invention. Further, separate references to “one embodiment” in this description do not necessarily refer to the same embodiment, however, neither are such embodiments mutually exclusive. 
     As will be apparent from this description, the present invention may be embodied, at least in part, as software, or as a result of executing software. That is, sequences of instructions contained in memory can be executed to cause a computer&#39;s microprocessor to perform or initiate the operations described herein. It is understood that such instructions may be loaded into the computer&#39;s memory from a persistent store, such as a mass storage device, and/or from one or more of the other computer systems over a network, such as the Internet. 
     FIG. 1 illustrates a conventional network arrangement by which a user can browse the World Wide Web (“the Web”) on the Internet. A client computer system  1  has a connection  3  via the Internet to a server computer system  2 . The client system  1  executes browser software which, in response to a user command, sends a request for a hypermedia based page, such as an HTML page, to the server  2  using, for example, Hypertext Transport Protocol (HTTP). The requested HTML page is one of a number of HTML pages  4  that are stored in a storage facility  5 . The storage facility  5  may or may not be physically located on the same computer system as the server  2 . The HTML pages  4  are functionally interconnected by various hypermedia (e.g., hypertext) links and may be logically arranged in a tree hierarchy, as shown. In response to the browser&#39;s request, the server  2  retrieves the requested page and provides it to the client  1 , which then displays the page to the user. 
     FIG. 2 is a simplified block diagram of the architecture of a computer system that may be representative of the client  1 , the server  2 , or any other computer system mentioned in this description. The computer system may be, for example, a conventional personal computer (PC), a workstation, or a hand-held device such as a personal digital assistant (PDA), personal information manager (PIM), cellular/wireless communication device, etc. The illustrated computer system includes a central processing unit (CPU)  10 , which is a microprocessor, random access memory (RAM)  11 , read-only memory (ROM)  12 , and a mass storage device  13 , all coupled to a bus system  18 . The bus system  18  may actually include one or more physical buses interconnected by one or more adapters, bridges and/or controllers. For example, the bus system may include a system bus connected to the CPU  10  and one or more peripheral buses, such as a Peripheral Component Interconnect (PCI) bus. 
     Also connected to the bus system  18  are a display device  14 , a keyboard  15 , a pointing device  16 , and a communication device  17 . The communication device  17  provides an interface between the illustrated computer system and the network connection  3  for purposes of communicating with other computer systems. 
     The communication device  17  may be any suitable device for allowing the computer system to communicate with a remote computer system communicating over a network connection  3 , such as an Ethernet adapter, a conventional telephone modem, a cable modem, an Integrated Services Digital Network (ISDN) adapter, a Digital Subscriber Line (xDSL) adapter, or any other suitable device. The mass storage device  13  may be or may include any suitable non-volatile medium for storing large amounts of data, such as a magnetic disk or tape, a magneto-optical (MO) storage device, any variation of Digital Versatile Disk (DVD) or Compact Disk (CD), flash memory, or the like. The pointing device  16  may be any suitable device for allowing a user to position a pointer displayed on the display device  14 , such as a mouse, trackball, touchpad, joystick, or the like. 
     Of course, numerous variations upon the illustrated system are possible. That is components may be added to the system or omitted from the system, as desirable for a particular application or manner of use. 
     FIG. 3 illustrates a presentation system for enabling a given software application to be executed in any of a plurality of render modes on a client on a network. The system is a server-based system that allows application information to be presented (rendered) in a format (mode) that is most suitable to the destination client. A key capability of the presentation system is its ability to use the same application definition, structure, and code logic regardless of the delivery mechanism. This allows applications to be created and deployed to a large number of diverse clients without modification or consideration of the end user&#39;s platform. End users can specify how they want information delivered to them when they make requests to the application server. This specification can alternatively be included in a user profile contained on the server, which is consulted in the absence of a user-specified format. 
     The system operates in a multi-tiered environment where clients, application servers, and original information sources can be placed on different physical computing devices and in different physical locations. The system addresses the problem of efficiently delivering application information from an application server tier to a client tier where the end user can view and/or interact with the information. Information is packaged in a format that is most suitable to the intended use and physical restrictions (such as bandwidth) requirements of the destination client. 
     Referring to FIG. 3, a software application  25  resides on a server  22  on a network, such as the Internet. The user of a remote client  21  on the network may wish to use the application  25 . The application  25  is defined as a set of hypermedia (e.g., HTML) based pages  26  and an associated set of executable components  27 , such as Java applets. One or more of the hypermedia pages  26  contain applet tags (e.g., “&lt;APPLET&gt;”) referencing one or more of the executables components  27 . The hypermedia pages  26  may be logically arranged in a hierarchy, as described above. The application  25  may also include various properties, parameters, etc., which may also be maintained in the server  22 . Thus, in the context of this description, a software application is a set of hypermedia pages, logic, properties, data sets, and executable code, which together cause useful information to be delivered to an end user of a client system. 
     Note that the server  22  may actually be implemented as two or more separate servers, such as an HTTP server, an application server, a database server, etc. Such multiple servers may be implemented in two or more separate computer systems. As noted above, each such computer system may have a configuration as described above and shown in FIG. 2, as may the client  21 . 
     When the user of the client  21  wishes to use the software application  25 , he initiates an HTTP based request for one of the pages  26  using the browser  23 , by clicking on a hypermedia link referencing one of the pages  26 . This in general causes the requested hypermedia page  26  to be downloaded from the server  22  to the client  21 , where the page is displayed to the user of the client  21  by the browser  23 . In addition, any of the executable components  27  referenced in that page are invoked and executed. 
     The specific functions of the executable components  27  depend on the nature of the application  25  but may include, for example, charting or spreadsheet functions, grid or table generation functions, spelling or grammar is checking, various user interface functions, etc. The manner in which their output (e.g., charts, grids, tables, etc.) is presented to the user depends on the capabilities of the client  21  and/or the preferences of the user. 
     The presentation system  24  in the server  22  enables the output of the executable components  27  to be presented to the user of the client  21  in a manner which is best suited to the capabilities of the client  21 . As described further below, the presentation system  24  includes a number of separate render modules  31 , each for rendering output of an executable components  27  according to a different rendering mode, for a particular type of executable component. 
     In one embodiment, the application information delivery format is specified by a specific parameter in the Uniform Resource Locator (URL) used to request the information from the server  22 . The URL parameter has the form “render=format”, which appears after the standard World Wide Web Consortium (W3C) URL parameter delimiter, “?”, e.g., “http://MyServer/MyApplication/?render=html” might be used to render output in standard HTML mode. A sophisticated user may manually add the render parameter to the URL prior to invoking a page  26 . Alternatively, a given page  26  may provide the user with separate hypermedia links (and therefore separate URLs) for each selectable rendering mode, with the appropriate render parameter already included in each URL. The user may then select the desired rendering mode by selecting the corresponding link. In another embodiment, the render mode may be selected by providing the user with a page  26  that lists a variety of application and/or client system configuration options; the user may then select an option, and this selection corresponds to a URL that specifies the (predetermined) appropriate render mode for that option. In yet another embodiment, the render mode may be specified in a user profile for a particular user or client machine. 
     The acceptable values of the format field (acceptable render modes) are dependent on the implementation; however, in one embodiment the set of acceptable format values include, HTML, LINKS, JAVA, PRINTER, XML, and XLS. The HTML format value is used to render application information in a non-interactive, static W3C HTML format. This mode is used to view application information, but does not include mechanisms to interact with the information presented. The LINKS value is used to format the information in interactive W3C HTML. In this format, the application information presented is the same as the HTML format above, however, the end user is given the capability to interact with the information. Examples of such interaction include, but are not limited to “drilling down”, pivoting, filtering, and moving On-Line Analytical Processing (OLAP) dimensions, changing colors and formats, and scrolling. In the interactive HTML case, the client  21  is caused to re-request the page  26 . The server  22  responds to this interaction request by performing the appropriate operation (e.g., drill down, pivot, change chart to fit, etc.) and then causes the browser  23  to re-request the original page. Thus, the current state of the application  25  is modified by the interaction request, and the subsequent page request displays the newly modified state of the executable component. 
     When JAVA format is used, Java applets are sent to the client  21  which contain a higher level of LINKS functionality. In this format, the Java applets control all aspects of information display and interaction. A Java applet tag is inserted into the HTML page that causes these applets to be loaded onto the client  21 . PRINTER format is used to format information in static W3C HTML suitable for output to a printer. XML format is used to format information in extensible mark-up language. When XLS format is used, the output information includes Multipurpose Internet Mail Extension (MIME) code that causes the browser  23  to launch a specific application and pass the static W3C HTML to that application. For example, the XLS format may be used to cause Microsoft Excel to be launched, such that the information is presented in the form of a standard Excel spreadsheet. Note that any valid MIME code may be used. The presentation system  24  is also extensible, such that new rendering modes can be added to provide the user with additional formatting options. 
     Referring again to FIG. 3, the presentation system  24  includes a page parser  28 , a render manager  29 , and a request handler  30 . The request handler  30  is a conventional HTTP request handler which receives HTTP requests from the browser  23  and responds to those requests by accessing the requested pages  26  and executable components  27 . The page parser identifies and removes certain predetermined elements from requested hypermedia pages in preparation for rendering, as described further below. These elements include Java applet tags corresponding to the executable components  27 . The render manager maintains and invokes particular ones of the render modules  31 , as appropriate for the specified rendering mode. The render manager  29  and the render modules may be implemented as Java classes. As noted, each of the render modules  31  is configured to render a particular type of executable component (e.g., grid, chart, etc.) in a particular render mode (HTML, LINKS, PRINTER, JAVA, etc.). In an alternative embodiment, however, Java rendering is handled separately, by the page parser  28 , which includes a separate Java applet for that purpose. 
     Operation of the presentation system  24  is as follows. A given hypermedia page  26  of the application  25  may contain one or more tags referencing executable components  27  (e.g., Java applets), corresponding to areas in the page which will display application information (charts, grids, etc.). The application page is sent from the server  22  to the client  21  in response to URL requests from the client  21 . The tags inform the server  22  which of executable components  27  to create and populate for the client  21  (i.e. the application information that will be sent to the client  21 ). For example, an application HTML page  26  in the server  22  may have an executable component for generating a chart and one for generating a grid. When the requested page is sent to the client  21 , the corresponding regions within the requested page contain application information in the form of a chart and a grid. As application pages  26  are processed on the server  22 , the presentation system  24  determines how each component should be formatted on the client  21  based on the render parameter of the URL or a default render format for the application and end user, as coded by the application&#39;s developer. This is done by invoking the appropriate one of the render modules  31  for each executable component associated with the page. Thus, the same application definition is used for multiple render modes. 
     Different rendering modes may be appropriate for different situations. For example, a user connecting to the server  22  using a slow-speed connection may request information to be formatted in the simplest format for viewing only HTML. A user who needs to perform in-depth analysis using the application  25  may request information to be presented using full-featured Java applets. A user who wants to print the application&#39;s information to a printer may use the PRINTER format to receive information that is “printer ready”. Using the XML format, another application server which requires information that the application  25  contains can request self-describing information. Using the XLS format, application information can be loaded directly into a spreadsheet. 
     Operation of the presentation system  24  will now be further described with reference to both FIG.  3  and FIG.  4 . At block  401  in FIG. 4, the server  22  receives an HTTP request for one of the hypermedia pages  26  from the client  21 . This request includes a URL with the render parameter that informs the presentation system  24  how the application information is to be presented. At block  402 , the server  22  starts the application  25 , if it is not already running. At block  403 , the server  22  creates an instance of the application  25  for the current user, if one has not already been created. At block  404 , the request handler  30  retrieves the requested page. At block  405 , the page parser  28  parses the retrieves page for developer-included Java applet tags that correspond to the executable application components  27  (e.g., charts, grids, etc.). The component for each such tag is then created for this application instance, if it has not already been created. At block  406 , the page is then reassembled for transmission to the client  21 ; this operation includes rendering the output of each such executable component  27  in the specified format, as described further below. The reassembled page is then transmitted to the client  21  at block  407 . 
     FIG. 5 illustrates in greater detail the reassembly and rendering block  406  (FIG. 4) for given executable component, with respect to the Java and HTML based rendering modes, for one embodiment. If the rendering mode specified for the executable component is JAVA at block  501 , then at block  503 , the page parser  28  strips the Java applet tag corresponding to the component out of the page and reinserts it with additional information, such as application information, session information, etc. (i.e., information which allows the Java applet to find the application created in block  402 ), and the process exits. Note that applet tags which do not correspond to any of the executable components  27  are simply buffered and sent back to the client  21  without modification in block  407 . If the specified rendering mode is not JAVA, then it is determined at block  502  whether the rendering mode is HTML based, i.e., static HTML (“HTML”) or interactive HTML (“LINKS”). If so, the process proceeds to blocks  504  through  508 . Note that blocks  504  through  508  can also be applied for other, non-Java rendering modes; however, only HTML based modes are noted here to simplify description. At block  504 , the page parser  28  strips the Java applet tag corresponding to the executable component out of the page. Again, applet tags which do not correspond to executable components  27  are simply buffered and sent back to the client  21  without modification in block  407 . Next, at block  505 , the render manager  29  locates the appropriate render module  31  based on the render parameter in the URL and the type of component that is being invoked. This is accomplished using a map maintained in the server  22  of executable components  27  to render modules  31 . At block  506 , the render manager  29  invokes the appropriate render module  31 , which generates dynamically (“on-the-fly”, in real-time) an HTML fragment, using information on the current state of the executable component. Each executable component  27  has a current state which may include, for example, data values, scroll position, colors, alerts, options, user properties, etc. The HTML fragment contains HTML code usable by the client  21  to render a visual representation of the component. In the case of interactive HTML (LINKS mode), the HTML fragment actually includes a combination of real-time generated JavaScript, HTML, and specially coded HTML links. From the user&#39;s perspective, these links are associated with normal HTML navigation methods, such as buttons, images, etc. At block  507 , the resulting HTML fragment is inserted by the appropriate render module  31  into the original page in place of the applet tag that was stripped out. At block  508 , the page parser  28  inserts additional applet tags that load very small applets maintained on the server, which are used to enable JavaScript on the browser  23  in the client  21 ; these additional applets are described further below. 
     As noted above, additional, very small applet tags are inserted into the page for the HTML based rendering modes, to enable JavaScript on the client  21 . The application environment described above is based on the ability of application developers/assemblers to code their business and navigation logic in JavaScript. The JavaScript is contained in the hypermedia pages  26  that the server  22  sends to the client  21 . In order for this developer-provided JavaScript to function, it must communicate back to the server  22  to request information, change states, and control server functions. The JavaScript normally does this by using Application Programming Interfaces (APIs) supplied by the Java client associated with server  22 . These APIs may be simply Java methods that are exposed on each of the executable components  27 . In order for this client side code to operate in all rendering modes, these APIs must be made available. 
     In the Java rendering mode, the same Java applets that present information to the user contain these JavaScript APIs. For example, a Java applet representing a charting component displays charts and also exposes the charting APIs to JavaScript. In the HTML rendering mode, however, Java is not used to display information to the client. Instead, the client browser  23  receives pure HTML representations of charts (e.g., JPEG) and data grids. Thus, a mechanism is needed to allow the developer-provided JavaScript code to operate. 
     Consequently, when an HTML-based rendering mode is selected, the server  22  strips out the Java applet tags (corresponding to executable components  27 ) from the HTML source page and replaces them with tags for alternate, very small Java applets, which reside on the server  22 . These small Java applets contain only a version of the above-mentioned APIs. They do not present information to the user and they are not visible on the screen. The developer&#39;s JavaScript is ignorant of the fact that it is communicating with these alternate applets. Thus, an application  25  operates the same in both Java and HTML based rendering modes on the client  21 . 
     Note that switching to these alternate Java applets for HTML based rendering modes also reduces the amount of code and the resulting startup time for the application  25 . Where a full Java applet complete with API and presentation information can be on the order of several megabytes in size (with all necessary supporting technologies), these alternate Java applets tend to be on the order of tens of kilobytes. This is major difference in size, as well as download time and complexity. Hence, download time for these alternative applets is insignificant. 
     Thus, a method and apparatus for enabling software to be presented in any of a plurality of render modes in a client system on a network have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.