Zones Limitations of Java ES Components

Java ES components are grouped into different types, as described in Sun Java Enterprise System 5 Technical Overview. Accordingly, system service components provide the main Java ES infrastructure services, while service quality components enhance those system services. These two types of Java ES components are together referred to here as product components, components that are selectable within the Java ES installer.

Each product component depends on one or more locally shared libraries known as Java ES shared components. Shared components are installed automatically by the Java ES installer during product component installation, depending on the product components that are being installed. They are not individually selected, installed, or configured during deployment of Java ES product components.

Java ES Shared Components and Zones

The discussion in Why Use Zones for Java ES? focused on the use of zones by Java ES product components: those that can be explicitly selected in the Java ES installer and installed and configured in various zones to achieve a desired deployment architecture and functional capability. However, the shared components upon which product components depend set a number of limitations on how Java ES is deployed in a multi-zone environment. There are two issues regarding Java ES shared components and zones:

Synchronization of Shared Components

The difficulty of testing and supporting the large number (around 30) and complex interactions between Java ES shared components and Java ES product components mandates that all shared components within a single operating system instance be synchronized to the same Java ES version. In other words, all Java ES shared components installed in a non-zone environment, or in any single zone within a Solaris 10 environment, must be of the same version. This requirement sets certain restrictions on how Java ES can be used in a multi-zone environment.

This synchronization requirement has the following implications:

• Different versions of Java ES shared components can only reside in different zones. For example, you can install Java ES Release 4 shared components in one zone and Java ES Release 5 shared components in another zone, but you cannot combine them in the same zone.

• If any shared component in a zone is upgraded or any new shared component of higher version is introduced, then all shared components in that zone must also be upgraded at the same time. (Shared components are required to be backwardly compatible, so there is no problem for Release 4 product components to work with Release 5 shared components.) For example, suppose a Release 5 product component is installed in a zone in which one or more Release 4 product components reside. Because the Release 5 product component requires some number of Release 5 shared components, the synchronization requirement means that all Release 4 shared components residing in that zone must be upgraded to Release 5 at the same time the Release 5 product component is installed. This is the case even if the Release 5 product component being installed requires different shared components from those that are already installed in the zone.

• When shared components are installed in and propagate from the global zone (see Java ES Propagation Policies), then special care must be taken to maintain synchronization of shared components in all zones. Otherwise it would be possible for shared components of an earlier version in a non-global zone to be mixed with Release 5 shared components that have been propagated from the global zone. (Special care normally means that shared component life-cycle management takes place only in the global zone. For more information see Table A–2, and Shared Component Special Cases.)

The shared component synchronization requirement imposes restrictions on what the Java ES installer is constrained to do in a multi-zone environment (for more information, see Zone Support in the Java ES Installer) and also impacts procedures for installing and upgrading Java ES product components in a multi-zone environment.

Shared Components and Sparse Root Zones

Another issue impacting the use of Java ES in a multi-zone environment is that a large number of shared components cannot be installed in sparse root zones because of the read-only file systems in sparse root zones. Hence, those shared components whose base directory is /usr (a directory that by default is shared by the global zone) must be installed in the global zone to be available in a sparse root zone.

The inability to install a number of Java ES shared components in sparse root zones means that to successfully install product components which have dependencies on such shared components into sparse root zones, the shared components must first be installed in the global zone and propagated to non-global zones.

Java ES Product Components and Zones

Some of the objectives discussed in Why Use Zones for Java ES? for using Java ES in a multi-zone environment, and the usage scenarios they imply, make use of the propagation capabilities of the global zone to simplify life-cycle management of Java ES product components. Such usage scenarios, for example, call for life-cycle management of Java ES product components to be performed in the global zone by the global administrator, while the configuration and runtime management of those components is performed in non-global zones by zone administrators.

In other words, product components would be installed and upgraded in the global zone, but instances would be configured and run in non-global zones. This usage scenario would combine the benefits of centralized life-cycle management with the isolation and security afforded by non-global zones.

This scenario, however, depends upon the ability of each product component to be installed in the global zone, but be configured and run in a non-global zone. This separation depends upon how configuration of each product component is achieved, where configuration and dynamic application data is stored, how configuration data is located by executing binaries, and how upgrades are performed. For example separation might depend upon what pre or post install or upgrade scripts do: whether they start or stop component instances, set up links to configuration data, or perform other tasks that blur the distinction between life-cycle and configuration management.

This separation can also depend upon whether configuration is performed in a whole root or sparse root zone. For example, if a product component's configuration script writes to a read-only file system in a sparse root zone (for example /usr) or if non-default file systems (such as /opt) are shared with a sparse root zone, then the configuration of a component can fail.

Nearly all Java ES product components are installed under /opt, which by default, is writable in sparse root zones. For more information, see Sun Java Enterprise System 5 Installation Reference for UNIX

At the current time, the ability of each of the roughly 20 Java ES product components to support the separation of life-cycle management and configuration/runtime management between global and non-global zones has not been established. The various product components have adopted different approaches to configuration and upgrade. Given this situation, propagation of Java ES product components (except for Message Queue) is not currently supported. For more information, see Java ES Propagation Policies.