1. Field of the Invention
The present invention relates to the field of Web portals and portlet handling, and, more particularly, to maintaining portlet data currency while minimizing latency.
2. Description of the Related Art
A Web portal is a Web site or service that offers a broad array of resources and information, such as e-mail, search engines, advertising, user-specific reports, personalized contact and task management functions, customized news feeds, local weather, and the like. A Web portal can include multiple Web portlets. Each Web portlet can be a reusable Web component that displays information to portal users from a designated source, which can be different from the source that provides information for the portal. An arrangement of portlets within a portal, a presentation of information within the portal, the responsiveness of this presentation, and other user perceived factors all contribute to the user experience of the portal.
The typical approach for a portlet to retrieve the information that is displayed to a user is for each portlet to independently request information from a data source and to independently present the obtained information to users. FIG. 1 shows the basic interactions executed to enable a client device to utilize one or more data sources linked to one or more portlets to produce a user experience for the portal.
While FIG. 1 assumes the data source used by the portlets is part of a Service Oriented Architecture (SOA) 112, the portlet communication pattern shown in FIG. 1 applies to portlets-data source communications in general and is not limited to a particular software architecture, such as SOA 112.
As shown, the client 102 portlets 106 and 108 of FIG. 1 can utilize JAVASCRIPTS to request that the portlets 106-108 be refreshed. Conventional client-side JAVASCRIPTS use a single thread model. The portal server 104 can create a process to handle retrieving data to update the portal 104. The portlets 106-108 can retrieve data from various components of the SOA 112. Each portlet 106-108 independently follows an equivalent update process. For example, a client 102 can request that information in a selected portal 104 to be refreshed. The portal 104 will render graphical objects in portlet 106 or 108. This rendering can require data values be obtained from a portlet process, which can require information be obtained from the SOA 112. The SOA 112 sends responses back to the common portlet process, to the requesting portlet 106 or 108, which sends data to the portal 104, which properly renders/presents the updated information upon client 102.
Using conventional techniques illustrated in FIG. 1, when multiple portlets require updates, multiple JAVASCRIPT requests are made for each portlet. The portal utilizes the same process on behalf of each portlet to request the information update. This approach consumes significant computing resources, such as processing power and bandwidth. The conventional approach is particularly problematic when real-time information is being presented within one or more portlets. Then, the constant polling for updates and receiving of responses that occur on a portlet-by-portlet basis can quickly overload a system or communication infrastructure to an extent that data updates are delayed, thus detracting from the resultant user experience of the portal.