Chapter 6 Implementation of a Deployment Design
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:
About Implementing Deployment Designs
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.
Documenting the Portal
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.
Tip –
Do not wait until the end of the deployment project, when time and money
are usually running short, to begin this documentation phase. Documenting your portal
should occur as an ongoing activity throughout the entire deployment.
Developing a Portal Prototype
To Develop a Portal Prototype
Steps
-
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 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:
-
Sun JavaTM System Access Manager
-
Portal Desktop
-
Sun JavaTM System Directory Server
-
Sun JavaTM System Virtual Machine
The following sections explain issues in terms of portal performance variables
and provides guidelines for determining portal efficiency.
Access Manager Cache and Sessions
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 amSSO and 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/debug 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.
Note –
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.
Thread Usage
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 Usage Information
Portal Server does not 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. However, you can build a Java servlet that would intercept every Portal
Server Desktop request, extract the SSO token, save the user access information to
a log, then redirect the user to the intended URL. Such a construct would be based
on custom attribute extensions to the Access Manager schema.
Identity and Directory Structure Design
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.
Note –
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.
Creating a Custom Access Manager Service
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 Portal Server 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.
Portal Desktop Design
The performance of Portal Server largely depends upon how fast individual channels
perform. In addition, the user experience of the portal is based upon the speed with
which the Portal Desktop is displayed. The Portal Desktop can only load as fast as
the slowest displayed channel. For example, consider a Portal Desktop composed of
ten channels. If nine channels are rendered in one millisecond but the tenth takes
three seconds, the Portal Desktop does not appear until that tenth channel is processed
by the portal. By making sure that each channel can process a request in the shortest
possible time, you provide a better performing Portal Desktop.
Choosing and Implementing the Correct Aggregration Strategy
The options for implementing portal channels for speed and scalability include:
-
Keeping processing functions on back-end systems and application servers,
not on the portal server. The portal server needs to optimize getting requests from
the user. Push as much business logic processing to the back-end systems. Whenever
possible, use the portal to deliver customized content to the users, not to process
it.
-
Ensuring that the back-end systems are highly scalable and performing.
The Portal Desktop only responds as fast as the servers from which it obtains information
(to be displayed in the channels).
-
Understanding where data is stored when designing providers, how the
portal gets that data, how the provider gets that data, and the type of data. For
example, is the data dynamic that pertains to an individual user, or is there code
needed to retrieve that customized or personalized data? Or, is the data static and
shared by a small group of users? Next, you need to understand where the data resides
(for example, in an XML file, database and flat file), and how frequently the data
is updated. Finally, you need to understand how the business logic is applied for
processing the data, so that the provider can deliver a personalized channel to the
user.
Working with Providers
Consider the following when planning to deploy providers:
-
URLScraperProvider. Typically you
use this provider to access dynamic content that is supplied by another web container’s
web-based system. It uses HTTP and HTTPS calls to retrieve the content. This provider
puts high requirements on the back-end system, as the back-end system has to be highly
scalable and available. Performance needs to be in double-digit milliseconds or hundredths
of milliseconds 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 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 teen 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. 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 JAXP 1.2 JAR files provided by Web Server.
-
LDAP-based provider. This type of provider retrieves information
about a user and use of personalization from user profile. It stays efficient
as long as the number of LDAP attributes stored is low. In general, this type of provider
is a good performer, second only to the file scraper provider within URLScraperProvider.
-
Database provider. This type of provider utilizes a back-end
database for its content. It requires that you build database connection polling and
that you use small queries (either single queries, or no more than a couple). You
might also have to perform extra work for HTML formatting. In general, this type of
provider is the worst performer, due to its use of database connection pooling, large
database queries, poor coding, or lack of indexing on the retrieved data. Additionally,
once the data has been retrieved, the portal needs to perform a large amount of processing
to display the data in the Portal Desktop. If you use this type of provider, push
as much data processing logic to the database as possible. Also, benchmark your portal
performance with and without database channels in the user profile.
Software Deployment
This section provides information on the software packaging mechanism, the software
categories within the system, and compatibility with Java software.
Software Packaging
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.
Note –
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.
Software Categories
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 installed in the Web Server.
-
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 installed in the Web Server.
Note –
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. If a component does not export any public Java APIs, it would not have this package.
Compatibility With Java Software
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 servlets
interface except where uses of special interfaces are identified. This includes compatibility
with Java 2 and later.
-
Stand-alone Java processes. Stand-alone Java software processes are
compatible with Java 2 and later. Some Portal Server software, specifically in SRA,
use JavaTM Native Interface (JNI) to call C application
programming interfaces (APIs). These calls are necessary to enable the system to run
as the user nobody.
Client Support
Portal Server supports the following browsers as clients:
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.
Note –
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 JavaTM 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.
Content and Design Implementation
The Portal Desktop provides the primary end-user interface for Portal Server
and a mechanism for extensible content aggregation through the Provider Application
Programming Interface (PAPI). The Portal Desktop includes a variety of providers that
enable container hierarchy and the basic building blocks for building some types of
channels. For storing content provider and channel data, the Portal Desktop implements
a display profile data storage
mechanism on top of an Access Manager service.
The various techniques you can use for content aggregation include:
-
Creating channels using building block providers
-
Creating channels using JSPProvider>
-
Creating channels using Portal Server tag libraries
-
Creating channels using custom building block providers
-
Organizing content using container channels
See the Sun Java System Portal Server 6 Secure Remote Access 2005Q4 Administration Guide and Sun Java System
Portal Server 7 Developer Sample Guide for more information.
Placement of Static Portal Content
Place your static portal content in the web-container-install-root/SUNWam/public_html directory or in a subdirectory under
the web-container-install-root/SUNWam/public_html directory (the document root for the web container). Do not place your
content in the web-container-install-root/SUNWportal/web-apps/https-server/portal/ directory, as this is a private directory.
Any content here is subject to deletion when the Portal Server web application is
redeployed during a patch or other update.
Integrating Applications
Integrating and deploying applications with Portal Server is one of your most
important deployment tasks. The application types include:
-
Channel. Provides
limited content options; is not a “mini-browser”.
-
Portlet.
Pluggable web component that processes requests and generates content within the context
of a portal. In Portal Server software, a portlet is managed by the Portlet Container.
Conceptually, a portlet is equivalent to a Provider.
-
Portal application. Launched from a channel
in its own browser window; the Portal Server hosts the application; created as an
Access Manager service; accesses Portal and Access Manager APIs.
-
Third-party application. Hosted
separately from Portal Server, but accessed from Portal Server; URL Scraper, which
calls Rewriter, rewrites web pages so that the web pages can be displayed in a channel;
uses Access Manager to enable single sign-on.
Integrating Microsoft Exchange
Using the 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 platform optional package and is also available as part of the Java 2 Enterprise Edition.
JavaMail provides a common uniform API for managing mail. It enables service
providers to provide a standard interface to their standards based or proprietary
messaging systems using Java programming language. Using this API, applications can
access message stores and compose and send messages.
Independent Software Vendors
Listed below are some types of independent software vendor (ISV) integrations.
-
Application user interface. This
integration uses the provider API and SRA for secure access. (SRA is not an integration
type on its own.) Examples include FatWire, Interwoven, SAP, Tarantella, Documentum,
Vignette, PeopleSoft, Siebel, Citrix, and YellowBrix.
-
Security products. This integration
uses the Access Manager Login API to enable portal access by using a custom authentication scheme.
Examples include RSA Security.
-
Content Management. This integration
provides data access into Portal Server, enabling searches on the data. Examples include
FatWire, Interwoven, and Vignette.
-
Content Syndication. This integration
provides managing and customizing information that appears on websites. Examples include
YellowBrix and Pinnacor.
-
Collaboration software. This integration
enables Sun JavaTM 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.
Note –
Portal Server cannot currently integrate another LDAP solution. Access
Manager and Portal Server rely on features not found in other LDAP implementations.
The “depth” to which user interface integration occurs with Portal
Server indicates how complete the integration is. Depth is a term used to describe
the complementary nature of the integration, and points to such items as:
-
Application availability through Portal Server
-
Application availability in secure mode (using SRA, Netlet rules)
-
Ability to use single sign-on
In general, the degree to which an application integrates in Portal
Server can be viewed as follows:
-
Shallow integration. This integration
essentially uses the Portal Server as a launch point. The user logs in to the portal
and clicks a link that starts a web application.
-
Deep integration. The user accesses
the user interface provided by the channels in Portal Server directly. That is, the
integrated software works within the portal. No additional windows or applets appear.
Rolling Out a Production Deployment
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.
Download this book in PDF (915 KB)