Ankiewsky Blog

Clebert Suconic, É um JBoss Core Developer que já passou pelo JBoss Cache, JBoss Serialization e atualmente está no JBoss Messaging. Clebert é sempre uma ótima referência de talento brasileiro na JBoss,  ele foi o criador e é atual Project Lead do JBoss Profiler, a ferramenta capaz de realizar testes e profiler vários Ambientes de Servidores de Aplicações , exemplo Sun Java System Application Server e claro o JBoss AS.

Já havia usado o JBoss Profiler inúmeras vezes na minha antiga empresa, aliás o Profiler nasceu por lá , visto que Clebert também trabalhou para a Summa. Estamos agora juntos com várias pessoas da comunidade, incluindo pessoas da Europa e até Japão, trabalhando na versão 2.0 do JBProfiler.
Várias novidades, estarão vindo no JBoss Profiler 2.0, entre elas esperamos a integração 100% Java para coleta de snapshots, assim como um webconsole novo, com alguns novos gráficos e todo construido utilizando JBoss Seam. Bom, novidades deste projeto, tentarei expor um pouco a respeito delas por aqui. A principal novidade é a nova logo do Projeto. Espero que gostem.

Pierre Fricke, Diretor de Produtos da JBoss, escreveu um ótimo artigo sobre SOA, muito mais de visão de negócio e aplicabilidades, problemas e vantagens do que sobre Tecnologia, vale a pena conferir, leia aqui:

Artigo de Pierre Fricke

Dias atrás publiquei no meu blog do java.net um post que tenta ensinar jBPM para as pessoas baseado/comparando ao Struts Framework. Uma das melhores formas de aprendizado ainda é com base na comparação, esse é um dos exemplos que tenho mostrado no Brasil, e até essa semana em Londres, para mostrar o quao simples pode ser uma máquina de processos.

Linguagens de Processos

O JBoss jBPM é mais que um framework de BPM, de fato vamos além disto, onde temos uma máquina de execução de processo agnóstica do ponto de vista de que linguagens, hoje suportamos JPDL, BPEL e Seam Flow, com a ajuda do JBoss ESB também podemos até suportar algo baseado no Rules Flow, ou na sua linguagem desde que você forneça o provider para tal. Ainda que BPEL seja uma linguagem apontada para o "padrão", na minha ótica é uma linguagem "não elegante"[1] e com vários buracos e necessidades ainda nao supridas, porém se seus processos envolvem apenas WebServices em termos de orquestração, BPEL atende, porém se você precisar de interações com usuários (Swinlanes), BPEL começa a ser problemático [1]. Ao passo que com JPDL, que é a linguagem padrão de representação do processo no jBPM, necessidades como estas relacionadas a tarefas associados a humanos(usuários) é algo extremamente simples.

Básico de um Processo

Longe da pretenção desse post explicar Finite State Machine ou Diagramas de Estado, mas estes conceitos em mente lhe deixam claro a cerca de processos. Basicamente tenha em mente que um fluxo tem um início e fim, e nesse caminho uma série de caminhos normais e fluxos alternativos. Veja o simples exemplo da entrega de um relatório de despesas:

Entre o início e fim, temos uma atividade, que tem o nome "entrega-report". Esta caixinha por sua vez possui eventos, estados, informações, variáveis que podem ou não estar associados a ela. Por exemplo, para sair dessa caixinha, um bean com as informacoes do relatório deve estar preenchida.

Criando um Servlet para ser o Gerenciador/Controller de execução de Processos

Para explicar a máquina de processos, vamos criar um servlet inspirado no ActionServlet do Struts, que pega o valor da ação com base em um parametro, e entrao chama todo o engine do jBPM e faz a máquina ir para o tarefa do processo apontado através de uma simples URL ou Form Html, veja o exemplo:

Como você pode ver, antes de chamar o método signal, que funciona como um "pescoção" ou um "pedala robinho" na tarefa do processo, fazendo com que ela seja executada, nos adicionamos o request e o response do Servlet no contexto da máquina de processo. Isso serve para mostrar a idéia que você pode injetar o que quiser no contexto da execução do processo, assim como você faz no contexto de uma sessão http.

Criando a Action (ActionHandler)

No jBPM o que basicamente você precisa é criar uma ação que no nosso caso vai ser invocada depois que sairmos(node-leave) da tarefa(Caixinha), e veja que do jBPM context podemos dizer até para que página a aplicação deve ir pois temos tudo que precisamos para fazer o jBPM interagir num contexto Http.

Espero que esse exemplo, possa demonstrar a simplicidade de usar máquinas de processos, daqui pra frente estou certo que você poderia usar esta mesma abstração para Actions do Swing, ou usar isso com qualquer outra tecnologia cliente.

[1] - Porco, bem porco!

[]s

Olá amigos, é com grande prazer que disponibilizo algumas entrevistas com meus amigos do time JBoss no Brasil, o primeiro deles é o Edson Tirelli, Core Developer do JBoss Rules, que nesta entrevista fala um pouco do seu trabalho com e para a Comunidade, além de seu trabalho na RedHat Brasil.

1 - Edson noss fale a repeito do que for interessante da sua vida pessoal, idade, hobbies, manias e etc?

Tenho 28 anos, sou casado, nasci em Santa Catarina e moro em São Paulo desde 2001. Curto muito viajar (eu e minha esposa adoramos praias desertas (difícil) e de águas calmas, para mergulhar). Gosto muito de assistir filmes e tenho um grupo de amigos que se reúne frequentemente para jogar eurogames.

2 - Faça um breve resumo de sua carreira antes de você entrar para a JBoss, a division of Red Hat ?

Me formei Bacharel em Ciências da Computação pela Universidade Federal de Santa Catarina no fim de 1999 e logo depois fui contratado pela Automatos. Fui trabalhar no Rio com desenvolvimento de sistemas de gerenciamento de Servidores de Missão crítica. Um trabalho bastante desafiador e de baixo nível, mas muito interessante. Em 2003, já em São Paulo, comecei a trabalhar na vertical de Telecom e fui para Convergys, uma grande multi-nacional no desenvolvimento de sistemas de Billing para Telecom. Lá atuei até 2004 como Gerente de Desenvolvimento. De lá fui para a Auster, que também desenvolve sistemas para a vertical de Telecom, trabalhando como Arquiteto de Soluções. Em todo este tempo, tive oportunidade de trabalhar com tecnologias que vão do C/C++ em ambientes unix pouco conhecidos como o Tru64, até aplicações java em cluster rodando em Mainframes zOS. Foi tudo sempre muito divertido.

3 - Open-Source é importante para você? Se sim, como o Opensource mudou o a concepção da tecnologia nos dias de hoje?

Comecei a trabalhar com open-source em 2002, justamente com o JBoss AS. De lá pra cá, minha impressão é de que as comunidades se fortificaram, a disponibilidade e a qualidade dos produtos aumentou e os modelos de negócio em torno do software open-source se solidificaram. Acho que o software open-source funciona cada vez mais como um catalizador na indústria de TI, acelerando a inovação e gerando demanda por alta tecnologia. Além disso, devo dizer que não conheço uma empresa sequer que consiga agregar a proporção de profissionais de qualidade que um bom produto open source consegue. Desenvolvedores open-source contribuem não porque são obrigados, mas porque gostam do que fazem, e isso por si só já é o maior estímulo possível para um trabalho bem feito. No campo pessoal, devo dizer que nunca aprendi tanto tecnicamente como nos últimos anos, desde que comecei a contribuir. Esses mesmos profissionais de alto nível técnico, de bom grado, ensinam e ajudam a todos os que se dispõem a contribuir também, passando adiante conhecimento, e impulsionando ainda mais a inovação. Tal ambiente é muito diferente de um ambiente corporativo tradicional, onde muitas vezes, infelizmente, a competição sobrepuja a inovação como maior objetivo de alguns profissionais.

4 - Como você ingressou no projeto Drools (antigo nome do JBoss Rules)? Você já começou ganhando um salário para isso?

Foi em 2004. A empresa em que eu trabalhava estava projetando um sistema especialista e eu fui encarregado de pesquisar e definir a plataforma e as tecnologias que adotaríamos. Ao final da avaliação, o Drools foi um dos produtos adotados. Comecei a utilizá-lo como usuário, mas me empolguei tanto com a área de IA e os Engines de Regras que acabei me juntando a comunidade e em 2005, comecei a contribuir para o projeto como um hobby. Não recebia salário por isso e contribuia em minhas horas vagas e fins de semana, mas acho que foi aí que entendi o valor de se tornar um desenvolvedor open-source. Construir algo que ajudará milhares de pessoas mundo afora e saber que é você quem está fazendo a diferença. Entrar em contato direto com as pessoas que você vê nos sites, lê nos livros, vê na televisão, e descobre que são pessoas como você. Aprender com elas (como alguns dizem: "beber direto da fonte!"), crescer profissionalmente, e quem sabe um dia, ser também você um ponto de referência para a comunidade mundial. Alguém que fez a diferença.
Em 2006, entrar para a Red Hat foi uma realização. Significou para mim, poder fazer em tempo integral aquilo que eu fazia somente por hobby. Significou entrar no olho do furacão. Entrar em uma das empresas que está no centro do movimento open source e que investe em seu crescimento e maturação. Realmente foi muito bom.

5 - Quer dizer então que a forma mais fácil de entrar no projeto é mandar o curriculum para você ou seu gerente?

A melhor forma é juntar-se a comunidade. Escolha um projeto que tenha a ver com áreas de interesses suas. Entre no IRC, fóruns e listas de discussões desse projeto. Conhecimento e experiência prévios são totalmente dispensáveis. Os desenvolvedores open-source são geralmente muito prestativos e procuram sempre ajudar, especialmente os novos usuários e contribuidores. O importante é gostar do que se faz, ser pró-ativo e não ter vergonha de aprender. Trabalhar em pesquisa e desenvolvimento (R&D) é trilhar caminhos nunca antes trilhados. É gerar conhecimento e moldar a tecnologia. Os projetos open-source não possuem um dono. Todos podem contribuir, e assim que começar a contribuir, você passa a fazer parte da equipe. É claro que existem muitas necessidades já mapeadas em projetos open-source, e conversando com a equipe de desenvolvimento de cada projeto, estes podem indicar áreas e tarefas pelas quais você pode começar a contribuir e que ajudarão no início de seu trabalho.

A Red Hat por sua vez investe constantemente nos projetos open-source através da contratação dos contribuidores mais prolíficos. E o melhor de tudo, como citei anteriormente, é que estes contribuidores são contratados para fazer em tempo integral aquilo que faziam como um hobby. Ou seja, seu currículo deixa de ser um papel e passa a ser o resultado do seu trabalho.

6 - Como é o dia-a-dia de um Core-Developer de produtos da JBoss e morando no Brasil?

Confesso que é bastante diferente de todos os trabalhos que já tive. À começar pela logística: os principais contribuidores do Drools/JBoss Rules ficam no Brasil, Canadá, Inglaterra e Austrália, com alguns contribuidores espalhados em outros países do mundo. Nosso principal meio de comunicação é o IRC, mas também usamos VoIP, IM e e-mail. A RedHat tem escritórios no Brasil e alguns dias por semana os desenvolvedores brasileiros se encontram para trabalhar no escritório. Nos outros dias, trabalhamos remotamente em home office. É impressionante como é bom e o quanto aprendemos quando passamos a trabalhar em projetos onde as barreiras geográficas desaparecem. Dos aspectos técnicos até a troca de experiência cultural entre a comunidade, o aprendizado é contínuo.

7 - Qual mensagem você deixa para vários desenvolvedores da comunidade Java como forma de incentivo profissional?

O Brasil é sem dúvida nenhuma um expoente em termos de desenvolvimento open-source e tecnologia Java. Vemos isso todos os dias, de projetos e contribuições fazendo sucesso mundo a fora, até eventos e convenções como o JavaOne onde a presença brasileira é sempre marcante. Então, para quem não participa ainda, junte-se a nós. Entre em contato, comece a contribuir e coloque o seu nome na história. Venha fazer a diferença!

Edgar: Muito obrigado Edson pela Entrevista!

Edson Tirelli - Core Devoper JBoss Rules.

Quando eu trabalhei em um grande projeto na Caixa em Brasília, usavamos o JAXB 1.x para fazer o data binding(marshall/unmarshall) de objetos Java para XML e vice-versa.

Componentes como o XStream da CodeHaus, facilitam bastante a vida, mas ainda é complicado dependendo do cliente homologar uma solução como esta. Sendo assim, vamos ao padrão, já que o JAXB faz parter do WebService Developer Pack, ou seja: Padrão estabelecidos em JSR e controlado pelos mebros no JCP, entre as principais melhorias, podemos citar:

• Bibliotecas de Runtime menores economizando assim no uso de memória.
• Muito menos classes são geradas se compararmos com o JAXB1.0. Para cada tipo complexo, a nova versão gera uma classe para direto ao invés de criar uma interface e uma implementação.
• Suporte a todos os tipos de XML Schema.
• Adição de tipos parametrizados.
• Suporte a bind Java-to-XML com as anotações do pacote: javax.xml.bind.annotation package.

Sendo assim, vamos a um pequeno tutorial, para mostrar como pode ser simples realizar o binding de objeto para XML e vice versa.

1. Faça o Downlaod do JAXB no site: http://jaxb.dev.java.net
2. Execute o JAR que é o instalador: java -jar jaxb.jar e instale num lugar do tipo /opt/java/jaxb ou c:/java/jaxb
3. Não vou citar IDE's, por isso criei toda uma estrutura baseada em ANT, sendo assim criei um arquivo chamdo de build.properties[1] que fornece informações para o build.xml, já que há uma TASK do JAXB, entao vamos usá-la para que esta realize as tarefas que desejamos, que é gerar as classes que vão estar visíveis pro contexto do JAXB[2].
4. A Estrutura do projeto é simples:

1. src (pasta com fontes)
2. gen-src (pasta com os fontes gerados pelo JAXB)
3. classes (pasta com as classes compiladas)
4. schema (caso você queira guardar os XSD's aqui[3])
5. lib (pasta com bibliotecas)

Referências

(more...)

O que você acha de transformar usuários em efetivos tomadores de decisão quando falamos de regras de negócio. Sabe aquele desejo antigo de UML para Analistas e Código para Programadores, ou melhor ainda: Caixinhas, Bolas, Setas e etc ligadas forma a execução de um processo do sistema! Parece loucura, mas não é. Usando BPM, ESB, JBI e etc, temos várias mecanismos para encaixar essas facilidades.

Errata:Sendo assim podemos criar uma Domain Specific Language (DSL), uma linguagem que é especifica para usuários, onde eles possam entender o que está acontecendo nas regras de negócio do sistema. É mais ou menos isso que o

Sendo assim, criamos um arquivo .DSL , que vai permitir que utilizemos uma linguagem natural que é especifica para usuários, onde eles possam entender o que está acontecendo nas regras de negócio do sistema. É mais ou menos isso que o projeto que estou ajudando tem que fazer, então vamos a um pequeno exemplo: PT_BR.dsl :

E com uma alteração no Engine de Leitura de Regras:

Agora, temos a possibilidade de trabalhar 100% com DSLs, sendo assim, em idiomas humanos, sendo assim inglês, francês e etc.

Consulte o site do JBoss Rules

Abraços

Edgar

O Summanoides, é um projeto de capacitação e reciclagem dos profissionais da Summa que tem interesse em participar. Nesta primeira fase, o estudo foi em cima de Enterprise Java Beans 3.0, onde apresentamos os novos recursos, as diferenças das specs anteriores.

Os resultados foram bem interessantes, além da melhora do desempenho de algumas pessoas que no início eram mais travadas para se comunicar, no final desta fase 1, tivemos grandes avanços.

Na sequência estaremos abordando em Janeiro: Java Server Faces, e em seguida SOA (Services Oriented Architecture), e para reunir e aplicar os conceitos, será desenvolvido um mini ERP para a área de RH da empresa, visto seu atual crescimento. Esse mini-erp, deverá ser usado no Soujava, e a idéia é que ele seja Opensource também!

Alguns resultados:

• Palestra: Novidades do EJB 3.0 (Soujava/Dezembro 2006 - Bruno Rossetto e Homero Damico)
• 2 Novos Blogs:

• Raphael Winkler

• Bruno Rossetto

Projetos como estes, são grandes motivdadores para você vir trabalhar conosco, fique atendo que a companhia está contratando bastante novos profissionais.

Abração

Edgar Silva
Summa Technologies, Inc

Elegi o Plone como uma das ferrramentas que tentarei usar como base de conhecimento (knowledge-base), para que dentro da empresa possamos ter mais controle do que estamos fazendo, nossos eventos, assim como a parte de humor no portal que sempre é super interessante.

Uma grande ajuda para quem não via o Plone há 4 anos foi esse site aqui: http://docs.neuroinf.de/PloneBook , espero que ele possa ser útil para quem precisar de algo.

Uma coisa legal do Plone, além de ser escrito em Python, é que construir entrada de dados, estilo "Lotus Notes", é uma tarefa simples, além de ter um mecanismo de pesquisa muito bom, o Plone tem uma das instalações mais plug-and-play que já vi, até no MacOS, tudo rodou bem, sem gerar conflitos com as outras versões de Python que tinha antes.

Alguns amigos não curtiram muito a idéia do Plone ser em Python, mas recentemente no TheServerSide, ele divulgaram a notícia que eles devem usar na plataformaZope o JEE, de tudo a única coisa que eu mais gostei foi do uso do JBoss SEAM.