especificação de servidores web jee
TRANSCRIPT
EVOLUÇÃO DA PLATAFORMA DE DESENVOLVIMENTO CORPORATIVO JEE
Nigini Abilio Oliveira1 Emanuell Faustino Henrique de Lucena2 ;Edmilson Pereira Lima Neto3
Resumo - Atualmente, Java é uma das tecnologias mais difundidas no mundo do desenvolvimento de sistemas computacionais. Quando o sistema a ser criado é destinado à utilização corporativa, faz-se necessária a utilização de ferramentas e padrões específicos. A Java Entreprise Edition (JEE) é um conjunto de especificações da tecnologia Java para esta finalidade. Este artigo visa expor os principais pontos de evolução da nova versão da plataforma JEE, a JEE 5, dando ênfase ao processo de padronização realizado pela mesma e sua relação com as tecnologias e conceitos nos quais este processo se baseia.
Palavras-chave: desenvolvimento; corporativo; sistemas; informação.
Abstract - These days Java is one of the more spread computational systems development tools in the world. When the system is an enterprise one, it is required that specific design patterns and resources be used. The Java Enterprise Edition (JEE) is a set of Java technology specifications for that type of software. This paper looks at the new JEE's (the JEE 5) evolution, focusing at the standardization process, and the relations between its specifications and the already developed technologies and concepts.
Keywords: development; enterprise; systems; information.
1. Introdução
No primeiro semestre de 2006 foi finalizada pela Java Community Process (JCP)
(jcp.org) a especificação da denominada Java Enterprise Edition 5 (JEE 5) (JENDROCK,
2007), referenciada pelo código JSR 244 (JCP, 2006). Desde então, o círculo de
desenvolvedores de Sistemas de Informação transformou-se num campo de valiosas batalhas
ideológicas: de um lado, o JCP e seus defensores - normalmente vistos como o interesse do
mundo corporativo convencional; e do outro, os defensores dos vários frameworks
competidores, quase sempre de código aberto e vistos como defensores do free software (FSF,
1996).
A visão dos autores deste trabalho não se aterá a nenhum dos grupos por dois motivos:
em primeiro lugar, acredita-se que a batalha ideológica citada é importante para a evolução do
processo de desenvolvimento de sistemas computacionais, e em segundo lugar, porque os
ideais de cada grupo serão utilizados, muitas vezes sem distinção, para caracterizar a evolução
1Professor do Curso de Bacharelado em Sistemas de Informação das Faculdades Integradas de Patos – FIP. Doutorando em Engenharia Elétrica pela UFCG. E-mail: [email protected] 2Estudante do Curso de Bacharelado em Sistemas de Informação das Faculdades Integradas de Patos – FIP. Graduando. E-mail: [email protected] 3Estudante do Curso de Bacharelado em Sistemas de Informação das Faculdades Integradas de Patos – FIP. Graduando. E-mail: [email protected]
da plataforma JEE. Desta forma, o posicionamento aqui assumido é o de considerar os pontos
positivos de cada ideal defendido em busca de ferramentas de trabalho cada vez melhores.
Este artigo aceita como verdade que a padronização de soluções é sempre uma
vantagem para a comunidade de desenvolvedores. A única questão em aberto é como esse
processo se dá. Um dos melhores exemplos disso é a Internet. Para que todos mantenham-se
em contato via a grande rede de computadores, uma antepassada guerra de especificações de
protocolos foi travada. De um lado, o comitê hoje conhecido como ISO-OSI (ISO 8602)
definiu um modelo "de referência" para o funcionamento da rede, enquanto que os padrões
TCP/IP (RFC 1180) surgiam e dominavam a rede, tornando-se o padrão adotado "de fato".
A questão desse artigo não envolve a vitória ou derrota de um ou outro grupo, mas
cita-se o caso acima apenas para denominar os grupos e suas ideologias: o JCP é o comitê que
buscaria o padrão "de referência", enquanto que os mais variados projetos de código aberto
estariam criando o padrão "de fato". É nesta denominação que surgem as primeiras diferenças
do exemplo anterior. A primeira é que o JCP funciona de forma aberta, significando que os
parceiros são livres para se associarem ao processo de criação das especificações. Uma outra
peculiaridade da padronização que envolve o JEE, é o fato de que há inúmeros "projetos
concorrentes", e espera-se deixar claro neste trabalho que, quando os mesmos se destacam na
sua área de atuação, logo são fonte de inspiração para as especificações do JCP.
Assim, o principal objetivo deste artigo é estabelecer uma visão da tecnologia definida
pela versão 5 da Java Enterprise Edition como um captador das grandes idéias arquiteturais
existentes na comunidade de desenvolvedores de sistemas computacionais. Para isso, a
plataforma de desenvolvimento Java/JEE será explicitada de forma geral na seção 2, seguida
de uma análise da criação de algumas das suas especificações mais populares na seção 3. Na
conclusão, serão levantados os principais pontos em aberto a serem avaliados como
complementação deste trabalho, dado que os autores o vêem muito mais como uma
fundamentação teórica para a área do desenvolvimento de sistemas corporativos em Java.
2. A Plataforma JEE
A Java Enterprise Edition (JEE 5) é um conjunto de especificações construídas sobre
um cerne tecnológico denominado Java Standard Edition (JSE). Esta "distribuição padrão" é
composta por três partes: uma linguagem de programação Orientada a Objetos, um conjunto
de APIs (bibliotecas) construído para esta linguagem, e um conjunto de aplicativos, dentre os
quais destaca-se a Java Virtual Machine (JVM), o qual é uma máquina virtual responsável por
executar o código criado para esta tecnologia. Dentre outras vantagens, a tecnologia Java visa
uma portabilidade de código, que era impossível antes do advento das máquinas virtuais.
Além de possibilitar a execução de sistemas em qualquer plataforma suportada, a JVM
também atua como gerenciador de alto nível desse código, provendo serviços tais como
gerenciamento de memória, segurança e perfilamento do sistema.
Por ser desenvolvida sobre a JSE, a plataforma JEE herda as vantagens acima citadas.
Seu principal objetivo é expandir os serviços da plataforma Java para o desenvolvimento de
sistemas baseados no modelo cliente-servidor. Visando facilitar o desenvolvimento da lógica
e as várias formas da acesso a esta, as solução JEE são voltadas a “componentes” de software
que podem ser construídos separadamente, montados e executados em um servidor capaz de
gerenciá-los, provendo uma maior escalabilidade e acessibilidade. Por este motivo, uma das
principais adições providas pela Java Enterprise Edition é o servidor de aplicação, ou
Container.
2.1 Arquitetura da Plataforma
A arquitetura em camadas é hoje um padrão comum para todo sistema computacional
complexo, pois o isolamento das funcionalidade em módulos e sua associação visando alto
grau de desacoplamento, são duas das principais características de sistemas de qualidade. A
Figura 1 mostra a arquitetura da plataforma JEE 5 dividida em 3 partes lógicas: camada do
cliente, camada lógica e camada de persistência.
Figura 1: Arquitetura simplificada da Plataforma JEE
Apesar da Figura 1 trazer uma versão simplificada da arquitetura, priorizando sistemas
de informação mais comuns, esta auxiliará o posicionamento correto das outras várias
especificações da JSR 244 de acordo com sua finalidade, a saber, JSF e JPA, explicadas em
detalhes em seções subseqüentes.
Na camada cliente estão localizados todos os aplicativos capazes de submeter
requisições à lógica de negócio do sistema. Estes aplicativos podem ser simples interfaces
gráficas com usuário, formulários web, sistemas legados ou outros sistemas de informação; e
ainda utilizando procolos de comunicação proprietários, HTTP, RMI, etc. Esta camada reúne
as várias formas de requisições aos serviços providos pela lógica. As especificações JEE
relacionadas a esta camada são, na verdade, padronizações para a comunicação entre camadas
como por exemplo, a implementação do padrão Model-View-Controller (MVC)
(REENSKAUG, 2003).
É no servidor, ou camada lógica, que está o foco do JEE. É nesta camada que estão
centralizadas tarefas como recepção, tratamento, processamento e resposta a requisições dos
clientes. Como pode ser visto na Figura 1 anterior, esta unidade lógica ainda pode ser divida
em outras duas camada:
Na camada Web, estão serviços direcionados a interface do sistema com os clientes.
Pela nomenclatura, pode-se imaginar que esta comunicação é sempre pelos padrões
web, como o protocolo HTTP, mas esta não é a realidade, pois qualquer outro serviço
de interfaceamento pode ser adicionado a esta camada de interface.
Na camada de negócio estão os componentes lógicos relacionados à execução das
regras de negócio mais básicas. Ela abrange os Objetos Java Simples (POJOs),
responsáveis por armazenar informações, e as entidades gestoras deste conhecimento,
implementadoras dos algoritmos de processamento dos dados.
Da mesma forma que a camada cliente, a camada de persistência (ou dados) é uma
abstração de encapsulamento das várias fontes de dados necessárias ao funcionamento do
sistema, sejam arquivos, sistemas gerenciadores de banco de dados (SGBD), sistemas
legados, redes P2P ou sistemas de arquivo distribuídos. O objetivo das especificações
disponíveis neste nível da arquitetura visam a homogeneização do acesso aos dados, visando a
implementação de padrões de projeto como o Data Acess Object (DAO) (DEEPAK, 2001) ou
DataMapper (FOWLER, 2002).
2.2 As Especificações da JEE 5
Padrões não devem ser revolucionários, mas sim evolucionistas. (Autor desconhecido)
A especificação JSR 244 é um arcabouço que reúne cerca de duas dezenas de
especificações divididas em quatro pacotes. Os pacotes e algumas de suas JSRs são citados no
Quadro 1 a seguir:
3. Evolução da Plataforma
O desenvolvimento da versão 5 do JEE tem como principal objetivo alcançar melhor
produtividade e maior velocidade de implementação. Para cumprir esta meta, várias diretrizes
Web Layer
Servlets Componente web capaz de responder a requisições ao servidor, tendo como mais comum representando a versão para protocolo HTTP.
JSR 245 Java Server Pages (JSP) Componente web para a construção de páginas dinâmicas baseada em
tags facilmente injetadas em páginas HTML.
JSR 252 Java Server Faces (JSF)
Framework web que implementa o padrão MVC baseado na configuração de um controlador para o fluxo de informações entre as camadas de visão e web.
Business Layer
JSR 919 JavaMail Facilitador para a utilização dos protocolos relacionados ao sistema de
e-mail. JSR 914 Java Message Service (JMS) Framework que implementa a arquitetura de sistemas distribuídos com
comunicação assíncrona, provendo um servidor de filas de mensagens. JSR 220 Enterprise Java Beans (EJB) Framework que provê uma infraestrutra de desenvolvimento baseado
em componentes de software desacoplados e reusáveis. JSR 220 Java Persistence API (JPA) API de alto nível para a persistência de informações, solucionando o
problema da conversão objeto-relacional. Web-Services
JSR 224
Java API for XML-Based Web-services (JAX-WS) Criação de Web-services baseados em comunicação XML.
JSR 101
Java API for XML-Based RPC (JAX-RPC) Criação de serviços baseados em chamadas remotas a métodos.
Mangement and Security
JSRs 88, 77, 115
Deploy, Management e Authorization
Especificações relacionadas a tarefa de gerenciamento dos aplicativos dentro do container e acesso a serviços do aplicativo por usuários do mesmo.
Quadro 1. Algumas das principais especificações da JEE 5
foram seguidas, assim como alguns padrões arquiteturais e tecnológicos foram
implementados. Esta seção visa esclarecer as forças que moldaram as mudanças de três das
especificações mais populares da JEE 5 e fazer observações sobre a aceitação das mesmas
pela comunidade de desenvolvedores.
A escolha das JSRs para a avaliação proposta neste trabalho se deu com base em dois
pontos: sua popularidade no meio dos desenvolvedores de sistemas e as características que
guiaram seu desenvolvimento. Quanto à popularidade, a escolha se baseou na enquete
disponível em (JAVA.NET, 2006), respondida por centenas de desenvolvedores usuários da
plataforma JEE sobre as especificações da versão 5 que mais lhes chamaram a atenção. Do
total, 35.4% votaram nas inovações do EJB 3, outros 17.4% na JPA e ainda 15% na JSF. As
duas primeiras são parte integrante da JSR 220 e serão comentadas nas seções 3.3 e 3.2,
enquanto a última é padronizada na JSR 252 comentada na seção 3.1.
A JSR 252 pertence ao grupo de especificações da "camada web", enquanto a JSR 220
padroniza dois importantes frameworks da "camada de negócio". Com relação às
características de desenvolvimento, a escolha destas JSRs foi fortalecida pela relação
existente entre as mesmas e melhorias relacionadas à: produtividade, através da utilização
eficiente de configurações; injeção de dependências, que é um padrão tecnológico envolvendo
conceitos como POJO e Spring; e a implementação de padrões de projeto, como o famoso
MVC. Cada uma destas melhorias será abordada nas sub-seções a seguir.
3.1 JSF
A Java Server Faces (JSF) é a mais nova integrante do conjunto de padrões para a
camada web da plataforma JEE. Para entender o seu desenvolvimento faz-se necessário um
rápido retrospecto sobre a evolução de soluções para esta camada. A primeira solução é o
Servlet, a estrutura básica para o desenvolvimento de aplicações web em Java. Através dele o
desenvolvedor recebe uma requisição, geralmente HTTP, realiza algum processamento e
produz um retorno para o cliente.
A resposta de uma requisição HTTP é escrita em HTML, o que exige a geração de
retornos relativamente longos dado que a resposta buscada na camada lógica deve ser
encrustada em um envelope HTML. Além disso, este método em épocas mais remotas, não
permitia grande flexibilidade e manutenibilidade. Qualquer alteração na apresentação no
design das interfaces com o usuário exigiam reescrita de código JAVA, o que normalmente
não está nas responsabilidade de um profissional de design. Buscando sanar esse problema
surgiram as Java Server Pages (JSP), uma forma de implementar a camada web criando um
documento útil para ambos os mundos, o do desenvolvedor da lógica e o do designer,
facilitando a manutenção e o reaproveitamento.
Como o simples fato de utilização destas tecnologias não implica em sistemas de
qualidade, neste caso um bom nível de desacoplamento entre a camada de visão e a de lógica,
torna-se importante a utilização/implementação de padrões de projeto. Por volta de 1978, o
padrão arquitetural Model-View-Controller foi criado e usado em aplicativos desenvolvidos
em liguagens de programação Orientadas a Objetos. O MVC surgiu exatamente com o
objetivo de separar a View (User Interface) do Model (Business Logic), o que pôde ser
aplicado também em sistemas web desenvolvidos com Servlets e JSPs.
Esse padrão baseia-se em três definições: i) o Model é a lógica da aplicação em
questão e livre de apresentação; ii) a View implementa a interação entre o usuário e a
aplicação não exigindo outro conhecimento do Model senão a definição de seus serviços; iii)
um Controller deve existir para intermediar a comunicação entre as definições anteriores,
como por exemplo, receber requisições da visão, gerenciar sincronização de estados entre as
duas camadas, entre outras. Para atacar a problemática do acoplamento entre as camadas de
apresentação e do modelo em sistemas web, surgiram implementações deste padrão através de
frameworks, sendo o caso de tecnologias Java atacado inicialmente pelo Struts
(struts.apache.org).
Por ser a primeira iniciativa de unificar em um framework algumas das boas práticas
padronizadas ou "ad hoc" já utilizadas por vários desenvolvedores, o Struts tornou-se uma
ferramenta muito utilizada em todo o mundo, sendo então doada à Fundação Apache
(apache.org) para uma manutenção mais cuidadosa. Hoje em sua segunda versão, o Struts
continua buscando a adição de formas de desenvolvimento difundidas dentro da comunidade.
Mas como o Struts é uma ferramenta mantida por terceiros, a JCP decidiu criar uma
especificação, com o nome de Java Server Faces (JSF), para padronizar a utilização de
serviços similares aos já providos pelo Struts. Alguns objetivos do JSF são: criar
componentes de interface com usuário (UI) de alta qualidade e que possam se conectar ao
comportamento de qualquer aplicação; possibilitar a fácil integração de ferramentas Rapid
Application Development (RAD) para aumentar a produtividade; forçar a utilização do padrão
MVC no projeto de sistemas web promovendo maior qualidade inerente; facilitar a gerência
de fluxos entre os componentes de visão, entre outros.
Dentre as três especificações aqui discutidas, esta é a menos complexa e passível de
poucos questionamentos, dado que a visão da mesma é de padronização de tendências já
adotadas pela comunidade de desenvolvedores. Acredita-se que o processo iniciado pela JSR
252 busca reunir as boas soluções que envolvem a camada de visão (e sua integração com o
modelo) o que não a impede, ou mesmo a obriga, de aproximar-se de soluções já existentes. A
competição existente entre Struts e JSF é no mínimo benéfica para a construção de
frameworks mais completos.
3.2 JPA
Como já foi dito no início deste trabalho a tecnologia Java é baseada em conceitos de
Orientação a Objetos (OO). Pela sua clareza e expressividade na modelagem da relação entre
as entidades do domínio dos Sistemas de Informação, este é o paradigma de linguagem de
programação mais utilizado neste contexto. No entanto, por questões que não convêm discutir
neste trabalho, o mundo dos Sistemas Gerenciadores de Banco de Dados (SGBD) é dominado
pelo paradigma relacional de modelagem de dados. Como quase todos os SIs são compostos
por uma lógica de negócio escrita em modelo OO, e os dados desta são armazenados em um
banco de dados (BD), surge a necessidade de construir soluções para realizar o mapeamento
objeto-relacional (O-R).
A primeira e mais simples dentre as soluções é a API JDBC (SUN, 2002). Ela é
composta por um conjunto de interfaces de programação que definem, entre outras coisas:
como um sistema desenvolvido em linguagem Java realiza uma conexão com o banco de
dados, como comandos SQL podem ser executados, e como os resultados de tais comandos
podem ser acessados. A responsabilidade de implementar estas funcionalidades pode ser
delegada a terceiros, como os próprios desenvolvedor de SGBD. As soluções finais para o
JDBC são compostas pelos denominados drivers, capazes de conectar o sistema Java a um
SGBD específico.
A JDBC é a solução padrão para todo mapeamento objeto-relacional, seja através de
sua utilização direta, seja através da utilização de camadas de mais alto nível. Sua principal
vantagem é a simplicidade arquitetural e facilidade de utilização. Mas por lidar com
linguagem SQL, que é uma especificação de mais baixo nível esta solução pode tornar-se
improdutiva ao ser utilizada em sistemas de grande porte.
Para solucionar a questão da produtividade do uso direto do JDBC e ainda tornar o
mapeamento O-R transparente ao desenvolvedor da lógica de negócio, surgiram frameworks
tais como o Hibernate (struts.apache.org) e o Toplink (ORACLE, 2007). Em termos gerais,
estas soluções fazem uso de um sistema paralelo de configuração do mapeamento desejado.
Um aplicativo interno ao framework fica responsável por traduzir, automaticamente,
operações de criação, edição, busca e remoção de objetos dentro do banco de dados.
O Hibernate é um framework que se tornou o padrão de fato neste contexto.
Percebendo esta realidade, a versão 5 da plataforma JEE criou a especificação denominada
Java Persistence API (JPA), a qual é parte integrante da JSR 220. Este talvez seja o
componente mais acessível do JEE 5, dado que sua implementação pode ser utilizada
independente do servidor de aplicações permitindo inclusive o seu uso por aplicativos JSE.
A JPA é um padrão com fortes indícios de aceitação pelo mercado dada a sua
consideração de conceitos tecnológicos já existentes e a sua busca por uma maior
produtividade. Um ponto a somar na sua aceitação é a pronta implementação das interfaces
definidas pela JPA pela tecnologia Hibernate (na sua versão 3). As principais críticas
envolvem não os conceitos existentes na JSR, mas sim a falta de alguns recursos já existentes
nas soluções não padronizadas.
Um dos exemplos é a facilidade de utilizar objetos como parâmetro em operações com
o banco de dados, e.g. uma busca (select) onde os filtros são objetos do tipo do retorno. Mas
dado que o processo de padronização é inerentemente evolutivo, os autores deste trabalho
consideram a implementação (ou exclusão consciente) de tais recursos uma questão de tempo
e de estudo mais cuidadoso. Esta espera permite uma maturação de conceitos mais recentes e
diminui as chances de absorção de recursos tecnicamente desvantajosos quando aplicados e
avaliados em contextos mais amplos.
No campo da produtividade e simplicidade a JPA possibilita realizar configurações via
Annotations (JSR 175), uma linguagem para a escrita de meta-dados da tecnologia Java
passível de checagem em tempo de compilação. Este formato para a definição do
mapeamento OR não substitui a utilização do XML, dado que a inserção de "anotações" no
código fonte da aplicação pode prejudicar a legibilidade do mesmo. Este trabalho não aborda
profundamente esta questão, mas julga que a avaliação do uso das várias formas de escrita de
meta-dados em sistemas Java é uma importante linha de pesquisa a ser atacada.
Por fim, a realidade de que o processo de padronização possui um caráter
evolucionista e não revolucionário fica clara nesta especificação. Há de se considerar que a
migração de tecnologias em sistemas reais deve passar por forte análise, mesmo sendo uma
questão de usar tecnologias padronizadas ou não. Mas como deixa claro Christian Bauer -
desenvolvedor do Hibernate – em fórum de discussão on-line mantido pela Hibernate.org, é
muito importante manter seu sistema compatível com APIs padronizadas, mesmo que parte
das funcionalidades utilizadas ainda não estejam especificadas. Isso porque os padrões de
mercado tendem a possuir um melhor suporte de ferramentas e opções de escolha entre
soluções concorrentes; e, dada uma maior quantidade de usuários, tende a aumentar a
qualidade e confiabilidade das opções.
3.3 EJB
O Enterprise JavaBeans (EJB) é uma arquitetura para o desenvolvimento e a
implantação de aplicativos baseados em componentes. Sistemas construídos sobre esta
plataforma devem levar em consideração os seguintes conceitos:
o componente de software desenvolvido para resolver problemas da lógica de negócio;
a montagem do sistema sob uma infraestrutura capaz de gerenciar os componentes;
a configuração do container, que é capaz de prover serviços adicionais como
segurança, gerência de ciclo de vida de objetos, persistência, etc.
A idéia de infraestruturas baseadas em componentes desacoplados, porém facilmente
encaixáveis, é uma das questões arquiteturais abertas por muito tempo. Durante anos, várias
ferramentas buscaram prover esta facilidade e a especificação EJB, já em sua terceira versão,
é mais uma delas. A importância da JSR 220 no contexto histórico é a busca "das pazes" com
os usuários do modelo de sistemas baseados em componentes. Em suas duas primeiras
versões o EJB tornou-se pouco popular por conta de sua arquitetura complexa e altamente
dependente do container, significando que componentes criados para a plataforma
dificilmente seriam reusáveis ou mesmo testáveis fora da mesma.
3.3.1 Evolução por Concorrência - O Framework Spring
Em 2002 foi disponibilizado o framework Spring (JOHNSON; 2002, 2007),
desenvolvido por um especialista em EJB 2, bastante descontente com o encaminhamento da
especificação. O Spring é um framework que constrói uma infraestrutura para a gerência de
componentes de software baseada em vários padrões tecnológicos "de fato". Baseado em um
core/container, provê vários outros módulos que, quando comparados às especificações JEE,
é visível a concorrência direta. Sua aceitação em detrimento da J2EE (versão anterior da
plataforma) é uma importante questão a ser analisada.
Tendências tecnológicas que vinham ganhando o mercado desde o início da década
tornavam-se padrão. A injeção de dependência, programação declarativa, desenvolvimento
baseado em POJOs, Programação Orientada a Aspectos (POA), e inversão de controle foram
alguns dos principais conceitos utilizados. Talvez por ser um framework idealizado por um
único especialista na área, o Spring foi capaz de absorver todas estas tendências rapidamente
tornando-se um framework conceituado como simples, modular, testável, de infraestrutura
leve e "não-intrusivo".
3.3.2 Um EJB Completamente Novo
"O propósito do EJB 3 é melhorar a arquitetura do modelo reduzindo sua complexidade do ponto de vista do programador."
(JSR-220)
Como a EJB 3.0 é uma especificação, que envolve o trabalho de um comitê, foi
necessário um tempo maior desde o processo de idealização, formação de comitê, finalização
e implementação do padrão. Num processo que leva cerca de 3 anos, esta nova versão do
modelo de sistemas componentizados buscou praticamente os mesmos avanços já atingidos
pelo Spring anteriormente, com a vantagem de ser um padrão “de referência”. A importância
de ser um padrão de comitê é uma questão que pode ser respondida apenas com o tempo de
maturação e índices de aceitadação do mercado.
Uma realidade importante é o fato de que o Spring ganhou adeptos baseado em um
destaque real de inovação tecnológica e arquitetural, vantagem esta que, se não já recuperada
pela JEE 5, já não as mantêm em patamares diferentes. A nova versão do EJB já provê
especificações desacopláveis do container, possui arquitetura simplificada e,
comparativamente, possui alto grau de produtividade baseada nas facilidade de configuração.
As principais mudanças relativas à simplificação da arquitetura EJB seguem abaixo:
nenhum requisito de herança de classe ou interface é exigido, tornando o modelo EJB
menos intrusivo;
contrato com o container reduzido à anotação/configuração de métodos;
possibilidade de uso de anotações para reduzir a necessidade de XML;
persistência de objetos baseada no mapeamento O-R da JPA.
Trabalhos futuros serão realizados visando uma comparação mais minuciosa entre as
duas opções de modelo de software, baseado em componentes, para a tecnologia Java. Mas a
impressão obtida ao acompanhar várias comunidades de desenvolvedores é a de que a
especificação EJB 3.0 resolveu os seus problemas arquiteturais e pode agora continuar com
sua evolução competitiva (a versão 3.1 terá a JSR finalizada ainda deste ano).
4. Considerações Finais
Este artigo buscou apresentar um panorama da plataforma de desenvolvimento Java
Enterprise Edition, com foco nas tendências de mercado que guiaram a evolução para a
última versão da mesma. Para isso mostrou-se alguns detalhes das três especificações mais
populares da plataforma: JSF, JPA e EJB. Enquanto todas seguem o princípio de aumentar a
produtividade da plataforma JEE, as duas primeiras buscam a facilitação do uso de padrões de
projeto - como MVC. Já a terceira sofreu influências diversas dado um histórico de baixa
aceitação da versão anterior.
Para trabalhos futuros os autores e outros colaboradores pretendem executar pesquisas
que quantifiquem a aceitação das mudanças aqui demonstradas. Um dos pontos já em estudo é
a avaliação da aplicabilidade das Annotations em detrimento a outras formas de configuração
e meta-dados. A análise dos reais ganhos de produtividade da JSF com relação ao Struts
também está início de estudo, assim como, uma avaliação entre os containers providos pelo
EJB e pelo Spring.
5. Referências
DEEPAK, Alur; CRUPI, Jonh; MALKS, Dan. Core J2EE Patterns - Data Access Object. In.: ______, Core J2EE Patterns: Best Practices and Design Strategies. 1st edition. New Jersey: Prentice Hall / Sun Microsystems Press, 2001. Disponível:<http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html> Acesso em: 01 jun. 2008.
FOWLER, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, Nov. 2002. p. 129-142.
JENDROCK, Eric et al. The Java EE 5 Tutorial, Santa Clara, EUA, Sept. 2007. Disponível: <http://java.sun.com/javaee/5/docs/tutorial/doc/>. Acesso em: 02 jun. 2008.
FSF - Free Software Foundation, INC. About Free Software, 1996. Disponível: <http://www.gnu.org/philosophy/about-free-software.html> Acesso em: 01 jun. 2008.
JCP – Java Community Process. JSR 244: JavaTM Platform, Enterprise Edition 5 (Java EE 5) Specification, May. 2006. Disponível: <http://jcp.org/en/jsr/detail?id=244> Acesso em: 01 jun. 2008.
JAVA.NET. Which Java EE 5 feature appeals to you most?, 2006. Disponível: <http://today.java.net/pub/pq/93> Acesso em: 01 jun. 2008.
JOHNSON, Rod. Expert One-on-One J2EE Design and Development. Birmingham, UK: Wrox Press Ltd, 2002.
JOHNSON, Rod. Introduction to the Spring Framework. Oct, 2007. Disponível: <http://www.theserverside.com/tt/articles/article.tss?l=IntrotoSpring25> Acesso em: 03 jun. 2008.
ORACLE. TopLink, 2007. Disponível: www.oracle.com/technology/products/ias/toplink/ Acesso em: 01 jun. 2008.
REENSKAUG, Trygve. The Model-View-Controller (MVC) Its Past and Present. University of Oslo, Aug, 2003. Disponível:. <http://heim.ifi.uio.no/~trygver/themes/mvc/mvc > Acesso em: 01 jun. 2008
SUN - Sun Microsystems, INC. JDBC Documentation. 2002. Disponível: <http://java.sun.com/javase/6/docs/technotes/guides/jdbc> Acesso em: 01 jun. 2008