Hoje consegui finalmente ler os Pipes do Yahoo e produzir uma saída singela, porém expressiva para nosso propósito: Condensar tudo o que nossa equipe faz durante o dia (commits de SVN, builds automáticos ou manuais, backups, emails, agendas, atualizações de wikis, worklogs do Jira, blogs, etc) e ejetar essa saída em....bem, ainda não sei exatamente :)
O Super Pipe
O pipe que montei foi este abaixo:
que na prática, é responsável por ler feeds diversos de vários locais (nos quais nossa equipe produz informação - por exemplo, um commit do SVN gera um Feed com um comentário de log, o qual é lido pelo pipe) e ejetar uma saída padronizada (em laranja na figura).
Essa saída é um típico JSON, que então uso como entrada na nossa arquitetura RESTFul.
Arquitetura
Na verdade, esse JSON é apenas uma das entradas, uma vez que outras são provenientes de locais que (ainda) não geram Feeds. Por exemplo, algumas tabelas de banco de dados atualizadas por sistemas de legado e calendários internos não publicáveis.
Todas essas entradas são interpretadas pelo que chamei de Producers, ou seja, classes produtoras de informação... que podem vir de qualquer lugar.
Os producers colocam as informações em uma base (ainda não sei se vou usar JMS ou vou fazer de outra forma para processar de forma assíncrona ou sei lá como).
Estando nessa base, os chamados Consumers são responsáveis por ler as informações que têm interesse e gerar algum resultado útil, tal como... hum, deixa eu ver... atualizar os Twitters pessoais ou da empresa ;) ou mesmo enviar SMS para os celulares dos plantonistas, no caso de emergências em clientes (por exemplo, o monitoramento JOPr indicar uma tendência para consumo de memória excessivo ou então a queda de um servidor JBoss em produção).
Um esboço primário disso é mostrado abaixo:
Observa-se que os producers e consumers são estensíveis. Na prática, estou configurando eles via um padrão "Quasi-Command", os quais são automaticamente escaneados e carregados se estiverem no classpath da aplicação.
NOTA: Sim, sim, eu sei. Também discuti com meu colega J. a possibilidade de usar um ESB (como o JBossESB) para isso. Mas daí o trabalho seria maior (no sentido de montar toda a plataforma operacional) e, principalmente, eu não teria a chance de voltar a programar depois de quase meio ano parado.
E o RESTFul?
Toda a arquitetura é montada com base em HTTP, usando uma sopa de letrinhas, orquestrada pelo RestEasy e alguns frameworks para trabalho com XML e JSON (mas não usei JAXB - bom, pelo menos não ainda), com ênfase para XPath, para extração e manipulação de dados (como JSON convertido em XML/DOM).
Finalizando
Nessa sexta, devo colocar a aplicação na nossa área Incubator, e começar a ajustar os ponteiros.
Até agora, foi tudo desenvolvimento local, sem testes profundos com estilo...hum, cowboy (putz).
A partir da outra semana, a coisa deve ficar mais bonitinha :)
O Super Pipe
O pipe que montei foi este abaixo:
que na prática, é responsável por ler feeds diversos de vários locais (nos quais nossa equipe produz informação - por exemplo, um commit do SVN gera um Feed com um comentário de log, o qual é lido pelo pipe) e ejetar uma saída padronizada (em laranja na figura).
Essa saída é um típico JSON, que então uso como entrada na nossa arquitetura RESTFul.
Arquitetura
Na verdade, esse JSON é apenas uma das entradas, uma vez que outras são provenientes de locais que (ainda) não geram Feeds. Por exemplo, algumas tabelas de banco de dados atualizadas por sistemas de legado e calendários internos não publicáveis.
Todas essas entradas são interpretadas pelo que chamei de Producers, ou seja, classes produtoras de informação... que podem vir de qualquer lugar.
Os producers colocam as informações em uma base (ainda não sei se vou usar JMS ou vou fazer de outra forma para processar de forma assíncrona ou sei lá como).
Estando nessa base, os chamados Consumers são responsáveis por ler as informações que têm interesse e gerar algum resultado útil, tal como... hum, deixa eu ver... atualizar os Twitters pessoais ou da empresa ;) ou mesmo enviar SMS para os celulares dos plantonistas, no caso de emergências em clientes (por exemplo, o monitoramento JOPr indicar uma tendência para consumo de memória excessivo ou então a queda de um servidor JBoss em produção).
Um esboço primário disso é mostrado abaixo:
Observa-se que os producers e consumers são estensíveis. Na prática, estou configurando eles via um padrão "Quasi-Command", os quais são automaticamente escaneados e carregados se estiverem no classpath da aplicação.
NOTA: Sim, sim, eu sei. Também discuti com meu colega J. a possibilidade de usar um ESB (como o JBossESB) para isso. Mas daí o trabalho seria maior (no sentido de montar toda a plataforma operacional) e, principalmente, eu não teria a chance de voltar a programar depois de quase meio ano parado.
E o RESTFul?
Toda a arquitetura é montada com base em HTTP, usando uma sopa de letrinhas, orquestrada pelo RestEasy e alguns frameworks para trabalho com XML e JSON (mas não usei JAXB - bom, pelo menos não ainda), com ênfase para XPath, para extração e manipulação de dados (como JSON convertido em XML/DOM).
Finalizando
Nessa sexta, devo colocar a aplicação na nossa área Incubator, e começar a ajustar os ponteiros.
Até agora, foi tudo desenvolvimento local, sem testes profundos com estilo...hum, cowboy (putz).
A partir da outra semana, a coisa deve ficar mais bonitinha :)
0 comentários:
Postar um comentário