Why Use Zones for Java ES?

The isolation provided to applications running in different zones is similar to the isolation provided by running applications in the operating systems of different computers. Hence, instead of installing, configuring, and running Java ES components on different computers in order to isolate and secure them, those components can be installed, configured, or run in different zones within the same computer.

This consolidation of Java ES components can also enable more efficient resource utilization. Java ES components running in dedicated, under-utilized computers, can be run instead in different non-global zones of a single computer. Global administrators can dynamically allocate resources among the different zones depending on the resource requirements of the components running in those zones. (Note this possibility requires more knowledge and understanding of the resource requirements of different components than is generally available at the present time.)

A multi-zone environment can help achieve other objectives as well:

• Version Separation. Parallel sets of Java ES components of different versions can be run in different zones. This allows for migration from one Java ES version to another over a period of time. For example, Java ES Release 4 components in one non-global zone can be run in parallel with Java ES Release 5 components in another non-global zone. To achieve this type of version separation, life-cycle management (as well as configuration and runtime management) is delegated to zone administrators.

• Centralized Life-cycle Management. While not fully supported due to Java ES limitations, zones make it possible to centralize life-cycle management of Java ES components: components can be installed, upgraded, and uninstalled in the global zone but configured and run in a number of non-global zones to provide for runtime isolation, security, scalability, and other needs. Centralization of life-cycle management is advantageous when there are a number of instances of a component running in different zones, or when you want to ensure that such instances are synchronized to the same release version.

  For example, you would be able to install Application Server once in the global zone and run multiple instances in different non-global zones. The various Application Server instances could support Access Manager, Portal Server, or other Java ES components (these can be the same or different components in different non-global zones). Or different Application Server instances could be used by different development teams in different zones.

  To achieve this objective, life-cycle management is performed by a global administrator, while configuration and runtime management is delegated to the respective zone administrators. This approach requires broad coordination when life-cycle management tasks (such as upgrade) are performed.

• Organizational Independence. Different organizations can maintain separate deployments of Java ES components, or separate runtime instances of Java ES components, all coexisting and running on the same computer. For example, different groups of developers can use their own distinct instances of Java ES components, or different organizations can use different deployments of Java ES for testing, pre-production staging, or production. Organizational independence can be achieved in various ways, depending on specific objectives: either by centralizing Java ES life-cycle management while delegating configuration and runtime management to zone administrators, or by delegating all management functions (life-cycle, configuration, and runtime) to zone administrators.

The different objectives you can achieve using Java ES in a multi-zone environment, and the usage scenarios they imply, require different strategies for deploying and administering Java ES components across a multi-zone environment. Some objectives make use of the isolation of different zones to independently manage different Java ES components and their runtime instances, while other objectives make use of the propagation capabilities of the global zone to simplify life-cycle management of Java ES components.

Installation and administration strategies for using Java ES in a multi-zone environment will be revisited after discussing some of the multi-zone environment limitations imposed by the nature of Java ES software.