During the technical requirements phase of the solution life cycle you perform a usage analysis, identify use cases, and determine quality of service requirements for the proposed deployment solution.
This chapter contains the following sections:
Technical requirements analysis begins with the business requirements documents created during the business analysis phase of the solution life cycle. Using the business analysis as a basis, you do the following:
Perform a usage analysis to aid in determining expected load conditions.
Create use cases that model typical user interaction with the system.
Create a set of quality of service requirements (QoS) that define how a deployed solution must perform in areas such as response time, availability, security, and others.
The quality of service requirements are derived from the usage analysis and the use cases, keeping in mind business requirements and constraints previously identified. The quality of service requirements are later paired with logical architectures in the logical design phase to form a deployment scenario. The deployment scenario is the main input to the deployment design phase of the solution life cycle.
As with business analysis, no simple formula for technical requirements analysis exists that generates the usage analysis, use cases, and system requirements. Technical requirements analysis requires an understanding of the business domain, business objectives, and the underlying system technology.
You need to establish baseline sizing figures that can be used in the logical and architecture and deployment design. Your technical representative can provide you with an automated sizing tool to calculate the estimated number of CPUs your Portal Server deployment requires.
Sizing requirements for a secure portal deployment using Sun JavaTM System Secure Remote Access software are covered in Usage Analysis for Secure Remote Access.
You need to gather the following metrics for input to the sizing tool:
Other performance metrics that affect the number of CPUs a Portal Server deployment requires, but are not used by the sizing tool, are:
Portal Desktop Configuration
Hardware and Applications
Back-end Servers
Transaction Time
Workload Conditions
A discussion of the these performance factors follows.
Maximum number of concurrent sessions defines how many connected users a Portal Server deployment can handle.
To calculate the maximum number of concurrent sessions, use this formula:
maximum number of concurrent sessions = expected percent of users online * user base
To identify the size of the user base or pool of potential users for an enterprise portal, here are some suggestions:
Identify only users who are active. Do not include users who are, for example, away on vacation, or on leave.
Use a finite figure for user base. For an anonymous portal, estimate this number conservatively.
Study access logs.
Identify the geographic locations of your user base.
Remember what your business plan states regarding who your users are.
Average time between page requests is how often, on average, a user requests a page from the Portal Server. Pages could be the initial login page to the portal, or a web site or web pages accessed through the Portal Desktop. A page view is a single call for a single page of information no matter how many items are contained on the page.
Though web server logs record page requests, using the log to calculate the average time between requests on a user basis is not feasible. To calculate the average time between page requests, you would probably need a commercially available statistics tool, such as the WebLoad performance testing tool. You can then use this figure to determine the number of concurrent users.
To perform stress testing, you can use the SLAMD Distributed Load Generation Engine. For more information about SLAMD, see http://slamd2.dev.java.net/.
Page requests more accurately measure web server traffic than “hits.” Every time any file is requested from the web server counts as a hit. A single page call can record many hits, as every item on the page is registered. For example, a page containing 10 graphic files records 11 “hits”—one for the HTML page itself and one for each of the 10 graphic files. For this reason, page requests gives a more accurate determination of web server traffic.
A concurrent user is one connected to a running web browser process and submitting requests to or receiving results of requests from Portal Server. The maximum number of concurrent users is the highest possible number of concurrent users within a predefined period of time. Calculate the maximum number of concurrent users after you calculate the maximum number of concurrent sessions. To calculate the maximum number of concurrent users, use this formula:
concurrent users = number of concurrent sessions / average time between hits
For example, consider an intranet Portal Server example of 50,000 users. The number of connected sessions under its peak loads is estimated to be 80% of its registered user base. On average, a user accesses the Portal Desktop once every 10 minutes.
The calculation for this example is:
40000 / 10 = 4000
The maximum number of concurrent users during the peak hours for this Portal Server site should be 4,000.
Average session time is the time between user login and logout averaged over a number of users. The length of the session time is inversely proportional to the number of logins occurring (that is, the longer the session duration, the fewer logins per second are generated against Portal Server for the same concurrent users base). Session time is the time between user login and user logout.
How the user uses Portal Server often affects average session time. For example, a user session involving interactive applications typically has a longer session time than a user session involving information only.
If your portal site will offer a Search channel, you need to include sizing factors for the Search Engine in your sizing calculations. Search Engine sizing requirements depend on the following factors:
The size of index partitions on the active list of the index directory
Partition size is directly proportional to the size and number of indexed and searchable terms.
Average disk space requirement of a resource description (RD)
To calculate this, use this formula:
average disk space requirement = database size / number of RDs in database
The average size adjusts for variations in sizes of RDs. A collection of long, complex RDs with many indexed terms and a list of short RDs with a few indexed terms require different search times, even if the complex RDs have the same number of RDs.
RDs are stored in a hierarchical database format, where the intrinsic size of the database must be accounted for, even when no RD is stored.
The number of concurrent users who perform search-related activities
To calculate this, use this formula:
number of concurrent users / average time between search hits
Use the number of concurrent users value calculated in Concurrent Users.
The type of search operators used
Types of search functions include basic, combining, proximity, passage and field operator, and wildcard scans. Each function uses different search algorithms and data structures. Because differences in search algorithms and data structures increase as the number of search and indexed terms increase, the type of search function affects times for search result return trips.
If you are using an authenticated portal, you must specify both Login Type and Desktop Type in the page configuration section of the automated sizing tool.
Login Type. Describes the type of portal page (content configuration and delivery method) that end users initially see after submitting user name and password. This process is typically taxing on the system because the process involves checking credentials, initializing the session, and delivering initial content.
The Measured CPU Performance characteristic associated with the Login Type is the Initial Desktop Display variable.
Desktop Type. Describes the type of portal pages (content configuration and delivery method) that end users see after the initial portal page. These pages are displayed with each subsequent interaction with the portal, or on Desktop refresh. Because the session has already been established and cached content can be exploited, less system resources are typically required and the pages are delivered more rapidly.
The Measured CPU Performance characteristic associated with the Desktop Type is the Desktop Reload variable.
For both Login Type and Desktop Type, select the appropriate content configuration:
Light-JSP. Describes a configuration of two tabs with five channels each.
Regular-JSP. Describes a configuration of two tabs with seven channels each.
Heavy-JSP. Describes a configuration of three tabs with seventeen channels each.
You can now give the above figures to your technical representative and ask that the sizing tool be run to identify your estimated number of CPUs.
Portal Desktop configuration explicitly determines the amount of data held in memory on a per-session basis.
The more channels on the Portal Desktop, the bigger data session size, and the less the throughput of Portal Server.
Another factor is how much interactivity the Portal Desktop offers. For example, channel clicks can generate load on Portal Server or on some other external server. If channel selections generate load on Portal Server, a higher user activity profile and higher CPU overhead occur on the node that hosts the Portal Desktop than on a node that hosts some other external server.
CPU speed and size of the virtual machine for the Java platform (Java Virtual Machine or JVMTM software) memory heap affect Portal Server performance.
The faster the CPU speed, the higher the throughput. The JVM memory heap size, along with the heap generations tuning parameters, can also affect Portal Server performance.
Portal Server aggregates content from external sources. If external content providers cannot sustain the necessary bandwidth for Portal Server to operate at full speed, Portal Desktop rendering and throughput request times will not be optimum. The Portal Desktop waits until all channels are completed (or timed out) before it returns the request response to the browser.
Plan your back-end infrastructure carefully when you use channels that do the following:
Scrape their content from external sources
Access corporate databases, which typically have slow response times
Provide email content
Provide calendar content
Transaction time, which is the delay taken for an HTTP or HTTPS operation to complete, aggregates send time, processing time, and response time figures.
You must plan for factors that can affect transaction time. These include:
Network speed and latency. You need to examine latency over a Wide Area Network (WAN). Latency can significantly increase retrieval times for large amounts of data.
The complexity of the Portal Desktop.
The browser’s connection speed.
For example, a response time delay is longer with a connection speed of 33.6 kilobytes per second than with a LAN connection speed. However, processing time should remain constant. Transaction time through a dial-up connection should be faster than transaction time displayed by a load generation tool because it performs data compression.
When you calculate transaction time, size your Portal Server so that processing time under regular or peak load conditions does not exceed your performance requirement threshold and so that you can sustain processing time over time.
Workload conditions are the most predominantly used system and JVM software resources on a system. These conditions largely depend on user behavior and the type of portal you deploy.
The most commonly encountered workload conditions on Portal Server software affect:
Portal Server performance is impacted when a large number of concurrent requests are handled (such as a high activity profile). For example, during peak hours in a business-to-enterprise portal, a significant number of company employees connect to the portal at the same time. Such a scenario creates a CPU-intensive workload. In addition, the ratio of concurrent users to connected users is high.
Portal Server capacity begins to be impacted when large numbers of users log in. As more users login, users use more of the available memory, and subsequently, less memory is available to process requests made to the server. For example, in a business-to-consumer web portal, a large number of logged-in users are redirected to external web sites once the initial Portal Desktop display is loaded. However, as more users continue to login, users create the need for more memory, even though the ratio of users submitting requests to Portal Server and the users merely logged-in is low.
Depending on the user’s behavior at certain times of the day, week, or month, Portal Server can switch between CPU-intensive and memory-intensive workloads. The portal site administrator must determine the most important workload conditions to size and tune the site to meet the enterprise’s business goals.
Use this section only if your organization is implementing a secure portal by installing Secure Remote Access. As you did for portal, for Secure Remote Access, you must first establish your Gateway instances baseline sizing estimate. A single machine can have one Gateway installation but multiple instances. Secure Remote Access enables you to install multiple Gateways, each running multiple instances.) Your design decisions help you make accurate estimates regarding Secure Remote Access user sessions and concurrency.
You must first establish your Gateway instances baseline sizing estimate. This baseline figure represents what you must have to satisfy your Gateway user sessions and concurrency needs.
Establishing an appropriate sizing estimate for your Secure Remote Access deployment is an iterative process. You might wish to change the inputs to generate a range of sizing results. Test these results against your original requirements. You can avoid most performance problems by formulating your requirements correctly and setting realistic expectations of Secure Remote Access performance.
Properly sizing the Gateway is difficult, and using the Gateway sizing tool is only the beginning. Gateway performance depends more on throughput then on the number of users, active users, or user sessions. Any sizing information for the Gateway has to be based on a set of assumptions.
You can choose between one, two, and four CPUs per Gateway instance. The number of CPUs bound to a Gateway instance determines the number of Gateway instances required for the deployment.
If you have numbers from a prototype of the portal with Secure Remote Access, you can use these numbers in the Gateway sizing tool to arrive at more accurate results. You would fill in the following:
Measured CPU Performance. The values used to help calculate the number of Gateway instances include:
Initial Portal Desktop Display, hits per second per CPU
Portal Desktop Reloads, hits per second per CPU
Netlet Applications Block Size. This value specifies the Netlet application byte size. The Netlet dynamically determines the block size based on the application that is used. Block size determined by Netlet for a Telnet is based on the amount of data transferred.
You do not need to specify the Page Configuration and Scalability options if you are using trial deployment numbers.
Key performance factors are metrics that your technical representative uses as input to an automated sizing tool. The sizing tool calculates the estimated number of Gateway instances your Secure Remote Access deployment requires.
Identifying these key performance factors and giving them to your technical representative is the first step in formulating your baseline sizing figure.
These are the key performance factors:
After you calculate these key performance factors, give the figures to your technical representative. Ask that the Gateway sizing tool be run to identify the estimated number of Gateway instances.
The session characteristics of the Gateway include:
Total number of Secure Remote Access (Gateway) users
This represents the size of your user base or pool of potential users for the secure portal..
Expected percentage of total users using the Gateway (at maximum load)
Apply a percentage to your total number of users to determine this figure.
Average time between page hits
This is how often on average a user requests a page from the portal server.
Session average time
This determines how many logins per second that the Gateway must sustain for a given number of concurrent users.
Consider the following Netlet characteristics of the Gateway, which can have a impact on calculating the number of Gateway instances:
Netlet is enabled in the Portal Server administration console.
If Netlet is enabled, the Gateway needs to determine whether the incoming traffic is Netlet traffic or Portal Server traffic. Disabling Netlet reduces this overhead since the Gateway assumes that all incoming traffic is either HTTP or HTTPS traffic. Disable Netlet only if you are sure you do not want to use any remote applications with Portal Server.
Expected percentage of total users using Netlet
Apply a percentage to your total number of users to determine this figure.
Expected throughput
Determine the expected throughput of your Gateway, expressed in kilobits per second (Kbps).
Netlet Cipher (encryption) being used
Choices include Native VM and Java software plugin ciphers.
Use cases are written scenarios used to test and present the system’s capabilities and form an important part of your high-level design. Though you implement use case scenarios toward the end of the project, formulate them early in the project once you have established your requirements.
When available, use cases can provide valuable insight into how the system is to be tested. Use cases are beneficial in identifying how you need to design the user interface from a navigational perspective. When designing use cases, compare them to your requirements to get a thorough view of their completeness and how you are to interpret the test results.
Use cases provide a method for organizing your requirements. Instead of a bulleted list of requirements, you organize them in a way that tells a story of how someone can use the system. This provides for greater completeness and consistency, and also gives you a better understanding of the importance of a requirement from a user perspective.
Use cases help to identify and clarify the functional requirements of the portal. Use cases capture all the different ways a portal would be used, including the set of interactions between the user and the portal as well as the services, tasks, and functions the portal is required to perform.
A use case defines a goal-oriented set of interactions between external actors and the portal system. (Actors are parties outside the system that interact with the system, and can be a class of users, roles users can play, or other systems.)
Use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain.
Use case scenarios are an instance of a use case, representing a single path through the use case. Thus, there may be a scenario for the main flow through the use case and other scenarios for each possible variation of flow through the use case (for example, representing each option).
When developing use cases for your portal, keep the following elements in mind:
Priority. Describes the priority, or ranking of the use case. For example, this could range from high to medium to low.
Context of use. Describes the setting or environment in which the use case occurs.
Scope. Describes the conditions and limitations of the use case.
Primary user. Describes what kind of user this applies to, for example, an end user or an administrator.
Special requirements. Describes any other conditions that apply.
Stakeholders. Describes the people who have a vested interest in how a product decision is made or carried out.
Precondition. Describes the prerequisites that must be met for the use case to occur.
Minimal guarantees. Describes the minimum that must occur if the use case is not successfully completed.
Success guarantees. Describes what happens if the use case is successfully completed.
Trigger. Describes the particular item in the system that causes the event to occur.
Description. Provides a step-by-step account of the use case, from start to finish.
Table 3–1 describes a use case for a portal user to authenticate with the portal.
Table 3–1 Use Case: Authenticate Portal User
To provide a quality of service, address the following topics:
Work with portal system administrators and portal developers to setthe portal performance objectives based on the projected requirements of your portal. Objectives include the number of users, the number of concurrent users at peak load time and their usage pattern in accessing Portal Server.
You need to determine these two factors:
Are you tuning for portal applications rapid response?
Are you tuning for a large number of user concurrency?
As the number of users concurrently connected to the portal increase, the response time decreases given the same hardware and same set of parameters. Hence, gather information about the level of usage expected on your Portal Server, the anticipated number of concurrent users at any given time, the number of Portal Desktop activity requests, the amount of portal channel usage, acceptable response time for the end-user which is determined by your organization, and an optimal hardware configuration to meet the criteria.
Making Portal Server highly available involves ensuring high availability on each of the following components:
Portal Server. In open mode, you can use a load balancer to detect a failed server component and redirect requests to other servers. In secure mode, Gateway components can detect the presence of a failed server component and redirect requests to other servers. (This is valid as long as the web container is the Sun Java System Web Server.)
Gateway. A load balancer used with the Gateway detects a failed Gateway component and routes new requests to other Gateways. A load balancer also has the ability to intelligently distribute the workload across the server pool. Routing is restored when the failed Gateway recovers. Gateway components are stateless (session information is stored on the client in an HTTP cookie) so rerouting around a failed Gateway is transparent to users.
Directory Server. A number of options make the LDAP directory highly available.
Netlet and Rewriter ProxiesIn the case of a software crash, a watchdog process automatically restarts the proxies. In addition, the Gateway performs load balancing and failure detection failover for the proxies.
Scalability is a system’s ability to accommodate a growing user population, without performance degradation, by the addition of processing resources. The two general means of scaling a system are vertical and horizontal scaling. The subject of this section is the application of scaling techniques for the Portal Server.
Benefits of scalable systems include:
Improved response time
Fault tolerance
Manageability
Expendability
Simplified application development
Building modules
In vertical scaling, CPUs, memory, multiple instances of Portal Server, or other resources are added to one machine. This enables more process instances to run simultaneously. In Portal Server, you want to make use of this by planning and sizing to the number of CPUs you need.
In horizontal scaling, machines are added. This also enables multiple simultaneous processing and a distributed work load. In Portal Server, you make use of horizontal scaling because you can run the Portal Server, Directory Server and Access Manager on different nodes. Horizontal scaling can also make use of vertical scaling, by adding more CPUs, for example.
Additionally, you can scale a Portal Server installation horizontally by installing server component instances on multiple machines. Each installed server component instance executes an HTTP process, which listens on a TCP/IP port whose number is determined at installation time. Gateway components use a round-robin algorithm to assign new session requests to server instances. While a session is established, an HTTP cookie, stored on the client, indicates the session server. All subsequent requests go to that server.
The section Designing for Localization, discusses an approach to a specific type of configuration that provides optimum performance and horizontal scalability.
Security is the set of hardware, software, practices, and technologies that protect a server and its users from malicious outsiders. In that regard, security protects against unexpected behavior.
You need to address security globally and include people and processes as well as products and technologies. Unfortunately, too many organizations rely solely on firewall technology as their only security strategy. These organizations do not realize that many attacks come from employees, not outsiders. Therefore, you need to consider additional tools and processes when creating a secure portal environment.
Operating Portal Server in a secure environment involves making certain changes to the SolarisTM Operating Environment, the Gateway and server configuration, the installation of firewalls, and user authentication through Directory Server and SSO through Access Manager. In addition, you can use certificates, SSL encryption, and group and domain access.
Portal Server relies on the HTTPS encryption protocol, in addition to UNIX system security, for protecting the Portal Server system software.
Security is provided by the web container, which you can configure to use SSL, if desired. Portal Server also supports SSL for authentication and end-user registration. By enabling SSL certificates on the web server, the Portal Desktop and other web applications can also be accessed securely. You can use the Access Manager policy to enforce URL-based access policy.
Portal Server depends on the authentication service provided by Access Manager and supports single sign-on (SSO) with any product that also uses the Access Manager SSO mechanism. The SSO mechanism uses encoded cookies to maintain session state.
Another layer of security is provided by Secure Remote Access. It uses HTTPS by default for connecting the client browser to the intranet. The Gateway uses the Rewriter or Proxylet to enable all intranet web sites to be accessed without exposing them directly to the Internet. The Gateway also provides URL-based access policy enforcement without having to modify the web servers being accessed.
Communication from the Gateway to the server and intranet resources can be HTTPS or HTTP. Communication within the Portal Server system, for example between web applications and the directory server, does not use encryption by default, but it can be configured to use SSL.
You can install and configure Portal Server to run under three different UNIX users:
root. This is the default option. All Portal Server components are installed and configured to run as the system superuser. Some security implications arise from this configuration:
An application bug can be exploited to gain root access to the system.
You need root access to modify some of the templates. Root access raises potential security concerns as this responsibility is typically delegated to non-system administrators.
User nobody. You can install Portal Server as the user nobody (uid 60001). This can improve the security of the system, because the user nobody does not have any privileges and cannot create, read, or modify the system files. This feature prevents user nobody from using Portal Server to gain access to system files and break into the system.
The user nobody does not have a password, which prevents a regular user from becoming nobody. Only the superuser can change users without being prompted for a password. Thus, you still need root access to start and stop Portal Server services.
Non-root user. You can run Portal Server as a regular UNIX user. The security benefits of a regular user are similar to the security benefits provided by the user nobody. A regular UNIX user has additional benefits as this type of user can start, stop, and configure services. After installation, you need to change ownership of some files.
See the Sun Java Enterprise System 5 Installation Guide for more information.
While the traditional security UNIX model is typically viewed as all-or-nothing, you can use alternative tools to provide some additional flexibility. These tools provide the mechanisms needed to create a fine grain access control to individual resources, such as different UNIX commands. For example, this toolset enables Portal Server to be run as root, while allowing certain users and roles superuser privileges to start, stop, and maintain the Portal Server framework.
These tools include:
Role-Based Access Control (RBAC). Solaris 8 and higher include the Role-Based Access Control (RBAC) to package superuser privileges and assign them to user accounts. RBAC enables separation of powers, controlled delegation of privileged operations to users, and a variable degree of access control.
Sudo. Sudo is publicly available software that enables a system administrator to give certain users the ability to execute a command as another user. See:
http://www.courtesan.com/sudo/sudo.html
For maximum security, the Gateway is installed between two firewalls. The outermost firewall enables only SSL traffic from the Internet to the Gateways, which then direct traffic to servers on the internal network.
Localization is the process of adapting text and cultural content to a specific audience. Localization can be approached in two different ways:
Localization of the entire product into a language that we don’t provide. This is usually done by a professional service organization.
Localization of parts of Portal Server that can be translated to support localization include:
Template and JSP files
Resource Bundles
Display profile properties
For advanced language localization, create a well-defined directory structure for template directories. To preserve the upgrade path, maintain custom content and code outside of default directories. See the Sun Java System Portal Server 7.1 Developer’s Guide for more information on localization.