Gerenciamento de Carga de Trabalho |
Notas Técnicas para Amostra do BeenThere |
Localizando Código-fonte |
Revendo Notas de Codificação |
O código-fonte para o aplicativo BeenThere está localizado no diretório
Clientes do z/OS: A árvore de códigos fonte para as Amostras não é fornecida na plataforma z/OS, pois os aplicativos de Amostra não são construídos na plataforma z/OS.
O aplicativo BeenThere demonstra a capacidades WLM (Gerenciamento da Carga de Trabalho) do WebSphere Application Server Network Deployment Edition. O aplicativo BeenThere contém o servlet BeenThere e o bean corporativo de sessão sem estado BeenThere. O servlet BeenThere demonstra o servidor de aplicativos em um cluster, para o qual um pedido HTML é despachado. O bean corporativo BeenThere demonstra o servidor de aplicativos em um cluster, para o qual um pedido do bean corporativo foi despachado. O bean corporativo BeenThere é chamado através do servlet BeenThere.
O servlet BeenThere exibe as seguintes informações:
Adicionalmente, o servlet BeenThere pode executar as seguintes ações:
O ambiente da Amostra utilizado para demonstrar o gerenciamento da carga de trabalho do contêiner da Web e do contêiner EJB é descrito na seguinte ilustração:
Figura 1 O Ambiente da Amostra
As máquinas nesse ambiente incluem:
A configuração contém dois clusters de servidor, MyWebCluster eMyEJBCluster. Um cluster do servidor consiste de um grupo de servidores de aplicativos. Se um dos servidores de membros falhar, os pedidos serão roteados para outros membros do cluster. Cada um dos clusters da Amostra é composto de dois membros do cluster. O cluster MyWebCluster consiste nos membros do cluster, WebServer1 e WebServer2, e o cluster MyEJBCluster consiste nos membros do cluster, EJBServer1 e EJBServer2.
Esse ambiente configurado é uma Amostra utilizada apenas para demonstrar como executar o aplicativo BeenThere. Em um ambiente de produção, o planejamento da capacidade de recursos deve ser feito para determinar quantos membros do servidor de aplicativos serão criados através de um número específico de máquinas, com base na carga esperada de pedidos do cliente.
O WebSphere Application Server Network Deployment Edition fornece WLM (Gerenciamento da Carga de Trabalho) de pedidos HTTP e EJB.
O gerenciamento da carga de trabalho de pedidos HTTP é manipulado pelo plug-in do servidor da Web.
Considere a configuração na Figura 1. A máquina web está executando em um IBM HTTP Server que despacha pedidos HTTP para cada um dos servidores de aplicativos WebServer1 e WebServer2, que compõem os membros do cluster MyWebCluster e estão executando o servlet BeenThere. Esses servidores de aplicativos são configurados nas máquinas app1 e app2, respectivamente. Além disso, o plug-in do IBM HTTP Server é configurado de forma que o WebServer1 tenha um peso de WLM de 2 e WebServer2 tenha um peso de WLM de 3. Você pode imaginar os pesos como contadores que iniciam em seu valor configurado e são diminuídos em 1, após cada pedido ser atendido. Os pedidos são despachados utilizando um processo circular para qualquer servidor de aplicativos que tenha atualmente um contador de peso maior que 0. Se o valor for 0, o servidor de aplicativos será ignorado. Depois de todos os contadores de peso serem diminuídos a 0, então, todos os contadores de peso do servidor de aplicativos serão reconfigurados para seu valor configurado e o processo de dispatch iniciará novamente.
O gerenciamento da carga de trabalho de pedidos EJB é manipulado internamente pelo controlador de WLM no WebSphere Application Server.
Considere a configuração na Figura 1. Um cluster MyEJBCluster definido é composto dos membros EJBServer1 e EJBServer2 do servidor de aplicativos que são responsáveis por executar o bean corporativo de sessão sem estado BeenThere. O servlet BeenThere faz uma chamada para o bean corporativo, para obter informações de execução sobre o servidor de aplicativos no qual o bean corporativo está em execução. Além disso, esses servidores são configurados com valores de peso 1 e 3, respectivamente.
Na plataforma z/OS, valores de peso são utilizados para equilibrar pedidos de HTTP, mas não são utilizados para equilibrar pedidos de IIOP (Internet Inter-ORB Protocol).
O aplicativo BeenThere utiliza as interfaces de programação de aplicativos administrativas no WebSphere Application Server. Com essas interfaces, os aplicativos podem acessar informações sobre configuração de tempo de execução e ambiente:
Fornece interfaces no lado do servidor para obter informações sobre atributos do servidor de aplicativos, bem como a habilidade de executar funções de gerenciamento padrão do JMX MBean.
Fornece interfaces no lado do cliente para um objeto AdminService remoto. A classe AdminClient fornece um proxy para o objeto AdminService remoto através de um dos conectores JMX (Java Management Extensions) suportados.
Fornece interfaces para consultar ou modificar dados de configuração, local ou remotamente, e gerencia o local e o conteúdo de documentos de configuração do servidor de aplicativos.
Para demonstrar a eficácia e a flexibilidade que esses aplicativos têm, quando utilizam as interfaces administrativas do WebSphere Application Server, o aplicativo BeenThere utiliza todas essas interfaces das seguintes maneiras:
A interface AdminService é utilizada pelo servlet e pelo bean corporativo BeenThere para obter o nome do nó, o nome do servidor de aplicativos e o ID do processo para o servidor no qual eles estão em execução. O seguinte segmento de código demonstra como obter informações sobre atributos do servidor:
// Obter o WebSphere AdminService. AdminService adminService = AdminServiceFactory.getAdminService(); // Obter a instância MBean do WebSphere Admin Local Server. ObjectName localServer = adminService.getLocalServer(); // Obter o nome do nó. nodeName = (String) adminService.getAttribute(localServer, "nodeName"); // Obter o nome do Servidor de Aplicativos. serverName = (String) adminService.getAttribute(localServer, "name"); // Obter o Id do Processo do Servidor de Aplicativos. serverPid = (String) adminService.getAttribute(localServer, "pid");
A interface AdminClient é utilizada para conectar o processo do gerenciador de implementação, para recuperar os valores de peso de membros do cluster para todos os membros do servidor de aplicativos do cluster que está executando o bean corporativo BeenThere. O seguinte segmento de código demonstra como obter uma instância da interface AdminClient:
// Obter o WebSphere AdminService. AdminService adminService = AdminServiceFactory.getAdminService(); // Obter a instância AdminClient do Gerenciador de Implementação. adminClient = adminService.getDeploymentManagerAdminClient();
A interface ConfigService é utilizada para ler o documento de configuração cell.xml do WebSphere Application Server para determinar se o aplicativo BeenThere está em execução em um ambiente WebSphere Application Server Base Edition ou Network Deployment Edition. O seguinte segmento de código demonstra como determinar o ambiente no qual um aplicativo está em execução:
// Criar uma nova Sessão de Gerenciamento do WebSphere. Session session = new Session(); // Obter a instância ConfigService do WebSphere // para o servidor de aplicativos que está executando esse servlet. ConfigService configService = ConfigServiceFactory.getConfigService(); if (configService != null) { // Ler o 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 a Sessão. configService.discard(session);Se um ambiente Network Deployment for detectado, então, a opção de peso do membro do cluster do bean Display será ativada e exibida, porque essa opção é válida apenas nesse tipo de ambiente. Caso contrário, esta opção não é exibida como uma opção selecionável.