… e da …

…da galera da SEA.

 Reaceso o mercado de servidores de aplicação pela RedHat, foi hora de dar um colorido extra à administração de ambientes JBoss. Utilizando-se de uma base de software já criada para monitoração e controle de sistemas (hyperic), a RedHat criou o JBoss Operations Network, vulgo JON (não John), que rapidamente se tornou na menina dos olhos para potenciais assinantes de subscrição JBoss.

O JON é uma ferramenta de administração, monitoração e controle de servidores JBoss.

Figura 1 - JON

Mitos

Existem alguns mitos em torno do JON que precisam ser desfeitos antes que se desenvolvam.

1. O JON é proprietário?

NÃO! Já foi, mas não é mais. Hoje o JON é apenas a versão "enterprise" de um projeto open source chamado Jopr, que é construído sobre outro projeto open source chamado RHQ. Ou seja, assim como o RHEL está para o Fedora e o JBoss EAP está para o JBoss.ORG, o JON está para o Jopr. Este é o modelo da RedHat.

Figura 1 - RHQ Project Homepage

Figura 2 - RHQ Project

Figura 3 - Jopr (apesar da logo ser do RHQ, a tela é do Jopr).

A propósito, vale a pena dar uma lida nesta entrevista com Chris Morgan, um dos líderes do projeto Jopr.

 

2. O JON resolve todos os meus problemas de monitoração?

NÃO! Não é responsabilidade do JON a monitoração e controle de ativos de rede, máquinas, sistemas operacionais, bancos de dados etc. Ele até realiza parte deste trabalho, mas não é o seu foco. Seu foco é no servidor de aplicação JBoss (que roda sobre um SO, que roda sobre um hardware, que roda sobre uma rede….) e em seus sub-elementos. Para o acompanhamento de outros níveis, acima ou abaixo do app server, existem outras ferramentas (livres) que, se devidamente utilizadas junto ao JON, formam uma suite imbatível para administração pró-ativa de toda infra. Outro dia eu falo dessas outras ferramentas (os quadrinhos cinzas da figura 4 abaixo).

Figura 4 - Monitoração, cada um no seu quadrado

Basicamente, o JON possui 3 focos distintos:

(a) monitoração e controle
(b) distribuição de software
(c) disponibilização do conhecimento

De longe, o primeiro item, (a), é o que está mais maduro na ferramenta. Por ele, é possível realizar a coleta de métricas dos recursos inventariados pela ferramenta, analisá-las visualmente, configurar alertas com base nas mais diversas condições e estabelecer políticas preventivas de administração.

Figura 5 - JON, Monitoração

Figura 6 - JON, Controle

Os demais itens (b) e (c), apesar de atrasados quanto ao primeiro, já tiveram seu desenvolvimento inicalizado e demonstram-se em grandes promessas para um futuro próximo. Por distribuição de software, entende-se a capacidade do administrador do JON controlar e comandar, remotamente, a distribuição de novas releases e patches das ferramentas homologadas para as demais áreas de sua instituição. Já o item (c), disponibilização de conhecimento, tem o propósito de agregar num ponto único todas as informações relevantes para usuários de ferramentas específicas da JBoss. Pelo discurso oficial, não faz sentido que um profissional que paga por um contrato de subscrição de JBoss tenha que garimpar na Rede a solução para seus problemas. Todos os problemas conhecidos deve ser catalogados e suas respectivas soluções devem estar disponíveis através da ferramenta.

Figura 7 - JON, Distribuição de Software

 

3. O JON faz monitoramento em tempo real?

NÃO! Não é do propósito do JON a monitoração em tempo real dos servidores. Sua proposta principal é de viabilizar a consolidação de uma base histórica de dados a partir da qual pode-se extrair informações úteis para a tomada de decisões pró-ativas para adequação do ambiente a tendências de acesso. Para monitoramento em real time, é melhor buscar uma ferramenta de profiling, como o JBoss Profiler que, by the way, foi concebida e é hoje mantida por brasileiros.

Figura 8 - JBoss Profiler

Esta imagem é do JBoss Profiler 1.0. A versão 2.0 já tem o beta disponível e o Edgar está trabalhando na transformação do Profiler num plugin do JON.

Figura 9 - Plugin do JBoss Profiler para o JON

 Conceitos

O principal conceito do JON (e seus familiares Jopr e RHQ) é recurso. Por recurso, entende-se plataformas, servidores e serviços. Plataformas são máquinas fisicas ou virtuais (e.g. Windows, Linux…). Servidores são coisas que rodam dentro das plataformas (e.g. JBoss App Server, Tomcat, Apache, Postgres, IIS…). Serviços são coisas que rodam geralmente dentro de servidores (ou também dentro de plataformas) (e.g. Stateless Session Bean, Datasource, Connection, Web Application, Virtual Host…). Cada servidor possui um conjunto de serviços próprios. Nos exemplos dados, Stateless Session Beans é um serviço do servidor JBoss App Server, mas Virtual Host já é um serviço do servidor Apache HTTP Server.

Por este mesmo raciocínio, cada tipo de recurso possui métricas e controles próprios. Assim, as métricas disponíveis para uma plataforma Linux, por exemplo, não são as métricas disponíveis para uma plataforma Windows ou um servidor JBoss. Veja os exemplos abaixo:

Métricas de uma Plataforma Linux

• Free Memory
• Used Memory
• Total Memory
• Free Swap Space
• Used Swap Space
• Total Swap Space
• Idle
• System Load
• User Load
• Wait Load
• … 

Métricas de um Servidor JBoss

• Active Thread Count
• Active Thread Group Count
• JVM Free Memory
• JVM Max Memory
• JVM Total Memory
• Transactions Active
• Transactions Committed
• Transactions Committed per Minute
• …
•  

Métricas de um Serviço Datasource

• Total Connections
• Available Connections
• Active Connections
• Connections Created
• Connections Created per Minute
• Connections Destroyed
• Connections Destroyed per Minute

Arquitetura

O JON segue uma arquitetura Servidor/Agentes (como o Nagios). Normalmente, instala-se 1 JON Server e N JON Agents. Para cada plataforma a ser monitorada, um JON Agent deve ser instalado. O agente do JON é o responsável por realizar a descoberta dos servidores e serviços da plataforma onde está instalado, coletar localmente suas informações e enviá-las periodicamente ao servidor do JON para serem consolidadas e apresentadas visualmente. É também responsabilidade do agente receber instruções enviadas pelo servidor e processá-las localmente, como, por exemplo, a reinicialização de um JBoss.

Cada agente, por sua vez, é composto por um conjunto de plugins. Cada plugin define um escopo de funcionalidades do agente. Então, no fundo, no fundo, o conjunto de métricas coletadas pelo agente e o conjunto de operações que podem ser comandadas remotamente em qualquer recurso dependem essencialmente do conjunto de plugins disponíveis dentro do agente.

Na prática, o que distingue o RHQ do Jopr é basicamente o conjunto de plugins embutidos em seus agentes. A grosso modo, o RHQ não possui os plugins de JBoss, Hibernate e Tomcat que o Jopr tem. Isso quer dizer que no Jopr é possível monitorar JBoss, Hibernate e Tomcat e no RHQ, não. Simples assim.

Mas, o melhor de tudo, é que a partir do momento em que o JON passou a compartilhar o codebase do projeto RHQ, na versão JON 2.0, a arquitetura de plugins dos agentes foi aberta. Com isso, tornou-se possível a nós, desenvolvedores ordinários, criar plugins para o JON. Isso quer dizer que, desde então, é possível monitorar qualquer software pelo JON, desde que um respectivo plugin seja desenvolvido.

Por isso que, recentemente, uma penca de plugins apareceram na net. Dentre eles, plugin pro Oracle, Hudson, Continuum, Jira, MySQL etc. Isso só enriquece o JON/JOPR/RHQ e todos nós só temos a ganhar.

BAM

A última moda do JON, entretanto, é seu uso como instrumento de Business Activity Monitoring.

Utilizando-se de sua infra-estrutura de criação, distribuição e gerenciamento de plugins, tem-se extendido o JON para monitoração e controle de aplicações corporativas. Neste sentido, define-se a coleta e computação de métricas com significado de negócio e beneficia-se de toda estrutura do JON para análise dessas informações e definição de alertas quando da extrapolação superior ou inferior de baselines pré-definidos. Por exemplo, num sistema do Ministério da Educação, pode-se criar um plugin para o sistema do ENEM que aponte o número de inscrições por minuto, ou a taxa de variação das vendas de uma empresa privada ou ainda o ainda a carga horária média de trabalho de minha equipe de consultoria. Aqui, a imaginação é o limite.

Legal, né?

Futuro

 Muito tem sido investido na plataforma RHQ/Jopr/JON. Aparentemente, a RedHat tem pretensões de fazê-la pivô de administração de seus projetos.

Se você é administrador JBoss, faça o teste. Se você é desenvolvedor Java, aproveite a oportunidade para a construção de coisas interessantes. Se quiser uma ajuda, utilize o gerador de plugins do Heiko que, durante a construção deste post, foi lançado e atualizado.

Se não for tirar férias em Janeiro, aproveite e assista o Webinar sobre Jopr que será realizado no dia 13.

 

[]s e boas festas!



 

 

Sua empresa já usa Wiki?

A gente começou a usar o Coral há pouco mais de 2 anos pra documentar projetos. O Coral tinha a vantagem de ser open source, usável, versátil, simples e bem feito. Foi uma customização nossa do tiddlywiki.

Ainda tem o que evoluir, mas observem o tanto de coisa que já fazemos com ele: no começo, ele era usado apenas como a cola entre repositórios, processo, comunicações e documentações de fato. Depois, avançou para condensar manuais de ferramentas, tutoriais, procedimentos, atas de reuniões, planejamento estratégico, organizar a vida pessoal dos colaboradores, passar pendências em saídas de férias………………….

Hoje, não só a área técnica usa o Coral, mas toda empresa. E para os mais diversos fins. Vou destacar algumas utilizações mais populares e que acho mais interessantes:

PMO

 

Como a diretoria pode ter uma visão geral de como andam os projetos da empresa?
Basta acessar esse painel, que funciona como um PMO bem simples e embrionário, mas tem atendido bem a nossas necessidades. Nele, são listados os projetos e através de cores, alguns indicadores e notas, pode-se ver o que está acontecendo. Caso queira maiores informações, a pessoa pode navegar pelos detalhes dos projetos, e acompanhar as notas da equipe sobre o que vem acontecendo. Cada projeto tem visão geral e histórico de acontecimentos. É lá que registramos nossas retrospectivas, lições aprendidas, andamento dos sprints, medidas de velocidade e etc. Só o suficiente.

RH

 

Além de armazenar dados dos colaboradores, currículo, certificações e etc; começamos há pouco tempo a utilizar um quadro de medalhas, em que distribuímos medalhas de ouro, prata ou bronze aos colaboradores. Isso ocorre de acordo com critérios como iniciativa, geração de resultados, satisfação dos clientes, etc. Em caso de resultados negativos ou reclamações, as medalhas são retiradas. Cada medalha tem seu fim e seu peso. Esses resultados são levados em consideração na avaliação do colaborador junto a outros fatores, e isso é revertido em aumentos de salário e/ou benefícios. Achamos que é uma forma transparente e divertida de tratar desse assunto sempre tão sério e delicado.

CRM

A área comercial mantém rastro das comunicações e negociações com nossos clientes. Isso facilita trabalhar com diversos negócios e reassumí-los sem perdas do ponto em que pararam. Também facilita passar negociações entre vendedores e manter conhecimento sobre o nível de satisfação dos clientes.

Se gostarem, baixem e experimentem! É de graça! Adapter, é aberto!

O resto depende só da criatividade de vocês.
Existem 1001 maneiras de se utilizar o Coral, qual é a sua?
[]s Willi

Está na hora de desovar uma série de posts sobre JBoss que há muito orbitam em minhas idéias. Vou começar por um discurso que eu repito em várias ocasiões e que acho que está na hora de ficar registrado para a prosperidade.

Todo mundo já deve ter ouvido falar dos altos e baixos da tecnologia Java. No lançamento da plataforma J2EE (+/- 2000), houve o boom. Passados uns anos, fracassos em massa em projetos críticos e a crise dos EJBs. Rod Johnson então põe ainda mais lenha na fogueira com o lançamendo de seu livro J2EE Development Without EJB. Por algum tempo a tecnologia ficou em cheque no mercado (boom do Spring), até que a comunidade resolveu reoxigená-la (JPA, EJB3…). De lá pra cá, a plataforma sofreu grandes ajustes e retoma, gradativamente, sua moral sem, entretanto, o mesmo glamour e frisson de outrora, tendo que brigar agora com concorrentes emersos de sua depressão (Ruby, Python, PHP…).

No lado dos fabricantes de servidores de aplicação J2EE, a mesma história se refletiu. O início do século representou a corrida atrás do ouro e dezenas de empresas entraram na briga dos servidores J2EE. Na metade da primeira década, fracassos de projetos, frustrações tecnológicas e a seleção natural das espécies. Vários produtos de mercado desapareceram. Na sequência, houve a reoxigenação da tecnologia e a establização dos mercados. Quem tinha que adotar J2EE como plataforma de desenvolvimento, adotou. Quem tinha que definir seus servidores de aplicação, definiu. Daí, observa-se a segmentação do mercado entre 4 principais players (Brasília/DF): IBM com Websphere, BEA com Weblogic, Oracle com OAS e Sun com SunONE.

Nesta época, o mundo já conhecia o servidor de aplicações J2EE livre JBoss que, apesar de amplamente respeitado pela comunidade tinha, na esfera pública federal de Brasília, adoção limitada a ambientes de teste ou desenvolvimento. Entretanto, em 2006, após a aquisição do JBoss pela RedHat, e seu consequente estabelecimento operacional em terras brasilis, em Abril de 2007, as bases estabelecidas do mercado brasiliense de servidores de aplicações começaram a ruim.

Curioso ou não, a partir do momento em que alguém se apresentou na Esplanada como representante oficial (e legal) do servidor cuja pressão pela adoção era gerada a partir dos níveis mais baixos da produção e não por articulações político-comerciais de alto escalão, observou-se no cenário brasiliense um processo de migração em massa de órgãos já estabelecidos em produtos proprietários para a solução livre agora da RedHat.

Com um modelo de negócio baseado em venda de contratos de subscrição, em pouco mais de um ano o  servidor de aplicações livre JBoss tem se tornado em Brasília uma das principais plataformas Java de produção, já com vários casos de sucesso divulgados na blogosfera. Neste modelo, muito recorrente no mundo do software livre, o cliente possui todo conforto e autonomia para a tomada de decisões, além de se permitir errar sem grandes prejuízos. Com o recurso necessário para custeio de uma licença proprietária sustenta-se anos de um contrato de subscrição com direito a suporte, acesso imediato aos últimos bug fixes, patches, notícias relevantes e fórum direto com os core developers da tecnologia. E, além do esperado suporte ao servidor de aplicações, todos os projetos desenvolvidos sob a marca JBoss são passíveis de suporte corporativo da RedHat.

Assim como seu sistema operacional, a RedHat manteve todo o código livre e o desenvolvimento do servidor de aplicações sob a dinâmica da comunidade open source. E, assim como o RHEL está para o Fedora, assim está o JBoss.EAP para o JBoss.ORG.

A vinda da RedHat/JBoss para o Brasil reaqueceu um mercado que há muito hibernava. Em sua curta história sob as asas da RedHat, o produto tem adquirido forma de gente grande, com adornos que não deixam a desejar a nenhuma das soluções-proprietárias-intergaláticas-com-promessas-mil. Evoluções recentes, entretanto, o posicionam além do crescimento tradicional de mercado. Discutiremo-las em outra ocasião. A quem estiver neste mercado corporativo, sugiro ficarem antenados.

[]s

A Fratech, com o apoio da SEA, abriu uma nova turma para o workshop de Modelagem Ágil e DDD que será realizado nos dias 12 e 13 de dezembro de 2008 em Brasília.

Aprenda a modelar software de forma orientada ao negócio e utilizando técnicas de modelagem ágil, neste workshop focado em práticas e dinâmicas. Saia Planejando, Modelando e Desenvolvendo Softwares com Produtividade.

Alguns dos tópicos abordados:

• O que é Domain Driven Design
• Criando uma Ubiquitous Language
• Documentação e o DDD
• Introdução ao Model Driven Design
• Arquitetura em Camadas (Layered Architecture)
• Domain Objects
• Supple Design
• Refactoring segundo DDD
• Design Estratégico (Strategic Design)
• Engenharia de requisitos com Scrum, XP e FDD
• O que é Modelagem Ágil
• Como e quando usar as técnicas de MA
• Documentação Ágil
• Explorando a visão arquitetural
• M3-Modelagem Baseada em Mapas Mentais
• UML em Cores
• Uso de prototipação
• Agile Draw

Instrutores:

Felipe Rodrigues de Almeida - é Arquiteto de Sistemas com experiência de 5 anos em desenvolvimento de sistemas distribuídos. Atualmente trabalha em projetos pela Fratech, atuando na arquitetura de aplicações críticas. Participa atvamente do desenvolvimento do framework Struts2 e mantém o projeto open-source BoxSQL. Palestrante no QCon em Londres. Passa o tempo livre curtindo e cuidando de seus 3 cães.

Manoel Pimentel Medeiros - é Engenheiro de Software, com mais de 15 anos na área de TI, atualmente trabalha com projetos Java pela Rhealeza(SP). É Diretor Editorial da Revista Visão Ágil, Membro da Agile Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil. Já escreveu para importantes revistas e portais especializados no Brasil e no exterior. Possui as certificações CSM e CSP da Scrum Alliance.

Para saber mais sobre Domain Driven Design leia o seguinte artigo

Participamos do I Fórum de Software Livre – SWL promovido pelo Centro de Computação de Aeronáutica de Brasília, muitas coisas interessante aconteceram e podemos destacar que:

1. Foi um evento muito interessante com a participação das demais forças (Exército, Marinha, PMDF). A grande participação dor organismos militares provou que o evento teve seu direcionamento para  um público bem definido e exigente. Outras instituições públicas também participaram como o SERPRO, DATAPREV, Min. Planejamento SLTI, CAIXA.

2. Muitas palestras interessantes, por exemplo, os processos de migração para SWL do Cindacta, do Comando da Aeronáutica, da Polícia Militar do DF, do SERPRO, da DATAPREV. O nível de palestras estava muito interessante, devemos sugerir que no próximo ano sejam menos paletras no mesmo dia, pois ficou muito puxado. Tive o prazer de dar uma palestra com o título “Formas de contratação em software livre”, que tinha por objetivo orientar gestores a contratar serviços de SWL através de licitações, mostrando vários modelos para isso. Segue a apresentação conforme prometido no evento.

 

3. Cases de sucesso da SEA Tecnologia sendo expostos nas palestras pelo próprios clientes. Principalmente os cases Sigadaer/Aeronática, muito falado em nosso blog, e a migração do MS-Exchange para Zimbra na Polícia Militar do DF. Foi muito gratificante ouvir nossos clientes tecendo elogios à SEA e expondo seus projetos realizados em parceria conosco.

4. A liberação do código fonte, pela Aeronáutica e pelo Exército, do código fonte do SIGADAER para o Portal do Software Público. Um passo importante para as forças armadas, pois a Aeronáutica quebra barreiras internas e no meio militar sobre abertura de código fonte mantendo a soberania de nosso país.