Consumindo e Testando Clientes REST

terça-feira, 29 de dezembro de 2009



A especificação JAX-RS é uma ótima opção para criar web services REST e fornece meios de desenvolver componentes server-side, mas não descreve como os desenvolvedores devem desenvolver seus componentes client-side em Java, e essa já é uma das promessas para a próxima release do JAX-RS.

Pelo fato de nossos serviços RESTful serem URIs e a forma de acesso a estes serviços serem os próprios métodos HTTP, podemos trabalhar diretamente com requisições HTTP ou utilizar bibliotecas para facilitar este trabalho. Felizmente é relativamente fácil trabalhar diretamente com requests e responses HTTP, e as linguagens mais populares de programação possuem métodos/bibliotecas HTTP, como por exemplo, urllib2 e httplib em Python, libcurl em PHP, HTTPWebRequest em C#, open-uri em Ruby, e o pacote java.net.* e o projeto HttpClient da Apache para Java, entre outros. Mas para qualquer linguagem que seja feito a requisição ao serviço RESTful, temos que passar por alguns passos, conforme segue:
  1. Montar os dados que irão trafegar pelo requisição HTTP, como a URI, HTTP header (se houver), e o método HTTP desejado.
  2. Formatar estes dados como uma requisição HTTP, e enviá-lo para um servidor HTTP apropriado.
  3. Efetuar o parsing dos dados retornados (XML, JSON, etc..) para as estruturas de dados que o seu programa precisa.

Para facilitar a pesquisa, montamos um pequeno guia, para os desenvolvedores e estudiosos que querem aprender um pouco mais sobre REST, onde iremos apresentar algumas bibliotecas para teste e consumo de serviços RESTful.

cURL

Se o intuito for apenas testar os serviços REST desenvolvidos e validar o retorno, o mais simples é utilizar ferramentas existentes na web como é o caso da biblioteca cURL, que é uma ferramenta de transferência de arquivos entre cliente-servidor desenvolvida em C, e suporta protocolos como HTTP, HTTPS, FTP, FTPS, etc.
 A listagem 1 apresenta alguns exemplos de como fazer uma requisição GET e POST com uso da biblioteca cURL, como podemos ver, ela não possui uma interface gráfica, sendo uma ferramenta de linha de comando.
 Fazendo uma requisição (GET), passando como parâmetro de headerv tipo de conteúdo json, (-H "Accept:application/json")


// Fazendo uma requisição POST, passando como  query parameter name = JumboComLtda
$ curl -d name=JumboComLtda http://localhost:8080/Contatos/resources/customers/2/cliente/

// Excluindo um registro com DELETE, pelo parâmetro –X
$ curl -v –X DELETE http://localhost:8080/Contatos/resources/customers/99/


Registro excluído com sucesso !


Listagem 1: Uso da biblioteca cURL.
 

Referências:

RESTClient

 RESTClient é uma aplicação Java própria para auxiliar nos testes de serviços RESTful, complementar a isto, ela pode ser utilizada para testar Web Services POX (Plain Old XML) sobre HTTP. Para utilizar, basta efetuar o download do arquivo jar (com dependências) da ultima versão, no momento que escrevo este artigo, a versão mais recente é a versão 2.3, e vem com duas opções.

A versão GUI, é uma aplicação Swing com diversas opções, e bem conhecida de quem trabalha com o RESTClient desde suas primeiras versões, e a outra versão "cli" é para execução batch de arquivos .rcq. Para começar utilizar a versão em Swing, basta digitar o seguinte comando (A aplicação requer Java 6 para rodar):
$java -jar restclient-ui-2.3-jar-with-dependencies.jar
 
Após executar a aplicação, deverá ser apresentado a tela conforme ilustra a Figura 1.


Figura 01 - Interface Swing do RESTClient.

Pela aparência da interface gráfica, podemos deduzir facilmente o modo de utiliza-lá, basta digitar no campo URL o caminho desejado, selecionar algum método HTTP na aba Method, e executar a consulta clicando no botão [>>]. O resultado será apresentando no bloco HTTP Response.


Funcionalidades

 Com RESTClient, podemos fazer qualquer tipo de requisição HTTP (GET, PUT, POST, DELETE, HEAD, OPTIONS, TRACE), ainda existe o suporte a SSL e a possibilidade de adicionar parâmetros de Header adicionais.
É possível salvar as requests, responses, e o Response Body (atráves do menu File > Save Request, ou Save Response, Save Response Body), o que é útil para testes de regressão, que podemos utiliza-los posteriormente na versão de linha de comando.
RESTClient ainda vem com o Conteiner Jetty embutido, que possui um Servlet que imprime os detalhes das requisições submetidas a ele. Para iniciar o servidor basta acessar o menu Tools > Opção Start Trace Server (subirá na porta 10101).

E por fim, uma das funcionalidades mais interessantes é o seu suporte integrado para testes, que podem inclusive ser escritos em Groovy, o suporte a testes é baseado no JUnit 3.x e os tests são atachados a cada requisição. Para iniciar os testes, na aba "Test Script", clique o no botão Insert Template, RESTClient irá criar o código para você, conforme mostra a Listagem 02:
// The test class name should end with `Test'--this is a convention:
public class TemplateClassTest 
    extends org.wiztools.restclient.RESTTestCase{

  // Test method names should start with `test':
  public void testStatus(){
    if(response.getStatusCode() != 200){
      fail("This will fail the test!");
    }
  }
}
Listagem 2: Template de Test gerado pelo RESTClient.

A partir da versão 2.3, RESTClient possui uma versão em linha de comando, está versão é utilizada para executar requisições de forma batch e armazenar o resultado dos testes.  Para executar está versão, basta na linha de comando executar:

$java -jar restclient-cli-2.3-jar-with-dependencies.jar -o /temp/diretorioResponse *.rcq

Esse comando, irá executar todos as requisições contidas nos arquivos de extensão (.rcq) no diretório de execução atual, e irá salvar as responses (na extensão .rcs) no diretório /temp/diretorioResponse. E por fim, o RESTClient, imprime um resumo da execução dos testes. 


Referências:

Testando Web Services RESTful no NetBeans.

 Para quem é usuário do NetBeans, uma outra opção para testar Web Services RESTful é utilizar o suporte do próprio IDE, com um projeto Web criado e os serviços RESTful devidamente configurados, é possível testá-los clicando com o botão direito do mouse em cima do projeto e selecionar a opção “Test RESTful Web Services” (Figura 02), lembrando que está opção só estará disponível, se o projeto WEB possuir serviços WEB.


Figura 02 -Suporte a REST no NetBeans.

Ao selecionar esta opção, será feito o build e o deploy da aplicação web, e ao final do processo será disponibilizado uma página de testes web, como mostra a Figura 03.



Figura 03 - Tela de testes de Web Services RESTful

Na página apresentada é possível testar todos os serviços disponíveis, criar novos parâmetros para a requisição (botão “Add Parameter”), e também é possível selecionar o tipo de método HTTP para teste e o tipo MIME de retorno.

Para iniciar o teste, basta clicar no botão “Test”, após a execução, dentro da seção Response, podemos analisar os dados de retorno, os dados do cabeçalho e o status da chamada.

Além disso, de acordo com os serviços criados, o NetBeans ainda gera o arquivo WADL, visível no canto superior esquerdo da Figura 03.
 
Referências:

JAXB

JAXB (Java Architecture for XML Binding) fornece a API, as ferramentas e um framework que automatiza o mapeamento entre documentos XML e objetos Java. Ou seja, fornece compiladores que compilam Schemas XML para objetos Java. Em tempo de execução podemos deserializar (unmarshal) o conteúdo de um arquivo XML para representações Java.

Além disso, podemos acessar, alterar e validar a representação Java contra regras de um Schema e por fim, podemos serializar (marshal) o conteúdo de um objeto Java em conteúdo XML. Veja sua arquitetura na Figura 04:




Figura 04 - Overview do JAXB.

Esta fora deste artigo um estudo mais aprofundado sobre o JAXB, mas apenas para conhecimento, a API JAXB acabou se tornando a forma padrão de mapeamento entre Java e XML, com JAXB temos anotações que nos permitem criar uma representação em Java de um Schema XML, estas anotações estão presentes no pacote javax.xml.bind.annotations, e possuem anotações associadas a pacotes Java (@XmlSchema, @XmlSchemaType, etc..), a classes Java (@XmlType, @XmlRootElement), a propriedades e campos (@XmlElement, @XmlAttribute), entre outras anotaçõe.

Para exemplificar, considere o exemplo da listagem 3, esta é uma classe POJO representando uma pessoa, com anotações JAXB.  Ao fazer um marshalling de uma instância da classe PessoaBinding para XML, teremos o resultado apresentado na listagem 04.

@XmlRootElement(name="pessoa")
@XmlType(name="", propOrder={"nome","idade","statusCivil"})
public class PessoaBinding {
/* Construtores e Setters omitidos */
    private String nome;
    private int idade;
    private String statusCivil;
    private String cpf;

    @XmlElement
    public String getNome() {
        return nome;
    }
    @XmlElement
    public int getIdade() {
        return idade;
    }
    @XmlAttribute(name="num_cpf")
    public String getCpf() {
        return cpf;
    }
    @XmlElement
    public String getStatusCivil() {
        return statusCivil;
    }
}
Listagem 03 - Classe PessoaBinding com anotações JAXB.

   
       Wagner
       29
       Casado
   
Listagem 04 - XML Gerado após marshalling de classe JAXB PessoaBinding.

A especificação do JAX-RS fornece alguns Entity Providers padrões, entre eles, provedores para JAXB, para quando o tipo de conteúdo trafegado for do tipo xml (application/xml, text/xml e application/*+xml), de modo que o programador não precisa criar código para converter um objeto Java em código XML e vice versa, facilitando muito nossa vida.


Ainda na classe PessoaBinding da  listagem 03, poderíamos então, no nosso exemplo, criar um serviço RESTful cujo retorno seja a classe JAXB PessoaBinding , neste caso a declaração do serviço seria similar ao método da listagem 05.

    @GET
    @Produces("application/xml")
    @Path("/NetFeijao/autor/{idPessoa}/")
    public PessoaBinding getPessoa(@PathParam("idPessoa") Integer id) {
         return dao.getPessoaAsBinding(id); // Retorna uma entidade Pessoa como PessoaBinding
    } 
Listagem 05 - Serviço RESTful cujo retorno é uma classe JAXB.

Ao fazermos o consumo deste serviço RESTful, vamos perceber que a conversão é feita automaticamente pelo entity provider padrão para XML (veja o teste na Figura 05, utilizando a ferramenta RESTClient). De maneira inversa poderíamos criar um serviço RESTful para receber requisições PUT e receber como parâmetro de entrada do método a classe PessoaBinding via HTTP Body.  Conforme apresenta a listagem 06:





Figura 05 - Retorno do serviço RESTful cujo retorno é uma classe JAXB.

    @PUT
    @Consumes("application/xml")
    @Path("/NetFeijao/")
    public void putPessoa(PessoaBinding pessoa) {
        // Operação de update
    } 
Listagem 06 - Convertendo código XML para objeto JAXB em chamada PUT com REST.



Referências:

JAKARTA COMMONS - HTTP CLIENT

HttpClient é um subprojeto open source da Jakarta Commons que se tornou independente em 2007, e que foi concebido para facilitar o desenvolvimento de aplicações que utilizam o protocolo HTTP.
 Ele é um projeto escrito totalmente em Java, e implementa todos os métodos HTTP (GET, POST, PUT, DELETE, HEAD, OPTIONS e TRACE).

Possui suporte ao protocolo HTTPS, suporte ao gerenciamento de conexões para uso em aplicações multi-thread, suporte a cookie, possui mecanismos de autenticação Basic, Digest e criptografia NTLM.

 Na listagem 07, demonstramos o uso da biblioteca HttpClient, onde consumimos dois serviços RESTful, um com uma chamada GET e outra com uma chamada PUT.

     public void testHTTPClient() {
        try {
            HttpClient client = new HttpClient(new MultiThreadedHttpConnectionManager());
            client.getHttpConnectionManager().getParams().setConnectionTimeout(30000);
            final String CONTENT_TYPE = "application/xml";
            final String CHARSET = "UTF8";

           /* Executando chamada com método HTTP GET */
        String getURI = "http://localhost:8080/ProjetoREST/NetFeijao/autores/Wagner/?idade=29";
        GetMethod get = new GetMethod(getURI);
        Header meuHeader = new Header("CPF","123456789");
        get.setRequestHeader(meuHeader);
        int statusCodeGET = client.executeMethod(get);
        String responseBody = get.getResponseBodyAsString();
        System.out.println("Chamada GET");
        System.out.println(" Status Code: "+statusCodeGET+" \nResponse Body:\n"+responseBody);

         /* Executando chamada com método HTTP PUT */
       String putURI = "http://localhost:8080/ProjetoREST/NetFeijao/autores/update/";
       PutMethod put = new PutMethod(putURI);
    StringRequestEntity requestEntity = new StringRequestEntity(responseBody, CONTENT_TYPE, CHARSET);
        put.setRequestEntity(requestEntity);
        int statusCodePUT = client.executeMethod(put);
        responseBody = put.getResponseBodyAsString();
        System.out.println("Chamada PUT");
        System.out.println(" Status Code: "+statusCodePUT+" \nResponse Body:\n"+responseBody);
    } catch (Exception ex) {/* OMITIDO */}
}
Retorno da chamada ao método.
Chamada GET
 Status Code: 200
Response Body:

  
       Wagner
       29
       Casado
  


Chamada PUT
 Status Code: 202
Response Body:

Bem vindo Wagner


Listagem 07: Consumindo serviços REST via GET e PUT com HTTPClient.

Primeiro, na linha 3 instanciamos a classe HttpClient que é o nosso agente HTTP que irá conter os atributos de persistência com cookies, e credenciais de autenticação através da classe HttpState. E também onde será armazenado uma ou mais conexões HTTP, cujo qual faremos chamadas aos métodos HTTP.

Na linha 4 atribuímos um timeout para a conexão de 30 segundos. Depois nas linhas 5, 6 e 9 declaramos as variáveis quer irão determinar o tipo de conteúdo, o character set e a URI de acesso ao serviço REST.

Na linha 10, instanciamos a classe GetMethod, que como o próprio nome indica representa o método GET, passando como parâmetro a URL do nosso serviço RESTful (getURI). Na linha 11 criamos um objeto Header, passando como parâmetro no construtor a chave e o valor que representam o parâmetro e o valor do cabeçalho, no nosso exemplo, passamos um número fictício de CPF. Na linha 12 atribuímos o objeto header para o objeto GetMethod.

 Na linha 13, fazemos a chamada ao serviço RESTful via HTTP GET, e armazenamos o código de status do retorno na variável statusCodeGET, na linha 14 extraímos os dados da Response como String para a variável responseBody. Pelo fato do retorno ser em XML, poderíamos facilmente utilizar JAXB para trabalhar o retorno como um objeto Java. Finalmente nas linhas 15 e 16 imprimimos no console o retorno da chamada a estes métodos.

A partir da linha 18, iniciamos o mesmo processo, mas agora para efetuar uma chamada via método PUT, as únicas diferenças, são o uso do método PutMethod, que implementa o método HTTP PUT e o uso da classe StringRequestEntity na linha  21,  com esta classe atribuímos uma entidade como String ao método PUT que será enviado junto a requisição.

Nas linhas 25 e 26 imprimimos o retorno da requisição PUT.

JavaScript:




Graças ao objeto XMLHttpRequest conseguimos nos comunicar com servidores de forma assíncrona,   desde então temos todas as vantagens do AJAX ao nosso dispor.  Para quem desenvolve interfaces WEB, este recurso resolveu grandes problemas no lado do cliente, mas vale lembrar que JavaScript não é Java, não possui threads, nem tipos, e possui uma grande gama de frameworks Ajax, como por exemplo Prototype, JQuery, Dojo, Script.aculo.us, Ext-JS, entre outros.

 Na listagem 08, temos um exemplo de uma função em JavaScript  que consume um serviço RESTful cujo retorno é um XML.




var xmlHttp;
function showCustomer(str){ 
    xmlHttp=GetXmlHttpObject(); // omitido código do método0
    if (xmlHttp==null) {
        alert ("Your browser does not support AJAX!");
        return;
    }
    var url='http://localhost:8080/Contatos/resources/customers/58/';
    xmlHttp.onreadystatechange=stateChanged;
    xmlHttp.open('GET',url,true);
    xmlHttp.send(null);
}

function stateChanged() { 
    if (xmlHttp.readyState==4){
        var xmlDoc=xmlHttp.responseXML.documentElement;
        document.getElementById("nome").innerHTML= 
        xmlDoc.getElementsByTagName("name")[0].childNodes[0].nodeValue;
    }
}
Listagem 08 - Consumindo um serviço RESTful (retorno XML) com Ajax.

Na listagem 08, vimos um exemplo de um serviço que retorna XML, mas uma das grandes vantagens dos serviços REST, é que podemos trabalhar com diversos formatos para troca de informação de um mesmo recurso. Entre eles JSON.

jQuery



JQuery é uma biblioteca JavaScript que vem chamando atenção por conta de sua facilidade de desenvolvimento, ela simplifica muito a manipulação dos elementos de um documento HTML, o tratamento de eventos e as interações Ajax para prover um desenvolvimento rápido de aplicações web, livrando o desenvolvedor de preocupações relacionadas a compatibilidade de navegadores e aderência a CSS.

A biblioteca jQuery fornece algumas funções para tratamento de requisições Ajax, ideais para o consumo de serviços REST, que reduzem muito a complexidade e a quantidade de linhas necessárias para consumir um serviço REST.  Com a função $.ajax() do jQuery, conseguimos um alto nível de controle nas requisições ajax.

A sintaxe do comando é $.ajax(options), onde o parâmetro options são as propriedades que passamos para controlar como a requisição é feita e retorno da chamada.
Na listagem 09, demonstramos o uso das funções $.ajax().
$.ajax({
    type: ‘DELETE’,
    url: "http://localhost:8080/ProjetREST/NetFeijao/autores/"+idAutor+"/",
    success: function(msg){
        $("#alert").html(msg);
    }
});
Listagem 09 - Consumindo um serviço REST com a função $.ajax().

Na listagem 09, usamos dois parâmetros na função $.ajax(), o parâmetro type para indicar o método HTTP que queremos executar e a url de chamada.

Para tratar tipos de retorno JSON, o jQuery oferece a função $.getJSON(), utilizada para carregar dados JSON mediante uma requisição HTTP GET.

Na listagem 10 mostramos um exemplo de uso da função $.getJSON() em um serviço REST do Flickr, nós fazemos uma chamada ao serviço REST e passamos o retorno da chamada ao método de callback. Dentro da função de callback criamos a tag passando como valor o endereço da foto retornada pelo serviço REST e a incluímos na div #foto. Note que a variável data, é um map chave-valor dos dados retornados pela função REST.
$.getJSON("http://api.flickr.com/services/rest/?method=flickr.photosets.getPhotos& photoset_id=72157614488723406&format=json&jsoncallback=?",
function(data){
    $.each(data.photoset.photo, function(i,item){
        if (item.title == foto){
            $("").attr("src", "http://farm"+item.farm+".static.flickr.com/"+item.server+"/"+item.id+"_"+item.secret+"_m.jpg").appendTo("#foto");
        }
    });
});
Listagem 10 - Uso da função $.getJSON para consumo de dados no formato JSON.

É isso aí, consumir serviços REST é diversão garantida !!! E a todos um Feliz Ano Novo repleto de código \o/ !!!

Java Magazine 73 - Portais Corporativos

segunda-feira, 21 de dezembro de 2009


No mês de Novembro, publiquei um artigo na revista Java Magazine, fazia um tempo que não escrevia por conta de um projeto que estou tocando.

O tema do artigo é "Portais Corporativos", Neste artigo é apresentado na teoria e na prática os fundamentos do desenvolvimento de portlets em portais corporativos e a importância de Portais no contexto de SOA (com a colaboração de meu amigo Marcelo Zanatto, que falou sobre SOA e Integração com Portais). Como é de costume, o artigo é bem longo e entra a fundo nas tecnologias envolvidas na construção de um grande portal, como as JSRs 168/286, que contemplam a criação e o ciclo de vida de um portlet. É explicado também como definir WSRPs, que são os web services para portlets remotos, e como converter uma aplicação JSF para um portlet com o uso do Portlet Bridge.

Como demo, utilizei o NetBeans para montar e configurar um ambiente para o desenvolvimento de portlets utilizando o Contêiner de Portlets, o pacote WSRP, e a biblioteca JSF/Portlet Bridge do projeto livre OpenPortal junto ao servidor de aplicações Glassfish V2.


Nesta edição, ainda são apresentados os seguintes artigos.
  • JavaOne 2009: Java + Community = Powerful
  • Desenvolvendo com JavaServer Faces
  • Portais Corporativos
  • Desenvolvendo com Hibernate
  • Spring-WS de ponta a ponta
  • O diferencial Scrum
Diversão Garantida!!

Perguntas Frequentes sobre Agilidade

quarta-feira, 14 de outubro de 2009

Em Julho deste ano, após o mini-curso que dei na Globalcode sobre Scrum + XP, uma das pessoas presentes, meu amigo Orlando, anotou diversas perguntas sobre Agilidade no formato de entrevista e pediu que eu respondesse por email.
Segue abaixo algumas perguntas que achei interessante, e resolvi publicá-las aqui no blog.

O que é ser ágil nos dias de hoje?

Acho que ser ágil nos dias de hoje é saber aproveitar as oportunidades de inovação no seu ambiente de trabalho, percebo que a maioria das pessoas acabam ficando acostumadas com a rotina de seus afazeres e perdem chances de inovar.
Quando digo inovar, digo que existem várias maneiras de você introduzir no seu dia a dia práticas ágeis. Outro ponto importante em ambiente ágeis é a comunicação, para ser ágil a pessoa saber lidar com pessoas, com o cliente, e ter um relacionamento de parceria, não pode ter medo de se expor e ser comprometido.
Comprometido não é trabalhar 250 horas por mês no projeto, é saber assumir responsabilidades e saber responder por elas, não ter vergonha de pedir ajuda na hora de uma dificuldade. É velha a história do porco e da galinha =).


Quais os pontos fracos das metodologias ágeis?

O que vejo como um ponto fraco em metodologias ágeis, pela sua própria natureza lean, ou seja, enxuta. É que fica um pouco difícil a sua adoção em ambientes que haja modelos de governança de TI como o Cobit, por exemplo. É difícil em um ambiente de Governança "certificado", você justificar para o gerenciamento de projeto o uso apenas de quadros e post-its, entende? Isso eu digo principalmente com Scrum e XP.
Neste tipo de cenário, a empresa tende a escolher modelos híbridos baseados no PMBook e RUP. O que no final acabam se tornando processos altamente burocráticos em cascata.
Por isso, que acho que esse é um campo que tem muito a ser explorado, trabalhei cerca de 2 a 3 com RUP, e uma escolha mal feita nos artefatos de projeto acaba comprometendo e muito o rendimento da equipe
Outro ponto fraco é o próprio agilista, que tende a pensar que é o dono da razão, pois a verdade é que Barry Boehm já falava da importância dos métodos iterativosque vieram bem antes do movimento ágil ).

Quando não usar?

Bem, independente do lugar que você esteja é muito importante praticar, aplicar os valores do Manifesto Ágil.
Eu não consigo enxergar o uso de métodos ágeis em projetos de implantação de ERP (pacote comprado), principalmente quando a implantação é feita em grandes empresas com diversas filiais. Geralmente, as empresas fornecedoras deste tipo de software já possuem métodos próprios.
Outra ponto, é se a sua empresa desenvolve software e seu cliente esta feliz, o desenvolvedor esta feliz, os projetos estão sendo entregues no prazo, o ROI esta dentro das expectativas, o Time-to-market do seu produto é baixo e a equipe é produtiva, se neste cenário você já não estiver usando ágil, fique onde está.
Se o seu processo de desenvolvimento esta atendendo plenamente você e seus clientes, então não mude. Você já esta no caminho certo.

O que mais dificulta a implantação de uma metodologia ágil numa empresa atualmente?

Com certeza o que dificulta a implantação de métodos ágeis nas empresas é a própria filosofia de desenvolvimento da empresa. Por requerer uma mudança radical na forma de lidar com o desenvolvimento de software, é difícil alcançar uma plenitude na implementação de métodos ágeis e isto pode afetar sua adoção, é difícil as pessoas envolvidas na definição de processos da empresa admitirem que estavam fazendo algo que é não muito produtivo, e que a maneira que elas desenvolvendo software não é a melhor.
Outros pontos que dificultam a implantação de métodos ágeis, ainda alinhado ao primeiro item é a falta de um sponsor, como um diretor, ou outro cargo executivo, se agile não está "vendido" para a alta cúpula da empresa, então pode haver muita resistência por conta da própria TI.
E por fim, a falta de comprometimento da equipe e a falta de conhecimento em métodos ágeis podem dificultar também a implantação.

Só serve para projetos? E a manutenção do sistema?

Agile proporciona um leque bem variado de métodos, entre eles FDD, Scrum, XP, Lean, Crystal, entre outros. Eu diria que os dois caminham juntos, a questão gira em torno de como você irá administrar e classificar os itens em seu backlog.
A partir do momento que um release do seu produto entra em produção, é natural que novas demandas e até bugs apareçam. Tem empresas que separam equipes para atuar somente em projetos de manutenção e outras equipes para trabalhar somente em projetos de evolução, depende tudo de como o trabalho é priorizado.
Para áreas de serviço, como Infraestrutura, onde a atuação das equipes geralmente é feita sob demanda, é recomendado o uso de quadros Kanban, inclusive atualmente estou fazendo um trabalho neste sentido (Quadros Kanban para áreas de Infraestrutura).

E a arquitetura do sistema, como fica?

Essa é uma questão polêmica e que gera muitas dúvidas para quem está iniciando no mundo ágil, principalmente para as pessoas que estão em transição de um método como o Waterfall para o Ágil.
Quando o time de desenvolvimento vem do Waterfall ou até mesmo do RUP, que é um método que descreve os artefatos necessários para se documentar a arquitetura do projeto e propõe um modelo "big design up front", ou seja, força o time tentar imaginar e fechar todos os modelos no inicio da execução do projeto.
Em processos ágeis isso acontece de forma natural e evolutiva, uma das práticas do XP, o "Simple Design" ou "Design Simples" nos diz para mantermos o nosso design o mais limpo e simples possível, e não tentar imaginar funcionalidades que o sistema possa vir a ter, e preparar o sistema para estes prováveis cenários. Isso foge completamente do modelo ágil de gerir projetos.
Independente do modelo que você segue, o seu sistema obviamente será construída baseada em uma arquitetura, e em toda metodologia é muito importante você fazer o planejamento da sua arquitetura, a diferença é que em métodos ágeis devemos sempre respeitar a maturidade atual do projeto de modo que quando houver mudanças ou adição de novos requisitos do negócio, fique fácil refatorar o sistema, levando sempre em consideração os requisitos de qualidade de serviço (QoS) conhecidos por todo arquiteto,

Como fica o contrato? Não há prejuízos para a produtora, uma vez que o cliente altere constantemente o que foi inicialmente solicitado?

Acredito que não, um dos valores do manifesto ágil diz que a colaboração com o cliente é mais importante do que a negociação de contratos, por que isso? Se olharmos para a maneira como as empresas negociam os contratos de software com as consultorias, veremos que esta é uma eterna luta. Porque as empresas adotam o modelo de "Preço Fixo" e para uma consultoria entrar em uma empresa, ao formular uma RFP ela acaba colocando valores que muitas vezes ela mesma sabe que pode tomar um prejuízo, mas o faz para ganhar o cliente.
Este tipo de contrato é ruim, pois passa a maior parte do risco para o desenvolvedor, se o projeto atrasa, o consultor arca com os custos, o que dificulta (e muito) mudanças de escopo.
Um modelo de contrato que achei muito interessante é o modelo "Money for Nothing, Changes for free" proposto por Peter Stevens em http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts#MFN-cff.

Qual o maior benefício (a longo ou curto prazo) que um funcionário (desenvolvedor, tester, analista, etc.) obtém quando se compromete a seguir uma proposta ágil?

Desenvolvedores geralmente gostam de agile, porque os métodos são voltados para times auto-gerenciáveis. Modelos ágeis dão uma liberdade maior aos membros do time, então acho que o maior benefício é o próprio bem-estar do time. Sem falar dos ganhos da empresa como a melhoria contínua da qualidade, redução do risco de entrega e do time to market, aumento da visibilidade do projeto, entre outros.

Como ser um Scrum Master?

Na minha visão, para ser um Scrum Master é preciso antes de tudo saber lidar com pessoas, isso é fundamental, além disso, precisa ser uma pessoa comprometida e responsável, que entenda os requisitos do negócio e as necessidades do time.
Tem que ser uma pessoa humilde, e que saiba influenciar a equipe de maneira positiva, com uma cultura de colaboração.

Como as empresas do Brasil estão aceitando a XP?

Hoje em dia é moda falar de Agilidade no Brasil, principalmente no meio dos desenvolvedores. O que vejo é que é um assunto muito falado, mas pouco aplicado.
XP tem sido assunto em roda de conversa de desenvolvedores durante muitos anos, e o que acaba sendo feito neste sentido são movimentos individuais de desenvolvedores que aplicam algumas práticas do XP de maneira isolada, principalmente TDD.
Com o advento e a popularidade do SCRUM, pessoas de outras esferas nas empresas estão começando a olhar agile de maneira diferente, e tem havido uma grande aceitação neste sentido, então acho que isso tem sido bom para XP também.

Dê algumas dicas de boas práticas àqueles que estão iniciando (estagiários e estudantes).

A melhor dica que posso dar é a mesma que dou em minhas apresentações quando sou indagado. Que é estudar, e tentar se manter bem informado sobre o que está acontecendo no mercado. É impressionante o que você consegue fazer com os feeds dos websites, busque os melhores sites e agregue-os em ferramentas como o Google Reader ou outro leitor de feed qualquer, isso potencializa muito o conhecimento.
Participe de lista de discussões, veja cases de implantação tanto de sucesso quando de insucesso e buscar ler o máximo que puder sobre o assunto.

Finalize com uma mensagem para aqueles que estão interessados, mas ainda são céticos.

Faça uma prova de conceito, e se possível procure implementar ao menos uma prática ágil. Uma dica que dou é sempre que possível, traga o cliente para o lado do desenvolvimento, se você puder fazer com que seu cliente avalie o produto que você está desenvolvendo semanalmente ou até de 15 em 15 dias, você irá começar a ver os ganhos do desenvolvimento ágil.
Ou ainda, vou ir totalmente contra o que acabei de falar, sempre que olhar para o seu processo atual de desenvolvimento, antes de tentar adicionar qualquer prática ou passo novo (menos a que citei sobre o cliente), exclua uma etapa do seu processo. Monte um gráfico de cadeia de valor dos seus processos, e analise o que você pode excluir de passos do seu processo. Se você fizer isso, você já está no caminho de se tornar um grande agilista!

The Developers Conference 2009 - Here we Go !!!

terça-feira, 13 de outubro de 2009



Está chegando mais uma edição do The Developers Conference 2009, que promete ser um dos eventos mais importantes de Java do Brasil. O evento é organizado pela Globalcode.
Afinal, não é todo os dias que temos a oportunidade de conhecer caras importantes como Rod Johnson, certo !!

A programação do evento já foi liberada, com uma novidade bem agradável, que são as Lightning Talks.

Nos encontramos lá !!!




A 3ª edição do The Developer’s Conference 2009, maior evento Java do país, contará com a participação de Chris Schalk, Developer Advocate do Google, trabalha atualmente no time de Google App Engine, plataforma de Computação em Nuvem do Google, além dos principais nomes da comunidade Java mundial: Ed Burns, Rod Johnson e Mike Keith. O evento acontecerá nas cidades de São Paulo (SP), nos dias 6 e 7 de novembro, em Florianópolis (SC) no dia 09 de novembro e no Rio de Janeiro (RJ) em 11 de novembro.
  • Haverá tradução simultânea em todas as etapas do evento;
  • Serão emitidos certificados de participação;
  • Inscrições antecipadas com desconto especial;
  • Inscrições corporativas e caravanas.

Diversão Garantida!!!

[Just Java 2009] De Web Services RESTful a aplicações Mashup

segunda-feira, 5 de outubro de 2009

Nos dias 15 a 17 de Outubro, aconteceu no Centro de Convenções do Senac de Santo Amaro, mais uma edição do Just Java. E como sempre, esta foi uma ótima oportunidade para aprender novas tecnologias e fazer aquele Network.



Apresentei no auditório principal, a palestra "De Web Services RESTFul a aplicações Mashups", onde pude abordar os conceitos de REST proposto pelo Dr. Roy Fielding, passando pela especificação JAX-RS, que define API para criação de Web Services, demonstrando várias maneiras de consumir e testar serviços REST, até chegar ao mundo dos Mashups, apresentando várias ferramentas com exemplos de uso .

Por fim foi apresentado uma demo, que infelizmente por falta de acesso a internet, não pude apresentar em sua plenitude =(.
Para ver o restante da programação e baixar as apresentações que rolaram no evento, acesse este link.







Fotos: Crédito de Eduardo Quagliato -Link: JustJava 2009 no Flickr – Compartilhamento de fotos!

Segue abaixo a apresentação.
 Diversão Garantida !!!

Widget SOUJava

quinta-feira, 10 de setembro de 2009


Já faz um tempo, que venho colaborando com o SOUJava, um dos maiores grupos de usuários Java no mundo, sem fins lucrativos. Após pequenas contribuições apresentando algumas palestras (localização, NetBeans Platform), nos últimos tempos tenho tido o privilégio de participar mais efetivamente com o grupo, que conta com a presença de pessoas como Bruno Souza, Mauricio Leal, Yara Senger, Mr. M, Fabio Velloso entre outros.

E uma das contribuições, junto com o grupo foi justamente na criação de um widget web para divulgação de eventos, notícias, reuniões para o SOUJava.

Esse widget foi desenvolvido utilizando o Zembly,  para quem não conhece, o Zembly é um ambiente de desenvolvimento no Browser criado pela Sun Microsystems, que permite um conceito novo chamado de programação social, muito similar a um Wiki. Com Zembly podemos criar aplicações para redes sociais como Facebook, Meebo, OpenSocial, aplicações web para o iPhone e outras plataformas sociais. E claro, permite criar web widgets

O widget que criamos (vide abaixo) é separado em cinco tabs, onde dispomos informações referentes aos eventos, reuniões, uma das abas (Notícias) é uma integração com o nosso feed. Periodicamente vamos atualizar o conteúdo do widget, sempre que surgir novidades.

O melhor disso tudo, é que VOCÊ desenvolvedor brasileiro, que possui algum site ou blog de tecnologia agora pode nos ajudar a divulgar os eventos promovidos pelo SOUJava e notícias do mundo Java, embutindo o widget em seu site, blog ou fórum.

Para divulgar nossos eventos é muito fácil, apenas copie o código javascript abaixo e inclua em seu blog ou site.


Segue abaixo, o widget em ação.

Diversão Garantida!!!

Entrevista para a Globalcode

No mês de Junho, foi publicado uma entrevista minha para meus caros amigos da Globalcode, sobre carreira e oportunidades, para quem não viu vale a pena conferir. Segue abaixo as perguntas que estão disponíveis no próprio site da Globalcode. Para quiser ver o link da entrevista, clique aqui.

1. Poderia nos contar como começou a desenvolver plugins para o Netbeans ?

Comecei a desenvolver plugins através do "Desafio NetBeans", um campeonato de desenvolvimento de plugins para o NetBeans patrocinado pela Globalcode, Sun e o SOUJava, me lembro que antes de iniciar o campeonato participei de alguns minicursos gratuitos promovido pela Globalcode, contando inclusive com a participação de dois desenvolvedores do NetBeans (Tim Boudreau e Charlie Hunt).
Neste campeonato desenvolvi meu primeiro plugin para o Netbeans, mais especificamente um plugin para o Hibernate, onde a partir de tabelas selecionadas de um Banco de Dados, o plugin gera as entidades de persistência, o arquivo de configuração, com suporte a xDoclet (na época não havia annotations). Neste primeiro contato com a plataforma NetBeans tive a oportunidade de aprender várias coisas legais que me motivaram a continuar o aprendizado.

2. Desde então, quais plugins você já desenvolveu?

O segundo plugin que desenvolvi foi o módulo CodeGen, um plugin para sobrescrever os métodos equals() e hashcode() que na época (NetBeans 5.0) não existia no NetBeans, e existia no Eclipse. Existe até uma história engraçada por trás disso, me lembro de estar em um minicurso em que o Vinicius comentou que abria o Eclipse apenas para utilizar a função do equals e hashcode, o que me motivou a criar este projeto =D.
Depois desenvolvi alguns plugins corporativos, e depois de um tempo, a pedido do meu amigo Renato Bellia, criei o plugin Diamond Powder for NetBeans. No evento Yahoo Open Hack Day desenvolvi junto com o time Globalcode o plugin Blueprints Yahoo!, e mais recentemente estou colaborando na criação de um plugin para o framework SuperCRUD para o meu amigo Vinicius Senger.

3.Poderia comentar um pouco sobre o plugin que você desenvolveu no Yahoo Open Hack Day onde participou da equipe que ganhou o prêmio Bridging the Gap ?

Para mim foi uma grande alegria e honra participar do time Globalcode, onde ao todo foram desenvolvidos 4 hacks. Sobre o plugin desenvolvido para o Yahoo Open Hack Day, é um módulo que permite a criação de projetos (através de templates) com suporte ao Yahoo! Blueprint, uma tecnologia desenvolvida pela Yahoo que permite a criação de web sites para celulares com uso apenas de XML. O plugin oferece a criação de um esqueleto para um projeto Yahoo, criando os arquivos necessários para seu funcionamento (gallery.xml e config.xml). Além disso, o plugin vem com alguns samples (desenvolvidos pela Globalcode) dentro do NetBeans para os desenvolvedores que querem entender como funciona um projeto Blueprint. E possui suporte a Update Center, Help, e a inclusão do guia do Desenvolvedor em pdf no NetBeans.

4. Quais os conhecimentos necessários para um programador começar a criar módulos para o NetBeans ?

Além de ter conhecimentos sólidos de Java Standard Edition, para o programador iniciar a criação de módulos para o NetBeans, é importante entender como funciona o NetBeans e a sua arquitetura. Procurar enxergar além do IDE, rs.. o IDE NetBeans é construído sobre a Plataforma NetBeans, assim como vários outros produtos, como por exemplo a ferramenta VisualVM, quem utiliza nota a grande semelhança com o NetBeans.
Ao iniciar o desenvolvimento na plataforma NetBeans, já temos disponíveis várias funcionalidades / componentes prontos para o uso e toda esta infraestrutura pode ser manipulada via código através das APIs da Plataforma NetBeans. A plataforma dispõe de APIs para trabalhar com diversos tipos de categorias entre os quais podemos destacar como as Ações do Sistema (Actions), Ant, Paleta de objetos, Debug, Dialogs (para notificação), Sistema de Janelas, Sistema de Arquivos, Editores, Navegação, Loaders, entre outros.
O programador precisa somente entender como manipular estas APIs que ele pode praticamente fazer o que quiser com o NetBeans.

5. Sabemos que você andou fazendo testes com Zembly, poderia comentar um pouco sobre o que é Zembly e para que serve ?

A ideia do Zembly, é criar uma espécie de Wiki para aplicações sociais como o Facebook, ele fornece o ambiente no próprio site do Zembly para criação e edição de aplicações sociais, essa aplicação fica hospedada em uma nuvem do Zembly de maneira que podemos compartilhar nossa aplicação entre diversos sites, como se fossem widgets.
É algo extremamente interessante, pois no Zembly, temos um editor para o código HTML/XHTML para UI, um editor CSS para aplicar os estilos da aplicação e um editor JavaScript para a lógica do negócio, que pode ser utilizado bibliotecas JavaScript como jQuery, Prototype e podemos fazer inclusive integração com diversas APIs como FlickR, Yahoo API, Google Maps, entre outros.
Atualmente estou trabalhando no SOUJava para criar uma aplicação que seja compartilhada pelos sites de tecnologia, fóruns, blogs, de maneira que o SOUJava possa divulgar suas atividades de uma maneira muito mais ampla, pois estes sites deverão apenas incluir um pequeno trecho de código JavaScript em seus sites.

6. Poderia comentar um pouco sobre o Plugin que desenvolveu como colaboração para o SuperCRUD ?

Na verdade, este foi um trabalho relâmpago que montamos para o SuperCRUD e está em evolução, atualmente o plugin permite a criação de qualquer tipo de projeto (web, desktop, maven) com fontes existentes a partir de um servidor remoto, onde o desenvolvedor precisa informar a URL para o projeto (zipado).
Pelo que sei, o desenvolvedor cria um projeto no SuperCRUD, e ao final o próprio SuperCRUD gera uma bookmarkable URL que o programador cola e copia no NetBeans (no plugin), que por sua vez abre o projeto remotamente. Mas claro, sobre esta parte do SuperCRUD o Vinicius poderia dar maiores detalhes =D.

7. Poderia comentar um pouco sobre o Plugin que fez para o projeto Diamond Powder junto com o Renato Bellia?

O Diamond Powder é um framework open source para Java ME desenvolvido pelo Bellia, que acelera a criação de coletores de dados em aplicações MIDP. O framework permite a criação dos formulários, fields (datafield, stringitem, textfield, choicegroup, filter, etc..), definição do fluxo de navegação das páginas e as páginas de help de maneira declarativa, baseada em definições de pares de chave-valor com uso de um Hashtable, que descreve toda a sua organização por um objeto chamado Schema.
O "Schema" é o coração do framework, mas conforme a sua aplicação cresce, fica cada vez mais difícil dar manutenção no seu Schema, como adicionar novas páginas e campos, e é onde o plugin entra, ele facilita muito a criação e a manutenção do código do Schema (com refactoring ou criação de uma nova classe) através de um wizard e evita a digitação errada dos nomes das váriaveis, campos.
Tem a possibilidade de gravar os dados criados (páginas, campos, etc...) em um arquivo properties e reutilizá-los em outros projetos.

8. Você realmente achou um nicho de mercado muito interessante, onde pode colaborar com praticamente qualquer projeto Open Source, quais as dicas que você poderia dar para as pessoas que estão iniciando?

A melhor dica que posso dar é estudar, estudar e estudar. Porém, se você ficar cansado de estudar, estude mais um pouco, faça cursos de java, visite sites de tecnologia como InfoQ, TheServerSide, execute os samples disponíveis no NetBeans e analise o código fonte, participe das listas de discussão. Participe dos eventos, dos minicursos, inscreva-se em todos os feeds possíveis sobre tecnologia, blogs, participe de grupos de discussão, tire certificações e o mais importante, participe de projetos open source, além de aprender com profissionais renomados e compartilhar conhecimento, você estará fazendo networking, sem falar da possibilidade do seu trabalho ficar conhecido no mundo todo.

9. Poderia citar algumas referências para quem quer começar a desenvolver plugins para NetBeans ?

Para as pessoas que estão iniciando, recomendo o próprio site do NetBeans Platform que possui diversos tutoriais, screencasts, wikis, samples que demonstram como criar módulos para o NetBeans, recomendo também o blog do Geertjan, um dos desenvolvedores e evangelista do NetBeans, e existe um livro excelente chamado Plugging into the NetBeans Platform, que apesar de ser de 2007 demonstra em detalhes a criação de módulos para o NetBeans e o uso correto das APIs. E também recomendo meu artigo que foi publicado na edição 29 da revista Mundo Java sobre a Plataforma NetBeans ;).

10. Poderia citar algumas referências para quem quer começar a estudar Zembly?

Para começar a estudar Zembly, o mais importante é conhecer bem JavaScript, (X)HTML e CSS, o resto é entender como funciona o ambiente do Zembly.
Uma ótima referência é o wiki do site, que possui diversos tutoriais de como criar aplicações a partir de templates, criação de aplicações para o Facebook, iPhone, Meebo, entre outros.

Oracle - Sun no fantástico mundo de Hardware

Para quem pensava que a Oracle não iria investir em Hardware, saiu hoje no site da Oracle um comunicado aos cliente da Sun sobre alguns de seus planos, mais especificamente na parte de hardware, observe que final ainda tem um aviso para IBM,

Nós estamos nesta para ganhar.
IBM prepare-se, nós estamos nos preparando para competir com vocês no negócio de Hardware.

Larry Elisson
É esperar para ver !!! =)
Diversão garantida !

Just Java 2009 - O principal evento da comunidade Java Brasileira

quarta-feira, 9 de setembro de 2009



Nos dias 15, 16 e 17 de Setembro acontece em São Paulo o Just Java 2009. Será a 8a. edição do principal evento da Comunidade Java Brasileira.
A grade do evento já está disponível no site http://grade.justjava.com.br/
Esse ano vou apresentar a palestra "De Web Services RESTFul a aplicações Mashups: Como chegar lá".
Onde vou apresentar o conceitos de REST, falar sobre especificação da JSR-311 que define o JAX-RS , falar sobre frameworks de teste, como consumir serviços REST e finalmente falar sobre Mashups, e a importância de REST neste contexto.
 Para se inscrever, acesse o site do evento aqui.

Diversão Garantida!!!

Scrum + XP = Agilidade eXtrema

quarta-feira, 12 de agosto de 2009

Nos dias 07 e 28 de Julho foi realizado no auditório da Globalcode o minicurso Scrum + XP = Agilidade eXtrema, gostaria de agradecer a Globalcode pelo espaço concedido e pela força e também a todos que compareceram, pelo ótimo feedback que recebi.

Para maiores detalhes de como foi o mini-curso acesse o seguinte link no site da Globalcode.

Na apresentação, o intuito foi dar um enfoque teórico e prático de como funciona o Gerenciamento de Projetos Ágeis utilizando XP e Scrum, e no final uma explicação de como combinar as duas.

O que acabou agregando bastante a apresentação foi o próprio público, que iteragiu bastante, com perguntas sobre planejamento e estimativas em projetos ágeis. Foi apresentado alguns técnicas para "vender" Agile em um ambiente corporativo. Conversamos bastante sobre o papel de uma equipe de testes, como escrever os testes de aceite e unitário dentro do TDD, Refactoring, Integração Contínua, priorização dos itens de backlog, User Stories, Débito Técnico, enfim.. três horas pareceu pouco =)


Conforme solicitado pelos colegas, segue a apresentação.

Scrum + XP na prática

Ainda durante a apresentação, demonstrei um vídeo bem engraçado intitulado "O Alpinista", onde fiz uma analogia de um alpinista com gerentes de projeto.. momento bacana para quebrar um pouco o gelo. Segue abaixo o vídeo.



Bom, é isso aí pessoal, obrigado mais uma vez !!!

Scrum + XP = Diversão Garantida !!!

Introdução ao Google Wave - Tutorial e Primeiras Impressões

quarta-feira, 22 de julho de 2009

Como muitos devem saber, a Google está lançando um novo produto chamado Google Wave, que a alguns meses está disponível para beta-testers em um sandbox para desenvolvimento. Se a Google revolucionou a forma como utilizamos a web, agora com Wave eles querem reinventar o email. Tenho testado a ferramenta, e com o uso fui compilando o material que encontrei sobre o wave que irei disponibilizar neste artigo.
Para este post, adaptei grande parte do conteúdo do artigo Google Wave: A Complete Guide do Site Mashable.com com as minhas impressões. O site ainda possui diversos artigos interessantes sobre o Wave.

Para iniciar veja na Figura 1, a aparência do Google Wave.

Figura 1: Aparência do Google Wave.

O Google Wave possui uma interface rica e intuitiva, onde começando da esquerda para a direita, temos a caixa de navegação com a Caixa de Entrada (Inbox), a opção Active apresenta as ondas que estão ativas, a opção All apresenta todas as ondas disponíveis, e assim por diante. Na caixa Contacts, temos a nossa lista de contatos. A coluna do meio (Inbox) apresenta a nossa caixa de entrada, ou a visão que estamos enxergando no momento, similar ao Gmail, que demonstra as mensagens de acordo com o filtro (se houver) estabelecido.
Na terceira coluna, vemos uma onda aberta similar a uma seção de chat.

Mas o que é o Google Wave?

Para resumir, o Google Wave é uma plataforma de comunicação em real-time, que combina diversos aspectos da Web 2.0 que utilizamos atualmente como mensagens instantâneas, blogs, wikis, redes social, sem falar de email =) tudo isso em seu browser.
Pode ser utilizado em diversas finalidades, para gerenciamento de projetos (ferramenta de colaboração), para compartilhar arquivos ou simplesmente iniciar uma conversa, ops , onda. As pessoas podem se comunicar e trabalhar em conjunto formatação de texto rich-text, fotos, vídeos, mapas, e muito mais.

Entre as diversas funcionalidades inovadoras, segue o resumo de algumas disponíveis:

  • Colaboração em Tempo Real: Tecnologia concorrente que permite que as pessoas em uma onda editem conteúdo de mídia ao mesmo tempo. (É possível ver o que a pessoa está escrevendo em tempo real.)
  • Ferramentas de Linguagem Nativa: Google Wave automaticamente corrige palavras escritas erroneamente, e o que achei mais impressionante, ele corrige erros de concordância.
  • Embutível: É possível embutir ondas em qualquer blog ou site. No GDD foi apresentado como publicar uma onda no blogspot, bem legal.
  • Aplicações e Extensões: Assim como o Facebook ou o iGoogle é possível criar aplicações para o wave, desde de robôs até complexas aplicações, gadgets. (Tanto em Java como em Python).
  • Suporte a Drag and Drop: É possível fazer drag and drop de documentos, fotos para a onda, no more attachments ;-)
  • Playback: Uma funcionalidade interessante, uma vez que a onde fica muito grande, se alguém entrar no meio da onda, pode ficar sem entender o histórico, para isso foi disponibilizado um botão (Playback), que é possível ver o que foi dito em qualquer parte da onda. E o melhor, o projeto é open source \o/
Terminologia

Para entrar na onda, é preciso entender o linguajar do Google Wave, que ajuda a definir e contextualizar essa nova plataforma de comunicação. Entender estes termos irá ajudar a compreender mais este novo projeto. Veja a Figura 2, que apresenta estes conceitos de maneira visual.

Figura 2: Entendendo os termos de uma Wave

  • Wave: A onda refere-se a uma thread especifica de uma conversação. Pode serincluída apenas uma pessoa, um grupo de usuários ou mesmo robôs. Que seria todo o histórico de conversação de um email.
  • Wavelet: Um wavelet é também uma thread de conversação, mas somente um subconjunto de uma grande conversação (ou uma onda).
  • Blip: Ainda menor que uma Wavelet, um Blip é uma única, mensagem individual. Blips podem conter outros blips anexados a ele. Para saber mais sobre Blips, acesse http://www.blippr.com/apps/337306-BLIP.
  • Documento: Refere-se ao conteúdo dentro de um blip. Podemos ser simples caracteres ou arquivos associados ao blip.
  • Extensões: Um extensão é uma mini-aplicação que opera dentro de uma onda. Existem dois tipos de extensão, os Gadgets e os Robots
  • Gadgets: Um gadget é uma aplicação onde os usuários podem utilizar em conjunto, a maioria é construída sobre a plataforma OpenSocial (da Google), podemos fazer uma comparação com os gadgets do iGoogle ou as aplicações do Facebook. Veja a Figura 3, para alguns exemplos de gadgets (Google Maps, Polls de pesquisa, um jogo de xadrez, entre outros).

Figura 3: Gadgets para o Google Wave.

  • Robots: Robots são aplicações (robots) que participam de uma onda. Eles podem interagir com os usuários de uma onda, podem fornecer informações de fontes externas como o Twitter, ou podem tomar ações baseadas no conteúdo digitado pelos participantes de uma onda, um exemplo muito interessante é o robô Rosy Etta, que em tempo real traduz o conteúdo de uma onda para participantes de linguagens diferentes (ex: Japonês x Inglês) =) ,, na apresentação do GDD este ano, este foi um dos pontos altos da apresentação \o/. Veja na Figura 4 alguns robôs em ação.

Figura 4: Robôs em ação em uma onda.
  • Ondas Embutidas: Uma onda embutida é uma maneira de levar uma conversação de uma Wave para dentro de seu site ou blog. Sendo possível utilizar a mesma como chat ou uma maneira de se comunicar com você.

Figura 5: Exemplo de Ondas embutidas

É isso aí, esse é apenas um aperitivo que vem por aí, lembrando que o Google Wave não está disponível ainda para o grande público, se a ansiedade for grande demais =) , solicite acesso ao acesso Dev Preview, e torça para ganhar um convite.

No próximo vou demonstrar como criar um robô passo a passo para o Wave.

Diversão Garantida!!!

RESTful Web Services e a API JAX-RS na revista Mundo Java, nº 35

terça-feira, 9 de junho de 2009


No mês de Maio foi publicado mais um artigo meu na revista Mundo Java, sobre a REST desde o conceito proposto pelo Dr. Roy Fielding até a implementação JAX-RS em Java, com diversos exemplos práticos no Jersey.

Graças a Deus tenho recebido um bom feedback das pessoas, no artigo procurei demonstrar as tecnologias por trás de um serviço REST, onde fiz primeiro uma introdução ao HTTP, para auxiliar aos leitores que estão iniciando a compreender a dinâmica do serviço.

Ainda no artigo, apresentei um artigo bem completo sobre a API JAX-RS, e mostrando na prática com diversos códigos como se trabalhar com os recursos, tratamento de exceções, extração de parâmetros e valores da URI na requisição.
Como trabalhar o retorno dos métodos ao Cliente, dando uma visão geral dos Providers.

E por fim, apresentei um guia de ferramentas para teste, e como consumir serviços REST, utilizando a API JAXB para conversão dos dados em objetos, uso prático da biblioteca Jakarta Commons HTTP Client, o uso de bibliotecas JavaScript como o jQuery, e o uso de JavaScript / AJAX..

Sem dúvida, uma ótima pedida para quem esta iniciando o desenvolvimento de serviços REST.

Além do artigo, tem vários destaques na revista deste mês, conforme segue:

Projeto da Certificação SCEA 5
Um exemplo fictício de projeto para a segunda fase da cobiçada certificação de arquiteto Java EE.
Autores: Márcio Varchawski

Conhecendo a Plataforma JavaFX Mobile
Através deste artigo crie e compreenda seus primeiros aplicativos utilizando a plataforma Java- FX Mobile.
Autores: Ricardo da Silva Ogliari

Mundo OO: Padrões de Projeto com Generics
Aprenda como tirar vantagem de Generics na implementação de Padrões de Projeto em suas aplicações Java.
Autor: Alexandre Gazola, Alex Marques Campos

RESTful Web Services e a API JAX-RS
Conheça o poder dos serviços REST e a implementação de Referência da Sun, o Jersey.
Autor: Wagner Roberto dos Santos

ProfessorJ: Conhecendo os parâmetros de configuração mais utilizados da JVM
Aprenda como configurar a Máquina Virtual JAVA para evitar os indesejados estouros de memória.
Autores: Rodrigo de Azevedo

Tendências em Foco: Adotando o Open Source no Ensino da Computação
Entenda a estratégia de adoção do Open Source no ensino da computação e programação Java.
Autor: Cezar Taurion

SOA na Prática: Governança em SOA - Versionamento de Serviços
Aprendendo a lidar com questões de versionamento de serviços dentro de uma arquitetura SOA.
Autor: Ricardo Ferreira

Made in Brazil: JColtrane - Parser XML com SAX + Anotações
Conheça essa alternativa nacional para processesar arquivos XML sem comprometer memória e a clareza do código.
Autor: Renzo Nuccitelli, Eduardo Guerra










Diversão Garantida !!!

Web Services WS-* vs REST.

quinta-feira, 14 de maio de 2009

Muitos sites, blogs e fóruns têm colocado seus pontos de vista em relação ao uso de web services REST e SOAP, gerando muitas vezes calorosas discussões.

Na verdade, não existe uma disputa entre eles, pois cada um possui uma proposta bem diferente. Vários estilos diferentes de aplicações tem sido utilizadas para integrar sistemas de informação corporativos, entre as opções, existem os banco de dados compartilhados, transferência de arquivos (EDI ), remote procedure call (RPC), ou troca de mensagens assíncronas via uma sistema de mensageria. Ao fazermos uma comparação entre REST e WS-* (pronucia-se ws-star), precisamos fazer uma comparação quantitativa baseado em princípios arquiteturais que envolvem questões relacionadas a cenário, tecnologia, métodos, formato dos dados trafegados, segurança, transação, entre outros fatores da sua aplicação. Devemos lembrar que estas tecnologias surgiram para suprir estes problemas recorrentes na maioria dos projetos de software, que é a interoperabilidade.

Foi quando começaram a surgir esforços da comunidade de buscar dos grandes players interoperabilidade entre suas plataformas, aplicações, e linguagens de programação. Foi quando surgiram as especificações WS-*, que atendem tanto ao estilo RPC quanto mensageria. A especificação SOAP não define como deve ser um message header, ou elementos do corpo do envelope, dessa maneira podemos ter aplicações que customizem o tipo de header que ela aceita, e o tipo de informação que deve estar vinculado ao body para uma operação em particular, sem falar que algumas dessas informações podem ser compartilhadas por diferentes aplicações, sem falar em questões de segurança, roteamento de mensagens, entre outros fatores.

As especificações WS-* definem padrões para mensagem, troca de metadados, segurança, entre outros. No mundo Java, para implementar este mundo de especificações, foi aberto o projeto WSIT (antigo projeto Tango) como parte do projeto Metro, que por sua vez faz parte do projeto Glassfish, veja a Figura 01 os padrões (em verde) utilizado no projeto WSIT.

Figura 1: Padrões de Web Services utilizados no WSIT.

É claro que para a maioria dos projetos, um web service simples resolveria, mas se começarmos a entrar mais a fundo no mundo orientado a serviços, começa a surgir a necessidade de integração com diversos sistemas, naturalmente teremos que utilizar estes padrões. É somente olhar para a figura 01 que já causa calafrios em muitos desenvolvedores, mesmo com suporte eficiente nos IDEs existentes.

Com isto, vemos claramente que a arquitetura de web services baseadas nas especificações WS-* é muito bem definida, com regras para trocas de dados, segurança, o que por conta de seu excesso de padrões acabou se tornando uma solução muito complexa.

Mesmo com toda a complexidade, serviços WS-* têm tomado cada vez mais espaço no mercado, graças aos projetos SOA que tem adotado largamente serviços WS-* por sua independência e transparência de protocolo. Por outro lado, REST é muito mais simples, como uma resposta para todos estes padrões e especificações, para utilizar REST basta ter um conhecimento razoável sobre HTTP e seus métodos.

Enquanto web services WS-* são orientados a atividade/serviço, serviços REST são orientados a recurso. Quando falamos em desenvolver serviços SOAP, estamos falando em criar APIs, contratos (WSDL), onde o WSDL descreve os detalhes de implementação, como as operações e os tipos de dados trafegados. REST por outro lado, conforme explicado no inicio diz respeito a utilizar o protocolo HTTP para manipular o estado de um recurso. Fazendo uma analogia, podemos dizer que assim como a linguagem de manipulação de dados (DML) do SQL é utilizada para manipular as informações de um banco de dados transacional, REST utiliza os métodos (verbos) do protocolo HTTP para manipular o estado de uma informação. Com estes verbos, podemos fazer praticamente tudo o que quisermos com os dados, independente se usarmos SQL ou HTTP.
Ao mapear os métodos HTTP (POST, DELETE, GET E PUT) com operações DML de um banco de dados temos a seguinte estrutura, conforme ilustra a tabela 01.

Métodos HTTP / Operações CRUD
GET -> SELECT
POST -> INSERT, UPDATE
PUT -> INSERT, UPDATE
DELETE ->DELETE

Tabela 01. Associação dos métodos HTTP com operações CRUD.
Na tabela podemos notar que podemos ter mais de uma operação relacionada a um verbo HTTP, como por exemplo, o método POST, que pode ser utilizado para diversas ações. O método PUT nos dá a possibilidade de criar um novo recurso, ou substituir por outro mais atualizado. Apesar dos diversos tutoriais e exemplos que encontramos na internet sobre REST que envolvem operações CRUD, isso não quer dizer que temos que ficar presos somente a estes tipos de operações. Por conta de sua própria natureza, REST é mais fácil e funciona muito bem com CRUDs, mas podemos em nosso design criar serviços REST. Web Services RESTful.



Pontos Positivos
Pontos Negativos
  • Linguagem e plataforma agnóstica.
  • Simplicidade, interface imutável.
  • Interação assíncrona, não possui estado.
  • Facilidade de adoção, pois não requer uma grande infra-estrutura, muito menos um middleware para WS-* ou camada intermediária adicional.
  • Utiliza a própria web como meio de transporte, sendo assim uma carga baixa para a rede.
  • Utilizada por grande parte das aplicações Web 2.0. (Google, Flickr, Amazon, etc..). Portanto, ótimo para mashups.
  • Curva de aprendizagem baixa.

  • Faltam padrões.
  • Falta de segurança (dados sigilosos não deveriam ser enviados como parâmetros na URI).
  • Não é indicado para trafegar grandes volumes de parâmetros via URI, no caso de PUT/POST para inclusão de dados, por exemplo.
  • Em muitas empresas apenas os métodos GET e POST do HTTP são liberados em proxies e firewalls. Dentro desta limitação, muitos preferem utilizar os métodos GET para requisições de consulta e POST para todo o resto.
  • Não há mecanismos de transação (Do it yourself)
  • Não existe um padrão como UDDI para service discovery.

Tabela 02: Pontos positivos e negativos de REST

SOAP


Pontos Positivos
Pontos Negativos


  • Diversas ferramentas de desenvolvimento.
  • Tipagem forte e um vocabulário bem definido.
  • Quando utilizado sobre HTTP, dificilmente é bloqueado por proxies e firewalls.
  • Permite o uso de diferentes tipos de protocolos.
  • Plataforma independente.
  • Linguagem independente.
  • Diversos padrões.
  • Complexidade dos padrões.
  • Performance.
  • Mensagens podem ficar muito extensas, por serem codificadas com XML
Tabela 03: Pontos positivos e negativos com SOAP.

Fazendo esta pequena análise, chegamos á conclusão de que ambas as soluções são úteis, e a utilização de cada uma depende do contexto em que será aplicada.

Referências (Links):

[Parley] A Little REST and Relaxation: http://tinyurl.com/cm33t2
Estilo SOAP vs Estilo REST: http://www.ibm.com/developerworks/webservices/library/ws-restvsoap/
Descrevendo Serviços REST com WSDL 2.0: http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/
Bruno Pereira: http://brunopereira.org/2008/05/14/precisamos-de-um-descritor-de-servicos-rest/

XP - Extreme Programming - Embrace Change Summary

sexta-feira, 17 de abril de 2009

As you may already know, XP is a lightweight methodology created by Kent Beck, for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.

To help the understand of the basis, i'm providing a summary and a mind map of the book eXtreme Programming - Embrace Change, by Kent Beck, as you can see below. Enjoy it!

Figure 1: Extreme Programming Mind Map

XP - Embrace Change is a small book, quite fast and easy to read, it took me only two days to finish it.
As Kent Beck said "XP is a philosophy of software development based on the values of communication, feedback, simplicity, courage, and respect."

The Basic Problem

Software development fails to deliver, and fails to deliver value. This failure behind software development has a huge economic and human impact. So it was the reason to find ways to develop software.

First recognize risks and try to address it applying some XP practices, like short release cycles to limit scope, one to four week iterations of features requests from customer, it will give you a fine-grained feedback about progress.
Economics of Software Development

Create a strategy for maximizing the economic value of the project, spending less, earning more (depends strategy), spending later and earning sooner, increase probability that the project will stay alive.

In projects we have to control five variables: cost, time, quality and scope, like PMBoK scope is the best way to achieve control. KEEP FOCUS ON SCOPE.
Cost of Change

The cost of changing a program rises exponentially over time. Figura 2 shows that the longer it takes you to find a defect then on average the more expensive it is to address.

Figure 2 - Cost of Change [Scott W. Ambler, 2006]

To overtake problems related to cost of change, after years of production some factors became clear like a simple design, intensive use of automated tests, refactoring code and design, incremental design, continuous integration.
Learning to drive.

Everything in software changes. requirements, design, business, technology, team members change. The problem
isn't change, the problem, rather, is the inability to cope with change when it comes.

Learn to control the development of software by making many small adjustments, not by making a few large adjustments, kind of like driving a car.


The driver of a software project is the customer. If the software doesn't do what they want it to do,
you have failed. Of course, they don't know exactly what the software should do. That's why
software development is like steering, not like getting the car pointed straight down the road. Our
job as programmers is to give the customer a steering wheel and give them feedback about
exactly where we are on the road.

XP Values

  • Communication: Ensured an effective comunication of your team and your organization core values.
  • Simplicity: Search for simple solutions.
  • Feedback: Work with your customers at your side, seat the team together.
  • Courage: Throw code possible whenever itŽs possible (keeping your code simple). Courage to change, to assume your faults.

PUT ALL THESE VALUES IN PRACTICE.

The Four Basic Activities

  • Coding: Code is the one artifact that development absolutely cannot live without, it gives you a chance to communicate clearly and concisely.
  • Testing: Writing every test you can imagine.
  • Listening: Learn to listen your customer, he knows about the business not you.
  • Designing: Good design ensures that every piece of logic in the system has one and only one home.

Figure 3 - XP Overview.
The Practices

Primary Practices
------------------------
-Integration
  • Ten minute build: Automatically build the whole system and run all of the tests in ten minutes.
  • Continuous integration: Integrate and test changes after no more than a couple of hours.
-Whole Team: Create cross-functional teams. Create a team with all the skills necessary for the project to succeed.
-Programming
  • Test-First Programming: [TDD] Test -> Code -> Refactor
  • Incremental Design: Keep the design investment in proportion to the needs of the system.
  • Pair Programming: Help to:
  1. Keep each other on task.
  2. Brainstorm refinements to the system.
  3. Clarify ideas.
  4. Lower frustration.
  5. Hold each other accountable

-Energized Work: Take care and respect yourself.

-Planning
  • Weekly Cycle: Plan work a week at a time, have meeting at the beginning of every week. During meetings, review progress, ask your customer to pick some stories to implement and break stories into tasks.
  • Monthly Cycle: Plan work quarter at a time, Identify bottlenecks, Initiate repairs, Plan the theme, pick the stories.
  • Stories: Write the stories on index cards and put them on a wall.
  • Slack: Include some minor tasks that can be dropped if you get behind in your plan.

The Planning Game:
  1. List the items of work that may need to be done.
  2. Estimate the items.
  3. Set a budget for the planning cycle.
  4. Agree on the work that needs to be done within the budget. As you negotiate, don't change the estimates or the budget.

Corollary Practices
--------------------------


-Business Negociated Scope Contract: Try a sequence of short contracts instead of one long one.
  • Pay-per-use: Charge for every time the system is used.
  • Daily Deployment: Put new software into production every night.
-Incremental Deployment: Find a little piece of functionality and deploy it.
-Programming
  • Single Code Base: Keep only one code stream.
  • Code & Tests: Mantain Code and tests as permanent artifacts.
  • Shared Code: Anyone on the team can improve any part of the system at any time.
-Root Cause Analysis: Eliminate defect and its cause. To find the Root cause, apply Taiichi Ohno's exercise, called "Five Whys":
  • Why did we miss this defect?
  • Why didn't we know?
  • Why isn't she part of the team?
  • Why doesn't anyone else know how?
  • Why isn't it a management priority?

-Real Customer Involvement: Put your customer at your side.
-Team
  • Team Continuity: Keep effective teams together.
  • Shrinking Teams: Lean Thinking, reduce the size.





If you like it, buy the book here..