Vale . . . → Ler Mais: Winsock: Você lembra disso? e o que isso tem a ver com Cloud e Virtualização]]> Eu não sou daqueles caras que se orgulha de ter tido um TK85 , não, eu graças ao meu bom Deus era uma criança que só queria jogar futebol, “empinar papagaio” (soltar pipa), mas eu lembro de algumas coisas interessantes a partir do OS2/Warp que vinha com o IBM Aptiva ou mesmo com o Windows 3.1.

Vale lembrar uma coisa da época do Windows 3.1 e DOS : Você sabia que o pacote TCP/IP era limitado no Windows 3.1? E para isso, você tinha o famoso: Trumpet Winsock.

Trumpet Winsock

Nesta época, a questão era: “Stack TCP não vinha como parte do SO”, e você deveria “adquirir um pacote extra, seja de uma empresa, ou um AddOn a mais a ser pago para a fornecedora do SO, afinal: Quem precisava de TCP/IP?

Nos dias de hoje, se você vai tomar um café, você tem a notificação: “Wireless Encontrada….Deseja conectar?”, e você algumas vezes não pensa que isto é possível por causa do stack TCP/IP, em outras palavras, é tão “bobo”, é uma caraterística tão banal, que você não pensa que um dia isto não fez parte do Sistema Operacional.

Você lembra de um texto e apresentação que escrevi a um tempo atrás baseado no livro: “Free: O Futuro dos Preços” de Chris Andersen, onde ele fala:

“A informação escassa quer ser cara e a informação abundante quer ser barata”

Eis que nos deparamos há alguns anos com a chamada: Virtualização , e por muitos anos, nós encaramos que isto não deveria ser parte do sistema operacional, e nossa indústria gastou milhões adquirindo uma tecnologia de praticamente um único fornecedor, muito embora estas tecnologias deste fornecedor sejam fantásticas.

Porém, o mundo necessita de quebra de mais players num nicho tão dominado quanto este, até para promover uma qualidade ainda maior para os consumidores.

Como um dos pilares da missão Red Hat na sua fundação, temos a frase: “Democratizar o conteúdo e tecnologia”, isso tem a ver com “opensource”, mas isto também tem a ver com um modelo de negócios que subisidie tal revolução, então a Red Hat junto com outras empresas, investiu no Linux-KVM, que é a fundação para a solução de missão crítica: Red Hat Enterprise Virtualization, que pode ser uma das soluções que você deve avaliar para suas inteções de Virtualização. O KVM é poder da virtualização já como parte integrante do Kernel, ou seja, assim como o TCP/IP tornou-se parte dos SOs, nós acreditamos que Virtualização também é algo que deve estar dentro do Kernel do SO, e não algo que você deve comprar como uma solução externa.

Democratizar: Este é o Objetivo

Uma das coisas interessantes, é que o KVM já está presente no Red Hat Enterprise Linux desde a versão 5.4, ou seja, Virtualização já é parte do nosso Sistema Operacional, porém, faltava uma camada de Gerenciamento adequada, para isto, o RHEV oferece uma interface de gerenciamento, a qual, meu colega Filipe Miranda apresenta no screencast abaixo:

Red Hat Enterprise Virtualization Console from fmiranda on Vimeo.

Em resumo, esta não é minha área de atuação, mas estaremos fazendo um grande trabalho de evangelhização, divulgação destas tecnologias, através do nosso time de Solution Architects, Consultores, Engenheiros brasileiros, já eu não posso ir tão longe, já que comparado a estes caras que eu citei, eu sou mais baixo que um protozoário ou plancton comparado a eles.

E o Cloud?

Em um outro post, volto a falar dos Hypes: Cloud, e as caronas desgovernadas que vejo o mercado oferecendo, observo vários absurdos em termos de cloud que fazem parecer a nova propaganda da SpaceFox (aquela da Ovelha é uma nuvem) até com mais senso.

Quase 3 anos atrás tivemos um cliente que utilizava: PHP e Active Server Pages (ASP), nada de errado nisto, a não ser o fato de ele querer adicionar suporte a Workflow e BPM na sua estrutura. Eis então que criamos uma infraestrutura baseada em REST.

Passado este tempo, percebi que vários clientes ainda buscam soluções similares a . . . → Ler Mais: Flowlet - REST seu BPM]]>

Quase 3 anos atrás tivemos um cliente que utilizava: PHP e Active Server Pages (ASP), nada de errado nisto, a não ser o fato de ele querer adicionar suporte a Workflow e BPM na sua estrutura. Eis então que criamos uma infraestrutura baseada em REST.

Passado este tempo, percebi que vários clientes ainda buscam soluções similares a estas, eis então que resolvemos deixar essa solução pública e opensource. Esta solução, demos o nome de Flowlet .  A idéia do flowlet é criar uma API através de URIs para máquinas de processos, neste caso, a primeira implementação foca no JBoss jBPM.

Nesse meio tempo, você não acredita que ao migrar de máquina, eu simplesmente perdi uma grande parte das últimas melhorias que vinha fazendo com o passar do tempo no Flowlet, por isto, em breve isto estará no GitHub(assim como eu aprender como usa essa droga direito) e por segurança, também no GoogleCode (SVN). Uma vez perdidos, como o leite derramado, não adianta chorar, então voltei a adicionar algumas coisas, agora utilizando algumas novas boas práticas de REST que surgiram nos últimos tempos, além do RestEasy 2.0-GA .

Motivação do Flowlet

Você precisa acessar uma API de processos/workflow, porém você quer fazer isso de qualquer linguagem Web, ou mesmo através de Widgets que podem ser expostos em Portlet cotainers. Então, por que não pensar em coisas como:E

• startProcesInstance : /start/process/{processdefinition}/{user}
• getProcessInstancesById : /process/id/{definitionid}/instances
• getProcessInstancesByProcessName : /process/name/{definition}/instances
• getProcessStats : /process/stats/
• getProcessStatsforGraph : /process/stats/graph

Estas URIs, podem ser acessadas de qualquer página, dispositivo móvel, e dependendo da requisição, podemos até especificar retornos específicos com a mídia requisitante (exemplo: JavaScript solicita um CSV text/plain, IPhone um XML ).

Executando

O Flowlet é empacotado num .war file, e basta você fazer um deploy deste arquivo em algum servidor de aplicações que contenha o jBpm instalado e em execução. Um exemplo deste servidor, é o JBoss ESB 4.9 Server, que já traz um JBPM Server instalado.

Modelo de Execução

O esquema de execução do flowlet é super simples, na verdade temos uma classe Java, que deveremos estar melhorando gradativamente seu uso, para oferecer cada vez mais recursos, mas hoje por exemplo, já podemos:

• Iniciar um Processo
• Sinalizar na Instância do Processo
• Iniciar Tarefas de uma Instância do Processo
• Adicionar variáveis ao Processo
• etc

Tudo isto é feito apenas com o uso da API do JBPM, e nada impede de no futuro, criarmos outras APIs para um BonitaBPM ou até outros motores.

Veja algumas operações:

Interface de entrada do Flowlet

Na interface acima, você tem algumas dicas de como usar as URIs disponíveis, uma coisa que estou bolando, é clicar e uma Interface ser aberta como modal, onde o usuário possa entrar com os parâmetros e aí executar os métodos.

Resultado do Processamento em text/plain

Acima você pode ver o resultado de uma das operações, que mostra apenas todos os processos e suas versões, e quando foram instalados, poderiamos ter uma “Negociação de Conteúdo”, que caso eu enviasse que meu cliente prefere o retorno em JSON, eu posso passar uma informação no Header HTTP (Accept: application/json), e automaticamente o RESTEasy me busca o método que responde a esta URI e que aceita este tipo de resposta.

Dashboard customizável oferecido dentro do Flowlet

Com a ajuda do meu amigo Bruno Pereira, que conhece bastante os truques de JavaScript, consegui disponibilizar uma interface para geração de Gráficos que podem servir de Dashboards mais “elegantes” para o JBPM, mas pode ser que você também possa querer extendê-los e criar os seus. Obrigado Bruno pela ajuda!

Próximos passos?

Interessado no Flowlet? Hoje é domingo, não consegui muito tempo para fazer o upload dos sources, mas assim que tiver tempo, eles estarão de alguma forma no GitHub.

Outra coisa, o Flowlet funciona para o JBPM 3.2.x, isto porquê a versão 4 do JBPM não será “produtizada”, apenas a nova versão que será a 5.0, que deverá ser lançada ano que vem.

Acompanhe as novidades no meu twitter: @jedgarsilva

Para diversão de vários congressistas, tinhamos um Wii em nosso stand, ele chegou a gerar . . . → Ler Mais: FISL11]]> O FISL11 (Forum Internacional de Software Livre), aconteceu em Porto Alegre dos dias 20 a 24 de Julho, fiquei pelo stand da Red Hat, e conversando com um monte de pessoas, estas coisas são boas em eventos, pelo menos revemos vários amigos.

Para diversão de vários congressistas, tinhamos um Wii em nosso stand, ele chegou a gerar várias filas para jogar:

Mas nada fez mais sucesso que os sorteios que fizemos na quinta e sexta-feira:

Hoje as 09:00 da manhã, tive a chance de falar um pouco sobre REST com Java para uma sala bem lotada, desde já obrigado a todos que foram.

Focamos muito na parte de “Negociação de Conteúdo”, executando o mesmo path (/servico/path/dele) para diferentes possíveis clientes, por exemplo: Um browser, ou IPhone por exemplo. Sem falar nas novidades do RestEasy 2.0 GA, entre elas a API JavaScript para integração com JQuery ou mesmo acesso JavaScript puro.

Eis meus slides apresentados:

Daqui a pouco, volto pra São Paulo, mas o FISL só acaba amanha(śabado dia 24), se você ainda não foi, ainda dar tempo de dar um pulinho por lá.

Vale lembrar, que tudo que fizemos no Enterprise Portal Platform 5.0, também serve para o Gatein, então, não fique com a idéia que os vídeos . . . → Ler Mais: JBoss EPP 5.0: Em Ação]]> Meus amigos que acompanham este blog, visando tornar o uso do JBoss EPP 5.0 mais simples, além de mostrar algumas de suas funcionalidades, criamos vários vídeos sobre o mesmo, hospedados no Vimeo.

Vale lembrar, que tudo que fizemos no Enterprise Portal Platform 5.0, também serve para o Gatein, então, não fique com a idéia que os vídeos limitam você como usuário destas tecnologias. No post anterior, expliquei um pouco da grande diferença destas soluções.

Já existem vários vídeos do EPP 5.0, mas decidi criar algumas coisas com dicas em nossa língua mãe: Português, a seguir o resultado deste trabalho:

Instalando o JBoss EPP 5.0 ou GateIn (mesmo procedimento)

Utilização Básica de Portlets Existentes

Registrando novos Widgets e Gadgets

Desenvolvendo seu Primeiro Portlet Java com EPP/Gatein

Adicionando suporte a JQuery em Portlets

Adicionando suporte ao JQuery / Lightbox ao seu Portlet

Adicionando o suporte do Twitter ao JBoss EPP 5.0

Espero que todos gostem, e estou fazendo o máximo para conseguir tempo livre para criar e divulgar estes vídeos, a próxima série de vídeos, estamos planejando abordar:

• Gestão de Conteúdo com o Add-On: JBoss Site Publisher (eXo WCM)
• Portlet Bridge
• IPC (InterPortlet Communication)
• WSRP  com outras soluções de Portal

Um abraço, e boa diversão com seus portais.

Há duas semanas a Red Hat lançou oficialmente a sua nova versão corporativa da solução de portal JBoss, oficialmente chamado de JBoss Enteprise Portal Platform 5.0, ou até mais simples EPP5.0 . Este pequeno post, irá explicar um pouco da estratégia JBoss Enteprise para este segmento de tecnologia.

Como isto começou?

Como tudo da Red Hat, . . . → Ler Mais: JBoss Enterprise Portal Platform 5.0]]>

Há duas semanas a Red Hat lançou oficialmente a sua nova versão corporativa da solução de portal JBoss, oficialmente chamado de JBoss Enteprise Portal Platform 5.0, ou até mais simples EPP5.0 . Este pequeno post, irá explicar um pouco da estratégia JBoss Enteprise para este segmento de tecnologia.

Como isto começou?

Como tudo da Red Hat, começou na comunidade, com a antiga versão de nossa solução de portais chamada ainda como JBoss Portal. Para clientes com necessidade de missão crítica, SLA, customizações e serviços, a Red Hat disponibilizava a plataforma JBoss Enteprise Portal Platform versão 4.3, esta por sua vez, já possuia fantásticos recursos de integração(WSRP, PortletBridge, SSO, Workflow), além de uma notável facilidade na customização. Porém a demanda de novos clientes e projetos, exigia que tivessemos uma nova solução pro mercado, eis então que surgiu uma grande parceria com a empresa francesa EXO Platform.

EXO: A Motivação

A eXo é uma empresa que segue os mesmos princípios da JBoss/Red Hat, ou seja: Democratizar o conhecimento através de soluções opensource, entretanto, muito mais focados em soluções de Portais e Colaboração. EXO e Red Hat, chegaram a um acordo de unirem suas soluções de portais, naquele momento: EXO Portal e JBoss Portal, dando origem a um novo produto comunitário: GateIn, que nada mais é que o merge de 2 projetos de Portais Java 100% opensource.

Tudo começa na comunidade

O JBoss Community é o nosso centro de pesquisa, inovação e desenvolvimento das tecnologias que várias pessoas utilizam no seu cotidiano, embora algumas destas pessoas estejam a cargo de aplicações de extrema missão crítica, cuja as empresas para as quais elas trabalham estejam extremamente preocupadas não só com tecnologias inovadoras, mas também com estabilidade, garantia de continuidade, suporte, serviços, treinamento oficial etc, de um fornecedor confiável, na qual elas possam atender e suprir suas necessidades de negócio; este é um momento então que a Red Hat realiza todo um trabalho de amadurecimento, QA, teste de performance, certificações de bancos de dados, sistemas operacionais, JVMs etc, é aí que o GateIn deixa de ser apenas um projeto opensource, para ser um produto de nível corporativo, para conseguir ser comparado a qualquer outra oferta de portal de outros fornecedores proprietários.

GateIn vs EPP

O GateIn é o produto comunitário, aberto, que qualquer um pode baixar e usar, no entanto o suporte também é comunitário, e sem garantias. Já o JBoss EPP (Enterprise Portal Platform) é um produto feito com base no GateIn, porém com vários testes, certificação e com todo o suporte e garantia da Red Hat.

Lembrando, que a Red Hat, não vende licença do EPP, e sim a subscrição, que em resumo é uma assinatura de benefícios para os clientes, entre eles:

• Suporte 0800 e Web
• SLA de até 24X7
• Garantia de Continuidade de Suporte de 5 a 7 anos
• Flexibilidade de versões (use versões novas ou anteriores da solução)
• Correções de Bugs
• Binário Enterprise (resultado do QA,Testes do binário comunitário)
• Patches de Segurança, Corretivos e Performance
• Docuementação Oficial e Corporativa
• etc

O JBoss EPP atende muito bem a cenários onde integrações via Portlets, SSO, Portlet Bridge, Multipele (Skinability), porém as novidades não param aí.

JBoss Enterprise Portal Platform Site Publisher

“Pois nem só de Portlets viverá um Portal Container”, em alguns casos de uso, precisamos gerenciar conteúdos, seja através de usuários finais, ou vários jornalistas separados geograficamente etc, para os clientes que tiverem estas necessidades, a Red Hat oferece um produto adicional ao EPP, que é o Site Publisher, que é a versão corporativa do produto da Exo chamado de WCM. Com o Site Publisher, nós saímos da esfera de atender apenas integração através de Portais e Portlets e entramos no nicho de Enterprise Content Management - ECM.

Colaboração Importa

Você deve estar se perguntando, onde mais poderiamos contribuir para facilitar seus projetos de Portais? A resposta é que além de toda a infra para Portais, WCM/ECM, através dos módulos de colaboração da eXo, você pode obter módulos que podem lhe ajudar na colaboração de pessoas dentro da sua empresa.

A Exo oferece uma série de módulos adicionais, para facilitar a sua vida quando a demanda for “Colaboração”, entre estes módulos:

• eXo Collaboration - Email, Chat, Catálogo de Endereços
• eXo Social - Espaço para Pessoas (Rede Social), Comunidade, Atividades etc
• eXo Knowledge - Forum, FAQ
• eXo Workflow - Melhore seu Workflow de Aprovações através de BPM com uso do jBPM.
• eXo DMS - Gestão de Documentos voltado para cenários de GED.

Informações

Em breve vou adicionar alguns vídeos de instalação, uso, desenvolvimento com uso do JBoss EPP, então fique atento no meu twitter (@jedgarsilva) para acompanhar as novidades que estão por vir. Se você quiser saber mais, envie um e-mail para info-br (no email da) redhat.com ou através do telefone: 11 3529-6000 (Vendas).

Alessandro Lazarotti, ou o Laza como chamamos no escritório da Red Hat, este mês nos encheu de orgulho, com um ótimo Artigo sobre CDI (Context Dependency Injection), usando a implementação de referência da JBoss: Weld. A propósito, esse assunto será abordado pelo escocês Pete Muir, Líder do Seam e do Weld durante do JBossinBossa . . . → Ler Mais: MundoJava: JEE 6.0]]>

Alessandro Lazarotti, ou o Laza como chamamos no escritório da Red Hat, este mês nos encheu de orgulho, com um ótimo Artigo sobre CDI (Context Dependency Injection), usando a implementação de referência da JBoss: Weld. A propósito, esse assunto será abordado pelo escocês Pete Muir, Líder do Seam e do Weld durante do JBossinBossa dias 7 e 8 de Maio na Anhembi Morumbi da Casa do Ator - Vila Olimpia.

Mas o assunto é o próprio Lazarotti, que representa um processo de contratação que temos dentro da Red Hat, que vai um pouco contra as vias tradicionais das empresas ditas “grandes”. Uma das coisas que buscamos sempre é:

O que essa pessoa faz ou fez de bom para os outros na Comunidade?

A resposta desta pergunta pode ser um grande fator de decisão para nossa contratação. O próprio Alessandro, sempre participou de discussões no GUJ, posts, palestras, artigos em revistas e ajudando em desenvolvimentos de iniciativas opensource como o próprio Seam e o SuperCrud da GlobalCode. Esse modelo deu super certo, e tornou-se um padrão dentro da divisão JBoss a ser seguido. Claro, existem exceções, como a toda “regra”, mas esse é um grande fator que buscamos sempre: Antes de saber o que a pessoa é de verdade através de somente uma visão fria de um curriculum, observamos qual o papel ela vem desempenhando na sociedade para ajudar as outras pessoas…. E vários e vários que estão no nosso time hoje, vieram e continuam alimentando esta prática, o que nos enche de orgulho e satisfação, é por essas e outras que eu só posso dizer que não tenho palavras para descrever o time de pessoas com as quais eu tenho prazer de trabalhar…. Entre elas nosso querido Lazarotti

Não sou de ficar

A palestra: Opensource SOA on Steroids: Combining the robustness of JBoss ESB with the flexibility of Apache Camel foi aceita, e em Junho, alguns dias antes do aniversário de minha mãezinha, . . . → Ler Mais: Palestra aceita no Jazoon 2010]]>

A palestra: Opensource SOA on Steroids: Combining the robustness of JBoss ESB with the flexibility of Apache Camel foi aceita, e em Junho, alguns dias antes do aniversário de minha mãezinha, eu embarco para Zurich se Deus quiser. Veja os outros palestrantes aqui: http://jazoon.com/Conference/Speakers

Poder falar num evento como o Jazoon para mim é mais que um privilégio, é poder estar num continente diferente mas com uma coisa muito forte em comum: O poder da colaboração em torno de Java.

Em resumo, a palestra mostrará como o Apache Camel pode ser utilizando como um Event Processor dentro da arquitetura do JBoss ESB, um prato cheio para quem gosta dos assuntos de integração/SOA.

Infelizmente, não vou poder encontrar este ano em Zurich uma pessoa muito querida não só por mim, mas definitivamente por um batalhão de pessoas , que não sei se era o mais “nordestino dos gaúchos”, mas simplesmente a síntese do ser brasileiro: Felipe Gaúcho, o qual conheci no JavaOne em 2007, e que conversamos muito sobre JUGs, o Sul, o Norde e Nordeste do Brasil, sei que ele está bem, e torcendo para que essa comunidade brasileira que ele ajudou tanto, continue sempre: Vibrante e Colaborativa!