|
| |
| Sun Java Enterprise System 2004Q2 Technical Overview | |
Chapter 4
Life-Cycle ConceptsBusiness solutions based on Java Enterprise System software involve a complex set of tasks that can be divided into the three life-cycle stages, shown in Figure 4-1.
This chapter describes the tasks involved in each of these stages, discussing concepts and terminology relevant to each:
Requirements AnalysisIn the requirements analysis stage of the life cycle, you translate an analysis of business needs into a deployment scenario. The deployment scenario serves as a specification for a deployment design.
The requirements analysis stage can be divided into three phases, as shown in Figure 4-1:
- Business analyses. In this phase, you define the business goals of a proposed deployment and state the business requirements and constraints that must be met to achieve that goal.
- Technical requirements. In this phase, you use the results of the business analysis to create use cases that model user interaction with a proposed deployment. You also anticipate usage patterns for those use cases. In addition, you determine quality of service requirements (see Table 2-2) for the proposed deployment, based on the business analysis.
- Logical Design. In this phase, you use the use cases to determine which Java Enterprise System infrastructure components and which custom-developed components are needed to provide end-user services. The use cases and other requirements are the basis for designing a logical architecture. The logical architecture depicts all the distributed components and infrastructure components required of a particular software solution and shows the interactions between those components.
The logical architecture, combined with performance, availability, security, and other quality of service requirements, is encapsulated in your deployment scenario, as shown in the following figure. For more information on the requirements analysis stage of the life cycle, see the Java Enterprise System Deployment Planning White Paper.
Figure 4-2 Requirements Analysis Results in a Deployment Scenario
DeploymentIn the deployment stage of the life cycle, you translate a deployment scenario into a deployment design, which you then implement, prototype, and roll out in a production environment.
The deployment process depends not only on a solution’s logical architecture, but also on performance, availability, security, scalability, serviceability, and other quality of service requirements. In other words, the quality of service dimension of deployment architecture plays a big role in the deployment stage.
The deployment process generally encompasses software components in all the tiers and in all the infrastructure service levels required to support an application. Thus, in addition to any specific distributed application components (J2EE components, web services, or other servers) you might deploy into a physical environment, you must also deploy the Java Enterprise System components (system components) needed to support the application.
In general, the deployment stage is a complex iterative process that involves a number of tasks. This section looks at the following two phases of the process:
Deployment Design
In the deployment design phase, you create a high-level deployment architecture followed by a low-level implementation design:
Deployment Architectures
A deployment architecture is created by mapping the logical building blocks of an application (the logical architecture) to a physical computing environment in a way that meets the quality of service requirements specified in the deployment scenario.
In other words, the deployment scenario is translated into a deployment architecture, as shown in the following figure.
Figure 4-3 A Deployment Scenario Translates into a Deployment Architecture
One aspect of this architectural design is sizing the physical environment to meet performance, availability, security, and other quality of service requirements. Once the sizing has been completed, you assign system servers and application components to the computing nodes in the physical environment. The resulting deployment architecture, must take into account the capabilities of different computing nodes, characteristics of system infrastructure services, and restrictions on the total cost of ownership or total cost of availability.
The larger the number of Java Enterprise System components in the deployment scenario, and the more demanding your quality of service requirements, the more demanding your design is on high-power computing nodes and high network bandwidth. Where hardware is limited, or prohibitively expensive, you might have to make trade-offs between fixed costs (hardware) and variable costs (human resource requirements), or between different quality of service requirements, or you might have to increase the sophistication of your design.
Because designing a deployment architecture is an inexact science, architectures often evolve in an iterative fashion. You incrementally expand an existing system, noting bottlenecks, and adjusting the hardware or modifying the architecture to remove bottlenecks.
As a starting point for deployment design, the Java Enterprise System is developing a set of reference deployment architectures. A reference architecture is based on a specific deployment scenario: a logical architecture with a specific quality of service requirements. In the reference architecture, the application is deployed across a specific physical environment in a way that meets all the quality of service requirements specified in the deployment scenario. Performance testing is based on the same set of use cases from which the deployment scenario was developed.
Based on a reference deployment architecture or a combination of reference architectures, you can design a first approximation of a deployment architecture that meets your own deployment scenario requirements. You can adjust the reference architectures or use them as reference points, taking into account the difference between your own deployment scenario and those upon which the reference architectures are based. In this way, you can assess the impact of your own sizing, performance, security, availability, capacity, and serviceability needs.
Implementation Design.
The implementation design provides details needed to implement the deployment architecture. This includes specifying the actual hardware, operating systems, network structure, and other aspects of a physical environment. The detailed design specification might also include specifying directory information needed for provisioning end users for access to system services.
Deployment Implementation
Deployment implementation starts with an implementation design and consists of the following general tasks:
The ordering of these tasks is not rigid: the deployment process is iterative in nature. Nevertheless, the following subsections discuss each of the major deployment tasks independently, in the order they are normally performed.
Hardware Build-Out
The implementation design specifies the configuration of your physical environment: the computers, network design, network hardware (including cabling, switches, routers, and load balancers), storage devices, and so forth. All this needs to be assembled as the hardware platform that will support your Java Enterprise System-based solution.
Software Installation
The implementation design tells you which application components and which Java Enterprise System components are to reside on each computer node in your physical environment. You can use the Java Enterprise System integrated installer to install the different system components and shared components on each computer.
The installer and its features are described in The Java Enterprise System Integrated Installer.
System Configuration
There are a number of system configuration tasks that you have to complete for the various system components to work together as an integrated system. There are initial configuration steps needed for each individual system component to start up, and these might depend upon first starting up another system component upon which the first depends. For example, the Directory Server must be started before you can configure and start up the Identity Server, which depends upon LDAP schema extensions being written into the directory.
In any case each Java Enterprise System component must be configured to communicate with those components upon which it depends, and then internally configured for the feature set desired. High availability must also be configured, depending on your availability implementation for each component. Users need to be provisioned so they can access various services, and authentication and authorization controls need to be set up.
For information relating to user provisioning, authentication, single sign-on, and authorization, see Integrated Identity and Security Services.
Customization and Development
The logical architecture specified in the deployment scenario generally determines the scope of customization and development work needed to implement a solution.
For some solutions, it might be sufficient to customize existing system servers, such as the Portal Server, to achieve the functionality required. In such cases, you normally do some minimal testing to make sure that your system was configured successfully, before going ahead with customization.
for other solutions, development might be quite extensive, requiring you to develop new business and presentation services from scratch using J2EE components that run in an Application Server or Web Server environment. In such cases it is wise to prototype your solution and perform proof-of-concept testing before embarking on a full development effort.
In the case of solutions requiring extensive development, Java Enterprise System does not provide tools for programming distributed components or business services. These tools are available in Sun Java Studio, which simplifies the programming and testing of applications supported by the Java Enterprise System infrastructure.
Testing
At some point, depending on the degree of customization or development work, you need to verify your deployment architecture. In other words, you need to test the solution against the use cases and verify that you can meet quality of service requirements.
In cases where you have relatively few custom-developed services (a mostly out of the box deployment), you might perform a pilot test of the system. However, if you have developed significant new application logic and created custom services, this testing might be more extensive.
If this testing reveals shortcomings in your deployment architecture, you need to modify the architecture and test again. This iterative process should eventually result in a deployment architecture and implementation that is ready for deployment in a production environment.
Production Rollout
Production rollout involves building out your deployment implementation in a production environment. This phase involves installing, configuring, and starting up distributed applications and infrastructure services in a production environment, provisioning production system end users, setting up single sign-on, access policies, and the like. You normally start with a limited deployment and move to organization-wide implementation. In this process, you perform trial runs, in which you apply increasing loads to confirm that quality of service requirements are being met.
OperationsIn the operations stage of the life cycle, you run a deployed application, monitoring and optimizing its performance and upgrading the application to include new functionality.
Java Enterprise System 2004Q2 does not provide a common monitoring and management infrastructure or administration tools for managing the system as a whole. Each system component has its own administration tools for configuring, tuning, or managing its operations. The goal is to provide system-wide administration for the Java Enterprise System in the future.
