REGISTER  |  SIGN IN
United States Patent Application20040205473
Kind CodeA1
Fisher, Gwyn ; et al.October 14, 2004
Method and system for implementing an enterprise information portal
Abstract
The invention provides an Enterprise Information Portal (EIP) for access by a user via a browser on a network, said portal comprising: (a) an interface for communicating between said portal and said user; (b) a theme manager for selecting a theme, said theme defining a presentation format for said browser; and (c) a plug-in manager for controlling a plurality of plug-ins, said plug-ins for retrieving and formatting information content for said user, wherein said plug-in retrieves information from both local and remote sources.
Inventors:Fisher; Gwyn (Ottawa, CA), Stevenson; Cam  (Ottawa, CA), Gutz; Steven  (Ottawa, CA), Hester; Doug  (Raleigh, NC), Lewis; John  (Raleigh, NC)
Correspondence Name and Address:Dowell & Dowell, P.C. Suite 309 1215 Jefferson Davis Hwy.
Ralph A. Dowell
Arlington
VA
22202
US
Series Code:205625
Filed:July 26, 2002
U.S. Current Class:715/500
U.S. Class at Publication:715/500
Intern'l Class:G06F 015/00
Claims

The Embodiments of the Invention in which an Exclusive Property or Privilege is claimed are Defined as Follows:
1. A system for providing a portal to a user via a browser on a network, said portal comprising: (a) an interface for communicating between said portal and said user; (b) a theme manager for selecting a theme, said theme defining a presentation format for said browser; and (c) a plug-in manager for controlling a plurality of plug-ins, said plug-ins for retrieving and formatting information content for said user, wherein said plug-in retrieves information from both local and remote sources.
Description


[0001] The invention relates to the field of data processing systems. More specifically, the invention relates to corporate or enterprise information portals.

BACKGROUND OF THE INVENTION

[0002] Consumer portals such as Yahoo!, Excite, Lycos, and InfoSeek have changed the way web surfers search for information by providing a single access point to satisfy most, if not all, of their content requirements. Portals are now receiving more attention than virtually any other Internet technology. In fact, many of the world's largest companies have begun implementing portal based solutions. In the near future, the implemenation of portal solutions may well redefine markets and the businesses upon which they are built. There is thus a need to redefine traditional information delivery based on the model of the Enterprise Information Portal (EIP).

[0003] An EIP is not a single technology or application, but a collection or related functional components that work together. Many existing corporate portals merely display information for users, or allow them to interact with a single application. There is thus a need for EIP solutions that provide users with a web-based workspace that is completely personalized and enables them to not only search for and view information, but also to act on the data using a variety of applications and technologies. Moreover, there are several market-dictated criteria that portal solutions should meet in order to be considered true Enterprise Information Portals and to meet the needs of corporate users.

[0004] In theory, an EIP is a web-based tool that bridges the disparate worlds of structured (databases) and unstructured (documents, images) data across the enterprise, providing users with access and analysis capabilities via a single point of access. In order to live up to this definition, an EIP solution must demonstrate a variety of characteristics and provide essential services. The most critical of the principal elements are as follows: security, presentation, personalization, collaboration, publishing and distribution, integration, interactivity, categorization, search, multi-repository support, and metadata management. However, present corporate portals do not provide these principal elements satisfactorily.

[0005] Thus, there is a need for an enterprise information portal that provides users with a single logon model. Such a model should streamline the workspace environment and eliminate the need to for users to remember, configure, and maintain multiple usernames and passwords. The goal would be to have a unified logon to all information sources and applications that a user normally has access to in a typical client/server environment. This means all network folders, e-mail systems, solutions, and other password protected accounts. Ideally, portal solutions should leverage existing security models to ensure the integrity of enterprise information.

[0006] Presentation is the element most responsible for the single point of access paradigm promised by EIP technology. There is a need then for presentation design that addresses the paramount issues surrounding EIP interfaces, those being:

[0007] Fitting all information, regardless or source, comfortably within the display space along with links to related information and applications.

[0008] Providing a familiar environment for users that minimizes, or ultimately eliminates, training time.

[0009] The key challenge is to address both the issues of integrated information display and ease of use at the same time. EIP solutions on the market today use one of several models, mostly revolving around the familiar Microsoft Windows Explorer hierarchical folder metaphor or an HTML-based "organizational" approach similar to MyYahoo! or My Netscape. Regardless of specific design model, the EIP needs to integrate all elements that a user has access to in a consistent look and feel and organize those elements in a fashion that makes sense to the user.

[0010] As with consumer portals, the personalization facility of EIP solutions is a critical ingredient in the productivity enhancement and effective individual information management, both professional and personal/collaborative. The concept of the "My!" facility allows users to customize their interface in order to manage layout, eliminate unnecessary or undesired content, and tailor information feeds in order to maximize efficiency.

[0011] Building on the idea of personalization is the idea of individual profiling that EIP solutions need to support. Individual profiling acts very much like information filtering in reverse. Individual profiling starts with a profile of user functions and interests, and then heuristically scans the information environment for new documents or other elements that might be of interest. Armed with the user's job and interest profile, the portal can then suggest new items of interest it has located in the process of scanning information sources. While suggestive computing is still in its infancy, the portal environment is a place in which it can achieve a range and scope that can make this functionality a helpful new mechanism to the knowledge worker environment.

[0012] Collaboration expands the role of the EIP from passive information kiosk to a new forum for organizational interactions. Collaboration capabilities through the EIP enable employee-to-employee interaction, and even more importantly, employee-to-customer or other business partner exchanges. By enabling this level of interactivity, EIP solutions can dramatically reduce the time required for such things as customer service and improve stakeholder relations. Within the organization, there are several levels of collaboration that EIP technology can address. Similar to the functionality of Microsoft Exchange or Lotus Notes platforms, enterprise wide collaboration is needed within the web-based EIP environment. In addition to this organizational level, collaboration at the project group level as well as the interest, or functional area (e.g. human resources) could be enabled.

[0013] Central to the concept of EIPs is the assumption that disparate applications (for such tasks as content management, and business intelligence) will access other internal and external sources of information and data, bi-directionally share that information, and use it within the portal workspace for processing and analysis. In other words, enterprise applications need to be seamlessly integrated with not only the portal environment but also with other applications as required. Ultimately, EIP solutions should enable organizations to integrate information regardless of platform or data type (structured or unstructured).

[0014] Enterprise Information Portals should not be static. That is, they should represent more to users than a web-based interface for viewing information. Rather EIPs should allow users to explore, analyze, query, and share the information presented by the interface. By seamlessly integrating with any enterprise application, EIP solutions provide users with the ability to better understand the information they use and the business environment in which they operate. Moreover, by providing interactive functionality, EIPs further enhance return on investment through process streamlining, and faster, timelier decision-making.

[0015] Valuable ideas and concepts may lay undiscovered through traditional access and search methods. Categorization provides a means to unearth and filter these concepts and ideas and organize them in a meaningful taxonomy that can be navigated by the user. The real benefit that categorization brings to the EIP is information context. Within each organization, elements such as current business practices, management initiatives, corporate history, structure and culture, available professional resources, and learning requirements build up a context for working with information. To capture and support this context consciously is one of the early perceptions of the movement toward knowledge management practice in many organizations. For the EIP to succeed, the information available on it must reflect those established patterns and familiar context.

[0016] The search element provides a centralized utility for pinpoint access to specific information items (structured, unstructured and metadata) throughout the collections available at the EIP or accessible to it. The challenge in integrating and unifying search functionality is to confront the widespread frustration and skepticism that has developed among users through their experience with inadequate search mechanisms on the Internet. As a general guideline, EIP solutions need to have the ability to generate a comprehensive taxonomy, metadata access, full text access, and concept based search capabilities built into their search functionality.

[0017] As organizations continue to diversify the types and purposes of IT systems, the number of repositories for the maintenance of metadata will 'also grow. As EIP solutions are called upon to manage enterprise applications, business intelligence solutions, document management systems, and other sources of metadata, the requirement of centrally managing and being able to access multiple repositories will be critical.

[0018] Many organizations have already seen the value that "verticalization" of the portal offers. By taking advantage of vendor-packaged applications that deliver targeted content to specific industries or lines of business, organizations can significantly reduce implementation times. Typically, a good deal of time and resources are spent customizing the software components of EIP solutions. Sound EIP solutions offer the ability to "snap-in" specialized functionality and begin realizing rapid ROI, rather than spending time tailoring the portal to meet industry or departmental specific needs.

[0019] A need therefore exists for a fully customizable Web-based workspace that enables access to business-critical applications and information, including structured and unstructured data, for maximum competitive advantage. This EIP should be an enterprise-scalable, application- and platform-independent solution that features a plug-in architecture to seamlessly integrate any enterprise application to the EIP environment, allowing users to act on the information they receive. In general, the need exists for an enterprise information portal that provides organizations with a straightforward, secure, and efficient way of consolidating information access and centralization of enterprise solutions in a web-based environment. Such an enterprise information portal should support the advanced business transformation needed to enable organizations to leverage and harness their knowledge and intellectual assets in superior ways. In doing so, such an EIP solution should allow organizations drive their business forward and help them emerge as leaders in the new e-economy.

SUMMARY

[0020] In accordance with this invention there is provided an Enterprise Information Portal (EIP) for access by a user via a browser on a network, said portal comprising: (a) an interface for communicating between said portal and said user; (b) a theme manager for selecting a theme, said theme defining a presentation format for said browser; and (c) a plug-in manager for controlling a plurality of plug-ins, said plug-ins for retrieving and formatting information content for said user, wherein said plug-in retrieves information form both local and remote sources.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The invention may best be understood by referring to the following description and accompanying drawings which illustrate the invention. In the drawings:

[0022] FIG. 1 is a block diagram of an enterprise information portal (EIP) according to the present invention;

[0023] FIG. 2 is a screen capture illustrating an output produced by several e-clips inserted into a basic HTML page;

[0024] FIG. 3 is a block diagram illustrating how the e-clips fit into the functional architecture of a portal server;

[0025] FIG. 4 is a block diagram illustrating an e-clip structure;

[0026] FIG. 5 is an event trace diagram for the e-clip illustrated in FIG. 4;

[0027] FIG. 6 is a block diagram illustrating a portal server in its typical mode of operation where a resident Java based e-clip is executed;

[0028] FIG. 7A is a block diagram illustrating an e-clip structure having a distributed component residing on a different network node;

[0029] FIG. 7B is a block diagram illustrating a portal server executing an e-clip via an HTTP connection;

[0030] FIG. 8 is a block diagram illustrating an alternate e-clip structure;

[0031] FIG. 9 is a block diagram illustrating the differences between internal and external component access;

[0032] FIG. 10 is a block diagram illustrating how the theme manager fits into the functional architecture of the portal server;

[0033] FIG. 11 is a block diagram illustrating a sample theme structure;

[0034] FIG. 12 is a block diagram illustrating the general structure of a theme;

[0035] FIG. 13 illustrates a sample class structure of the theme manager;

[0036] FIG. 14 illustrates the general operation of the session manager;

[0037] FIG. 15 is a block diagram illustrating the overall structure of a navigation bar environment;

[0038] FIG. 16 is a block diagram illustrating the general architecture for a navigation bar e-clip;

[0039] FIG. 17 is a block diagram illustrating a navigation bar component of FIG. 16 in greater detail;

[0040] FIG. 18 is an event trace diagram for gathering data by the navigation bar component;

[0041] FIG. 19 illustrates the method steps for populating an EIP system's navigation bar with items from an integrated application;

[0042] FIG. 20 illustrates the method steps for searching an application using the EIP system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0043] For convenience, like numerals in the description refer to like elements in the drawings. Referring to FIG. 1, a block diagram of an enterprise information portal (EIP) in accordance with an embodiment of the present invention is illustrated generally by numeral 100. A user (not shown) accesses a portal server 105 via a hypertext transfer protocol (HTTP) service interface 104. The portal server 105 comprises an HTTP service servlet interface 106, which is coupled to an application session manager 110, a content manager 112, and an activity manager 114. The application session manager 110 is coupled with the content manager 112, which is coupled with the activity manager 114. The content manager 112 is further coupled to a theme manager 122 and an e-clip manager 120. The theme manager is further coupled to a theme specific help support 124
and a repository manager 126, which is in turn coupled to a repository 128. The e-clip manager 120 is coupled to the repository manager 126 as well as to a protocol manager 116. The protocol manager 116 is coupled to a network 118 such as the Internet. The application session manager 110
is farther coupled to a common authentication protocol (CAP) server 108. The CAP server 108, the repository 128, and the network 118 are external to the portal server 105.

[0044] The browser 102 is typically a hypertext mark up language (EML) viewer and acts as a main interface between the user and the portal server 105. The portal server 105 is designed to support as many simultaneous user connections as possible. Examples of browsers include Netscape's Navigator.TM., Microsoft's Internet Explorer.TM., Phone.com's UP.Browser.TM., and the like. The browser 102 and the HTTP service interface 104 are standard in the art and need not be discussed in greater detail.

[0045] The portal server 105 is responsible for displaying HTML pages that are either static or dynamic in nature. In the latter case, the portal server 105 generates displays by issuing requests to one or more e-clip components and collecting the resulting HTML produced for creating an output page.

[0046] The HTTP services servlet interface 106 is responsible for managing HTTP requests from several different sources. Requests can originate as a result of a user page request, or from another portal server requesting access to a given, shared component or e-clip residing on the portal server 105. The HTTP services servlet interface 106 is designed as a servlet that sits on top of an HTTP server, such as a web server or application server.

[0047] The application session manager 110 controls access to external applications registered to the portal server 105. It is not only responsible for managing individual user sessions, but also maintains a global session with each application. The latter is used to support a bidirectional heartbeat for insuring that both the application and the portal 105 are still alive.

[0048] The CAP server 108 is able to log individual users into the portal server 105 and manage security tickets produced by a centralized log-in system. This system is responsible for controlling access to shared pages, e-clips, and components. The CAP server is described in more detail in the applicant PCT applicator filed concurrently herewith and incorporated herein by reference.

[0049] The content manager 112 is primarily responsible for generating portal pages for user viewing. The content manager 112 works closely with the theme manager and the e-clip manager 120 for generating proper displays based on user preferences and page content.

[0050] The theme manager 122 manages themes specific information for providing "look and feel" information for the portal server 105. The theme manager 122 controls which themes are loaded and provides programmatic access to the properties of a theme. The theme dictates how the retrieved information is displayed to the user. The theme specific helps support 124 provides help in accordance with the selected theme. Theme-specific help 124 allows for different html, images, etc., for on-line help depending upon what theme the user is currently in, operating in th esame manner as themes in general. Therefore, if a user changes their UI in certain locations in EIP, only help 124 that applies to that changed UI is changed. In other words, help 124 has the same kind of hierarchical fallback as themes 122 in general.

[0051] The e-clip manager 120 controls the execution of all components and e-clips supported by the portal 105. These objects can be invoked by the content manager 112 when rendering pages or may be manipulated as a result of an external request from another portal server 105.

[0052] The repository manager 126 manages all data associated with the portal server 105. It manages user page and preference information, as well as all e-clips and components required for constructing and rendering pages. The repository 128 is the memory where the data is stored. The repository 128 may include a database, a file system, or the like. A portal administrator registers applications with the portal repository 128. A user interface allows the administrator to modify appropriate settings for the application.

[0053] The activity manager 114 is responsible for monitoring portal user activity for the purpose of building up portal statistics. This information includes user click activity, page creation details, and the like. The information is used for assisting other users attempting similar activities.

[0054] The components of the overall architecture described above are described in detail in the following sections. The description will provide firer details to the architecture and function of each of the individual components, and in some cases how they interact with each other.

[0055] The HTTP services servlet interface 106 is be identified as "hcleip" and is accessed as a URL using the following format:

[0056] http://<server>/servlet/hcleip?[portal parameters]

[0057] All classes relating specifically to the portal server shall be defined within a package-naming format as illustrated in Table 1 below.

1TABLE 1
com.hcl.portal.server This package contains all classes directly related to setting up and maintaining the portal server. This includes code for the EIP servlet. com.hcl.portal.manager.plugin This package manages the e-clip architecture including support for component sharing. com.hcl.portal.manager.content This package manages content provision for the portal. This group of classes supports page rendering and page loading com.hcl.portal.manager.theme This package contains all classess relating to management of portal themes. com.hcl.portal.manager.appsession This package supports all application session management for the portal com.hcl.portal.component This package is the conven- tional location for user- written components and those that are not part of the portal kernel. com.hcl.portal.utility This package contains all of the utility classes for the portal product, including replacer and string management support.

[0058] A "replacer" performs the task of replacing a given metatag buried in an HTML output stream with a specific block of replacement text. The replacer is typically a Java class that can be added as a filter to the stream of HTML being written back to the browser. When the replacer intercepts a metatag, it replaces that tag with a dynamic block of HTML code. For example, a replacer for the $title_text$ tag is added to the output stream for the replacement text, "<H1>This is the title</H1>".

[0059] The following source:

2
<HTML> <HEAD><TITLE>Replace sample</TITLE></HEAD> <BODY> <P> The title of this document is:</P> $title_text$ </BODY> </HTML>

[0060] Would appear as:

3
<HTML> <HEAD><TITLE>Replace sample</TITLE></HEAD> <BODY> <P> The title of this document is:</P> <Hl>This is the title</H1> </BODY> </HTML>

[0061] Replacers can be registered with the portal server 105 at any time. Until the replacers are unregistered, they will replace their assigned metatags transparently in the output stream.

[0062] The following section details the Application Program Interface (API) for accessing URL interfaces within the portal server 105. All servers that provide access to these objects should implement the HTTP interfaces to execute e-Clips and components.

[0063] As discussed above, the portal servlet code provides support for replacers. Since the replacer interface is not part of the HTTP server itself, page content containing replacers must be loaded through the servlet code. Most application servers load HTML and other content using commands in the form:

[0064] http://server/page.html

[0065] However, if there are any replacers in the loaded file, they will be ignored by the server's page loader. Furthermore, the portal server 105 will load user pages from a repository (to ease scalability in future releases). Therefore, pages cannot be loaded by specifying a simply URL.

[0066] To solve these problems, the HTTP services servlet interface 106
provides a special interface to perform the same page loading tasks from the page repository, and will process any replacers and e-clips as the pages are streamed to the browser. The URL used to accomplish this is of the form:

[0067] http://server/servlet/hcleip.cmd=page&object=page.html&user=<por- tal_username>

[0068] This URL format will work correctly even for pages without replacer tags. The "portal_username" element is used to indicate which user page repository this page originates in. Note that the portal server 105
itself is considered a special user "hcleip", which is the repository structure where the pages used to generate the default portal user interface reside.

[0069] Further, the HTTP services servlet interface 106 supports loading user, sector and theme pages [via the URL interface]. To load a user page, the command is of the following format:

[0070] http://server/servlet/hcleip?cmd=page&object:=page.html&user=user.n- ame

[0071] Note that requests for user pages are validated to ensure that the user has access to the page. To load a sector page the command is of the following format:

[0072] http.//server/servlet/hcleip?cmd=page&object=page.html&sctr=sectorm- ame

[0073] Note that each request for a sector page is validated to ensure that the user making the request has "read" access to the page. To load a theme page, no access validation is performed. The format is as follows:

[0074] http.//server/servlet/hcleip?cmd=page&object=page.html&theme=themen- ame

[0075] Note that to improve portability of theme pages between themes, a theme name replacer tag ($ThemeName$) can be specified instead of a hard-coded "Themename" value.

[0076] Themes usually require special images to produce the desired presentation. Like all other data for the portal, these images are stored in the repository, and are accessed through the [portal URL API] HTTP services servlet interface. The URL format for loading an image is as follows:

[0077] http://server/servlet/hcleip?cmd=iamge&object=image.gif&theme=theme- name

[0078] The portal uses a MIME.PROPERTIES file to determine the MIME type of the image. The portal server 105 supports image formats such as GIF, JPEG, and the like.

[0079] Once again, the portability of theme pages between themes can be improved by inserting a theme name replacer tag ($ThemeName$) instead of a hard-coded "themename" value.

[0080] A portal document is considered to be a user page plus a title and is targeted at the reserved frame name "EIPDocumentFrame". This frame includes a frameset consisting of a title bar and a page display frame. This functionality is typically used from a navigation bar. The navigation bar is a particular implementation of an e-clip, and is described in detail further on. The format is as follows:

[0081] http://<server>/servlet/hcleip?cmd=doc&object=page.html&title- =My+Title&user=Anonymous or,

[0082] http//<server>/servlet/hcleip?cmd=doc&object=page.html&title=- My+Title&sctr=sectorname

[0083] To access a component or e-Clip from an external source, the basic URL format is as follows:

[0084] http://<server>/servlet/hcleip?cmd=exec&type=<obj type>&object=<obj name>&request=<request>

[0085] where,

4
<server> Identifies the server name or IP on which this object will be executed <obj type> Determines if this object is a "component" or a "e-clip" <obj name> Identifies the unique name of this object <request> Contains the data associated with this object request

[0086] Within a user repository folder, each user is given a space into which their "personality" is stored. This information includes information such things as a profile (user.properties), a keychain (an encrypted file with account information), a personal table of contents (TOC), and any user pages that they own.

[0087] The user.properties file is a text file that stores most of the personalization for each user and is normally editable directly only by an administrator. The following an example of a typical profile:

[0088] FullName=Steve Gutz

[0089] NavbarOrder=Everyone,GuySmut,User,Administrator,Public,Steve.Gutz

[0090] DefaultTheme=Default

[0091] HomePageType=Sector

[0092] HomePageTypeName=Everyone

[0093] HomePage=defaultPortal.html

[0094] Applications=*

[0095] DisableSessionTimeout=true

[0096] Each of the valid fields for the user.properties file are described in Table 2.

5TABLE 2
Field Description FullName This field normally contains the full name of the user, but since it is editable from the user profile editor within the portal, it may contain any value. During normal operation, this field is ignored by the portal, but it's value is accessible either through the $SessionFullName$ replacer or through code from a plugin. NavbarOrder This field stores the user's preferred tree order. This represents the order in which sector contents are drawn within the user's navbar tree. It is controlled by the ordering mechanism in the user profile editor. DefaultTheme This value contains the user's preferred theme. HomePage This field stores the filename of the user's preferred start page in the portal. This is the page the user gets when he connects. HomePageType This field stores the type of repository folder in which the user's start page is stored. Valid values are "user", "sector", or "theme" HomePageTypeName This field stores the name of the repository folder in which the user's start page resides. Typically this would be the name of the user's own folder. Applications The use of this field is currently undocumented DisableSessionTimeout This field accepts a "true" or "false" value and is used to control how the portal session timeout code reacts to this user. If the value is true, the user's session will never timeout.

[0097] The following section defines the e-clip architecture for the preferred embodiment.

[0098] The e-clip architecture constitutes part of the portal server 105. The e-clip architecture is designed such that new applications and web-based information can easily be integrated into the portal server. The e-clip architecture further attempts to shelter developers from the underlying portal technology by providing simple interfaces to all of its capabilities.

[0099] Preferably, e-clips, which are also referred to as plug-ins, are designed such that individual components communicate using standard protocols. Therefore, data transferred between portal and external applications will preferably be described using extensible markup language (XML) and HTML. If required, network transfer of data is accomplished using HTTP.

[0100] The e-clip architecture is designed such that it excels readily to meet requirements of large user populations. Data sources are easily and transparently accessed across local Intranets, as well as the Internet and Wide Area Networks. The e-clips, and their integral parts, can be distributed and shared among multiple portal servers.

[0101] It is preferable that the core portal server code is written in pure Java and, therefore, is platform neutral by nature. E-clips are typically written in platform portable Java. However, as a result of an HTTP based communication protocol as will be described in this section, e-clips can be written in any computer language. Furthermore, in the preferred embodiment, an e-clip does not return simple binary data. All data returned from the e-clip is HTML compliant.

[0102] An e-clip is a collection of components responsible for accepting a request from the portal server and processing this request for producing the desired output. Output can be in the form of HTML for a visible e-clip, or some other custom form as required by the portal server. External communication to e-clips is performed through an HTTP/URL interface. Referring to FIG. 2, sample output produced by several e-clips inserted into a basic HTML page is illustrated generally by numeral 200. The page 200 is comprised of several sections each having information provided by a specific e-clip and merged into a single page. A first section 202 includes headlines from a local newspaper, a second section 204 includes a national weather forecast, a third section 206 includes a local weather forecast, and a fourth section 208 includes a current stock quotation. Note that the portal server is designed to generate e-clip results in both HTML table/cell format as well as within a separate HTML frame.

[0103] Referring to FIG. 3, a block diagram illustrating how the e-clips fit into the functional architecture of the portal server is shown generally by numeral 300. As previously described, a user requests a web page via the web browser 102. The web browser 102 retrieves the web page via HTTP server 104 and HTTP services servlet interface 106 on the portal server. The request is transferred to a client interface 302 for processing the client request. In accordance with a theme determined by the theme manager (not shown) the client interface accesses e-clips 304a to 304c as required. The details of the theme manager 122 will be discussed later. The e-clips 304a to 304c return the desired information to the client interface 302, which consolidates the information to a single web page and returns the web page to the user.

[0104] Alternately, the request for the e-clips may come from another portal server in a knowledge neighbourhood, since e-clips can be shared across portal servers. The other portal server 306 requests the information via the HTTP server 104, which is in communication with the portal server via HTTP services servlet interface 106. The portal server processes the request via a sharing interface 308, which accesses the e-clips 304a to 304c in a similar fashion to the client interface 302.

[0105] From the perspective of the e-clip architecture, the portal server interacts with an e-clip using a single point of entry and a single point of return. Typically, an e-clip will not be required to accept information from more than one data source. Several exceptions are possible, one of which is the possibility for an e-clip to merge a portal request with a request from a different source into a single output stream.

[0106] The portal server is a Java servlet that is instantiated by a simple application server and resides in a user workstation or corporate server. The portal server is responsible for managing user requests and determining which e-clip is required to service that request. The e-clip manager within the portal controls interactions between specific constituent components and is responsible for transferring information between them. The sharing interface 308 manages requests from other user portals and servers on the network and proxies these requests using internal e-clips.

[0107] All e-clips managed by the portal server consist of at least one component and are responsible for accepting a client request and producing output in a format digestible by the requesting client. Referring to FIG. 4, a sample e-clip structure is illustrated generally by numeral 400. In this particular example, a request is received from a client and input to a first component 402. Output from the first component 402 is input to a second component 404. Output from the second component 404 is input to a third component 406. Output from the third component 406 is sent back to the client as a response.

[0108] In this particular example, the components are organized in a daisy chain structure. The output produced by one component is fed directly into the request input for the next component in the chain. The first component 402 in the chain is typically responsible for querying the data source, while the last component 406 in the chain is typically responsible for ensuring the response is in a format acceptable to the client. Generally, this format is HTML.

[0109] Referring to FIG. 5, an event trace diagram for the e-clip architecture illustrated in FIG. 4 is shown generally by numeral 500. The client sends a page request to the portal server, which causes the portal to create an e-clip and issue a request to that e-clip. When the e-clip is created, the three components are created. However, the request issued by the portal is chained through each of the components in accordance with the architecture illustrated in FIG. 4. Therefore, once the e-clip receives the issue request from the portal, it sends the issue request to the first component 402. The first component 402 sends an issue request to the second component 404, which in turn sends an issue request to the third component 406. The third component 406 returns its response to the e-clip, which returns its response to the portal. The portal then responds to the client.

[0110] The c-clip illustrated in FIG. 4 is the simplest form, where the e-clip and all of its constituent components are Java code and they reside on the same virtual machine. Referring to FIG. 6, a portal server in its typical mode of operation, where a resident Java based e-clip is executed to produce output is illustrated generally by numeral 600. Internal e-clips offer the best performance because the e-clip object lives in the same virtual machine as the portal server.

[0111] However, e-clips can also be accessed from other portal servers in the knowledge neighbourhood. In this case, the e-clip is language neutral and is accessed across a network through a URL interface. The system on which the e-clip resides is therefore required to implement at least a rudimentary HTTP server for supporting the URL API, described later in this section.

[0112] Referring to FIG. 7A, a structure of an e-clip having a distributed component residing on a different network node is shown generally by numeral 700. A first server 702 and a second server 704 are coupled by a network 706. A first component 708 and a third component 710 reside on the first server 702 and a second component 712 resides on the second server 704. In an arrangement similar to the architecture illustrated in FIG. 4, the components are daisy chained together for producing a response to the client request. However, in the present example, the components are located on separate servers.

[0113] Referring to FIG. 7B, a portal server executing an e-clip via an HTTP connection is represented generally by numeral 750. The e-clip manager 120 accesses a remote e-clip manager 752 via an HTTP network 754, such as the Internet. The remote e-clip manager accesses a local e-clip 754 and returns the result to the e-clip manager 120 via the HTTP network 754. This provides the ability to distribute processing requirements across multiple servers, allowing for infinite scaling.

[0114] In yet an alternate structure, an e-clip response can involve more than a single sequential process. It is possible produce more complex e-clips that merge parallel requests into a single result, or which have internal components generate secondary requests and merge the results into the response.

[0115] Referring to FIG. 8, an alternate e-clip structure is illustrated generally by numeral 800. A first component 802 receives a request and transmits its response to a second component 803, a third component 804, and a fourth component 805. Each of the components 803-805 receive the request from the first component 802 and process it in parallel. Output from the second component 803, the third component 804, and the fourth component 805 is merged into a single stream, the result of which is the input to a fifth component 806. Output from the fifth component 806 is the e-clip response. The e-clip manager permits components 803 to 805 to operate either synchronously (sequentially) or asynchronously (in parallel threads). In the latter case, the fifth component 806 waits until all component threads have been completed before continuing.

[0116] An e-clip is simply a package of constituent components that manages a request and produces a response on behalf of a client. An e-clip is not a piece of purpose-specific code. Rather, an e-clip is described by a text file that is read by the e-clip manager. The following text describes an e-clip structure, similar to that illustrated in FIG. 4, containing three components. The first component handles page requests from the web, the second parses specific information out of the page, and the third component formats the result into an XML packet.

[0117] # Define the component chain to handle a retrieval from the web

[0118] # parse it and produce an XML output packet

[0119] com.hcl.portal.WwwComponent

[0120] com.hcl.portal.components.PageParserComponent

[0121] http://servet/servlet/hcpeip?cmd=exec&type=component&object=HTML2XM- LComponent

[0122] Note that the portal server transparently handles requests to and from components located external to the portal server. Therefore, in the e-Clip descriptor file shown above, the line:

[0123] http://server/servlet/hcleip?cmd=exec&type=component&object=compone- ntHTML2XML

[0124] describes a constituent component residing remotely on a component vendor. The remote component vendor is essential just another portal server. The e-clip manager automatically routes the request via an HTTP POST and retrieves the response from the remote server. Because components can be distributed to external computers, portal e-clips can become technically complex.

[0125] The e-clip is responsible for maintaining the current request and response data for all of its constituent components. As such it requires a number of attributes to manage data flow, as shown in Table 3.

6 TABLE 3
Attribute Description Name A character string uniquely identifying this e-clip. For example "eclipDF" could be the name given to the e-clip that accesses a DOCS/Fulcrum knowledge server. Request This field contains the current request information routed to the e-clip by the portal server. Response Once the e-clip has performed its duties, this field will contain the resultant data produced by the e-clip. ComponentVector This attribute maintains a list of constituent component instances that are contained within the e-clip.

[0126] The components within an e-clip are normally processed in the order in which now appear in the e-clip script. However, this scenario is not ideal for all situations. For example, if several components generate independent results involving different network operations, it will be advantageous to execute these components in parallel to improve overall e-Clip performance. The following e-Clip example shows three components that are executed in parallel on separate threads of execution.

[0127] # Define an asynchronous component chain cache=session

[0128] com.hcl.portal.WwwComponent

[0129] *com.hcl.portal.components.PageParserComponent1

[0130] *com.hcl.portal.components.PageParserComponent2

[0131] *com.hcl.portal.cornponents.PageParserComponent3

[0132] com.hcl.portal.components.PageMergerComponent

[0133] Note in the example the addition of a leading "*" character on entries that can be executed asynchronously. The e-clip manager interprets these special characters and automatically executes the components on separate threads of execution. The component immediately following the asynchronous lines shall be blocked until all previous threads have completed.

[0134] Often a component will need to obtain the results of a previously executed component. The e-clip manager provides access to these components through a standard API in code. However, access is provided from within an e-clip script. For example:

[0135] # Define an asynchronous component chain cache=session

[0136] com.hcl.portal.WwwComponent

[0137] com.hcl.portal.components.Component1

[0138] com.hcl.portal.components.Component2

[0139] com.hcl.portal.components.Component3 $com.hcl.portal.components.Com- ponent1

[0140] com.hcl.portal.components.Component4

[0141] In this example, Component3 takes its initial input request from the output generated by Component1. The "$" followed by a fully qualified component name will automatically obtain the request information from the named source.

[0142] The HTTP services servlet interface supports many different types of clients. For example, in addition to web browsers, XML formatted output could be used to integrate directly into MS-Office or other common application. Therefore, the e-clips are accessible through standard URL requests as well as internal XML/HTML requests. This section details the interfaces for both request mechanisms.

[0143] The URL format for requesting an e-clip from the portal server is as follows:

[0144] HTTP://server/servlet/hcleip?cmd=exec&type=eclip&object=myEclip&req- uest=Myrequest

[0145] The details of the URL format are described in Table 4.

7TABLE 4
Cmd=exec States that this is a URL to execute an e-Clip or component Type=eclip Defines this as a request for a specific e-Clip residing on this server. Object Is the full unique name of the e-Clip Title Contains a title string that will be displayed in the title bar of this e-clip. Border Contains a true or false value to indicate if this e-Clip will be drawn with a border. If its, the portal will encase the e-Clip output within a border. Request Contains the request parameters for the e-Clip. This request must adhere to whatever the format the e-Clip demands. The portal server will not tamper with any data in this field Id Contains a string that uniquely identifies this instance of the e-Clip. This identifier is meaningful only if the e-Clip is cached either globally or in session and is used by the e-Clip manager to locate instances of e-Clips within the cache.

[0146] The portal server supports both HTTP GET and POST type requests. E-clip requests containing large amounts (>1024 bytes) of information typically use a POST request.

[0147] The portal server also accepts requests in XML formatted packets and will automatically extract e-clip request information and replace it with the e-clip's response. The following listing is an XML packet that supplies a request to a specific e-clip:

8
<html> <head></head> <body> <ECLIP name="WwwEClip" id="helloWorld" title="My Title"> http://server/hello.html </ECLIP> </body> </html>

[0148] Executing this XML-based request produces:

9
<html> <head></head> <body> <P>Hello World</P> </body> </html>

[0149] The following are a set of rules for the present embodiment. These rules are particularly useful for HTML based systems. However, for other language-based systems, various modifications to the rules will be apparent to a person skilled in the art.

[0150] 1. e-clips must always produce complete HTML fragments.

[0151] 2. e-clip must never include header tags such as <html>, <head>, body>, etc.

[0152] 3. It is understood that an e-clip's output may be placed within an HTML table cell or within an HTML frame without corrupting the display.

[0153] 4. e-clips must be capable of residing on the same user page as other e-Clips without causing display corruption.

[0154] As previously mentioned, an e-clip is a container for components and is responsible only for routing requests and responses between them. A component contains a minimum set of information required by the e-clip manager, but may contain additional information to support the specific functionality within the component. Table 5 details the e-clip specific attributes of a component.

10 TABLE 5
Attribute Description Name An identifier uniquely identifying this component. For example "WwwComponent" would be the name to the component that accesses the web to load an HTML page. Server If the component is remote to the portal server, this field will contain the URL required to access the component in its remote location. Request This field contains the current request information. response Once the component has performed its duties, this field will contain the resultant data produced by the component.

[0155] A component is coupled to an e-clip either tightly (by providing an internal Java class) or loosely (by providing a URL path to the component code). In the latter case, the component can reside anywhere on the network including the local workstation. However, for performance reasons, any local component written in Java should avoid network interaction and expose an internal interface for access. Local components written in languages other than Java must implement their own external HTTP interface. Referring to FIG. 9, the differences between internal and external component access is illustrated generally by numeral 900.

[0156] The HTTP service servlet interface supports requests from external sources for component access. That is, the portal is a component vendor and must be able to service other portals requesting access to specific shared components. Preferably, all access to components from external server portals is done via an HTTP request by specifying a URL. The URL format to request a component from the portal engine is as follows:

[0157] HTTP://server/servlet/hcleip?cmd=exec&type=component&object=myComp&- request=MyRequest

[0158] The details of the URL format are described in Table 6.

11TABLE 6
cmd=exec States that this is a URL to execute an e-clip or component type=component Defines this as a request for a specific component available on this portal server Request Contains the request parameters for the component. Note that this request must adhere to whatever the format the component demands. The portal engine will not tamper with any data in this field. object Is the full name of the component (for a Java-based component, this includes the full package designation for the class)

[0159] The portal engine supports both HTTP GET and POST type requests. Part requests containing large amounts of request information typically use a POST request.

[0160] For testing purposes, a complete test suite is provided for exercising each e-clip. These tests are validated on each platform supported by the portal server. Each individual component is tested separately on each applicable platform before fall integration testing is done within an e-clip.

[0161] Some platforms support several different Java virtual machines (for example, Microsoft Windows.TM.). On such platforms, e-clips and component objects should be verified with as many virtual machines as possible. For Windows.TM., tests should be run for virtual machines from Sun, Microsoft and IBM as a minimum.

[0162] Each distributed e-clip and component should be tested independently of an entire system. Since each e-clip and component provide a single point of entry and return, a simple test harness can be designed to verify the operation of these classes.

[0163] As previously described, an e-clip is simply a list of components and optional request parameters that perform a specific task. An e-clip accepts an initial request and produces output defined by the last member of its component chain, which is typically an HTML formatter. E-clips are defined as scripts and are contained in standard text files with the following naming convention:

[0164] <eClipName>

[0165] where eClipName matches the unique name of the e-clip and there is no file extension. As sample e-clip script containing a two component chain is as follows:

12
<ECLIP> <DESCRIPTION> Define the component chain to handle a retrieval of the front page for the Ottawa Citizen </DESCRIPTION> <PARAMETERS> cache=session </PARAMETERS> <COMPONENTS> com.hcl.portal.component.WwwComponent http://www.citizen.com/frontpage.html ottawaCitizenComponent </COMPONENT> </ECLIP>

[0166] The first component line declares a component com.hcl.portal.component.WwwComponent that takes a URL and retrieves an HTML page from that location. The e-clip then passes this text to the "ottawaCitizenComponent", which extract items of particular importance. The results of this component, being the last in the chain, are returned to the e-clip and ultimately back to the portal server for display.

[0167] Components can be accessed from a remote portal server or vendor. In these situations, the remote component us accessed using the URL API. The following script shows an example of this:

13
<ECLIP> <DESCRIPTION> Define the component chain to handle a retrieval of the front page for the Ottawa Citizen </DESCRIPTION> <PARAMETERS> cache=session </PARAMETERS> <COMPONENTS> com.hcl.portal.component.WwwComponent http://www.citizen.com/frontpage.html http://anotherportal?cmd=- exec&type= component&object=ottawaCitizenComponent </COMPONENT> </ECLIP>

[0168] The e-Clip manager automatically routes the component request to the remote object and retrieves that object's results.

[0169] For performance reasons, the results produced by an e-clip are cacheable with either a global scope, wherein the results are available to all users, or with a session scope, wherein the results are available only to the current user. Caching should be used only when a given request generates the same output for an e-clip each time it is executed. e-clips that manipulate session-based servers (such as Docs/Fulcrum) should either not use cached e-clips or should use them cautiously. Conversely, e-clips associated with stateless data such as web pages should use caching to improve client performance and reduce network traffic. By default, e-clips are not cached. To locate cached e-clip instances, the e-clip manager keys on the e-clip name, the optional unique identifier and, in the case of non-static cached e-Clips, the last request it executed.

[0170] Caching is controlled by inserting a configuration parameter into the c-clip script.

[0171] The format is as follows:

[0172] cache=<cache scope>

[0173] Where <cache scope> is one of the variable described in Table 7.

14 TABLE 7
Global The cached results are preserved in the global space of the portal server and are available to all user pages making the same request for the e-Clip. This scope should be used only for information which is not sensitive (i.e. public knowledge) Session The cached results stored within the user's are available only to this one user. This scope should be used for e-Clips that generate repetitious information that might be sensitive to a given user. Transient This default scope indicates that each time the e-Clip is executed, it's results are regenerated (no caching is performed)

[0174] In addition to the cache scope, an e-clip script also permits the specification of a refresh time for the cache. This is used to determine if the data for a cached e-Clip needs to be reacquired. The format of the refresh parameters is:

[0175] refresh=<refresh time>

[0176] where <refresh time> is a combined numerical value and weight character. The weighting for the number is determined using Table 8.

15 TABLE 8
s The refresh time is specified in seconds. This is the default and omitting the weighting character completely will resolve refresh in seconds as well. m The refresh time is specified in minutes h The refresh time is specified in hours. d The refresh time is specified in days w The refresh time is specified in weeks

[0177] Therefore, for example, if the refresh is set as refresh=3d, the e-clip cache is discarded every three days. If the refresh line is omitted or the specified value is "0", the cached item will never refresh. However, e-clips cached against the session will refresh the next time the user connects the browser to the portal server.

[0178] Caching does not solve simple data persistence problems within an e-clip. Since the c-clip manager does not pass requests to previously cached components, an extension is defined to control data persistence. To enable e-clip persistence for cached objects, a modifier is added to the "cache" statement in the in e-clip description. The form of this statement is as follows:

[0179] cache=<cache scope>,static

[0180] The addition of the "static" modifier prompts the e-Clip manager to react differently than it does for normal e-Clip caching. In this case a request is passed into the e-clip as it would be for a transient e-clip. However, all data from previous executions of the e-clip remains. This allows e-clips to effectively store data within the storage space scoped by the "cache" statement (either globally or within the user session). The "static" modifier is ignored if it is added to a "cachetransient" statement.

[0181] The e-clip script can contain a number of statements to control how it is rendered in the portal server. Table 9 shows additional parameters that can be applied to an e-clip.

16TABLE 9
Parameter Description Example Title This parameter defines the default title="This is my title" title used for any instance of this (Default value: "") e-clip. The title is enclosed in double quotes. If present, the e-clip is rendered with a caption bar. This parameter can be overridden within a <PLUGIN> tag in a user page. Border This boolean parameter controls border=true the presence of a border around the (Default value: false) e-clip when it is rendered by the portal. This parameter can be overridden within a <PLUGIN> tag in a user page. Showrefreshbutton This boolean parameter control the showrefreshbutton=true presence of a manual refresh (Default value: false) button within the caption bar of the e-clip. The refresh button allows the user to manually re-fetch the e-clip contents from its specified source and re-render the page. This parameter can be overridden within a <PLUGIN> tag in a user page. pageref This parameter specifies a URL pageref="http://www.cnn.com" that is invoked within a separate (Default value: "") browser window when the user select the "show in new window" button in the caption bar. This button automatically appears if the pageref tag is present in the e-clip. The URL appears within double quotes. This parameter can be overridden within a <PLUGIN> tag in a user page. id This parameter specifies a unique id=AnyString value for the e-clip. This can be (Default value: "") used when there is more than one cached e-clip with the same name and different data. Unbounded This boolean flag controls how the unbounded=true e-clip will be rendered. If set to (Default value: false) false the e-clip will be bounded by an HTML table when rendered, otherwise no table bounding will be performed. This tag is meant for internal use only. Showrefreshtime If this boolean flag is true, then the showrefreshtime=true e-clip is rendered with a caption (Default value: false) bar including the last time this e-clip was refreshed. Renderer This parameter specifies the renderer=com.hcl.portal. rendering component for an e-clip. component.TreeRenditionComponent The rendering component is the (Default value: N/A) last entry in the component chain and is responsible for generating the final HTML for the e-clip

[0182] The are two ways to create a component. The easiest method is by using a generic scripting component and providing a script file. Scripting may not be sufficient to complete a task, however. So the e-Clip architecture will also support creating components with code. The following Java source code accepts a URL wraps it in an HTML image tag:

17
package com.hcl.portal.component; import java.io.*; import java.net.*; public class componentHtmlImg extends PortalComponent { public componentHtmlImg( ) { } public void handleRequest( ) { StringBuffer sb = new StringBuffer( ); sb.append( "<IMG SRC=" + getRequest( ) + ">.backslash.n" ); setResponse( sb.toString( ) ); } }

[0183] The details of the PortalComponent class will be shown later. However, an important point of this source code is the handleRequest( ) method, which be implemented for each component. Within the code shown above, the incoming request (a URL pointing to an image) is simply wrapped in an HTML image tag and this new string is written as the response value from this component.

[0184] However, the structure of most components is sufficiently similar that they can be created using simple scripts, rather than compiled code. The portal server includes a generic "scripting component" that accepts instructions via a scripting language and uses these instructions to interpret the incoming request and generate an outgoing response. For example, the following is a sample, scripted component:

18
<COMPONENT> <DESCRIPTION> These rules define the extraction range to get local stock quotes from the Ottawa Citizen </DESCRIPTION> <TAG> $Body$ <!--STOCKS START- -> <!--STOCKS END- -> </TAG> <REPLACE> <TABLE BORDER="0" WIDTH="100%"> <TR VALIGN="TOP"> <TD ALIGN="LEFT"> $Body$ </TD> </TR> </TABLE> </REPLACE> </COMPONENT>

[0185] This script defines a replacer called $Body$ which is defined to be all of the text between "<!-STOCKS START->" and "<!-STOCKS END->" within the raw HTML for a given page. The script:

19
<Replace> <P> $Body$ </Replace>

[0186] tells the generic component to replace whatever the e-clip offers as the request input with the contents of the $Body$ replacer prefixed by an HTML paragraph tag.

[0187] This section details the API used by the generic scripting component. The scripting language allows developers to intercept and modify text as it passes from the input side to the output side of a component. If the component contains no script then it acts like a pipe, simply passing data from the input to the output side. Scripting provides a mechanism to intervene in this operation to insert or remove text, or to completely replace block of data with something different.

[0188] The <Tag> definition is used to define a replacer metatag for a range of text within the input request stream.

20
<TAG> metatag start string end string </TAG>

[0189] The "metatag" identifies the name of the metatag. This string should be unique within the input stream, so it will typically have the format <$metatagname$>. The "start string" identifies a unique string pattern within the input stream where the replacer content begins. The "end string" identifies a unique string pattern where the replacer content ends.

[0190] This format provides a facility to extract a block of text from the input stream delimited by the start and stop strings and associate it with a replacer metatag that can be used in the output stream of the component. The generic scripting component automatically creates a replacer to manage the text replacement for all metatags defined in the script. Finally, there is virtually no limit on the number of metatag values that can be extracted from the input stream or written to the output stream. However no overlap of metatag replacement text can occur.

[0191] A "DELETE" script tag removes a specified range of data as it passes through the component. The format for the "DELETE" script tag is as follows:

21
<DELETE> start string end string </DELETE>

[0192] where the start and end string values define string patterns within the data stream where data will be removed. The deletion is inclusive of the start and end strings.

[0193] A "DELETEFROM" script tag removes a block of data from a specified matching "start" string to the end of the data buffer. The format is as follows:

22
<DELETEFROM> start string </DELETEFROM>

[0194] where the "start string" defines a string pattern within the data stream from which data removal will start. All data from this point to the end of the buffer is removed.

[0195] A "DELETETO" script tag removes a block of data from the beginning of the data buffer to a specified matching "end" string. The format is as follows:

23
<DELETETO> end string </DELETETO>

[0196] where the "end string" defines a string pattern within the data stream at which data removal will end. All data from start of the buffer to the specified end point is removed from the buffer.

[0197] A "PREFIX" script tag allows the insertion of data to the output stream before the incoming data is passed through the component. For example, this tag is used when header information must be inserted into the data stream. The tag format is as follows:

24
<PREFIX> Data lines to be inserted </PREFIX>

[0198] A "POSTFIX" script tag allows the insertion of data to the output stream after the incoming data is passed through the component. For example, this tag is used when footer information must be inserted into the data stream. The tag format is as follows:

25
<POSTFIX> Data lines to be inserted </POSTFIX>

[0199] A "SUBSTITUTE" script tag allows the substitution of data in the stream with different data For example, this tag is used to correct errant URLs. The tag format is as follows:

26
<SUBSTITUTE> Original Data New Data </SUBSTITUTE >

[0200] A "REPLACE" script tag replaces the entire contents of the component response with a block of data identified. Any metatags defined by the <Tag> definitions or standard replacer tags are replaced within the block of data written to the output stream.

27
<REPLACE> Replacement lines of data </REPLACE>

[0201] The replacer tags defined in the script above are a few examples of the possibilities of the e-clip system. Furthermore, a script file for a component can contain a number of standard replacer tags. The following section outlines some examples of hard coded replacer tags that can be used when scripting components.

[0202] $eClipRequest$

[0203] An original request string passed to the e-clip replaces all instances of this tag in the script. This provides access to the original request string at any point in the e-clip component chain and allows custom URL parameters to be passed to specific components.

[0204] $ComponentRequest$

[0205] A request string that was passed to this component replaces all instances of this tag. This is useful when the original request string must be extended in some way before passing it to the next component in the chain.

[0206] The following are some examples of component scripts. A first example illustrates text deletion, as follows:

28
<COMPONENT> <DESCRIPTION> This script removes a specified range of data from an HTML page <DESCRIPTION> <DELETE> <!--Ad start- -> <!--Ad end- -> </DELETE> </COMPONENT>

[0207] A second example illustrates text replacement, as follows:

29
<COMPONENT> <DESCRIPTION> These rules define the extraction range to get the detailed Ottawa Weather out of the Weather Network's web server. <DESCRIPTION> <TAG> $Body$ <!--CURRENT CONDITIONS- -> <!--Begin generated HTML- -> </TAG> <REPLACE> <P> $Body$ </REPLACE> </COMPONENT>

[0208] A third example illustrates postfix data, as follows:

30
<COMPONENT> <DESCRIPTION> These rules describe how a SearchServer query server (based on SBJ) can accept a search request. On input, the component must identify the servlet to which this request will be made along with any fixed parameters. This component script will then add (to the end of that string) any additional parameters required to complete the search, including the search request string. <DESCRIPTION> <POSTFIX> ?key=fancy&fc=DOCS&qs=$partRequest$ </POSTFIX> <COMPONENT>

[0209] The following section details the theme manager 122 for the preferred embodiment. The theme manager 122 constitutes part of the portal server 105. The theme manager 122 is an asynchronous process within the portal engine 105 that is responsible for managing access to images and pages based on a selected look-and-feel selected by the user of the portal administrator. Themes encompass overall presentation of the portal user interface including e-clip rendering, navigation bar display and operation, and the language of the user.

[0210] The theme manager 122 supports object-like hierarchies of themes. Therefore, one theme may be based on another, while providing new or different rendering of e-clips, pages, and images. The theme manager 122
stores and retrieves information relating to themes within the portal repository 128.

[0211] In addition to a default central portal theme, the theme manager 122 provides a configuration interface to permit users to select a theme from a list. Each user theme operates independently of the default system theme and the theme selected by other users. Theme creation and configuration is made as simple as possible. In the preferred embodiment, this is accomplished through HTML and text editors.

[0212] Referring to FIG. 10, a block diagram illustrating how the theme manager 122 fits into the functional architecture of the portal server 105 is shown generally by numeral 1000. The theme manager 122 interacts with the portal server block to receive page and image requests, with the content repository to load user pages, and with the e-clip manager to render e-clips displays. The Theme Manager is an asynchronous process within the portal engine responsible for rendering the user interface of the user's portal session.

[0213] The content manager is an asynchronous process within the portal engine responsible for generating content based on requests received from the client browser. The e-clip manager controls the execution of all components and e-clips supported by the portal, as previously described. These objects can interact with the theme manager to render e-clips with the correct appearance for the selected theme. The repository manages portal pages and images for each theme residing within the portal. All information relating to the themes themselves originates in the repository.

[0214] The theme manager performs asynchronous queued operations on behalf of all users of the portal 105. The portal initialization code creates a single instance of the theme manager object that is used by all request operations.

[0215] The theme manager is a block of code within the portal 102 for managing templates. These templates specify fonts, colors and images relating to a particular presentation style. Theme templates are inheritable, which means that one theme can be based on another, in whole or in part.

[0216] Referring to FIG. 11, a sample theme structure for the present embodiment is illustrated generally by numeral 1100. A base template 1102
provides basic presentation information. In the present embodiment, the base template is referred to as "EIPBase". All other themes and language specific renditions evolve from the EIPBase template 1102.

[0217] For example, a plurality of language specific base templates 1104
is derived from the base template 1102. Examples of such language specific base templates include a French template 1104a, a German template 1104b, a Japanese template 1104c, and a Korean template 1104d. A plurality of user interface specific templates 1106 is derived from the language specific base templates 1104. For example, a first French (or default) theme 1106c, a second French (or fancy) theme 1106b, and a third French (or simple) theme 1106a are derived from French template 1104a.

[0218] Furthermore, in addition to siring language-specific theme bases 1104, the EIPBase template 1102 also directly provides default pages and images required for English language support. These include a default theme 1106d, a fancy theme 1106e, and a simple theme1106f. Typically, for each language specific theme, three themes will be provided as follows as indicated in Table 10.

31 TABLE 10
Theme Description Default This theme is the "middle-of-the-road" theme. It provides standard HTML with a minimum of glitz. It is designed for standard 4.x-level web browser on desktop and notebook systems. Fancy This theme makes maximum use of advanced browser capabilities to present the most appealing portal presentation possible. Simple This theme is designed for use on palm-based PDAs such as Pilots and WinCE systems. Typically, it exploits no advanced features and is design to support the reduced screen size of handheld devices.

[0219] Themes are basically a bin into which theme pages and images are stored and can be retrieved upon request by the portal 105 or a user. Referring to FIG. 12, the structure of a theme is illustrated generally by numeral 1200. A theme 1202 comprises theme pages 1204 and page images 1206. The theme pages 1204 include a plurality of web pages 1206. The web pages 1206 may or may not contain frames and framesets. The page images 1206 comprise a plurality of images in various image formats including GIF, JPG, TIF, and the like.

[0220] The only restrictions on a theme in the present embodiment are the inclusion of a start page named portalEIP.html and a document display page named portalDocument.html. The purpose of these pages is described later in this section.

[0221] To request a theme page using the portal API, a URL of the following form is used:

[0222] http://server/servlet/hcleip?cmd=page&object=pageName.html&theme=&l- t;theme name>

[0223] where <theme name> is the name of the theme containing the page. If the URL reference is referenced from within an HTML document, the "$ThemeName$" replacer tag can be used instead of the actual theme name. This allows for theme-independent pages wherein the content manager replaces the tag with the name of the theme currently loaded for the user. If the page doesn't exist in the current theme, the theme manager reverts to a parent theme. Similarly, to load a theme-specific image, a URL of the following format is used:

[0224] http://server/servlet/hcleip?cmd=image&object=imageName.gif&theme=&- lt;theme name>

[0225] As noted, themes can be based on other themes, which provides a powerful capability to revert, or "fallback", to a parent theme when requested. This allows theme creators to derive new themes from existing themes and replace or implement only new features. For example, if a new theme based on "Default" does not provide a "portalEIP.html" file, attempts to load this page from the new theme will prompt the theme manager to load it from the "Default" theme. If, however, the new theme based on "Default" does provide a portalEIP.html page, it will be loaded and any similar files existing within the theme hierarchy will be ignored. Fallback works for any theme page or image. As long as the requested resource lies within the hierarchy of a theme, the theme manager will find it.

[0226] Each theme provides a configuration file named "theme.properties" that describes the uniqueness of the theme. The following list illustrates theme properties for a sample theme:

32
ParentTheme EIPBase BackgroundColor #F5F5ED DialogTextColor #034C71
DialogBackgroundColor #CCDCEA CaptionTextColor white CaptionBackgroundColor #00639C NavbarBackgroundColor #CCDCEA NavbarTextColor black

[0227] Typical properties included in a theme are listed in Table 11.

33TABLE 11
Property Name Description ParentTheme This value identifies a parent theme. Generally, a value is specified for this property. When in doubt use "EIPBase" Watermark Specifies the background image used for all pages rendered with this theme. This image is applied to all user pages displayed by the portal. The default from EIPBase is PortalBackground.jpg. This value and a"BackgroundColor" property are mutually exclusive. BackgroundColor Specifies the background color for all pages rendered with this theme. This color is applied to all user pages displayed by the portal. DialogBackgroundColor Specifies the background color used by all display elements that "look" like dialog boxes. For example, the portal login screen uses this value to paint the background of the form it displays. DialogTextColor Specifies the text colour used by display elements that "look" like dialog boxes. For example the portal login screen uses this value to paint the text of the form it displays CaptionBackgroundColor Specifies the background color used in the title bar of all display elements that "look" like dialog boxes. For example the portal login screen uses this value to paint the background of the cell containing the form title. This value is also used for the title of any rendered e-clip titles CaptionTextColor Specifies the text color used in the title bar of all display elements that "look" like dialog boxes. For example the portal login screen uses this value to paint the text of the form title. This value is also used for the title of any rendered e-clip titles NavbarBackgroundColor Specifies the background color used in the navigation bar e-clip. NavbarTextColor Specifies the text color used in the navigation bar e-clip.

[0228] The following section outlines reserved pages stored in the theme. Typically, only pages directly relating to the portal will ever be changed by theme creators. Pages relating to e-clips should not be modified under normal circumstances. Theme names that begin with the letters "EIP" are reserved for portal use. Any theme whose name begins with this sequence will not appear in a theme selection list presented to the user and is strictly for creating base themes. The base versions of these pages reside in the EIPBase theme in the repository.

[0229] The portal reserves a large number of page-names within all themes exclusively for its own use. Although new themes are free to re-implement these pages, their use must remain specific. This section outlines these reserved pages and their uses.

[0230] Theme pages are used directly by a theme and can be overridden in any theme. Samples of such pages are provided in Table 12.

34TABLE 12
Page Description PortalEIP.html The portal invokes this page after a user logs in to the portal. It is the top-most page of the portal and typically will contain only framesets. PortalDocument.html This page is sent to the browser in response to a "cmd=doc" URL request. It typically contains a frameset containing a titlebar and a replacer for the document page being displayed. portalAccessError.html Displayed when the user tries to access a page to which he has no rights portalBlank.html Displays a blank page userLogin*.html Displays the login page using a single contained e-clip: utilityLogin. userLogout*.html Contains the form asking the user if he really wants to log out portalTitledPlugin.html Contains a template for e-clips that display a title bar. portalUntitledPlugin.html Contains a template for e-clips that do not display a title bar.

[0231] Login Pages

[0232] These pages are used by the utilityLogin e-clip. This internal e-clip is responsible for showing the login screen to the user and passing it's form input to the portal for authentication.

35
Page Description userLoginTable*.html Contains the HTML presentation for the login page. userLoginSimple.html Contains the login form for simple username/password logins. userLoginDomain.html Contains the login form for qualified username/password/domain logins.

[0233] Administration Pages

[0234] These pages are used by one of the internal administration e-clips:

36
Page Description adminAppConfig.html Contains the HTML script to administer the applications associated with the portal adminSectorManagement*.html These pages are used by the group maintenance e-clip adminViewPlugins*.html These pages are used by the e-clip maintenance e-clip. adminUserManagement*.html These pages are used by the user administration e-clips adminAppManagement*.html These pages are used to administer external applications integrated into the portal AdminRepositoryImport*.html These pages are used to administrate repository importing and maintenance. AdminServerStatistics*.html These pages are used to display server statistics.

[0235] Sample pages used by one of the internal user configuration e-clips are described in Table 12.

37TABLE 12
Page Description UserEditProfile.html Contains the HTML UserPropertiesEditor*.html script to modify UserKeyChainEditorForm.html the user's profile, UserKeyChamEditorFormQualified.html including the UserKeyChainEditorFormSimple.html application keychain. As previous described, the keychain is an encrypted file containing account information UserUP*.html These pages are used to manage user page creation for the portal.

[0236] FIG. 13 illustrates a sample class structure of the theme manager for the preferred embodiment, which is represented generally by numeral 1300.

[0237] The following section details the application session manager 110
for the preferred embodiment. The portal server 105 manages two types of session within each application in use. First a global session, to which timer events are sent and on which all user sessions depend, is managed. Second, user sessions each corresponding to a unique user of the portal server, is managed. Each session requires application-specific login credentials to be provided by the portal repository. Such a system is particularly useful

[0238] Referring to FIG. 14, the general operation of the session manager is illustrated generally by numeral 1400. The portal server 105
communicates with an application 1404 in a sequence of steps. On a first request to use the application 1404, the EIP requests a global session and specifies a timeout value. In response, the application 1404 creates a session and returns its identifier to the portal server 105. In order to create a new user sessions, the portal server 105 requests a user session, referencing the global identifier previously received. The application 1404 creates another session and returns its identifier to the portal server 105. Periodically, the portal server 105 issues a "keepalive" request on the global session to prevent a session timeout.

[0239] When a user interacts with the portal server, such interaction is typically personal in nature. That is, the tasks that the portal server allows a user to complete in a cooperating application reflects the privileges and responsibilities that the user would enjoy were they to interact directly with the application without the intervention of the portal server. A cooperating application is an application that provides the portal server with registration information such that the portal server can reflect elements of the functionality of the application. An example is the navigation bar, which is described further on.

[0240] Further, the portal server provides the cooperating applications information regarding a failure in the portal server allowing them to shutdown outstanding user sessions This information is propagated to the applications without undue burden on the system as a whole.

[0241] Users of the portal server are allowed to interact with cooperating applications via CAPS in a fully secure mode, without requiring the user to login to the application. Therefore, the portal server itself maintains some information regarding the identity of the user. This is true not only in the context of the portal but also in the context of every cooperating application. This context is used for establishing a session in cooperating applications.

[0242] User credentials for every cooperating application are securely stored in the repository. The repository holds a secure keychain for each user, specifying the login credentials for that user in each cooperating application.

[0243] Each registered application informs the portal server what credentials it requires to validate a user. This information is stored in a "properties" file in the portal repository under an Applications branch. For example, the directory structure may appear as:

38
.backslash.Applications .backslash.DOCSFulcrum .backslash.application.properties

[0244] In the present embodiment, the application.properties file comprises the following attributes:

[0245] ApplicationID=<app ID form, e.g. Hcl.Fulcrum>

[0246] ApplicationTitle=<full, descriptive name of application>

[0247] AuthenticationType={simple.vertline.qualified}

[0248] QualifierTitle=<name of qualifier, e.g. Domain>

[0249] SupportsAnonymous={true.vertline.false}

[0250] RequiresSession={true.vertline.false}

[0251] DAC=<class name of data access component to use>

[0252] NavBarURL=<where is the app's NavBar bandler?>

[0253] NavBarDTDVersion=<version of NB DTD understood by application>

[0254] The portal server uses these attributes to present a configuration page to end-users. The configuration page allows the users to specify their own login information for each cooperating application.

[0255] In the case of a "simple" authentication type, the portal presents a username and a password entry fields. In the case of a "qualified" authentication type, the portal also presents a qualifier field, entitled with a qualifier title value. If the "Supports Anonymous" attribute is set to "true", the portal gives the user the opportunity to connect to the application without specific credentials. The "Requires Session" attribute is used by the application session manager to determine whether it should establish a specific session for the user, or whether the cooperating application in question is transactional in nature.

[0256] For example, consider the following sample "application.properties"- :

[0257] ApplicationID=hcl.fulcrum

[0258] ApplicationTitle=DOCSFulcrum

[0259] AuthenticationType=qualified

[0260] QualifierTitle=NT Domain

[0261] SupportsAnonymous=true

[0262] RequiresSession=true

[0263] DAC=com.hcl.portal.component.HttpDAComponent

[0264] NavBarURL=http://elmo/cgi/dfxml.dll

[0265] NavBarDTDVersion=v1

[0266] Using these attributes, the portal might create the following HTML portion:

39
<TABLE> <TR VALIGN="TOP"> <TD WIDTH="50%"> <TABLE BORDER="0"> <TR> <TD>Specify credentials for: DOCSFulcrum</TD> </TR> <TR VALIGN="CENTER" > <TD>User name:</TD> <TD><input type="text" name= "DOCSFulcrum_un"></TD> </TR> <TR VALIGN="CENTER" > <TD>Password:</TD> <TD><input type="password" name= "DOCSFulcrum_pw"></TD> </TR> <TR VALIGN="CENTER" > <TD>NT Domain:</TD> <TD><input type="text" name= "DOCSFulcrum_qual"></TD> </TR> </TABLE> </TD> </TR> </TABLE>

[0267] This portion of HTML is written within the framework of a larger HTML form, containing input's for all the cooperating applications that are installed in the portal server. This form is the user preference form that is presented to the user on a first login.

[0268] A secure storage mechanism is created on a per-application, per-user credential basis. The per-user, per-application credentials are stored in the repository, under the user's private folder in an encrypted file called "keychain.properties". The encryption class used to encrypt/decrypt the keychain is loaded from the repository from a class file called "keychain". The keychain is encrypted and therefore requires decrypting before being of any use. The keychain is only read when it has to be, which is once per session (or following an update to the user's preferences). Thus, the class managing the keychain is loaded at a session scope.

[0269] The keychain data file is of the following format:

40
file ::= <header><key chain> header ::= <version><crypto id> version ::= <byte> crypto id::= <long> key chain ::= <app count><app data>* app count ::= <byte> app data ::= <app name><auth type><credentials> app name ::= <string> auth type ::= <byte> credentials ::= <string><string>[<string>]

[0270] The portal uses the file header to detect an attack. That is if the cryptography identification does not match that specified in the cryptography class, access to the file is blocked.

[0271] Applications that have no defined credentials default to an anonymous user setting. The anonymous user has no key chain and therefore no access to any cooperating applications on a secured basis.

[0272] While the above has been described with reference to a session keychain, a global session keychain is stored in a similar fashion. The global session keychain is stored under the portal server's user directory in the repository.

[0273] A control mechanism is provided for controlling application session information for all applications. The mechanism provides startup and shutdown of the session manager for an application and startup and shutdown of an application user session. The control mechanism returns an IDENTITY block for an application user session.

[0274] The application session manager further supports efficient timeouts so that cooperating applications can terminate user sessions in the event of critical failure in the portal. In order to provide an efficient "ping" mechanism, the portal maintains a "global" session with each cooperating application. Therefore, watchdog timer events need only be sent to a single session per application. The keychain for the global session is stored in the portal server's user directory, in a typical keychain file, in the repository.

[0275] The application session manager provides a mechanism for enumerating the installed applications. In order to provide several of the above points, a means to enumerate installed applications is required. Therefore, in the root of the "Applications" branch of the repository, a single properties file contains a list of installed applications. This file is of the form:

[0276] Applications=DOCSFulcrum, CyberDOCS, BI/Suite

[0277] The list of applications can then be used to traverse the subdirectories of the Applications folder to ascertain specific application configuration data.

[0278] As previously mentioned the portal supports the concept of anonymous users. A checkbox on the login screen provides the user with one method for logging-in anonymously. Furthermore, there are portal configurations that do not use CAP at all. Hence, sessions are not authenticated at all and the users are treated similarly to an anonymous user.

[0279] Every user of the portal has a CAP ticket or token and a keychain, and for every cooperating application, each user will have a session ID. The CAP ticket or token is a data element that is passed to any part of the data processing system that needs to know the idenity of the user. The ticket or token indicates that the user supplied authentic credentials to the CAP server. Each cooperating application has a single global application session, which will consist of a keychain and a session ID. A manager class, ApplicationSessionManager, is created for brokering user requests for application session, securely querying the repository for key chains, and holding application session ID's for each user in each cooperating application. The ApplicationSessionManager class is defined below as:

41
public class ApplicationSessionManager extends PortalManager { //Functional methods: //Establish an application session for a user public void establishApplicationSession(HttpSession session, String app); //Update the session ID for a user public void updateApplicationSessionID(HttpSession session, String app,String newID); //Tear down an application session for user public void destroyApplicationSession(HttpSession session, String app); //Informational methods: //Return a formatted IDENTITY block for an application public String getApplicationSessionIdentity(HttpSession user, String app); //Return configuration information for an application public ApplicationConfiguration getApplicationConfiguration (String app); //Return a Vector of all current ApplicationConfigurations public Vector //getApplicationConfigurations( ) }

[0280] For each user, for each application, an identity is stored so that the (XML-based) IDENTITY block can be created for that user for that application. Therefore, in the application session manager a vector of users is stored. Each vector element stores a reference to a vector of applications, each element of which references an instance of an ApplicationSession class:

[0281] class ApplicationSession

42
{ //The states that the IDENTITY can reflect static public final short ANONYMOUS = 0; static public final short TICKET = 1; static public final short KEY = 2; //Data members public short m_state; public String m_keys; }

[0282] The zero'th element of the user vector is reserved for the portal user, that is, the owner of the global sessions in each cooperating application.

[0283] The KeyChain class encapsulates the encrypted data stored in the file keychain.properties. The KeyChain class manages decryption/encryption of this file via the private methods "readKeyChain( )" and "storeKeyChain( )" respectively. However, as mentioned, the ApplicationSessionManager is responsible for securely querying the repository for keychains and the retrieval and setting of credentials stored in the keychain. Only the ApplicationSessionManager can instantiate KeyChains and retrieve or set credentials contained therein.

43
public class ApplicationSessionManager extends PortalManager { //INFORMATIONAL METHODS: //Get a user's keychain public KeyChain getKeyChain( String userName, HttpSession session, RepositoryManager rm, Vector appConfigVector) //Get a keychain's credentials public String[] []getKeyChainCredentials( KeyChain kc, String userName, HttpSession session, Vector appConfigs) //Get a keychain's credentials for the specified application public String[] getKeyChainAppCredentials( KeyChain kc, String userName, HttpSession session, String appID) //Set a keychain's credentials public boolean setKeyChainCredentials( String[] credentials, KeyChain kc, String appID, HttpSession session, String userName) }

[0284] The application session manager further stores per-application configuration information.

[0285] For each cooperating application, the application session manager stores an instance of a public class ApplicationConfiguration. The information in these instances is read from the repository, applications section, from the file "application.properties" for each application as described in the following code.

44
public class ApplicationConfiguration { //Types of authentication supported public final short SIMPLE = 0; public final short QUALIFIED = 1; //Generic configuration information public String m_appID; public String m_appName; public short m_authType; public String m_qualTitle; public boolean m_supportsAnon; public boolean m_requiresSession; public String m_dacClassName; //NavBar-specific configuration information public String m_navBarURL; public String m_navBarDTDVersion; }

[0286] The application session manager is further described along with the navigation bar, and specifically with reference to FIG. 15.

[0287] The following sections describe the navigation bar in greater detail. As previously mentioned, the navigation bar is a particular implementation of an e-clip. Specifically, the navigation bar is a user interface device from which all portal resources may be accessed. A navigation bar e-clip gathers and merges hierarchical data for the navigation bar and renders it as a tree as described below.

[0288] When a user connects to the portal server, a hierarchical set of links is provided in the left pane of the user interface. Collectively these links are known as the navigation bar. The links in the navigation bar serve as direct links into applications, corporate information and user information. The constituent data of the navigation bar may come from multiple back-end applications. Thus, the navigation bar can unify this data into a single hierarchy. In order to unify data from multiple back-end applications, the navigation bar facility operates in the context of the portal server.

[0289] The user is presented with a single navigation bar whereby all portal resources are accessed. The navigation bar (navbar) e-clip finds applications and other potential sources of data for the navbar that are currently available in the portal.

[0290] Furthermore, the navbar e-clip gathers data from one or more data sources. For efficiency, concurrent requests for data to multiple data providers are made.

[0291] The navbar e-clip enriches data in order to more fully describe the rendition and behavior associated with the data in the context of the portal. This includes the assignment of icons and custom URLs to nodes in the tree of known types. The navbar e-clip organizes all the data it has gathered into a single hierarchy and presents the hierarchy as an HTML document. Multiple renditions may be required depending on browser requirements and user interface design.

[0292] The navbar e-clip can operate with large quantities of data. It does not assume that it will be able to retrieve all available data with a single request. Therefore, multiple requests for large quantities of data may be required. In qualitative terms, the tree presented by the navbar e-clip responds to a user's expansion and collapse requests quickly. If the user moves off a page containing the navigation bar and returns to the page a short time later, the navigation bar looks the same as it had previously looked.

[0293] To ensure responsiveness, the design of the navigation bar attempts to minimize the number of network transactions required for expanding and collapsing operations. Where possible, the operation is handled on the browser, eliminating a network transaction. This will be possible for some expansions on browsers supporting dynamic HTML (DHTML) rendition. The server does not know about an expansion or collapse that is performed using DHTML. Expansions and collapses performed using DHTML are not reflected in the state of the tree that is stored in the portal session for the user.

[0294] Alternately, a request may need to be made from the browser to the portal. The portal handles this request making as few additional requests to a back-end application as possible. This is achieved if more data is cached on the portal than is returned to the browser.

[0295] Referring to FIG. 15, the overall architecture of a navbar environment is illustrated generally by numeral 1500. A navbar e-clip 1502 operates in a multi-tiered environment. Data is obtained from interfaces provided by back-end applications 1504, which are, themselves, multi-tiered applications. A browser 1506 serves as a client and interacts with the navbar e-clip by requesting a content page 1508 from the portal 105.

[0296] The navbar e-clip 1502 is included in the content page 1508. When the content manager interprets the page 1508, the navbar e-clip is invoked to generate a navigation bar. The script that defines the navbar e-clip is of the form:

[0297] # Component chain for navbar e-clip

[0298] com.hcl.portal.navbar

[0299] com.hcl.portal.treeRendition

[0300] Referring to FIG. 16, a general architecture for a navbar c-clip is illustrated generally by numeral 1600. The navbar e-clip 1600 comprises a navbar component 1602 and a TreeRendition component 1604. Each of these components extends the PortalComponent class.

[0301] The navbar component 1602 is responsible for all logic involved in obtaining data and preparing the data for rendition. The TreeRendition component 1604 comprises presentation logic required to effectively render hierarchical data described in an XML document.

[0302] Referring to FIG. 17, the navbar component 1602 is illustrated in greater detail. In order to discover available sources of information for the navigation bar, the navbar component 1602 includes an access component 1702 for querying the portal repository 128. Requests for data are issued through data access components 1704. Response XML returned from a data access component is parsed into an XML tree using an XML parser 1706 and enriched using rules provided in a NavBarConfig file 1708.

[0303] The output of the navbar component 1602 is an XML document conforming to the TreeRendition DTD. The e-clip manager 120 passes the response of the navbar component 1602 to the request of the TreeRendition component 1604, which in turn responds with an HTML rendition of the tree.

[0304] The navbar component 1602 obtains from the portal repository 128
user page information, a list of the available applications, configuration information for each application and the URL that may be used to access each application. The application registers the information of interest to the navbar with the repository. Such information includes:

45
Key Description Sample ApplicationID Unique Application HCL.FULCRUM identifier. Equivalent to APPID in NavBar Response NavBarUrl A resource locator that http://dingo/cgi-bin/dfxml.dll will be passed to the component data access component with NavBar request. DAC The rally qualified com.hcl.portal.component.HttpDAComponent classname of the data access component to be used to obtain data from this application. DTDVERSION Indicates the version 1
of the NavBar Request and Response DTD that is supported by the application.

[0305] This information is registered with the portal as a set of global settings for an application, and is stored in the application.properties item in the repository. The Application Session Manager 110 provides access to this information.

[0306] The user may store in the keychain information that could be used to override some settings in the application table of contents file. For instance, a particular user may wish to always connect to DOCSFulcrum anonymously. In such a case, the user's keychain would contain a directive to log on to DOCSFulcrum anonymously. User-specific configuration information can also be contained in the keychain to replace globally defined configuration information. However, the user interface allows a user to set up a keychain for an application permits only reasonable modifications.

[0307] The data access components 1704 are Java classes residing on the portal server. A data access component 1704 extends PortalComponent, and is called using similar methods as are used when the e-clip manager invokes any PortalComponent.

[0308] A generic data access component 1704a is provided. Most applications intending to provide navbar data using HTTP and XML should use the generic data access component 1704a. However, this component may not be appropriate for all applications. For instance, it is possible to access navigation bar data stored in the portal repository without issuing an HTTP request back to the portal server. Applications that wish to provide a custom data access component to service navbar requests must specify the data access component class name DACCLASSNAME of the component when registering with the portal.

[0309] The data access component 1704 expects to be provided a request that conforms to the Navigation Bar Request document type definition (DTD) and the value of NAVBARURL registered for the particular application. A data access component returns a response conforming to the Navigation Bar Response DTD.

[0310] The navbar component 1602 generates appropriate navbar request datagrams, based on input received. On initialization, or when expanding a node containing a replaceable reference, a request is generated for each data source. To service a tree expansion within a particular application, a request is generated for a single data source.

[0311] For each data source with a pending navbar request, a thread is initialized. The request, a NavBarURL value, and the data access component class name are passed to the thread. Each thread attempts to locate, load and link the data access component, make the request and wait for the response. A synchronized method is called from the thread to add the response data into an XML tree or handle the error. The thread then removes itself from a vector of pending threads. All threads created by the navbar component 1602 are terminated before the navbar component returns control to the e-clip manager 120.

[0312] Referring to FIG. 18, an event trace diagram for gathering data is illustrated generally by numeral 1800. The navbar component creates all the components in parallel. Similarly, the navbar component issues a request to each of the components in parallel. Once the component has finished processing the request, it returns a response to the navbar component. This approach provides the navbar component with concurrent requests for data and synchronized XML tree updates, conditional loading of requests to data access components, and preservation of the navbar state information while data access components are executing

[0313] The desire to define rendition and behavior at the portal level motivates the navbar e-clip's data enrichment. Customarily, trees have an icon at each node to indicate the type of the item. Depending on the interface theme or user preferences, the desired images could vary in size, colour and iconography. Data providers are not required to provide multiple icons to the portal, nor do they know about icon files that exist on the portal server. To provide this functionality, the navbar component is able to enrich navbar data with the name of the icon that is used for the entry. The NavBarConfig file may contain information to map a known class identifier CLASSID to an icon file name. This centralizes knowledge of ico