O público era bem misto, com pessoal técnico e não técnico. Bastante gente veio conversar comigo no fim da palestra e demonstraram surpresa com relação a abordagem diferente sobre SOA. Um pouco na linha do fantástico Guerrilla SOA do Jim Webber, tentei falar sobre o assunto sem tentar vender nenhum produto gigante middleware-de-integração. Se você ainda não viu: veja agora, sério. A minha palestra fala um pouco sobre como SOA não precisa ser buzzword, SOA é integração:

Talvez a palestra não faça tanto sentido para quem não esteve presente, mas fiquem a vontade para dar uma olhada e comentar a respeito.

Esta semana tive o prazer de palestrar no Café Com Tapioca, evento do CeJUG realizado em Fortaleza. Estavam presentes dois conhecidos evangelistas da Sun: Reggie Hutcherson e Simon Ritter.

O agradecimento fica ao Rafael Carneiro, do PortalJava e do CeJUG, pela organização geral do evento. Agradeço também à equipe do grupo Fortes pela minha vinda ao Ceará: ao Clavius Tales, Igo Coelho, Antônio Israel, Ronaldo Moreira, Tiago Moraes, Rodrigo Maia e tantos outros. Vale reparar como a comunidade java cearense é ativa nos blogs! Nesse sábado também ministrei umworkshop sobre Arquitetura e Design Java aqui em Fortaleza.

Durante esses dias aqui, muitas pessoas perguntaram bastante sobre webservices: em especial JSON e Rest. Compilei alguns dos pontos que foram recorrentes nas discussões e considerados como boas práticas:

Cuidado com a granularidade – a granularidade do seu serviço não pode ser muito fina, caso contrário seus seviços sofrerão dos mesmos problemas que o EntityBean do EJB2 exposto remotamente: uma enorme quantidade de requisições serão disparadas para executar pequenas tarefas, como getters! Seus serviços devem realizar uma quantidade significativa de tarefas, para evitar um número alto de roundtrips!

Exponha serviços, não dados – é comum ouvir a frase “Vou criar webservices para expor os meus dados“. O grande perigo aqui é deixar toda a lógica de negócio na mão do cliente, o que descentralizará seu serviço e forçará o cliente a realizar muitas requisições ao servidor. Devemos expor serviços, e não dados em sua forma mais crua.

Nunca parsear WSDL/SOAP manualmente – antes das ferramentas que trabalham com webservices terem atingido sua maturidade, era muito comum ver por aí as pessoas gerando o SOAP manualmente, através de bibliotecas XML ou às vezes até mesmo concatenando String com o uso de StringBuffer! O SOAP é o protocolo de comunicação, e assim como quando você usa RMI/CORBA e você não enxerga absolutamente nada do JRMP/IIOP, você nunca deveria ter contato direto com o protocolo de comunicação! O SOAP e o WSDL devem ser utilizados por ferramentas, e não pela sua própria aplicação. Hoje em dia qualquer ferramenta como o Apache Axis, Apache CXF, ou mesmo o wsimport, que já vem no JDK 6, auxilia nossa tarefa de gerar Stubs que sabem trabalhar com o SOAP, sem que você nem mesmo precise ve-lo um dia. Se você está usando um servidor de aplicação, esta tarefa é ainda mais fácil, até mesmo para fazer o deploy do serviço.

Não enviar XML dentro de XML – outra prática comumente encontrada em aplicações antigas que usam Webservices: dentro do SOAP é enviado um outro XML como um dos parâmetros, então mesmo usando ferramentas para gerar os stubs você fica com uma String que dentro dela há um XML e este precisa ser parseado por sua própria aplicação. Isto é uma má interpretação do conceito que “Webservices é comunicação via XML“. Concordo que em alguns raros casos isso possa fazer sentido, como por exemplo se o valor do que você quer realmente é um outro XML, mas no geral isto é feito sem necessidade nenhuma, como é o famoso caso do WebService MS Office dos Correios do Brasil.

Considerar protocolo binário – são muitas as reclamações de que o SOAP acaba sendo um XML grande e pesado para ser transportado. Hoje em dia há muitas formas de contornar isso, como o uso do padrão Fast InfoSet para compressão do XML. Uma outra forma seria o uso de protocolos proprietários, como o AMF da Adobe, que é uma opção comum no uso do Flex.

Considerar não usar WSDL/SOAP – pelas diversas críticas a burocracia exagerada do WSDL/SOAP, muitas pessoas estão optando por usar algo mais simples, como o bom e velho XML (POX), JSON ou até mesmo uma forma qualquer de estruturar dados. Caso você precise de simplicidade e velocidade no desenvolvimento com outras plataformas, essa é uma boa opção. Cuidado: muita gente está considerando qualquer webservice que não use WSDL/SOAP como sendo REST. Os webservices do flickr e da Amazon são um bom exemplo: tudo é via GET (as vezes POST) e não há recurso identificado pela URI. Na verdade ele usa apenas um esquema HTTP+XML (POX), considerado apenas em parte como RESTful. Você pode ver que esses webservices são muito diferentes do modelo RESTful do Atom Publishing Protocol. Criar um protocolo realmente REST como este não é fácil: porém teremos esse trabalho bastante simplificado com a JAX-RS (JSR 311), e já podemos ver isso através do Glassfish Jersey.

Considerar usar JSON – JSON é um formato que tem ganho muita popularidade. Não é a toa: além de ser um simples para debugar, parsear e gerar, com javascript basta fazer um eval em um resultado JSON que ele já estará pronto para usar. É uma excelente opção para o consumo via AJAX e criação de mashups. JSON tem ganho bastante força na comunidade Flex, tornando-o uma ótima opção como ponte entre Flex e Java. A escolha por JSON abre portas para muitos tipos diferentes de clientes, e em especial o browser, que é nossa plataforma global.

Update: numa abordagem mais REST, a granularidade pode ser sim fina (e focada nos dados), tomando cuidado para deixar isso explícito, e sempre atento aos headers que possibilitarão o cache.

Fui ver então como ele podia inserir um tema que tem tantos detalhes e conceitos em um curso que já era pesado. Ele está usando a JSR 181, que define anotações para a criação de um webservice para qualquer bean que você deseje deixar acessível. Fiquei muito impressionado com a simplicidade. Vamos direto ao código:

@WebService
public class AgenteDeReservaBean {
  @WebMethod
    public boolean reserva(@WebParam(name = "nome") String nome,
                                         @WebParam(name = "voo") String voo) {

    // acesso ao EntityManager injetado
    // logica de negocios, ou delegacao para o BO
    return false
  }
}

@WebParam é opcional, mas como o bytecode do java 5 não retém os nomes dos parâmetros (em outras palavras, por reflection você não obtém essa informação), o WSDL gerado iria gerar nomes automáticos para os parâmetros (arg0, arg1, etc).

Como ativar esse webservice? XMLs gigantes de configuração? Não! Basta um container que já faz tudo isso para você.

Existem algumas opções de implementações da JSR-181. O pessoal do GUJ gosta do XFire, mas como ele não é um container Java EE 5, você precisa fazer algumas configurações (tais como o web.xml e um outro xml dele próprio) para realizar o deploy.

O JBossWS é uma opção extremamente simples: anote sua classe com @Stateless, instale o JBoss 4.0.x com suporte a ejb3, ligue-o, gere o viagens.jar com essa única classe, deploy, e acesse:

http://localhost:8080/viagens/AgenteDeReserva?wsdl

Seu webservice já está respondendo nesse memo endereço (sem o ?wsdl no final, claro). Um monte de defaults foram usados (nome do serviço, das operações, do resultado, complex types, etc), você poderia configurar tudo isso através das anotações.

Você ainda pode gerar a interface do endpoint necessária através do wstools que acompanha o jboss. Uma maneira extramamente mais simples é já criar um endpoint, definindo essa interface como @WebService, e no seu bean você pode indicar que essa interface é o seu endpoint, evitando assim a geração de código java.

É, e você pensava que o Apache Axis te ajudava bastante para criar um webservice...