Browse Prior Art Database

Portal Aggregation Stream Dynamic Validation and Reactive Recovery Disclosure Number: IPCOM000125993D
Original Publication Date: 2005-Jun-27
Included in the Prior Art Database: 2005-Jun-27
Document File: 2 page(s) / 23K

Publishing Venue



Dynamic Validation and Reactive Error Recovery Within a Dynamic Portal Aggregation Stream

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Page 1 of 2

Portal Aggregation Stream Dynamic Validation and Reactive Recovery

Portal Servers are a very popular technology in wide use both worldwide on the public Internet, and within large enterprise intranets. A portal server creates portlet content through a process called aggregation. During the aggregation, the portal calls each sub application (typically a portlet) and the portlet returns content in the form of markup to the aggregator by writing the markup to the aggregation stream. When the aggregation is complete the composite stream is returned to the client requesting the portal rendering, and the content is displayed on the devices browser.

When building traditional web sites, customers can easily use automatic tools to assure the quality of the web site by validating the syntax of the language (for example HTML).

This validation is very important, since today's browsers tend more and more to ignore a certain number of errors and problems in the given mark-up. As different browsers ignore different errors it is nearly impossible to predict how a browser that was not tested individually will react to the mark-up. The W3-Consortium (W3C) provides a set of rules and definitions to validate mark-up. A number of tools are available that load mark-up from a given address and run a syntax check on it.

As stated above, portal environments as WebSphere Portal are highly dynamic. The following points give just a brief idea of the dynamic capabilities of a portal:
* Allows customization of the look-and-feel of the generated pages to a very high degree. Besides configuration of the layout this also includes adaptation of the navigation in an extremely complex manner.
* Most of the mark-up is generated by independent applications called portlets. They mostly use Java code and JSP's, which are built together in a highly dynamic way and are influenced by a number of state information, to produce the mark-up.

This makes the portal stream syntax validation and analyses very difficult, since one URL can send back different mark-up based on the state of the portal. Testing each portlet's content contribution separately (JSP's and Java code) has only limited success since errors that occur when pieces are put together cannot be tested. Also, most parts of a portal will require a logon, so automated syntax validation tools test only very limited pieces of the mark-up without being logged into the portal.

WebSphere Portal provides the function of PortalFilters. PortalFilters are a mechanism to work with the request and response objects provided by the WebSphere Application Server before and after the portal itself is using them. The portal's main servlet checks for the presence of a PortalFilter and when it finds one it calls it before the real portal code is started.

This gives a PortalFilter the opportunity to filter content, change parameters in the request object, access information in the user's session, change the client detection, etc.