Content and Design Implementation

The Portal Desktop provides the primary end-user interface for Portal Server and a mechanism for extensible content aggregation through the Provider Application Programming Interface (PAPI). The Portal Desktop includes a variety of providers that enable container hierarchy and the basic building blocks for building some types of channels. For storing content provider and channel data, the Portal Desktop implements a display profile data storage mechanism on top of an Access Manager service.

The various techniques you can use for content aggregation include:

• Creating channels using building block providers

• Creating channels using JSPProvider>

• Creating channels using Portal Server tag libraries

• Creating channels using custom building block providers

• Organizing content using container channels

See the Sun Java System Portal Server 6 Secure Remote Access 2005Q4 Administration Guide and Sun Java System Portal Server 7 Developer Sample Guide for more information.

Placement of Static Portal Content

Place your static portal content in the web-container-install-root/SUNWam/public_html directory or in a subdirectory under the web-container-install-root/SUNWam/public_html directory (the document root for the web container). Do not place your content in the web-container-install-root/SUNWportal/web-apps/https-server/portal/ directory, as this is a private directory. Any content here is subject to deletion when the Portal Server web application is redeployed during a patch or other update.

Integrating Applications

Integrating and deploying applications with Portal Server is one of your most important deployment tasks. The application types include:

• Channel. Provides limited content options; is not a “mini-browser”.

• Portlet. Pluggable web component that processes requests and generates content within the context of a portal. In Portal Server software, a portlet is managed by the Portlet Container. Conceptually, a portlet is equivalent to a Provider.

• Portal application. Launched from a channel in its own browser window; the Portal Server hosts the application; created as an Access Manager service; accesses Portal and Access Manager APIs.

• Third-party application. Hosted separately from Portal Server, but accessed from Portal Server; URL Scraper, which calls Rewriter, rewrites web pages so that the web pages can be displayed in a channel; uses Access Manager to enable single sign-on.

Integrating Microsoft Exchange

Using the JavaMail^TM API is one of the primary options for integrating Microsoft Exchange messaging server with Portal Server. The JavaMail API provides a platform independent and protocol independent framework to build Java technology-based mail and messaging applications. The JavaMail API is implemented as a Java platform optional package and is also available as part of the Java 2 Enterprise Edition.

JavaMail provides a common uniform API for managing mail. It enables service providers to provide a standard interface to their standards based or proprietary messaging systems using Java programming language. Using this API, applications can access message stores and compose and send messages.

Independent Software Vendors

Listed below are some types of independent software vendor (ISV) integrations.

• Application user interface. This integration uses the provider API and SRA for secure access. (SRA is not an integration type on its own.) Examples include FatWire, Interwoven, SAP, Tarantella, Documentum, Vignette, PeopleSoft, Siebel, Citrix, and YellowBrix.

• Security products. This integration uses the Access Manager Login API to enable portal access by using a custom authentication scheme. Examples include RSA Security.

• Content Management. This integration provides data access into Portal Server, enabling searches on the data. Examples include FatWire, Interwoven, and Vignette.

• Content Syndication. This integration provides managing and customizing information that appears on websites. Examples include YellowBrix and Pinnacor.

• Collaboration software. This integration enables Sun Java^TM System InstantMessaging product to move a collaboration session from one forum to a another. Examples include WebEx, BeNotified, and Lotus.

• Monitoring. This integration focuses on billing, performance measurement, and diagnostics, for which you rely on log files (or Portal Server’s Logging API) and traffic snooping. Examples include Mercury Interactive, Hyperion, and Informatica.

• Portal capability augmentation. This integration enables products to add functionality to Portal Server. Examples include Altio, Bowstreet, rule engines to add group capability, and dynamic standard Portal Desktop and provider contents (HNC).

• Integratable portal stack. This integration includes products that replace elements of Portal Server. Examples include Access Manager and LDAP.

Portal Server cannot currently integrate another LDAP solution. Access Manager and Portal Server rely on features not found in other LDAP implementations.

The “depth” to which user interface integration occurs with Portal Server indicates how complete the integration is. Depth is a term used to describe the complementary nature of the integration, and points to such items as:

• Application availability through Portal Server

• Application availability in secure mode (using SRA, Netlet rules)

• Ability to use single sign-on

In general, the degree to which an application integrates in Portal Server can be viewed as follows:

• Shallow integration. This integration essentially uses the Portal Server as a launch point. The user logs in to the portal and clicks a link that starts a web application.

• Deep integration. The user accesses the user interface provided by the channels in Portal Server directly. That is, the integrated software works within the portal. No additional windows or applets appear.