WO2002001388A2

WO2002001388A2 - Portal server that provides a customizable user interface for access to computer networks

Info

Publication number: WO2002001388A2
Application number: PCT/US2001/019986
Authority: WO
Inventors: Daniel Flesner; Miles Chaston; Ed Anuff; John Dean Taylor; David Macleod; Peter Leiser; Oliver Muoto; Seth Ladygo; Brian Slesinsky; Terry Joyce; Paul Emery; Dean Moses
Original assignee: Epicentric, Inc.
Priority date: 2000-06-23
Filing date: 2001-06-22
Publication date: 2002-01-03
Also published as: AU2001270084A1

Abstract

A portal server presents an HTML page that comprises a plurality of modules. Each module represents a network resource that can be accessed by a user through the portal. The portal server includes an administration interface that enables an administrator to select from various layout styles for a page of the portal. In establishing a layout an administrator specifies the number of dividers and cells to generate on the layout. The administrator also defines the width of dividers and cells. The interface enables a variety of layout schemes to be employed. In addition, a variety of modifications can be done to the portal without requiring programming skills. An updateable subsystem class is configured to instantiate an update subsystem object. The update subsystem object is operable to select an updated implementation of module from a set of update servers. An appropriate update server is selected from a set of update servers based on host identification information of a site hosting the portal including the module.

Description

PORTAL SERVER THAT PROVIDES A CUSTOMIZABLE USER INTERFACE FOR ACCESS TO COMPUTER NETWORKS

BACKGROUND OF THE INVENTION Field of the Invention:

The present invention is generally directed to the mechanisms via which users access information provided over computer networks, such as the Internet, intranets and extranets. More particularly, the present invention relates to portal mechanisms, wherein users redisplay any web content, such as web pages, web sites or web applications within a portal, configure layout properties to define a page of the portal, and modify modules within the portal.

Description of the Prior Art: Browser applications have become ubiquitous tools for accessing the vast amounts of information that are available via computer networks, such as the Internet and the like. At its basic level of operation, the browser permits a user to connect to a given network site, and download informational content from that site, such as an HTML document and web based applications, for display at the user's computer. A limitation of the browser is that to view additional information, or a different type of information, the user must designate a new network address, e.g., a different HTML file, whose contents then replace the previously displayed information on the user's computer. To alleviate the viewing limitation of browsers, portals are being employed on a more common basis. In general, a portal is an entry point or gateway for access to Internet web sites, or the like. One of the prominent advantages of a portal is the fact that information stored at a plurality of different network addresses, including different sites, can be simultaneously viewed on the display, rather than limiting the user to information from one site at a time. Most companies and organizations provide different types of portals for a variety of purposes, including portals for the general public, intranet portals for their employees, and extranet portals for their customers, vendors, supplies and other parties with whom they transact business. However, the cost and effort of developing, deploying, administering and continually enhancing portals grows as the organizational needs served by a portal grows. While portals address the viewing limitation of browsers, they do not address the inability of the browser to penetrate firewalls in order to connect to the Internet at large. Proxy servers are being employed to give browsers access to network sites they would not otherwise have access due to, for example, firewalls. Proxy servers, however, are specifically developed to serve the needs of an organization, and thus, are costly to develop, deploy, administer and continually enhance.

Accordingly, there exist a need for a system for proxying/redisplaying a given remote web application without the use of a proxy server or special browser configuration. There also exists a need for a system for integrating a given remote web page or web based application within a portal server. There exists a need for a system for proxying remote web application in a variety of formats. There is a need for a method of proxying/redisplaying a given remote web application without the use of a proxy server or special browser configuration. There exist a need for a system of modifying modules within the portal on a computer network. There exist a need for the system to dynamically modify individual modules. There also exists a need for such modules to be made available to users without requiring the interruption of system operation and user interaction. There exist a need for a method of modifying modules within the portal on a computer network. There exist a need for a system that enables an administrator to create and establish a page layout for a page of the portal. There also exist a need for the system to define the content that will be associated with the layout.

SUMMARY OF THE INVENTION

Based on the above and foregoing, it can be appreciated that there presently exists a need in the art for a system and corresponding method which overcomes the above-described deficiencies. The present invention was motivated by a desire to overcome the drawbacks and shortcomings of the presently available technology, and thereby fulfill this need in the art.

According to embodiments of the present invention, methods, systems and computer program products for streamlining the processes involved in offering a feature-rich portal are provided. A portal server for the portal provides for proxying a given remote web application by another web application that does not require the use of a proxy server or special browser configurations. The web application that performs the proxy is an intermediate web application. The web page, web site or web-based application that is proxied is referred to as a remote web application. The Intermediate web application allows for any web page or web-based application to integrated within the portal server and dynamically displayed. The portal server provides services through a library of object-oriented classes, such as classes in the Java programming language developed by Sun Microsystems, that give access to various databases, web servers, scripting environments and mail services.

According to an embodiment of the present invention, a method of proxying a web-based resource according to an embodiment of the present invention includes parsing the entire contents of a web-based resource. The method further includes identifying a particular item of interest in the web- based resource. HTML code of the web-base resource is transformed to reform the link inside the portal. The item of interest may be stored to a buffer. According to an embodiment of the present invention, a system for proxying a web-based resource includes a content transformation class configured to instantiate a transformation object. The transformation object is operable to parse the entire content of a web page, identify an items of interest within the web page, and transform the item of interest to a portal URL. The content transformation class are executable by a processor upon installation on the computer network.

According to embodiments of the present invention, a method, a system and a computer program product for configuring a layout page are provided. According to an embodiment of the present invention, a method includes an administration interface that enables an administrator to create and establish a page layout, as well as to define the content that will be associated with the layout. The method further includes specifying a coordinate axis as the orientation for the layout page. Any number of dividers are then generated within the layout in a direction away from the coordinate axis. Dividers are used to form any number of cells, wherein the cells are generated within the dividers. Characteristics of cells, such as relative or absolute widths, are set as part of this step. The administrator can be shown a grid that visually reflects the layout of cells within the page. Network resource types are then assigned to each of the cells using modules. An infinite number of layout pages can be created to facilitate the maintenance of a portal.

According to an embodiment of the present invention, a system for configuring a layout page includes a network interface operable to exchange information with a network. The system further includes a memory operable to store process management services and libraries and a processor. The processor is coupled to the network interface and the memory. The processor is operable to determine a coordinate axis of orientation, generate a number of dividers within the layout in a direction away from the coordinate axis, generate at least one cell within at least some of the dividers, and assign a module to the at least one cell within the at least some dividers.

According to embodiments of the present invention, a method, a framework and a computer program product for modifying modules within a portal on a computer network are provided. Individual modules can be dynamically modified by the various entities which supply those module, and such modified versions can be made available to users without requiring the interruption of system operation and user interaction. In addition, an individual module may be viewed in a number of appearance styles. Moreover, the users may switch between appearance styles without interruption in the operation of the system.

According to an embodiment of the present invention, a framework for modifying modules within a portal on a computer network includes an intermediate class configured to instantiate an intermediate object. The intermediate object is operable to hold a reference to a current implementation of an instantiated object encapsulating information of a particular type on the computer network. The framework further includes an updateable subsystem class configured to instantiate an update subsystem object. The update subsystem object is operable to select an updated implementation of the instantiated object from a set of update servers. An appropriate update server in the set of update servers from which to select the updated implementation of the instantiated object is based on host identification information of a site hosting the portal. The classes are executable by a processor on the computer network upon installation.

According to an embodiment of the present invention, a method of modifying modules within a portal on a computer network includes providing an intermediate class configured to instantiate an intermediate object operable to hold a reference to a current implementation of an instantiated object. The instantiated object encapsulating information of a particular type on the computer network. The method further includes providing an updateable subsystem class configured to instantiate an update subsystem object operable to select an updated implementation of the instantiated object from a set of update servers. An appropriate update server in the set of update servers from which to select the updated implementation of the instantiated object is based on host identification information of a site hosting the portal. The classes are executable by a processor on the computer network.

Further features and advantages of the invention will become apparent to those skilled in the art with reference to the accompanying figures and written description below.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a general block diagram of an exemplary network system in which the present invention can be implemented;

Figure 2 is an illustration of an exemplary front page of a portal; Figure 3 is a diagram of the high-level architecture of the portal server;

Figure 4 is a block diagram of an object model for a module; Figure 5a is a detailed view of a layout based on an orientation along a horizontal axis; Figure 5b is a detailed view of a layout based on an orientation along a vertical axis;

Figure 5c depicts an exemplary screen for configuring the layout of a page;

Figure 6 is a block diagram of a user object model; Figure 7 is a block diagram of the permission object model;

Figure 8 is an overview of one implementation of the portal server; Figure 9 illustrates the initialization and front page files for one implementation; Figure 10 illustrates front-page and edit views of a module; Figure 11 illustrates the front page and edit views in greater detail; Figure 12 illustrates a customized front-page view; Figure 13 depicts the execution environment for one implementation of the portal server;

Figure 14 is a flow chart of the process for dynamically updating modules in the portal server;

Figure 15 is a flow chart of the process for changing the style of a module; Figure 16 is a block diagram of a stream state engine of the portal server;

Figure 17 is a block diagram of a proxy servlet authentication; and Figure 18 is a block diagram of an intermediate web application system.

DETAILED DESCRIPTION OF THE INVENTION

To facilitate an understanding of the present invention, it is described hereinafter with reference to specific implementations thereof.

For example, the software programs that underlie the invention can be coded in different languages, for use with different platforms. In the description that follows, examples of the invention are described in the context of web sites that employ Java Server Pages (JSP) or Active

Server Pages (ASP). It will be appreciated, however, that the principles that underlie the invention can be implemented with other types of computer software technologies as well. 1. Overview

A general depiction of a networked computer system in which the present invention can be implemented is illustrated in Figure 1. In essence, the computer system enables individual users of communication devices 10, including personal computers 10a, workstations 10b, web access devices 10c, and the like, to view informational content provided by various servers 12a-12n. The communication devices 10 are connected to the servers 12 by means of a suitable communications network 14, such as a local area network, a wide area network, the Internet, or the like. To view the content provided by the servers, the devices 10 run a browser application 16. At the servers 12, the available content and services are stored on suitable storage media, such as magnetic or optical disk drives, in a format that is capable of being read by the browser applications, such as HTML or XML. Typically, each segment of information that can be accessed at once, e.g. file, is referred to as a web page, and has an associated network address. Thus, by entering a particular address in a browser application, the user is presented with one page of information that is stored at a particular server. A collection of web pages that relate to a common topic and are interlinked with one another may form a web site.

At its basic level of operation, a browser is designed to display one web page at a time. In such a case, the user is required to navigate from one web page to another in order to view different types of information available on different sites. Quite often, however, the user desires to be able to view a variety of different types of information at once, and then select the particular type of information that is of most interest at that time. For instance, within a corporate context, a user may desire to have quick access to various resources and data provided by the employer, while at the same time being able to view information provided over the Internet, such as news headlines, financial data, and vendor data.

The present invention is particularly directed to a server application and framework that dynamically constructs and maintains portals for display to users. An example of a portal display that incorporates features of the present invention is illustrated in FIG. 2. The portal comprises an HTML web page 18, identified as a "front page". In essence, each page presents a predetermined layout of encapsulated modules containing the resources that are available to the user. A set of personalized buttons or links 24 and one or more modules 26 are displayed.

Each module 26 provides the user with access to a particular type of resource, such as news headlines or stock quotes. As will be apparent from the discussion that follows, these resources can be applications, databases, services, informational content, e-commerce offerings, and the like, that are available from one or more of the servers 12a- 12n. The employer (or other provider of the portal) may provide some of these resources, whereas others may come from independent third parties. By interacting with any one of these modules, the user can access the information or services provided by that module. The set of personalized buttons 24 permit the user to personalize the portal. For example, the personalization buttons enable the user to customize the portal including revise the layout of the portal, such as which modules appear in each of the groups, change the portal color scheme, update the modules within the portal, and edit that user's account, such as change a password.

Furthermore, the user is often at a local network and desires to access and utilize web applications located at a remote network location to the user. The present invention proxies the application located at the remote network location and displays the application located at the remote network location as pages within the user's local network. At no point does the web browser looking at the application located at the remote network location via the local network go to the remote network location for HTML pages; all HTML pages come from the local network. The local network may place its own HTML entities on the pages with remote application, such as local network's branding, navigation, or other local network content. The HTML that the remote application returns to the local network is incorporated into the local network's HTML page, which the local network then displays to the end user.

2. High-Level Architecture

The functionality associated with the portal is provided by a portal server, running on one or more of the servers 12a- 12n. Referring to Figure 3, the portal server can be viewed as a client/server model. The client interface is provided by HTML code generated by the portal server to run in a user's browser application. The server consists of process management services that are provided by a web server and suitable class libraries. These libraries connect to other servers and use other resources as needed, including a data store which provides object persistence via a suitable database interface. In one exemplary embodiment of the invention, this functionality might be provided by a JDBC interface over a SQL database. In another embodiment based upon an LDAP environment, user management can be provided via JNDI over LDAP. The server can connect to other network resources, for example to acquire information from the Internet or an intranet.

Prior to any customization by an administrator, the portal server can provide a set of web pages that constitute a default, self-contained portal web site. One implementation of the portal server includes a Java Server Pages (JSP) web site, for use under any web server that supports Java servlets and JSP. Another implementation comprises an Active Server Pages (ASP) web site, for use under Internet Information Server (IIS) provided by Microsoft Corporation. Both of the implementations under these different scripting environments can use the same Java libraries and services; the primary difference between them is the web site upon which they are based (JSP or ASP), and how the web site interfaces with the Java libraries.

3. Object Model

An object-oriented software system consists of software objects. A software object represents an actor within an overall system design. Such actors may correspond to real-world concepts, or may exist purely to support the overall design. Software objects encapsulate the data and logical processes of the actor. This encapsulation makes objects easy to use, because the user of an object need not know how the object performs its processes. Software objects are also extensible: other objects can be built on top of existing objects, allowing the new object to expand the concept of the old object without having to rewrite the functionality. These properties of software objects make object-oriented systems flexible and extensible.

An object model comprises a collection of objects that work together in documented relationships. The portal server is an object-oriented system built on such an object model, illustrated in Figures 4, 6 and 7. The objects that make up the portal server architecture include Components, Managers and Services, Modules, Views, Pages and Page Ordering, Layouts, Users, Permissions, Content Parsers, Data Storage and Tasks. 3.1 Components

Components are a set of loosely related classes used to create wrappers to provide simplified access to other objects within the architecture of the portal server. In a preferred embodiment of the invention, one component 28, designated as the "Portal Services Component," is employed as a single point of access for methods that are external to the portal server. The function served by the Portal Services Component is access to other objects within the architecture. Since the Portal Services Component provides a single point of access, it allows a very simple distributed object registry profile for use in object brokers. Only the Portal Services Component need be registered. Other objects can be accessed by calls to the Portal Services Component. An example of an object broker is the Microsoft Common Object Model (COM). When running under an ASP web site, for example, the Portal Services Component can be published as a Microsoft COM/ActiveX control. An instance of this class is created once at web server startup in an ASP environment. In contrast to the ASP environment, under a JSP web site, any JSP page has access to any Java object made visible in the classpath. However, the Portal Services Component can still be used as a single point of retrieval for important objects within the architecture. This architecture provides simplicity as well as compatibility with the ASP version of the portal server. 3.2 Managers and Services

Managers and Services perform similar functions, but in slightly different and complementary ways. A Manager encapsulates details for handling the creation and manipulation of a set of objects. A Service can encapsulate any identifiable Application Programming Interface (API) within the portal server. Managers can be implemented as Services within the portal server; however, Services are not restricted to being Manager implementations. Both Managers and Services allow for run-time replacement of their implementation with specific versions adapted to user-specific needs.

Two examples of Managers are a module manager and a user manager. Modules follow a "singleton" design pattern, meaning that there is one instance of a module for the lifetime of a server session. The class of module managers, therefore, maintains those module instances, and handles their persistence. The user manager class is an abstract class whose purpose is to manage the persistence of User objects. Classes that extend this class could, for instance, store users in a SQL database or an LDAP server or Java serialization.

To be useful to a broad range of portal providers, a portal framework must easily allow different implementations of key services. Services such as user management, flexible schema storage, and search engines are likely to be different for different portals. To facilitate a high degree of customization, the portal server includes technology for allowing configuration-data driven resolution of service implementations within the portal server. This technology provides a means of allowing runtime resolution of the specific class used to implement the service, as well as configuration of all its properties. Essentially, a Service allows a few lines of configuration data within the computer system's startup configuration files or registry to specify details of the run-time implementation, including the actual class to be run to provide the service. This allows the portal provider to use existing implementations or define their own, and substitute their chosen implementation into the system without rewriting source code that uses the implementation.

The portal server Service includes the following elements:

1. a format for specifying configuration directives - identifying the service implementation, by type and by name;

2. a format for specifying and locating configuration directives used by the service implementation;

3. A Service Manager class, which acts as the factory for loading and retrieving individual Service Managers; 4. A Service Manager API, which an implementation must satisfy to act as service manager to a particular service type; and

5. a "Service" API, which an implementation must satisfy to act as a Service. Given these elements, a process can utilize a Service by calling the

Service Manager class, and asking for a particular service manager by its type. Once the service manager is retrieved, it can be used to retrieve a particular service, by giving the name of the service. Once the service is retrieved, it can be used for its intended purpose. 3.3 Modules

Modules are objects that encapsulate a specific, bounded portion of content at a network address, and allow that portion to be administered as a unit. For example, a module might display news, sports scores, stock quotes, or weather forecasts. Site and end-user content preferences are expressed by the set of modules displayed on a portal page. Figure 4 illustrates the module object model. A module 29 follows the "singleton" design pattern, the same as Java servlets, which means that the portal server keeps only one instance of the module, which persists for the lifetime of a web server session.

3.3.1 Module Types and Descriptors

Each new class that implements the module interface defines a new module type. Each module type has a module descriptor object 30, that defines metadata for the module, such as its name, administrative properties, and default settings. A module descriptor gets its initial data from an XML document. The metadata for a module can be customized simply by editing the XML document. Since XML documents are quite easy to change, the module descriptor provides another point for the customization of the portal server. Each module descriptor represents a module type that can be added to a portal using an administration GUI (described hereinafter). A module that has been added to a portal is an instance of its module type. 3.3.2 Views

Views are the means by which the portal server isolates the presentation logic so that it can be more easily customized. The Module View 32 is the display logic for a particular view, or mode, of a particular module. Examples of views are the front page of a portal, where the module is displayed within a box or other graphical region (as shown in Figure 2); the page where a user customizes a module (for example, selects news categories or stocks of interest); and the page where the portal administrator customizes the global properties of a module. A new view object is created for each HTTP request.

The Module View interface defines constants identifying these and other common views. Modules can also create custom views to handle module-specific processes. Implicit to most methods in this interface is that the Module View contains an HTTP request, an HTTP response, and other page-specific data, all of which is encapsulated within a Portal Page Context object 34. However, this interface specifies no method for setting that information. This architecture provides flexibility for the creating module to independently manage and create its views. Any object can perform some process at the start of a Module View by implementing a Page Start Handler object 36, and passing itself to the view via its constructor.

Each module view's purpose is to create an HTML page, or part of an HTML page, displaying some aspect of the module's data. Module views can generate their HTML through any means desired. To this end, therefore, certain types of modules can be defined for the portal administrator to use as building blocks in the construction of a portal site. For example, a "clip" module can capture specific HTML elements from an HTML page, so that only those elements are retrieved as the content of a module. In contrast, an "include" module can be defined that is capable of capturing the entirety of an HTML page for inclusion in a module. In these types of modules, the HTML data can be embedded in the Module View class. Other types of exemplary building block modules comprise an XML inclusion module, which retrieves an XML style sheet and generates the HTML for display as the content of a module; a transaction module which can employ a script to obtain filtered data from a network location for display in a module; a JSP module, which can execute a JSP page and display the contents of that page as the contents of the module; and a module that creates a framework for multiple JSP pages providing common module views.

Using JSP with modules has a number of advantages:

1- Modules that use JSP are easier to maintain than modules that embed their HTML in a Java class. If a module's JSP file is changed, all users of that module see the changes immediately, with no recompiling of Java class files required.

2- Once a module is built using JSP, HTML knowledge is all that is required to change the module's look-and-feel.

3- Because the HTML generation is controlled by JSP, the Module View objects can be very thin.

A module subclass can be defined that enables creation of new module types using only JSP. Modules that do not need their own new methods can use this subclass and JSP files for all of their functionality. Each module view corresponds to a JSP file that contains the HTML and logic for that view. The portal server allows a Module View, which is a class object, to execute a JSP page and add its results to the overall HTML page being constructed. 3.3.4 Portal Page Context and Portal Page Info

A Portal Page Context object 34 extends the Page Context class 46, which can be a class within the javax.servlet.jsp package provided by Sun Microsystems. The Portal Page Context object contains everything a Module View needs to know about its execution environment. A Portal Page Info object 48 tells the modules about the display characteristics of an HTML page that is being constructed. By using the Portal Page Info object passed to them via their page context, all modules on a page can coordinate their fonts, colors, and other display characteristics.

3.3.5 Intermediate Web Application

The Intermediate Web Application allows for any web site, web page or web-based application to be integrated within the portal server. The Intermediate Web Application operates in a similar manner to the "clip" or "include" modules described above in section 3.3.2. Whereas the "clip" and "include" modules clip static content, the Proxy Module captures dynamic content for redisplay in the portal.

The Proxy Module includes the following features :

1. a Pass-Through of User's HTTP Request, where the intermediate web application passes the user's entire HTTP request through to the remote web application.

2. a Pass-Through User Authentication, where the credentials of the user, as sent by the user's web browser, are passed through from the Portal Server to the remote web application. 3. a Maintaining per-user cookie state, where intermediate web application remembers the cookies sent by the remote web application to each end user, and returns them to the remote web application as appropriate. 4. a Multi-Page Containment, where the intermediate web application displays proxies all pages of the remote web application, not just a single page. In other words, links in the page of the remote web application do not send the end user to the original URL of the remote web application; instead, links send the user back to the intermediate web application.

5. a Containment Restrictions By Domain, wherein there is the ability to limit by domain which linked pages are displayed within the portal. The administrator of the intermediate web application can control which links in the remote application direct users to the intermediate application, and which direct users off of the intermediate application (i.e. to where the user is accessing the URL directly, not proxied via the intermediate application).

6. a HTML Page Rewriting, where each HTML page of the remote web application that is proxied via the intermediate web application must be rewritten, or adjusted, to ensure that the page displays and behaves correctly when contained within a page of the intermediate web application.

7. Frame Sets. Each HTML page, which contains frames sets of the remote web application that is proxied via the intermediate web application must be rewritten, or adjusted to ensure that the page displays and behaves correctly when contained within a page of the intermediate web application. This is accomplished by creating a generic frame set that nests the frame set of the remote application. 8. Java Script Interpreting. Each page of the remote application that is proxied, which contains Java Scripting is interpreted, rewritten and adjusted to ensure that the page displays and behaves correctly when contained within a page of the intermediate web application.

The Intermediate web application acts as a local representative of a remote web application or web site. The administrator selects any given URL within that application to be proxied, such as http://www.foo.com/index.html. The administrator can also define the depth or zone of the proxy (this is the abovementioned "containment restrictions by domain"). For instance, the administrator might select http://www.foo.com as the zone. The intermediate web application initially displays http://www.foo.com/index.html. When the user clicks on a link from that page, if the link is a URL within http://www.foo.com , it will be displayed "contained" in the portal. If the link is not a URL within http://www.foo.com, such as http://customer.foo.com, is displayed as a normal page in the user's browser. When no zone is specified, the module proxies in a contained fashion the entirety of the Internet.

Exposing the content of a remote web application or web site works by parsing the entire content of the selected remote page and transforming the URLs of the linked pages to be URLs directed at the Portal Server machine. The actual URL of the linked page is contained in the Portal Server machine's URL's query string. Parsing is controlled by a Content Transformation class, which reads every character of a web page or application. The method looks at a stream of data from the page and examines each character in what is commonly referred to in the art as a stream state engine. This particular engine looks at each character in the data stream and when it finds a particular item of interest it stores this information to a buffer or performs a selected operation, which transforms that piece of data and then stores that information to the buffer. The module state engine detects for every known way of formatting URL's in HTML. The items of interest include URLs, Meta content, Forms, Frame sets, in-line images, body, and tables.

When the state engine detects a URL a link method is called, which first checks to see if the link is malformed and if so, the link is simply passed onto the buffer (i.e. if the link is malformed then that link is not in the proxy). If the link is well formed and it is within the previously specified "zone" the link is then transformed by adding the portal URL and selected parameters of the module and the view of the module. Referring to the previous example of selecting the http://www.foo.com/index.html URL as the starting point, when reading the page the engine comes across a URL to another page, such as:

Which is the HTML code for the link http://www.foo.com index/docs/books/tutorial. The link method than transforms the HTML code to so that link is reformed inside of the portal.

If the state engine detects Meta Content in the page, which has a link structure a Meta Content method is called. The Meta Content method transforms the relative URL to an absolute URX and then calls the previously described Link Method to proxy the link into the Portal. The state engine as mentioned previously looks for Forms (e.g. search boxes, etc.). When a Form is detected the Form URL is stored and the URL is checked to see if it is within the "zone". The Form URL is then replaced with the Portal URL and another method is called to reconstruct the link to append to the portal URL any hidden fields, the stored Form URL and selected parameters representing the view of the module, as well as the module itself.

The state engine works similarly for frame sets, in-line images etc. It searches for the web page or application for the items of interest relating to these HTML tags until a link is detected. The module then calls another method to reconstruct those relative links to absolute links by adding the source URL.

The intermediate web application can also proxy web sites or applications that support Java Script. Unlike, the HTML implementation described above, a different stream state engine is used. When is has been determined that the page or web application supports the use of Java Script. This stream state engine can look for how the token ends and not how the token starts. The stream state engine can detect for all types of special characters that are encountered in Java Script pages (e.g. ";", "&", "{", "}", etc.), and flushes these terms out of the buffer. If a "<" tag is detected then an all_done_event is thrown indicating the end of the Java Script. The stream state engine upon not finding an "<" the engine begins looking for items of interest, including: if, while, for, and switch statements. After the above statements have been found then flush out the buffer and read until an "(, )" statement is encountered. Which signifies that there may be possible links or images to be read in the following statement. The engine then calls a method, which looks for all possible URL or images in these statements and stores these into a string. The stream state engine can also handled statements that have string concatenation or extensions. After determining that there are possible links or images in the statements the engine then checks for concatenation or extension operators. After checking which operator has been used these strings are then read into the string buffer until and end of statement tag is detected.

As stated above, the stream state engine can interpret different types of Java Script statements and parsing their contents for items of interest such as, links and images. The links are proxied and the images are converted to absolute. This is accomplished by invoking two types of interpreters, a parameter interpreter or a method interpreter depending on the type of statement encountered in the Java Script. Method interpreters adjust or rewrite Java Scirpt statements such as, document. write and window.open. The method interpreter can searche for document.write and window.open statements. It then parses the contents of those statements and begins searching for src, href and background tags. The method interpreter then reads any links that are appended to thereto and calls another method to convert those URLs from relative links to absolute links in a very similar fashion as done with the HTML pages stated previously. Similarly, the parameter interpreter searches for other statement such as, location, location.href, and src. In the form of <token>.<method> = <value> (e.g. self.location = site). The parameter interpreter can return the intermediate applications own methods plus the bean-id of the intermediate application to proxy the links and absolute the images.

The stream state engine also can look for Eval statements in the Java Script. When an eval statement is detected and is followed by a quote symbol and an equal sign without any other special symbols (e.g. another equal sign, plus sign, percent sign, etc.) the contents the follow the equal sign can be sent to the parameter interpreter and handled as described in the above paragraph.

The stream state engine can also detect for Frame Sets. Frame Sets allows the existence of multiple HTML documents or other resources on one page. Frame sets are a group of frames in an HTML document each of which display a different resource (an HTML file, for instance). Frame sets are used within the <BODY> tag and replace any content, which would otherwise exist inside the body of a document. There are two parts to a frame set. The general tag for specifying a frame set and the properties of all frames in the frame set is the <FRAMESET> tag, and the tag, which is used to indicate the frames is the <FRAME> tag. In order to proxy any application or web site that supports Frame

Sets, a Frame Set for the intermediate application can be created after the stream state engine detects the use of Frames. Essentially, the intermediate application can constructs a nested Frame Set using the generic frame set constructed by the intermediate web application. The Frame Set can consists of two frames, a top frame for the Portal and a lower frame for the proxied site or application. The intermediate application can proxy the URL of the web site or application to a raw page and redirects the page to the constructed Frame Set, and specifically to the lower frame of the constructed frame set The intermediate application can determines whether the user has left/entered either the top or lower frame of the intermediate web application (e.g. are they in the portal or the proxied web application). Otherwise, the stream state engine works in the same fashion as that as described in the above application of proxing HTML pages or applications. The Intermediate web application can also handle file upload requests. The module detects for multipart/form data within a page. When this type of data is detected, a constructor is called, which constructs a new Multi-Part request to handle the specified request, saving any uploaded files to a metastore folder. The constructor actually takes the information in the form of an input stream and parses the multipart/form-data and saves the parameters and files. The parsing works by reading in the boundary, content disposition and type. After reading the last boundary line, the actual content is then read and stored. This allows for the module to easily reference, reconstruct and proxy the multi-part form data from the metastore folder. When there is a request the information is then extracted from the metastore, the multi-part form data is then rebuilt and then proxied for view within the Portal Server. The intermediate web application supports three different types of user authentication, basic, cookie on the client and servlet based. In the prior art basic authentication the user would access a secure website or application through their browser and enter in their user ID and Password to gain access and they would receive a cookie from the site and it would be stored in the users browser. When the secure site is accessed through the intermediate web application and the user has set the UserlD and Password in the User Edit View. The module adds these to the authorization header field of the request and a cookie is returned through the portal server. Authorization by servlet in the prior art is that the user has a special URL to access a secure website, which points to a servlet and the user enters their ID and Password. The Intermediate web application admin view allows the administrator to set trie URL location of the servlet, the field names of where the userlD and password should be entered plus an argument field name. The argument field is used by some websites for additional authentication parameters, such as a favorite color or age of the user. The Intermediate web application then sends this information to the servlet allowing the user to automatically enter the secure site. The site then returns a cookie to the b>rowser and the intermediate web application stores the cookie to the metastore, so when the user returns to the site they are still authenticated. The intermediate web application also allows for entering secure web sites that have been proxied, which have form fields for user authentication (userid and Password). After the page is proxied the user enters the userid and password in the appropriate location and after authentication the browser receives a cookie sent by the website and the cookie is then stored in the metastore, so when the user returns to the site they are still authenticated.

3.4 Page Layout

Multiple modules are presented to the user, for example, within an

HTML pages. The present invention enables the addition of modules to a page to take place in a flexible manner, which provides control to both a portal administrator and the end user. Several alternative methods for achieving such a result can be used.

3.4.1 Layouts and Groups

A Layout 38 contains the Groups 40 on a specific HTML page of the portal, and Groups contain a set of modules specific to one user of the portal. Hence, in the example of Figure 2, the Layout for the illustrated page contains two groups, e.g. left column and right column, and the two groups contain three and two modules, respectively. A module constructs a Module View that is specific to the user and context, and the view assembles the HTML presentation. The JSP or ASP code enumerates through groups and then enumerates through the modules within each group.

A Group Template 42 is a pattern used by a Group object to create itself. Unlike a regular Group object, the Group Template is not user-specific. A Layout Template 44 holds a collection of Group Template objects. A regular Layout is created by patterning itsel from a Layout

Template. 3.4.2 Pages, Page Layout and Page Ordering

An alternative to Layouts and Groups can use Pages, Page Ordering, and Page Layouts. This alternative can provide better built-in support for multiple-page designs, such as those typical of a "tabbed" user interface. In a tabbed user interface, the end user mouse-clicks on one of a series of tabs to move between pages. Each page has its own content and layout.

The site administrator can create pages, and can publish them for availability by end users. The general steps for an administrator to create a page and make it available to users are as follows:

1. Create the page by identifying its descriptive information: e.g. title and description;

2. Establish the page layout, as a set of columns and or rows in which modules are to be grouped. Columns and rows form cells. Characteristics of cells, such as relative or absolute widths, are set as part of this step. The administrator can be shown a grid that visually reflects the layout of cells within the page. Figures 5a and 5b illustrate two examples of such a grid. The layout of Figure 5a is row-centric, i.e. it comprises two horizontal rows of module cells, whereas the layout of Figure 5b is column-centric;

3. Specify modules for cells within the page. The administrator can leave the set of modules completely up to the end user, or can add modules to cells within the page. The administrator can decide whether a given module is optional to the end user, or is required. The administrator can also lock entire cells, effectively dictating a predefined set of module content;

4. Assign styles to elements of the page;

5. Assign appearance settings, such as fonts and color; 6. Publish the page, making it available to one or more user groups, and establishing the order of this page relative to others.

The following describes establishment of a page layout. A page layout defines the physical structure or look-and-feel of a front page. FIG. 5c depicts an exemplary screen for configuring the layout of a page. The layout screen may include orientation property provision 80, divider width property provision 82, number of dividers property provision 84, layout preview image 86, and cell property provision 88. The layout screen is the means by which an administrator can define the look-and- feel of a front page.

The orientation property provision 80 is the mechanism useful for setting the orientation of a layout. A layout may have any orientation along a coordinate axis, such as a vertical axis or a horizontal axis. Dividers may be positioned within a layout along a line away from the coordinate axis. Dividers are the objects to which modules are assigned and grouped for display on a page. Orientation properties may be set by an individual, such as an administrator, but can easily be extended to end- users.

Divider width property provision 82 sets the unit of measure on which the width of dividers will be based. Such units of measure include, but are not limited to, pixels and percentage. The pixel setting sizes the width of dividers based on pixels. The percentage setting sizes the width of dividers based on percentage of the layout. Each divider will be given a width based on many parameters, for example, the dimensions of the layout, the unit of measure chosen and the orientation of t ie divider.

A user can select the number of dividers property provision 84 to set the number of dividers that will be positioned in the specified orientation. Any number of dividers may be selected. As one having ordinary skill in the art would recognize, the descriptive text associated with the provision may be dynamic and change to reflect the specified layout orientation. For example, the text will read "Number of rows" when the horizontal orientation provision is specified, but will read "Number of columns" when the vertical orientation provision is specified. Layout preview image 86 is a small scale representation of a layout as configured using the aforementioned provisions. Divider image 88 provides a detailed view of the dividers selected using the number of dividers property provision 84. Divider image 88 provides a mechanism for selecting cell properties for each divider.

FIG. 5a is an illustration of a layout based on an orientation along a horizontal axis. In a horizontal orientation axis, each cell can include row numbers, such as 90a, column numbers, such as 92a, cell numbers, such as 94a, and cell property provision, such as 96a. A row number 90a corresponds to the number assigned to a divider with respects to other dividers. For example, the row number 90a indicates that the divider is first with respects to other divider. A cell number 94a corresponds to the number assigned to a cell with respects to total number of other cells in the layout. A column number 92a corresponds to a num >er assigned to a cell in a divider with respects to other cells in a divider. For example, if each row had two columns then the cells in the column would be numbered one and two respectively.

The number of cells in any particular divider can be easily changed by designating the number of cells using cell property provision 96a. In the exemplary embodiment shown in FIG. 5a, each cell is positioned within a divider along the horizontal orientation axis. For example, a divider oriented horizontally is subdivided by cells horizontally positioned along the orientation axis. In a preferred embodiment, each cell that subdivides a horizontally oriented divider has a height equal to the height of the divider. Provisions 96a are provided in each divider for specifying the property for the number of cells to be included within a divider and cell width. Each cell can be associated with modules that will be presented on the page. Accordingly, a user can specify an infinite number of module layout schemes in either the horizontal or vertical axis.

In the horizontal orientation, the width for each cell can be expressed in the unit of measure specified for the divider. In the preferred embodiment, the portal server initially automatically assigns the appropriate width for each cell in the divider. The width for each cell can be automatically assigned based on the unit of measure selected and the number of cells selected. For example, if two cells are selected for each row divider the width in percentage for each cell is automatically 50%, for a total width of 100% along the horizontal axis. The portal administrator, using the cell provision 96a, can change the width for each cell. Assigning a width for one cell will result in trie portal server automatically determining the appropriate width for remaining cells in the divider containing the cell. In the preferred embodiment, there is no provision for a user to specify the height of each cell, while other embodiments can include such flexibility. In the prefeπred embodiment, the height is automatically determined by the content defined by the module or modules to be contained within that cell.

FIG. 5b is a detailed view of a layout based oxi an orientation along a vertical axis. In a vertical orientation, each cell includes . row numbers, such as 90b, column numbers, such as 92b, cell numbers, such as 94b, and a number of rows property provision, such as 96b. A column number 92b corresponds to the number assigned to a divider with respects to other dividers. For example, the column number 92b indicates that the divider is first with respects to other divider. A cell number 94b corresponds to the number assigned to a cell with respects to total number of other cells in the layout. A row number 90b corresponds to a number assigned to a cell with respects to other cells in a divider. For example, if each column had two rows then the row number 90b in each cell in the column would be numbered one and two respectively.

Like the horizontal orientation, the number of cells in any particular divider can be easily changed by designating the cell property provision 96a. In the exemplary embodiment shown in FIG. 5b, each cell is positioned within a divider along the vertical orientation axis. For example, a divider oriented vertically is subdivided by cells vertically positioned along the orientation axis. In a preferred embodiment, each cell that subdivides a vertically oriented divider has a width equal to the width of the divider. For Example, a vertical orientation a,xis based layout having two dividers and the unit of measure set to percentage will assign widths for each cell to 50%, since each divider has a widtli of 50%. Also, if the width for the first divider is set by the administra-tor to 25%, any cells will have a width of 25% and the Portal Server will automatically set the other column width, and thus any of its cells to be 75%. The page layout can be generated by, for example, building a table in a Java data structure located within a specially created Java class. In this example, Java data structure can set a default value for the number of cells and dividers. The widths for both the cells and dividers can also be initialized to a predetermined value. This class retrieves the number of dividers specified on the administrator layout page, as described in the above examples. The Java class then creates the dividers and by default sets each divider to have one cell. The divider widths are then adjusted proportionally to accommodate new or deleted dividers. If the number of dividers is decreased then all the cells in those dividers are removed. This applies only for vertically orientation. Note that in horizontal orientation the width is only a function of the number of cells in each divider. The cells for each specific divider are then updated. In absolute pixel mode, adding or removing cells has no effect on the remaining cell widths. However, in a relative width mode the cell widths are recalculated so width for all cells in a given row total 10O.

The administrator can assign modules to cells within the page or enable an end-user to assign desired modules to a specific cell. The administrator can decide whether a given module is optional to the end user, or is required. The administrator can also lock an individual module, a set of modules within the layout, or the entire module set of a layout, effectively dictating a predefined set of module content.

In the preferred embodiment, the administrator maintains a list of required and default modules for a user or group of users for a page in a Page Module Set class. This Page Module Set class also allows the administrator to assign a "locking state" to an individual cell in a layout, a set of cells within the layout, or the entire layout. This prevents the end user from either deleting a module from the page or adding more modules to that particular page, such as if the entire cell set of a layout. The Page Module Set class can also reset the location of the modules, such as when there is a change in the page layout structure. When there is such a change in the layout structure this class can also change the location of the modules within the new layout scheme. Each module width is compared against the newly created cell width and if no cells are wide enough to accommodate the module, the Page Module S t class removes the module from the layout. In the preferred embodiment, the module contents of a user's page and the lock state associated with the user's page are represented by a User Module Set class. The User Module Set class uses the locking state of the Page Module Set class as a template that define limits of the locking state. The User Module Set class can maintain a timestamp of the last layout and Page Module Set class that was last valid for a given user. The timestamps are useful for determining if modification to the User Module Set class is necessary.

In the preferred embodiment, the User Module Set brings its page module list into synchronization with updates to either the Page Module Set class or Page Layout class. A page module list is a list of modules enabled for use in the page. In synchronizing a page module list with changes made to a Page Layout class, divider and cell counts can be adjusted. Modules in deleted cells can also be placed in a most recently added cell of a divider, if it still exists, or the last cell of the oldest divider.

In synchronizing a page module list with changes made to a User Module Set class, locking states can be checked prior to changes to the User Module Set class. In the preferred embodiment, when a page is locked, any modules that the user has added are deleted, and the user added modules are cleared from the User Module Set. Also, when an individual cell is locked, any modules that the user has added to that cell are deleted from that cell, a new non-locked cell location is determined for the user added module as well as added to the User N Iodule Set class, and an administrative assigned module provided in the locked cell.

Once a page has been published, it can become available to end users. They can control which modules are on the page, within the restrictions established by the administrator. For example, users might be able to choose modules and rearrange them within the cells of one page, but the portal administrator might lock the content and arrangement of another page.

Page ordering is controlled by a Page Ordering object within the object model. This object holds the collection of published pages, and supports re-ordering of the pages. This is a portion of the API that can be used, for instance, to affect the relative tab positions of published pages. In an implementation of the administration user interface, it can use the API to allow the portal administrator to re-order pages visually.

3.4.3 Manager Classes

The Layout Manager class 50, the Group Manager class 52, and the Module Manager class 54 manage object persistence. For each defined layout, the Layout Manager maintains information regarding the groups contained in that layout. The Group Manager, in turn, maintains information describing the modules that comprise each group. The module Manager determines the particular characteristics of each module in a group, e.g. which news sources the user has selected for display in a "News" module.

3.4.4 Templates and Styles

Templates and Styles collectively provide a Templates API. In one implementation, there are three main classes in the Templates API: the Style class, the Template Manager class and the Template class. The Style class corresponds to a single style. The Style class contains methods to display itself (the execute methods) and to make itself persistent. The Template Manager class is used to create, retrieve and store Template objects. The Template class conesponds to a single style type. The main function of this class is to associate default Styles with particular templates and to create Style objects. Default Style associations for every template can be made on a system-wide, per-user- group, per-page, or per-user-group-per-page basis.

3.5 Users

A User object 56 represents an end user of the portal. Figure 6 illustrates the User object model. Referring thereto, a User Group 58 is a site-defined group of users, to support permissions, described below. Registered portal users can be assigned to one or more user groups. Examples of user groups are Engineering and Sales, or Beginning and Advanced. The user data and group assignments can be stored in an LDAP directory or a database. User groups enable different portals to be targeted to different users, as well as to distribute different administrative functions to selected users. User Query 60 is an interface for searching and retrieving users. An instance of the User Query class is created via the User Manager 62, which is the abstract implementation of a class to manage User persistence. Classes that extend the User Manager class could, for instance, store user data via a SQL database, an LDAP server, or Java serialization.

A User Set 64 contains a set of User objects, and could be implemented in a relational database, for example. Xhe User Group Manager 66 is an interface to the underlying representation of user groups. The portal server manages user retrieval and authentication through a general API composed of the User Manager, User, and User Set classes. A portal server configuration property specifies the actual classes that are used at runtime. This design makes it possible to plug in any desired user manager implementation. The portal server can employ various user manager implementations. Examples include one that is SQL-based and another that is directory server-based (JNDI over LDAP). A variation of the SQL user manager performs its user authentication against NT domain user accounts.

3.6 Permissions

Properties are associated with modules to determine which modules users can access, which ones they can customize, which ones they cannot remove from their front pages, and which ones they can minimize on their front pages. For instance, in the example of Figure 2, the "Company Directory" module does not include an edit button 27, so that the user is not able to edit its content. In one implementation of the invention, a permissions architecture can be employed to control what a user group can do to a particular object. In this implementation, permissions can be associated with the Modules and Users classes. User group permissions determine whether one group can perform any administrative tasks over another group (for example, view the group membership, add members to the group, delete members from it, etc.). Module permissions determine what a user group can do to a particular module. A standard set of permissions can apply to every module. Some of these can be end-user permissions (for example, whether a module is available to the members of the user group, whether the user group members can customize the module, etc.), while others are administrative permissions (for example, whether user group members can add new instances of a module or edit a module's end-user permissions). In addition, a module can have custom permissions that control access to functionality that is particular to that module. For example, a discussion board module might have custom permissions controlling whether a group is allowed to post messages to the board and create new discussion categories.

The various types of permissions can be set via an administration tool, which is preferably web-based. In addition, delegated administration modules, such as User Manager 62 and Module Manager 54, can enable user groups to perform specific administrative tasks without having access to the full range of administrative privileges available through the administration tool. Figure 7 illustrates the permission object model. The core of the permissions API comprises four interfaces. A Permission object 72 is a string ID (such as "enabled"), a list of groups that are allowed the permission, and an "everyone" Boolean that determines whether the permission is on or off for everyone. This Boolean supercedes the group list. A Permission Context object 74 is a set of permissions. Each object that has permissions defined on it, like a module, has one Permission Context object containing all of the permissions for that object. Permission Catalog 76 is a static, class-wide list describing the permissions allowed in a Permission Context object. A catalog is used to initialize and update the permissions in an object's Per ission Context. A Permission Catalog Item 78 is the definition of a permission within the Permission Catalog. Each item describes a permission's ID (e.g., CAN_EDIT), friendly name (e.g., "Can edit module"), and a default seed value for the "everyone" Boolean. Each module has one Permission Context object 74 containing all the permissions defined for the module. There is one Permission Catalog that defines the standard module permissions. Each module defines a custom Permission Catalog. The catalog can be empty by default, but permissions can be added to the catalog by defining them within the module's descriptor file. All permissions referenced in the catalog are created when the module is instantiated.

3.7 Content Parsers

One of the significant advantages of the portal framework of the present invention is the fact that the resources that are made available to the user via the modules can come from a variety of third-party sources. Consequently, however, the content for the modules may be largely unstructured, which can be problematic when it is to be made available for manipulation and display within the portal. To this end, therefore, a parsing technology is employed for retrieving data from external web sites and various other sources, translating the data into XML, and returning structured results as objects for use by other entities, such as modules. A Content Parsing object is used for executing a transaction script and obtaining the results produced by it. The Content Parsing Manager class, which manages Content Parsing objects, can be instantiated by a web server or called directly using code.

Once the Content Parsing Manager is created and the script package loaded, transactions are created. Only one script package need be used per Content Parsing Manager. Since initializing a Content Parsing Manager can often involve time-consuming one-time setup operations such as loading and parsing a package file, preferably a single instance is created for each web server "application, " while multiple Content Parsing objects are created to handle individual i ser actions.

The Content Parsing script provides a level of abstraction between a source of data, e.g. headlines from a news source, and the manner in which the data is used. If a change occurs in the data source, only the script needs to be updated, and not the various entities that use the data, such as modules, Java programs, JSP files, etc.

3.8 Data Storage A portal is supported by an extensible database schema at the data storage tier of the overall architecture so that new data storage requirements do not in turn require a database administrator to modify the structure of underlying tables. The Data Storage object is a dynamically extensible, hierarchical data store, consisting of folders and documents, that enables modules to be developed that can store their own custom persistent properties, without having an impact on the overall schema.

The Data Storage object can also be employed to solve another problem, namely the performance hit associated with retrieving web content. The Data Storage object provides an infrastructure that can be used to cache web content. Recently used data can be stored in a memory cache, and content can be programmatically expired and/or uncached. The memory cache holds onto data with weak references, i.e. when memory gets scarce, garbage collection can be performed on the cache. The following API provides an interface to an abstract storage system: 1- Data storage: the data store itself

2- Data Storage Folder: a folder within the Datai Storage object. Folders can have an unlimited number of string or integer properties and can contain Data Storage Documents as well as subfolders. A folder within the Data Storage object is accessed by its patti, similar to the operation of a file system.

3- Data Storage Document: a document within the Data Storage object. The document can be a string, a serializable object, a DOM Document, the contents of a URL, or a byte array. Each document can have an unlimited number of string properties.

Different implementations of the Data Storage class, with different persistence mechanisms, are possible. One version could use a relational database, another could use LDAP, and yet another could use custom machinery. In a SQL and file system implementation of the Data Storage class, document contents are stored in the file system. For instance, a document containing a Java object is serialized and written to a file. A document containing text has the text written as a simple bytestream to file. A document containing a URL has the contents of the URL downloaded and written as a bytestream to file. A relational database keeps track of document names and where in the file system their contents are stored. Every document, when created or retrieved, is automatically put into a memory cache. The memory cache can be cleared by the Java Virtual Machine (JVM) when resources are running low.

The portal server can be scaled by load balancing across multiple machines. Many web sites cannot be replicated across servers because of state cached in memory that gets out of synchroni2ation. The portal server of the present invention can notify all servers in a cluster that cached content has changed.

3.9 Task

Services frequently need to be able to execute job s according to a schedule. An example is a cache cleanup routine, which must be run, transparent to any user, on a regular basis, e.g. every 15 minutes.

Another example is a news headline purge routine that should run every few days to remove headlines older than a specified number of days. In the portal server, these scheduled matters are handled by a task. A task is a collection of one or more subtasks coupled with a schedule. Tasks can be set up to run as external programs, Java programs in separate JVMs, on separate threads in the current JVM, or on the current thread. A schedule defines run times. It is made up of an interval, interval units, and constraining variables:

1- Maximum number of repetitions (if left at 0, unrestricted);

2- Start date (if left blank, can start immediately, depending on other constraints); 3- End date (if blank, never expires);

4- Arrays of allowed days of week, days of month, and months

(specifying any of these constrains the schedule to run only on days that match the array contents; the effect of constraining arrays is cumulative). The Persistent Scheduler class executes from a collection of persistent tasks described in its database. It reads the database for all current tasks, finds those due to be executed, and executes them.

A Task Scheduler object can iterate over scheduled tasks until there are no more to schedule, or until a shutdown time. Direct Task is an interface for a task that can be executed directly, instead of by indirection. This interface is useful for single tasks that do not need input parameters.

4. Initialization Architecture The portal server can have different initializatioxi strategies, e.g. one for an Active Server Pages (ASP) version and another for a Java Server Pages (JSP) version. These strategies solve the problem of allowing dynamic web pages to obtain access to Java objects within the object model.

4.1 ASP Version The ASP version of the portal server can run under Microsoft

Internet Information Server (IIS). The bridge between IIS and Java classes is the Microsoft Component Object Model (COM), an operating system service for connecting objects that are written in different languages. The portal server registers one of the classes within its class library as a COM object, e.g. PortalServices. When a browser first accesses the IIS portal server ASP pages, an instance of PortalServices is created within the JVM. This PortalServices object provides a path to other portal server objects so that they do not also have to be registered with COM. Figure 8 summarizes how the portal server works under ASP. IIS serves HTML and ASP pages for an IIS web application. According to the IIS definition, an "application" is the collection of files in a particular web directory and its subdirectories. Each application must have an initialization file, named global.asa, in its root directory. The starting point for an IIS application is defaixit.asp. Figure 9 shows the role of global.asa and default.asp in one possible portal server IIS implementation. Everything under the portal directory is part of the portal server application. The global.asa file in this directory is portal server's application initialization file. An OBJECT tag in global.asa creates one instance of the PortalServices COM component at web server startup.

At the start of a user's session, the global.asa file finds the correct User object, and the default.asp file creates the Layout object. ASP is used for the pages served to the user. JSP can be used to generate the module HTML within those pages, using the portal server's JSP execution environment. This technique constitutes JSP wrappering within an ASP environment

4.2 JSP Version

Unlike some scripting environments, standard JSP does not have the built-in capability to know when the web server has started, or to know when a new user has begun a session. By contrast, ASP has the notion of the global.asa file, in which code can be placed that is executed before any page in the directory is accessed by a particular user. Accordingly, the JSP version of a portal web site can be designed to ensure that initialization code is executed before any page of the site is run. The initialization code can be in a file that contains a session start method and an application start method. This file is preferably included at the top of every JSP file to ensure that the application and current user have been initialized correctly.

5. User Session Control A portal server session begins when a user first accesses any portal server page, and ends after a period of inactivity that is configurable via the web server, e.g. 20 minutes.

Identifying information about registered site users is stored in a database. A registration page enables new users to ^"be added to the database; a login page enables users to identify themselves to the portal server by entering their user name and password. The login information can be stored as a browser cookie so that users don't have to log in each time they visit a site.

MISSING AT THE TIME OF PUBLICATION

a separate "view" object in charge of each type of display. Figure 10 displays the front-page and edit views for the news module.

These two views create only the portion of a module that is surrounded by a dotted line in Figure 10, namely its substantive content. The front page and user edit page create the rest of the displayed features.

A module view object contains the display logic for its module. When a user accesses the portal, each module on the front page creates an object that generates the HTML for its front-page view. When the user clicks the edit button of a module, the edit view object creates and displays the user edit page. Figure 11 shows the display logic in more detail, again using the news module as an example.

A layout page, which is accessed by one of the personalization links 24, lists all modules that are available to any user group to which the user belongs. Users can add, remove or reorder the modules that are included in their layouts by means of this page.

Modules allow attributes to be added easily, without concern over the method of storage. The portal server provides custom properties, which support an easily extensible storage mechanism. Figure 12 illustrates how the hypothetical news module could use the Data Storage object to customize a view for a particular user. The Data Storage object stores any administrative customizations that a module might have. In the case of the news module, these customizations could, be default news categories that individual users can override for their own front pages, categories that users are required to include on their own front pages, or a combination of the two.

A module can have custom properties as well. .A module might use a custom property for values an administrator would change frequently - such as reminders or a "tip of the week." 6.1 Multithreaded Module Preparation

Since the portal server partitions a web page into logical components, i.e. modules, they can do much of their work separate, simultaneous threads. Multithreading permits multithreaded page requests to yield faster page response time, especially for heavily dynamic and network-bound pages. For example, if three modules are making network connections to get their data and each one takes two seconds, the response time for a single-threaded application would be at least six seconds. However, a multithreaded portal server's response time could be closer to two seconds.

7. JSP Hosting

An ASP version of the portal server can include a JSP execution environment that is available to module views, as depicted in Figure 13. JSP files are manipulated via a Java servlet, a Sun Microsystems specification analogous to the CGI specification. The ASP version of the portal server can include a servlet host and JSP servlet to execute JSP files. A JSP version of the portal server can also use thi s internal servlet host. Alternatively, the JSP version can use the web server's JSP servlet, by making a Servlet API call for inclusion of the module's HTML output within a web page being constructed.

8. Site Look-and-Feel, and Communities

Users of a portal web site typically belong to o ie or more user groups that are important to the portal provider. The user groups may constitute communities united by a special interest, common job role, common membership in a department or group, etc. Very commonly, the portal providers may want to create a different look to their sites for each of the different user groups. In other words, stylistic elements of the page can be varied depending on the user's group membership. To provide for this facility, these general provisions are required:

1. a means of associating formatting intelligence with specific portions of a page, thus defining a style;

2. a way of associating a user group with the style;

3. a way of identifying which of a user's group memberships takes primacy in choosing styles .

Each of these provisions is addressed in the description to follow.

8.1. Styles and Templates

A "style" is a portion of software source code affecting the look-and-feel of a user interface. For styles to be useful, their code must be packaged in a way that makes them easy to administer and to include in a user display.

Since it is a portion of user interface source code, a style cannot be useful outside of a context. A "template" is a category to which a style can belong. Templates provide the context in which a style will be used.

Templates also provide a means of retrieval for the currently selected style.

In an HTML-based implementation, styles and templates are the means by which a page can provide a different look-and- feel for different portions of the page and for different user groups.

The usefulness of styles and templates depends on how easy they are to create and to incorporate within a page. Both "templates" and "styles" can be created dynamically, as part of an administration user interface. This dynamic creation process involves the following general steps:

1. define the template, by describing it to the administrative user interface; 2. create the style's source code in a file, using whatever language and technique is appropriate to the deployment and to the types of templates to which the style will apply;

3. define the style in association with a template;

4. upload the style files to the portal web site. Once a template has been created and has one or more styles associated with it, the styles can be retrieved for use in a page. Part of the API for the Template object includes methods for retrieving styles. Once retrieved, the API for the Style object allows the style to be executed, creating the desired portion of the user interface.

8.2. Style-to-group Mapping

Styles provide the means of delivering a particular look to a template. To support the notion that different user groups will have different styles, a style within the template's set can be identified as the desired style for a group. This can be made more sophisticated to allow defaulting to a style when the user's group does not explicitly have a style associated with it.

8.3. User Primary Group

Users can belong to multiple user groups. To create a look-and-feel tailored to the user's group membership, one approach is to choose one of the user's groups as the "primary user group". This group is the one used to select user interface look-and-feel, by asking the

Template object to return the style associated with the user group.

To achieve this purpose, there must be some way of assigning the primary user group to the user, from among the set of groups to which the user belongs. For instance, an administrative user interface can include a way to flag one of the groups as "Primary".

Once the primary group has been chosen for the user, it can be used as the basis to make decisions. To support this, the API returns the primary group. In one implementation, the User object includes a method to return the user's primary group. Given the primary group, the portal web site can be written to exploit the style association with user group. For instance, the rule can be "for a given template, get the style associated with the user group, and execute the style."

8.4 Group-specific module layout An important aspect of creating a site for a user community is the ability of the portal administrator to create pages whose modules are specific to that group. This can be supported by allowing each page to have module contents by group. The ability to add modules to pages can be made specific to a group.

8.5. Special Provisions for Delegated Administration

In a system which allows "delegated administrat on" where users other than a portal administrator have some control over the look and feel of a portal page, care must be given to what template definition and style definition capabilities are made available to delegated administrators, and how those templates and styles are allowed to be added to the web site. Since styles define actual pieces of code affecting the appearance of the web site, they should be treated as potential viruses, and subjected to source control as with the rest of the site.

Thus, while a portal administrator can add styles without restriction, and can make them live immediately, risers acting as delegated administrators must be restricted so that they cannot introduce ill-behaved code. One way to accomplish this is to restrict what delegated administrators can add to the system to be only HTML, rather than JSP or ASP code. This restriction lessens the potential for serious harm to the server, but places no restriction on the content being added to the site's pages.

8.6. Viewing the End Result

Given the many provisions for an administrator to control the look-and-feel of a site by user group, and since users can belong to many different groups, an administrator can easily lose track of what the resulting portal site might look like to the end user. A solution to this problem is to give the administrator the ability to check out the end user site, by allowing them to quickly and easily "log in" as that user. This can be provided from the portion of the administrative interface that allows editing of the user record. This portion is only accessible to an administrator who necessarily has access to the user's log in, so security is arguably not compromised by providing this access. A single button within the user editing pages can provide this access. 9. Administration

As discussed in previous sections, a useful feature of the portal server is a web-based administration tool that enables administrators to perform many tasks through simple browser actions. These tasks can include any or all of the following:

1- Adding module types to the web site and setting module properties

2- Performing user administration

3- Designing page layouts and styles for user groups, and defining system- wide defaults

4- Enabling or disabling the guest and user self-registration features

5- Reviewing the most recent log of portal server activity

6- Maintaining user groups and user group membership (version 2.0 and later)

7- Setting module and user permissions

8- Running various graphical utilities, such as one that sweeps obsolete data from the Data Storage object and database; one that diagnoses the current operating conditions of the portal; one that maps images to document mime types; one that explores the contents of the Data Storage object; and/or various utilities for setting up portal services.

9.2. Delegated Administration

A portal web site can be administered entirely ^"by one or more portal administrators who have access to all the administration capabilities of the system. However, depending on thie nature of the portal site and its user communities, this central administration can create a large workload for those administrators, and may vi olate privacy of some of the communities. A remedy to these problems is the ability to delegate specific portions of administration to trusted members of user communities.

Because modules are the portal server's means of distributing content in a controlled fashion to user communities, they can serve as an excellent basis for distributing administration capabilities to a subset of users. Specifically, modules can be written to provide certain administrative capabilities, and those modules can be assigned to user groups, so that only members of those user groups will have access to the modules. Typically, of course, the user group to which an administration module is assigned is carefully restricted to a very limited number of authorized users, but this decision is left to the portal adirxinistrator.

10. Portal Site Updates 10.1 System Updates

The Java servlet is a common gateway interface (CGI). CGI programs provide the means by which web clients can run applications on web servers in real time and receive back dynamically created output. A CGI program is executed each time a client requests an Uniform Resource Locator (URL) associated with the CGI program. A limitation in implementing CGI programs is that a web-based server executing the CGI program typically does not keep track or know whicli individual user is accessing and executing a given CGI program. This can create potential security problems, particularly in the case where it is desirous to have CGI programs behave differently depending upon tJb.e privilege level of the user accessing the web-based server executing tl e CGI program. For example, a single entity may have two Portal Server installations, one with an advertising or logging and one without. In an embodiment of the present invention, a dynamic system update feature allows modules within a portal server to be updated without rebooting the user's desktop or the portal server. Administrators can update the system by retrieving an appropriate version of an updateable module for authorized installation from an update server to a portal server via a secure HyperText Transfer Protocol (HTTPS). By using HTTPS appropriate security can be maintained.

Referring to Figure 14, a system update is implemented via the Portal Server Administrator (142). Every module that is updated uses a Java interface "(swappable interface," 146), which is a marker interface. Every updateable module has its own intermediate class (144) that proxies calls by using an Updateable Subsystem (148). The intermediate class (144) holds a reference to the cunent implementation of an updateable module. It throws the reference to the current implementation of the updateable module away and holds the reference to the new instance of the updateable module upon receiving the updated implementation of the updateable module.

The Updateable Subsystem (148) follows a "singleton" design pattern, meaning that there is one instance of a module for the lifetime of a server session. The main function of the Updateable Subsystem (148) is to find the newest implementation of an updateable module using a secure socket layer protocol (HTTPS) to communicate with an update server by executing a Portal Module Upgrade servlet (150). The Updateable Subsystem verifies that it can create a new instance of the class for the updated implementation of the updateable module before returning a reference for the updated implementation to the intermediate class (144) or administrative tool, and registering the class into the appropriate portal server. The interface between the Updateable Subsystem (148) and the Portal Module Upgrade servlet (150) is an HTML form containing: a Portal Server Identification Code for the portal site host, the name of the updateable module and its version number, and the actual class name. The Portal Module Upgrade servlet (150) returns a jar file, such as a compressed file containing class, image, sound, and/or other data files, to the Updateable Subsystem (148). The Portal Module Upgrade servlet (150) also returns a serialized properties Object containing the location of the jar file to retrieve, the class name of the new implementation, the title and description of the module to be displayed on the user interface, and the new version of the module that is available to the Updateable Subsystem (148).

The Portal Module Upgrade servlet (150) is a module that consists of a Servlet. The Servlet responds to download requests from the Updateable Subsystem (148) using a secure socket layer protocol (HTTPS) to deliver the requested jar files, from an appropriate update server (152). The update server (152) is chosen based on host information identifying the portal site host, such as a system serial number. In an embodiment of the present invention, one version of a requested module in an update server may be selected over another version of a requested module in the update server based on the serial number of the system requesting the module. Alternatively, one version of a requested module in an update server may be selected over the same version of the requested module in another update server based on the serial number of the system requesting the module. In addition, the database determines sets of permissions, such as premium news and advertisements, available to the version of the updateable module selected in accordance with the host information identifymg portal server. After receipt of the information by the Updateable Subsystem (148), a Dynamic Class Loader (154) retrieves the new classes for the new implementation of the updateable modules from the downloaded jar file and instantiates them for use in the system as necessary. It loads the new class for the new implementation of the updateable module in its own name space and provides the new class to the intermediate class (144) via the Java swappable interface (146) for use within the portal server. The intermediate class (144) updates the reference to the current version of its swappable implementation of the updateable module and provides the updateable module to the administrative interface (142) and then to the user.

10.2 Style Changes

A chrome is a template that defines the elements, including functionality, around the content of a module, such as module title, as well as edit, delete and minimize buttons. For example, a Christmas module chrome can be a specific style that is designed for use during the Christmas season. A template may have multiple styles. Each style has a corresponding Java object that is instantiated by a Java style class. The Java style class controls whether a given user can execute that particular style, and is persistently stored in. a database, where the other web servers in a cluster can get to them after their creation.

In an embodiment of the present invention, dynamic modules on a single or multiple servers may have their styles clianged without interrupting a single user interaction with the modi les or web-site operation. For example, an administrator may uplo ad a Christmas module chrome by executing a command to change a style. The portal server containing the module whose style is to be changed suspends all new requests for that module, while also permitting all users currently interacting with the module to complete their task. When no one is interacting with the module, a style corresponding to the Christmas module chrome is retrieved from the database to the web-server providing the portal server. This enables templates and styles to be applied in real-time without the need to turn off the website.

Referring to Figure 15, in step 160, a principle JSP file is executed. An administrator who wants to upload a new style, such as the Christmas module chrome, may execute the principle JSP file. The execution of the JSP file may be initiated via an administrative interface. The JSP file outputs the HTML code corresponding to the chrome and any secondary files, such as the GIF file buttons to edit, delete or minimize. In step 162, the portal server receives the upload of the JSP and stores it in a temporary file folder. In step 164, the Style Object (style class) temporarily suspends any request for that style for all users in the cluster. This suspension is achieved through the access that the Java Virtual Machine allows to the operating system's threads of execution. An HTTP reqixest for a style is executed on a thread. The update of the style itself happens on a thread. One facility of the JVM is to tell one thread to wait for another thread to complete execution before resuming its own execution. If the style is in the middle of being updated, the Style Object controlling access to the style instructs the thread of any HTTP request for the style to wait until the updating thread is done. The Style Object detects if anyone is currently using the style. If they are, the process proceeds to step 170 where they are allowed to continue. If they are not, the process proceeds to step 166, where they are not allowed any new request for that style. The Style Object then moves the new files (i.e. Christmas module chrome) from the temporary file folder to the web-server file system. In step 172, the Style Object releases the users from suspension, and allows them to execute the module with the new style. Once the Style Object has finished updating the web files, the updating thread completes, and the JVM takes care of starting all the request threads again.

11. Summary

From the foregoing, it can be seen that the present invention provides an architecture for a portal server that offexs a number of features and advantages. One such feature is its platform independence. The portal server can work with UNIX, Linux, and Windows NT, as well as with leading web servers, application servers, and databases. Further advantages lie in the fact that installation is rapid. An. entire working portal can be up and running very quickly: in hours or days, rather than weeks or months that were required prior to the invention. Organizations can, at their own pace, change all aspects of the lookz-and-feel of the portal, integrate their own content, and use the portal server's development tools to extend out-of-the-box functionaJity. The portal server is preferably based on Java, JSP, JDBC, X ML, and other standards-based technologies, thereby promoting integration with existing systems and reducing required learning time.

It will be appreciated by those of ordinary skill in the art that the present invention can be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The presently disclosed embodiments are therefore considered in all respects to be illustrative, and not restrictive. The scope of the invention is indicated by the appended claims, rather than the foregoing description, and all changes that come within the meaning and range of equivalence thereof are intended to be embraced therein.

Claims

CLAIMS What is claimed is: 1. A portal server framework for modifying modules within a portal on a computer network, comprising: an intermediate class configured to instantiate an intermediate object, the intermediate object operable to hold a reference to a current implementation of an instantiated object, the instantiated object encapsulating information of a particular type on the computer network; and an updateable subsystem class configured to instantiate an update subsystem object, the update subsystem object operable to select an updated implementation of the instantiated object from a set of update servers; whereby, an appropriate update server in the set of update servers from which to select the updated implementation of the instantiated object is based on host identification information of a site hosting the portal, and upon installation on the network, the classes are executable by a processor on the computer network.

2. The portal server framework of claim 1, further comprising a portal module upgrade servlet class configured to instantiate a portal module upgrade servlet object, the a portal module upgrade servlet object operable to deliver a file to the update system object from the appropriate update server in the set of update servers.

3. The portal server framework of claim 2, wherein the file includes a combination of: a class file, an image file, a sound file and data information file.

4. The portal server framework of claim 3, further comprising a dynamic loader class configured to instantiate a dynamic loader object, the dynamic loader object operable to retrieve a set of classes for the updated implementation of the instantiated object.

5. The portal server framework of claim 4, further comprising a swappable loader class configured to instantiate a swappable object, the swappable object operable to provide the set of classes for the updated implementation of the instantiated object to the intermediate object.

6. The portal server framework of claim 5, wherein the intermediate object replaces the reference to the current implementation of the instantiated object with a reference to the updated implementation of the instantiated object.

7. The portal server framework of claim 1, further comprising a portal module upgrade servlet class configured to instantiate a portal module upgrade servlet object, the portal module upgrade servlet object operable to deliver a properties object to the update system object from the appropriate update server in the set of update servers.

8. The portal server framework of claim 7, wherein the properties object includes a combination of the location of: a file, a class name of the updated implementation of the instantiated object, a title of the updated implementation of the instantiated object, a description of the updated implementation of the instantiated object, and an updated implementation of the instantiated object.

9. The portal server framework of claim 1, further comprising an administrative interface class configured to instantiate an administrative object, the administrative object operable to provide an instantiated new object, the instantiated new object representing an updated implementation of the instantiated object.

10. A method of modifying modules within a portal on a computer network, comprising: providing an intermediate class configured to instantiate an intermediate object, the intermediate object operable to hold a reference to a current implementation of an instantiated object, the instantiated object encapsulating information of a particular type on the computer network; and providing an updateable subsystem class configured to instantiate an update subsystem object, the update subsystem object operable to select an updated implementation of the instantiated object from a set of update servers; whereby, an appropriate update server in the set of update servers from which to select the updated implementation of the instantiated object is based on host identification information of a site hosting the portal, and the classes are executable by a processor on the computer network.

11. The method of claim 10, further comprising providing a portal module upgrade servlet class configured to instantiate a portal module upgrade servlet object, the a portal module upgrade servlet object operable to deliver a file to the update system ob ect from the appropriate update server in the set of update servers.

12. The method of claim 11, wherein the file includes a combination of: a class file, an image file, a sound file and data information file.

13. The method of claim 12, further comprising providing a dynamic loader class configured to instantiate a dynamic loader object, the dynamic loader object operable to retrieve a set of classes for the updated implementation of the instantiated object.

14. The method of claim 13, further comprising providing a swappable loader class configured to instantiate a swappable object, the swappable object operable to provide the set of classes for the updated implementation of the instantiated object to the intermediate object.

15. The method of claim 14, wherein the intermediate object replaces the reference to the current implementation of the instantiated object with a reference to the updated implementation of the instantiated object.

16. The method of claim 10, further comprising providing a portal module upgrade servlet class configured to instantiate a portal module upgrade servlet object, the portal module upgrade servlet object operable to deliver a properties object to the update system object from the appropriate update server in the set of update servers.

17. The method of claim 16, wherein the properties object includes a combination of the location of: a file, a class name of the updated implementation of the instantiated object, a title of the updated implementation of the instantiated object, a description of trie updated implementation of the instantiated object, and an updated implementation of the instantiated object.

18. The method of claim 10, further comprising providing an administrative interface class configured to instantiate an administrative object, the administrative object operable to provide an instantiated new object, the instantiated new object representing an updated implementation of the instantiated obj ect.

19. A computer program product for modifying modules within a portal on a computer network, comprising: a computer readable medium; and computer program instructions, recorded on the conxputer readable medium, executable by a processor, for performing the step s of: instantiating an intermediate object, the intermediate object operable to hold a reference to a current implementation of an instantiated object, the instantiated object encapsulating information of a particular type on the computer network; and instantiating an update subsystem object, the update subsystem object operable to select an updated implementation of the instantiated object from a set of update servers; whereby, an appropriate update server in the set of update servers from which to select the updated implementation of the instantiated object is based on host identification information of a site hosting the portal.

20. The computer program product of claim 19, further comprising computer program instructions for performing the step of instantiating a portal module upgrade servlet object, the a portal module upgrade servlet object operable to deliver a file to the update system object from the appropriate update server in the set of update servers.

21. The computer program product of claim 20, wherein the file includes a combination of: a class file, an image file, a sound file and data information file.

22. The computer program product of claim 21 , further comprising computer program instructions for performing the step of instantiating a dynamic loader object, the dynamic loader object operable to retrieve a set of classes for the updated implementation of the instantiated object.

23. The computer program product of claim 22, further comprising computer program instructions for performing the step of instantiating a swappable object, the swappable object operable to provide the set of classes for the updated implementation of the instantiated object to the intermediate object.

24. The computer program product of claim 23, wherein the intermediate object replaces the reference to the current implementation of the instantiated object with a reference to the updated implementation of the instantiated object.

25. The computer program product of claim 19, further comprising computer program instructions for performing the step of instantiating a portal module upgrade servlet object, the portal module upgrade servlet object operable to deliver a properties object to the update system object from the appropriate update server in the set of update servers.

26. The computer program product of claim 25, wherein the properties object includes a combination of the location of: a file, a class name of the updated implementation of the instantiated object, a title of the updated implementation of the instantiated object, a description of the updated implementation of the instantiated object, and an updated implementation of the instantiated object.

27. The computer program product of claim 19, further comprising computer program instructions for performing the step of instantiating an administrative object, the administrative object operable to provide an instantiated new object, the instantiated new object representing an updated implementation of the instantiated object.

28. A method for configuring a layout of a page in a portal server, the method comprising: determining a coordinate axis of orientation; generating a number of dividers within the layout in a direction away from the coordinate axis; generating at least one cell within at least some of the dividers; and assigning a module to the at least one cell within the at least some dividers.

29. The method according to claim 28, further comprising selecting the number of dividers.

30. The method according to claim 28, wherein the generating of dividers comprises assigning a width to each of the numb er of dividers.

31. The method according to claim 30, further comprising selecting a unit of measure.

32. The method according to claim 30, further comprising generating additional cells within a selected divider.

33. The method according to claim 32, further comprising assigning a module to at least one of the additional cells.

34. The method according to claim 32, wherein the generating of additional cells comprises assigning a width to each of the additional cells within the selected divider.

35. The method according to claim 30, further comprising generating a number of additional dividers within the layout in a direction away from the coordinate axis.

36. The method of claim 28, further comprising locking a set of modules within the layout.

37. The method of claim 28, further comprising locking the entire module set of a layout.

38. A computer program product comprising: a computer useable medium computer program instructions, recorded on the computer useable medium, executable by a processor, for performing the steps of: determining a coordinate axis of orientation; generating a number of dividers within the layout in a direction away from the coordinate axis; generating at least one cell within at least some of the dividers; and assigning a module to the at least one cell within the at least some dividers.

39. The computer program product according to claim 38, further comprising computer program instructions for selecting the number of dividers.

40. The computer program product according to claim 38, wherein the generating of dividers comprises assigning a width to each of the number of dividers.

41. The computer program product according to claim 40, further comprising computer program instructions for selecting a unit of measure.

42. The computer program product according to claim 40, further comprising computer program instruction for generating additional cells within a selected divider.

43. The computer program product according to claim 42, further comprising computer program instruction for assigning a module to at least one of the additional cells

44. The computer program product according to claim 40, further comprising computer program instruction for generating a number of additional dividers within the layout in a direction away from the coordinate axis.

45. The computer program product of claim 38 , further comprising computer program instruction for locking a set of modules within the layout.

46. The computer program product of claim 38, further comprising computer program instruction for locking the entire module set of a layout.

47. A system for configuring a layout of a page in a portal server, the system comprising: a network interface exchanging information with a network;

a memory storing process management services arid libraries; and

a processor, coupled to the network interface and the memory, for: determining a coordinate axis of orientation; generating a number of dividers within the layout in a direction away from the coordinate axis; generating at least one cell within at least some of the dividers; and assigning a module to the at least one cell within the at least some dividers.

48. The system according to claim 47, further comprising the processor for selecting the number of dividers.

49. The system according to claim 47, wherein the generating of dividers comprises assigning a width to each of the number of dividers.

50. The system according to claim 49, further comprising the processor for selecting a unit of measure.

51. The system according to claim 49, further comprising the processor for generating additional cells within a selected divider.

52. The system according to claim 51 , further comprising the processor for assigning a module to at least one of the additional cells.

53. The system according to claim 51 , wherein the generating of additional cells comprises assigning a width to each of the additional cells within the selected divider.

54. The system according to claim 49, further comprising the processor for generating a number of additional dividers within the layout in a direction away from the coordinate axis.

55. The system according to claim 47, further comprising the processor for locking a set of modules within the layout.

56. The system according to claim 47, further comprising the processor for locking the entire module set of a layout.

57. A method of proxying a remote web application, web page and web site, the method comprising: parsing the entire content of a web page; identifying an items of interest within the web page; and transforming the item of interest to a portal URL;

58. The method according to claim 57, further comprising determining a form of the items of interest.

59. The method according to claim 58, wherein identifying comprises determining a zone of the items of interest.

60. The method according to claim 58, wherein the identifying comprises converting the item to one of: a absolute item

61. The method according to claim 57, wherein the transforming comprises adding portal properties to the item of interest.

62. The method according to claim 57, wherein the transforming comprises replacing the item of interest with a portal property.

63. The method according to claim 1, wherein the identifying comprises generating a request in response to an upload information.

64. The method according to claim 63, further comprising displaying the item.

65. The method according to claim 57, further comprising displaying the portal URL.

66. The method according to claim 57, wherein the identifying comprises determining that the item is a special item.

67. The method according to claim 66, wherein the special item is one of: an image, a link, associated with a frameset.

68. The method according to claim 67, further comprising searching for statements.

69. A framework for proxying a remote web application. , web page and web site on a computer network, the method comprising: a content transformation class configured to instantiate a transformation object, the transformation object operable to: parse the entire content of a web page; identifying an items of interest within the web page; and transforming the item of interest to a portal URL; whereby, upon installation on the network, the classes are executable by a processor on the computer network.

70. The framework according to claim 69, wherein the transformation object is operable to determine a form of the items of interest.

71. The framework according to claim 70, wherein identifying comprises determining a zone of the items of interest.

72. The framework according to claim 70, wherein the identifying comprises converting the item to one of: a absolute item

73. The framework according to claim 69, wherein the transforming comprises adding portal properties to the item of interest.

74. The framework according to claim 69, wherein the transforming comprises replacing the item of interest with a portal property.

75. The method according to claim 69, wherein the identifying comprises generating a request in response to an upload information.

76. The framework according to claim 75, further comprising displaying the item.

77. The framework according to claim 69, further comprising displaying the portal URL.

78. The framework according to claim 69, wherein the identifying comprises determining that the item is a special item.

79. The framework according to claim 78, wherein the special item is one of: an image, a link, associated with a frameset.

80. The framework according to claim 69, further comprising searching for statements.