Los componentes de Java ES están agrupados en tipos diferentes, tal como se describe en Descripción general técnica de Sun Java Enterprise System 5. Los componentes de servicio de sistema proporcionan la infraestructura básica de servicios de Java ES, mientras que los componentes de calidad de servicio mejoran dichos servicios de sistema. Estos dos tipos de componentes Java ES son conocidos como componentes de producto, componentes seleccionables con el instalador de Java ES.
Cada componente de producto depende de una o más bibliotecas compartidas conocidas como componentes compartidos Java ES. Los componentes compartidos los instala automáticamente el instalador de Java ES durante la instalación de componentes del producto, según los componentes del producto que se estén instalando. No se seleccionan, instalan o configuran uno por uno durante la implementación de componentes de producto Java ES.
El debate de la sección ¿Por qué utilizar zonas para Java ES? se centra en el uso de zonas por componentes del producto de Java ES: los que se pueden seleccionar de forma explícita en el instalador de Java ES e instalarse y configurarse en varias zonas para obtener la arquitectura de implementación y capacidad funcional deseada. Sin embargo, los componentes compartidos en los que los componentes del producto dependen establecen una serie de limitaciones sobre cómo se implementa Java ES en un entorno de varias zonas. Existen dos problemas relacionados con los componentes compartidos de Java ES y las zonas:
La dificultad de poner a prueba y admitir el alto número (unos 30) de componentes y las interacciones complejas entre componentes compartidos de Java ES y los componentes de producto Java ES hace que sea necesario que todos los componentes compartidos dentro de una misma instancia del sistema operativo se tengan que sincronizar con la misma versión de Java ES. En otras palabras, todos los componentes compartidos de Java ES instalados en un entorno que no sea de zonas o en una sola zona de un entorno Solaris 10 tienen que ser de la misma versión. Este requisito pone ciertos límites a cómo se puede utilizar Java ES en un entorno de varias zonas.
El requisito de sincronización implica lo siguiente:
Las diferentes versiones de los componentes compartidos de Java ES sólo pueden residir en diferentes zonas. Por ejemplo, puede instalar componentes compartidos Java ES versión 4 en una zona y componentes compartidos Java ES versión 5 en otra zona, pero no podrá combinarlos en la misma zona.
Si se actualiza un componente compartido en una zona o se introduce un componente compartido nuevo de una versión más reciente, entonces todos los componentes de la zona deberán actualizarse a la vez. (Es necesario que los componentes compartidos sean compatibles con versiones anteriores, de forma que los componentes de producto de la versión 4 funcionen con los componentes compartidos de la versión 5.) Por ejemplo, supongamos que un componente de producto de la versión 5 se instala en una zona donde residen uno o más componentes de producto de la versión 4. Como el componente de producto de la versión 5 requiere una serie de componentes compartidos de la versión 5, el requisito de sincronización significa que todos los componentes compartidos de la versión 4 que residan en dicha zona se tendrán que actualizar a la versión 5 cuando se instale el componente de producto de la versión 5. Esto es así aunque el componente de producto de la versión 5 que se esté instalando requiera diferentes componentes compartidos de los que ya están instalados en la zona.
Cuando se instalan componentes compartidos en la zona global y se propagan desde la misma (consulte la sección Reglas de propagación de Java ES), debe tenerse especial cuidado en el mantenimiento de la sincronización de componentes compartidos en todas las zonas. En caso contrario, existe la posibilidad que componentes compartidos de una versión anterior de una zona no global se entremezclen con los componentes compartidos de la versión 5 que se han propagado desde la zona global. (Especial cuidado no significa que la administración del ciclo de vida de los componentes tenga lugar únicamente en la zona global. Para otener más información, consulte la Tabla A–2 y Casos especiales de componentes compartidos..)
El requisito de sincronización de componentes compartidos impone restricciones sobre qué limitaciones tiene el instalador de Java ES en un entorno de varias zonas (para obtener más información, consulte Compatibilidad de zonas en el instalador de Java ES) y afecta también a los procedimientos para instalar y actualizar componentes de producto de Java ES en un entorno de varias zonas.
Otro problema que afecta el uso de Java ES en un entorno de varias zonas es que no se puede instalar un número elevado de componentes compartidos en zonas de poca raíz debido a los sistemas de archivos de sólo lectura de las zonas de poca raíz. Así los componentes compartidos cuyo directorio base es /usr (un directorio que, de manera predeterminada, se comparte en la zona global) deben instalarse en la zona global para que estén disponibles en una zona de poca raíz.
La incapacidad de instalar varios componentes compartidos Java ES en zonas de poca raíz significa que para poder instalar correctamente componentes de producto con dependencias en componentes compartidos de este tipo en zonas de poca raíz, los componentes compartidos se deben instalar primero en la zona global y posteriormente propagarlos hacia las zonas no globales.
Algunos de los objetivos tratados en ¿Por qué utilizar zonas para Java ES? sobre el uso de Java ES en un entorno de varias zonas y los casos de uso que suponen hacen uso de las capacidades de propagación de la zona global para simplificar la gestión de los ciclos de vida de los componentes de producto de Java ES. Estos casos de uso, por ejemplo, requieren que la gestión de ciclos de vida de los componentes de producto de Java ES las realice el administrador global en la zona global, mientras que la gestión de la configuración y del tiempo de ejecución de dichos componentes las realizan los administradores de zona en las zonas no globales.
En otras palabras, los componentes de producto se instalarían y actualizarían en la zona global, pero las instancias se configuran y ejecutan en zonas no globales. Este caso de uso combinaría las ventajas de una gestión centralizada de los ciclos de vida con las ventajas del aislamiento y seguridad que proporcionan las zonas no globales.
Este caso, sin embargo, depende de la capacidad que tiene cada componente de producto de instalarse en la zona global y de poderse configurar y ejecutar en una zona no global. Esta separación depende de cómo se obtiene la configuración de cada componente de producto, dónde se almacenan los datos de configuración y datos dinámicos de aplicación, cómo se buscan los datos de configuración mediante la ejecución de archivos ejecutables y cómo se llevan a cabo las actualizaciones. Por ejemplo, la separación puede depender de qué hacen las secuencias de comandos de preinstalación y postinstalación: si inician o detienen instancias de componentes, si establecen enlaces a datos de configuración o realizan otras tareas que atenúan la diferencia entre gestión de ciclos de vida y gestión de configuración.
Esta separación también puede depender de si la configuración se realiza en una zona de raíz completa o en una zona de poca raíz. Por ejemplo, si una secuencia de comandos de configuración de componentes de producto graba en un sistema de archivos de sólo lectura de una zona de poca raíz (por ejemplo /usr) o si los sistemas de archivos no predeterminados (como /opt) están compartidos con una zona de poca raíz, entonces la configuración de un componente puede fallar.
Casi todos los componentes de producto de Java ES se instalan en /opt , que de forma predeterminada, se puede escribir en zonas de poca raíz. Para obtener más información, consulte Guía de referencia de instalación de Sun Java Enterprise System para UNIX
Actualmente la capacidad de cada uno de los aproximadamente 20 componentes de producto Java ES de ser compatibles con la separación de la gestión de ciclos de vida y la gestión de configuración/tiempo de ejecución entre zonas globales y no globales no ha sido establecida. Los diferentes componentes de producto han adoptado diferentes enfoques de la configuración y de la actualización. En tal situación, actualmente no se admite la propagación de componentes de producto de Java ES (excepto para Message Queue). Para obtener más información, consulte Reglas de propagación de Java ES.