During the implementation phase of the solution life cycle you work from specifications and plans created during deployment design to build and test the deployment architecture, ultimately rolling out the deployment into production.
Implementation is beyond the scope of this guide, however this chapter describes how to monitor and tune a deployment prototype.
This chapter contains the following sections:
After the deployment architecture has been approved and implementation specifications and plans have been completed, you enter the implementation phase of the solution life cycle. Implementation is a complex set of processes and procedures that requires careful planning to ensure success.
Implementation includes the following tasks:
Building the network and hardware infrastructure
Installing and configuring software according to an installation plan
Migrating data from existing applications to the current solution
Implementing a user management plan
Designing and deploying pilots or prototypes in a test environment according to a test plan
Designing and running functional tests and stress tests according to a test plan
Rolling out the solution from a test environment to a production environment according to a rollout plan
Training administrators and users of the deployment according to a training plan
Details of implementation are beyond the scope of this guide. However, the following sections provide overview information for some of these tasks.
A comprehensive set of documentation on how your portal functions is an important mechanism to increasing the supportability of the system. The different areas that need to be documented to create a supportable solution include:
System architecture
Software installation and configuration
Operational procedures, also known as a “run book”
Software customizations
Custom code
Third-party products integration
The run book outlines troubleshooting techniques as well as the deployment life cycle. Make this book available during the training and transfer of knowledge phase of the project.
Do not wait until the end of the deployment project to begin this documentation phase. Documenting your portal should occur as an ongoing activity throughout the entire deployment.
Identify and remove obvious bottlenecks in the processor, memory, network, and disk.
Setup a controlled environment to minimize the margin of error (defined as less than ten percent variation between identical runs).
By knowing the starting data measurement baseline, you can measure the differences in data performance between sample gathering runs. Be sure measurements are taken over an adequate period of time and that you are able to capture and evaluate the results of these tests.
Plan to have a dedicated machine for generating load simulation which is separate from the Portal Server machine. A dedicated machine helps you to uncover the origin of performance problems.
Define a baseline performance for your deployment, before you add in the full complexity of the project.
Using this initial benchmark, define the transaction volume your organization is committed to supporting in the short term and in the long run.
Determine whether your current physical infrastructure is capable of supporting the transaction volume requirement you have defined.
Identify services that are the first to max out as you increase the activity to the portal. This indicates the amount of headroom you have as well as identify where to expend your energies.
Develop and refine the prototype workload that closely simulates the anticipated production environment agreed between you and the portal administrators and portal developers.
Measure and monitor your traffic regularly to verify your prototype.
Track CPU utilization over time. Load usually comes in spikes and keeping ahead of spikes involves a careful assessment of availability capabilities.
Most organizations find that portal sites are “sticky” in nature. This means that site usage grows over time, even when the size of the user community is fixed, as users become more comfortable with the site. When the size of the user community also grows over time a successful portal site can see a substantial growth in the CPU requirements over a short period of time.
When monitoring a portal server’s CPU utilization, determine the average web page latency during peak load and how that differs from the average latency.
Expect peak loads to be four to eight times higher than the average load, but over short periods of time.
Use the model for long-range scenario planning. The prototype can help you understand how dramatically you need to change your deployment to meet your overall growth projections for upcoming years.
Keep the error logging level to ERROR and not MESSAGE. The MESSAGE error level is verbose and can cause the file system to quickly run out of disk space. The ERROR level logs all error conditions and exceptions.
Monitor customized portal applications such as portlets.
Monitor the following areas.
Portal Desktop
Channel rendering time
Sun JavaTM System Access Manager
Sun Java System Directory Server
Sun Java System Virtual Machine
Web container
The following sections explain issues in terms of portal performance variables and provides guidelines for determining portal efficiency.
The performance of a portal system is affected to a large extent by the cache hit ratio of the Access Manager cache. This cache is highly tunable, but a trade-off exists between memory used by this cache and the available memory in the rest of the heap.
You can enable the amSDKStats logs to monitor the number of active sessions on the server and the efficiency of the Directory Server cache. These logs are located by default in the /var/opt/SUNWam/stats directory. Use the com.iplanet.am.stats.interval parameter to set the logging interval. Do not use a value less than five (5) seconds. Values of 30 to 60 seconds give good output without impacting performance.
The com.iplanet.services.stats.directory parameter specifies the log location, whether to a file or to the Portal Server administration console, and also is used to turn off the logs. You must restart the server for changes to take effect. Logs are not created until the system detects activity.
Multiple web container instances write logs to the same file.
The cache hit ratio displayed in the amSDKStats file gives both an internal value and an overall value since the server was started. Once a user logs in, the user’s session information remains in cache indefinitely or until the cache is filled up. When the cache is full, oldest entries are removed first. If the server has not needed to remove a user’s entry, it might be the case that on a subsequent login—days later, for example—the user’s information is retrieved from the cache. Much better performance occurs with high hit ratios. A hit ratio of a minimum of 80 percent is a good target although (if possible) an even higher ratio is desired.
Use the web container tools to monitor the number of threads being used to service requests. In general, the number of threads actually used is generally lower than many estimates, especially in production sites where CPU utilization usually is far less than 100 percent.
Portal Server does include a built-in reporting mechanism to monitor portal usage information by portal users. This includes which channels are accessed, how long the channels are accessed, and the ability to build a user behavioral pattern of the portal. Portal monitoring can be administered using the psconsole or cli psadmin. The following monitoring capabilities are possible:
Managed Desktop Services:
Content Request
Edit Request
Process Request
Logout Request
Services exposed
cumulatively
per channel
Each service has set of attributes
Service Attributes:
Name Count
Last Service Time
Maximum Service Time
Minimum Service Time
Average Service Time
User Based Tracking (UBT) is also administered using the psconsole or cli psadmin. UBT is disabled by default. To enable user based tracking, set property com.sun.portal.ubt.enable=true in file /var/opt/SUNWportal/portals/portal1/config. The level INFO, FINE, FINER, FINEST, OFF controls extent of data captured. Logs are routed to a file: /var/opt/SUNWportal/portals/portal1/logs/%instance/ubt.%u.%g.log which is configurable.
A major part of implementing your portal involves designing your directory information tree (DIT). The DIT organizes your users, organizations, suborganizations into a logical or hierarchical structure that enables you to efficiently administer and assign appropriate access to users.
The top of the organization tree in Access Manager is called dc=fully-qualified-domain-name by default, but can be changed or specified at install time. Additional organizations can be created after installation to manage separate enterprises. All created organizations fall beneath the top-level organization. Within these suborganizations other suborganizations can be nested. The depth of the nested structure is not limited.
The top of the tree does not have to be called dc. Your organization can change this to fit its needs. However, when a tree is organized with a generic top, for example, dc, then organizations within the tree can share roles.
Roles are a grouping mechanism designed to be more efficient and easier to use for applications. Each role has members, or entries that possess the role. As with groups, you can specify role members either explicitly or dynamically.
The roles mechanism automatically generates the nsRole attribute containing the distinguished name (DN) of all role definitions in which the entry is a member. Each role contains a privilege or set of privileges that can be granted to a user or users. Multiple roles can be assigned to a single user.
The privileges for a role are defined in Access Control Instructions (ACIs). Portal Server includes several predefined roles. The Portal Server administration console enables you to edit a role’s ACI to assign access privileges within the Directory Information Tree. Built-in examples include SuperAdmin Role and TopLevelHelpDeskAdmin roles. You can create other roles that can be shared across organizations.
Service Management in Access Manager provides a mechanism for you to define, integrate, and manage groups of attributes as an Access Manager service.
Readying a service for management involves:
Creating an XML service file
Configuring an LDIF file with any new object classes and importing both the XML service file and the new LDIF schema into Directory Service
Registering multiple services to organizations or sub-organizations using the Access Manager administration console
Managing and customizing the attributes (once registered) on a per organization basis
See the Sun Java System Portal Server 6 Secure Remote Access 2005Q4 Administration Guide, Sun Java System Directory Server Enterprise Edition 6 2006Q1 Deployment Planning Guide and the Access Manager Deployment Guide for more information on planning your Access Manager and Directory Server structure.
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.
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.
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 PagesTM (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).
This section provides information on the software packaging mechanism, the software categories within the system, and compatibility with Java software.
Portal Server uses a “dynamic WAR file” approach to deploy software to the system. Portal Server is installed using SolarisTM 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.
The WAR file packaging and deployment mechanism is for use only by Portal Server products. Customer modifications to the WAR file or any files used to build it are currently not supported.
Portal Server distinguishes between the following kinds of software that it installs onto the Portal Server node:
Dynamic web applications. These include servlets running on a Java platform, JSP files, content providers, and other items that the web container processes when accessed by the user’s browser. For Portal Server, these files are deployed in the web container directory structure.
Static web content. These include static HTML files, images, applet JAR files, and other items that can be served up directly by the web server without using the Web Server container. For Portal Server, these files are also deployed in the web container directory structure.
Static web content and dynamic web applications are all grouped together into a single WAR file.
Configuration data. These include data that is installed into the directory, that is, the Access Manager 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.
Software Development Kit (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. The portal sdk files are located under the directory /opt/SUNWportal/sdk. The desktop subdirectory contains the desktopsdk.jar file required when building custom providers. The wsrp sub-directory contains the wsrpsdk.jar file.
Portal Server software falls into three categories:
Applets. Applets used in Portal Server are compatible with Java 1.1, which is supported by most browsers.
Web applications. Web applications are intended to be compatible with the (J2EETM) web container based on the servlet's interface except where uses of special interfaces are identified. Web application compatibility includes Java 2 (J2SE 1.3) and later.
Stand-alone Java processes. Stand-alone Java software processes are compatible with Java 2 and later. Some Portal Server software, specifically in Secure Remote Access, use Java Native Interface (JNI) to call C application programming interfaces (APIs).
Portal Server supports the following browsers as clients:
Netscape 7.1 or higher
Mozilla 1.7.12 or higher
Firefox 1.0.7 or higher
Multiple client types, whether based on HTML, WML, or other protocols, can access Access Manager and hence Portal Server. For this functionality to work, Access Manager uses the Client Detection service (client detection API) to detect the client type that is accessing the portal. The client type is then used to select the portal template and JSP files and the character encoding that is used for output.
Currently, Access Manager defines client data only for supported HTML client browsers, including Internet Explorer and Netscape Communicator. See the Access Manager documentation for more information.
Sun Java System Portal Server Mobile Access software extends the services and capabilities of the Portal Server platform to mobile devices and provides a framework for voice access. The software enables portal site users to obtain the same content that they access using HTML browsers.
Mobile Access software supports mobile markup languages, including xHTML, cHTML, HDML, HTML, and WML. It can support any mobile device that is connected to a wireless network through a LAN or WAN using either the HTTP or HTTPS protocol. In fact, the Portal Server Mobile Access software could support any number of devices, including automobiles, set-top boxes, PDAs, cellular phones, and voice.
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
See the Sun Java System Portal Server 7.1 Secure Remote Access Administration Guide and Sun Java System Portal Server 7.1 Developer Sample Guide for more information.
Place your static portal content in the web-container-instance-root/ https-server/docs directory or in a subdirectory under the web-container-instance-root/directory/https-server/docs (the document root for the web container). Do not place your content in the web-container-instance-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 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.
Using the JavaMailTM 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 optional package that can be used on JDK 1.4 and later on any operating system. The JavaMail API is also a required part of the Java Platform, Enterprise Edition (Java EE).
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.
Listed below are some types of independent software vendor (ISV) integrations.
Application user interface.. This integration uses the provider API and Secure Remote Access for secure access. (Secure Remote Access 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 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 7.1 is reliant on using the amsdk. Limited Realm Mode support is possible, however by default portal 7.1 will install in legacy mode. Sun One Java Directory Server 6 is supported and any LDAPv3 directory server.
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 Secure Remote Access, 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.
Once the pilot or proof-of-concept deployment passes the test criteria, you are ready to roll out the deployment to a production environment. Typically, you roll out to a production environment in stages. A staged rollout is especially important for large deployments that affect a significant number of users.
The staged deployment can start with a small set of users and eventually expand the user base until the deployment is available to all users. A staged deployment can also start with a limited set of services and eventually phase in the remaining services. Staging services in phases can help isolate, identify, and resolve problems a service might encounter in a production environment.