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.
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:
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 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)
