Chapter 1 Overview of Sun ONE Portal Server

The Sun™ ONE Portal Server product is an identity-enabled portal server solution. It provides all the user, policy, and identity management to enforce security, web application single sign-on (SSO), and access capabilities to end user communities. In addition, Portal Server combines key portal services, such as personalization, aggregation, security, integration, and search. Unique capabilities that enable secure remote access to internal resources and applications round out a complete portal platform for deploying robust business-to-employee, business-to-business, and business-to-consumer portals. The Sun™ ONE Portal Server, Secure Remote Access (SRA) product provides additional secure remote access capabilities to access web- and non-web enabled resources.

Portal Server is a component of the Sun Java™ Enterprise System. Sun Java™ Enterprise System is a software system that supports a wide range of enterprise computing needs, such as creating a secure intranet portal to provide the employees of an enterprise with secure access to email and in-house business applications.

Each enterprise assesses its own needs and plans its own deployment of Java Enterprise System. The optimal deployment for each enterprise depends on the types of applications that Java Enterprise System is supporting, the number of users, the kind of hardware that is available, and other considerations of this type.

This chapter describes the basic ideas you need to understand before designing your portal. This chapter contains the following sections:

Understanding Portal Server

To begin understanding Portal Server, and how it fits in your organization, use this section to gather the necessary background information on the Portal Server product and lifecycle.

What Is a Portal?

A portal is an entry point to a set of resources that an enterprise wants to make available to the portal’s users. For some consumer portals, the set of resources includes the entire World-Wide Web. For most enterprise portals, the set of resources includes information, applications, and other resources that are specific to the relationship between the user and the enterprise. For service providers, the portal provides a point of entry to customer service applications as well as a controlled content aggregation service.

Resources can include the use of provider applications and utilities such as mail, file management, and storage facilities.

Overview of a Portal Server 6.2 Deployment

The combination of the above software provides the following capabilities to your organization:

Secure access and authorized connectivity, optionally using encryption between the user’s browser and the enterprise

Authentication of users before allowing access to a set of resources that are specific for each user

Support for abstractions that provide the ability to pull content from a variety of sources and aggregate and personalize it into an output format suitable for the user’s device

A search engine infrastructure to enable intranet content to be organized and accessed from the portal

Ability to store user- and service-specific persistent data

Access to commonly needed applications for accessing services such as mail, calendar, and file storage

An administration interface enabling delegated and remote administration

Examples of How Portal Server 6.2 Satisfies Business Needs

Depending on your organization’s requirements and business needs, your portal deployment will vary. The following section provides a high-level look at how three organizations have deployed Portal Server. Use the information in this section to generate ideas that will help you more effectively deploy Portal Server in your organization.

Business-to-Employee Portal

This multinational company, which manufactures a wide range of products, has hundreds of thousands of employees located around the world, grouped in hundreds of business units. Thus, the company has a highly-distributed computing environment.

Previously, the company relied on a static portal for employee communications, which proved inefficient in meeting its business needs. The company decided to move to a dynamic portal where employees could get personalized access to company information. The portal needed to be configured to support multiple organizations and user roles, and to provide access to internal sites from the company’s intranet.

Table 1-1 summarizes this organization’s goals and presents the Portal Server feature or capability that meets this goal.

Table 1-1 Business-to-Employee Portal Server Example Goals
Goals	Portal Server Feature or Benefit That Meets This Goal
Improve information delivery to the company’s distributed workforce	With technology changing at an ever-increasing speed, the company needed a solution that would facilitate knowledge sharing and collaboration among its employees. Divisions within the company are spread across disparate geographic locations and time zones, and so the portal aggregated content from disparate sources. The portal provided employees with a single point for accessing all their applications, content, and services.
Enable employees to authenticate just once	Portal Server’s single sign-on (SSO) and authentication were implemented with an existing Secure ID infrastructure for security and authentication, both to the portal and other existing internal sites. Users only need sign on one time and are authenticated to all appropriate internal sites and applications.
Improve employee-to-employee communication	By bridging together different sources of information in their native form, workers were able to easily share information and collaborate in real time by using web-based email and calendaring.
Provide a Portal Desktop for a variety of purposes	The Portal Desktop was configured in such a way to use color to indicate channel function (personal, corporate, or business-related). The Portal Desktop also included mandatory channels required for all users, which are not removable by users; default channels, which are automatically selected by an administrator; and available channels, which are created by global or delegated administrators, that users can select from.
Provide for high-availability and reliable access across geographic sites	To meet these requirements, this company developed a portal architecture that included three separate geographic installations, failover between these main locations, and load balancing within each installation. LDAP replicas are placed at each installation, obtaining their information from a master LDAP at the main data center, which is also configured for HA failover.
Implement a centralized administrative model that also enables delegated administration	Identity Server provides role-based delegated administration capabilities to different kinds of administrators to manage organizations, users, policy, roles, channels, and Portal Desktop providers based on the given permissions. For example, within business units, delegated administrators can add or remove channels for their particular line of business.

Business-to-Consumer Portal

This travel company markets various vacation destinations and ancillary businesses, and needed a business-to-consumer portal to help develop a direct relationship with end customers. The portal needed to serve as the mechanism to execute a strategy moving away from travel agencies to a direct consumer relationship.

Table 1-2 summarizes this organization’s goals and presents the Portal Server feature or capability that meets this goal. In this table, the first column gives the goal. The second column describes the Portal Server feature or benefit that meets this goal.

Table 1-2 Business-to-Consumer Portal Server Example Goals
Goals	Portal Server Feature or Benefit That Meets This Goal
Understand customers better to make it easier to do business with them (serve their needs)	Portal Server enabled the consolidation of numerous applications, providing single-point access for both customers and employees. The company saw immediate benefits including strengthened customer service relationships due to this consolidation.
Save money	Because the company was spending large amounts of money on IT, with no slowdown foreseen in the future, the company needed to find a way to lower expenses. The portal provided a single point of system management, helping to reduce the company’s IT complexity and cost. In addition, rather than manage multiple portal projects that might later need to be combined using expensive consulting services that will duplicate effort and infrastructure, Portal Server empowers and enables IT administrators to learn and manage a single platform.
Offer new products or services to customers	Customers access the company’s offerings through a web services portal, which provides access to a broad range of internal and external tools including market research, personalized feeds, pricing and configuration, product data, and presentations. This centralized services portal boosts productivity by giving customers a single point of access for all data, services, and online resources.
Communicate new information consistently and quickly	The portal solution deploys technology that enabled this company to lower operating costs while delivering personalized content to its customers. Users were able to customize their portals to deliver the most important and relevant information to them. The portal also provides extended features (such as customer support) to registered customers.

Internet Service Provider Portal

This company provides a full range of telecommunications services and products, is a leading service provider in its country, and needed to quickly transition from a telephone services company to a communications service provider. In response to new customer demands, as well as strong competitive threats, the company decided to build a solution that would include an affordable Internet access as well as small business services such as fax and email, supplementing and eventually replacing standard telephone services.

The company developed a solution that was a comprehensive, end-to-end portal framework to delivery Internet service and applications.

Table 1-3 summarizes this organization’s goals and presents the Portal Server feature or capability that meets this goal.

Table 1-3 Internet Service Provider Portal Server Example Goals
Goals	Portal Server Feature or Benefit That Meets This Goal
Ease of development	J2EE™, LDAP, and XML standards enabled the organization to leverage existing investments. In addition, Portal Server provided a reliable foundation with integrated transaction management, load balancing, and failover capabilities for the delivery of J2EE-technology-based applications.
Ready adaptability of system components	The flexible design enabled the organization to create a system blueprint, allowing the architecture to be applied to multiple industries and customers.
Scalability and availability of IT architecture	The portal architecture easily scaled both horizontally and vertically without sacrificing performance. The company has the capacity of growing and handling a customer base of hundreds of thousands of subscribers in conjunction with thousands of concurrent users. As the company adds more servers to its infrastructure, it will have the capacity of supporting more than one million users. Other major benefits include availability and reliability. The company is now available 99.99 percent of the time.
Secure Web-enabled transactions	The organization’s assets and confidentiality are protected by transacting vital information securely over the Web.
More intuitive system management	The portal architecture was easy to administer, making it both organized and controllable. The delegated administration feature enabled the service provider to share directory administration with its customers. As a result, customers were able to achieve the flexibility necessary to manage their own directories privately and securely.
Faster time to market	Because there was an integration methodology in place, implementing best-of-breed commercial off-the-shelf products now requires less time, and generates greater return on investment (ROI).

Portal Server Life Cycle

The previous section illustrates an important point in deploying Portal Server, namely the Portal Server product life cycle. In general, any product deployment can be broken down into the following sequence of events, or life cycle:

Planning—In the planning phase, your organization and your Sun ONE representatives work to understand your business and its needs, establish business objectives, and scope and collect requirements.

Developing—In this phase, your organization develops an overall portal design based on the requirements you have established and your deployment estimates.

Designing, Building, and Testing—Once you have arrived at an overall architecture, you can begin designing, building, and testing your portal.

Deploying—In this phase, you install a server instance as a trial and test whether your portal can handle your user load. If the portal is not adequate as it is, you then adjust your design and test the trial again. Adjust your trial design until you have a robust portal that you can confidently introduce to your organization.

Production—Once you have put your portal through a trial run and tuned the portal, you need to develop and execute a plan for taking the portal from trial to production.

Portal Server Resources

JavaServer Pages Technology

To generate the rendered Portal Desktop user interface (what the industry refers to as the “presentation”), Portal Server makes use of either JavaServer Pages™ (JSP™) technology or template files (HTML). JSP technology is preferred because it enables a much easier customization process without having to change the provider Java™ classes. JSP technology also provides a way to enable a strict separation of business and presentation logic. Specifically, this means having the business logic in the provider classes and presentation logic in JSP technology.

In JavaServer Pages technology, actions are elements that can create and access programming language objects and affect the output stream. JSP technology supports reusable modules called custom actions. You invoke a custom action by using a custom tag in a JSP file. A tag library is a collection of custom tags. The Portal Desktop custom tag library contains tags that you use to perform Desktop operations for JSP code.

Before tag libraries, JSP code was difficult to maintain because you were forced to use JavaBeans™ components and scriptlets as the main mechanism for performing tasks. Custom actions, that is, a tag library, alleviate this problem by bringing the benefits of another level of componentization to JSP code. A tag library encapsulates recurring tasks so that they can be reused across more than one application.

See the Sun ONE Portal Server 6.0 Desktop Customization Guide for more information on JSP technology and Portal Server.

Portal Desktop Content

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 through the Identity Server administration console.

The Portal Desktop displays portlets which are pluggable web components that process requests and generate content within the context of a portal. In the Sun ONE Portal Server software, portlets are managed by the Portlet Container. Conceptually, portlets are equivalent to the Providers. Sun ONE portlets are JSR 168 compliant.

Configuration Data

As an Identity Server application, 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 directory service. Server-specific data can be stored in properties files that are local to the specific server.

In addition, Portal Server uses certain files to manage the configuration of the Portal Desktop and Search services. The Portal Desktop configuration file, desktopconfig.properties, defines server-specific parameters.

The Search service uses the following configuration files: classification.conf, filter.conf, filterrules.conf, and robot.conf files. The convert.conf and import.conf files are generated by the Search server. Do not manually edit these files. The search.conf file lists all the specific search values you have set.

At installation time, you are given the option of defining values or using the default values for the base directory (/opt), the deployment URI (/portal) and the deploy instance (cate.sesta.com).

See the Sun ONE Portal Server 6.2 Administrator’s Guide for more information on product configuration files.

Application Data

Portal Server stores certain data in the user’s profile that is passed to back-end applications. For example, the User Preference channel stores NetMail service data (user preferences for using NetMail). Application data also includes Rewriter rulesets.

Site Data

Portal Server uses the local file system to store data specific to a particular instance or node. Site data includes the identity-server-install-root/SUNWam/lib/AMConfig.properties file and the /etc/opt/SUNWps/desktop/desktopconfig.properties file file.

Portal Server, Secure Remote Access

The Portal Server, Secure Remote Access (SRA) offers browser-based secure remote access to portal content and services from any remote browser. SRA is a cost-effective, secure access solution that is accessible to users from any browser enabled with Java technology. SRA eliminates the need for additional client software. Because SRA is integrated with Portal Server, users receive secure encrypted access to the content and services that they have permission to access.

Using SRA, you can install your portal in secure mode. Secure mode provides users with secure remote access to required intranet file systems and applications.

Secure mode uses the SRA gateway, which typically resides in the demilitarized zone (DMZ). The gateway provides a single secure access point to all intranet URLs and applications, thus reducing the number of ports to be opened in the firewall. All other Portal Server services such as Session, Authentication, and the Portal Desktop reside behind the DMZ in the secured intranet. Communication from the client browser to the gateway is encrypted using HTTPS (over Secure Sockets Layer). Communication from the gateway to the server and intranet resources can be either HTTP or HTTPS.

Migrating to a New Version of Portal Server

Migrating from Portal Server 3.0 to Portal Server 6.2 requires a different set of deployment requirements that are outside the scope of this document. Several new features in Portal Server 6.2 require format changes in the data store of Portal Server 3.0 because of the new access layer and Identity Server APIs that Portal Server now uses.

The Portal Server 3.0 Data Migration Tool Suite provided with Portal Server 6.2 enables you to migrate the following:


Note	You can provide secure access to users of web-enabled resources by running Portal Server in open mode with the HTTPS protocol. However, without SRA, you cannot provide secure remote access to file systems or TCP/IP applications.

Independent Software Vendor Integrations with Portal Server

This section provides an overview of some of the independent software vendor (ISV) integrations that exist for Portal Server.

Integration Types

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 Identity Server Login API to enable portal access by using a custom authentication scheme. Examples includes RSA.

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™ ONE Instant Messaging 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 Identity 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 Portal Desktop and provider contents (HNC).

Integratable portal stack—This integration includes products that replace elements of Portal Server. Examples include Identity Server and LDAP.



Note	Portal Server cannot currently integrate another LDAP solution. Identity Server 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:

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

Collaboration and Application Emulation ISVs

Citrix NFuse—Solves access-related problems by delivering a suite of software products and services that provide access to any device, over any network to any application or information source. Portal Server integrates with Citrix’s NFuse through a portal channel, the NFuse provider. NFuse enables web-based access to applications running on MetaFrame servers in a Citrix server farm. Portal Server’s integration works for both open and secure portal modes. The NFuse provider is an icon-based interface with features that can be personalized.

Tarantella—Provides browser-based access to back-end applications via the portal, without any code modifications. Tarantella immediately web-enables UNIX®, Linux, Windows, mainframe, AS/400, and Java applications without rewriting code, changing the architecture, or touching the infrastructure. All of these capabilities can be displayed through Portal Server.

Content and Document Management ISVs

Most portals provide some support for content management. However, in general, analysts agree that portals need to be supplemented by a dedicated content management system (CMS). While portals usually handle content through search and display functions, they generally do not provide for creating and adding portal content. This is where a content management system comes in.

Documentum—Provides automated processes for production, review, approval, and publishing of document assets within an organization. Documentum enables existing applications (for example, ERP/CRM) with enterprise content, managing business critical documentation.

FatWire—As a portal content management system, FatWire Spark pCM installs and runs within the Portal Server system. It provides portlets (channels) for all three content management processes:

CM Home Channel—Provides the business interfaces for creating and managing content with a wide array of data types.

CM Control Center Channel—Provides tools for administrative functions, such as managing users and groups, creating content folders, and selecting workflows.

Content-rich display Channels—SparkpCM is delivered with a selection of portlets for content display. SparkpCM also includes developer interfaces and integration for rapidly building additional portlets (channels) within the portal framework.

Interwoven—Provides content management software and services for the enterprise web. TeamSite from Interwoven is usually installed on separate machines. The providers are installed on the machine hosting Portal Server.

Vignette—Provides content management across multiple web sites, content inheritance by child sites from parent sites, personalization of content, and role- and policy-based access via Portal Server. Provides various prebuilt portlets (channels) for distribution within Portal Server, including:

Vignette Content Contribution Channel—Displays content types that can be created by the authorized user

Vignette Content Inbox Channel—Manages the workflow and tasks assigned to the authorized user, and enables the user to preview the content and manage the content’s status

Vignette Site and Channel Management Channel—Displays the site and channel management console, and enables the user to manage content across multiple sites and multiple channels

Content Syndication ISVs

YellowBrix—Provides authoritative, real time, industry specific information used by global organizations to strengthen business decision making, gain competitive advantage, improve employee productivity, expand customer relationships, identify new opportunities, and drive new revenue streams.

Pinnacor (formerly Screaming Media)—Delivers syndicated content to portal channels, including news stories from nearly 3,000 premium newswires, newspapers, magazine and trade journals, categorized and delivered to your specifications. Pinnacor content providers leverage all the functionality of Portal Server to deliver a high return on your portal investment. Modular content provider offerings deploy rapidly, run efficiently with the existing portal framework, and require minimal maintenance with no additional hardware. Using Pinnacor, you can create a targeted experience with single sign-on and multilevel personalization, without extraneous advertising or link-outs.

Enterprise Applications ISVs

PeopleSoft—The PeopleSoft CRM connector for Portal Server enables portal users to access the PeopleSoft CRM application in Portal Server channels with single sign-on. The PeopleSoft CRM functionality exposed through the connector includes Customer Contact Information management and Opportunity Management.

SAP—The integration with SAP can be achieved by using the Java Connector Architecture (JCA). Several vendors write these connectors (for example, Altio, Insevo). True SSO is not possible at this point since SAP is not Identity Server aware.

Siebel—The Siebel eService and ERM Portal Connectors for Portal Server enable users to access their Siebel ERM (Employee Relationship Management) and eService applications through Portal Server channels.

Personalization, Business Intelligence, and Analysis ISV

Fair, Isaac—Provides an integration module that enables Blaze Advisor to provide rules-based personalization and other services to Portal Server. Using this module, you can take advantage of the Blaze Advisor rule syntax and sophisticated design tools while giving portal administrators and users the power to change their personalization rules using simple web-based interfaces. The scope of the integration is focussed on the following:

Personalization based on the user profile (both internal and external). The internal profile is the profile stored on Portal Server. The external profile is stored as part of some other data store to which the Blaze rules engine and Portal Server have access to. This kind of personalization determines the content to be displayed on individual channels and can also be used to determine the combination of channels to be displayed, based on the user.

Personalization based on preferences of other users with similar profiles or preferences.

Personalization based on the click stream analysis and history of usage.

Rapid Portlet and Web Services Development ISVs

Types of Portal Deployments

Three general types of portals are in use today: business-to-employee (B2E), business-to-consumer (B2C), and business-to-business (B2B). Each type has its own special needs, and Portal Server has features to support each type.

Business-to-Employee Portal (B2E)

B2E portals provide a collection of information and applications from the company’s internal network. These portal services are accessed by employees in their offices as well as by remote, travelling, and telecommuting employees from any web-enabled browser on the Internet. B2E portals include features such as:

Portal Server enables companies to establish secure employee portals using existing enterprise authentication mechanisms and additional one-time password and certificate-based authentication for Internet-based access. Furthermore, Portal Server is capable of presenting employee portals on the intranet using only standard HTTP port 80, and on the Internet using only secure HTTPS on port 443.

Business-to-Consumer Portal (B2C)

B2C portals generally grant access to anyone on the Internet, without using secure authentication and encrypted communication. These portals typically sell products and services to anyone visiting the site. B2C portals often provide extended features (such as customer support) to registered customers, who also might or might not be paying customers. It is well known that the longer a user visits a site the more likely it is for a purchase to be made. Thus, many portals have increased their “stickiness” through the addition of syndicated content that helps to prolong site visits.

The Portal Server architecture enables companies to build B2C portals by extending Sun ONE or third-party commerce applications to customers on any web-enabled browser. Portal Server’s membership management services can be used to help build user communities through self-administered membership modules. Management services can also enforce policy-based access so that enhanced services are only provided to customers who have paid for them. You incorporate applications and content into B2C portals through channels that can be configured both by the hosting company and by individuals. Giving users power to control their portal experience increases the likelihood of return visits. To further increase site stickiness, you can configure search engines and syndicated content (such as news feeds) for user access.

Business-to-Business Portal (B2B)

B2B portals establish extranet connections through which companies and their suppliers and partners can more effectively communicate and collaborate. Suppliers can better match supplies to demand when they have direct access to ERP systems that handle the sales and production process. Consultants can be more effective when they have direct access to engineering specifications and diagrams. And company accountants can more quickly meet tax deadlines when they can get data directly from company accounting systems. Because B2B portals are designed for sharing business-critical information with third parties, security is of paramount importance. B2B portals must provide the means to authenticate the identity of their visitors, and once access is authorized, securely encrypt the data as it passes between the portal and the authorized users.

When used to support B2B portals, Portal Server can be configured to use strong authentication techniques ranging from one-time passwords to unforgeable X.509 certificates. Even before the authentication process is initiated, connections to Portal Server can be encrypted with HTTPS sessions with keys up to 128 bits in length. Once users are authorized, Portal Server can provide access to company information based on the user’s identity, group, or organization. User access can be as fine-grained as is necessary for your site.

Portal Server can provide access to just about any kind of information that business partners need. Access to UNIX and Microsoft Windows applications is provided through Citrix technologies. Applications using Java technology applets and even proprietary protocols can be supported through SRA Netlet software. Terminal emulation is also available, giving partners access to command-line interfaces ranging from standard Telnet to mainframe applications.


Note	Another type of portal that deserves mention is business-to-everyone, usually implemented by carriers and ISPs.


Note	When deploying a B2E portal, you can use SRA to install a gateway, if desired. However, most often a B2E portal is only accessible behind a firewall, so SRA is not required.


Note	Open anonymous mode is a good example of how B2C portals enable non-personalized (non-profiled) access.


Note	Because security is so important for B2B portals, you need to deploy a secure portal running SRA for HTTPS sessions. See Chapter 3, "Sun ONE Portal Server, Secure Remote Access Architecture" for more information.

Portal Deployment Architecture

Usually, but not always, you deploy Portal Server software on the following different portal nodes (servers) that work together to implement the portal:

Portal node—The server upon which you install the Portal Server, Sun ONE Web Server or other web container, and Identity Server software. You can also install the Search component on this node if desired.

Search node—Optional. The server you use for the Portal Server Search component. You can install the Portal Server Search component on its own server for performance, scalability, and availability reasons.

Gateway node—Optional. The server upon which you install the SRA gateway component. You can also install the gateway on the portal node, though in general, because you locate the gateway in the DMZ, it will be on a separate, non-portal node.

Netlet Proxy node—Optional. The node used to run applications securely between users’ remote desktops and the servers running applications on your intranet.

Reverse Proxy node—The server that receives a request, checks the session validity and forwards the request to the server as specified by the HTTP header. Upon receiving a response from the server, the Reverse proxy translates the response so that all intranet links within the response work on the extranet.

Directory server—The server running Sun ONE Directory Server software. You can install Directory Server on a separate node (a non-Portal Server node).

Other servers—These servers, such as mail, file, and legacy servers, provide backend support, data, and applications to portal users.

Figure 1-1 shows the high-level architecture of a typical installation at a company site for a business-to-employee portal. In this figure, the gateway is hosted in the company’s DMZ along with other systems accessible from the Internet, including web servers, proxy/cache servers, and mail gateways. The portal node, portal search node, and directory server, are hosted on the internal network where they have access to systems and services ranging from individual employee desktop systems to legacy systems.


Note	If you are designing an ISP hosting deployment, which hosts separate Portal Server instances for business customers who each want their own portal, contact your Sun ONE representative. Portal Server requires customizations to provide ISP hosting functionality.

In Figure 1-1, users on the Internet access the gateway from a web-enabled browser and connect to the gateway at the IP address and port for the portal they are attempting to access. For example, a B2B portal would usually allow access to only port 443, the HTTPS port. Depending on the authorized use, the gateway forwards requests on to the portal node, or directly to the service access on the enterprise internal network.

Figure 1-1 illustrates some of the components of a portal deployment but does not address the actual physical network design, single points of failure, nor high availability. See Chapter 7, "Creating Your Portal Design", for more detailed information on portal design.

Establishing Quality Goals

When deploying Portal Server, think about the quality goals you want to establish for your organization. Some of these goals might include:

Upgrading all existing Portal Server servers and users to Portal Server 6.2 within a certain timeframe, say 12 months.

If you are upgrading from previous versions of Portal Server, your organization’s IT group must maintain existing portal services during the migration.

Setting performance and reliability expectations. You will need to establish baseline measurements and then continue tracking as you move to a production environment.

Maintaining a completely functioning network infrastructure throughout the transition period from trial to production.

Eliminating single points of failure for the portal system by developing an architecture that includes redundant portal servers, gateways, and directory replicas and masters at various service layers.