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.