EVOLUÇÃO DA PLATAFORMA DE DESENVOLVIMENTO CORPORATIVO JEE

Transcrição

1 EVOLUÇÃO DA PLATAFORMA DE DESENVOLVIMENTO CORPORATIVO JEE Nigini Abilio Oliveira 1 Emanuell Faustino Henrique de Lucena 2 ;Edmilson Pereira Lima Neto 3 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 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 1 Professor do Curso de Bacharelado em Sistemas de Informação das Faculdades Integradas de Patos FIP. Doutorando em Engenharia Elétrica pela UFCG. nigini@ffm.com.br 2 Estudante do Curso de Bacharelado em Sistemas de Informação das Faculdades Integradas de Patos FIP. Graduando. emanuell@ffm.com.br 3 Estudante do Curso de Bacharelado em Sistemas de Informação das Faculdades Integradas de Patos FIP. Graduando. edmilson@ffm.com.br

2 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

3 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

4 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 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).

5 2.2 As Especificações da JEE 5 Padrões não devem ser revolucionários, mas sim evolucionistas. (Autor desconhecido) A especificação 244 é um arcabouço que reúne cerca de duas dezenas de especificações divididas em quatro pacotes. Os pacotes e algumas de suas s são citados no Quadro 1 a seguir: Web Layer Servlets Java Server Pages (JSP) Java Server Faces (JSF) Business Layer JavaMail Java Message Service (JMS) Enterprise Java Beans (EJB) Java Persistence API (JPA) Web-Services Java API for XML-Based Web-services (JAX-WS) Java API for XML-Based RPC (JAX-RPC) Componente web capaz de responder a requisições ao servidor, tendo como mais comum representando a versão para protocolo HTTP. Componente web para a construção de páginas dinâmicas baseada em tags facilmente injetadas em páginas HTML. 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. Facilitador para a utilização dos protocolos relacionados ao sistema de . Framework que implementa a arquitetura de sistemas distribuídos com comunicação assíncrona, provendo um servidor de filas de mensagens. Framework que provê uma infraestrutra de desenvolvimento baseado em componentes de software desacoplados e reusáveis. API de alto nível para a persistência de informações, solucionando o problema da conversão objeto-relacional. Criação de Web-services baseados em comunicação XML. Criação de serviços baseados em chamadas remotas a métodos. Mangement and Security s 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 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

6 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 s 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 220 e serão comentadas nas seções 3.3 e 3.2, enquanto a última é padronizada na 252 comentada na seção 3.1. A 252 pertence ao grupo de especificações da "camada web", enquanto a 220 padroniza dois importantes frameworks da "camada de negócio". Com relação às características de desenvolvimento, a escolha destas s 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

7 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á

8 adotadas pela comunidade de desenvolvedores. Acredita-se que o processo iniciado pela 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.

9 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 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, 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 ( 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

10 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 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 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

11 ú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" Um EJB Completamente Novo "O propósito do EJB 3 é melhorar a arquitetura do modelo reduzindo sua complexidade do ponto de vista do programador." (-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 finalizada ainda deste ano).

12 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, Disponível:< > Acesso em: 01 jun FOWLER, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, Nov p JENDROCK, Eric et al. The Java EE 5 Tutorial, Santa Clara, EUA, Sept Disponível: < Acesso em: 02 jun FSF - Free Software Foundation, INC. About Free Software, Disponível: < Acesso em: 01 jun JCP Java Community Process. 244: JavaTM Platform, Enterprise Edition 5 (Java EE 5) Specification, May Disponível: < Acesso em: 01 jun JAVA.NET. Which Java EE 5 feature appeals to you most?, Disponível: < Acesso em: 01 jun JOHNSON, Rod. Expert One-on-One J2EE Design and Development. Birmingham, UK: Wrox Press Ltd, 2002.

13 JOHNSON, Rod. Introduction to the Spring Framework. Oct, Disponível: < Acesso em: 03 jun ORACLE. TopLink, Disponível: Acesso em: 01 jun REENSKAUG, Trygve. The Model-View-Controller (MVC) Its Past and Present. University of Oslo, Aug, Disponível:. < > Acesso em: 01 jun SUN - Sun Microsystems, INC. JDBC Documentation Disponível: < Acesso em: 01 jun. 2008