Portal Desktop Design

The performance of Portal Server largely depends upon how fast individual channels perform. In addition, the user experience of the portal is based upon the speed with which the Portal Desktop is displayed. The Portal Desktop can only load as fast as the slowest displayed channel. For example, consider a Portal Desktop composed of ten channels. If nine channels are rendered in one millisecond but the tenth takes three seconds, the Portal Desktop does not appear until that tenth channel is processed by the portal. By making sure that each channel can process a request in the shortest possible time, you provide a better performing Portal Desktop.

Choosing and Implementing the Correct Aggregration Strategy

The options for implementing portal channels for speed and scalability include the following.

• Keeping processing functions on back-end systems and application servers, not on the portal server. The portal server needs to optimize getting requests from the user. Push as much business logic processing to the back-end systems. Whenever possible, use the portal to deliver customized content to the users, not to process it.

• Ensuring that the back-end systems are highly scalable and performing. The Portal Desktop only responds as fast as the servers from which it obtains information (to be displayed in the channels).

• Understanding where data is stored when designing providers, how the portal gets that data, how the provider gets that data, and the type of data. For example, is the data dynamic that pertains to an individual user, or is there code needed to retrieve that customized or personalized data? Or, is the data static and shared by a small group of users? Next, you need to understand where the data resides (for example, in an XML file, database and flat file), and how frequently the data is updated. Finally, you need to understand how the business logic is applied for processing the data, so that the provider can deliver a personalized channel to the user.

Working with Providers

Consider the following when planning to deploy providers:

• URLScraperProvider. Typically you use this provider to access dynamic content that is supplied by another web container’s web-based system. It uses HTTP and HTTPS calls to retrieve the content. This provider puts high requirements on the back-end system, as the back-end system has to be highly scalable and available. Performance needs to be in tenths of a second to show high performance. This provider is very useful for proof of concept in the trial phase of your portal deployment due to the simplicity of configuration.

  URLScraperProvider also performs some level of rewriting every time it retrieves a page. For example, if a channel retrieves a news page that contains a picture that is hosted on another web site, for the portal to be able to display that picture, the URL of that picture needs to be rewritten. The portal does not host that picture, so URLScraperProvider needs to rewrite that picture URL to present it to portal users.

  The URL Scraper provider that is part of Portal Server can also function as a file scraper provider.

  To use URLScraperProvider as a file scraper provider, specify the URL as follows:

  String name=“url”value="file://path/filename”

  This is the best performing provider, in terms of how fast it retrieves content. On the first fetch of content, performance for this provider is usually in the low ten milliseconds. On subsequent requests, using a built-in caching mechanism, this provider can usually deliver content in one millisecond or less. If applicable, consider using the file scraper provider in place of the URL Scraper provider.

• JSPProvider. Uses JavaServer Pages^TM (JSP) technology. JSPProvider obtains content from one or more JSP files. A JSP file can be a static document (HTML only) or a standard JSP file with HTML and Java programming language embedded within tags. A JSP file can include other JSP files. However, only the topmost JSP file can be configured through the display profile. The topmost JSP files are defined through the contentPage, editPage, and processPage properties.

• LoginProvider. Provides access to the Access Manager authentication service through a Portal Desktop channel. This provider enables anonymous Portal Desktop login so that a user can log in directly from the Portal Desktop.

• XMLProvider. Transforms an XML document into HTML using an XSLT (XML Style Sheet Language) file. You must create the appropriate XSLT file to match the XML document type. XMLProvider is an extension of URLScraperProvider. This provider uses the javax.xml.transform classes provided with j2se 1.5.

• SimpleWebServiceProvider.As a subclass of URLScraperProvider, SimpleWebServicProvider retrieves the WSDL file and communicates with the associated Web service through Simple Object Access Protocol (SOAP).