In designing a successful software solution, you must establish the relevant quality-of-service requirements for your business needs. Five important service qualities are used to specify such requirements, as summarized in the following table.
Table 1–2 Reference Configuration Service Qualities
Service Quality |
Description |
---|---|
Performance |
A measure of response time and latency with respect to user load conditions. |
Availability |
A measure of how often a system's resources and services are accessible to end users (the uptime of a system). |
Security |
A complex combination of factors that describe the integrity of a system and its users. Security includes the physical security of computer systems, network security, application and data security (authentication and authorization of users), as well as the secure transport of information. |
Scalability |
The ability to add capacity to a deployed system over time. Scalability typically involves adding resources to the system but should not require changes to the deployment architecture. |
Serviceability |
The ease by which a deployed system can be maintained, including monitoring the system, repairing problems that arise, and upgrading hardware and software components. |
The requirements regarding these service qualities have a big impact on how application and infrastructure components are deployed in a physical environment.
The following sections describe the quality-of-service requirements upon which the Portal Service on Application Server Cluster reference configuration is based:
A portal service is an end-user service, and a fairly high level of performance (an acceptably short response time) is expected. The performance of Sun Java System Portal Server is generally measured by the response time of the standard channels that are available in the default desktop sample. The reference configuration is designed to provide a response time under two seconds for these channels at peak load levels. In a typical deployment, however, response time is dependent upon not only the portal service, but also the back-end applications that it aggregates.
Availability is a crucial requirement for a portal service. In many organizations, the portal is the employee's (or the customer's) gateway to critical information that is aggregated and displayed by the portal service. If the portal services fails, the employee or customer has no other way to access the information needed to conduct business.
Portal services can be classified according to the following levels of availability requirements:
Low availability. This level has no real availability requirements. If the system goes down, it is acceptable to take days to repair it. This level of availability is suitable for software development, unit testing, or demonstration systems.
Service Availability. With this level, the portal service must always be accessible to users, where failures will affect the work of employees or customers.
Session State Availability. In addition to service availability, this level requires that session state is not lost when a user is redirected to another service instance (service failover) when failure occurs. The following are two types of session state availability requirements for portal services:
User Session State Availability. A user is not required to log in again when service failover occurs. In other words, that user session state is preserved in case of a service failure.
Application Session State Availability. A user is not required to restart a business operation when service failover occurs. In other words, the session state of applications that are providing the service is preserved in case of a service failure, and the user will not notice the failure.
The Portal Service on Application Server Cluster reference configuration is designed to provide service availability with both user session state and application session state availability. However, if application session state availability and/or user session state availability are not requirements of your organization, you can choose deployment architecture options that do not include them.
The reference configuration is not designed to sustain the complete failure of a data center. To overcome such failures, the portal service needs to be distributed across multiple locations. This kind of implementation is out of scope for the reference configuration.
The availability of a system should be measured from the user's perspective. Users care about how often a system fails and how long it takes to recover. There is no difference between a system being unavailable due to a systems failure or because of a scheduled maintenance window. Consequently, when measuring availability and when designing a highly available system, both planned and unplanned downtime needs to be considered. The reference configuration is designed to have no single points of failure. If implemented in conjunction with appropriate operational procedures and staffing, the reference configuration should result in less than one hour of unplanned downtime per year (99.99 percent availability).
Portal services deliver varied content to varied users, often over the public Internet. In many cases, the content is confidential and should only be viewed by authorized users. Hence, the following security features are included in the basic feature requirements for portal services:
Authentication of all users, including remote and wireless client access and mobile access
Role-based access control
In addition, a more general set of security requirements is needed to provide secure access to confidential data. These requirements are shown in the following table.
Table 1–3 Security Requirements for Portal Services
The Portal Service on Application Server Cluster reference configuration is designed to support these security requirements.
Most organizations anticipate growth in their user populations and want to know that their portal service can grow along with the size of their user populations.
As a result, no computer system should be more than 80 percent utilized under daily peak load. Also the deployed system should accommodate long-term growth of 10 percent per year.
While there are upper limits to how much any system can scale, due to the increased interactions among its components and the limitations of the network infrastructure, the Portal Service on Application Server Cluster reference configuration is designed to be easily scalable up to these limits.
Because a portal service is normally critical to conducting business, it must be maintained with minimal disruption and downtime.
Common servicing operations include database backups, replacement of applications and system software, upgrades, and other maintenance. Analyzing the solution's requirements for such servicing, and techniques to facilitate the servicing, should be a priority when you design the system.
For example, on an intranet-oriented portal, users are generally most active during the 8:00 a.m. to 5:00 p.m. working hours. This means all system servicing operations can be done after hours. However, if your organization is geographically distributed over multiple time zones, or users need 24–by-7 access to the system, there is no servicing window. Instead, the system needs to be designed so that all maintenance operations can be done with the system in operation or having little impact on the system's availability. In addition to an appropriate deployment architecture, it is necessary to have well-defined and tested operational procedures that ensure minimum downtime.
The Portal Service on Application Server Cluster reference configuration is designed to maximize serviceability, both with respect to scaling the portal service and upgrading software components in the configuration.