The chapter discusses concepts and terminology relevant to each phase of the Java ES solution life cycle. The focus of this chapter is on deployment tasks, particularly deployment design and deployment implementation tasks.
The chapter is organized around the following three groupings of life-cycle phases:
The solution life cycle was introduced in Chapter 1, Introduction to Java Enterprise System as a standard approach to implementing business solutions using Java ES software. This chapter describes the tasks involved in each phase of the life cycle. The life-cycle diagram is repeated in Figure 4–1 for easy reference.
In the predeployment phases 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.
Predeployment tasks are grouped into three phases, as shown in Figure 4–1:
Business analysis. In this phase, you define the business goals of a proposed deployment effort 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 an anticipated software system. You also determine the usage patterns expected for those use cases. Using both the business analysis and the usage analysis, you formulate quality-of-service requirements (see Table 2–2) that the proposed deployment must meet.
Logical design. In this phase, you analyze the use cases developed in the technical requirements phase to determine which Java ES infrastructure components and which custom-developed application components are needed to provide end-user services. Using the concepts discussed in Chapter 2, Java Enterprise System Solution Architectures, you design a logical architecture. The logical architecture shows all the components, and all the interactions between the components, that are needed to effect the use cases of a particular software solution.
The logical architecture, combined with performance, availability, security, and other quality-of-service requirements, is encapsulated in a deployment scenario, as shown in the following figure. For more information on the predeployment phases of the life cycle, see the Sun Java Enterprise System 2005Q4 Deployment Planning Guide.
In the deployment phases of the life cycle, you translate a deployment scenario into a deployment design, which you then implement, test, and roll out in a production environment.
The deployment process generally encompasses software components in all the tiers and in all the infrastructure service levels required to support a software solution. In general, you have to deploy both custom-developed application components (J2EE components, web services, or other servers) and the Java ES components needed to support the solution.
Deployment tasks are grouped into two phases, as shown in Figure 4–1:
Deployment Design. Deployment design depends both on a solution’s logical architecture and on the performance, availability, security, scalability, serviceability, and other quality-of-service requirements a solution must meet. The quality of service dimension of deployment architecture plays a big role in the deployment design phase.
Deployment Implementation. Implementation of a deployment design is an often iterative process that involves hardware setup, software installation and configuration, development and integration, testing, and other aspects of production rollout.
The following sections look more closely at these two phases of the deployment process.
In the deployment design phase, you create a high-level deployment architecture followed by low-level implementation specifications.
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.
The deployment scenario is translated into a deployment architecture, as shown in the following figure.
One aspect of this architectural design is sizing the physical environment (determining the number of computers and estimating their processor power and RAM requirements) to meet performance, availability, security, and other quality-of-service requirements. Once the sizing has been completed, you map Java ES components and application components to the various computers in the physical environment. The resulting deployment architecture must take into account the capabilities of different computers, characteristics of system infrastructure services, and restrictions on the total cost of ownership or total cost of availability.
The larger the number of Java ES components in the deployment scenario, and the more demanding your quality-of-service requirements, the more demanding your design is on high-power computers and high network bandwidth. Where hardware is limited or prohibitively expensive, you might have to assess 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.
The design of a deployment architecture often evolves in an iterative fashion. As a starting point for deployment design, however, 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 specific quality-of-service requirements. In the reference architecture, a software solution is deployed across a specific physical environment in a way that meets specified quality-of-service requirements. Performance testing at specified loads is based on the same set of use cases from which the deployment scenario was developed. Reference architecture documentation is available to Java ES customers under non-disclosure.
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 specifications provide details needed to implement a deployment architecture. The specifications generally include the following information:
Actual hardware, including computers, storage devices, load balancers, and network cabling
Operating systems
Network design, including subnets and security zones
Availability design details
Security design details
Directory design information needed for provisioning end users
Implementation plans describe how you plan to perform the various tasks in the deployment implementation phase. The plans generally cover the following tasks:
Hardware setup
Software installation, upgrade, and migration
System configuration and customization
Development and integration
Testing
Production rollout
Implementation of a deployment design consists of the tasks listed in the previous section and shown in Figure 4–1. The ordering of these tasks is not rigid because the deployment process is iterative in nature. The following subsections discuss each of the major deployment implementation tasks in the order they are normally performed. For detailed documentation of these tasks see the Sun Java Enterprise System 2005Q4 Documentation Roadmap for details.
The implementation specification includes all of the details of your physical environment: the computers, network design, network hardware (including cabling, switches, routers, and load balancers), storage devices, and so forth. All this hardware needs to be set up as the platform that supports your Java ES solution.
The deployment architecture, along with additional details provided in implementation specifications, tells you which application components and which Java ES components are to reside on each computer in your physical environment. You use the Java ES integrated installer to install the appropriate Java ES components on each computer in your deployment architecture (see The Java Enterprise System Integrated Installer).
Your installation plan describes the sequence and scope of installer sessions. The approach you take to performing installation, however, might depend upon whether you are performing a new installation of Java Enterprise System, whether you are upgrading previously installed Java ES components, or whether you are replacing third-party components with Java Enterprise System. The last two of these Java ES adoption scenarios often require you to migrate data or application code to achieve compatibility.
You must complete a number of system configuration tasks for the various system components to work together as an integrated system. First among these tasks is the initial configuration needed for each individual system component to start. Secondly, each Java ES component must be configured to communicate with those components upon which it interacts.
High availability must also be configured, depending on your availability solution for each component. Users need to be provisioned so they can access various services, and authentication and authorization policies and controls need to be set up (see Integrated Identity and Security Services).
In most cases configuration tasks include some degree of customization of Java ES components to achieve the exact feature set you require. For example, you typically customize Portal Server to provide portal channels, Access Manager to perform authorization tasks, and Messaging Server to use virus checking and anti-spam filtering.
The logical architecture specified in the deployment scenario generally determines the scope of custom development work needed to implement a solution.
For some deployments, development might be quite extensive, requiring you to develop new business and presentation services from the beginning using J2EE components that run in an Application Server or Web Server environment. In such cases, you create a prototype of your solution and perform proof-of-concept testing before embarking on a full development effort.
For solutions that require extensive development, Sun Java Studio provides tools for programming distributed components or business services. Sun Java Studio simplifies the programming and testing of applications supported by the Java ES infrastructure.
In some situations, Java ES components might be integrated with legacy applications or third-party services. These integrations might involve existing directories or data services in the data tier or existing components in the business services tier. Integrating Java ES components with these systems might require migrating data or application code.
The J2EE platform provides a connector framework that lets you plug existing applications into the Application Server environment by developing J2EE resource adapters, and Message Queue provides a robust asynchronous messaging capability for integrating diverse applications.
Depending on the amount of customization or development work required, at some point you need to verify your deployment architecture; you need to test the solution against the use cases to verify that you can meet quality-of-service requirements.
If you have relatively few custom-developed services (a mostly out-of-the-box deployment), your solution might simply require customization of Java ES components and 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, involving prototype testing, integration testing, and so forth.
If this testing reveals shortcomings in your deployment architecture, you 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 involves building out your deployment implementation in a production environment. This phase involves installing, configuring, and starting distributed applications and infrastructure services in a production environment, provisioning production system end users, setting up single sign-on and 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.
In the postdeployment stage of the life cycle, you run a deployed solution in a production environment. The following tasks are involved in the operations phase of the life cycle:
Monitoring. These tasks include regular monitoring of system performance and system functions.
Maintenance. These tasks include everyday administrative functions, such as adding new end users to a system, changing passwords, adding new administrative users, changing access privileges, performing regular backups, and so forth.
Performance tuning. These tasks include the use of regular monitoring information to find bottlenecks in system operations and attempting to eliminate those bottlenecks by changing configuration properties, adding capacity, and so forth.
System enhancements and upgrades. These tasks include adding new Java ES components to a system to add new functionality or to replace non-Java ES components. In either case, these changes might require a redesign of the system, beginning with the initial phases of the solution life cycle. Upgrade tasks are more limited, usually amounting to upgrades of Java ES components
Each Java ES component has its own administration tools for configuring, tuning, or managing its operations. The goal is to provide a common monitoring and management infrastructure and administration tools for managing the system as a whole.
This section explains key technical terms used in this chapter, with an emphasis on clarifying the relationships between these terms how they are used in the Java Enterprise System context.
A stage of the Java Enterprise System solution life-cycle process in which a deployment scenario is translated into a deployment design, implemented, prototyped, and rolled out in a production environment. The end product of this process is also referred to as a deployment (or deployed solution).
A logical architecture for a Java Enterprise System solution and the quality-of-service requirements that the solution must satisfy to meet business needs. The quality-of-service requirements include requirement regarding: performance, availability, security, serviceability, and scalability/latent capacity. A deployment scenario is the starting point for deployment design.
A task in the Java Enterprise System solution deployment process, by which the custom components of a deployment architecture are programmed and tested.
A stage of the Java Enterprise System solution life-cycle process in which business needs are translated into a deployment scenario: a logical architecture and a set of quality-of-service requirements that a solution must meet.
A stage of the Java Enterprise System solution life-cycle process in which distributed applications are started up, monitored, tuned to optimize performance, and dynamically upgraded to include new functionality.
A deployment architecture that has been designed, implemented, and tested for performance. Reference deployment architectures are used as starting points for designing deployment architectures for custom solutions.
A specific end-user task or set of tasks performed by a distributed enterprise application, and used as a basis for designing, testing and measuring the performance of the application.