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: nigini@ffm.com.br 2Estudante do Curso de Bacharelado em Sistemas de Informação das Faculdades Integradas de Patos – FIP. Graduando. E-mail: emanuell@ffm.com.br 3Estudante do Curso de Bacharelado em Sistemas de Informação das Faculdades Integradas de Patos – FIP. Graduando. E-mail: edmilson@ffm.com.br

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