Você está na página 1de 13

EVOLUO 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 utilizao corporativa, faz-se necessria a utilizao de ferramentas e padres especficos. A Java Entreprise Edition (JEE) um conjunto de especificaes da tecnologia Java para esta finalidade. Este artigo visa expor os principais pontos de evoluo da nova verso da plataforma JEE, a JEE 5, dando nfase ao processo de padronizao realizado pela mesma e sua relao com as tecnologias e conceitos nos quais este processo se baseia. Palavras-chave: desenvolvimento; corporativo; sistemas; informao. 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. Introduo No primeiro semestre de 2006 foi finalizada pela Java Community Process (JCP) (jcp.org) a especificao da denominada Java Enterprise Edition 5 (JEE 5) (JENDROCK, 2007), referenciada pelo cdigo JSR 244 (JCP, 2006). Desde ento, o crculo de desenvolvedores de Sistemas de Informao transformou-se num campo de valiosas batalhas ideolgicas: de um lado, o JCP e seus defensores - normalmente vistos como o interesse do mundo corporativo convencional; e do outro, os defensores dos vrios frameworks competidores, quase sempre de cdigo aberto e vistos como defensores do free software (FSF, 1996). A viso dos autores deste trabalho no se ater a nenhum dos grupos por dois motivos: em primeiro lugar, acredita-se que a batalha ideolgica citada importante para a evoluo do processo de desenvolvimento de sistemas computacionais, e em segundo lugar, porque os ideais de cada grupo sero utilizados, muitas vezes sem distino, para caracterizar a evoluo

Professor do Curso de Bacharelado em Sistemas de Informao das Faculdades Integradas de Patos FIP. Doutorando em Engenharia Eltrica pela UFCG. E-mail: nigini@ffm.com.br 2 Estudante do Curso de Bacharelado em Sistemas de Informao das Faculdades Integradas de Patos FIP. Graduando. E-mail: emanuell@ffm.com.br 3 Estudante do Curso de Bacharelado em Sistemas de Informao 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 padronizao de solues sempre uma vantagem para a comunidade de desenvolvedores. A nica questo 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 especificaes de protocolos foi travada. De um lado, o comit hoje conhecido como ISO-OSI (ISO 8602) definiu um modelo "de referncia" para o funcionamento da rede, enquanto que os padres TCP/IP (RFC 1180) surgiam e dominavam a rede, tornando-se o padro adotado "de fato". A questo desse artigo no envolve a vitria 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 padro "de referncia", enquanto que os mais variados projetos de cdigo aberto estariam criando o padro "de fato". nesta denominao que surgem as primeiras diferenas do exemplo anterior. A primeira que o JCP funciona de forma aberta, significando que os parceiros so livres para se associarem ao processo de criao das especificaes. Uma outra peculiaridade da padronizao que envolve o JEE, o fato de que h inmeros "projetos concorrentes", e espera-se deixar claro neste trabalho que, quando os mesmos se destacam na sua rea de atuao, logo so fonte de inspirao para as especificaes do JCP. Assim, o principal objetivo deste artigo estabelecer uma viso da tecnologia definida pela verso 5 da Java Enterprise Edition como um captador das grandes idias arquiteturais existentes na comunidade de desenvolvedores de sistemas computacionais. Para isso, a plataforma de desenvolvimento Java/JEE ser explicitada de forma geral na seo 2, seguida de uma anlise da criao de algumas das suas especificaes mais populares na seo 3. Na concluso, sero levantados os principais pontos em aberto a serem avaliados como complementao deste trabalho, dado que os autores o vem muito mais como uma fundamentao terica para a rea do desenvolvimento de sistemas corporativos em Java. 2. A Plataforma JEE A Java Enterprise Edition (JEE 5) um conjunto de especificaes construdas sobre um cerne tecnolgico denominado Java Standard Edition (JSE). Esta "distribuio padro" composta por trs partes: uma linguagem de programao Orientada a Objetos, um conjunto de APIs (bibliotecas) construdo para esta linguagem, e um conjunto de aplicativos, dentre os quais destaca-se a Java Virtual Machine (JVM), o qual uma mquina virtual responsvel por executar o cdigo criado para esta tecnologia. Dentre outras vantagens, a tecnologia Java visa

uma portabilidade de cdigo, que era impossvel antes do advento das mquinas virtuais. Alm de possibilitar a execuo de sistemas em qualquer plataforma suportada, a JVM tambm atua como gerenciador de alto nvel desse cdigo, provendo servios tais como gerenciamento de memria, segurana e perfilamento do sistema. Por ser desenvolvida sobre a JSE, a plataforma JEE herda as vantagens acima citadas. Seu principal objetivo expandir os servios da plataforma Java para o desenvolvimento de sistemas baseados no modelo cliente-servidor. Visando facilitar o desenvolvimento da lgica e as vrias formas da acesso a esta, as soluo JEE so voltadas a componentes de software que podem ser construdos separadamente, montados e executados em um servidor capaz de gerenci-los, provendo uma maior escalabilidade e acessibilidade. Por este motivo, uma das principais adies providas pela Java Enterprise Edition o servidor de aplicao, ou Container. 2.1 Arquitetura da Plataforma A arquitetura em camadas hoje um padro comum para todo sistema computacional complexo, pois o isolamento das funcionalidade em mdulos e sua associao visando alto grau de desacoplamento, so duas das principais caractersticas de sistemas de qualidade. A Figura 1 mostra a arquitetura da plataforma JEE 5 dividida em 3 partes lgicas: camada do cliente, camada lgica e camada de persistncia.

Figura 1: Arquitetura simplificada da Plataforma JEE

Apesar da Figura 1 trazer uma verso simplificada da arquitetura, priorizando sistemas de informao mais comuns, esta auxiliar o posicionamento correto das outras vrias especificaes da JSR 244 de acordo com sua finalidade, a saber, JSF e JPA, explicadas em detalhes em sees subseqentes. Na camada cliente esto localizados todos os aplicativos capazes de submeter requisies lgica de negcio do sistema. Estes aplicativos podem ser simples interfaces grficas com usurio, formulrios web, sistemas legados ou outros sistemas de informao; e ainda utilizando procolos de comunicao proprietrios, HTTP, RMI, etc. Esta camada rene as vrias formas de requisies aos servios providos pela lgica. As especificaes JEE relacionadas a esta camada so, na verdade, padronizaes para a comunicao entre camadas como por exemplo, a implementao do padro Model-View-Controller (MVC)

(REENSKAUG, 2003). no servidor, ou camada lgica, que est o foco do JEE. nesta camada que esto centralizadas tarefas como recepo, tratamento, processamento e resposta a requisies dos clientes. Como pode ser visto na Figura 1 anterior, esta unidade lgica ainda pode ser divida em outras duas camada:

Na camada Web , esto servios direcionados a interface do sistema com os clientes. Pela nomenclatura, pode-se imaginar que esta comunicao sempre pelos padres web , como o protocolo HTTP, mas esta no a realidade, pois qualquer outro servio de interfaceamento pode ser adicionado a esta camada de interface.

Na camada de negcio esto os componentes lgicos relacionados execuo das regras de negcio mais bsicas. Ela abrange os Objetos Java Simples (POJOs), responsveis por armazenar informaes, e as entidades gestoras deste conhecimento, implementadoras dos algoritmos de processamento dos dados. Da mesma forma que a camada cliente, a camada de persistncia (ou dados) uma

abstrao de encapsulamento das vrias fontes de dados necessrias ao funcionamento do sistema, sejam arquivos, sistemas gerenciadores de banco de dados (SGBD), sistemas legados, redes P2P ou sistemas de arquivo distribudos. O objetivo das especificaes disponveis neste nvel da arquitetura visam a homogeneizao do acesso aos dados, visando a implementao de padres de projeto como o Data Acess Object (DAO) (DEEPAK, 2001) ou DataMapper (FOWLER, 2002).

2.2 As Especificaes da JEE 5 Padres no devem ser revolucionrios, mas sim evolucionistas. (Autor desconhecido) A especificao JSR 244 um arcabouo que rene cerca de duas dezenas de especificaes divididas em quatro pacotes. Os pacotes e algumas de suas JSRs so citados no Quadro 1 a seguir:
Web Layer Servlets JSR 245 JSR 252 Java Server Pages (JSP) Componente web capaz de responder a requisies ao servidor, tendo como mais comum representando a verso para protocolo HTTP. Componente web para a construo de pginas dinmicas baseada em tags facilmente injetadas em pginas HTML. Framework web que implementa o padro MVC baseado na configurao de um controlador para o fluxo de informaes entre as camadas de viso e web.

Java Server Faces (JSF) Business Layer

JSR 919 JSR 914 JSR 220 JSR 220 JSR 224 JSR 101

JavaMail Java Message Service (JMS)

Facilitador para a utilizao dos protocolos relacionados ao sistema de e-mail.

Framework que implementa a arquitetura de sistemas distribudos com comunicao assncrona, provendo um servidor de filas de mensagens. Framework que prov uma infraestrutra de desenvolvimento baseado Enterprise Java Beans (EJB) em componentes de software desacoplados e reusveis. Java Persistence API (JPA) Web-Services Java API for XML-Based Web-services (JAX-WS) Java API for XML-Based RPC (JAX-RPC) Mangement and Security Criao de Web-services baseados em comunicao XML. Criao de servios baseados em chamadas remotas a mtodos. API de alto nvel para a persistncia de informaes, solucionando o problema da converso objeto-relacional.

JSRs 88, 77, 115

Deploy, Management e Authorization

Especificaes relacionadas a tarefa de gerenciamento dos aplicativos dentro do container e acesso a servios do aplicativo por usurios do mesmo.

Quadro 1. Algumas das principais especificaes da JEE 5

3. Evoluo da Plataforma O desenvolvimento da verso 5 do JEE tem como principal objetivo alcanar melhor produtividade e maior velocidade de implementao. Para cumprir esta meta, vrias diretrizes

foram seguidas, assim como alguns padres arquiteturais e tecnolgicos foram implementados. Esta seo visa esclarecer as foras que moldaram as mudanas de trs das especificaes mais populares da JEE 5 e fazer observaes sobre a aceitao das mesmas pela comunidade de desenvolvedores. A escolha das JSRs para a avaliao proposta neste trabalho se deu com base em dois pontos: sua popularidade no meio dos desenvolvedores de sistemas e as caractersticas que guiaram seu desenvolvimento. Quanto popularidade, a escolha se baseou na enquete disponvel em (JAVA.NET, 2006), respondida por centenas de desenvolvedores usurios da plataforma JEE sobre as especificaes da verso 5 que mais lhes chamaram a ateno. Do total, 35.4% votaram nas inovaes do EJB 3, outros 17.4% na JPA e ainda 15% na JSF. As duas primeiras so parte integrante da JSR 220 e sero comentadas nas sees 3.3 e 3.2, enquanto a ltima padronizada na JSR 252 comentada na seo 3.1. A JSR 252 pertence ao grupo de especificaes da "camada web ", enquanto a JSR 220 padroniza dois importantes frameworks da "camada de negcio". Com relao s caractersticas de desenvolvimento, a escolha destas JSRs foi fortalecida pela relao existente entre as mesmas e melhorias relacionadas : produtividade, atravs da utilizao eficiente de configuraes; injeo de dependncias, que um padro tecnolgico envolvendo conceitos como POJO e Spring; e a implementao de padres de projeto, como o famoso MVC. Cada uma destas melhorias ser abordada nas sub-sees a seguir. 3.1 JSF A Java Server Faces (JSF) a mais nova integrante do conjunto de padres para a camada web da plataforma JEE. Para entender o seu desenvolvimento faz-se necessrio um rpido retrospecto sobre a evoluo de solues para esta camada. A primeira soluo o Servlet, a estrutura bsica para o desenvolvimento de aplicaes web em Java. Atravs dele o desenvolvedor recebe uma requisio, geralmente HTTP, realiza algum processamento e produz um retorno para o cliente. A resposta de uma requisio HTTP escrita em HTML, o que exige a gerao de retornos relativamente longos dado que a resposta buscada na camada lgica deve ser encrustada em um envelope HTML. Alm disso, este mtodo em pocas mais remotas, no permitia grande flexibilidade e manutenibilidade. Qualquer alterao na apresentao no design das interfaces com o usurio exigiam reescrita de cdigo JAVA, o que normalmente no 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 lgica e o do designer, facilitando a manuteno e o reaproveitamento. Como o simples fato de utilizao destas tecnologias no implica em sistemas de qualidade, neste caso um bom nvel de desacoplamento entre a camada de viso e a de lgica, torna-se importante a utilizao/implementao de padres de projeto. Por volta de 1978, o padro arquitetural Model-View-Controller foi criado e usado em aplicativos desenvolvidos em liguagens de programao Orientadas a Objetos. O MVC surgiu exatamente com o objetivo de separar a View (User Interface) do Model (Business Logic), o que pde ser aplicado tambm em sistemas web desenvolvidos com Servlets e JSPs. Esse padro baseia-se em trs definies: i) o Model a lgica da aplicao em questo e livre de apresentao; ii) a View implementa a interao entre o usurio e a aplicao no exigindo outro conhecimento do Model seno a definio de seus servios; iii) um Controller deve existir para intermediar a comunicao entre as definies anteriores, como por exemplo, receber requisies da viso, gerenciar sincronizao de estados entre as duas camadas, entre outras. Para atacar a problemtica do acoplamento entre as camadas de apresentao e do modelo em sistemas web, surgiram implementaes deste padro atravs 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 prticas padronizadas ou "ad hoc" j utilizadas por vrios desenvolvedores, o Struts tornou-se uma ferramenta muito utilizada em todo o mundo, sendo ento doada Fundao Apache (apache.org) para uma manuteno mais cuidadosa. Hoje em sua segunda verso, o Struts continua buscando a adio de formas de desenvolvimento difundidas dentro da comunidade. Mas como o Struts uma ferramenta mantida por terceiros, a JCP decidiu criar uma especificao, com o nome de Java Server Faces (JSF), para padronizar a utilizao de servios similares aos j providos pelo Struts. Alguns objetivos do JSF so: criar componentes de interface com usurio (UI) de alta qualidade e que possam se conectar ao comportamento de qualquer aplicao; possibilitar a fcil integrao de ferramentas Rapid Application Development (RAD) para aumentar a produtividade; forar a utilizao do padro MVC no projeto de sistemas web promovendo maior qualidade inerente; facilitar a gerncia de fluxos entre os componentes de viso, entre outros. Dentre as trs especificaes aqui discutidas, esta a menos complexa e passvel de poucos questionamentos, dado que a viso da mesma de padronizao de tendncias j

adotadas pela comunidade de desenvolvedores. Acredita-se que o processo iniciado pela JSR 252 busca reunir as boas solues que envolvem a camada de viso (e sua integrao com o modelo) o que no a impede, ou mesmo a obriga, de aproximar-se de solues j existentes. A competio existente entre Struts e JSF no mnimo benfica para a construo de frameworks mais completos. 3.2 JPA Como j foi dito no incio deste trabalho a tecnologia Java baseada em conceitos de Orientao a Objetos (OO). Pela sua clareza e expressividade na modelagem da relao entre as entidades do domnio dos Sistemas de Informao, este o paradigma de linguagem de programao mais utilizado neste contexto. No entanto, por questes que no convm 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 so compostos por uma lgica de negcio escrita em modelo OO, e os dados desta so armazenados em um banco de dados (BD), surge a necessidade de construir solues para realizar o mapeamento objeto-relacional (O-R). A primeira e mais simples dentre as solues a API JDBC (SUN, 2002). Ela composta por um conjunto de interfaces de programao que definem, entre outras coisas: como um sistema desenvolvido em linguagem Java realiza uma conexo 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 prprios desenvolvedor de SGBD. As solues finais para o JDBC so compostas pelos denominados drivers, capazes de conectar o sistema Java a um SGBD especfico. A JDBC a soluo padro para todo mapeamento objeto-relacional, seja atravs de sua utilizao direta, seja atravs da utilizao de camadas de mais alto nvel. Sua principal vantagem a simplicidade arquitetural e facilidade de utilizao. Mas por lidar com linguagem SQL, que uma especificao de mais baixo nvel esta soluo pode tornar-se improdutiva ao ser utilizada em sistemas de grande porte. Para solucionar a questo da produtividade do uso direto do JDBC e ainda tornar o mapeamento O-R transparente ao desenvolvedor da lgica de negcio, surgiram frameworks tais como o Hibernate (struts.apache.org) e o Toplink (ORACLE, 2007). Em termos gerais, estas solues fazem uso de um sistema paralelo de configurao do mapeamento desejado.

Um aplicativo interno ao framework fica responsvel por traduzir, automaticamente, operaes de criao, edio, busca e remoo de objetos dentro do banco de dados. O Hibernate um framework que se tornou o padro de fato neste contexto. Percebendo esta realidade, a verso 5 da plataforma JEE criou a especificao denominada Java Persistence API (JPA), a qual parte integrante da JSR 220. Este talvez seja o componente mais acessvel do JEE 5, dado que sua implementao pode ser utilizada independente do servidor de aplicaes permitindo inclusive o seu uso por aplicativos JSE. A JPA um padro com fortes indcios de aceitao pelo mercado dada a sua considerao de conceitos tecnolgicos j existentes e a sua busca por uma maior produtividade. Um ponto a somar na sua aceitao a pronta implementao das interfaces definidas pela JPA pela tecnologia Hibernate (na sua verso 3). As principais crticas envolvem no os conceitos existentes na JSR, mas sim a falta de alguns recursos j existentes nas solues no padronizadas. Um dos exemplos a facilidade de utilizar objetos como parmetro em operaes com o banco de dados, e.g. uma busca (select) onde os filtros so objetos do tipo do retorno. Mas dado que o processo de padronizao inerentemente evolutivo, os autores deste trabalho consideram a implementao (ou excluso consciente) de tais recursos uma questo de tempo e de estudo mais cuidadoso. Esta espera permite uma maturao de conceitos mais recentes e diminui as chances de absoro de recursos tecnicamente desvantajosos quando aplicados e avaliados em contextos mais amplos. No campo da produtividade e simplicidade a JPA possibilita realizar configuraes via Annotations (JSR 175), uma linguagem para a escrita de meta-dados da tecnologia Java passvel de checagem em tempo de compilao. Este formato para a definio do mapeamento OR no substitui a utilizao do XML, dado que a insero de "anotaes" no cdigo fonte da aplicao pode prejudicar a legibilidade do mesmo. Este trabalho no aborda profundamente esta questo, mas julga que a avaliao do uso das vrias 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 padronizao possui um carter evolucionista e no revolucionrio fica clara nesta especificao. H de se considerar que a migrao de tecnologias em sistemas reais deve passar por forte anlise, mesmo sendo uma questo de usar tecnologias padronizadas ou no. Mas como deixa claro Christian Bauer desenvolvedor do Hibernate em frum de discusso on-line mantido pela Hibernate.org, muito importante manter seu sistema compatvel com APIs padronizadas, mesmo que parte das funcionalidades utilizadas ainda no estejam especificadas. Isso porque os padres de

mercado tendem a possuir um melhor suporte de ferramentas e opes de escolha entre solues concorrentes; e, dada uma maior quantidade de usurios, tende a aumentar a qualidade e confiabilidade das opes. 3.3 EJB O Enterprise JavaBeans (EJB) uma arquitetura para o desenvolvimento e a implantao de aplicativos baseados em componentes. Sistemas construdos sobre esta plataforma devem levar em considerao os seguintes conceitos:

o componente de software desenvolvido para resolver problemas da lgica de negcio; a montagem do sistema sob uma infraestrutura capaz de gerenciar os componentes; a configurao do container, que capaz de prover servios adicionais como segurana, gerncia de ciclo de vida de objetos, persistncia, etc. A idia de infraestruturas baseadas em componentes desacoplados, porm facilmente

encaixveis, uma das questes arquiteturais abertas por muito tempo. Durante anos, vrias ferramentas buscaram prover esta facilidade e a especificao EJB, j em sua terceira verso, mais uma delas. A importncia da JSR 220 no contexto histrico a busca "das pazes" com os usurios do modelo de sistemas baseados em componentes. Em suas duas primeiras verses 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 reusveis ou mesmo testveis fora da mesma. 3.3.1 Evoluo por Concorrncia - 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 especificao. O Spring um framework que constri uma infraestrutura para a gerncia de componentes de software baseada em vrios padres tecnolgicos "de fato". Baseado em um core/container, prov vrios outros mdulos que, quando comparados s especificaes JEE, visvel a concorrncia direta. Sua aceitao em detrimento da J2EE (verso anterior da plataforma) uma importante questo a ser analisada. Tendncias tecnolgicas que vinham ganhando o mercado desde o incio da dcada tornavam-se padro. A injeo de dependncia, programao declarativa, desenvolvimento baseado em POJOs, Programao Orientada a Aspectos (POA), e inverso 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 tendncias rapidamente tornando-se um framework conceituado como simples, modular, testvel, de infraestrutura leve e "no-intrusivo". 3.3.2 Um EJB Completamente Novo "O propsito 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 especificao, que envolve o trabalho de um comit, foi necessrio um tempo maior desde o processo de idealizao, formao de comit, finalizao e implementao do padro. Num processo que leva cerca de 3 anos, esta nova verso do modelo de sistemas componentizados buscou praticamente os mesmos avanos j atingidos pelo Spring anteriormente, com a vantagem de ser um padro de referncia. A importncia de ser um padro de comit uma questo que pode ser respondida apenas com o tempo de maturao e ndices de aceitadao do mercado. Uma realidade importante o fato de que o Spring ganhou adeptos baseado em um destaque real de inovao tecnolgica e arquitetural, vantagem esta que, se no j recuperada pela JEE 5, j no as mantm em patamares diferentes. A nova verso do EJB j prov especificaes desacoplveis do container, possui arquitetura simplificada e,

comparativamente, possui alto grau de produtividade baseada nas facilidade de configurao. As principais mudanas relativas simplificao da arquitetura EJB seguem abaixo:

nenhum requisito de herana de classe ou interface exigido, tornando o modelo EJB menos intrusivo;

contrato com o container reduzido anotao/configurao de mtodos; possibilidade de uso de anotaes para reduzir a necessidade de XML; persistncia de objetos baseada no mapeamento O-R da JPA. Trabalhos futuros sero realizados visando uma comparao mais minuciosa entre as

duas opes de modelo de software, baseado em componentes, para a tecnologia Java. Mas a impresso obtida ao acompanhar vrias comunidades de desenvolvedores a de que a especificao EJB 3.0 resolveu os seus problemas arquiteturais e pode agora continuar com sua evoluo competitiva (a verso 3.1 ter a JSR finalizada ainda deste ano).

4. Consideraes Finais Este artigo buscou apresentar um panorama da plataforma de desenvolvimento Java Enterprise Edition , com foco nas tendncias de mercado que guiaram a evoluo para a ltima verso da mesma. Para isso mostrou-se alguns detalhes das trs especificaes mais populares da plataforma: JSF, JPA e EJB. Enquanto todas seguem o princpio de aumentar a produtividade da plataforma JEE, as duas primeiras buscam a facilitao do uso de padres de projeto - como MVC. J a terceira sofreu influncias diversas dado um histrico de baixa aceitao da verso anterior. Para trabalhos futuros os autores e outros colaboradores pretendem executar pesquisas que quantifiquem a aceitao das mudanas aqui demonstradas. Um dos pontos j em estudo a avaliao da aplicabilidade das Annotations em detrimento a outras formas de configurao e meta-dados. A anlise dos reais ganhos de produtividade da JSF com relao ao Struts tambm est incio de estudo, assim como, uma avaliao entre os containers providos pelo EJB e pelo Spring. 5. Referncias 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. Disponvel:<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. Disponvel: <http://java.sun.com/javaee/5/docs/tutorial/doc/>. Acesso em: 02 jun. 2008. FSF - Free Software Foundation, INC. About Free Software, 1996. Disponvel: <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. Disponvel: <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. Disponvel: <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. Disponvel: <http://www.theserverside.com/tt/articles/article.tss?l=IntrotoSpring25> Acesso em: 03 jun. 2008. ORACLE. TopLink, 2007. Disponvel: 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. Disponvel:. <http://heim.ifi.uio.no/~trygver/themes/mvc/mvc > Acesso em: 01 jun. 2008 SUN - Sun Microsystems, INC. JDBC Documentation. 2002. Disponvel: <http://java.sun.com/javase/6/docs/technotes/guides/jdbc> Acesso em: 01 jun. 2008