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

[0002] 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.

[0003] 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.

[0004] 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.

[0005] 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.

[0006] 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.

[0007] 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.

[0008] Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows.

[0009] 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:

[0010] FIG. 1 illustrates a network arrangement by which a server system provides a client system with access to hypermedia pages;

[0011] FIG. 2 is a block diagram of a computer system that may represent a server system or a client system such as described herein;

[0012] 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;

[0013] FIG. 4 is a flow diagram illustrating a server-implemented process for providing hypermedia documents to a client for a selected rendering mode; and

[0014] FIG. 5 is a flow diagram illustrating a server-implemented process for reassembling a hypermedia page for a selected render mode.

[0015] 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.

[0016] 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.

[0017] 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's microprocessor to perform or initiate the operations described herein. It is understood that such instructions may be loaded into the computer'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.

[0018] 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's request, the server 2 retrieves the requested page and provides it to the client 1, which then displays the page to the user.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] 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.

[0023] 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'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.

[0024] 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.

[0025] 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., “<APPLET>”) 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.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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'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.

[0035] 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'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.

[0036] 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.

[0037] 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'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.

[0038] 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.

[0039] 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.

[0040] 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'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.

[0041] 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.

[0042] 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.