Furious Bob

A espera foi longa mas valeu a pena! Saiu ontem a versão Beta1 do JBoss OSGI. Acho que era isso que faltava para os containers OSGI darem um grande pulo em direção a plataforma JEE. O JBoss OSGI, assim como o Spring Dynamic Modules, é uma camada de integração com containers OSGI existentes ( felix, equinox, knopflerfish).

Ainda estou testando o container, e parece ser promissor, junto com um post mais detalhado sobre OSGI (estou preparando uma palestra para turma de computação da PUC-MG sobre o assunto) eu posto aqui minhas impressões.

Não deixem de conferir: JBoss OSGI

Uma das minhas grandes paixões no mundo java é o projeto Lucene, e com ele, todos os seus fantásticos sub-projetos como:

• Nutch - Um poderoso crawler (ou spider se preferir) que consegue rodar de forma paralela em vários nós de cluster.
• Solr - Um sistema completo de indexação e busca que oferece uma interface webservice para acesso remoto. Nunca foi tão simples criar um full text search para sua aplicação (e não importa qual linguagem)
• Mahout - Um framework para execução em cloud de algoritmos tradicionais de inteligência computacional (como Redes Neurais, Clustering, Classification, Collaborative Filtering, Algoritmos Genéticos e etc), o Mahout é o meu principal foco de estudos ultimamente e se basea no Hadoop (mais abaixo)

Hadoop - Cloud computing for java masses

Mas de todos os projetos que estão sob a tutela do Lucene, um em particular se destaca. O Hadoop. O Hadoop começou como um subprojeto lucene, mas hoje já se elevou a categoria de subprojeto apache. O Hadoop é uma implementação do famoso algoritmo Map-Reduce do google. Tentando resumir muito brevemente a idéia por de trás deste algoritmo, o que ele faz é segmentar o trabalho a ser executado (vamos imaginar que voce precise de ordernar uma lista de 10^16 elementos), a chamada map fase, e então os trabalhos são divididos entre nós do cluster que executam apenas um pequeno trecho. Ao final, a fase de Reduce junta os pedaços para completar a execução.
A filosofia por de trás do Hadoop é muito bacana. Aplicações tradicionais tendem a mover o dado (que se encontra normalmente centralizado em um SGDB) e distribuir a computação (um cluster de servidores de aplicação por exemplo). O Hadoop faz o oposto: Você segmenta seus dados em N partições, e então “move” a computação para cada um dos nós.
Isto é feito através do uso de um sistema distribuido de arquivos próprio do Hadoop (HDFS, que por sinal foi inspirado no google GFS). A computação é um jar que você gera e que contêm a implementação do Map-Reduce para sua tarefa específica. O Hadoop cuida da distribuição, ciclo de vida, e gerência de falhas de seus jobs.
O Hadoop merece vários posts apenas para ele, e estou preparando, mas no momento estou atolado com estudos e com a palestra de Collective Intelligence que vou ministrar no próximo evento em maio do MGJUG (mais informações em breve)
Para vocês terem uma breve noção do poder do Hadoop aqui vai alguns números interessantes:

• O Facebook usa o Hadoop, são 600 servidores com 2 processadores quad-core rodando os jobs
• O Hadoop venceu ano passado a competição de Terabyte Sort, um cluster com 910 máquinas conseguiu ordenar 1 terabyte de dados em apenas 207 segundos
• O Yahoo usa hadoop, acredita-se que cerca de 10.000 máquinas (isso mesmo, você leu correto) usem o hadoop para filtros de spam

Após estes números se vocês não acreditarem no poder do framework, não sei o que mais poderia convence-los.

Bem, depois de explicar um pouco o que é o Hadoop, vamos finalmente ao título do Post :). Bem o serviço de Elastic Computing da amazon (na minha opinião a mais sensacional revolução dos últimos 5 anos em TI), lançou ontem o serviço de map-reduce distribuido.

O bacana deste serviço é a facilidade de uso, e a possibilidade de usar centenas de máquinas para processamento em paralelo e pagar pouco por isso. Deixe-me ilustrar com um exemplo:

Uma máquina simples custa $0.015 a hora. Vamos supor que você queira ordenar o terabyte do concurso mencionado antes. Vamos usar 910 máquinas para isso. então: 910*0.015= 13,65

Bem, você gastaria apenas 13,65 dólares por 1 hora de processamento. Como foram gastos cerca de 4 min (levando pra cima o valor), então: T= 13,65/15 = 0.91. Agora, imagine você tendo que comprar 910 máquinas para processar alguma coisa?

A descrição do serviço se encontra em: http://aws.amazon.com/elasticmapreduce/

Abraços

Bem, essa aqui é uma dica simples e rápida :). No meu último post falei sobre clusters, e por isso mencionei o serviço de bindings do jboss 4.2. Meu amigo Elton, fez uma pergunta se referindo ao 5.0, bem, aqui vai a resposta:

No JBoss AS 5.0, clustering ficou quase identico ao 4.2 (obrigado RH pela estratégia em time que esta vencendo agente não mexe), uma das poucas difereças é o VFS e o novo MicroContainer que injeta os serviços.

Assim sendo, toda configuração de bindigins, ficou centralizada no arquivo $SERVER_NAME/conf/bootstrap/bindings.xml

Abaixo um trecho

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
30
31
32
33
34
35
36
37
38
39

<?xml version="1.0" encoding="UTF-8"?>
 
<deployment xmlns="urn:jboss:bean-deployer:2.0">
 
   <classloader><inject bean="bindings-classloader:0.0.0"/></classloader>
 
   <classloader name="bindings-classloader" xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY" import-all="true">
      <root>${jboss.common.lib.url}jboss-bindingservice.jar</root>
   </classloader>
 
   <bean name="ServiceBindingManager" class="org.jboss.services.binding.ServiceBindingManager">
 
      <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.system:service=ServiceBindingManager", exposedInterface=org.jboss.services.binding.ServiceBindingManagerMBean.class, registerDirectly=true)</annotation>
 
      <constructor>
         <!-- The name of the set of bindings to use for this server -->
         <parameter>${jboss.service.binding.set:ports-default}</parameter>
 
         <!-- The named sets of bindings -->
         <parameter>
            <bean name="ServiceBindingStore" class="org.jboss.services.binding.impl.PojoServiceBindingStore">
 
               <!-- Base bindings that are used to create bindings for each set -->
               <property name="standardBindings"><inject bean="StandardBindings"/></property>
 
               <!-- The sets of bindings -->
               <property name="serviceBindingSets">
                  <set>
                     <inject bean="PortsDefaultBindings"/>
                     <inject bean="Ports01Bindings"/>
                     <inject bean="Ports02Bindings"/>
                     <inject bean="Ports03Bindings"/>
                  </set>
               </property>
            </bean>
         </parameter>
      </constructor>
 
   </bean>

Note que nas linhas 27-32 estão definidas as configurações de portas, logo abaixo (omitido no post) estão cada uma das configurações com os respectivos nomes (ports-default,ports-01,ports-02,ports-03).

Para alterar as portas da sua instância, basta modificar a linha 17, após boss.service.binding.set. Pronto, agora ao iniciar seu JBoss ele já estará rodando em outra configuração de porta. Bem mais simples não é? Por default o AS agora já executa o binding service.

Espero que o pequeno post seja de ajuda.

Abraços