Você deve pensar: Ah, lá vem mais um mala querer falar de Cloud, REST e essas “buzzwordzinhas” famosas…Calma, eu concordo com você no aspecto de não gostar de buzzwords. Neste post, ao invés de ficar “punhetando”(*) ou tentando criar complexidade sobre REST e Cloud, vou mostrar um resultado de algumas horas de pesquisa para executar alguns conceitos e tecnologias na nuvem da Google: Google App Engine usando JSF2.0 e JAX-RS (REST).
Cloud está muito voltada a Infraestrutura, e trazer para os clientes o benefícios de investir no que realmente se usa, e sempre ter recursos quando for necessário. Quantos já viram empresas perguntando para você em consultoria: “Quantos servidores eu preciso para rodar minha aplicação?”, é claro, que se você responder isso sem nenhum medo, recomendo você também começar a jogar na mega-sena, pois as chances de acertar com exatidão é quase a mesma. Alongando a história um pouco mais, para evitar que você erre, você dimensiona um ambiente X, e sempre põe 200% de margem de erro, afinal pra que usar “desvio padrão”, quando o padrão é “chutar”? Só existem 3 cenários possíveis para essa demanda:
Boa, você é o cara! Você acertou na mosca, aproveite e vá ao banheiro agora! Na volta, passe na lotérica
Seu cliente está “pê” da vida, pois o que você dimensionou não está aguentando
Tem tanta máquina sobrando, que o cliente tá pensando em destinar um servidor de jogos pra empresa!
Com o conceito de Cloud, você pode ainda ser solicitado a realizar o famoso “sizing”(dimensionamento) para seus clientes, embora, caso você erre, ou exagere, o cliente poderá readequar seu investimento, alcançando assim exatamente a infra que ele precisa, seja pra um uso contínuo, ou até sazional (ex:matrícula de alunos).
Existem vários provedores de Clouds, entre eles Amazon, a própria Google, e alguns players brasileiros entrando nessa disputa também, entre eles, o provedor que hospeda meu site: TeHospedo .
REST por outro lado, trazendo para a realidade, é basicamente a capacidade de você através de URIs, definir uma estrutura de serviço, por exemplo:
Na URI acima, temos uma semantica simples para entender o que esse serviço se trata: consulta/voos
A partir daí temos as instruções do serviço na URI, tudo que está entre {} , significa que são variáveis, que na execução real, os valores serão passados nos lugares das variáveis sem as {}, por exemplo, imagine então que através do Facebook, você vai chamar este serviço, isto poderia ficar:
Qualquer humano consegue entender essa URI, imagine então máquinas?! Interpretando:
Consulte os Voos saindo de Belém indo para Guarulhos dia 10/02/2010 entre as 12:00 e 16:00, simples não é?
Mas a idéia de REST, ainda vai também no aspecto de qual HyperMedia (formato) as informações podem ser trafegadas e exibidas, recomendo você ler o prático e objetivo artigo de Bruno Pereira sobre o assunto aqui.
CoreREST
Foi pensando em criar uma “Plataforma” onde as pessoas pudessem criar seus scripts, que pensei num domingo que a minha esposa estava visitando nossa família e que odeio videogames, resolvi começar a brincar com isto: A idéia do CoreRest é permitir com que pessoas que conheçam Groovy e Ruby(**), possam criar e definir seus serviços no Cloud da Google: Google App Engine:
Eu também tenho um outro interesse, criar alguns serviços usando Ruby, já que eu gostaria de melhorar meus conhecimentos desta linguagem de uma forma divertida. Com o CoreREST algumas bibliotecas estão no contexto, como por exemplo: Smooks, que é um framework de transformação de dados, a idéia é adicionar outras em breve.
Na implementação do CoreREST, utilizei a implementação REST da Red Hat: RestEasy , que pode ser executado de forma muito simples e transparente dentro do GAE.(Google App Engine), a idéia é que via REST, nós capturemos os scripts (Mashups) gerados pelos usuários, e via o uso da execução de Scripts da Máquina Virtual Java no GAE, possamos executar estes scripts. Para isso, existe apenas uma váriável do tipo String que os usuários devem se preocupar, em breve, vou adicionar suporte a algumas Mídias diferentes para negociação de conteúdos entre os requisitantes e o serviço raíz CoreRest.
3- Esta é a edição do seu Serviço, onde você entrará com:
3.1 - nome do script - É ele que vai servir como chave de inovação do seu serviço
3.2 - URL Mapping: Esta será a URL de mapeamento das váriáveis que você quer passar para seu serviço, neste caso, entre com o valor: /voar/{origem}/{destino}
3.3 - Adicione uma descrição para seu serviço
3.4 - Aqui vai o código do seu script, neste momento, estamos suportando Groovy, mas alguns voos atrasados, e entre uma esticada antes de dormir, irei adicionar o suporte ao Ruby via JRuby. Você entrará com o seguinte código:
response = “Voando de “+ origem + ” para ” + destino;
return response;
3.5 - Clique no botão Create e pronto!
Seu primeiro script estará pronto!
Para acessar seu Script, existe um REST Service raiz, mapeado como a URI “/service”, a notação dele é que em seguida vem: {nomedoscript}/quantas/uris/e/{vars}/{voce}/quiser . Só que tudo que estiver entre {} , será considerado variáveis do tipo String, que você terá no contexto do código do seu Script. A idéia é você então ter uma fonte, para adicionar seus pequenos “mashups” de Aplicações, retornando o tipode dados interessante, que você queira para adicionar em seu blog, ou aplicação dentro do Facebook, Orkut etc, ou alguma coisa até mais profissional. O interessante é que tudo está sendo executado no cloud da Google! Você vai poder dizer: Eu tenho um serviço meu rodando em Cloud! (GAE).
Quando você cria seu script, ele estará disponível no meu lateral direito, onde há um ícone “Run”, clique neste e você verá a seguinte tela:
Executando o Serviço dentro do CoreRest
Automáticamente a página de execução irá mostrar todas as variáveis necessárias pro seu serviço, portanto, basta preencher as variáveis e clicar no botão: Execute the Service Endpoint. Pronto!
Amigos, não faço idéia do futuro deste CoreRest, só sei que está sendo muito interessante, pois estou conseguindo me atualizar em algumas coisas, entre elas JSF 2.0 puro, sem o Seam, como disse no meu blog em inglês: JSF2.0 sem o Seam é como “Churrasco sem sal”! Parece que sempre está faltando algo.
Se você for no TDC 2010, na trilha #JEE , você vai poder ver o CoreRest em mais detalhes! Assim que eu der uma organizada no código irei disponibilizar o código dele como opensource!
Desculpem o tom “irreverente” do post, apenas queria mostrar como pode ser simples, você criar no final um “PaaS”- Platform as a Service! Caramba! E eu fiz de tudo para evitar as malditas buzzwords
(*) Este é meu blog pessoal, existe uma nota nele que fala que o que eu falo aqui não reflete a opinião ou visão do meu empregador.
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
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
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.
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)
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).
