jbossbrasil.org

Bom vamos lá para mais um texto da Taliban productions!

Resolvi publicar algo que mostrasse efetivamente como criar um serviço para o JBoss, e já que pensei em montar isso preparei o exemplo nas duas formas possíveis de fazê-lo (e em duas partes): MBean e POJO.

Vamos ao primeiro exemplo utlizando MBean, e no próximo post tratarei dos serviços implementados com POJO simples e suas vantagens.

Primeiramente criei um projeto java simples no eclipse de nome teste-mbean com a seguinte estrutura:

Após criar o package, criei duas classes java, sendo uma delas a interface TesteSeviceMBean que segue abaixo:

1
2
3
4
5
6
7
8

package org.jboss.teste.mbean;
 
import org.jboss.system.ServiceMBean;
 
public interface TesteServiceMBean extends ServiceMBean {
	public String getProperty(String property);
	public void setProperty(String key, String value);
}

Um ponto importante a ser levantado, a interface precisa estender a classe ServiceMBean obrigatoriamente, e precisa ter o sufixo MBean no nome.

Abaixo segue a implementação do serviço que apenas adiciona um valor indexado por uma chave e precisa estender a classe ServiceMBeanSupport e implementar a interface criada acima:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

package org.jboss.teste.mbean;
 
import org.jboss.system.ServiceMBeanSupport;
 
public class TesteService extends ServiceMBeanSupport implements TesteServiceMBean {
 
	@Override
	protected void startService() throws Exception {
		log.info("TesteMBeanService Iniciado");
	}
 
	@Override
	protected void stopService() throws Exception {
		log.info("TesteMBeanService Parado");
	}
 
	@Override
	public String getProperty(String property) {
		String value = System.getProperty(property);
		log.info("TesteMBeanService retornando: "+value);
		return value;
	}
 
	@Override
	public void setProperty(String key, String value) {
		System.setProperty(key, value);		
	}
 
}

Os métodos getProperty e setProperty são apenas para exemplificar um método de negócio em um serviço qualquer. Os métodos startService e stopService são sobrecarregados e fazem parte do ciclo de vida de um MBean, apenas para que seja jogado um log apenas informando que o serviço iniciou ou parou corretamente.

Agora precisamos configurar o serviço implementado, para isso criaremos um xml que define qual a classe de implementação (atributo code na tag mbean), e qual o nome que daremos ao serviço (atributo name na tag mbean), lembrando sempre que o nome do serviço é formado com a seguinte estrutura:

E segue o arquivo de configuração do serviço que deve ter a seguinte estrutura de nome: *-service.xml

No nosso case dei o nome de testembean-service.xml e o adicionei na pasta META-INF do nosso projeto.

1
2
3
4
5

<server>
  <mbean code="org.jboss.teste.mbean.TesteService"
     name="org.jboss.teste.mbean:service=TesteService">
  </mbean>
</server>

Até aqui legal, agora basta exportarmos esse trem como um arquivo *.jar e jogá-lo na pasta deploy do seu perfil iniciado do JBoss. Essa não é a única forma de fazer deploy de um serviço no JBoss, quem sabe num texto futuro eu aborde apenas isso =P

Você verá no log algo como: INFO [TesteService] TesteMBeanService Iniciado

Com o serviço iniciado podemos verificar e invocar seus métodos via twiddle ou jmx-console, tirei o screenshot do serviço disponibilizado no jmx-console:

E acessando o link do serviço podemos ver a descrição completa de atributos e temos a possibilidade de invocar seus métodos, lembram do setProperty e do getProperty?

Bom agora basta interagir com seu serviço, beber algumas e ter idéias geniais de serviços que você pode implementar

No próximo post trataremos de serviços também, mas implementandos a partir de classes POJO simples.

Num post futuro quero tratar apenas de formas de utilização do twiddle!

Bom prometi a mim mesmo que não me prolongaria nos posts, portanto vamos lá:

O container EJB no JBoss mantém um pool de SLSB para evitar de a todo momento criar e destruir instâncias. Você pode configurar o tamanho desse pool alterando o parâmetro maxSize que fica no trecho que código do xml abaixo retirado do arquivo deploy/ejb3-interceptors-aop.xml:

<annotation expr=”class(*) AND !class(@org.jboss.ejb3.annotation.Pool)”>
@org.jboss.ejb3.annotation.Pool (value=”ThreadlocalPool”, maxSize=30, timeout=10000)
</annotation>

O atributo timeout é o tempo de espera por uma instância válida no pool caso suas requisições tenham atingido o limite de 30 (que na verdade é o valor default)

O JBoss utiliza a implementação de ThreadLocalPool para evitar a sobrecarga de sincronização Java, mas nada impede que você mude a implementação para um mecanismo diferente de pooling. O JBoss implementa também o StrictMaxPool que fixa um número máximo de requisições simultâneas. Se não houver threads disponíveis, as requisições que ultrapassam o tamanho especificado em maxSize ficarão bloqueadas até que uma instância esteja disponível.

<annotation expr=”class(*) AND !class(@org.jboss.ejb3.annotation.Pool)”>
@org.jboss.ejb3.annotation.PoolClass (value=”org.jboss.ejb3.StrictMaxPool“, maxSize=30, timeout=10000)
</annotation>

Os parâmetros de configuração do pool de SLSB pode ser verificado a qualquer momento via JMX. Basta buscar no seguinte domínio: jboss.j2ee e selecionar o serviço EJB que você deseja monitorar. Lá você encontrará o atributo Available Count que mostrará a quantidade de instâncias disponíveis no pool de SLSB para processamento.

Mas e se você precisasse definir um tamanho de pool específico para um EJB e todo o resto utilizasse a configuração definida no xml?

Basta anotar seu bean com a seguinte anotação:

@PoolClass (value=org.jboss.ejb3.StrictMaxPool.class, maxSize=10, timeout=1000)

Abraços ai galera!

Em breve mais dicas de JBoss diretamente do Taliban!