Artigo Java Magazine 21 - Gerenciamento em Java

Byte Code

Gerenciamento em Java

JMX e tecnologias relacionadas, na prática

As técnicas de gerenciamento, hoje peça fundamental de Java, simplificam a manutenção e aumentam a robustez de sistema complexo

Na engenharia de software consideramos que todo sistema possui dois tipos de requisitos. Sabemos que os requisitos funcionais são as características especificadas (e pagas) pelo cliente, por exemplo, “gerar relatório mensal de vendas em formato HTML ou PDF”; e os requisitos não-funcionais são todos aqueles assumidos como item obrigatório: que o software seja robusto, eficiente, seguro, fácil de manutenção etc.

Em alguns casos, nem é do cliente ou usuário final que será afetado pela ausência ou presença dos requisitos não-funcionais. Quando você coloca uma aplicação em produção sob contrato de suporte, qualquer dificuldade que tenha para diagnosticar e corrigir eventuais problemas será um prejuízo seu, seja em esforço de diagnóstico e correção, seja na imagem do produto com o cliente. Mesmo quando a aplicação é de uso interno, ou seja, produzida e utilizada pela mesma empresa, um trabalho de manutenção é um desperdício de esforço que poderia estar sendo utilizado para outra coisa. Por isso, um dos requisitos não-funcionais mais importantes de uma aplicação é o que chamamos de “gerenciamento”.

A plataforma Java suporta gerenciamento através da JMX (Java Management Extesion). Quando a Java Magazine publicou seu primeiro artigo sobre o assunto (na Edição 5), esta API estava “planejada inclusão no J2EE 1.4”. Hoje, temos a JMX embutida não só no J2EE 1.4, mas também no J2SE 5.0, facilitando ainda mais o seu uso sem necessidade de redistribuir pacotes adicionais. Isto é, o “X” de JMX perdeu o significado, pois a API não é mais uma “extensão” e sim uma API fundamental da plataforma Java.

Se você estiver utilizando o J2SE 1.3 ou 1.4, e não estiver fazendo uso de container J2SE, terá que instalar as APIs JMX para testar os exemplos deste artigo (veja links).

Gerenciabilidade

Num certo grau, qualquer aplicação é gerenciável. Na pior hipótese, podemos ir até as dependências do cliente, conectar um notebook à rede de produção e rodar a aplicação sob um depurador ou profiler, acessando o banco de dados real, e assim por diante. Mas é um processo desconfortável, custoso e intrusivo, e é o que todo desenvolvedor evita se puder. Para permitir uma rotina de manutenção melhor, toda aplicação razoavelmente bem escrita utilizará, no mínimo, a técnica de geração de logs, que permite à aplicação deixar “pistas” do seu funcionamento que facilitem o diagnóstico de problemas (veja o artigo “Logging J2SE 1.4” na mesma Edição 5). Também podemos empregar outra pratica que facilitem o suporte de software.

Gerenciamento no J2EE

A plataforma J2EE foi uma grande melhoria nesse sentido, facilitando a distribuição, configurações e atualizações de aplicações. Hoje é moda falar mal da complexidade da plataforma J2EE, das suas APIs, descritores de deployment e servidores paquidérmicos. Qualquer veterano que lembre como as coisas eram há dez anos vai constatar que muitas práticas hoje corriqueiras não eram possíveis, ou custariam muito mais esforço para serem variáveis na prática. Por exemplo, atualizar parte de uma aplicação “à quente”, num cluster, e sem exigir conhecimento avançados de administração de sistema, nem ferramentas caras e proprietárias.

Os servidores J2SE são muito bons, mas seus recursos de gerenciamento são limitados. As interfaces gráficas de gerenciamento destes servidores limitam-se a controlar recursos “gerenciamento pelo container”. Assim, há produtos que permitem configurar visualmente as propriedades de um pool de conexões, verificar a qualquer momento quantas conexões uma aplicação está sendo usando, gerar alguma ação automática quando ocorreram eventos como “uso pool maior que 90%”, ou gerar um gráfico diário de numeração de conexão x tempo. Mas as mesmas facilidades não estão disponíveis para informações produzidas pela própria aplicação, que também podem ser muito importantes para o seu gerenciamento.

Por exemplo, você poderia querer um gráfico diário de “relatórios de vendas gerados por minutos”, mas o seu servidor J2EE não será capaz de produzir algo desse tipo. Você poderia programar esse relatório como parte da aplicação (talvez acessível via comandos secretos, conhecidos apenas pela equipe de desenvolvimento), mas é uma tarefa trabalhosa, que seria uma solução “sob demanda”, proprietária à aplicação e não interoperável com nada.

O ideal seria que as aplicações somente expusessem informações críticas, como o número de relatórios gerados, usando interfaces e protocolos padronizados e permitindo o uso de ferramentas de prateleira para gerenciar uma grande variedade de aplicação de forma conveniente. É exatamente essa a idéia por trás das plataformas de gerenciamento.

Java e JMX

A plataforma Java ganhou suas primeiras facilidades oficiais de gerenciamento com a JMX, criada por um dos primeiros padrões do JCP (JSR-003), seguida por varias outras JSRs. Na Tabela1, podemos ver a curiosa historia das especificações da JMX, que talvez seja a tecnologia Java com maior número de especificações canceladas – três JSRs que foram iniciadas e depois abandonadas. Essa não-continuidade era sempre devido à “falta de demanda” ou à “falta de recursos” das próprias empresas que haviam proposto as JSRs; mas pode ter sido motivada por uma tentativa inicial muito fragmentada de padronizar varias camadas de interoperabilidade.

Veja o quadro “Tecnologias de gerenciamento” sobre tecnologias como TMN, WBEM e SNMP (mencionadas a seguir), além de outros conceitos relacionados a estas tecnologias.

A perda da JSR-070 (JMX/CORBA) foi compensada mais tarde pela JSR-160 (Remote API). A JSR-146 específica à integração JMX/WBEM, foi cancelada, mas a JSR-48, que traria suporte mais abrangente ao WBEM, continua andando (embora lentamente, sem notícias desde sua posição em 2000). Já a idéia de suportar TMN parece ter morrido totalmente. Talvez um indício do crescimento da SNMP e da progressiva diminuição de demanda por TMN. Para quem quiser trabalhar com TMN, Java permite utilizar produtos que implementam o padrão CORBA/TMN Internetworking da OMG, ou produtos que suportam TMN em Java mesmo sem seguir um padrão aprovado pelo JCP (veja links).

A JCP finalmente acertou o passo com a JSR-160, que padronizou as interfaces remotas que mais importam: RMI para ambientes Java (ou não-Java, com CORBA via RMI/IIOP) e SNMP para softwares de gerência de rede voltados à área de telecomunicações.

Tabela 1. JSRs relacionadas à JMX

Logging x gerenciamento

Qualquer aplicação não-trivial, especialmente aplicações servidoras, possui alguma quantidade de códigos de autogerenciamento. A maioria utiliza JMX, SNMP ou outras soluções mais robustas de gerenciamento, mas produz logs de eventos importantes, por exemplo, com uma API de logging como a Log4J ou a java.util.logging (lançada no J2SE 1.4).

Logging é uma ferramenta antiga e perfeitamente legítima de gerenciamento de aplicações. Com logs bem estruturados, detalhados e configuráveis é possível implementar muitas facilidades de gerenciamento (veja o artigo da Edição 5 já citado, para detalhes). Há também diversas outras opções de gerenciamento que não cobriremos aqui.

Precisamos identificar em quais cenários é melhor usar logs e em quais é recomendável utilizar gerenciamento. Podemos começar listando as desvantagens e dificuldades do logging como solução de gerenciamento:

...
Quer ler esse conteúdo completo? Tenha acesso completo