Diego Silva

Plataforma Java EE

A plataforma Java EE é especializada no desenvolvimento de aplicações multicamadas, baseadas em componentes distribuidos, executadas em um servidor de aplicações. Esse servidor (compatível com a especificação Java EE) oferece uma série de serviços de infra-estrutura aos componentes da aplicação (ex.  tolerância a falhas, segurança, transações, autenticação, distribuição, etc) que ajudam a garantir a robustez da aplicação sem que o desenvolvedor necessite escrever muitas linhas de código para isso.

Na Java EE 5, o foco foi basicamente na simplicidade de desenvolvimento de componentes, com o uso intensivo de anotações e Injeção de Dependência, a inclusão do JavaServer Faces(JSR 127) e a substituição do padrão Entity Beans pelo padrão Java Persistence API(JSR 220).

Vencida a barreira da complexidade de desenvolvimento, o objetivo na Java EE 6(JSR 316) passa a ser a busca pela maturidade da plataforma, por meio da evolução e fortalecimento de seus padrões, e o aumento na sua flexibilidade de uso e integração.

O maior desafio na especificação da Java EE 6 tem sido na definição de novos conceitos para a plataforma: profiles, extensibility e pruning. Esses conceitos permitem melhor adequação da plataforma às diferentes necessidades do mercado e mais facilidade de integração com novas tecnologias, frameworks e aplicações.

Dentre as melhorias esperadas estão a evolução de algumas APIs mais importantes, como JavaServer Faces 2.0(JSR 314), Java Persistence API 2.0(JSR 317), Enterprise Java-Beans 3.1(JSR 318) e Java Servlet 3.0(JSR 315), e a inclusão de novas APIs como WebBeans(que agora se chama Java Contexts and Dependency Injection JCDI)(JSR 299), Bean Validation(303) e JAX-RS(311).

Profile, Extensibility e Pruning

Desde as primeiras versões da Java EE, várias tecnologias, frameworks e aplicações tem sido criadas para suprir as imperfeições da plataforma ou aumentar sua facilidade de desenvolvimento. Para melhorar a capacidade de integração das aplicações Java EE com essas tecnologias, a versão 6 da plataforma tem dois grandes objetivos: a definição de profiles e o suporte à extensibilidade

Profiles

Um profile é caracterizado por um conjunto de tecnologias, que fazem parte ou não da especificação Java EE completa, necessários para suportar o desenvolvimento de aplicações de diferentes segmentos do mercado.

O uso de profiles na Java EE 6 é a resposta às críticas enfrentadas pela plataforma no que diz respeito ao tamanho da especificação Java EE. Nem todas as aplicações que desenvolvemos necessitam de utilizar o vasto conjunto de tecnologias que fazem parte do Java EE, o que causa um desespedício de suporte quando se utiliza um servidor Java EE completo. Daí a necessidade para a definição de profiles.

Requisitos comuns como serviço de nomes, recursos de injeção de dependência, regras de empacotamento, segurança, entre outros, devem ser compartilhados por todos os profiles para garantir a uniformidade dos produtos e das aplicações Java EE. Além disso, todas as dependências dos componentes suportados por cadas profile devem estar confidos no profile para garantir o seu funcionamento out-of-the-box.

Extensibility

O aspecto da extensibilidade na plataforma Java EE está relacionada com a necessidade de melhorar o suporte de outras tecnologias e frameworks dentro dos servidores de aplicação Java EE. Por exemplo, atualmente, para usar um framework em uma aplicação Java EE é necessário fazer alterações nos deployment descriptors,  criar filtros, ajustar bibliotecas, etc. A proposta de extensibilidade da Java EE 6 é facilitar esse processo criando mais pontos de extensão na plataforma.

Algumas das idéias discutidads para aumentar os pontos de extensão consideram o uso de anotações, injeção de dependência, interceptadores, APIs de serviço (SPIs – Service Providers Interfaces) e, até mesmo,  facilidade de implantar um simples jar dentro da aplicação(sem a necessidade de configurações complexas).

Profiles e extensibility são dois conceitos que estão diretamente relacionados, pois os profiles, além de oferecer o conjunto de tecnologias especificadas, também devem permitir a integração simplificada de outras tenologias, mesmo que estas não sejam padrão Java EE.

Pruning

Apesar de não estar como objetivo principal da especificação, pruning ou “poda” é um objetivo igualmente importante para a Java EE 6, que passa por um momento de amadurecimento.

Alguns dos padrões considerados essenciais em versões anteriores da Java EE agoar não são mais tão importantes. Exemplo disso são os Entity Beans, substituídos por JPA na Java EE 5.

A partir da Java EE 6, tecnologias consideradas de pouca relevância podem ser depreciadas para que, somente nas versões futuras da plataforma, se tornem opcionais. Assim, os vendedores de produtos poderão optar se querem ou não manter suporte a essas tecnologias na próxima versão  da plataforma. Essa é a definição de pruning adotada no JCP.

Na especificação Java EE 6, as tecnologias eleitas para o pruning são: EJB CMP, substituído pelo JPA, e JAX-RPC(JSR-101), substituído por JAX-WS(JSR-224), ambos na Java EE5. Portanto, a partir da próxima versão da Java EE(Java EE 7), os servidores escolhem se mantêm ou não suporte a essas tecnologias.

Novas versões das principais APIs

Com o objetivo de melhorar ainda mais a facilidade de uso e oferecer recursos mais poderosos  para as tecnologias padronizadas na Java EE 6, essa versão também está prevendo uma evolução da principais APIs.

JavaServer Faces 2.0

A versão 2.0 de JavaServer Faces, parte de Java EE 6, está sendo desenvolvida na JSR 314, liberada por Ed Burns e tem como principais novidades:

• Configuração do estágio do projeto/ Project Stage: Permite configurar qual o estágio de desenvolvimento: Production, Test, Development, UnitTest, System Test, Extension. Possibilitando que a aplicação seja executada de forma diferente, dependendo do estágio do projeto, por exemplo, se a aplicação está em produção pode ter um comportamento de log diferente da mesma aplicação em desenvolvimento.
• Criação do escopo View: baseado no escopo Page do JBoss Seam e no escopo KeepAlive do RichFaces, permite que um componente esteja associado a uma página, ou seja, estes componentes tem a “duração de uma página”. Quando o usuário sai daquela página o componente não estará mais acessível;
• Simplificação do desenvolvimento de componentes com conceito similar a TagFiles, baseado em Facelets;
• Definição de uma PDL(Page Description Language): baseada em Facelets, tornando-se a forma padrão para a criação de páginas em detrimento a JSPs.
  
• Melhor suporte a AJAX: trazendo conceitos de diversas bibliotecas do mercado, como DynaFaces, JMaki e Shale Remoting;
• Introdução do conceito de Resources(recursos): todos os artefatos (arquivos CSS, imagens e scripts) necessários para que o User Agent (geralmente um browser) possa renderizar o componente JSF são chamados recursos e devem ser disponibilizados em um diretório padrão.

Java Persistence API 2.0

A primeira versão da JPA foi  lançada em 2006 como parte da especificação do EJB 3.0(JSR-220) para facilitar o desenvolvimento da camada de persistência das aplicações. Muitas das idéias utilizadas na definição da JPA foram baseadas nas esperiências do mercado com frameworks de persistência. No entanto, a JPA 1.0 teve foco nos requisitos essenciais de persistência, não envolvendo aspectos mais podedoros de mapeamento e pesquisa.

Com o crescente interesse nessa API não apenas na plataforma Java EE, a JPA ganhou sua própria especificação (JSR-317) sob a liderança de Linda DeMichiel, que também foi líder das especificações EJB 2.1 e 3.0.

Essa JSR foi incluída na Java EE 6, sendo que o objetivo na versão 2.0 é a inclusão de recursos mais avançados de ORM e de busca.

Em relação aos recursos de ORM, algumas das melhorias trazidas pela JPA 2.0 são:

• Suporte ao mapemaneto de coleções de tipos básicos.
• Suporte a listas ordenadas.
• Melhor suporte a coleção de tipo Map
• Suporte ao relacionamento OneToMany unidirecional com mapeamento por chave estrangeira.
• Inclusão da API de Criteria.

Java Servlet 3.0

Uma das principais melhorias nessa API é a plugabilidade. O objetivo é permitir que frameworks como Struts, JSF, Spring, entre outros, possam ser mais facilmente configurados numa aplicação Web, sem a necessidade de configuração de deployment descriptor como é exigido atualmente. Para isso, o arquivo web.xml passa a ser modular. Cada framework pode definir seu próprio web.xml, usando uma tag específica para definição de fragmentos de aplicação Web, e incluí-lo no diretório META-INF de um arquivo jar. O container é responsável por reconhecer os fragmentos que estão nos jars vinculados à aplicação Web.

A facilidade de desenvolvimento é outro objetivo importante dessa especificação. O uso de recursos da Java SE 5, como anotações e generics, permitem tornar o web.xml opcional e reduzir erros de compilação e execução comumente gerados por implementações e configurações equivocadas. Para criar um servlet na Java EE 6, basta adicionar a anotação @Servlet(url-mapping=”url”) numa classe POJO. Os métodos podem ser anotados com @GET, @POST, entre outras, para identificar o tipo de requisição HTTP atendida. Essas facilidades também estão sendo extendidas para a criação de filtros e listeners.

Um modelo de Servlet assíncrono também está sendo incluído por meio do estilo de programação Comet.

Enterprise JavaBeans 3.1

Na Java EE 5, o componente EJB, que por muitos anos foi criticado por sua complexidade, teve alterações significativas para facilitar o seu uso. O uso de anotações permitiu evitar as interfaces complexas e reduzir as necessidades de configuração no deployment descriptor. Mas a busca pela simplicidade continua na Java EE 6 com o EJB 3.1(JSR 318), liberado por Kenneth Saks.

As interfaces de negócio passam a ser opcionais para acesso local: o loolup pode ocorrer diretamente pela classe do componente, sendo que todos os seus métodos públicos ficam disponíveis. Para oferecer esse suporte, basta não adicionar interfaces para o componente, ou, se uma interface remota(ou mesmo local) já estiver sendo oferecida, basta usar a anotação @LocalBean.

Alguns métodos do EJB podem ser marcados como a anotação @Asynchronous.

O Cliente do componente faz a requisição ao método assíncrono sem precisar esperar pelo retorno imediado, solicitando o resultado quando necessário. O cliente só é bloqueado para esperar um retorno do componente caso a resposta da requisição ainda não tenha sido totalmente concluída quando o cliente a solicita.

Novas APIs

É comum ouvirmos falar que Web Beans é o JBoss Seam, assim JPA é o Hibernate, ou como Facelets está sendo incorporado no JSF 2.0. Mas na verdade a história não é tão simples. Uma analogia válida équando criamos uma classe e depois “extraímos” a interface desta classe. A interface pode não conter todos os métodos e certamente não contém todos os detalhes de implementação da classe. A mesma coisa acontece com os frameworks que estão sendo “incluídos” na Java EE.

Web Beans

A JSR 299: Web Beans, foi criada para unificar os padrões de componentes EJB e JSF Managed Beans, oferecendo um modelo de programação mais simples para aplicações Web. Diversos traços do framework JBoss Seam estão presentes em Web Beans, mas não exatamente como uma réplica, pois diversas funcionalidades de JBoss Seam não serão implementadas. Além disso, houve uma redução  do acoplamento com JavaServer Faces, tornando o Web Beans útil para todos os tipos de aplicação, independente do uso de JSF ou EJB 3.0.

Algumas das principais caracteristicas desta API são:

• Permitir que qualquer componente possa ser acessado via Unified Expression Language(EL) em páginas JSF e JSP.
• Introduzir um novo escopo/contexto para as aplicações Web, chamado Conversation, que é maior do que o escopo de Request, e menor do que o escopo Session.
• Um Web Bean poderá ser injetado em qualquer componente Java EE.

O gerenciador de Web Beans oferece os seguintes serviços para aplicações com EJBs:

• Injeção de Web Beans em qualquer EJB, Servlet ou Listener ou outro Web Bean;
• Binding de interceptors e decorators;

Gerenciamento do ciclo de vida dos EJBs, criando e destruindo os componentes e disponibilizando as instâncias no contexto da aplicação.

Existem quatro formas diferentes de criarmos um Web Bean, são elas:

• Simple Web Bean: uma classe Java simples, concreta;
• Enterprise Web Bean: é um Web Bean implementado com um Enterprise Java Bean;
• Producer Methods: são fábricas de objetos que retornam objetos para serem injetados em outros componentes;
• JMS endpoint: é um Web Bean que representa uma fila ou tópico JMS.

Bean Validation

A JSR 303: A API de validação definida por essa JSR não foi projetada para atender a um tipo específico de aplicação(Web ou Desktop) ou ainda a uma camada específica da aplicação. Pelo contrário, foi criada para unificar a validação em todas as camadas e nos diversos tipos de aplicação Java, sendo vista como uma extensão ao modelo de componentes JavaBeans. Sua configuração pode ser feita por anotações ou XML.

JAX-RS 1.0

Para oferecer suporte ao novo formato de serviços web(REST), a JSR 311 definiu a API JAX-RS 1.0, baseada em anotações da Java SE 5, para viabilizar a disponibilização de RESTFul web services na plataforma Java SE e Java EE.

É isso ai, este artigo fica por aqui!

Abraços!