|
| |
| Sun Java Enterprise System 2005Q4 Gu�a de actualizaci�n | |
Cap�tulo 1
Planificaci�n de las actualizacionesEste cap�tulo proporciona informaci�n para planificar la actualizaci�n del software de Sun Java™ Enterprise System (Java ES) a Java ES 2005Q4 (Versi�n 4). Incluye las siguientes secciones:
Componentes de Java ES 2005Q4 (Versi�n 4)A modo de introducci�n a la planificaci�n de la actualizaci�n del software de Java ES, esta secci�n analiza los componentes incluidos en Java ES Versi�n 4. En funci�n de su situaci�n, es posible que deba actualizar uno o varios de estos componentes a la versi�n incluida en la Versi�n 4.
Los componentes de Java ES se agrupan en diferentes tipos, tal y como se describe en Java Enterprise System Technical Overview (http://docs.sun.com/doc/819-2330). Los componentes de servicio del sistema proporcionan los servicios principales de infraestructura de Java ES, mientras que los componentes de calidad de servicio mejoran estos servicios del sistema. A estos dos tipos de componentes de Java ES se les denomina conjuntamente componentes de productos, es decir, componentes que se pueden seleccionar en el programa de instalaci�n de Java ES.
Cada componente de producto depende de una o varias bibliotecas compartidas localmente, conocidas como componentes compartidos de Java ES. El programa de instalaci�n de Java ES instala autom�ticamente estos componentes compartidos durante la instalaci�n de componentes de productos en funci�n de los componentes que se van a instalar.
Componentes de productos de la Versi�n 4
Los componentes de productos de la versi�n 4 de Java ES se muestran en la siguiente tabla por orden alfab�tico. Esta tabla incluye el tipo de mejora de servicio que ofrecen los componentes de calidad de servicio.
Componentes compartidos de la Versi�n 4
Los componentes compartidos de Java ES, de los que dependen los componentes de productos instalados en un �nico equipo, no se pueden seleccionar (ni anular su selecci�n) en el programa de instalaci�n de Java ES. Al instalar los componentes de productos de Java ES, el programa de instalaci�n de Java ES instala autom�ticamente los componentes compartidos necesarios para los componentes de productos instalados.
Los componentes compartidos de la versi�n 4 de Java ES se muestran en la siguiente tabla.
Acerca de la actualizaci�n de Java ESLa actualizaci�n del software de Java ES a la Versi�n 4 no se realiza normalmente mediante el programa de instalaci�n de Java ES u otra utilidad del sistema. Se realiza componente a componente, equipo a equipo, mediante procedimientos de actualizaci�n espec�ficos para cada componente.
La actualizaci�n de un componente puede variar de una actualizaci�n importante, en la que no hay compatibilidad con la versi�n anterior del componente, a una actualizaci�n totalmente compatible que simplemente ofrece algunas soluciones a errores. Debido a las dependencias entre los componentes de Java ES, la naturaleza de la actualizaci�n puede influir en la necesidad de actualizar tambi�n o no el resto de componentes.
Actualizaci�n de componentes de productos
El proceso de actualizaci�n de los componentes de productos de Java ES incluye dos operaciones b�sicas que se asemejan a la instalaci�n y configuraci�n iniciales de los componentes de Java ES:
- Instalaci�n del software actualizado. El nuevo software puede mejorar o arreglar el software existente o sustituirlo. Por lo general, para conseguir el nuevo software, se deben aplicar revisiones a los paquetes de software, sustituir los paquetes existentes, instalar nuevos paquetes o reinstalar por completo un componente con el programa de instalaci�n de Java ES.
- Reconfiguraci�n. La reconfiguraci�n abarca todos los cambios realizados en los datos de configuraci�n, datos de usuario o datos de aplicaci�n din�micos necesarios para poder utilizar el software actualizado. Un cambio en los datos puede implicar la inclusi�n de datos adicionales, un cambio en el formato de los datos (en los archivos de proporciones o en el esquema de base de datos) o un cambio en la ubicaci�n de los datos. En ocasiones, la reconfiguraci�n se realiza mediante un procedimiento expl�cito y otras veces se realiza de forma autom�tica sin que sea necesario intervenir.
Estos aspectos relacionados con la actualizaci�n de los componentes se describen en la Gu�a de actualizaci�n de cada uno de los componentes de productos de Java ES.
La Gu�a de actualizaci�n tambi�n describe otros aspectos importantes relacionados con la actualizaci�n de componentes de productos, incluidos los siguientes:
Actualizaci�n de los componentes compartidos
La actualizaci�n de los componentes compartidos de Java ES es a menudo una parte necesaria del proceso de actualizaci�n de los componentes de productos que dependen de ellos.
La actualizaci�n de los componentes compartidos es normalmente m�s directa que la actualizaci�n de los componentes de productos. Generalmente, para actualizar un componente compartido, se deben aplicar revisiones a los paquetes existentes o sustituir �stos. En comparaci�n con la actualizaci�n de los componentes de productos, no es necesario volver a realizar la configuraci�n o llevar a cabo procedimientos posteriores a la actualizaci�n.
Aunque los componentes compartidos se pueden actualizar de uno en uno, Java ES Versi�n 4 permite actualizar de forma conjunta una serie de componentes compartidos en una �nica operaci�n. Para obtener m�s informaci�n, consulte el Cap�tulo 2, “Actualizaci�n de los componentes compartidos de Java ES.”
Tecnolog�as de actualizaci�n
Para actualizar los componentes de productos y los componentes compartidos, como se describe en la Gu�a de actualizaci�n, es necesario modificar o sustituir los paquetes de software instalados actualmente y, en algunos casos, instalar nuevos paquetes. Las plataformas Solaris y Linux utilizan tecnolog�as similares para administrar los paquetes de software instalados y realizar un seguimiento de los cambios mediante un registro de paquetes.
- Plataforma Solaris. Los paquetes de Java ES pueden instalarse y eliminarse con los comandos pkgadd y pkgrm de Solaris, utilizando los paquetes que se encuentran en la distribuci�n de software de Java ES. Una vez instalado, el contenido del paquete puede modificarse mediante las revisiones aplicadas o eliminadas con los comandos patchadd y patchrm. Las revisiones para los paquetes de Solaris se distribuyen mediante el sitio web de SunSolve en: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
Las revisiones de Solaris se pueden aplicar en uno o varios paquetes. El comando patchadd guarda el paquete al que se va a aplicar la revisi�n o realiza una copia de seguridad del mismo para facilitar la eliminaci�n de la revisi�n mediante el comando patchrm. Las revisiones se identifican mediante un Id. de revisi�n, compuesto por el n�mero de revisi�n seguido del n�mero de versi�n que se incrementa a medida que se modifica la revisi�n con el paso del tiempo.
Las revisiones de Solaris pueden agruparse tambi�n en un cl�ster de revisiones. Un cl�ster permite descargar y aplicar de forma conjunta todas las revisiones incluidas en �l. Los cl�sters de revisiones se proporcionan para actualizar los componentes compartidos de Java ES (consulte el Cap�tulo 2, “Actualizaci�n de los componentes compartidos de Java ES”).
- Plataforma Linux. Los paquetes de RPM (Red Hat Package Manager) de Java ES se pueden instalar o actualizar mediante el comando rpm, utilizando los paquetes que se encuentran en la distribuci�n de software de Java ES. Sin embargo, el contenido del paquete, una vez instalado, no puede modificarse mediante revisiones. En su lugar, los paquetes de RPM se actualizan mediante la opci�n de comando rpm -U, que sustituye el paquete actual por uno nuevo.
Para mayor comodidad, muchas de las actualizaciones de los paquetes de RPM no s�lo se incluyen en la distribuci�n de software de Java ES, sino tambi�n mediante el sitio web de SunSolve: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
Para su distribuci�n mediante SunSolve, los paquetes de RPM se agrupan en revisiones y se les asigna un Id. de revisi�n y un n�mero de revisi�n similares a los de las revisiones de Solaris. Estas revisiones de Linux pueden incluir uno o varios paquetes de RPM, cada uno identificado por un nombre de RPM exclusivo, un n�mero de RPM y un n�mero de revisi�n que aumenta a medida que se modifica el paquete de RPM con el paso del tiempo.
Problemas del sistema operativo
Una serie de problemas del sistema operativo afectan a la actualizaci�n del software de Java ES, tal y como se describe a continuaci�n.
Revisiones del sistema operativo necesarias
En algunas situaciones, para actualizar satisfactoriamente un componente de producto de Java ES, es necesario aplicar en primer lugar la revisi�n del sistema operativo o revisiones espec�ficas. En lugar de aplicar la revisi�n espec�fica del sistema operativo necesaria en cada caso, suele ser preferible actualizar simplemente el sistema operativo antes de realizar las actualizaciones de Java ES.
- Las revisiones de la plataforma Solaris est�n disponibles en el sitio web de SunSolve en forma de cl�sters de revisi�n, es decir, un grupo de revisiones del sistema operativo que se pueden aplicar de forma conjunta. Los cl�sters de revisiones del sistema operativo para Solaris 8, 9 y 10 est�n disponibles en: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Las versiones de actualizaci�n de la plataforma Linux est�n disponibles en: https://www.redhat.com/apps/download/
Actualizaci�n de versiones inferiores
Un gran n�mero de los componentes compartidos de Java ES presentan paquetes espec�ficos para la versi�n de Solaris. Es posible que estos paquetes no funcionen correctamente en otras plataformas Solaris. Por ejemplo, los paquetes destinados al sistema operativo Solaris previsiblemente no funcionar�n en los sistemas operativos Solaris 9 o Solaris 10.
Al actualizar el sistema operativo de una versi�n inferior a otra, se ver�n afectados los diversos componentes compartidos de Java ES instalados. Cuando los componentes compartidos incluyen paquetes espec�ficos de una versi�n, estos paquetes deben actualizarse tambi�n, una vez actualizado el sistema operativo, para que puedan funcionar en el sistema operativo que se ha actualizado recientemente.
Actualizaci�n a plataformas no compatibles
Java ES 2004Q2 (Versi�n) es compatible con los sistemas operativos Solaris 8 y Solaris 9 en Red Hat Enterprise Linux (RHEL) 2.1. Si desea actualizar la plataforma de sistema operativo a Solaris 10 o RHEL 3.0, que no son compatibles con Java ES Versi�n 2, deber� actualizar tambi�n Java ES Versi�n 2 a una versi�n de Java ES que sea compatible con la plataforma actualizada, preferiblemente a Java ES Versi�n 4.
Dado que al actualizar algunos componentes de Java ES es necesario actualizar otros componentes de Java ES que se est�n ejecutando, no puede, por regla general, actualizar la plataforma de sistema operativo a Solaris 10 o RHEL 3.0 antes de actualizar Java ES desde la Versi�n 2 (Java ES Versi�n 2 no admite estas plataformas).
En su lugar, debe decidir el enfoque necesario en funci�n de la plataforma:
- Plataforma Linux. Debe actualizar en primer lugar Java ES Versi�n 2 a la Versi�n 4 y, a continuaci�n, actualizar a RHEL 3.0.
- Plataforma Solaris. Debe desinstalarJava ES Versi�n 2, actualizar el sistema operativo a Solaris 10 y, a continuaci�n, realizar una nueva instalaci�n de Java ES Versi�n 4. Esta operaci�n implica que se debe realizar una nueva configuraci�n de los componentes de Java ES. En este caso, es recomendable realizar una copia de seguridad de las personalizaciones y los archivos de configuraci�n de Java ES Versi�n 2 para utilizarlos en la configuraci�n de los componentes de Java ES Versi�n 4.
Planificaci�n de la actualizaci�nEl enfoque que debe tomar al actualizar un sistema de software de Java ES implementado a Java ES Versi�n 4 puede depender de sus objetivos en relaci�n con la actualizaci�n, as� como del alcance y la complejidad de su arquitectura de implementaci�n.
Por ejemplo, si su arquitectura de implementaci�n de Java ES est� formada por un �nico componente de Java ES que se ejecuta en un �nico equipo, su objetivo de actualizaci�n consistir� en solucionar algunos errores presentes en la versi�n anterior del software. Por otro lado, si su arquitectura de implementaci�n de Java ES est� formada por una serie de componentes interdependientes de Java ES implementados en distintos equipos, su objetivo consistir�a en lograr nuevas funciones mediante la actualizaci�n del m�nimo n�mero de componentes necesarios para alcanzar este fin con el m�nimo tiempo de inactividad.
Estos dos ejemplos representan dos situaciones de actualizaci�n con diferentes dificultades y que requieren planes de actualizaci�n considerablemente distintos. Ninguna planificaci�n sirve para todos los sistemas de software de Java ES implementados.
Por lo general, cuanto mayor sea el n�mero de componentes de Java ES, mayor ser� el n�mero de equipos de la arquitectura de implementaci�n y m�s compleja ser� la planificaci�n de actualizaci�n.
�Qu� es un plan de actualizaci�n?
Un plan de actualizaci�n indica c�mo abordar cada etapa del proceso de actualizaci�n. Este proceso incluye, como m�nimo, las fases que se muestran en la siguiente tabla.
En las siguientes secciones, se proporciona informaci�n que puede ayudar a elaborar un plan de actualizaci�n.
Consideraciones sobre el plan de actualizaci�n
Su plan de actualizaci�n depender� de una serie de factores, adem�s del alcance y la complejidad de su arquitectura de implementaci�n. Entre estos factores, se incluyen los siguientes:
Estos factores se abordan en las siguientes secciones.
Rutas de actualizaci�n
Aunque sea posible actualizar todas las versiones anteriores del software de Java ES a Java ES 2005Q4 (Versi�n 4), las �nicas actualizaciones certificadas son las de Java ES 2005Q1 (Versi�n 3) y Java ES 2004Q2 (Versi�n 2). No se documentan las actualizaciones desde versiones anteriores en esta Gu�a de actualizaci�n.
Las diferentes rutas incluyen distintas estrategias de actualizaci�n, tal y como se describe en la Tabla 1-4.
Debido a las diferentes caracter�sticas de las rutas de actualizaci�n de la Versi�n 3 a la Versi�n 4 y de la Versi�n 2 a la Versi�n 4, as� como al hecho de que los procedimientos de actualizaci�n de los componentes de productos dependen a menudo de la ruta de actualizaci�n, los diferentes cap�tulos de esta Gu�a de actualizaci�n, que describe la actualizaci�n de cada componente de producto, se dividen en dos secciones: una sobre la actualizaci�n de la Versi�n 3 a la Versi�n 4 y otra sobre la actualizaci�n de la Versi�n 2 a la Versi�n 4.
Tabla 1-4 Rutas de actualizaci�n a Java ES 2005Q4 (Versi�n 4)
N�mero de producto
Versi�n de Java ES
Caracter�sticas del sistema
Estrategias de actualizaci�n
2005Q1
Versi�n 3
Java ES Versi�n 4 admite una combinaci�n de los componentes de la Versi�n 3 y la 4 en un mismo equipo. Esto incluye tanto los productos de componentes como los componentes compartidos. Se han probado todas las compatibilidades entre los componentes de la Versi�n 3 y 4, y aquellas incompatibilidades detectadas se indican en las Java Enterprise System Release Notes (http://docs.sun.com/doc/819-2329).
La coexistencia entre los componentes de la Versi�n 3 y la Versi�n 4 ofrece la posibilidad de actualizar los componentes de la Versi�n 3 a la 4 de forma selectiva en un determinado equipo en una arquitectura de implementaci�n compuesta por varios equipos.
2004Q2
Versi�n 2
Java ES Versi�n 4 no admite una combinaci�n de los componentes de la Versi�n 2 y la 4 en un mismo equipo. Esto incluye tanto los productos de componentes como los componentes compartidos. Existen incompatibilidades conocidas entre los componentes de las dos versiones y no se ha verificado la interoperatividad entre los componentes de la Versi�n 2 y la Versi�n 4.
Al actualizar los componentes de la Versi�n 2 a la Versi�n 4 en un determinado equipo, deben actualizarse todos los componentes. Sin embargo, suponiendo que exista alguna compatibilidad entre los componentes, es posible combinar componentes de la Versi�n 2 y la Versi�n 4 que residan en diferentes equipos en una arquitectura de implementaci�n compuesta por varios equipos.
2003Q4
y anterioresVersi�n 1 y anteriores
Java ES Versi�n 4 no admite una combinaci�n de los componentes de la Versi�n 1 o versiones anteriores y la 4 en un mismo equipo. Esto incluye tanto los productos de componentes como los componentes compartidos. Existen incompatibilidades conocidas entre los componentes de las versiones y no se ha verificado la interoperatividad entre los componentes de la Versi�n 1 o anteriores y la Versi�n 4.
Java ES Versi�n 4 no certifica la actualizaci�n directa de la Versi�n 1 o anteriores a la Versi�n 4.
No obstante, en algunos casos, es posible realizar una actualizaci�n desde la Versi�n 1 si se actualiza primero a Java ES Versi�n 3, tal y como se describe en el manual de la Versi�n 3, Gu�a de migraci�n y actualizaci�n de Java Enterprise System (http://docs.sun.com/doc/819-0062).
En otros casos, se puede realizar la actualizaci�n de la Versi�n 1 a la Versi�n 4 del mismo modo que la actualizaci�n de la Versi�n 2 � 3 a la 4. En dichos casos, se indicar� esa posibilidad en el proceso de actualizaci�n de ese componente incluido en esta Gu�a de actualizaci�n.
Dependencias de actualizaci�n
Uno de los principales problemas a la hora de planificar la actualizaci�n de un determinado componente de Java ES consiste en conocer las dependencias de ese componente con los dem�s componentes de Java ES y si dichos componentes deben actualizarse tambi�n para poder realizar la actualizaci�n del componente dependiente.
En este sentido, existen dos tipos de dependencias de actualizaci�n:
- Dependencia de actualizaci�n fuerte. Una relaci�n de dependencia de actualizaci�n fuerte se produce cuando la versi�n actualizada de un componente necesita la versi�n actualizada de otro componente del que depende. Este requisito puede deberse a una nueva funci�n, nuevas interfaces o soluciones de errores necesarias para el componente dependiente. No se puede actualizar y utilizar satisfactoriamente el componente sin actualizar primero el componente del que depende.
- Dependencia de actualizaci�n leve. Una relaci�n de dependencia de actualizaci�n leve se produce cuando la versi�n actualizada de un componente no necesita la versi�n actualizada de otro componente del que depende. Se puede actualizar y utilizar satisfactoriamente el componente sin necesidad de actualizar el componente del que depende.
Para actualizar un componente de Java ES, es necesario actualizar todos los componentes con los que tenga fuertes relaciones de dependencia, aunque no es obligatorio actualizar los componentes con los que tenga relaciones de dependencia leves. (Esta regla general no es aplicable cuando se actualiza de la Versi�n 2 a la Versi�n 4 en un �nico equipo.)
Sin embargo, esta regla general no debe ponerse en pr�ctica necesariamente cuando existan varios componentes interdependientes incluidos en la actualizaci�n. En dichos casos, debe actualizar un componente s�lo si uno de los dem�s componentes de Java ES presenta una fuerte relaci�n de dependencia con dicho componente.
Actualizaci�n selectiva o actualizaci�n completa
La diferencia entre las relaciones de dependencia de actualizaci�n fuertes y leves permite actualizar de forma selectiva los componentes de Java ES en un sistema implementado. Esta posibilidad s�lo es efectiva al actualizar de la Versi�n 3 a la Versi�n 4 en un mismo equipo (consulte las caracter�sticas de las rutas de actualizaci�n en Rutas de actualizaci�n). No se permite la actualizaci�n selectiva de la Versi�n 2 a la Versi�n 4 en un mismo equipo.
- Actualizaci�n selectiva. El enfoque de actualizaci�n selectiva comienza con la selecci�n del componente de Java ES que desea actualizar a la Versi�n 4. Determina las relaciones de dependencia fuertes y leves de dicho componente, entre las que se incluyen tanto las dependencias con componentes de productos como con componentes compartidos. Dichos componentes deber�n actualizarse tambi�n. Repita este proceso para cada dependencia de actualizaci�n fuerte hasta que no haya ning�n componente m�s que se deba actualizar. Este ejercicio especifica todos los componentes de Java ES que se deben actualizar.
- Actualizaci�n completa. De forma alternativa, puede actualizar todos los componentes implementados de Java ES a la Versi�n 4. La complejidad de este enfoque depender� tambi�n de la arquitectura de implementaci�n. En algunos casos, es simplemente imposible actualizar todo el sistema a la vez por motivos empresariales.
La siguiente tabla muestra una comparaci�n de estos dos enfoques de actualizaci�n.
La elecci�n entre la actualizaci�n selectiva o completa no es siempre inflexible. Por ejemplo, puede optar por actualizar de forma selectiva los componentes de productos en un determinado equipo, pero actualizar todos los componentes compartidos necesarios para los componentes de productos seleccionados. De hecho, para la actualizaci�n de la Versi�n 3 a la Versi�n 4, es recomendable actualizar de forma selectiva los componentes y actualizar de forma completa todos los componentes compartidos correspondientes.
Actualizaci�n de varias instancias
La secuencia de los procedimientos de actualizaci�n puede depender de si se utiliza o no la redundancia en una arquitectura de implementaci�n y de qu� forma se utiliza. Se pueden utilizar varias instancias de un componente de Java ES para obtener una mayor disponibilidad, escalabilidad, capacidad de servicio o cualquier otra combinaci�n de estas cualidades de servicio. Existen tres tipos de tecnolog�a que utilizan los componentes redundantes en las arquitecturas de implementaci�n de Java ES: el equilibrado de carga, las t�cnicas de alta disponibilidad (Sun Cluster y el Almac�n de sesi�n de alta disponibilidad) y la repetici�n de r�plicas principales (Directory Server).
En la mayor�a de los casos en los que se emplea la redundancia, es recomendable realizar las actualizaciones sin que haya ning�n tiempo de inactividad. Estas actualizaciones por turnos intentan actualizar sucesivamente las instancias redundantes de un componente sin comprometer el servicio que ofrecen.
En la mayor�a de los casos, las instancias redundantes se implementan en varios equipos. Desde la perspectiva de la planificaci�n de la actualizaci�n, esto puede implicar el aislamiento de la actualizaci�n de dichos componentes replicados frente a la actualizaci�n de otros componentes para reducir al m�nimo el tiempo de inactividad. En otras palabras, puede realizar todas las tareas previas a la actualizaci�n del componente en cada equipo antes de realizar una actualizaci�n por turnos del componente replicado.
Cada tecnolog�a de replicaci�n incluye procedimientos de configuraci�n o reconfiguraci�n que pueden afectar a la secuencia general de actualizaci�n de los componentes de Java ES. Por ejemplo, es posible que sea necesario actualizar Sun Cluster para los componentes que se ejecuten en un entorno de Sun Cluster antes de actualizar estos componentes.
Dependencias de los componentes de Java ESComo se indicaba en la secci�n anterior, el plan de actualizaci�n debe especificar los componentes de Java ES que deben actualizarse, as� como la secuencia en que debe llevarse a cabo dicha actualizaci�n. Una de las consideraciones m�s importantes de un plan de actualizaci�n son las dependencias entre los diversos componentes de Java ES de un sistema implementado.
Independientemente de que realice una actualizaci�n selectiva o completa, la secuencia mediante la que se va a realizar la actualizaci�n de los componentes se ver� afectada por la naturaleza de las dependencias entre �stos.
En esta secci�n se proporciona informaci�n sobre las dependencias de los componentes de Java ES. Los siguientes factores asociados a las dependencias pueden afectar al plan de implementaci�n.
Cada uno de estos factores se describe brevemente en las siguientes secciones.
Dependencias con componentes compartidos
Al actualizar los componentes de productos de Java ES, debe tener en cuenta las relaciones de dependencia que estos componentes de Java ES tienen respecto a los componentes compartidos de Java ES. Cuando un componente de producto presenta una fuerte dependencia de actualizaci�n con un componente compartido, �ste debe actualizarse tambi�n.
Matriz de dependencias de componentes compartidos
La Tabla 1-6 muestra las relaciones de dependencia de los componentes de productos de Java ES 2005Q4 (Versi�n 4) con los componentes compartidos de Java ES. Las abreviaturas de los componentes de productos que encabezan las columnas de la Tabla 1-6 se han obtenido de la Tabla 1-1. Las abreviaturas de los componentes compartidos aparecen en la Tabla 1-2.
No se incluyen cuatro componentes de productos en la Tabla 1-6: Directory Proxy Server (DPS), el Almac�n de sesi�n de alta disponibilidad (HADB) y la Herramienta de preparaci�n de directorios (DPT) se han omitido porque no tienen relaciones de dependencia con ning�n componente compartido. Service Registry (SR) se ha omitido porque es un nuevo componente de producto, por lo que no existe ninguna versi�n anterior para actualizarla. Sin embargo, Web Proxy Server (WPS), otro componente de producto de la Versi�n 4, se ha incluido en la Tabla 1-6 porque puede actualizarse a la Versi�n 4 desde la versi�n anterior, que no estaba incluida en Java ES.
En la matriz de la Tabla 1-6, las relaciones de dependencia de actualizaciones fuertes de la Versi�n 3 a la Versi�n 4 aparecen se�aladas con la letra “F,” mientras que las relaciones de dependencias de actualizaci�n leves aparecen con la letra “L.” En las actualizaciones de la Versi�n 2 a la Versi�n 4, todas las relaciones de dependencia son fuertes por definici�n, por lo que se deben actualizar todos los componentes compartidos.
La Tabla 1-6 de los componentes de productos representa las dependencias directas e indirectas con los componentes compartidos. En otras palabras, un componente de producto puede depender de un componente compartido espec�fico que, a su vez, dependa de uno o varios componentes compartidos adicionales. Las dependencias con los componentes compartidos mostradas en la Tabla 1-6 incluye todas las dependencias indirectas de este tipo. La siguiente figura muestra las interdependencias entre los componentes compartidos.
Figura 1-1 Interdependencias de los componentes compartidos
Directrices para la actualizaci�n de componentes compartidos
La Tabla 1-6 permite determinar los componentes compartidos que se van a actualizar durante la actualizaci�n de uno o varios componentes de productos en un determinado equipo.
- Actualizaci�n de la Versi�n 2 a la Versi�n 4. Si va a realizar una actualizaci�n de la Versi�n 2 a la Versi�n 4, deben actualizarse todos los componentes marcados con la letra “L” o “F” en la Tabla 1-6 para los respectivos componentes de productos.
- Actualizaci�n de la Versi�n 3 a la Versi�n 4. Si va a realizar la actualizaci�n de todos los componentes de productos de la Versi�n 3 a la Versi�n 4, deben actualizarse todos los componentes de productos de la Tabla 1-6 para los respectivos componentes de productos.
Sin embargo, aunque realice una actualizaci�n selectiva de los componentes de productos, es recomendable actualizar los componentes compartidos necesarios para todos los componentes de productos en el equipo; los componentes de la Versi�n 4 se han certificado para su uso con los componentes de productos de la Versi�n 3.
Aunque la actualizaci�n selectiva de componentes compartidos puede ser eficaz en muchos casos (es decir, la actualizaci�n de aquellos componentes compartidos que admitan de forma selectiva los componentes de productos compartidos, o la actualizaci�n de las relaciones de dependencia fuertes frente a las leves), este enfoque supone un mayor riesgo.
Si no hay ninguna dependencia de actualizaci�n fuerte, no se pueden actualizar de ninguna forma los componentes compartidos. Sin embargo, por regla general, es aconsejable actualizar la base de componentes compartidos de Java ES subyacente a las versiones m�s actuales.
Nota
La secuencia de actualizaci�n de los componentes compartidos puede depender de las interdependencias mostradas en la Figura 1-1.
Adem�s, si pretende actualizar J2SE a J2SE 5.0, deber�a actualizar primero este componente compartido. J2SE es el componente base de muchos de los componentes de Java ES.
Para obtener informaci�n sobre c�mo actualizar los componentes compartidos, consulte Cap�tulo 2, “Actualizaci�n de los componentes compartidos de Java ES.”
Dependencias con componentes de productos
Las relaciones de dependencia de un componente de producto con otro determinan en gran medida los componentes de Java ES que se van a actualizar y la secuencia en la que deber�n actualizarse. Las dependencias de los componentes de productos se dividen en dos categor�as: dependencias de tiempo de ejecuci�n y dependencias de configuraci�n.
- Dependencias de tiempo de ejecuci�n. El funcionamiento de un sistema de software se basa en la interacci�n entre sus componentes implementados. Las dependencias de infraestructura entre los componentes de Java ES se describen en Java Enterprise System Technical Overview. Al actualizar un componente de producto de Java ES, debe tener en cuenta estas dependencias. Si una versi�n actualizada de un componente presenta una fuerte relaci�n de dependencia con otro componente, esta dependencia implica que el componente dependiente s�lo debe actualizarse una vez actualizado el componente del que depende.
- Dependencias de configuraci�n. En muchos casos, se debe instalar, configurar y ejecutar un componente de Java ES para poder configurar otro componente. Por ejemplo, el directorio de configuraci�n de Directory Server debe ejecutarse para poder configurar los componentes de Messaging Server, o el directorio de usuarios/grupos de Directory Server debe estar ejecut�ndose para poder registrar un servicio de Access Manager. A menudo, en los procedimientos de actualizaci�n de componentes, se deben volver a configurar los componentes actualizados o se deben migrar los datos de configuraci�n. De hecho, la funci�n principal de algunos componentes de productos consiste en proporcionar configuraci�n y asistencia administrativa para otros componentes. Por lo tanto, las dependencias de configuraci�n tienen una gran influencia en la secuencia de los procedimientos de actualizaci�n.
La Tabla 1-7 muestra las dependencias entre los componentes de productos de Java ES mostrados en la Tabla 1-1. Sirvi�ndose de la Tabla 1-7, puede confeccionar un diagrama con la cadena de dependencias del paquete de actualizaci�n. La columna de la izquierda muestra cada componente de producto, la columna central muestra sus dependencias con otros componentes de productos, la tercera describe cada dependencia y la �ltima columna indica si los componentes respectivos deben ser o no locales.
Directrices generales de secuenciaci�nLos factores abordados en las secciones anteriores pueden afectar a los componentes de Java ES que tiene intenci�n de actualizar, as� como al orden en que se van a actualizar. Estos factores influyen tambi�n en el enfoque de actualizaci�n de los componentes de Java ES implementados en varios equipos. La influencia espec�fica de estos factores depende de su arquitectura de implementaci�n.
No obstante, pueden utilizarse algunas directrices generales de secuenciaci�n, aunque no en todos los casos. La siguiente lista indica el orden en que pueden actualizarse con �xito los componentes de Java ES en un mismo equipo o en un sistema implementado. Al realizar la actualizaci�n, omita aquellos componentes que no formen parte de su arquitectura de implementaci�n o, si va a realizar una actualizaci�n selectiva, omita aquellos componentes que no formen parte del plan de actualizaci�n.
- Componentes compartidos (Consulte Cap�tulo 2, “Actualizaci�n de los componentes compartidos de Java ES”)
Los componentes compartidos deben actualizarse normalmente antes que los componentes que dependen de ellos.
- Software de Sun Cluster (Consulte Cap�tulo 3, “Software de Sun Cluster”)
Si un componente se ejecuta en un entorno de Sun Cluster y es necesario actualizar el software de Sun Cluster, �ste debe actualizarse antes que los componentes que utilicen los servicios de Sun Cluster. Sun Cluster Agents, en caso de actualizarse, debe incluirse como parte de la actualizaci�n de Sun Cluster.
- Directory Server y Administration Server (Consulte Cap�tulo 4, “Directory Server y Administration Server”)
Muchos componentes almacenan datos de usuario o configuraci�n en Directory Server, por lo que la actualizaci�n de Directory Server debe realizarse, por lo general, antes que la actualizaci�n de los componentes que presentan relaciones de dependencia de configuraci�n o tiempo de ejecuci�n con Directory Server. Administration Server debe actualizarse junto con Directory Server.
- Directory Proxy Server (Consulte Cap�tulo 5, “Directory Proxy Server”)
Directory Proxy Server presenta una fuerte relaci�n de dependencia con Directory Server y Administration Server y, por lo tanto, debe actualizarse despu�s de Directory Server y Administration Server. Otros componentes pueden acceder a Directory Server a trav�s de Directory Proxy Server.
- Web Server (Consulte Cap�tulo 6, “Web Server”)
Una serie de componentes de Java ES requieren compatibilidad con un contenedor web. Por lo tanto, el contenedor debe actualizarse antes que los componentes que necesitan servicios de contenedor web. Normalmente, estos servicios los proporciona Web Server o Application Server, pero si en la arquitectura se incluyen ambos, actualice primero Web Server.
- Message Queue (Consulte Cap�tulo 7, “Message Queue”)
Si se actualiza Message Queue, debe actualizarse antes que Application Server, ya que �ste necesita de Message Queue para ser compatible con Java 2 Enterprise Edition (J2EE).
- Almac�n de sesi�n de alta disponibilidad (Consulte Cap�tulo 8, “Almac�n de sesi�n de alta disponibilidad”)
Si se actualiza el Almac�n de sesi�n de alta disponibilidad, es mejor hacerlo antes que Application Server, ya que �ste necesita este almac�n para obtener alta disponibilidad.
- Application Server (Consulte Cap�tulo 9, “Application Server”)
Application Server depende de Web Server para el complemento de equilibrado de carga, por lo que si se utiliza esta funci�n, Application Server debe actualizarse despu�s de Web Server.
- Web Proxy Server (Consulte Cap�tulo 10, “Web Proxy Server”)
Web Proxy Server puede actualizarse en cualquier momento, aunque normalmente se deber�a actualizar despu�s del componente Web Server o Application Server, ya que proporciona un servicio de proxy. Web Proxy Server es un nuevo componente de Java ES Versi�n 4 que puede actualizarse desde la versi�n anterior, no asociada a Java ES.
- Access Manager (Consulte Cap�tulo 11, “Access Manager”)
Access Manager desempe�a un papel central en la autenticaci�n y autorizaci�n, incluido el inicio de sesi�n �nico, y debe actualizarse antes que los componentes que dependen de �l para poder utilizar estos servicios. Adem�s, Access Manager requiere un esquema espec�fico de Directory Server (Schema 2), que afecta a la forma en que los dem�s componentes utilizan Directory Server.
- Herramienta de preparaci�n de directorios (Consulte Cap�tulo 12, “Herramienta de preparaci�n de directorios”)
La Herramienta de preparaci�n de directorios depende del esquema de Directory Server y, por lo tanto, debe ejecutarse en Directory Server una vez actualizado Access Manager. (Para conocer una excepci�n a esta directriz, consulte Actualizaci�n de Access Manager desde Java ES Versi�n 2.) La Herramienta de preparaci�n de directorios debe actualizarse antes que los componentes de comunicaci�n que dependen de esta herramienta para realizar cambios en el directorio: Messaging Server, Calendar Server, Communications Express y Delegated Administrator.
- Messaging Server (Consulte Cap�tulo 13, “Messaging Server”)
Messaging Server s�lo debe actualizarse despu�s de las actualizaciones anteriores, aunque antes de actualizar Communications Express, que presenta una relaci�n de dependencia con los componentes de Messaging Server.
- Calendar Server (Consulte Cap�tulo 14, “Calendar Server”)
Calendar Server debe actualizarse despu�s de Messaging Server, ya que algunas de las sus funciones requieren compatibilidad con Messaging Server. Calendar Server debe actualizarse antes de Communications Express, que tiene una dependencia con Calendar Server.
- Communications Express (Consulte Cap�tulo 15, “Communications Express”)
Communications Express depende de gran parte de los componentes anteriores (Calendar Server, Messaging Server, la Herramienta de preparaci�n de directorios, Access Manager, Web Server y Directory Server), por lo que debe actualizarse despu�s de estos componentes.
- Instant Messaging (Consulte Cap�tulo 15, “Communications Express”)
Instant Messaging puede actualizarse en cualquier momento una vez actualizado Access Manager.
- Portal Server (Consulte Cap�tulo 17, “Portal Server”)
Portal Server, al igual que Communications Express, depende de gran parte de los componentes anteriores pero, en especial, de Communications Express para proporcionar canales de mensajer�a y calendario, por lo que debe actualizarse despu�s de Communications Express
- Portal Server Secure Remote Access (Consulte Cap�tulo 18, “Portal Server Secure Remote Access”)
Portal Server Secure Remote Access puede actualizarse en cualquier momento una vez actualizado Portal Server.
- Delegated Administrator (Consulte Cap�tulo 19, “Delegated Administrator”)
Delegated Administrator puede actualizarse y utilizarse en cualquier momento para la configuraci�n de usuarios despu�s de que la Herramienta de preparaci�n de directorios se haya actualizado y ejecutado en Directory Server. Por acuerdo, los usuarios pueden configurarse una vez actualizados e iniciados los dem�s servicios. Sin embargo Delegated Administrator puede actualizarse antes de actualizar los componentes de comunicaci�n que dependen de Delegated Administrator para la configuraci�n de usuarios.
