Chapter 2
Sun ONE Portal Server Architecture

This chapter describes the architecture, protocols, interfaces, directory structure, deployment, and customization of the Sun™ ONE Portal Server 6.2 product.

This chapter contains the following sections:

Portal Server Components
Java Enterprise System Software Interfaces
Portal Server Configuration Files and Directory Structure
Portal Server Software Deployment
The Portal Desktop is the presentation of the portal. It is the logical component consisting of the Desktop servlet, provider APIs, channels, and various other support APIs and utilities. The Desktop is constructed of a set of channels that can be easily replaced. The Desktop also uses a proprietary templating mechanism used by many Desktop providers to separate static content from compiled Java code.
Portal Server Customization
Portal Server Availability and Fault Tolerance
Portal Server Security, Encryption, and Authentication

---

Portal Server Components

This section describes the Portal Server components, first in terms of the platform itself and individual components, then in terms of the portal services. See Chapter 3, "Sun ONE Portal Server, Secure Remote Access Architecture" for details on the Sun™ ONE Portal Server, Secure Remote Access (SRA) product.

Deployment Platform

Portal Server is part of the Sun ONE architecture. Within the Sun ONE architecture, Portal Server provides technologies that locate, connect, aggregate, present, communicate, personalize, notify, and deliver content.

Java Enterprise System ships with Sun™ ONE Web Server and Sun™ ONE Application Server web application containers.

In addition, the following application servers can be used as its web application container, in place of the Sun™ ONE Web Server and Sun™ ONE Application Server software.

BEA WebLogic Server™
IBM WebSphere® Application Server

See the Sun ONE Portal Server 6.2 Installation Guide for information on deploying Portal Server in various web containers.

Portal Server is able to work with previously installed software components. In this case, Portal Server uses the installed software as long as the software is an appropriate version. Portal Server add-on products include the additional software that is needed for that product. You must install Portal Server before installing an add-on product.

Software Components

Figure 2-1 shows the software components that comprise Portal Server. (This figure shows Sun™ ONE Web Server software as the web container. It could just as well use one of the application servers previously mentioned.) The software components are arranged in a hierarchy.

The bottom layer is Sun™ ONE Identity Server software. Within it are the following core components: the Java™ API for XML Processing (JAXP), Java™ Development Kit (JDK™) Network Security Services for Java™ (JSS), Sun ONE Web Server, and Sun™ ONE Directory Server software.

The next layer is the Sun ONE Portal Server. Within it are the following internal components (services): Portal Desktop, NetMail, Rewriter, and Search Engine.

Figure 2-1  Portal Server Software Components

Throughout the figure, the line type in which a component is drawn indicates the following:

Dotted lines indicate components that can use their own copies of a contained component or share copies with other components. Other components can directly use the interfaces from contained components. In addition, contained components can be updated independently from a component. For Portal Server, these components include Identity Server, Java Development Kit, and Directory Server.
Dashed lines indicate components that have one or more characteristics from each of the other two categories. For Portal Server, this component is Sun ONE Web Server.
Solid lines indicate components that use their own copies of the contained component. Other components are not allowed to share the contained component or directly use the interfaces from the contained component. In Portal Server, these components are the add-on components, Portal Server itself, the Search Engine, Portal Desktop, NetMail, and Rewriter , and JAXP and JSS components.

The following sections describe the software components identified in Figure 2-1.

Sun ONE Web Server, Sun ONE Application Server, BEA , and IBM Application Servers

Sun ONE Application Server is included with the Java System Enterprise software.

Sun ONE Portal Server uses Sun ONE Web Server, or one of the supported application servers, as the web application container for Sun ONE Portal Server and Sun ONE Portal Server add-on applications. Components within an instance communicate through the JVM™ using Java APIs.

See Sun ONE Portal Server 6.2 Installation Guide for information on deploying Portal Server in various web containers.

Sun ONE Directory Server

Sun ONE Directory Server provides the primary configuration and user profile data repository for Portal Server. The Directory Server is LDAP compliant and implemented on an extensible, open schema.

Sun ONE Identity Server

Sun ONE Identity Server provides user and service management, authentication and single sign-on services, policy management, logging service, debug utility, the administration console, and client support interfaces for Portal Server.

Java Development Kit

Java Development Kit provides the Java run-time environment for all Java software in Portal Server and its underlying components. Portal Server depends on the JDK of the web container.

Note	See the Sun ONE Portal Server 6.2 Release Notes for specific versions of products supported by Sun ONE Portal Server 6.2.

Services Used by Portal Server

This section provides general information about Portal Server components that integrate external components into a system that is easier to install and use, provide additional functionality to external components, and provide backward compatibility for old interfaces. The relationships and interfaces associated with these components are shown in Figure 2-2.

Figure 2-2  Services Used

by Portal Server

Portal Desktop

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 Identity Server service. You can edit the display profile and other Portal Desktop service data with the Identity Server administration console.

Portlet Container

The Portal Desktop displays portlets which are pluggable web components that generate content within the context of a portal. Sun ONE portlets are Java Specification Request (JSR) 168 compliant.

The Portlet Container manages and dispatches requests to portlets. The Portlet Container collects and sends back the content through a provider.

To create a portlet, you can can use the sample portlet shipped with Portal Server as an example. For information on developing and deploying a portlet, see the Sun ONE Portal Server 6.2 Developer’s Guide.

Sun ONE Portal Server Providers

A provider is a Java™ class responsible for converting the content in a file, or the output of an application or service into the proper format for a channel.

Portal Server implements several content providers as part of the Portal Server product rather than in the Portal Desktop component because of dependencies on other system components. For a list of providers and detailed information, see the Sun ONE Portal Server 6.2 Desktop Customization Guide.

Examples of providers that are part of the Portal Server product include:

JSPProvider—Uses JavaServer Pages™ (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 code. 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 Identity Server 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.

Portal Server Channels

To the end user, a channel is a distinct unit of content in the Portal Desktop, usually (but not always) set off with a border and header row of icons that enables users to configure the channel to their preference.

Once a portlet is deployed, Portal Server is aware of a portlet defined in an application. You can create channels based on a portlet. For information on creating channels, see Sun ONE Portal Server 6.2 Administrator’s Guide.

Some of the channels provided by Portal Server 6.2 are:

Login
UserInfo
Bookmark
App
SampleJSP
Search
Bookmark2
SampleRSS SampleXML
SampleURLScraper
Notes
PersonalNotes
MailCheck
SampleSimpleWebService
SampleSimpleWebServiceConfigurable
Subscriptions
Discussions
DiscussionLite
Calendar
AddressBook
Mail
IMChannel

NetMail

The NetMail component implements the NetMail (based on Java technology) and NetMail Lite email clients. These clients work with standard IMAP and SMTP servers. You can edit NetMail service data with the Identity Server administration console.

Rewriter

The Rewriter provides a Java class library for rewriting URL references in various web languages such as HTML, JavaScript™, and WML, and in HTTP Location headers (redirections). The Rewriter defines an Identity Server service for storing rules that define how rewriting is to be done and the data to be rewritten. You can edit Rewriter rules with the Identity Server administration console.

Search Engine

The Search Engine service provides basic and advanced search and browse channels for the Portal Desktop. It uses a robot to create resource descriptions for documents that are available in the intranet, and stores these resource descriptions in an indexed database. Resource Descriptions (RDs) can also be imported from another server or from a backup Summary Object Interchange Format (SOIF) file. The Search Engine includes Java and C APIs for submitting resource descriptions and for searching the database. The Search Engine database can also be used for storing other arbitrary content, for example, a shared content cache for other content providers. You can edit Search Engine service data with the Identity Server administration console.

The Search Engine service is used in the Subscription channel to summarize the number of hits (relevant information) that match each profile entry defined by the user for categorized documents and discussions.

Additionally, the Search Engine service is used in the Discussion channel to individually search contents and rate the importance for comments.

Portal Server, Secure Remote Access

SRA enables remote users to securely access their organization’s network and its services over the Internet. Additionally, it gives your organization a secure Internet portal, providing access to content, applications, and data to any targeted audience—employees, business partners, or the general public.

See Chapter 3, "Sun ONE Portal Server, Secure Remote Access Architecture" for more information.

Service Configuration

As a Sun ONE Identity Server application, Sun ONE Portal Server defines services that are managed using the Identity Server service management system. Generally, any service-related data that is not server-specific is stored in the LDAP directory. Server-specific data can be stored in properties files that are local to the specific server. See the Sun ONE Portal Server 6.2 Administrator’s Guide for information on these files.

Portal Server registers its services into the Identity Server Services Management Services framework. This occurs during the pre-installation of Portal Server and post-installation for Identity Server.

Services Management System provides a mechanism for services to define and manage their configuration data by using an XML file that adheres to the Services Management System Document Type Definition (DTD). The definition of the configuration parameters through the XML file is called the schema for the service.

The service configuration schema and the service configuration data are stored in the directory server using the LDAP Directory Information Tree (DIT) and schema defined by the product. Each Portal Server service (listed below) has its own XML and properties files for presenting and modifying service specific data.

Configuration data for a service can be classified as global, dynamic, organization, user, and policy. In general, configuration data that is global and not instance-specific is stored under the root node as ou=service. Configuration information that is specific to an organization is stored under the organization’s node as ou=services. Each organization has its own configuration for Portal Desktop services.

Portal Server defines services within the Identity Server framework:

Portal Desktop—includes data associated with the Desktop component, including the display profile and other configuration parameters associated with the Desktop. The Identity Server service name is SunPortalDesktopService .
Search Engine—the search engine for each Portal Server instance. Defines at least one service, but can use multiple backend databases and search engine instances. The Identity Server service name is SunPortalSearchService.
NetMail—includes data associated with the NetMail application primarily consisting of the user’s preferences. The Identity Server service name is SunPortalNetMailService .
Rewriter—includes data associated with the Rewriter component, including the named rule sets that control the rewriting operation. The Rewriter API makes reference to the named rulesets that are stored in the directory. The Identity Server service name is SunPortalRewriterService.
SRA—includes the following services: Access List, Gateway, NetFile, and Netlet. The Identity Server service name is SunPortalSRAPService.
Subscriptions—includes dynamic and user attributes. Values applied to the dynamic attributes are applied across the Sun ONE Identity Server configuration.The Identity Server service name is SunPortalSubscriptionService.

You administer Portal Server services (as well as the Identity Server services) through the Identity Server administration console. For more information, see the Sun ONE Portal Server 6.2 Administrator’s Guide.

---

Java Enterprise System Software Interfaces

The Java Enterprise System software has the following interfaces:

Front-end Interface—enables users to access enterprise resources from the Internet.
Back-end Interfaces—used by Portal Server to access those resources and to provide the administrative interface.
Customer and Third-Party Software Interface—used by developers to add functionality to the Portal Server system.

Front-end Interface

The front-end interface uses the HTTP or HTTPS protocol with markup languages (such as HTML), JavaScript functions, and Java applets, depending on the application. All of these are standard protocols supported by the most commonly used browser software. When Java applets, which are bundled with Portal Server, are downloaded into the browser, the applets use proprietary protocols layered on top of the protocols listed above to communicate with other components within Portal Server. However, since the applet is considered part of the Portal Server system, that communication happens within the Portal Server system rather than external to it.

Back-end Interfaces

The back-end interfaces provided by Identity Server include:

Enterprise resource access protocols—Mail (for example, SMTP, IMAP4, and LDAP); file access (for example, FTP, NFS, and SMB); web browsing and information services (HTTP and HTTPS); and calendar (rpc.cmsd and IETF calendar protocol). Additional protocols might be used if you add applications to the system.
Administration console protocols—HTTP with HTML and other web languages as described in the front-end interface.

Customer and Third-Party Software Interface

The customer and third-party software interface consists of extension APIs and protocols that are used to extend the Portal Server system. For more information, see the Sun ONE Portal Server 6.2 Developer’s Guide.

Users of the Interfaces

The three classes of human interfaces to the Portal Server system correspond to the three types of people who use it:

End-users—End users interact with the end-user interface, which consists of several web applications that are accessed by a web browser. The Portal Desktop application is the primary portal interface, providing web pages that consist of a collection of channels. Each channel provides an access point into some function or information. Users can configure the set of channels that is displayed and specific characteristics of each channel. Other web applications in the end-user interface provide access to specific resources, such as mail, files, and calendar.
Administrators—Administrators use the Identity Server administration console, and Identity Server and Portal Server command-line utilities, to configure, administer, and maintain the system. A Portal Server system can have many administrators, each delegated with a specific responsibility. Many administrative tasks can be accomplished by using the Identity Server administration console, which is a web application accessed using a web browser. Command-line tools for administration are also available to facilitate scripting and batch execution.
Developers—Developers use the programming APIs to extend the Portal Server system. These APIs provide for developing enterprise resource applications, authentication modules, and Portal Desktop channel providers.

Public Interfaces in Sun ONE Portal Server

Sun™ ONE Portal Server provides public interfaces that developers can use for to extend Portal Server software. See the Sun ONE Portal Server 6.2 Developer’s Guide for information on various APIs.

This section lists exported interfaces and the components they apply to. .

Table 2-1  Portal Server Interfaces - Portal Desktop  

Exported Interface	Description
Portal Desktop Service Definition	Defines the Identity Server configuration attributes for the Portal Desktop service. See the Sun ONE Portal Server 6.2 Administrator’s Guide for more information.
Portal Desktop Display Profile XML DTD	Defines the display configuration for the Portal Desktop by defining provider and channel objects, and their properties. See the Sun ONE Portal Server 6.2 Administrator’s Guide for more information.
Portal Desktop SDK (PAPI)	Supplies provider interfaces, base classes, context, and exceptions. See the Sun ONE Portal Server 6.2 Developer’s Guide for more information.
Leaf Building-Block Providers	Supplies the URLScraper, XML, and JSP providers. See the Sun ONE Portal Server 6.2 Developer’s Guide for more information.
Container Building-Block Providers	Supplies the JSP, single, table, tab, and tab container providers, and exceptions. See the Sun ONE Portal Server 6.2 Developer’s Guide for more information.
Portal Desktop Command-Line Interface	Supplies the dpadmin and par command utilities for product administration. See the Sun ONE Portal Server 6.2 Administrator’s Guidee for more information.
Portal Desktop Graphical User Interface	Provides the primary end-user interface and a mechanism for extensible content aggregation through the Provider Application Programming Interface (PAPI).
Portal Desktop Servlet	Routes client requests for content and processing and passes them on to the specific provider object. See the Portal Server Javadoc™ for more information.
Portal Desktop Template File Format	The Portal Desktop HTML templates were used in Sun ONE Portal Server 3.0 and are included for backward compatibility only. See the Sun ONE Portal Server 6.2 Desktop Customization Guide for more information.
Portal Desktop JSP Tag Libraries	Supplies the tag library descriptor (TLD) files that can be used on any provider or container that implement the PAPI interface, that operate on a provider or container that support the ProviderContext and ContainerProviderContext interfaces, and that operate on specific container providers (SingleContainer, TableContainer, TabContainer). See the Sun ONE Portal Server 6.2 Developer’s Guide for more information.
Portal Desktop Admin Console Module	Supplies the means by which you manage Portal Server services in the Identity Server framework. See the Sun ONE Portal Server 6.2 Administrator’s Guide for more information.

Table 2-2  Portal Server Interfaces - Search

Exported Interface	Description
Search Service Definition	Defines the Identity Server configuration attributes for the Search service. See the Sun ONE Portal Server 6.2 Administrator’s Guide for more information.
Search SDK	Supplies the C API for customizing the way the robot crawls URLs and generates resource descriptions; the Java APIs for searching the database, for submitting data, and for manipulating SOIF objects, such as RDs (RDM and SOIF APIs); and the Search provider tag library and helper beans that enable you to write customized search JSPs. See the Sun ONE Portal Server 6.2 Developer’s Guide for more information.
Search Provider	Supplies the search function using the Portal Server Search Engine.
Search CLI	Supplies the rdmgr, sendrdm, and StartRobot command-line utilities for product administration. See the Sun ONE Portal Server 6.2 Administrator’s Guide for more information.

Table 2-3  Portal Server Interfaces - Rewriter

Exported Interface	Description
Rewriter Service Definition	Defines the Identity Server configuration attributes for the Rewriter service. See the Sun ONE Portal Server 6.2 Administrator’s Guide for more information.
Rewriter Rules XML DTD	See the Sun ONE Portal Server, Secure Remote Access 6.2 Administrator’s Guide for more information.
Rewriter CLI	Supplies the rwadmin command-line utility for product administration. See the Sun ONE Portal Server 6.2 Administrator’s Guide for more information.

---

Portal Server Configuration Files and Directory Structure

This section describes the Sun ONE Portal Server directory structure and properties files used to store configuration and operational data.

Directories Installed for Portal Server

Table 2-4 shows the platform-specific directory structures that are installed for Portal Server.

Table 2-4  Portal Server Directories  

Description	Location
Default installation directory	portal-server-install-root/SUNWps
Default installation directory for configuration information	/etc/portal-server-install-root/SUNWps
Default installation directory for SDK	portal-server-install-root/SUNWps/sdk
Temporary files	/usr/tmp
Debug files	/var/portal-server-install-root/SUNWam/debug
Log files	/var/portal-server-install-root/SUNWam/log /var/portal-server-install-root/SUNWps/instance-directory
Search Engine logging, configuration, and data directories	/var/portal-server-install-root/SUNWps/instance-directory/log-directory
Container and channel display profile	portal-server-install-root/SUNWps/samples/desktop/dp-org.xml
Provider display profile	portal-server-install-root/SUNWps/samples/desktop/dp-providers.xml
HTML template files	/etc/portal-server-install-root/SUNWps/desktop/default/channelname.template
JSP template files	/etc/portal-server-install-root/SUNWps/desktop/default/JSPchannelname
Command-line utilities	portal-server-install-root/SUNWps/bin/
Tag library definitions	/etc/portal-server-install-root/SUNWps/desktop/default/tld/*.tld
Display profile DTD	portal-server-install-root/SUNWps/dtd/psdp.dtd
Java properties files	portal-server-install-root/SUNWam/locale

Configuration Files

All Portal Server configuration data is stored using the Identity Server services management function. Identity Server provides the bootstrap configuration file that is needed to find the directory server.

---

Portal Server Software Deployment

This section provides information on software deployed in Portal Server. It provides information on the software packaging mechanism, the software categories within the system, and the Java compatibility of the software.

Software Packaging

Portal Server uses a “dynamic WAR file” approach to deploy software to the system. Portal Server is installed using Solaris™ packages, which consist of individual files that comprise web applications, for example, JAR, JSP, template, and HTML files. The packages do not contain WAR or EAR files. The packages do contain web.xml fragments that are used to construct the Portal Server WAR file at installation time. This dynamically constructed file is then deployed to the web application container. As additional packages are added to the system, for example, for localization, the web application file is rebuilt and redeployed.

Note	The WAR file packaging and deployment mechanism is for use only by Sun ONE Portal Server products. Customer modifications to the WAR file or any files used to build it are currently not supported.

Software Categories

Portal Server distinguishes between the following kinds of software that it installs onto the Portal Server node:

Dynamic web applications—Includes Java servlets, JSP files, content providers, and other items that the Java web container processes when accessed by the user’s browser. For Portal Server, these files are installed in the web server.
Static web content—Includes static HTML files, images, applet JAR files, and other items that can be served up directly by the web server without using the Java web container. For Portal Server, these files are also installed in the web server.

Note	Static web content and dynamic web applications are all grouped together into a single WAR file.

Configuration data—Includes data that is installed into the directory, that is, the Identity Server service definitions and any other data that modifies the directory at installation time. This includes modifications to the console configuration data to connect in the Portal Server extensions. Configuration data is installed only once no matter how many Portal Server nodes there are.
SDK—This is the JAR file or files that contain the Java APIs that are made available by a component. Developers need to install this package on a development system so that they can compile classes that use the API. If a component does not export any public Java APIs, it would not have this package.

Java Compatibility

Portal Server Java™ software falls into three categories:

Applets
Web applications
Stand-alone Java processes

Applets used in Portal Server are compatible with Java 1.1, which is supported by most browsers.

Web applications are intended to be compatible with the J2EE™ web container based on the servlets interface except where uses of special interfaces are identified. This includes compatibility with Java 2 and later.

Stand-alone Java processes are compatible with Java 2 and later. Some Portal Server software, specifically in SRA, use JNI to call C APIs. These calls are necessary to enable the system to run as the user nobody.

---

Portal Server Desktop

The Portal Desktop is the presentation of the portal. It is the logical component consisting of the Desktop servlet, provider APIs, channels, and various other support APIs and utilities. The Desktop is constructed of a set of channels that can be easily replaced. The Desktop also uses a proprietary templating mechanism used by many Desktop providers to separate static content from compiled Java code.

The Portal Desktop is composed of the following entities:

Content provider—The programmatic entity responsible for the generation of content. Generated content can consist of entire pages, frames, or channels; any markup.
Channel—A unit of content, usually (but not necessarily) arranged in rows and columns. A provider generates a channel.
Display profile—An XML document describing container management and properties for channels.
Portlets—Pluggable web components that process requests and generate content within the context of a portal. In Sun ONE Portal Server software, portlets are managed by the Portlet Container. Conceptually, portlets are equivalent to the Providers.

See the Sun ONE Portal Server 6.2 Administrator’s Guide for Portal Desktop administration tasks. See the Sun ONE Portal Server 6.2 Desktop Customization Guide for tasks on how to customize the Desktop’s look and feel.

User Experience with the Portal Desktop

Figure 2-3 shows a sample of the out-of-the-box Portal Desktop front page from Sun ONE Portal Server 6.2.

Figure 2-3  Portal Server Sample Portal Desktop

After the user is authenticated through the Identity Server Authentication service, the user is directed to the Portal Server Desktop. From there, the user can access a variety of services and applications. These services and applications can be categorized as follows:

Portal Desktop channel applications—Applications based entirely on one or more Portal Server Desktop channels. For example, Portal Server includes a bookmark channel that enables users to save bookmarks and use those bookmarks from any browser that has access to the portal.
Stand-alone web applications—Applications for which the Portal Server Desktop provides a link to the web application. This link helps the user start the application, but there is no application-specific functionality provided on the Desktop itself. An example of this type of application is NetFile in SRA, which provides access to files in intranet file systems.
Web applications with front-end channel—Applications in which Portal Server provides one or more channels as an entry point into the web application. In this context, a web application is any application whose interface is delivered through a web browser, whether it uses HTML, JavaScript functions, Java applets, plugins, or some other markup language.

User Session

Figure 2-4 represents a typical Portal Server user session. Session exit is either by an explicit Portal Desktop log out or by an implicit session time out event. The horizontal line is a Portal Server activity time line. The activities of a single user’s session is represented. Session activities proceed from left to right and are labeled from A to I as follows:

A: User submits request to home page.

B: Portal Server returns the authentication menu.

C: User submits request to authentication module.

D: Portal Server returns authentication form.

E: User submits request login credentials.

F: Portal Server returns initial Desktop display.

G: User submits request to Desktop action.

H: Portal Server returns result of new request.

I: User logs out or exits.

Note	Items B and C are valid only if more than one authentication mechanism is enabled. Most organizations use a single authentication mechanism, and hence will not see the authentication menu.

Figure 2-4  Portal Server Users Session

During this session:

From point A to B, Portal Server processes the user’s request to download Portal Server’s home page.
From point B to C, the user views the result of the request and decides which authentication method to use.
From point C to point D, the server computes and returns the authentication page for the method that the user selected.
From point D to point E, the user, in think mode, enters authentication credentials.
From point E to point F, Portal Server computes and returns the initial Portal Desktop display.
From point F to point G, the user browses sites referenced by the Portal Desktop. To Portal Server, this is equivalent to think time.
From point G to point H, Portal Server executes a new user request.

---

Portal Server Customization

The Sun™ ONE Portal Server user interface is fully customizable and extensible by the customer or third-parties. This section describes the various customizations you can perform on Portal Server.

The methods for customizing Portal Server include:

Modifying the look and feel of the user interface by using JSP and template files
Defining additional content channels using built-in content providers
Writing custom content providers to be used in defining new channels
Writing custom authentication modules
Writing custom service administration modules

Customization is provided through templates (JSP or other template languages) that can be edited to modify branding or other look-and-feel characteristics. Extension is possible through the creation of applications and services that use any of these user interface models.

In addition, you can customize the system by using the capabilities of the underlying components such as Identity Server and the web container. These types of customizations include:

Defining new services, including new data for the directory
Writing custom web applications (servlet, JSP, and EJB™ applications)

See the Sun ONE Portal Server 6.2 Desktop Customization Guide and the Sun ONE Portal Server 6.2 Developer’s Guide for information on how to customize and develop applications for Portal Server. See the Sun ONE Identity Server Programmer’s Guide for information on defining new services and writing custom web applications.

---

Portal Server Availability and Fault Tolerance

Portal Server achieves high availability and fault tolerance through software replication. You can configure Portal Server to run multiple instances of each web application, thereby providing a backup if one of the instances fails. In addition, Portal Server uses Identity Server services for session management and non-local data access. Therefore, the portal system inherits all the benefits and constraints of Identity Server with respect to high availability and fault tolerance. The Identity Server services are either stateless, or they can share context data so that they can recover to the previous state in case of a service failure. See the Identity Server documentation for more information.

Within the Portal Server web applications, state is not shared among instances. This means that a failure causes the application to be restarted. Usually, end users do not notice that this has happened because the state information that is associated with the Portal Server applications can be restored by reading the user’s profile and using information in the request. (This refers to the case where HTTP session replication provided by the application sever is being used, so that re-authentication is not necessary.)

Replication eliminates single points of failure in the system. For Sun ONE Directory Server, this is provided by using a multiple master configuration. However, this solution does not completely address all fault tolerant aspects of the system. A data loss can still occur due to a crash during the process of data synchronization among masters. See the Directory Server documentation for more information.

See Chapter 7, "Creating Your Portal Design", for details on creating your portal design to include high availability.

The high availability features described above are transparent to the client of those services. Portal Server components address high availability natively to different extent. There is a different level of recovery for different components. For details, check the corresponding Portal Server deployment product documentation.

---

Portal Server Security, Encryption, and Authentication

Portal Server system security relies on the HTTPS encryption protocol, in addition to UNIX system security, for protecting the Portal Server system software. The first layer of security is provided by the web container, which you can configure to use SSL if desired. Portal Server also supports SSL for authentication and end-user registration. By enabling SSL certificates on the web server, the Portal Desktop and other web applications can also be accessed securely. You can use the Identity Server policy to enforce URL-based access policy.

The second layer of security is provided by SRA. This product provides a gateway that resides in the DMZ and provides a single secure access point to all intranet URLs and applications. It uses HTTPS by default for connecting the browser to the intranet. The gateway includes a reverse proxy that uses the Rewriter, which enables all intranet web sites to be accessed without exposing them directly to the Internet. The gateway also provides URL-based access policy enforcement without having to modify the web servers being accessed.

Communication from the gateway to the server and intranet resources can be HTTPS or HTTP. Communication within the Portal Server system, for example between web applications and the directory server, does not use encryption by default, but it can be configured to use SSL.

Portal Server depends on the authentication service provided by Identity Server and supports single sign-on (SSO) with any product that also uses the Identity Server SSO mechanism. The SSO mechanism uses encoded cookies to maintain session state.

Previous      Contents      Index      Next

---

Copyright 2003 Sun Microsystems, Inc. All rights reserved.