Patent Abstract:
The rendering of portal pages on can be sped up by allowing individual portlets to be displayed while other portlets of the page are still waiting to finish rendering. Temporary messages can be displayed for the portlets that are still rendering. This temporary content can be replaced by the finished portal rendering for the slow rendering portlets. Additionally, a timeout feature for the portlets can be used. The timeout feature allows the rendering of the portlet to be stopped after a certain period of time.

Full Description:
CLAIM OF PRIORITY 
     This application claims priority to U.S. Provisional Application No. 60/573,204 entitled “Independent Portlet Rendering” filed May 21, 2004. 
    
    
     FIELD OF THE INVENTION 
     The present invention is directed to portal technology. 
     BACKGROUND 
     Portals can provide access to information networks and/or sets of services through the World Wide Web and other computer networks. Portals can provide a single point of access to data and applications, making them valuable to developers, businesses, and consumers alike. A portal can present a unified and personalized view of enterprise information to employees, customers, and business partners. In many implementations, portal applications can include web application views designed as a portal. 
     Portals are capable of presenting multiple web application views within a single web interface. In addition to regular web content that can appear in a portal, portals provide the ability to display portlets (self-contained applications or content) in a single web interface. Portals can also support multiple pages with menu-based or custom navigation for accessing the individualized content and portlets for each page. 
     A working portal can be defined by a portal configuration. The portal configuration can include a portal definition such as a file including Extensible Markup Language (XML); portlet definition files for any portlets associated with the portal; java server pages (JSPs); web application descriptors; images such as graphics interchange format files (GIFs); deployment descriptors, configuration files, the java archive (JAR) files that contain the logic and formatting instructions for the portal application; and any other files necessary for the desired portal application. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         FIGS. 1A-1C  are diagrams that illustrate the display of a portal page of one embodiment of the present invention. 
         FIG. 2  illustrates a system of one embodiment of the present invention. 
         FIG. 3  is a flowchart of a method of the present invention. 
         FIG. 4  illustrates interactions of a server and a browser client of one embodiment of the present invention. 
         FIG. 5  is a flowchart of a method of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     Portals can provide access to information networks and/or sets of services through the World Wide Web (WWW) or other computer networks. These networks can range from broad interconnections of computing systems such as the Internet to localized area networks including a few computers located in close geographic proximity such as a home or office. Portal applications can include web application views designed as a portal. 
     Portlets can be implemented as java server pages (JSPs) referenced by XML-based metadata of the portal descriptor. Portlets can utilize various types of display code to display highly focused information directed to a specific user or user group, having a portal as its container. Portlets can be comprised of portlet components which include portlet attributes (i.e. whether the portlet is editable, floatable, minimizable, maximizable, helpable, mandatory, has defaults minimized, or whether login is required) and portlet layout elements or components (i.e. banner, header, content, and footer sections). In one embodiment, a portlet is defined by a file that contains a portlet&#39;s XML-based metadata, which is created and edited by an integrated design environment or administration tool. Portlets can also be associated with portlet resource files including skeleton JSPs (one for each portlet layout element) and image files saved to a local file system by portal designer of integrated design environment. 
     In one embodiment, the portlets can be rendered in their own threads. A “forkable” portlet is one whose execution takes place on the thread that is separate from the main servlet thread (This thread can allocated from a separate thread pool and can be configured in the config.xml file). This can increase the efficiency as the total time to execute the page is no longer the sum of all portlet execution times but is now limiting by the longest running portlet. However, all portlets on a portal page must finish execution before the page can be rendered as a single Hypertext Markup Language (HTML) document. Therefore, the slowest portlet, and more generally the slowest-executing portion of a portal page still act as the governing entity with regard to actual portal response time. That is to say, the “longest link” in the processing chain can still have a significant effect on portal response time. 
     The present invention concerns ways to speed up the presentation of a portal page to a user. One embodiment of the present invention concerns providing a portal page display with only the fast rendering portlets at first and then later providing the slow rendering portlet information to update the display. This can enhance the user experience since the display does not wait for slow rendering but potentially inessential portlets. 
     Another embodiment concerns the use of a timeout property for portlets. If the portlet rendering exceeds the timeout period, the rendering of the portlet can stop. An error message can be displayed to the user. 
       FIGS. 1A-1C  are diagrams that illustrate one embodiment of the present invention. In one embodiment, a portal page is constructed using portlets. As shown in  FIG. 1A , the display  102  of the portal page does not wait for at least one slow rendering portlet but at least one fast rendering portlet  104  is displayed to the user before the at least one slow rendering portlet. As shown in  FIG. 1B , the display can be updated with the at least one slow rendering portlet  108  after it renders. 
     Looking again at  FIG. 1A , temporary content  110  can be displayed for a slow rendering portlet. A fast content (temporary content) Uniform Resource Indicator (URI) can be used to obtain the temporary content  110  if the portlet is slow to render. The portlets can have a ‘fast content URI’ property to indicate the URI of the temporary content. ‘Fast content URI’ is an optional URI that the system can render if the portlet is in ‘render independently’ mode. The fast content could display a simple message like “retrieving flight information.” while the system is working on the real portlet content, and upon completion would replace the ‘fast content’ in the portal. 
     The independent rendering functions of the portlets can be activated or inactivated based on stored information for each portlet. This allows essential portlets to always be rendered with the first display of the portal page. 
     A ‘supports rendering independently’ property of the portlet marks the portlet as supporting this feature. This property can be set in the IDE as it is determined by the developer. The developer can decide if the portlet will not be adversely affected if the portlets rendering phase is out of sync with other portlets. A case where a portlet&#39;s functionality could be affected is were the developer inserts request or session attributes during the render phase and other portlets are relying on these attributes. 
     ‘A render independently’ property of the portlet can actually turn on the independent rendering function for the portlet. The portal framework would not wait for the portlet to finish rendering before sending its HTML to the browser. When the portlet completes the rendering phase, the portlet&#39;s contents can get injected into the main page. 
     In one embodiment, the portlet execution can be timed out if the portlet rendering exceeds a predetermined period of time.  FIG. 1C  shows an error message  112  that is displayed to the user after a portlet times out. In this case, an error message  112  can replace the temporary content  114 . A ‘timeout’ attribute of the portlet can inform the framework to kill the processing of the portlet if the execution of the portlet exceeds that of the timeout value. This can insure that one portlet cannot bring down the entire portal. Upon a portlet timeout, an error message can be displayed in the portlet&#39;s content indicating a timeout has occurred and the user may wish to try again. 
     The server  202  can be used to produce the portal for display at the browser client  204 . In one embodiment, the server  202  produces portal display information in response to a request from the browser client  204 . The portal can be configured for different users and different group of users, where different portlets can be displayed based upon a user&#39;s group or role. The server  202  can use a portlet configuration  210 . The portlet configurations including a portal definition  212  which can be an XML file pointing to portal elements  214 . In one embodiment, the portal elements can include a portlet definition  216 . The properties of the portlet can include the “support rendering independently”, “fast content URI” and “timeout”. These properties can be stored in the portlet definition. The portal elements  214  can also include other portals elements  218 , such as images, look and feel elements JSPs and the like. The server  202  can use the properties stored in the portlet definition to determine the information provided to the browser client  204 . The server  202  can be software that can be run on one or more server machines. In one embodiment, the server  202  is the WebLogic Server™ available BEA Systems Inc., of San Jose, Calif. 
     The browser client  204  can produce a display  220  of the portal pages and other information from the Internet. In one embodiment, the Document Object Model (DOM) standard is supported by the client as well as the current browser client supporting javascript. The DOM/javascript  224  can be used for updating the portal page displays with the information provided by the server as discussed below. 
     A portal product  230  can be Integrated Designed Environment (IDE) for producing the portal. In one embodiment, the IDE includes a portal designer  232  for the design of the portal, portlets and other portal elements. The administration tools  234  and visitor tools  236  are used for producing versions of the portal. In one embodiment, different version use the portal configuration  210  and stores it in a database where changes to the portal configuration can be done. Portals can be produced from the database or directly from the portal configuration. 
       FIG. 3  illustrates a flow chart of one embodiment in the present invention. In step  302 , the rendering of the portlets or the portal page has begun. If the “support rendering independently” property is not set, as determined in step  304 , or the “rendering independently property” is not set as determined in step  306 , then, in step  308 , the portlet is rendered without independent portlet rendering. 
     If a portet is ready to render in step  310 , then the independent display of the portlet can be done in step  312 . If not, if there is a fast URI as determined in step  314 , independent display of the fast URI content can be can be done in step  316 . If the portlet times out as determined in step  318 , an independently displayed error message can be produced in step  320 . Steps  304 - 320  can be done independently for each portlet, each portlet in its own thread. 
       FIG. 4  illustrates the operation of one embodiment of the present invention. The browser client  402  sends a request, in step A, for a portal page to the server  404 . In step B, the server begins rendering the portlets for the portal page. In step C, the preparation of the fast rendering portlets is finished. In one embodiment, the fast rendering portlets are determined after certain period of time or after certain number of portlets are finished. In step D, an HTML connection with the browser client is opened. HTML for the fast running portlets is set along with temporary messages for and associated IDs for the slow rendering portlets to the browser/client  402 . In step E, browser client  402  can display the portlet page. This can correspond to the display of  FIG. 1A . In step F, the preparing of a slow rendering portlet is finished and an HTML for a slow rendering portlet along with the ID of the portlet is set to the browser/client  402 , in step G. In step H, javascript can be used to update the display of the portal rendering page with the slow rendering portlet. This can correspond with the display of  FIG. 1B . 
     In step I, a portlet times out. In step J an error message can be sent for a timed out portlet along with the portlet ID. In step K, the browser/client  402  use javascript to update the display of the portlet page with error message. This can correspond with the display of  FIG. 1C . In step L, the HTML connection can be closed. 
     Delayed rendering can use ordinary HTTP request response type mechanisms to achieve its goal. A portlet that is delayed will not output its content into the HPPT response but instead can output a div tag with a special id/name. This marks a place in the DOM were javascript at the browser can update the contents at a later time. The HPPT response is held open unitl the delayed portlets are finished or timeout. This gives the illusion that the portlet&#39;s content is being pushed to the browser. 
     The response is not held open any longer than if we did not do delayed rendering. In one embodiment, the benefit comes with the HTML filing the screen a lot faster with portlest that have already finished their execution. 
     In one embodiment, a timeout property of a portlet is checked. If the timeout property value is exceeded by the rendering time of the portlet, the rendering of the portlet is ended. This can be done as part of the delayed rendering system of  FIG. 3  as discussed above. 
       FIG. 5  shows an alternate embodiment where the display waits until all portlets render or the timeout property value is exceeded for all portlets. In step  502 , rendering begins. After step  504  determines that all of the portlets are either ready to displayed or timeout, the display of the whole page with any error messages for timed out potlets is done in step  506 . 
     One embodiment may be implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art. 
     One embodiment includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the features presented herein. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, micro drive, and magneto-optical disks, ROMs, Rams, EPROM&#39;s, EPROM&#39;s, Drams, Rams, flash memory devices, magnetic or optical cards, Nan systems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data. 
     Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and user applications. 
     The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to one of ordinary skill in the relevant arts. For example, steps performed in the embodiments of the invention disclosed can be performed in alternate orders, certain steps can be omitted, and additional steps can be added. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims and their equivalents.

Technology Classification (CPC): 6