Domínio

Quando trabalhamos em um ambiente de desenvolvimento, basicamente o que temos que nos preocupar é referente a criação de um domínio. Um domínio nada mais é que um conjunto de recursos e serviços que fisicamente são mantidos através de arquivos.

A parte principal de um domínio chama-se Administration Server, que é uma instância de um Weblogic Server responsável por manter e configurar seus recursos. Todo esse gerenciamento do Adminstration Server é feito através do Admin Console, que por sua vez é uma aplicação que é deployada no seu Administration Server e que será responsável por fornecer uma interface gráfica para que você possa gerenciar seu domínio, ou seja, toda a configuração feita pelo Admin Console é baseada em XML e é ele quem gerencia esses arquivos.

É através do Administration Server que você faz o deploy/undeploy das suas aplicações, porém em um ambiente de produção, ou até mesmo de homologação, o mais indicado é que tenhamos nossas aplicações em um servidor a parte, que são chamados de Managed Servers.

Managed Servers

Uma instância de um Weblogic Server, que não é uma instância do Administration Server, é chamada de Managed Server, é no Managed Server onde suas aplicações e recursos serão deployados de fato, deixando para o Administration Server apenas a responsabilidade de gerenciá-los.

São os Managed Servers que hospedam todos os componentes e recursos que constituem uma aplicação, e toda vez que um Managed Server é inicializado, ele se conecta com o Administration Server para obter informações de configuração e deployment.

Cluster. O quê é e por quê usar?

Em ambientes de produção é normal que existam certas preocupações que não ocorrem com ambientes de desenvolvimento, como alta disponibilidade das aplicações e balanceamento de carga.

Imagine que ocorra qualquer problema na máquina onde a sua aplicação está deployada? O quê fazer? Para não ficar a mercê desse tipo de problema, o correto é pensar em uma estrutura em que sua aplicação possa ser replicada em N instância de servidores em máquinas diferentes, onde caso uma máquina dê problema, a outra assume e assim sucessivamente.

Outro problema comum é a sobrecarga de uma aplicação. Um cenário normal em aplicações web é o acesso de muitos usuários e consequentemente o processamento a exaustão das máquinas onde essas aplicações estão deployadas, isso por muitas vezes pode ocasionar um estouro de processamento ou até mesmo um tempo de resposta maior para o usuário. E como fazer para resolver esse problema? A resposta é através do balanceamento de carga.

Para resolver esses tipos de problemas foi criada uma estrutura cuja o nome é Cluster. Um Cluster é um conjuto de computadores que trabalham de forma conjunta cujo objetivo é fazer com que todo o processamento da aplicação seja distribuído a N computadores, mas de forma que pareça com que eles sejam um computador só.

Cluster e Managed Servers

Um Cluster de Weblogic Server corresponde a múltiplas instância de Weblogic Server que estão trabalhando e rodando simultaneamente com o objetivo de prover escalabilidade e disponibilidade.

Ou seja, um Cluster é um conjunto de Managed Servers, e cada Managed Server representa um nó de um cluster.

Quando se pensa em uma arquitetura usando Clusters, é normal que se pense em mais de uma máquina, afinal não faz muito sentido ter um Cluster com uma máquina, pois caso essa máquina pare de funcionar, todas as aplicações também irão parar.

A relação Managed Servers, Machines e Domínio

Partindo do princípio que um Cluster deve necessariamente ter mais de uma máquina, chegamos ao conceito de “Machines” do Weblogic Server.

Uma “machine” é exatamente uma máquina, um computador físico, e essa máquina pode ter mais de um managed server, ou seja, pode ter mais de uma instância do Weblogic Server rodando ao mesmo tempo. É óbvio que nesse caso teríamos que ter essas duas instâncias rodando em portas diferentes.

Dessa forma, chegamos a seguinte associação: Domínio -> Administration Server -> Cluster -> Machine -> Managed Server.

Node Manager

Quando falamos a nível de máquina (machine), devemos falar também dos Node Managers. Um Node Manager não está associado a um domínio, está associado a uma máquina, já que uma máquina pode ter mais de um Managed Server.

Um Node Manager é uma aplicação standalone responsável por gerenciar Managed Servers em uma máquina (machine) remota. Através do Node Manager é possível inicializar, parar e re-startar instâncias do Administration Server e dos Managed Servers de uma máquina remota.

Multi-cast Address

Em um ambiente clusterizado, precisamos ter N computadores trabalhando de forma conjunta de forma que isso seja transparente, mas quando usamos recursos como sessões, ou até mesmo conexões distribuídas, precisamos que isso também seja feito de forma distribuída, sem que seja necessário por exemplo criar uma sessão para cada Managed Server.

Isso é feito através do multi-cast address, que é um IP associado a um cluster, que por sua vez irá informar esse IP para seus Managed Servers para que os mesmos possam usar um único IP para fazer esse tipo de compartilhamento.

Juntando tudo

Para dar uma visão mais clara de toda essa arquitetura e quem está associado a o que, resolvi criar um diagrama que mostra todos os elementos citados acima e associação/relação entre eles.

No exemplo usei ainda o Apache como Servidor Web, que será a porta de entrada de tudo, será ele que irá receber as requisições HTTP, fazer o balanceamento de carga e delegar as responsabilidades para os Managed Servers. Será o Apache ainda o responsável por identificar e servir conteúdo estático sem que seja necessário passar pelo Cluster.

Diagrama

clique para ampliar

Mais Informações

Weblogic Server
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/admin.html

Understanding Cluster Configuration
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/cluster/config.html

Understanding Weblogic Server Clustering
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/cluster/overview.html

Setting Up Weblogic Cluster
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/cluster/setup.html

Using Node Manager
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/server_start/nodemgr.html

Node Manager Architecture
http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/adminguide/nodemgr.html

Configure Apache HTTP Server
http://download.oracle.com/docs/cd/E15051_01/wls/docs103/plugins/apache.html

Um domínio Weblogic pode ser corrompido por diversos motivos, como: domínio ser encerrado de forma forçada ( com um kill -9, por exemplo), máquina ser desligada de forma repentina, falta de luz, etc. Quando isso acontece, seu domínio que estava rodando pode ser corrompido, e com isso a seguinte mensagem é retornada ao tentar iniciá-lo novamente:

Server cannot be started.   The server process cannot be started, or terminated abruptly. Check the start script.

Para resolver isso é muito simples, basta remover todas as pastas build pré-existentes (são geradas automaticamente pela seu Workshop, quando a aplicação é compilada) e em seguida basta fazer um start do seu domínio novamente.

Outra dica, é que antes de tentar fazer o deploy das aplicações em cima desse domínio novamente, que antes faça um undeploy (usando o console) das mesmas, pois se o domínio foi encerrado de forma forçada, as aplicações ainda estarão lá deployadas e caso você tente novamente, provavelmente não conseguirá.

Procurei sobre isso nos forums da Oracle e não achei nada, então fica aí a dica, pois isso evita que você tenha que re-criar e configurar seu domínio novamente.

Com o HermesJMS é possível publicar mensagens, remover, ver o conteúdo das mensagens publicadas, a quantidade, dentre outras funcionalidades. Eu diria que o HermesJMS está para JMS como o soapUI está pra Web Services.

Só que existe um pequeno probleminha de incompatibilidade entre o HermesJMS e o Weblogic 10.2. O HermesJMS foi construído com a JVM 1.6 e o Weblogic 10.2 roda com a JVM 1.5, portanto quando tentamos acessar resources JMS configurados em um servidor Weblogic temos um probleminha com o ClassLoader, segundo bug relatado nesse link.

Geralmente para resolução desse problema, quando eu ia usar o Hermes, eu mudava a minha váriavel ambiente JAVA_HOME para apontar para o JDK 1.5, para agilizar esse processo pode ser feito um Shell Script que seta essa varíavel de ambiente apontando para o JDK 1.5 e abrindo o HermesJMS logo em seguida, mas existe uma solução melhor e mais limpa para isso, que é setando uma propriedade na inicialização do HermesJMS, seguem os passos necessários:

1) Entrar no diretório de instalação do HermesJMS, no meu caso é /opt/HermesJMS
2) Editar o arquivo hermes.sh que fica dentro do diretório bin
3) Ir para a última linha desse arquivo e adicionar a propriedade: -Dsun.lang.ClassLoader.allowArraySyntax=true

Dessa forma, a última linha do arquivo /bin/hermes.sh ficaria assim:

"$JAVACMD" -XX:NewSize=256m -Xmx1024m -Dsun.lang.ClassLoader.allowArraySyntax=true $HERMES_OPTS -Dhermes.home=$HERMES_HOME -Dhermes=$HERMES_CFG -Dhermes.libs=$HERMES_LIB_PROPERTY -classpath $LOCALCLASSPATH hermes.browser.HermesBrowser

Esse pequeno workaround corrige esse probleminha de incompatibilidade entre o HermesJMS e o Weblogic 10.2 e nos permite usar o HermesJMS com o JDK 1.6.

Na aplicação web do projeto que estou trabalhando, nós fazemos o uso da API Commons Logging do Apache para poder fazer logging da aplicação, só que para o log aparecer corretamente no console existe um pequeno “macete”, que por incrivel que pareça não diz com mais detalhes na documentação do Weblogic.

O probleminha era, que por mais que eu fizesse o seguinte:

public class SovWS {
 
	private static Log log =  LogFactory.getLog("SOV-"+SovWS.class);
 
	@WebMethod
	public SaveMetaResponseDocument saveMeta(SaveMetaRequestDocument request) {		
		log.info(this.getClass() + " iniciando a nova meta");
               ....
        }
}

Eu não conseguia fazer com que a mensagem de log aparecesse no console do Workshop, ainda que tudo estivesse correto.

Para resolver é muito simples, basta ir nas propriedades do projeto, ir nos facets do projeto e verificar se a extensão Weblogic Integrated Commons Logging está como um facet do projeto, se não estiver, está aí o problema e para resolver basta adicionar esse novo facet.

Para ter certeza que está tudo certinho, sugiro abrir o arquivo weblogic-application.xml e verificar se a seguinte configuração está presente:

<wls:library-ref>
    <wls:library-name>wls-commonslogging-bridge</wls:library-name>
    <wls:specification-version>1.0</wls:specification-version>
    <wls:exact-match>true</wls:exact-match>
</wls:library-ref>

Se a seguinte configuração estiver presente, pronto, tudo ok! Agora o log deverá aparecer no console sem problemas.

PS: Só para ressaltar que essa dica é válida para ambiente de desenvolvimento.