CAELUM

O Paulo colocou um capítulo de webservices no curso de EJB, com o intuito de aumentar a abrangência do curso em relação as novidades do Java EE 5 e aos poucos diminuir a pesada carga da 1.4, conforme o mercado assimila mais a nova versão.

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…

Ontem fui almoçar com alguns desenvolvedores da Nextel e da 2RP Informática, no Súbito da avenida Paulista (creio que as palavras que mais se ouvem naquele restaurante são Lasagna, Oracle, .NET e Java).

Durante a digestão das massas conversamos sobre os assuntos que estão na boca do desenvolvedor: frameworks, servidores de aplicação antigos, as brigas com o DBA, o super aquecimento do mercado Java e atrasos nos projetos.

A questão girou em torno de adicionar mais pessoas em um projeto que já está atrasado. Lembro-me de anos atrás o Michael ter conversado comigo sobre esse assunto, e só depois vim a ler The Mythical Man-Month, um livro com diversos ensaios sobre engenharia de software e gerenciamento de projetos.

Em um dos principais ensaios, o qual o entitula, Fred Brooks disserta a respeito do mito do homem-hora (em inglês homem-mês, mas aqui no Brasil o termo usual das consultorias é medido em horas, por isso escolhi essa tradução).

Desse livro cunharam a lei de Brooks:

Adicionar desenvolvedores para um software atrasado deixa-o mais atrasado ainda.

Não vou entrar em detalhes, apesar do ensaio ser bem curto, mas o autor critica severamente o hábito de mensurar projetos através da quantidade de homens-horas que este irá levar. Ele começa com um exemplo de um projeto com cronograma de 4 meses e 3 programadores, e que depois de um mês de trabalho, percebe-se que há a necessidade de mais um mês. As opções então são mostradas: atrasar o projeto ou segurar o projeto e colocar mais pessoas (e você vai ficar surpreso de quantas pessoas a mais serão necessárias para isso). Fortemente indicado, o livro já tem 25 anos e há uma edição comemorativa com alguns ensaios reescritos.

Uma infinidade de empresas de tecnologia possuem blogs para os seus desenvolvedores. Isso faz parte do cotidiano dos funcionários da Microsoft, da Sun, do JBoss e muitas outras. Aqui no Brasil o mesmo ocorre. A Locaweb agora possui o seu blog e oferece o serviço de blog para as empresas que tem hospedagem com eles. Com tudo isso, porque não o blog da Caelum?

Depois de uma fase de testes, rascunhos de artigos e coleta de opinião com colegas, desenvolvedores e amigos, optamos por criar um blog voltado para o público mais técnico de autoria de todos os desenvolvedores da empresa.

Esperamos que você possa aproveitar aqui das dicas, pequenos exemplos e notícias. Contamos com seus comentários e sugestões, em especial nesse começo de uma nova empreitada.

Este post no guj trouxe uma discussão já conhecida de volta a ativa: singleton. Devemos usar singletons ou métodos estáticos?

O Carlos Villela já coloca uma opinião muito interessante:

Estado mantido de forma estática numa aplicação é tão venenoso quanto variáveis globais. Não importa como esse estado é acessado. Seja via singletons ou métodos estáticos, vai continuar sendo venenoso.

Mais para frente, ele ainda diz:

Singletons é um indício de que você precisa pensar melhor sua arquitetura

Muitas pessoas (inclusive eu) consideram o Carlos Villela um extremista da orientação a objeto. Mas nesse tópico eu concordo totalmente com ele: estamos viciados em usar Singletons apenas para facilitar nossa busca por uma varáivel global (no caso de OO, uma referência a um objeto que é compartilhado globalmente). Quando que realmente faz sentido existir um e apenas um objeto de determinado tipo? É raro.

Em outras palavras, você deve evitar ao máximo a utilização de métodos estáticos (que tem um sabor de função procedural) e nem singletons (com o sabor variável global). Como resolver essa nossa necessidade? Certamente com injeção de dependências. Algumas pessoas já classificam Singleton como um antipattern: uma má solução para o seu problema.

A idéia é que você tire a responsabilidade de fazer lookup de recursos da sua lógica de negócio, e que esse seu recurso (essa sua dependência) seja lhe dada (injeção de dependências, DI) por outra pessoa, invertendo assim os papéis (inversão de controle, IOC): você não mais busca por um recurso, esse recurso é dado a você!

Entendo que muitos dos leitores já estão cansados de usar essas técnicas, mas vale lembrar que elas são úteis também no nosso caso de Singletons. Tanto que você vai encontrar diversos tópicos por aí como este: Como refatorar Singleton para injeção de dependências.

Mais abaixo o Villela fala do interessante recurso que alguns linguagens consideradas mais puramente OO tem, que no Java seria equivalente ao seguinte trecho (apenas ficção):


Integer i = 5;
Integer raiz = i.squareRoot();


Imagine todas as classes wrappers terem todos os tipos imagiáveis de operações? Não só elas, mas também BigInteger e BigDecimal? Nesse caso ainda prefiro as funçõezinhas procedurais da java.lang.Math :).