A última versão do Java Enterprise, que foi aprovado há poucos dias, apresenta uma capacidade para funções baseadas em profile. O primeiro publicado é o Web Profile, que se destina a desenvolvedores web, mas não é certo se ele será suficiente para impulsionar a adoção da plataforma em um campo com tantas ofertas atraentes.
Como o draft final do Web Profile menciona o princípio é atingir os desenvolvedores de aplicações web modernas, oferecendo razoavelmente uma stack completa, ao mesmo tempo que estabelece um limite para o footprint dos containers web, tanto em termos físicos quanto em termos conceituais:
Em termos de completude, o Web Profile oferece uma stack completa, com tecnologias que tratam da apresentação e gerenciamento de estado (JavaServer Faces, JavaServer Pages), funcionalidades do núcleo do container web (Servlet), lógica de negócio (Enterprise JavaBeans Lite), transações (Java Transaction API), persistência (Java Persistence API) e outras.
Em favor da simplicidade, ele deixa de fora muitas das APIs backend que são parte da plataforma Java EE. Ele também depende das novas funcionalidades de plugabilidade da especificação Servlet (ver o ponto 8.2 de tal documento) que permite aplicações a usarem bibliotecas que estendem o container servlet com o mínimo de overhead de configuração. Por exemplo, uma tecnologia padrão, como a API Java para Restful Web Services (JAX-RS), que é parte da plataforma completa Java EE, mas não do Web Profile, pode ser "plugado" em um container web sem necessidade de qualquer alteração no descritor web.xml da aplicação.
Vale ressaltar que não existem componentes opcionais e que as seguintes tecnologias devem ser implementadas completamente por uma solução para ser conforme ao Web Profile:
- Servlet 3.0
- JavaServer Pages (JSP) 2.2
- Expression Language (EL) 2.2
- Debugging Support for Other Languages (JSR-45) 1.0
- Standard Tag Library for JavaServer Pages (JSTL) 1.2
- JavaServer Faces (JSF) 2.0
- Common Annotations for Java Platform (JSR-250) 1.1
- Enterprise JavaBeans (EJB) 3.1 Lite
- Java Transaction API (JTA) 1.1
- Java Persistence API (JPA) 2.0
- Bean Validation 1.0
- Managed Beans 1.0
- Interceptors 1.1
- JSR-299 1.0
- JSR-330 1.0
Uma questão que tanto o Java EE quanto SE se deparam é a incapacidade da Sun para convencer a comunidade sobre o seu plano para "abrir" a plataforma. Isto tem sido ainda maior pela incerteza que tem seguido a sua aquisição pela Oracle. Preocupações como essas podem proibir organizações de fazerem um investimento estratégico na plataforma, como o registro de votação mostrou o qual aumentou durante o processo JCP. Na verdade, este foi o motivo da Apache Software Foundation votar "não" para o Java EE 6 Spec:
RedHat:
O líder da especificação EE6 confirmou que o TCK EE6 não conterá nenhuma "restrição de uso legal", como originalmente levantado pela Apache em observação adicionada a JSR (isto é, o licenciamento do TCK SE). Isso é uma coisa boa. Entretanto, na ausência de uma regra explícita no JSPA que proiba tais restrições de uso legal, nós continuaremos preocupados que um problema semelhante possa ressurgir a qualquer momento, por qualquer JSR. Conseqüentemente, no futuro, para qualquer JSR submetida (pela Sun Microsystems ou não), vamos esperar especificamente o líder da spec fornecer informações claras sobre esse aspecto e considerar a resposta na decisão do nosso voto.
Intel Corp.:
Até o momento da EE 6 JSRs vir à votação final, esperamos uma declaração de que a Licença do TCK EE 6 não restrinja o domínio de utilização, que não requeira nenhuma implementação além do que é exigido na própria especificação (sem "valor adicional" prevê a implementação somente da especificação) e não imponha qualquer outra licença que restrinja o uso de especificações JCP.
Apache Software Foundation:
É com pesar que a Apache vota "Não" para JSR-316, como afirmamos a líder da spec - Sun Microsystems - que não está cumprindo com a JSPA no que diz respeito a Licença do TCK do Java SE. Acreditamos que membros do JCP que não cumprem com o acordos e com o espírito de regras de governança não devem ser autorizados a conduzir JSRs. Esta não é uma declaração sobre o mérito técnico e qualidade do trabalho realizado pelo Expert Group até esta data, e se não fosse pelos desacordos não resolvidos pela Sun, a Apache provavelmente votariam "Sim".
Também não é muito claro no momento quando e por quais fornecedores será implementado o Web Profile. É possível que o VMWare, através do SpringSource, possa acabar por fazê-lo - eles certamente estão falado sobre isso no controlador de bugs do dm Server, mas eles também expressaram alguns comentários negativos sobre o Web Profile em público. Por exemplo, JürgenHöller co-fundador do framework Spring, foi negativo sobre o Web Profile durante a sua apresentação no QCon sobre Spring e Java EE 6:
Implementar este perfil não é muito atraente. Ainda estou para ver um vendedor com intenção de implementar somente este Profile e não o completo.
Da mesma forma Dimitris Andreadis, líder de projeto do JBoss AS manifestou a sua preocupação sobre a finalidade de ter "uma configuração web pré-definida":
Como vocês sabem, você pode alterar as configurações do JBoss AS para ter os serviços que você realmente precisa, o que sempre foi possível com o JBoss. Agora com uma configuração web pré-definida, isso parece, no momento, mais com uma decisão de marketing do que técnica. Remoção de capacidades e recursos é mais fácil do que adicionar novos. Por enquanto, temos focado em mover acima na cadeia, introduzindo o JBoss Enterprise SOA Platform, que acrescenta as funcionalidades JBoss ESB, JBoss jBPM e JBoss Rules em cima do JBoss EAP. Mas se há uma demanda real do mercado, ou se os Profiles Java EE 6 forem para frente, provavelmente vamos criar e suportar uma distribuição Web Platform também.
JBoss na realidade, anunciou que está trabalhando em um protótipo do Web Profile para o seu servidor de aplicação, embora a sua oferta atual, o JBoss Enterprise Plataforma Web "realça o Java EE Web Profile com as características enterprise".
Por outro lado, Gavin King criador do Hibernate, está otimista com a criação do Web Profile, pois considera algo positivo para a plataforma Java e que ajudará os desenvolvedores web os quais até o momento estavam preso entre escolher um container servlet faltando alguns recursos ou levar a sobrecarga da adoção da stack completa EE:
O Java EE Web Profile define um container "menor", com apenas as tecnologias que a maioria dos desenvolvedores realmente precisam: servlets, JPA, JTA, CDI, EJB Lite. Isso torna EE mais fácil de implementar, o que poderia resultar em um mercado mais vibrante, com mais implementações e ciclos de liberação menores. Isso definitivamente elimina a principal razão que muitos desenvolvedores dão para a não adoção do Java EE.
Até melhor, o CDI portable extension SPI torna muito mais fácil integrar as tecnologias no ambiente Java EE. E, já que algumas implementações CDI também rodam em um container servlet simples, como o Tomcat, o CDI também pode servir como uma base para a integração de tecnologias para esses ambientes.
Da mesma forma, Sacha Labourey antiga JBoss CTO, é muito otimista sobre o potencial do Web Profile:
É com grande prazer que eu soube que o JCP EC aprovou a votação final para o Weld e EE6!
Isso realmente termina o trabalho iniciado com EE5 e claramente posiciona o EE6 como o mais poderoso e fácil de usar Java Runtime Environment, claramente à frente do Spring e seus excessivos XML. Além disso, a definição de um Web Profile poderoso sem o incômodo de algumas das especificações mais legadas do EE (IIOP alguém?) dará ar fresco para muitas equipes de TI construir (e tentar manter) o seu próprio Tomcat sobre esteróides.
O que você acha sobre o Web Profile? Será que ele ajuda a tornar a plataforma Java uma solução atraente para o desenvolvimento web?