Notas técnicas del ejemplo de BeenThere


Localizar el código fuente
Revisar notas de la codificación


Localizar el código fuente

El código fuente de la aplicación BeenThere está ubicado en el directorio raíz_perfil/samples/src/BeenThere, donde <raíz_perfil> es la vía de acceso plenamente cualificada del perfil del gestor de despliegue.

Clientes de z/OS: no se proporciona el árbol de código fuente de los ejemplos en la plataforma z/OS porque las aplicaciones de ejemplo no están creadas en plataformas z/OS.



Revisar notas de la codificación

Visión general

La aplicación BeenThere demuestra las posibilidades de gestión de carga de trabajo (WLM) de IBM WebSphere Application Server Network Deployment Edition. La aplicación BeenThere contiene el servlet BeenThere y el enterprise bean de sesión sin estado BeenThere. El servlet BeenThere demuestra el servidor de aplicaciones de un clúster al que se envía una petición HTTP. El enterprise bean BeenThere demuestra el servidor de aplicaciones de un clúster al que se ha enviado una petición del enterprise bean. El servlet BeenThere invoca el enterprise bean BeenThere.

El servlet BeenThere muestra la información siguiente:


De modo adicional, el servlet BeenThere puede realizar las acciones siguientes:


Entorno

El entorno del ejemplo que se utiliza para demostrar la gestión de carga de trabajo del contenedor Web y del contenedor EJB se representa en la ilustración siguiente:



Figura 1   Entorno del ejemplo


Entre los equipos de este entorno se incluyen:



La configuración contiene dos clústeres de servidor, MyWebCluster y MyEJBCluster. Un clúster de servidor consta de un grupo de servidores de aplicaciones. Si uno de los servidores miembros no funciona, las peticiones se direccionan a otros miembros del clúster. Todos los clústeres del ejemplo se componen de dos miembros del clúster. El clúster MyWebCluster consta de miembros del clúster, WebServer1 y WebServer2 y, el clúster MyEJBCluster consta de miembros del clúster, EJBServer1 y EJBServer2.

Este entorno configurado es un ejemplo que se utiliza sólo para demostrar cómo ejecutar la aplicación BeenThere. En entornos de producción, se debe realizar una planificación cuidadosa de la capacidad de los recursos para determinar cuántos miembros del servidor de aplicaciones se deben crear en un número de equipos concreto, basándose en la carga de la petición del cliente esperada.

Gestión de cargas de trabajo

WebSphere Application Server Network Deployment Edition proporciona la gestión de carga de trabajo (WLM) de peticiones HTTP y de peticiones EJB.

Gestión de carga de trabajo del contenedor Web

La gestión de carga de trabajo de las peticiones HTTP se lleva a cabo mediante el plug-in del servidor Web.

Tenga en cuenta la configuración de la Figura 1. En el equipo web se ejecuta IBM HTTP Server que envía peticiones HTTP a cada uno de los servidores de aplicaciones WebServer1 y WebServer2 que componen los miembros del clúster MyWebCluster y ejecutan el servlet BeenThere. Estos servidores de aplicaciones se configuran en los equipos app1 y app2, respectivamente. Además, el plug-in de IBM HTTP Server está configurado de tal modo que WebServer1 tiene un peso de WLM (gestión de carga de trabajo) de 2 y WebServer2 tiene un peso de WLM de 3. Puede pensar en los pesos como contadores que se inician en sus valores configurados y se decrementan en 1 cada vez que se atiende una petición. Las peticiones se envían, utilizando el proceso round-robin, al servidor de aplicaciones que actualmente tenga un valor de contador de peso superior a 0. Si el valor es 0, se omite el servidor de aplicaciones. Cuando todos los contadores de peso se han decrementado a 0, se restablecen todos los contadores de peso del servidor de aplicaciones a sus valores configurados y el proceso de envío vuelve a empezar de nuevo.

Gestión de carga de trabajo del contenedor EJB

La gestión de carga de trabajo de peticiones EJB se gestiona internamente mediante el controlador de WLM (gestión de carga de trabajo) en WebSphere Application Server.

Considere la configuración de la Figura 1. Se define un clúster MyEJBCluster que se compone de los miembros del servidor de aplicaciones EJBServer1 y EJBServer2 que se encarga de ejecutar el enterprise bean de sesión sin estado BeenThere. El servlet BeenThere hace una llamada al enterprise bean para obtener información de ejecución acerca del servidor de aplicaciones en el que se ejecuta el enterprise bean. Además, estos servidores se configuran con los valores de peso 1 y 3, respectivamente.

En la plataforma z/OS, los valores de peso se utilizan para equilibrar peticiones HTTP, sin embargo, no se utilizan para equilibrar peticiones IIOP (Internet Inter-ORB Protocol).

Interfaces de programas de aplicación administrativa de WebSphere

La aplicación BeenThere utiliza las interfaces de programas de aplicación administrativa de WebSphere Application Server. Con estas interfaces las aplicaciones pueden acceder a la información de ejecución y de configuración del entorno:


AdminService

Proporciona interfaces en el servidor para obtener información de atributos del servidor de aplicaciones así como la posibilidad de realizar funciones de gestión del MBean JMX estándar.

AdminClient

Proporciona las interfaces en el cliente con objetos AdminService remotos. La clase AdminClient proporciona un proxy al AdminService remoto a través de uno de los conectores JMX (Java Management Extensions) soportados.

ConfigService

Proporciona interfaces para consultar o modificar datos de configuración, locales o remotos, y gestiona la ubicación y el contenido de los documentos de configuración del servidor de aplicaciones.

Para demostrar las posibilidades y la flexibilidad que las aplicaciones tienen cuando utilizan las interfaces administrativas de WebSphere Application Server, la aplicación BeenThere utiliza todas estas interfaces de los modos siguientes:


AdminService

El servlet BeenThere y el enterprise bean utilizan la interfaz AdminService para obtener el nombre de nodo, el nombre de servidor de aplicaciones y el ID de proceso del servidor de aplicaciones en el que se están ejecutando. El segmento de código siguiente demuestra cómo obtener información de atributos del servidor:


// Obtener WebSphere AdminService.
AdminService adminService = AdminServiceFactory.getAdminService();

// Obtener la instancia del MBean del servidor local de WebSphere Admin.
ObjectName localServer = adminService.getLocalServer();

// Obtener el nombre de nodo.
nodeName = (String) adminService.getAttribute(localServer, "nodeName");

// Obtener el nombre de servidor de aplicaciones.
serverName = (String) adminService.getAttribute(localServer, "name");

// Obtener el ID de proceso del servidor de aplicaciones.
serverPid = (String) adminService.getAttribute(localServer, "pid");

AdminClient

Se utiliza la interfaz AdminClient para conectar con el proceso gestor de despliegue con el fin de recuperar los valores de peso de miembros del clúster para todos los miembros servidores de aplicaciones del clúster que ejecutan el enterprise bean BeenThere. El segmento de código siguiente demuestra cómo obtener una instancia de la interfaz de AdminClient:


// Obtener WebSphere AdminService.
AdminService adminService = AdminServiceFactory.getAdminService();

// Obtener la instancia de AdminClient para el gestor de despliegue.
adminClient = adminService.getDeploymentManagerAdminClient();

ConfigService

La interfaz ConfigService se utiliza para leer el documento de configuración cell.xml de WebSphere Application Server para determinar si la aplicación BeenThere se ejecuta en el entorno de WebSphere Application Server Base Edition o de Network Deployment Edition. El segmento de código siguiente demuestra cómo determinar el entorno en el que se está ejecutando la aplicación:


// Crear una sesión nueva de gestión de WebSphere.
Session session = new Session();

// Obtener la instancia de ConfigService de WebSphere
// del servidor de aplicaciones que ejecuta este servlet.
ConfigService configService = ConfigServiceFactory.getConfigService();
if (configService != null)
{
  // Leer el documento cell.xml.
  ObjectName cellObj = ConfigServiceHelper.createObjectName(null, "Cell");
  ObjectName[] cellObjs = configService.queryConfigObjects(session, null, cellObj, null);

  if (cellObjs.length != 0)
  {
    cellObj = cellObjs[0];
    String cellName = (String) configService.getAttribute(session, cellObj, "name");
    String cellType = (String) configService.getAttribute(session, cellObj, "cellType");
    if (cellType.equals("DISTRIBUTED"))
    {
      websphereND = true;
    }
  }

  // Liberar la sesión.
  configService.discard(session);

Si se detecta un entorno de Network Deployment, se habilitará la opción Display bean cluster member weights (Mostrar pesos de miembros de clúster del bean) y se mostrará porque esta opción sólo es válida en este tipo de entorno. Si no es así, no se mostrará esta opción como seleccionable.