Java EE 6 para quem está com pressa

Eu sempre achei legal aprender linguagens de programação, novas maneiras de expressar ideias em código. E linguagens são relativamente fáceis de testar: digitar ou copiar um trecho de código e mandar compilar/rodar. Se tiver um REPL (uma linha de comando interativa), é melhor ainda.

Já coisas mais “enterprise” (cof, cof) eu sempre achei um saco. Java, Java EE e a infinita disponibilidade de frameworks para Java eram os grandes culpados. Às vezes realmente eram tecnologias pouco importantes mesmo, que cairiam no esquecimento afogados na própria complexidade, mas outras vezes surgem coisas bem legais mas que ainda assim não são tão acessíveis: de qualquer jeito, só para começar, a pessoa tem que instalar um ambiente com editor, compilador, interpretador/VM, um servidor web, um banco de dados, ferramenta de construção (Ant ou Maven, se não quiser ficar preso ao Eclipse, NetBeans, JDeveloper, etc.), JARs de algumas bibliotecas e frameworks extras, caso não esteja usando o Maven para baixá-los… Faz lembrar este vídeo: Java vs Ruby On Rails (não que eu conheça Rails, mas a parte Java é bem realista). Nem todas essas coisas são obrigatórias, mas a maior parte acaba sendo.

Mas como eu ia dizendo, às vezes tem coisas legais, depois de transpor a barreira inicial. E o Java EE 6 não é mais aquele inferno de XMLs de configuração que fazem qualquer um esquecer o objetivo do programa/tutorial que está construindo/seguindo enquanto configura coisas irrelevantes. Às vezes era fácil até de esquecer o que realmente é o Java EE: Java EE é o mesmo que EJB? JSP também é Java EE? E no que isso tudo me ajuda?

Então, para dar uma visão geral e ter condições de posteriormente ler algo mais aprofundado sem se perder, aqui vai um resumão:

Servlet: classe que responde a requisições HTTP. Declarada com @WebServlet ou no web.xml. Servlets são instanciados uma vez e acessados simultaneamente por todas as requisições (cuidado com variáveis de instância, elas serão compartilhadas por todos os clientes!). A partir de um servlet você pode despachar a requisição para um JSP (que também é um servlet) ou gerar dinamicamente toda resposta, seja HTML ou outra coisa (por exemplo, até mesmo gerando uma imagem para um captcha).

Filter: classe que é executada “ao redor” de uma requisição HTTP (ao redor de um servlet). Declarado com @WebFilter ou no web.xml.

web.xml: arquivo de configuração que fica dentro da pasta WEB-INF, que fica dentro de um arquivo war. Nele você configura servlets, filters e qualquer coisa em geral que construa sobre essa fundação. Tornou-se opcional por causa das novas anotações @WebServlet e @WebFilter, mas ainda tem bastante utilidade (por exemplo, escolher a ordem dos filters)

Os três itens acima são a base (mas não tudo) da parte web do Java EE. Se você já ouviu falar dos frameworks para construir sistemas web em Java, é [quase] certo que esses frameworks são ou contêm alguns servlets e/ou filters que dão um jeitão novo para o desenvolvimento. Esse “jeitão” que eu digo pode ser a troca dos JSPs por outra linguagem de marcação, ou um arquivo de configurações diferente, ou funcionalidades extras pré-empacotadas, etc.

JSP: página HTML com umas tags especiais para integração com o Java. No fim é compilado para um servlet por baixo dos panos. Então, cuidado ao usar variáveis declaradas entre <%! … %>, porque serão compartilhadas por todos os clientes — variáveis entre <% … %> e guardadas nos escopos “page” e “request” não têm esse problema. Algumas das tags especiais são as tags do JSTL. Possui também uma minilinguagem chamada EL (Expression Language) para fazer coisas como ${objeto.propriedade} no meio de uma página ou atributo de tag.

JSF: uma tentativa de fazer que sites se comportem como programas desktop, usando componentes e tentando de certa forma abstrair a existência das requisições HTTP. Não gosto muito, porque complica coisas simples (e complica coisas complicadas também — o ciclo de vida de uma requisição é um saco de entender). As páginas podem ser escritas em JSP ou Facelets (um Facelet é basicamente um XHTML com algumas coisas a mais) e costumam usar a EL na forma #{objeto.propriedade}.

JAX-RS: uma maneira diferente de atender requisições HTTP com algumas facilidades para fazer web services do tipo RESTful (REST significa simplesmente “HTTP do jeito que seu criador tinha realmente imaginado”), retornando JSON, XML ou outros formatos. Declarado com @Path na classe ou método. A configuração global do JAX-RS fica numa classe que herda de Application e é anotada com @ApplicationPath. A URL gerada será a concatenação do @ApplicationPath + @Path da classe + @Path do método (se houver).

JAX-WS: outro jeito de fazer web services, só que com mais XML (formato SOAP). Usa a anotação @WebService, entre outras.

CDI: você declara uma classe com @RequestScoped, ou @SessionScoped, ou @ApplicationScoped, ou o default @Dependent e em [quase] qualquer outro lugar do programa você declara um objeto dessa classe com @Inject em cima. E magicamente você obtém uma instância no escopo correto sem se preocupar como nem quando esse objeto foi criado (na verdade você obtém um objeto proxy que acessa o objeto verdadeiro no escopo correto). O objeto que recebe outros objetos por injeção deve ser instanciado pelo contêinter (servlet, EJB, managed bean do JSF, outro bean CDI, etc.), ou seja, o @Inject não funciona para objetos instanciados com new (a construção de objetos normais do Java não muda). Possui também outros recursos como eventos e interceptors. É necessário ter um arquivo beans.xml (mesmo vazio) no WEB-INF ou META-INF do seu pacote (war, jar) para usar os recursos do CDI no Java EE 6.

EJB: classe anotada com @Stateless, @Stateful ou @Singleton que é capaz de iniciar e terminar (com commit ou rollback) transações automaticamente entre outros recursos. As transações incluem bancos de dados (com JDBC ou JPA), serviço de envio mensagens (JMS) e timers. EJBs eram famosos por serem complicados antigamente, mas agora estão bem fáceis de usar, basta a anotação, e têm uns recursos novos como chamadas assíncronas. Assim como objetos do CDI, podem ter interceptors. Ao contrário de servlets, EJBs @Stateless não são acessados simultaneamente, o servidor contêiner faz um pool deles para atender as chamadas e por isso o código não precisa se preocupar com reentrância. Já os EJBs @Singleton, naturalmente, só são instanciados uma vez (por nodo num cluster), e têm suas próprias @anotações para controle concorrência.

JPA: você cria classes com @Entity e usa elas para representar linhas do banco de dados. A manipulação dessas @Entity‘s é feita com um EntityManager que pode ser obtido com @PersistenceContext. Com EJBs, tudo fica integrado e o contexto é automaticamente propagado, de modo que não é necessário ficar passando o EntityManager de um lado para o outro. Um EntityManager foi projetado para ser usado numa só operação (uma só thread, e muitas vezes apenas uma transação, embora também exista a opção EXTENDED para deixá-lo aberto para outra transação, que eu nunca usei). A configuração fica no META-INF/persistence.xml de um jar ou WEB-INF/classes/META-INF/persistence.xml de um war (achou estranho o WEB-INF/classes/META-INF? Eu também achei, mas está lá na especificação).

Interceptor: permite que você execute uma tarefa “ao redor” (@AroundInvoke) de chamadas de métodos (semelhante a um filtro). Essas chamadas têm que ser feitas a objetos obtidos com @Inject (CDI ou EJB), já que é o @Inject que cria o objeto proxy capaz de fazer a “mágica”. Afinal, chamadas de métodos em Java continuam sendo a mesma coisa de sempre.

JMS: permite enviar mensagens assíncronas de um sistema para outro. Não, não são e-mails (tem o JavaMail pra isso). Tem também os EJBs @MessageDriven para ajudar na tarefa.

Arquivo .jar (Java Archive): pacote compactado que contém classes Java. Existe também um tipo especial de jar para EJBs, mas no Java EE 6 os EJBs também podem ficar direto num arquivo war (na pasta WEB-INF/classes ou WEB-INF/lib)

Arquivo .war (Web Archive): pacote que contém JSPs e a pasta WEB-INF, que por sua vez contém o arquivo web.xml e as subpastas classes e lib.

Arquivo .ear (Enterprise Archive): pacote que pode conter pacotes war, jar  e mais algumas configurações.

Fazer deploy: pegar um pacote desses e colocar num servidor para ficar disponível pela web.

Context root: parte do endereço onde ficarão todas as coisas de um arquivo war. Por exemplo em http://example.com/my-web-app/index.jsp o context root é /my-web-app. O context-root pode ser o próprio nome do war ou pode ser configurado no application.xml do ear ou ainda pode ser configurado de uma forma específica ao servidor de aplicação (interface visual de administração, arquivo de configuração proprietário, etc.).

JNDI: um negócio para seu programa pegar coisas globais que o servidor disponibiliza através de caminhos especiais (ex.: “java:global/isso/aquilo” ou “java:comp/env/isso/aquilo”). Ficou bem menos necessário usar diretamente o JNDI quando surgiram as anotações @Inject e @Resource (ufa, ainda bem).