Você está na página 1de 69

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMTICA CURSO DE BACHARELADO EM CINCIA DA COMPUTAO

Anlise Comparativa entre as Verses 2.1 e 3.0 da Arquitetura Enterprise JavaBeans


por EDUARDO STUDZINSKI ESTIMA DE CASTRO

Projeto de Diplomao

Prof. Dr. Cludio Fernando Resin Geyer Orientador

Porto Alegre, 14 de Setembro de 2006

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitor: Prof. Jos Carlos Ferraz Hennemann Vice-reitor: Prof. Pedro Cezar Dutra da Fonseca Pr-Reitor de Graduao: Prof. Carlos Alexandre Netto Diretor do Instituto de Informtica: Prof. Flvio Rech Wagner Bibliotecria-Chefa do Instituto de Informtica: Beatriz Regina Bastos Haro

Agradecimentos
Primeiramente gostaria de agradecer a minha famlia por ter sempre colocado a educao em primeiro lugar e me apoiado durante todo esse curso de graduao. Obrigado Antnio (Pai), Lurdes (Me), Ndia (Mana), Marly (Tia) e Lcia (Av). Gostaria de agradecer Gisele, certamente faltariam palavras para expressar todo o meu obrigado. Gostaria de agradecer especialmente ao Professor Doutor Cludio Fernando Resin Geyer por todo o apoio prestado durante o desenvolvimento desse trabalho e pelos grandes esforos para que o projeto BRAFITEC tivesse sucesso. Gostaria de agradecer especialmente Professora Doutora Mara Abel, minha orientadora de Iniciao Cientfica, tanto pelo apoio para o meu desenvolvimento no meio cientfico e acadmico, como pela amizade. Gostaria de agradecer ao Professor Dr. Luiz Fernando De Ros, meu orientador de Iniciao Cientfica, por seus conhecimentos na rea de Geologia, campo pouco conhecido por mim. Gostaria de agradecer aos amigos do Grupo BDI, especialmente ao Sandro, Felipe e Laura pela grande troca de conhecimentos realizada durante as bolsas de iniciao cientfica. No podendo esquecer de agradecer pelos timos momentos de descontrao. Gostaria de agradecer ao meu amigo Sandro que conheo desde os tempos do Ensino Fundamental. Obrigado por ter participado dos inmeros trabalhos que sempre tiveram resultados excelentes durante o curso. Gostaria de agradecer aos grandes amigos Carlos Alberto, Carlos Moreira, Edson, Emanuel, Gallina, Giacomel, Mrcio, Peter, Rafael e Tota. Gostaria de agradecer a todo o corpo docente e funcionrios do Instituto de Informtica/UFRGS pelo esforo conjunto realizado ao longo dos anos possibilitando uma formao de excelncia na rea de Cincia de Computao. Por fim, gostaria de agradecer a todos que colaboraram de algum modo para a minha realizao do curso de Cincia da Computao.

Sumrio
Lista de Abreviaturas ou Siglas ............................................................................... 7 Lista de Figuras......................................................................................................... 8 Lista de Tabelas ........................................................................................................ 9 Resumo..................................................................................................................... 10 Abstract.................................................................................................................... 11 1. Introduo ........................................................................................................... 12 2. Java EE ................................................................................................................ 14 2.1. Plataforma Java EE ........................................................................................ 14 2.2. Componentes Java EE.................................................................................... 15 2.2.1. Componentes Clientes............................................................................. 15 2.2.2. Componentes Web................................................................................... 15 2.2.3. Componentes de Negcios ...................................................................... 15 2.3. Contineres Java EE ...................................................................................... 15 2.3.1. Continer de Clientes.............................................................................. 16 2.3.2. Continer de Web.................................................................................... 16 2.3.3. Continer de EJB .................................................................................... 16 2.4. Servios.......................................................................................................... 16 2.5. Comunicao e Interoperabilidade ................................................................ 17 3. Enterprise JavaBeans, verso 2.1 ...................................................................... 18 3.1. Arquitetura EJB ............................................................................................. 18 3.1.2. Continer de EJB .................................................................................... 19 3.1.3. Servidor de EJB ...................................................................................... 20 3.2. EJB Roles....................................................................................................... 20 3.2.1. Provedor de Enterprise Beans ................................................................ 20 3.2.2. Montador de Aplicao .......................................................................... 20 3.2.3. EJB Deployer .......................................................................................... 20 3.2.4. Provedor de Servidor EJB ...................................................................... 21 3.2.5. Provedor de Continer EJB.................................................................... 21 3.2.6. Administrador de Sistemas ..................................................................... 21 3.3. Componentes Session Bean ........................................................................... 21 3.3.1. Stateless Session Beans........................................................................... 21 3.3.2. Stateful Session Beans ............................................................................ 22 3.3.3. Exigncias no Desenvolvimento de Session Beans................................. 24

5 3.4. Componentes Message-Driven Bean............................................................. 25 3.4.1. Exigncias no Desenvolvimento de Message-Driven Beans .................. 26 3.5. Componentes Entity Bean ............................................................................. 26 3.5.1. Bean-Managed Entity Beans (BMP)....................................................... 27 3.5.2. Exigncias no Desenvolvimento de Bean-Managed Entity Beans.......... 29 3.5.3. Conteiner-Managed Entity Beans (CMP)............................................... 30 3.5.4. Exigncias no Desenvolvimento de Container - Managed Entity Beans 31 3.5.5. EJB QL.................................................................................................... 31 3.6. Suporte a Transaes ..................................................................................... 31 4. Enterprise JavaBeans, verso 3.0 e Comparao com a Verso 2.1 .............. 32 4.1. Anotaes de Metadados ............................................................................... 32 4.2. Programao Orientada a Aspecto................................................................. 32 4.2.1. Interceptors ............................................................................................. 33 4.3. Conceito POJO .............................................................................................. 35 4.4. EJB Roles....................................................................................................... 35 4.5. Componentes Session Bean ........................................................................... 36 4.5.1. Stateless Session Beans........................................................................... 36 4.5.2. Stateful Session Beans ............................................................................ 37 4.5.3. Exigncias no Desenvolvimento de Session Beans................................. 39 4.6. Componentes Message-Driven Bean............................................................. 41 4.6.1. Exigncias no Desenvolvimento de Message-Driven Beans .................. 42 4.7. Componentes Entity Bean ............................................................................. 43 4.7.1. Persistence Contexts, API Entity Managers e API Queries ................... 44 4.7.2. Ciclo de vida de Entity Beans ................................................................. 47 4.7.3. Exigncias no Desenvolvimento de Entity Beans ................................... 48 4.7.4. EJB QL.................................................................................................... 49 4.8. Suporte a Transaes ..................................................................................... 50 5. Metodologia para Avaliao de Desempenho de Componentes EJB............. 51 5.1. Mtrica de Desempenho ................................................................................ 51 5.2. Reduo de Erros em Medidas Experimentais .............................................. 52 5.3. Critrios de Avaliao.................................................................................... 53 5.4. Critrios de Avaliao Utilizados .................................................................. 54 5.5. Modelo de Cliente Utilizado.......................................................................... 55 6. Avaliao de Desempenho de Componentes EJB: Verses 2.1 e 3.0.............. 56 6.1. Recursos Utilizados ....................................................................................... 56

6 6.1.1. Hardware ................................................................................................ 56 6.1.2. Software .................................................................................................. 56 6.2. Medio do Tempo ........................................................................................ 57 6.3. Procedimento de Teste................................................................................... 57 6.4.1. Lookup de componentes Session Beans .................................................. 58 6.4.2. Invocao de mtodos de componentes Session Beans .......................... 60 6.4.3. Invocao de mtodo transacional gerenciado pelo continer .............. 62 6.4.4. Invocao de mtodo transacional gerenciado pelo bean ..................... 63 6.4.5. Localizao de um componente Entity Bean .......................................... 64 7. Concluso............................................................................................................. 66 Referncias Bibliogrficas...................................................................................... 67 ANEXO 1 Exemplo de Anotaes de Metadados.............................................. 69

Lista de Abreviaturas ou Siglas


BMT CMT DOT EJB EE EIS CORBA CTS HTML HTTP HTTPS IDL IIOP JDBC JIT JMS JNDI JOnAS JRMP JSP JVM OD ORB POA RMI SGBD XML Bean-Managed Transaction Demarcation Continer-Managed Transaction Demarcation Distributed Object Technology Enterprise JavaBean Enterprise Edition Enterprise Information System Common Object Request Brokerage Architecture Compatibility Test Suite HyperText Markup Language HyperText Transfer Protocol HyperText Transfer Protocol Secure Interface Definition Language Internet Inter-ORB Protocol Java Database Connectivity Just-in-time Java Message Service Java Naming and Directory Interface Java Open Application Server Java Remote Method Protocol JavaServer Pages Java Virtual Machine Objetos Distribudos Object Request Broker Programao Orientada a Aspecto Remote Method Invocation Sistema Gerenciador de Banco de Dados Extensible Markup Language

Lista de Figuras
FIGURA 2.1 - Camadas Java EE.............................................................................. 14 FIGURA 2.2 Servidor Java EE e Contineres ....................................................... 16 FIGURA 3.1 Arquitetura EJB, verso 2.1 ............................................................. 18 FIGURA 3.2 Ciclo de vida de um stateless session bean(Fonte [SUN 03]) ......... 22 FIGURA 3.3 Ciclo de vida de um stateful session bean (Fonte [SUN 03]).......... 24 FIGURA 3.4 Ciclo de vida de um message-driven bean (Fonte [SUN 03]) ......... 26 FIGURA 3.5 Ciclo de vida de um bean-managed entity bean (Fonte [SUN 03]). 29 FIGURA 4.1 Exemplo de Interceptor.................................................................... 34 FIGURA 4.2 Relaes entre os "EJB Roles"......................................................... 36 FIGURA 4.3 Ciclo de vida de um stateless session bean, EJB 3.0....................... 37 FIGURA 4.4 Ciclo de vida de um stateful session bean, EJB 3.0......................... 39 FIGURA 4.5 - Ciclo de vida de um message-driven bean, EJB 3.0........................ 41 FIGURA 4.6 Organizao da API de Persistncia ................................................ 47 FIGURA 4.7 Ciclo de vida de um entity bean, EJB 3.0. ....................................... 48 FIGURA 5.1 Determinao do Zc para 95% de confiana .................................... 52 FIGURA 5.2 Frmula para o clculo do tamanho da amostra .............................. 53 FIGURA 6.1 Clculo do tempo para uma operao. ............................................. 57 FIGURA 6.2 Lookup de um stateless session bean .............................................. 59 FIGURA 6.3 - Lookup de um stateful session bean................................................. 59 FIGURA 6.4 Invocao de um mtodo sem parmetro e sem resultado............... 61 FIGURA 6.5 Invocao de um mtodo sem parmetro, mas com resultado......... 61 FIGURA 6.6 Invocao de um mtodo com parmetro e com resultado.............. 62 FIGURA 6.7 Invocao de um mtodo com transao demarcada pelo continer 63 FIGURA 6.8 Invocao de um mtodo com transao demarcada pelo bean ...... 64 FIGURA 6.9 Localizao de um componente entity bean .................................... 65

Lista de Tabelas
TABELA 2.1 Servios e Protocolos na plataforma Java EE ................................. 17 TABELA 3.1 Comparao entre mtodos find e select......................................... 30 TABELA 4.1 Comparao entre session EJB 2.1 e EJB 3.0................................. 40 TABELA 4.2 Principais anotaes utilizadas em session beans........................... 40 TABELA 4.3 Comparao entre message-driven EJB 2.1 e EJB 3.0 ................... 42 TABELA 4.4 Principais anotaes utilizadas em message-driven beans ............. 42 TABELA 4.5 Principais anotaes do mapeamento O/R...................................... 43 TABELA 4.6 Anotaes para a definio de mtodos de callback....................... 48 TABELA 4.7 Comparao entre entity EJB 2.1 e EJB 3.0.................................... 49 TABELA 4.8 Anotaes para definies de consultas.......................................... 50 TABELA 6.1 Tempo mdio de lookup do tipo stateless....................................... 58 TABELA 6.2 Tempo mdio de lookup do tipo stateful......................................... 59 TABELA 6.3 Tempo mdio de invocao de um mtodo sem parmetro e resultado ......................................................................................................................... 60 TABELA 6.4 Tempo mdio de invocao de um mtodo sem parmetro, mas com resultado ......................................................................................................................... 61 TABELA 6.5 Tempo mdio de invocao de um mtodo com parmetro e resultado ......................................................................................................................... 61 TABELA 6.6 Tempo mdio de invocao de um mtodo com transao demarcada pelo continer ............................................................................................... 62 TABELA 6.7 Tempo de invocao de um mtodo com transao demarcada pelo bean ................................................................................................................................ 63 TABELA 6.8 Tempo mdio de localizao de um componente entity bean......... 64

10

Resumo
A utilizao da plataforma Java Enterprise Edition (Java EE) no desenvolvimento de aplicaes corporativas distribudas tem aumentado consideravelmente nos ltimos anos. Os fatores fundamentais para o aumento do uso dessa plataforma referem-se capacidade de reduo do grau de complexidade para o desenvolvimento de aplicaes multicamadas e o fornecimento de servios de baixo nvel como suporte a transaes e tolerncia a falhas. Essa plataforma, para o desenvolvimento da camada de negcios localizada no servidor, prope a utilizao de Enterprise JavaBeans(EJBs); entretanto, a verso 2.1 dessa arquitetura tem sido bastante criticada pela quantidade de exigncias existentes para o seu uso. Desse modo, a Sun Microsystems, responsvel pela especificao da arquitetura EJB, est propondo a verso 3.0 cujo enfoque principal a reduo da complexidade com enfoque no desenvolvedor. Para acompanhar a evoluo dessa arquitetura, esse trabalho apresenta um estudo comparativo entre as verses 2.1 e 3.0, destacando as principais caractersticas e diferenas. Alm disso, uma anlise de desempenho entre as principais implementaes das verses dessa arquitetura torna-se importante para deciso de adoo dessa nova verso da arquitetura EJB. A partir do estudo comparativo realizado entre as especificaes da verso 2.1 e 3.0, pode-se identificar simplificaes significativas na verso 3.0 que facilitam a utilizao dessa arquitetura e eliminam a realizao repetitiva de certas tarefas. Alm disso, os resultados obtidos na avaliao de desempenho demonstraram ganhos de desempenho em aspectos relacionados localizao de componentes EJB e persistncia de informaes quando utilizada a verso 3.0; entretanto, em alguns aspectos a verso 2.1 ainda apresenta um melhor desempenho. A anlise de desempenho foi desenvolvida com base em uma metodologia, na qual os critrios para avaliao so apresentados, assim como a mtrica de desempenho utilizada. A definio da metodologia utilizou importantes trabalhos relacionados avaliao de desempenho de tecnologias de objetos distribudos. Apesar dos resultados favorveis encontrados para a verso 3.0 da especificao, destaca-se que as implementaes disponveis esto em nvel inicial de desenvolvimento. Desse modo, a tomada de deciso final sobre sua adoo deve aguardar a disponibilidade de implementaes estveis.

Palavras-chave: Aplicaes Distribudas, EJB 2.1, EJB 3.0, Enterprise JavaBeans, Reduo de Complexidade, Anlise de Desempenho.

11

Abstract
The Java Enterprise Edition (Java EE) platform use for enterprise distributed applications development has increased considerably in the last years. The main factors to the growth in the use of this platform is related to the capability of complexity level reduction in the multi-tier applications development and to the low level services provided as transactions and fault. This platform, to the business logic development in the server, proposes the Enterprise JavaBeans (EJBs) use; however, the version 2.1 of this architecture has been criticized intensely because it has a high number of obligations for its use. For this reason, the Sun Microsystems, which is responsible to the EJB architecture specification, is proposing the version 3.0 whose mainly focus is complexity reduction from the developers point of view. To follow the evolution of this architecture, this work presents a comparative study between the specification versions 2.1 and 3.0, showing the mainly characteristics and differences. Furthermore, a performance analyses among the implementations of these two versions becomes important for the decision in the version 3.0 adoption. Using this comparative study between the versions 2.1 and 3.0, it is possible to identify significant simplifications in the version 3.0, which make easier the use of this architecture and which eliminate the need of making repetitively tasks. In addition, the performance analyses results demonstrate advances in aspects related to the EJB component lookup and information persistence when the version 3.0 is used; however, in some aspects the EJB 2.1 still has a better performance. The performance analyses was developed using as basis a methodology, which the operations to the evaluation are specified, as well as the performance metric used. The methodology definition is based on important works related to performance evaluation of distributed object technologies. In spite of the encouraging results found to the specification version 3.0, the available implementations are in the primarily level of development. For this reason, the decision making about an EJB 3.0 server adoption must wait the release of stable implementations.

Keywords: Distributed Applications, EJB 2.1, EJB 3.0, Enterprise JavaBeans, Complexity Reduction, Performance Analyses.

12

1. Introduo
O desenvolvimento de aplicaes corporativas em um tempo hbil um ponto chave para a manuteno de competitividade de uma empresa. Tendo em vista essa necessidade, a Sun Microsystems props a plataforma Java Enterprise Edtion (Java EE) para o desenvolvimento de aplicaes corporativas multicamadas utilizando uma abordagem baseada em componentes [SUN 06a]. A plataforma Java EE foi projetada para permitir o desenvolvimento de aplicaes corporativas que necessitam de servios como suporte a transaes, confiabilidade e escalabilidade. Alm disso, para facilitar o acesso desses servios pelos desenvolvedores, essa plataforma props a utilizao da arquitetura Enterprise JavaBeans (EJBs) na camada de negcios. Essa arquitetura na verso 2.1, entretanto, no conseguiu atingir o objetivo proposto de simplificao devido quantidade de requisitos necessrios para o desenvolvimento de componentes EJB, fato que prejudica a sua ampla adoo. Desse modo, a Sun desenvolveu a verso 3.0 trazendo mudanas significativas no modo de desenvolvimento desses componentes. A nova verso exige a implementao de novas aplicaes chamadas de servidores EJB. Esse tipo de aplicao fornece os recursos necessrios para a execuo de componentes EJB. Em adio, o desenvolvimento dessas aplicaes exige o cumprimento rgido da especificao proposta pela Sun. Desse modo, testes de conformidade so um recurso til para verificar a conformidade da implementao em relao especificao. Tendo em vista a importncia desse tipo de teste, anteriormente a esse trabalho, foi realizado um estudo e desenvolvimento de um conjunto de testes para verificar a conformidade do servidor EJB chamado EasyBeans. Os resultados desse trabalho so apresentados em [CAS 06]. As novidades introduzidas na verso 3.0 parecem ser um passo importante para a expanso do seu uso; contudo, um estudo comparativo necessrio para auxiliar na tomada de deciso sobre sua utilizao. Em razo disso, esse trabalho busca analisar a verso 2.1 e a verso 3.0, destacando os novos conceitos propostos pela verso 3.0 que buscam reduzir a complexidade de desenvolvimento de componentes EJB. O trabalho desenvolvido dividiu-se em duas principais etapas: anlise textual da especificao e avaliao de desempenho de implementaes das diferentes verses dessa arquitetura. A primeira etapa iniciou com a reviso bibliogrfica da verso 2.1 e da verso 3.0 da arquitetura, fator que permitiu a comparao textual entre as ltimas verses da arquitetura EJB. O objetivo principal dessa etapa foi permitir a identificao das principais diferenas existentes entre as verses da arquitetura e, tambm, os novos conceitos incorporados que permitem a simplificao da nova verso. Adicionalmente, essa etapa foi importante para a identificao de possveis fatores de influncia no desempenho das implementaes de cada verso, pois novos recursos podem ocasionar aumento ou queda de desempenho. A segunda etapa consistiu inicialmente na reviso bibliogrfica sobre tcnicas e fatores importantes para o estabelecimento de uma metodologia adequada para a anlise de desempenho. Aps essa reviso, foi possvel descrever a metodologia utilizada e desenvolver os experimentos necessrios para a realizao da anlise crtica dos

13 resultados obtidos que concluem esse estudo. Os experimentos foram interessantes para identificar os pontos nos quais houve um aumento de desempenho na verso 3.0 e tambm pontos em que houve reduo. O desenvolvimento dos captulos foi organizado do seguinte modo para facilitar a apresentao dos resultados obtidos: o captulo 2 apresenta uma viso geral da plataforma Java EE, na qual a arquitetura EJB est includa. O objetivo desse captulo familiarizar o leitor com o assunto estudado; o captulo 3 descreve a verso 2.1 da arquitetura EJB, destacando os pontos principais que aumentam a complexidade para o desenvolvimento de componentes EJB; o captulo 4 realiza a apresentao da verso 3.0 da arquitetura EJB e, paralelamente, compara as diferenas significativas existentes entre a verso 2.1 e 3.0. A apresentao e comparao foram realizadas no mesmo captulo para facilitar a identificao das diferenas entre as diferentes verses, pois essa arquitetura faz uso de uma grande quantidade de termos e conceitos. Desse modo, quando eles so apresentados, logo em seguida feita a comparao; o captulo 5 define a metodologia completa utilizada para a avaliao de desempenho de componentes EJB desenvolvidos para as diferentes verses da arquitetura; o captulo 6 apresenta os experimentos realizados nesse trabalho para a avaliao de desempenho e analisa os resultados obtidos; o captulo 7, por fim, explicita as consideraes finais e tambm os trabalhos futuros.

14

2. Java EE
A plataforma Java EE busca prover uma srie de servios necessrios para o desenvolvimento de aplicaes multicamadas. O fornecimento desses servios visa reduzir a complexidade de desenvolvimento dessas aplicaes, garantindo propriedades importantes para aplicaes utilizadas em um ambiente comercial. Entre as principais propriedades podemos destacar as seguintes: segurana, desempenho aceitvel e confiabilidade. Esse captulo apresenta a plataforma Java EE e destaca as suas principais caractersticas. Essa apresentao permite a compreenso de conceitos necessrios para o entendimento dos prximos captulos nos quais a arquitetura EJB estudada.

2.1. Plataforma Java EE


A abordagem de design e desenvolvimento de uma aplicao Java EE baseada no modelo de componentes. Componentes so elementos atmicos que seguem um determinado modelo e implementam um conjunto de interfaces, permitindo o seu reaproveitamento sem necessidade de modificaes [HEI 01]. Alm disso, para permitir um maior reaproveitamento desses componentes e fornecer servios essenciais, por exemplo, gerncia transacional e segurana, a plataforma Java EE utiliza um modelo de aplicaes distribudas multicamadas. As camadas propostas pela plataforma Java EE, conforme a FIGURA 2.1, so denominadas de camada de componentes do cliente que executa na mquina do cliente, camada de componentes web e camada de componentes de negcios que executam no servidor Java EE e, por fim, camada de enterprise information system (EIS) que executa em um servidor EIS. Cada camada agrupa um tipo de componente e cada tipo est associado a uma entidade de software denominada continer. Esses conceitos sero definidos ao longo desse captulo.

FIGURA 2.1 - Camadas Java EE

15

2.2. Componentes Java EE


Os componentes Java EE podem ser definidos como unidades funcionais autocontidas que devem ser agregadas a uma aplicao Java EE [SUN 06a], essas unidades podem se comunicar com outros componentes utilizando servios padronizados pela plataforma Java EE. Essa padronizao de servios necessria para simplificar o desenvolvimento de componentes e tambm garantir maior reusabilidade de componentes. Todo componente Java EE dependente de outra entidade de software denominada continer. Os contineres so responsveis por fornecer os servios requisitados pelos componentes, por exemplo, segurana e gerncia de recursos. 2.2.1. Componentes Clientes Os componentes clientes so executados na mquina cliente de uma aplicao Java EE. Esses componentes podem ser devidos em dois tipos: os clientes web e os aplicativos clientes. Os clientes web so compostos pelo web browser que recebe informaes do servidor utilizando tecnologias como HTML e XML. Desse modo, pode-se identificar que eles so relativamente simples, pois todo o processamento fica a cargo do servidor Java EE. Os aplicativos clientes so mais complexos que os clientes web, pois eles utilizam diversos recursos fornecidos pela linguagem de programao Java. Normalmente, eles fornecem uma interface grfica para o usurio e tratam de uma maior quantidade de informaes. 2.2.2. Componentes Web Os componentes web so entidades de software que processam requisies de clientes e dinamicamente constroem uma resposta. Eles podem ser classificados em servlets ou pginas web desenvolvidas com a tecnologia JSP. Os servlets so classes Java que executam em um servidor Java EE e tm como objetivo processar requisies dos clientes. Os JSPs so similares a pginas web simples; entretanto eles contm trechos de cdigo Java que representam a lgica de negcios e produzem dinamicamente respostas aos clientes. 2.2.3. Componentes de Negcios Os componentes de negcios so utilizados para o desenvolvimento da lgica de negcios de uma aplicao corporativa. A plataforma Java EE propem a arquitetura Enterprise JavaBeans para a simplificao do desenvolvimento dessa camada. Essa arquitetura ser estudada ao longo dos prximos captulos.

2.3. Contineres Java EE


A utilizao de componentes na plataforma Java EE est associada ao uso dos contineres (FIGURA 2.2). Um continer responsvel por criar um ambiente de execuo para os componentes, sendo assim a interface entre um componente e servios fornecidos pela plataforma que suportam o componente [SUN 06a]. Alm disso, a

16 definio dos contratos entre os componentes e os contineres realizada pela especificao Java EE garante a portabilidade de componentes entre diferentes implementaes de um tipo de continer.

FIGURA 2.2 Servidor Java EE e Contineres 2.3.1. Continer de Clientes Os componentes clientes so instalados e executados no continer de clientes. Esse tipo de continer responsvel por gerenciar a execuo dos componentes no cliente e fornece uma srie de servios que permitem o acesso ao servidor Java EE, uso de web services e gerncia de persistncia. 2.3.2. Continer de Web O continer de web responsvel por gerenciar a execuo dos componentes web no servidor Java EE. Alm dos servios padres oferecidos pelo continer, ele oferece servios adicionais para o tratamento de requisies e respostas aos clientes. Entre os servios para transmisso de informaes, destaca-se a possibilidade de utilizao do protocolo padro HTTP e o protocolo seguro HTTPS. 2.3.3. Continer de EJB O continer de EJB responsvel por gerenciar a execuo dos componentes Enterprise Beans que fazem parte da arquitetura Enterprise JavaBeans. Alm disso, segundo Roman, ele prov os servios necessrios para que os clientes possam se conectar aos componentes, para a coordenao do processamento transacional, para prover persistncia e gerenciar o ciclo de vida desses componentes [ROM 05].

2.4. Servios
Os servios fornecidos pela plataforma Java EE utilizam uma srie de tecnologias essenciais para a reduo de complexidade de desenvolvimento: Java Transaction API: responsvel pelo gerenciamento de transaes; JDBC API: responsvel pela conectividade com banco de dados relacionais;

17 Java Persistence API: responsvel pelo gerenciamento de persistncia objeto/relacional; Java Naming and Directory Interface API: responsvel pelo acesso de informaes usando servios de nomes e diretrios; Java Message Service API: responsvel pelo acesso para o envio e recebimento de informaes usando sistemas de mensagens.

2.5. Comunicao e Interoperabilidade


A comunicao entre componentes Java EE realizada atravs de servios de comunicao definidos pelo Java em conjunto com protocolos de comunicao de uso corrente (TABELA 2.1). Essa abordagem visa manter a reusabilidade dessas entidades. Alm disso, a plataforma Java EE fornece uma srie de servios que garantem a interoperabilidade com outros tipos de componentes no pertencentes plataforma Java EE, por exemplo: web services e objetos CORBA. TABELA 2.1 Servios e Protocolos na plataforma Java EE Servio Java IDL Networking Protocolos Utilizados IIOP HTTP/HTTPS Objetivo Permitir o acesso a objetos CORBA. Permitir a comunicao entre componentes usando protocolos que no so frequentemente bloqueados por firewalls. Permitir o acesso a componentes de diferentes linguagens definidos no formato RMI usando o protocolo IIOP. Permitir o acesso a componentes Java definidos no formato RMI usando o protocolo JRMP.

RMI-IIOP

IIOP

RMI-JRMP

JRMP

18

3. Enterprise JavaBeans, verso 2.1


A especificao Enterprise JavaBeans um elemento complementar da especificao Java Enterprise Edition. Assim como no Java EE, essa especificao foi desenvolvida com o objetivo de permitir a utilizao da abordagem baseada em componentes na camada de negcios de uma aplicao corporativa, visando simplificar o desenvolvimento dessa camada. Mais especificamente, a especificao EJB define os requisitos necessrios para o desenvolvimento de aplicaes capazes de gerenciar os componentes EJB (Servidor/Continer EJB) e aplicaes que utilizam os recursos da arquitetura EJB. Nesse captulo so explanados os principais conceitos que compem a arquitetura EJB e os trs tipos de componentes propostos para o desenvolvimento da camada de negcios so apresentados. Esses componentes so denominados de session beans, message-driven beans e entity beans.

3.1. Arquitetura EJB


A arquitetura EJB 2.1, como exemplificado na FIGURA 3.1, foi organizada em quatro elementos principais que combinados permitem a utilizao de todos os recursos providos pela tecnologia EJB: Enterprise Bean, Continer de EJB, Servidor de EJB e clientes. Essa arquitetura tem por objetivo reduzir a complexidade para o desenvolvedor de EJB, para isso, torna-se necessrio a utilizao implcita de middleware.

FIGURA 3.1 Arquitetura EJB, verso 2.1 3.1.1. Enterprise Beans A base dos componentes EJB so os objetos distribudos, ou seja, objetos que podem ser utilizados por sistemas remotos. Esses objetos so interessantes por permitirem a distribuio de uma aplicao entre diversos pontos, fator que pode facilitar a gerncia de grandes aplicaes. Entretanto, a utilizao de objetos distribudos demanda o uso de middlewares que fornecem servios como gerncia de transaes distribudas ou mecanismos de segurana.

19 O uso de middleware, no modelo de programao distribuda tradicional, feito de maneira explcita, ou seja, o desenvolvedor deve fazer chamadas especficas a sua API. Esse modo de utilizao explcito torna complexa a manuteno do cdigo e no garante independncia em relao ao provedor de middleware. Devido s desvantagens existentes no uso explcito, arquiteturas baseadas em componentes passam a utiliz-lo de maneira implcita. Essa abordagem permite que o desenvolvedor construa a lgica de negcios dos componentes e declare, por exemplo, via arquivos descritores, os servios middleware necessrios para os componentes. Isso facilita o desenvolvimento dos componentes, pois elimina a necessidade de conhecimento da API do middleware utilizado e evita a mescla de cdigo lgico com o cdigo para utilizao de servios, fator que incrementa o grau de manutenibilidade desses componentes. Os componentes Enterprise Beans so compostos pelas seguintes entidades: Classe do Bean: contm a lgica do componente desenvolvida pelo bean provider, essa classe deve implementar interfaces especficas para os diferentes tipos de beans existentes na especificao EJB. Qualquer mtodo deve suportar o lanamento da exceo java.rmi.RemoteException por serem mtodos remotos; Objeto EJBObject: esse objeto construdo pelo servidor EJB para cada Enterprise Bean. Ela encapsula toda lgica de acesso necessria para o uso de servios do middleware evitando que o desenvolvedor deva se preocupar com essa lgica. O acesso aos Enterprise Beans pelos clientes feito atravs desse objeto, ou seja, o acesso pelos clientes feito de maneira indireta, pois o cliente no utiliza diretamente um objeto do bean, mas o EJBObject criado pelo servidor de EJB; Interface Remote: essa interface necessria para permitir que a ferramenta geradora do EJBObject possa incluir todos os mtodos de negcios definidos na classe do Bean. Essa interface deve ser derivada de uma interface chamada javax.ejb.EJBObject, esta ltima contm a assinatura de mtodos que sero gerados automaticamente pelo continer de EJB. Esses mtodos so utilizados pelo continer EJB para o gerenciamento das instncias do componente; Interface Remote Home: essa interface responsvel por definir quais so os modos de criao, destruio e localizao do componente. Ela torna-se necessria devido ao modo indireto de acesso aos Enterprise Beans, esse tipo de acesso requer o fornecimento dessas informaes ao continer e isso feito atravs dessa interface.

Alm dessas quatro entidades, opcionalmente, um Enterprise Bean pode definir as interfaces Local Home e Local, essas interfaces permitem a eliminao do overhead de utilizao de objetos remotos quando o cliente e o Enterprise Bean esto localizados na mesma mquina virtual Java. 3.1.2. Continer de EJB O continer responsvel por gerenciar todos os aspectos dos Enterprise Beans, incluindo transaes, concorrncia, segurana, acesso aos recursos e, inclusive, o acesso ao componente. O modo de acesso indireto a esse tipo de componente provido pelo continer de EJB essencial para a utilizao implcita de middleware.

20 O modo de acesso indireto permite que o continer encapsule toda lgica de utilizao de middleware em objetos transparentes aos clientes. Os clientes utilizam os mtodos fornecidos pela interface Home de um Enterprise Bean e o continer gerencia o acesso atravs do objeto EJBObject. 3.1.3. Servidor de EJB O servidor EJB responsvel por implementar todos os mecanismos necessrios para o suporte de transaes distribudas, segurana, persistncia, gerncia eficiente de memria e fornecimento simplificado do acesso aos servios utilizados pelos bean providers. Alm disso, os contineres EJB so desenvolvidos utilizando os recursos fornecidos pelo servidor de EJB. 3.1.4. Clientes Os clientes podem ser representados por aplicaes Java tradicionais, aplicaes Web ou qualquer outro tipo de aplicao que suporte o acesso a aplicaes EJB. Os clientes, conforme descrito anteriormente, invocam um Enterprise Bean atravs da interface Home e acessam os mtodos de negcios atravs da interface Remote. Alm disso, os clientes utilizam o servio de nomes JNDI para encontrar os Enterprise Beans.

3.2. EJB Roles


O termo role ou papel foi incorporado da abordagem de desenvolvimento baseado em componentes. O objetivo dos roles definir as responsabilidades existentes no processo de desenvolvimento de uma aplicao. No caso do EJB 2.1, existem seis papis envolvidos no processo de desenvolvimento de aplicaes e no ciclo de publicao e execuo de EJBs. 3.2.1. Provedor de Enterprise Beans O provedor de Enterprise Beans corresponde a um desenvolvedor de componentes, ou seja, ele produz componentes publicveis que podem ser combinados para a construo de uma aplicao. 3.2.2. Montador de Aplicao Esse role responsvel por organizar os componentes Enterprise Beans e obter uma aplicao concreta. Em certos casos, pode haver a necessidade do desenvolvimento de novos componentes para a integrao de outros componentes. 3.2.3. EJB Deployer O EJB Deployer responsvel por configurar as aplicaes geradas pelo montador de aplicao. Aps as configuraes necessrias, por exemplo, integrar com o sistema de segurana da empresa, o EJB Deployer pode publicar as aplicaes em um ambiente operacional. Esse ambiente operacional fornecido pelo provedor de servidor EJB.

21 3.2.4. Provedor de Servidor EJB O provedor de servidor EJB responsvel por construir um servidor EJB que seja capaz de gerenciar as aplicaes que utilizam a arquitetura EJB. Normalmente, esse role corresponde a um desenvolvedor de middleware, por exemplo, o consrcio ObjectWeb. A Sun Microsystems fornece uma ferramenta denominada Compatibility Test Suite que permite verificar se uma implementao das especificaes Java EE e EJB atende aos requisitos mnimos necessrios para o suporte de aplicaes Java EE / EJB. 3.2.5. Provedor de Continer EJB Esse role responsvel por desenvolver um elemento fundamental para a arquitetura EJB, o continer EJB. Esse continer responsvel por criar um ambiente para publicao e execuo de Enterprise Beans. 3.2.6. Administrador de Sistemas O administrador de sistemas responsvel por monitorar o sistema de publicao (deployment) dos Enterprise Beans. Os servidores EJB, freqentemente, fornecem ferramentas que possibilitam uma monitorao detalhada do ambiente de execuo dos Enterprise Beans. A tecnologia Java Management Extesion (JMX) busca definir um padro para a construo de ferramentas de monitorao.

3.3. Componentes Session Bean


Os componentes session bean implementam parte da lgica de negcios utilizada em uma aplicao EJB. O objetivo desses componentes ocultar a complexidade das tarefas de negcios para os clientes, por exemplo, a validao de um nmero de carto de crdito, decodificao de informaes ou simulao de um carrinho de compras. Alm disso, esses componentes fornecem a abstrao de sesso para os clientes, pois uma instncia de um session bean no pode ser compartilhada entre diversos clientes. Esse tipo de componente usado como meio de acesso a uma aplicao Enterprise Bean, deve ser ressaltado o fato que esses componentes no so persistentes, ou seja, se ocorrer um problema com o servidor de EJB, o estado no momento anterior a falha no poder ser recuperado. Entretanto, mesmo no sendo persistentes, os session beans podem participar de transaes e realizar operaes em banco de dados. A classificao dos componentes session beans define dois subtipos desses componentes: os stateless session beans e os stateful session beans. A principal diferena entre esses dois subtipos est relacionada com a manuteno do estado de uma sesso do cliente. Os stateless no mantm informaes sobre o estado da sesso entre a invocao de diferentes mtodos de uma mesma instncia desse tipo de componente; entretanto, os stateful possuem a capacidade de armazenar o estado da sesso de um cliente, por exemplo, um carrinho de compras de uma loja virtual. 3.3.1. Stateless Session Beans Os stateless session beans so utilizados no caso de operaes que no necessitam a manuteno de estado entre a invocao de diferentes mtodos de uma instncia de um

22 session bean. Alm disso, por no serem necessrias as operaes para manuteno de estado entre diferentes invocaes de mtodos, os stateless apresentam um melhor desempenho em relaes aos stateful. O ciclo de vida de uma stateless, conforme a FIGURA 3.2, composto por dois estados. O primeiro estado chamado de does not exist, ou seja, o estado no qual no existe a instncia do session bean. O segundo estado chamado de method - ready pool, ou seja, o estado no qual o componente est pronto para atender a requisies do cliente. O ciclo de vida de um stateless organizado nas seguintes etapas: O continer invoca uma nova instncia do session bean atravs do mtodo newInstance(). Em seguida, o continer deve chamar o mtodo setSessionContext(arg) definido na classe do stateless e o mtodo ejbCreate(). O mtodo setSessionContext define a varivel de sesso que fornece o acesso a diversos recursos fornecidos pelo continer ao stateless; Aps a concluso da etapa anterior, o stateless est pronto para atender a requisies dos clientes ou a chamada pelo continer do mtodo ejbTimeout(arg). Esse mtodo utilizado quando servios de Timer fornecidos pela plataforma Java EE so utilizados; O ciclo de vida de um stateless finalizado quando o continer, no necessita mais de uma instncia e invoca o mtodo ejbRemove().

FIGURA 3.2 Ciclo de vida de um stateless session bean(Fonte [SUN 03]) 3.3.2. Stateful Session Beans Os stateful session beans, em oposio aos stateless, apresentam a capacidade de manter informaes sobre o estado de uma sesso entre diferentes invocaes de mtodos de uma instncia. O uso desse tipo voltado para a realizao de mediao entre o cliente e outros componentes do sistema; isso possibilita simplificar a viso do cliente sobre os outros componentes, por exemplo, o acesso aos entity beans. Alm disso, eles podem ser responsveis por gerenciar uma srie de outros componentes simultaneamente, fator que reduz a complexidade para o lado do cliente.

23 O ciclo de vida de um stateful, conforme a FIGURA 3.3, relativamente mais complexo que o ciclo de vida um stateless. O primeiro estado chamado de does not exist, ou seja, o estado no qual a instncia no existe. O segundo estado e terceiro estados so chamados respectivamente de method ready e method ready in TX, a diferena entre eles refere-se a existncia de um contexto transacional, sendo que o primeiro no apresenta um contexto transacional, mas o segundo apresenta. O ciclo de vida de um stateful pode ser descrito nas seguintes etapas: O continer invoca uma nova instncia do session bean atravs do mtodo newInstance(). Em seguida, o continer deve chamar o mtodo setSessionContext(arg) presente na instncia do componente e um dos mtodos ejbCreate<METHOD>(args), conforme a requisio do cliente via create<METHOD>(args). Destaca-se que <METHOD> um nome definido pelo bean provider; Aps a execuo das tarefas descritas no passo anterior, o bean est pronto para atender ao cliente. Conforme atributos de transao, o mtodo pode ser transacional ou no; No mtodo no transacional, a invocao causa diretamente a execuo desse mtodo de negcios; No mtodo transacional, antes da invocao de qualquer mtodo de negcios transacionais, o continer ir invocar o mtodo afterBegin(). Nesse ponto, a instncia do bean associada com uma transao e ser desassociada somente quando a transao for finalizada; Quando um commit solicitado para a transao, o continer invoca o mtodo beforeCompletion(). Aps, o servio de gerncia de transaes tenta realizar o commit efetivo, podendo ocorrer o commit ou o rollback em caso de erro. Aps a resposta do servio de gerncia de transaes sobre o commit, o mtodo afterCompletion(true) executado em caso de sucesso no commit, em caso de rollback, o mtodo executado como afterCompletion(false); Durante a utilizao desse tipo de componente, o continer pode identificar a necessidade de remover uma instncia da memria principal e ento lev-la para o estado passivate. A seleo de quem ser escolhido para o passivate feita atravs do algoritmo LRU (Least Recently Used). Aps a escolha, o continer executa o mtodo ejbPassivate() e salva a instncia em um sistema de armazenamento secundrio; Se o cliente invocar uma instncia no estado passivate, o continer restaura a instncia e invoca o mtodo ejbActivate(); Se o cliente invocar o mtodo remove solicitando a remoo de uma instncia, o continer invoca o mtodo ejbRemove() da instncia e finaliza o ciclo de vida. Alm disso, uma exceo em algum mtodo de um stateful, assim como o timeout no estado passivate tambm ocasiona o fim do ciclo de vida de um stateful.

24

FIGURA 3.3 Ciclo de vida de um stateful session bean (Fonte [SUN 03]) 3.3.3. Exigncias no Desenvolvimento de Session Beans O ciclo de vida dos session relativamente simples; entretanto, essa verso da especificao exige uma srie de obrigaes para o bean provider, fator que aumenta significativamente a complexidade de desenvolvimento desses componentes. As principais exigncias so descritas nesse tpico. A classe do session bean contm os mtodos de negcios e deve diretamente ou indiretamente implementar a interface javax.ejb.SessionBean. Alm disso, essa classe implementa os mtodos prefixados com ejbCreate, esses mtodos representam os mtodos usados pelos clientes para invocar uma instncia de um session bean e so definidos na interface Remote Home. O prefixo ejbCreate obrigatrio para cada mtodo que implementa os mtodos prefixados com create na interface Remote Home; A interface Remote deve obrigatoriamente estender a interface javax.ejb.EJBObject. Qualquer mtodo definido nela deve suportar o lanamento da exceo java.rmi.RemoteException, pois os sessions so objetos distribudos Java; A interface Remote Home deve obrigatoriamente estender a interface javax.ejb.EJBHome. Todos os mtodos definidos nessa interface, assim como os definidos pela interface Remote devem suportar o lanamento da exceo

25 java.rmi.RemoteException. Essa interface obrigatoriamente deve definir, no mnimo, um mtodo prefixado como create e esse mtodo deve corresponder a um mtodo prefixado como ejbCreate desenvolvido na classe do bean. A exceo javax.ejb.CreateException deve ser obrigatoriamente adiciona as possveis excees dos mtodos create; A interface Local deve estender a interface javax.ejb.EJBLocalObject e qualquer mtodo declarado nessa interface no deve lanar a exceo java.rmi.RemoteException, pois a chamada a esses mtodos deixa de ser remota quando o bean usado localmente. As demais regras existentes na interface Remote permanecem vlidas; A interface Local Home deve estender a interface javax.EJB.EJBLocalHome e qualquer mtodo declarado nessa interface no deve lanar a exceo java.rmi.RemoteException. As demais regras existentes na interface Remote Home permanecem vlidas.

Conforme identificado acima, existe uma quantidade acentuada de exigncias. Isso torna relevante a simplificao e eliminao de algumas exigncias para a prxima verso da especificao EJB. A comparao entre as duas verses ser feita no prximo captulo.

3.4. Componentes Message-Driven Bean


Os componentes do tipo message-driven bean foram especificados para possibilitar o tratamento de mensagens assncronas em aplicaes EJB. Desse modo, esses componentes servem como listeners de mensagens provenientes de diferentes origens, por exemplo, um cliente EJB ou outro componente. Os message-driven beans apresentam algumas caractersticas em comum com os stateless session beans. Destacam-se as caractersticas deles no serem persistentes, nem armazenarem dados ou estados referentes a um cliente especfico, ou seja, diferentes instncias de um message-driven bean so equivalentes e podem atender a mltiplos clientes. Apesar de no armazenarem dados especficos a um cliente, eles podem manter algumas informaes durante o atendimento de mensagens, por exemplo, uma conexo a um banco de dados ou a referncia a um outro objeto EJB. O ciclo de vida desses componentes indica outra semelhana aos stateless, pois, assim como os stateless, os message-driven, conforme a FIGURA 2.1, apresentam apenas dois estados. O primeiro estado chamado de does not exist, ou seja, o estado no qual no existe a instncia do componente. O segundo estado chamado de method-ready pool, ou seja, o estado no qual o componente est pronto para tratar mensagens destinadas a esse tipo de message-driven. O ciclo de vida de um stateless pode ser descrito nas seguintes etapas: O continer invoca uma nova instncia do message-driven atravs do mtodo newInstance(). Em seguida, o continer deve chamar o mtodo setMessageDrivenContext(mdc) definido na classe do componente e o mtodo ejbCreate(). O mtodo setMessageDrivenContext define a varivel de sesso que fornece o acesso a diversos recursos fornecidos pelo continer a esse tipo de componente;

26 Aps a concluso da etapa anterior, o message-driven est pronto para atender a mensagens ou a chamada pelo continer do mtodo ejbTimeout(arg). Este mtodo invocado quando timers associados ao componente expiram sua contagem, esse recurso til para processos de negcios de longo prazo; O ciclo de vida de um message-driven finalizado quando o continer no necessita mais de uma instncia e invoca o mtodo ejbRemove().

FIGURA 3.4 Ciclo de vida de um message-driven bean (Fonte [SUN 03]) 3.4.1. Exigncias no Desenvolvimento de Message-Driven Beans Os componentes do tipo message-driven, apesar de serem semelhantes aos stateless, no necessitam obrigatoriamente de uma interface desenvolvida pelo bean provider. Eles exigem apenas o desenvolvimento da classe do componente. Essa classe, entretanto, deve obrigatoriamente implementar duas interfaces: javax.ejb.MessageDrivenBean que define mtodos usados pelo continer; a interface message listener requerida pelo tipo de mensagem que ele suporta. Na plataforma Java, o servio de mensagens fornecido se chama JMS e a interface disponibilizada por ele denominada javax.jms.MessageListener.

Alm dessas exigncias, a classe do componente deve obrigatoriamente implementar o mtodo ejbCreate() chamado pelo continer.

3.5. Componentes Entity Bean


Os componentes entity beans foram concebidos para representar objetos de negcios de modo persistente, mais especificamente, informaes armazenadas em banco de dados relacionais. A necessidade de persistncia est relacionada com a importncia de garantir o armazenamento de informaes relacionadas com a camada de negcios da aplicao, por exemplo, uma aplicao de um banco monetrio, torna obrigatrio o armazenamento das contas dos clientes e o saldo de cada uma de maneira persistente.

27 Os entity beans diferenciam-se dos session beans por permitirem acesso compartilhado, apresentarem chave primria, participarem de relacionamentos com outros entity beans e, principalmente, por serem persistentes [ROM 05]. O acesso compartilhado importante para esses objetos, pois, como citado anteriormente, eles podem representar contas de clientes de um banco monetrio. Nesse caso, diversos funcionrios do banco podem necessitar acessar simultaneamente essas informaes. Para permitir o acesso compartilhado, o servidor EJB responsvel pela gerncia transacional e deve possuir mecanismos que evitem inconsistncia de informao. Estados de inconsistncia podem ocorrer devido a presena de diversas instncias de uma mesmo entity podem estar na memria principal. A chave primria de um entity um identificador nico que permite a localizao desses objetos pelos clientes. No caso de um entity representando uma linha de uma tabela de um banco de dados relacional, o valor da chave primria do componente pode ser o valor da chave-primria da linha da tabela representada. A possibilidade de definir relacionamento entre entities aumenta a capacidade de representao de informao por estes componentes. Essa caracterstica fundamental para permitir a representao de banco de dados relacionais por estes componentes. A persistncia desses componentes indica que o ciclo de vida deles no est relacionado ao ciclo de vida do cliente ou ao ciclo de vida do servidor EJB. Isso significa que a ocorrncia de problemas no cliente ou no servidor no influencia na existncia desses objetos, pois eles so armazenados em um sistema persistente. Alm disso, a persistncia para esses componentes, nessa verso da especificao, classificada em dois tipos: bean-managed e container-managed. A principal diferena entre os dois tipos est relacionada com a maneira como gerenciado o acesso ao banco de dados. No primeiro tipo, o desenvolvedor responsvel por codificar todos os acessos necessrios para a garantia de persistncia. No segundo tipo, com a ajuda de descritores XML fornecidos pelo desenvolvedor, o continer responsvel pela gerao do cdigo necessrio para o acesso ao banco de dados e a garantia de persistncia. Na verso 2.1, no existe uma definio de qual tipo de mecanismo de persistncia deve ser utilizado, ou seja, pode-se utilizar a serializao de objetos Java ou mapeamento objeto/relacional. A prxima verso da especificao passa a definir regras de mapeamento objeto/relacional que facilitam a utilizao de mecanismos de persistncia como o Hibernate e TopLink. 3.5.1. Bean-Managed Entity Beans (BMP) Esse tipo de entity caracterizado pela responsabilidade do desenvolvedor na codificao das chamadas a banco de dados necessrias para a gerncia de persistncia. Em razo da necessidade de codificao do acesso ao banco de dados, esse tipo tende a ser menos portvel que o tipo container-managed, pois mesmo com o padro SQL 2 existe a necessidade de utilizao de comandos especficos para um determinado sistema gerenciador de banco de dados. A portabilidade desses componentes pode ser facilitada pela delegao de chamadas aos SGBD a outros componentes que encapsulam esses acessos. Apesar da menor

28 portabilidade desse tipo de componente, destaca-se a possibilidade de aumentar o desempenho deles com a utilizao de recursos fornecidos por um SGBD especfico. O ciclo de vida desse tipo de componente divido em trs estados (FIGURA 3.5). O estado does not exist indica que a instncia de um entity no existe. O segundo estado, pooled, indica que o continer criou uma instncia, mas ainda no associou com uma determinada identidade, ou seja, ele ainda no representa uma informao de um meio persistente. O terceiro estado, ready, indica que o entity foi associado a uma determinada identidade e est pronto para ser utilizado pelo cliente. O ciclo de vida de um bean-managed entity bean pode ser descrito nas seguintes etapas: O continer invoca uma nova instncia do entity atravs do mtodo newInstance(). Em seguida, o continer deve chamar o mtodo setEntityContext(ec) definido na classe do componente. Esse mtodo define a varivel de sesso que fornece o acesso a diversos recursos fornecidos pelo continer a esse tipo de componente; Aps a execuo dos mtodos descritos no tpico anterior, a instncia passa ao estado polled. Nesse estado todas as instncias so consideradas idnticas, pois elas no esto associadas a nenhuma identidade, ou seja, no esto associadas a informaes de um banco de dados. Nesse estado os mtodos iniciados por ejbHome e ejbFind podem ser invocados; Uma instncia pode transitar ao estado ready de duas maneiras. A primeira maneira iniciada pela invocao de um mtodo iniciado por create, essa chamada causa a invocao dos mtodos iniciados por ejbCreate e ejbPostCreate referentes ao mtodo create invocado pelo cliente. Aps a invocao desses mtodos, a instncia associada a uma determinada informao. A segunda maneira ocorre atravs da chamada, pelo continer, do mtodo ejbActivate(), esse mtodo realiza operaes necessrias para ativar um entity, ou seja, a recuperao de informao de um meio secundrio para a memria principal; No estado ready, os mtodos de negcios podem ser invocados n vezes pelos clientes. O mtodo ejbTimeout(args) invocado n vezes pelo continer e est relacionado ao servio de timer fornecido pela plataforma Java. Os mtodos ejbLoad() e ejbStore() so invocados pelo continer e tem o objetivo de manter sincronizada as informaes da memria principal com as informaes das fontes de dados; O continer pode necessitar transitar o estado de uma instncia para pooled novamente. A primeira opo a chamada pelo continer do mtodo ejbPasstivate(), esse mtodo desassocia a instncia de uma identidade, mas no remove essa instncia. A segunda opo atravs da chamada do mtodo ejbRemove(), esse mtodo pode ser chamado pelo continer devido a disponibilidade da memria principal ou em razo da chamada de um mtodo remove pelo cliente. A terceira opo est relacionada a um rollback da transio na qual a instncia est associada, caso essa operao ocorra, a instncia levada para o estado pooled.

29

FIGURA 3.5 Ciclo de vida de um bean-managed entity bean (Fonte [SUN 03]) 3.5.2. Exigncias no Desenvolvimento de Bean-Managed Entity Beans Esse tipo de componente apresenta diversas exigncias para o bean provider. Essas exigncias so fortemente criticadas em razo do aumento de complexidade para utilizao desses componentes e impossibilidade de utilizao de caractersticas importantes da orientao a objetos, por exemplo, polimorfismo. As principais exigncias so as seguintes: A classe do entity deve obrigatoriamente estender a interface javax.ejb.EntityBean e implementar os mtodos iniciados por ejbCreate, ejbPostCreate, ejbFind e ejbHome. Alm disso, ela deve conter um construtor sem argumentos que ser utilizado pelo continer; Os mtodos iniciados por ejbCreate e ejbPostCreate devem ter sua assinatura corresponde aos iniciados por create que so definidos na interface Remote Home; Os mtodos de localizao devem ser obrigatoriamente iniciados por ejbFind e corresponderam a um mtodo find descrito na interface Remote Home; Os mtodos iniciados por ejbHome devem corresponder a cada um dos mtodo home definidos nas interfaces Remote Home e Local Home; A chave primria de um entity deve ser representada por uma classe, o tipo deve ser vlido para o protocolo RMI-IIOP; A interface Remote deve estender a interface javax.ejb.EJBObject e todos os mtodos definidos nessa interface devem seguir as regras para o RMI-IIOP, ou seja, devem usar parmetros vlidos para esse protocolo e devem permitir o lanamento da exceo java.rmi.RemoteException. Como citado anteriormente,

30 todos os mtodo definidos nessa interface devem apresentar uma implementao correspondente na classe do entity; A interface Remote Home deve estender a interface javax.ejb.EJBHome e somente pode definir mtodos de criao, localizao e home. A assinatura desses mtodos deve corresponder com a assinatura a ser implementada na classe do entity; A interface Local deve estender a interface javax.ejb.EJBLocalObject e no deve ser adicionada a exceo java.rmi.RemoteException aos mtodos declarados nessa interface, pois a chamada a esses mtodos deixa de ser remota quando o bean usado localmente. As demais regras existentes na interface Remote permanecem vlidas; A interface Local Home deve estender a interface javax.EJB.EJBLocalHome e no deve ser adicionada a exceo java.rmi.RemoteException aos mtodos declarados nessa interface. As demais regras existentes na interface Remote Home permanecem vlidas.

3.5.3. Conteiner-Managed Entity Beans (CMP) Esse tipo de entity visa eliminar a necessidade de desenvolvimento do cdigo relacionado ao acesso a fonte dados utilizada pelo entity bean. Essa caracterstica interessante por permitir o desenvolvimento de componentes reutilizveis em diferentes fontes de dados. Para permitir que o continer realize a gerao automtica do cdigo necessrio para o acesso a fontes de dados, a especificao cria o conceito de esquema abstrato dos entity beans. Esse esquema, descrito via arquivos XML, identifica os campos persistentes de um entity e define o relacionamento entre os mesmos. A desvantagem de utilizao desse tipo de entity a existncia de arquivos XML que so fortemente suscetveis a erros e exigem a descrio de uma grande quantidade de informaes que podem ser testadas somente em tempo de execuo. O ciclo de vida desse tipo semelhante ao do tipo bean-managed, a principal diferena est relacionada com a adio de mtodos do tipo select. O objetivo desses mtodos permitir a seleo de informaes atravs da linguagem EJB QL que ser descrita ao longo desse captulo. A tabela TABELA 3.1 indica as principais diferenas entre os mtodos finder and select. TABELA 3.1 Comparao entre mtodos find e select Assinatura do Mtodo Visibilidade Estado da instncia Valor de sada Mtodos Finder find<Nome> Visvel ao cliente Estado pooled em qualquer instncia EJBObjects ou EJBLocalObjects do mesmo tipo do entity utilizado para a chamada do find<Nome> Mtodos Select ejbSelect<Nome> Interno a classe do bean Especfico a uma instncia no estado pooled ou ready EJBObjects, EJBLocalObjects ou qualquer tipo de campo CMP

31 3.5.4. Exigncias no Desenvolvimento de Container - Managed Entity Beans As exigncias para o desenvolvimento desse tipo de componente so as mesmas dos componentes do tipo bean-managed. Destaca-se a eliminao de codificao de mtodos para acesso a fonte de dados. 3.5.5. EJB QL A linguagem EJB QL tem um papel fundamental para a utilizao do tipo CMP, pois atravs dela que consultas so definidas nesse modelo e a navegao entre os relacionamentos entre os entities realizada. Ela permite a localizao de objetos entities atravs dos mtodos find e, tambm, a localizao de objetos entities ou valores derivados desses objetos atravs dos mtodos select. Essa linguagem utiliza o esquema abstrato definido pelo bean provider para permitir a definio de consultas portveis para diferentes fontes de dados. Alm disso, ela pode ser compilada para a linguagem de consulta da fonte de dados de maneira transparente para o bean provider garantindo a portabilidade. O desenvolvimento dessa linguagem foi fortemente baseado no padro SQL 2, mas apresenta algumas limitaes criticadas pelos desenvolvedores. Por exemplo, no permitida a utilizao de sub-consultas, o uso de bulk updates/deletes e no existe suporte a query nativas que podem ser necessrias em casos especficos.

3.6. Suporte a Transaes


O suporte a transaes distribudas essencial para aplicaes corporativas; entretanto, transaes distribudas apresentam um grau elevado de complexidade. Tendo em vista esse problema, na arquitetura EJB a complexidade de utilizao de transaes distribudas encapsulada atravs de mecanismos providos pelo continer de EJB. Os mecanismos providos pelo continer para os componentes do tipo session bean e message-driven bean compreendem dois tipos de gerncia de demarcao de transaes: container-managed transaction demarcation e bean-managed transaction demarcation. No primeiro tipo, container-managed transaction demarcation, o desenvolvedor necessita apenas indicar quais mtodos do bean sero includos em uma transao. Aps essa etapa o desenvolvedor pode utilizar diferentes fontes de dados sem levar em conta o controle das transaes, pois o continer, de modo transparente, responsvel. No segundo tipo, bean-managed transaction demarcation, o desenvolvedor passa a ser responsvel por identificar a regio de um mtodo que ser includa em uma transao. Para isso, utiliza-se o javax.transaction.UserTransaction que prove mtodos como begin(), commit() e rollback() para gerenciar o uso de transaes. Na regio includa em uma transao, o continer responsvel por gerenciar o acesso a diferentes fontes.

32

4. Enterprise JavaBeans, Verso 3.0, e Comparao com a Verso 2.1


A motivao principal para o desenvolvimento da verso 3.0 da arquitetura EJB est relacionada simplificao para a construo de uma aplicao EJB. Conforme visto no captulo anterior, identificou-se a grande quantidade de exigncias existentes para o desenvolvimento de cada tipo de componente dessa arquitetura. Essa nova verso acompanha as mudanas introduzidas no Java EE 1.5, pois incorpora a utilizao de anotaes de metadados, utiliza conceitos da programao orientada a aspecto, introduz a injeo de recursos, alm de transformar os componentes EJB em objetos POJO e definir uma nova API de persistncia. Nesse captulo so apresentados os novos conceitos incorporados a EJB 3.0 e, principalmente, apresentada a anlise comparativa entre componentes EJB 2.1 e componentes EJB 3.0, na qual so destacadas as principais diferenas entre as duas verses.

4.1. Anotaes de Metadados


As anotaes de metadados, providas pela verso 1.5 da linguagem de programao Java, possuem um papel chave na simplificao do desenvolvimento de componentes EJB 3.0. O objetivo delas fornecer informaes necessrias para que ferramentas especficas possam gerar cdigo fonte automaticamente para o desenvolvedor, evitando o uso de arquivos externos, como, por exemplo, descritores XML amplamente utilizados na verso 2.1. Em suma, esse recurso permite o uso do estilo de programao declarativo no qual o desenvolvedor especifica a anotao e o compilador gera o cdigo necessrio para ela. O ANEXO 1 exemplifica o uso de anotaes de metadados. As anotaes, entretanto, nem sempre indicam a melhor soluo, pois, ao serem utilizadas, ocorre a declarao de configuraes diretamente no cdigo fonte. No caso da necessidade de modificao de uma configurao definida atravs de uma anotao seria necessrio realizar uma nova compilao do cdigo fonte; caso fosse usado um arquivo de configurao externo, isso seria desnecessrio. Devido a esse fato, os arquivos descritores XML continuam vlidos na verso EJB 3.0 e configuraes feitas atravs deles apresentam precedncia em relao a anotaes. O suporte a descritores tambm mantido para garantir a compatibilidade entre as duas verses e permitir uma migrao gradual.

4.2. Programao Orientada a Aspecto


A programao orientada a aspecto (POA) foi desenvolvida pela Xrox e considerada uma complementao da programao orientada a objetos [PAW 04]. Esse novo paradigma busca apresentar solues para problemas existentes na programao orientada a objeto como o fenmeno de disperso de cdigo. A disperso de cdigo pode, por exemplo, ocorrer em uma aplicao que necessita manter um registro de operaes executadas ao longo de sua execuo, nesse caso, o desenvolvedor para cada registro de operao precisa acrescentar um trecho de cdigo para registrar a operao. Na plataforma Java, existem diversos pacotes que podem oferecer esse recurso, entretanto, ao ser utilizado um determinado pacote, a chamada

33 aos mtodos que permitem a realizao do log fica dispersa ao longo de todo o cdigo da aplicao. Essa disperso reduz a manutenibilidade do cdigo, pois caso fosse necessrio mudar de pacote para o suporte de log, seria necessrio modificar a chamada aos mtodos de log existentes em diversas classes da aplicao. Para solucionar o problema de disperso de cdigo, esse paradigma introduz o conceito de aspecto. Conforme [PAW 04], um aspecto uma entidade de software que captura uma funcionalidade transversal uma aplicao. Esse conceito permite a especificao de uma entidade que fornece uma funcionalidade utilizada ao longo de toda a aplicao, evitando que ao ser necessrio uma modificao, toda a aplicao deva ser modificada. Um exemplo de aspecto amplamente utilizado corresponde aos design patterns. A utilizao desses padres conceituais em aplicaes orientadas a objetos evita que uma modificao no mecanismo que prov a funcionalidade exija a modificao de todas as chamadas a esse mecanismo na aplicao. Por exemplo, o design pattern denominada Data Access Object permite encapsular mecanismos de acesso a dados, evitando que a troca de um sistema gerenciador de banco de dados exija modificaes na camada de negcios. Outro conceito importante para esse paradigma chamado de ponto de juno. Conforme [POW 04], um ponto de juno um ponto na execuo de um programa no qual, em torno dele, um ou mais aspectos podem ser adicionados. Os principais pontos de juno utilizados pela POA em uma aplicao so os mtodos, atributos, construtores e excees. O conceito acima utilizado em conjunto com o conceito de cdigo advice. Segundo [POW 04], cdigo advice um bloco de cdigo que define o comportamento de um aspecto. Este ltimo conceito utilizado para a criao das entidades chamadas de interceptors no EJB 3.0. 4.2.1. Interceptors Os interceptors na arquitetura EJB so utilizados para interceptar invocaes de mtodos de negcios e eventos do ciclo de vida de uma instncia de um componente EJB. Esse recurso elimina a obrigao existente na verso 2.1 de implementao de diversos mtodos definidos na interface javax.ejb.SessionBean utilizados pelo continer para gerncia do ciclo de vida de um session bean. Nessa verso diversos tipos de interceptors so adicionados para aumentar o controle do desenvolvedor sobre as operaes realizadas durante o ciclo de vida dos componentes. As anotaes utilizadas para definir esses interceptors, assim como a funo de cada um so apresentadas nos tpicos referentes a cada tipo de componente ao longo desse captulo. Alm disso, a interceptao da chamada de qualquer mtodo de negcios existente em um session ou message-driven bean possvel atravs da anotao @AroundInvoke sobre qualquer mtodo com a assinatura <Nome>( InvocationContext arg) throws Exception existente na classe do componente. A interface InvocationContext padroniza o tipo de objeto passado para os mtodos de interceptao e fornece mtodos para que seja possvel haver trocas de informaes entre diversos interceptors, pois mltiplos interceptors podem ser aplicados em uma classe ou mtodo. Os interceptors podem ser definidos em classes externas do componente EJB. Para isso utiliza-se a anotao @AroundInvoke sobre um mtodo com a assinatura <Nome>(

34 InvocationContext arg) throws Exception na classe externa e, obrigatoriamente, utilizase a anotao @Interceptors na classe do componente para a especificao de qual classe externa apresenta mtodos de interceptao. Esta anotao pode ser aplicada sobre a classe do componente para que todos os mtodos presentes sejam interceptados ou somente nos mtodos que devem sofrer interceptao. A seqncia de execuo de mtodos com interceptors feita da seguinte maneira: primeiro so executados os interceptors aplicados classe do componente, aps so executados os interceptors aplicado ao mtodo chamado e por ltimo o mtodo executado. O encadeamento de execuo entre os interceptors e o mtodo de negcios feito atravs da chamada do mtodo proceed() existente na interface InvocationContext, caso no ocorra a chamada desse mtodo ao longo da interceptao, o mtodo de negcios no ser executado. A figura FIGURA 4.1 apresenta o cdigo fonte para a utilizao de um interceptor sobre um mtodo do EJB bean e ilustra a seqncia de execuo de um mtodo que sofre interceptao. Conforme definido anteriormente, o mtodo pay(double v) deve ser interceptado pela classe StoreTime, pois utilizou-se a anotao @Interceptors sobre a declarao do mtodo. A classe StoreTime reconhecida como um interceptor devido utilizao da anotao @AroundInvoke sobre um mtodo pertencente a ela. Na seqncia de execuo, primeiramente o cliente invoca o mtodo pay(100) do bean, logo aps, antes da execuo efetiva do mtodo pay(100), ocorre a execuo do mtodo runTime pertencente ao interceptor, esse mtodo, ento, invoca o mtodo pay(100) atravs da execuo de ctx.proceed(). Alm disso, ele determina o tempo gasto para a execuo do mtodo do bean. Ressalta-se que para o cliente, a execuo do interceptor ocorre de forma transparente.

FIGURA 4.1 Exemplo de Interceptor

35 4.2.2. Injeo e Declarao de Recursos A injeo de recursos um elemento adicionado especificao EJB 3.0 que permite a injeo de diversos servios providos pelo Java EE sem a necessidade de utilizao de descritores XML necessrios na verso anterior, entre os servios possveis destaca-se conexes a fonte de dados, referncia ao SessionContext ou UserTransaction. Para realizar a injeo de um recurso no ambiente de execuo de um session ou message-driven bean utiliza-se a anotao @Resource sobre um atributo ou um mtodo com nome iniciado por set. Essa anotao suporta a definio de qual o tipo de objeto ser inserido a partir da definio do atributo type, alm de permitir a definio do nome especfico do servio para um determinado servidor Java EE, evitando novamente, a utilizao de arquivos XML. Alm da injeo de servios, possvel, atravs da utilizao da anotao @EJB, disponibilizar um determinado componente EJB em outro componente, inclusive para o uso em um cliente Web ou aplicativo. Esse mecanismo evita a utilizao direta dos mtodos definidos pelo JNDI para a recuperao de um componente EJB, o que torna transparente para o desenvolvedor essa API, pois a ferramenta de interpretao da anotao que responsvel pela gerao de chamadas necessrias para a invocao desses recursos. Essas anotaes tambm podem ser utilizadas para declarar um recurso no ambiente de execuo de um bean. Para isso, necessrio definir as anotaes sobre a classe de um bean e, dessa forma, elimina-se a necessidade de utilizar os descritores XML para definir quais so os recursos utilizados em um bean. Deve-se ressaltar que se houver a necessidade de declarao de mltiplos recursos, utilizam-se as anotaes @Resources e @EJBs.

4.3. Conceito POJO


Os componentes EJB na verso 2.1, apesar de serem construdos como classes Java, exigem uma srie de interfaces e normas para a definio de mtodos desses componentes. Na verso 3.0, a identificao da necessidade de simplificao dos componentes EJB provocou a transformao dos componentes EJB em Plain Old Java Objects(POJO) [PAN 06]. Esse conceito indica que os session, message-driven e entity beans passam a ser desenvolvidos como objetos simples da linguagem de programao Java. Na verso 3.0, o desenvolvedor passa utilizar os recursos de anotaes para identificar certas configuraes necessrias para esses componentes e as ferramentas de interpretao de anotaes passam a gerar o cdigo necessrio para essas configuraes. As mudanas para o desenvolvimento de cada tipo de componente EJB sero explicadas ao longo desse captulo.

4.4. EJB Roles


A verso 3.0 da especificao adiciona um novo role para o padro EJB em comparao verso 2.1. Esse novo role, chamado de Provedor de Persistncia conseqncia do novo modelo de persistncia descrito no tpico anterior, pois passa a ser necessrio definir o responsvel por prover o ambiente de execuo transacional que possibilite a gerncia de persistncia. A FIGURA 4.2 apresenta a relao entre os roles e o novo role acrescentado na verso 3.0.

36 O provedor de persistncia uma ferramenta capaz de gerenciar o mapeamento objeto/relacional entre os entity beans e os bancos de dados, fator essencial para o novo modelo de persistncia. Alm disso, como citado anteriormente, essa ferramenta deve ser capaz de criar um ambiente transacional que gerencia a persistncia. Devido a flexibilidade do modelo de persistncia, possvel utilizar ferramentas como o Hibernate e o TopLink. Os demais roles mantm suas responsabilidades definidas na verso 2.1.

FIGURA 4.2 Relaes entre os "EJB Roles"

4.5. Componentes Session Bean


Os componentes session beans na verso 3.0 mantm as funes definidas na verso 2.1. A principais mudanas em relao a verso 2.1 esto relacionadas ao modo de construo desses componentes e a alterao no ciclo de vida desses componentes, reduzindo-se o nmero de obrigaes para o bean provider. Alm disso, destaca-se o suporte a injeo e declarao de dependncias nesses componentes. Esses componentes permanecem sendo classificados em dois tipos: os stateless session beans e os stateful session beans. 4.5.1. Stateless Session Beans Os componentes do tipo stateless session bean mantm os mesmos objetivos da verso anterior. A principal novidade nesses componentes refere-se eliminao da necessidade de implementar as interfaces javax.ejb.EJBHome, javax.ejb.EJBLocalHome, javax.ejb.EJBObject e javax.ejb.EJBLocalObject. Alm disso, evita-se a declarao de mtodos desnecessrios devido ao carter facultativo de todos os mtodos de callback. A anlise da FIGURA 4.3 do EJB 3.0, em comparao FIGURA 3.2 do EJB 2.1, revela que os estados desse tipo de componente permanecem os mesmos; entretanto, diversos processos ocorrem somente se forem definidos. Isso ressalta outra

37 caracterstica dessa nova verso, na qual, a configurao dos componentes feita por exceo, ou seja, no caso do componente necessitar de determinados mtodos de ciclo de vida, eles so implementados, caso contrrio, no h necessidade do desenvolvedor tratar desses mtodos. As seguintes etapas descrevem detalhadamente o ciclo de vida desses componentes na verso 3.0: O continer cria uma nova instncia do session bean atravs do mtodo newInstance(). A criao ocorre para atender invocao do componente pelo cliente ou para inserir a instncia no pool (quando o servidor EJB apresenta essa otimizao). No segundo passo, se existir a necessidade de injeo, o continer deve injetar esses recursos. No terceiro passo, mtodos de callback definidos atravs da anotao @PostConstruct so executados aps a injeo de recursos. Caso haja alguma exceo na execuo desses mtodos, a instncia descartada; Aps a concluso da etapa anterior, o stateless passa ao estado method-ready pool, no qual est pronto para atender a requisies dos clientes ou chamada pelo continer do mtodo ejbTimeout(arg). Este mtodo invocado quando timers associados ao componente expiram sua contagem, esse recurso til para processos de negcios de longo prazo; O encerramento do ciclo de vida desses componentes ocorre quando o continer no necessita mais da instncia (normalmente para gerncia de memria). A principal diferena em relao verso 2.1 est relacionada com invocao pelo continer de mtodos de callback anotados com @PreDestroy. Esses mtodos so invocados automaticamente antes da destruio da instncia do componente. Eles so teis para realizar o fechamento de conexes a recursos disponibilizados pelo Java EE, fato que possibilita um melhor gerenciamento de recursos.

FIGURA 4.3 Ciclo de vida de um stateless session bean, EJB 3.0 4.5.2. Stateful Session Beans Os componentes stateful session beans de forma anloga aos stateless mantm os mesmos objetivos da verso 2.1. As diferenas esto relacionadas capacidade de serem alvos de injeo e no necessitarem implementar a interface

38 javax.ejb.SessionBean. Alm disso, todos os mtodos responsveis por gerenciar o ciclo de vida desses componentes passam a ser opcionais. O carter facultativo de diversos mtodos de ciclo de vida e o uso de anotaes exigiram alteraes no ciclo de vida desses componentes em relao verso 2.1, conforme a FIGURA 3.3 e a FIGURA 4.4. Os seguintes passos descrevem o ciclo de vida desses componentes para a verso 3.0: O primeiro estado, no qual a instncia do componente no existe, permanece sendo chamado de does not exist. Para atender a uma solicitao do cliente, o continer deve primeiramente criar uma nova instncia de um componente; a partir desse ponto ocorre a injeo de recursos e a chamada de mtodos de callback anotados com @PostConstruct. Esses mtodos so sempre chamados aps a injeo e antes da execuo de qualquer mtodo de negcios invocado pelo cliente. Alm disso, caso o componente seja desenvolvido para clientes da verso 2.1, os mtodos anotados com @Init ou com a assinatura do tipo ejbCreate<Nome> so invocados. Aps a execuo dos mtodos citados acima, o componente passa do estado does not exist para method ready; No estado method ready, a instncia est pronta para atender a requisies dos clientes. Caso ocorra a chamada de um mtodo sem transao, ele executado e a instncia permanece no mesmo estado. Caso ocorra a chamada de um mtodo que utiliza o servio de transaes e o componente implementar a interface javax.ejb.SessionSynchronization mtodos relacionados s etapas de funcionamento de uma transao devem ser executados. O primeiro mtodo denominado de afterBegin() e sofre a invocao aps o incio da transao. O fim da execuo desse mtodo permite que a instncia passe a fornecer uma transao para os mtodos que solicitam esse recurso; O retorno para o estado method ready realizado quando a transao sofre o commit ou rollback da transao. Se ocorrer o commit, imediatamente antes deste ocorrer, o continer invoca o mtodo beforeCompletion() que permite ainda definir um rollback. Isso pode ser necessrio para a validao de um determinado valor que determina o sucesso ou no de uma transao. Logo aps, se o commit for executado com sucesso, o continer notifica a instncia atravs da invocao do mtodo afterCompletion(true). Se ocorrer o rollback da transao, o continer notifica a instncia atravs da invocao do mtodo afterCompletion(false); No estado method ready, o continer tem a possibilidade de liberar recursos, ao levar uma instncia ao estado passive. Para isso, deve-se invocar os mtodos definidos como PrePassivate, caso eles tenham sido definidos. Aps a execuo desses mtodos, a instncia passa ao estado passive e permanece at a sua ativao, na qual o continer a carrega para a memria principal e realiza a invocao de mtodos definidos como PostActivate. No estado passive, caso ocorra o timeout de uma instncia, ela pode ser destruda retornando ao estado does not exist; Por fim, no estado method ready pode ocorrer a chamada pelo cliente ou pelo continer de mtodos do tipo Remove. Nesse caso, ocorre a invocao de mtodos de callback do tipo PreDestroy que possibilitam a otimizao do uso de

39 recursos, por exemplo, possvel fechar conexes que no sero mais necessrias.

FIGURA 4.4 Ciclo de vida de um stateful session bean, EJB 3.0 4.5.3. Exigncias no Desenvolvimento de Session Beans O desenvolvimento de componentes do tipo session bean foi simplificado na verso 3.0. Nessa verso, elimina-se a necessidade de implementao de interfaces fornecidas pela especificao da tecnologia EJB e os mtodos que controlam o ciclo de vida desses componentes passam a ser opcionais. Esses componentes devem apenas implementar uma interface de negcios que define os mtodos visveis aos clientes. Essa interface pode ser definida como local ou remota, mas no simultaneamente para ambos os tipos em uma mesma classe de um componente. Em adio, esses componentes suportam o uso de anotaes para eliminar a necessidade do uso de descritores XML; entretanto, o suporte a descritores XML est presente em razo de manuteno da possibilidade de manter em arquivos separados a implementao do componente e as suas configuraes. Alm disso, essa nova verso exige que os novos contineres mantenham o suporte a componentes desenvolvidos para a verso 2.1, facilitando a migrao gradual.

40 Identifica-se que a verso 3.0, conforme a TABELA 4.1, torna opcional diversos fatores que eram obrigatrios. Isso permite que apenas recursos que sero utilizados sejam definidos, fator que elimina exigncias para o desenvolvedor. TABELA 4.1 Comparao entre session EJB 2.1 e EJB 3.0 EJB 2.1 Anotaes Descritores XML No suporta Suporta EJB 3.0 Suporta Suporta. Descritores tm precedncia sobre as anotaes. Opcional Obrigatria Opcional Suporta Opcional Suporta

Interface Home Interface de Negcios Interface SessionBean Injeo de Recursos Mtodos de callback para eventos do ciclo de vida Interceptors

Obrigatria Obrigatria Obrigatria No suporta Obrigatria a implementao No suporta

Em relao ao uso de anotaes, resumidas na TABELA 4.2, esses componentes podem solicitar a injeo de recursos ou outros componentes da arquitetura EJB utilizando, respectivamente, as anotaes @Resource e @EJB sobre mtodos com assinatura do tipo setXXX() ou variveis. Alm disso, essas anotaes podem ser utilizadas sobre a declarao da classe do componente e, desse modo, servirem para declarao de recursos. Esses recursos podem ser obtidos com a utilizao do objeto SessionContext que disponibiliza o acesso ao ambiente operacional de um componente EJB ou atravs da utilizao de chamadas a mtodos nativos da API JNDI. TABELA 4.2 Principais anotaes utilizadas em session beans Anotao @Stateless @Stateful @Remote Funo Define o tipo do componente como stateless. Deve ser utilizada sobre a declarao da classe de um componente. Define o tipo do componente como stateful. Deve ser utilizada sobre a declarao da classe de um componente. Define quais sero as interfaces remotas de um componente. Mltiplas interfaces podem ser definidas; entretanto, uma interface do tipo remota no pode ser definida como local para a mesma classe de um componente. Define quais sero as interfaces locais de um componente. Mltiplas interfaces podem ser definidas; entretanto, uma interface do tipo local no pode ser definida como remota para a mesma classe de um componente. Permite que um componente desenvolvido para verso 2.1 seja utilizado em um continer da verso 3.0.

@Local

@RemoteHome

41 @LocalHome @Init Permite que um componente desenvolvido para verso 2.1 seja utilizado em um continer da verso 3.0. Permite que um cliente desenvolvido para a verso 2.1 possa acessar um componente EJB 3.0. Essa anotao identifica um mtodo na classe do bean correspondente a um mtodo iniciado por create da interface home remota ou home local de um componente. Define a invocao do mtodo aps a injeo dos recursos em um componente. Deve ser utilizada sobre um mtodo. Define a invocao do mtodo antes da passivao de um componente. Suportada somente para o tipo stateful. Define a invocao do mtodo aps a ativao de um componente. Suportada somente para o tipo stateful. Define a invocao do mtodo antes da destruio da instncia do componente. Define que, aps a execuo do mtodo anotado, a instncia deve ser removida pelo continer.

@PostConstruct @PrePassivate @PostActivate @PreDestroy @Remove

4.6. Componentes Message-Driven Bean


Os componentes do tipo message-driven bean, assim como os demais tipos de componentes incorporam o uso de anotaes. O ciclo de vida deles semelhante aos stateless da verso 3.0. Conforme descrito no ciclo de vida dos componentes stateless session beans, mtodos de callback do tipo PostConstruct e PreDestroy so opcionais e, quando definidos, devem ser invocados pelo continer. A FIGURA 4.5 ilustra o ciclo de vida para a verso 3.0:

FIGURA 4.5 - Ciclo de vida de um message-driven bean, EJB 3.0

42 4.6.1. Exigncias no Desenvolvimento de Message-Driven Beans Esses componentes, seguindo o objetivo da verso 3.0, sofreram reduo no nmero de exigncias existentes em relao a verso 2.1. Na TABELA 4.3 so apresentadas as principais diferenas entre a verso 2.1 e 3.0 para message-driven beans. Nessa nova verso, no h mais necessidade de implementar a interface javax.ejb.MessageDrivenBean. Existe apenas a obrigao de definio de uma interface de negcios que corresponda ao tipo de mensagem que deve ser atendida por esses componentes. A definio dessa interface feita atravs do uso da anotao @MessageDriven ou de um descritor XML. Alm disso, existe o suporte aos mtodos de callback do tipo PostConstruct e PreDestroy assim como o mecanismo de injeo e de interceptors. A configurao desses elementos pode ser realizada por anotaes apresentadas na TABELA 4.4 ou descritores XML. TABELA 4.3 Comparao entre message-driven EJB 2.1 e EJB 3.0 EJB 2.1 Anotaes Descritores XML No suporta Suporta EJB 3.0 Suporta Suporta. Descritores tm precedncia sobre as anotaes. Opcional Obrigatria

Interface MessageDrivenBean Interface Message Listener(identifica o tipo de mensagem suportado pelo bean) Injeo de Recursos Mtodos de callback para eventos do ciclo de vida Interceptors

Obrigatria Obrigatria

No suporta Obrigatria a implementao No suporta

Suporta Opcional Suporta

TABELA 4.4 Principais anotaes utilizadas em message-driven beans Anotao @MessageDriven Funo Define o tipo do componente como message-driven. Deve ser utilizada sobre a declarao da classe de um componente e deve tambm definir a interface do tipo de mensagem atendida por esse componente. Define a invocao do mtodo aps a injeo dos recursos em um componente. Deve ser utilizada sobre um mtodo. Define a invocao do mtodo antes da destruio da instncia do componente.

@PostConstruct @PreDestroy

43

4.7. Componentes Entity Bean


A rea mais criticada da verso 2.1 da arquitetura EJB est relacionada com o modelo de persistncia definido. Desse modo, a verso 3.0 apresenta uma reformulao da API de persistncia e aproxima o modelo de persistncia, utilizado por esta arquitetura, aos modelos de mapeamento objeto/relacional, utilizados pelas ferramentas Hibernate e TopLink. A primeira grande mudana em relao a verso 2.1 refere-se a transformao de um componente entity bean em uma classe Java simples, um POJO. Nessa verso um objeto do tipo entity bean passa a ser uma classe Java tradicional, no h necessidade de ser abstrata e no h necessidade de implementao de interfaces externas que anteriormente continham mtodos utilizados pelo continer na verso 2.1. Os entities, sendo classes concretas, tal como classes Java, suportam construtores e podem implementar mtodos getters/setters para a definio de suas propriedades e incluso de lgica de validao, aumentando a capacidade de expresso desses componentes. Alm disso, o suporte a herana e ao polimorfismo, permitidos pela transformao de entities em objetos POJO, simplifica a representao de bases de dados relacionais. A representao de relaes entre entities, necessrias para o mapeamento O/R, feita atravs do uso de anotaes, o que elimina a necessidade de longos descritores XML de descrio de relaes. Em adio, elas so representadas por objetos colees Java, o que facilita o mapeamento de resultados obtidos a partir da obteno dos valores dessas relaes. A definio de todos os parmetros utilizados no mapeamento O/R, tais como a propriedade que define a chave primria de um entity ou a tabela que ser criada por ele em uma base de dados relacional, pode ser feita atravs do uso de anotaes, eliminando por completo descritores XML utilizados para a definio de configuraes dos entities. O resumo das principais anotaes suportadas pela API de Persistncia para o mapeamento O/R apresentado na TABELA 4.5. TABELA 4.5 Principais anotaes do mapeamento O/R Anotao @Id @IdClass @Table @SecondaryTable, @SecondaryTables Funo Define a propriedade ou campo de um entity que ser a chave primria desse componente. Define uma classe externa utilizada como chave primria de um entity. Utilizada para chaves primrias compostas. Define a tabela primria para um entity. Definem tabelas adicionais utilizadas por um entity. Essas anotaes so utilizadas em conjunto ao uso de herana de entities, quando h necessidade de armazenar informaes em mltiplas tabelas. Define a coluna para o qual uma propriedade ou campo de um entity ser mapeado. Define a restrio de um valor nico para um determinado

@Column @UniqueConstraint

44 grupo de propriedades ou campos de um entity. @Transient @Lob Define que uma propriedade ou campo de um entity no ser persistente. Define que uma propriedade ou campo representar um grande objeto suportado por bases relacionais. Exemplo: imagens ou vdeos. Define que uma propriedade ou campo representar um dado temporal. Exemplo: hora ou data. Define que uma propriedade ou campo representar um tipo enumerado suportado a partir da verso 1.5 do Java. Define uma associao com valor simples de multiplicidade 1..1. Exemplo: um aluno e a nota de uma prova realizada por ele. Define uma associao com valor simples de multiplicidade n..1. Exemplo: no componente pedido uma propriedade cliente, diversos pedidos podem pertencer a um cliente. Define uma associao com mltiplos valores de multiplicidade 1..n. Exemplo: no componente cliente uma propriedade pedidos, um cliente pode ter diversos pedidos. Define uma associao de mltiplos valores com multiplicidade n..n.Exemplo: um cliente pode ter vrios telefones e um telefone pode pertencer a vrios clientes. Define a ordem na qual os elementos de uma coleo sero retornados. Define um gerador de chave primria.

@Temporal @Enumerated @OneToOne

@ManyToOne

@OneToMany

@ManyToMany

@OrderBy @SequenceGenerator

Nessa verso, com a introduo da API Entity Manager, os tipos CMP e BMP existentes na verso 2.1 deixam de existir. Nesse novo modelo, os beans migram em direo aos CMP, mas tem o seu ciclo de vida modificado, pois passam a ser gerenciados pela API Entity Manager que ser apresentada em 4.7.1. Uma nova caracterstica a possibilidade de utilizao externa ao continer EJB. Isso possvel devido a capacidade de serializao desses objetos e a possibilidade deles apresentarem um estado denominado detached, ou seja, desconectados de uma base de dados. Essa nova caracterstica interessante por permitir a realizao de testes sobre a camada lgica sem a necessidade do uso de um continer EJB. 4.7.1. Persistence Contexts, API Entity Managers e API Queries O modelo de persistncia definido para verso 3.0 define uma srie de novos conceitos. Entre eles podemos destacar os persistence contexts, a API Entity Manager e a API Query. Cada um desses novos conceitos ser definido detalhadamente nessa seo devido a sua importncia para compreenso do novo modelo de persistncia proposto.

45 Os persistence contexts representam um conjunto de instncias de entities no qual, para cada identidade de um entity, ou seja, sua chave-primria, existe somente uma instncia. So nesses contextos que as operaes de persistncia permitidas pela API Entity Manager so executadas, ressalta-se que esses contextos so divididos em dois tipos principais. O primeiro tipo denominado de container-managed persistence context, nesse tipo o ciclo de vida do persistence context gerenciado automaticamente pelo continer. A gerncia feita de modo transparente para o usurio. Esse tipo de continer subdividido em dois tipos: container-managed transaction-scoped persistence context e container-managed extended persistence context. O tipo container-managed transaction-scoped persistence context corresponde a um contexto de persistncia criado no momento da invocao de uma operao da API Entity Manager. Nessa invocao, caso exista uma transao ativa, esse persistence context passa a ser associado a ela, caso no exista uma ativa, uma nova transao criada antes da execuo da operao e finalizada logo aps o encerramento da operao pelo Entity Manager. Destaca-se que um persistence context com escopo de transao existe somente durante o tempo de vida da transao ao qual ele est associado. O fato de ele deixar de existir, conforme definido na seo 4.7, provoca a transio para o estado detached das instncias de entities associadas esse persistence context; nesse estado, os entities no esto ligados a nenhum meio persistente. Desse modo, uma pane provoca perda de informaes. O tipo container-managed extended persistence context pode ser criado somente por componentes do tipo stateful. Contextos desse tipo existem desde o momento da invocao de um stateful at o momento de finalizao do mtodo anotado com @Remove ou a destruio da instncia desse stateful. Esse contexto pode ser associado a diversas transaes, ele permanece mesmo com o commit de diversas transaes; entretanto, caso haja um rollback, ele deixa de existir. Esse tipo extremamente til no caso de processos que exijam diversas invocaes de um componente. Por exemplo, numa aplicao de comrcio eletrnico existem diversos passos para a concluso de uma compra. Devido ao modelo estendido do contexto de persistncia, no existe a necessidade de transferir parmetros entre diversas invocaes do stateful que est gerenciando o processo de compra, pois o persistence context permanece ativo entre as chamadas de diferentes mtodos do stateful. Em oposio ao tipo container-managed existe o tipo definido como applicationmanaged persistence context. Nesse tipo, o desenvolvedor interage diretamente no controle do ciclo de vida dos gerenciadores de persistncia denominados Entity Managers, a gerncia do ciclo de vida feita atravs do uso de objetos do tipo EntityManagerFactory. Esses objetos so capazes de criar novos Entity Managers e so capazes de encerr-los atravs da operao denominada close. Esse tipo sempre considerado estendido. Em adiao aos persistence contexts, a API de persistncia introduzida na verso 3.0 especifica a API Entity Manager. Ela responsvel por permitir a utilizao de diferentes provedores de persistncia, pois cada provedor pode desenvolver os seus mecanismos de persistncias e esses podem ser apresentados de maneira encapsulada e padronizada. As principais operaes disponibilizadas por essa API voltada para um modelo simplificado de persistncia so denominadas de persist, merge, remove, flush, refresh, createQuery e createNamedQuery.

46 A primeira operao, persist, consiste em persistir a instncia de um entity, ou seja, somente quando esse mtodo invocado pelo desenvolvedor a instncia passa a ser persistente aps a invocao desse mtodo, dependendo do persistence context utilizado, a instncia persistida automaticamente. A segunda operao, merge, corresponde a realizar um merge entre uma instncia de um entity com um persistence context. Essa operao necessria devido a existncia da possibilidade de entities no estado detached. A terceira operao, remove, consiste em remover uma instncia de um entity, isso significa que a informao armazenada por ele ser eliminada do meio persistente. Apesar de removida, essa instncia pode ser novamente persistida conforme a execuo da primeira operao definida acima. A quarta operao, flush, solicita que o provedor de persistncia sincronize o persistence context corrente com o banco de dados utilizado como meio persistente. Essa operao no necessita ocorrer imediatamente, pois, no uso real, ela ser executada no momento de commit da transao associada ao persistence context. A quinta operao, refresh, sempre executada imediatamente e permite que as informaes armazenadas no meio persistente sejam atualizadas na instncia do entity. Essa operao permite que modificaes incorretas sejam imediatamente desfeitas na instncia de um entity. A sexta operao e stima operaes, createQuery e createNamedQuery, permitem que o desenvolvedor realize operaes de consultas sobre os entities disponveis na aplicao. Destaca-se que essas operaes permitem a utilizao de consultas previamente definidas pelo desenvolvedor (conforme a seo 4.7.4) e possibilitam a criao de novas consultas em tempo de execuo desses componentes. As duas ltimas operaes citadas esto relacionadas a API Queries, pois, quando efetuadas, retornam uma estrutura chamada de query. Essa estrutura, componente da API Queries, possibilita que parmetros sejam definidos pelo desenvolvedor, esses parmetros so anlogos aos parmetros utilizados para restringir o resultado de uma consulta SQL. Por exemplo, podemos definir o parmetro valor igual a 10 e, desse modo, somente entities que tenham o atributo valor igual a 10 sero selecionados. O resultado obtido pela execuo de uma query pode ser tanto um valor unitrio como uma coleo. A FIGURA 4.6 apresenta a organizao dos conceitos definidos na API de persistncia definida na verso 3.0 da especificao EJB. Um EntityManagerFactory pode ter associado a ele mltiplos EntityManagers. Cada EntityManager deve estar associado a uma EntityTransaction e pode gerar n queries. Alm disso, um EntityManager pode gerenciar n instncias de entities.

47

FIGURA 4.6 Organizao da API de Persistncia 4.7.2. Ciclo de vida de Entity Beans O ciclo de vida dos componentes entity beans, conforme a FIGURA 4.7, foi reformulado na verso 3.0. Destaca-se que ele passa a ser controlado pelo EntityManager. Os seguintes passos descrevem o ciclo de vida desse tipo de componente: O primeiro estado de uma instncia desses componentes chamado de New/Transient. Nesse estado o componente no est ligado a nenhum contexto de persistncia, caso ocorra uma pane no servidor, as informaes armazenadas na instncia so perdidas. Ao ocorrer a chamada de um mtodo denominado de persist do EntityManager, a instncia passa ao estado Managed; No estado Managed, a instncia passa a ser persistente, pois est associada a um contexto de persistncia. Nesse estado, qualquer modificao que ocorra nessa instncia ser persistida, garantido desse modo o salvamento dessas informaes. Alm disso, uma instncia nesse estado pode transitar para todos os demais estados: New/Transient, Detached e Removed. A transio para o estado New/Transient ocorre em um contexto de persistncia do tipo entendido quando ocorre o rollback da transao a qual ele est associado. A transio para Detached realizada quando ocorre o commit, rollback da transao associada ao contexto de persistncia ou a invocao do mtodo close do EntityManager. A transio para Removed realizada se o mtodo remove do EntityManager for invocado; No estado Detached, a instncia desassociada de um contexto de persistncia e pode ser manipulada por um cliente. As modificaes realizadas podem ser persistidas ao ser invocado o mtodo merge do EntityManager, nesse caso, a instncia retorna ao estado Managed; No estado Removed, as informaes contidas na instncia so removidas do meio persistente quando ocorre o commit da transao a qual o contexto de persistncia est associado. Caso ocorra o rollback da transao associada a um contexto de persistncia estendido ou a invocao do mtodo persist do EntityManager, a instncia retorna ao estado Managed.

48

FIGURA 4.7 Ciclo de vida de um entity bean, EJB 3.0. Em adio a simplificao do ciclo de vida, esses componentes passam a suportar mtodos de callback que so notificados quando existe a ocorrncia de eventos do ciclo de vida do entity bean. A capacidade de identificar etapas no ciclo de vida desses componentes aumenta o controle por parte do desenvolvedor, pois se torna possvel identificar quando o componente ser persistido e, desse modo, validar se as informaes so vlidas para serem salvas. As anotaes para definio dos tipos de eventos que devem ser notificados a um mtodo so apresentadas na TABELA 4.6. TABELA 4.6 Anotaes para a definio de mtodos de callback Anotao @PrePersist @PostPersist @PreRemove @PostRemove @PreUpdate @PostUpdate @PostLoad Funo Define a invocao do mtodo, respectivamente, antes ou aps a insero das informaes em um banco de dados. Define a invocao do mtodo, respectivamente, antes ou aps a insero das informaes em um banco de dados. Define a invocao do mtodo, respectivamente, antes ou aps a atualizao das informaes do entity. Define a invocao do mtodo aps a recuperao das informaes do banco de dados para a instncia do entity.

4.7.3. Exigncias no Desenvolvimento de Entity Beans Os componentes entity beans, conforme definido nas sees 3.5.2 e 3.5.4, apresentavam uma srie de exigncias para os desenvolvedores. Em oposio a verso 2.1, a verso 3.0 passa a exigir basicamente somente duas configuraes para a criao desse tipo de componente. Ambas as configuraes podem ser feitas utilizando anotaes ou descritores XML. A primeira anotao utilizada para configurao chamada de @Entity, ao ser utilizada sobre uma classe Java, ela passa a ser considerada um entity bean. Esse novo entity pode ser do tipo field-based access ou property-based access.

49 O primeiro tipo exige somente a declarao de quais campos o componente ir conter, por exemplo, um identificador do entity e a data de acesso. O segundo tipo exige a declarao dos mtodos setPropriedade(arg) e getPropriedade(); esse tipo interessante por permitir a validao dos dados de entrada. Para ambos os tipos, a especificao considera que os campos declarados sero persistentes, caso eles no devam ser persistentes, utiliza-se a anotao @Transient. A ltima configurao obrigatria refere-se a definio de qual campo ser a chaveprimria desse componente, para isso, se o campo for um tipo primitivo do Java encapsulado em um objeto(E.g.: Interger, Float), basta ser utilizada a anotao @Id sobre o campo ou a propriedade. As demais configuraes podem ser especificadas a partir de anotaes apresentadas na TABELA 4.5 ou atravs de descritores XML. As principais diferenas entre um entity EJB 2.1 e EJB 3.0 so apresentadas na TABELA 4.7. TABELA 4.7 Comparao entre entity EJB 2.1 e EJB 3.0 EJB 2.1 Anotaes Descritores XML Interface Remota ou Local Classe Abstrata Suporte a Herana Tipos EntityManager API Provedor de Persistncia Uso desconectado do continer 4.7.4. EJB QL A linguagem EJB QL na verso 3.0 foi estendida em comparao a verso 2.1 da especificao. Nessa nova verso operaes ausentes na verso 2.1 so introduzidas, entre elas, destacam-se as operaes de atualizao e remoo do tipo bulk, possibilidade de operaes do tipo JOIN, GROUP BY, HAVING, projeo e subconsultas. Alm disso, o suporte a definio de consultas em linguagem nativa a base relacional foi adicionado. Ressalta-se que o uso de linguagem nativa reduz a portabilidade dos componentes, mas permite otimizaes ou utilizao de operaes no suportadas nativamente pela linguagem EJB QL. No suporta Suporta Obrigatria Obrigatria Parcialmente CMP/BMP No suporta Continer EJB 3.0 Suporta Suporta Sem interfaces Opcional Total Somente um, semelhante ao CMP Suporta Aplicao Externa ou o prprio continer. Exemplo: Hibernate Suporta

No suporta

50 Deve-se destacar que consultas pr-definidas podem ser declaradas via anotaes, o que elimina a necessidade do uso de descritores XML para esse fim. As duas principais anotaes so definidas na TABELA 4.8. TABELA 4.8 Anotaes para definies de consultas Anotao @NamedQuery @NamedNativeQuery Funo Definir consultas do tipo EJB QL. Definir consultas utilizando nativa SQL.

4.8. Suporte a Transaes


O suporte a transaes distribudas entre a verso 2.1 e 3.0 no apresenta diferenas significativas. Destaca-se que na verso 3.0 o desenvolvedor pode indicar atravs de anotaes o suporte a transaes.

51

5. Metodologia para Avaliao de Desempenho de Componentes EJB


A avaliao de desempenho entre as duas verses da arquitetura EJB importante para mensurar se as simplificaes trazidas pela verso 3.0 no trazem reduo no desempenho de suas implementaes. Alm disso, essa anlise visa fornecer, em unio com a anlise textual realizada no captulo anterior, um conjunto de informaes consistentes que facilitem a tomada de deciso de migrao para a verso 3.0. A realizao dessa avaliao de desempenho deve ser fundamentada em uma metodologia, pois isso permite a obteno de resultados adequados, evitando o uso de mtricas inconsistentes que possam mascarar os resultados dessa anlise. Em razo disso, esse captulo descreve as caractersticas da metodologia utilizada.

5.1. Mtrica de Desempenho


A utilizao de uma mtrica adequada para a avaliao de desempenho fundamental nesse tipo de anlise. Deve-se destacar, conforme [LIL 04], que o tipo de mtrica adequada varia conforme o objetivo da anlise. As principais caractersticas de uma mtrica de desempenho adequada, conforme [LIL 04], so as seguintes: Linearidade: em razo da caracterstica de pensamento linear do ser humano, o valor de uma mtrica deve ser linearmente proporcional a certa taxa. Por exemplo, se a taxa duplicada, o resultado obtido com a mtrica tambm deve ser duplicado; Confiabilidade: uma mtrica considerada confivel se no caso de um sistema A ser inferior a um sistema B em relao a uma propriedade avaliada, o resultado obtido com ela para o sistema A for inferior ao sistema B. Por exemplo, se uma mtrica utilizada para verificar a capacidade de processamento de uma CPU e um sistema A tiver uma CPU com capacidade inferior ao de um sistema B, o resultado obtido deve indicar que A inferior a B; Repetitibilidade: a caracterstica de repetitibilidade obtida quando para um mesmo experimento realizado mltiplas vezes, o valor obtido o mesmo; Facilidade de medio: uma mtrica deve ser fcil de ser utilizada para reduzir a probabilidade de introduo de erros; Consistncia: uma mtrica consistente se a unidade da mtrica for vlida para a realizao em diferentes sistemas ou aplicaes; Independncia: uma mtrica deve ser independente de um determinado fabricante ou desenvolvedor, garantido iseno na anlise.

Aps a identificao das principais caractersticas para uma mtrica de desempenho adequada optou-se pela utilizao da mtrica de tempo de execuo [LIL 04]. Em adio, essa mtrica foi utilizada por trabalhos anteriores em anlise de desempenho de objetos distribudos por Juric et al, Hericko et al e Hirano et al, respectivamente, nos artigos [JUR 99], [HER 98] e [HIR 98].

52 Alm disso, essa mtrica freqentemente utilizada para avaliaes de desempenho de sistemas de alto desempenho e avaliaes de servidores Java EE. Trabalhos como [CEC 02] e [PET 05] utilizam essa mtrica.

5.2. Reduo de Erros em Medidas Experimentais


O uso de uma mtrica de desempenho adequada deve considerar os erros existentes quando medidas experimentais so utilizadas. No caso do uso do tempo de execuo, deve ser considerada a influncia de outros elementos de software na obteno de resultados. Valores obtidos podem ser influenciados por tarefas secundrias do sistema operacional, pela paginao de memria, pelo intervalo de tempo alocado para aplicao e outros fatores. No caso do Java, conforme [PRI 04], o garbage collector pode causar grande influncia nos resultados obtidos. A reduo da influncia dos erros no resultado dessa anlise foi realizada atravs do uso de um modelo estatstico. Esse modelo, conforme [LIL 04], assume que os erros experimentais so Gaussianos, ou seja, a realizao de uma medida experimental diversas vezes tende a valores que seguem uma distribuio normal (Gaussiana). A partir desse modelo, possvel determinar o nmero de amostras necessrias para que os resultados obtidos sejam considerados vlidos conforme uma taxa aceitvel de erro. Conforme a FIGURA 5.1, nesse trabalho foi adotado um erro aceitvel de 1% da mdia e um grau de confiana de 95% para o clculo do tamanho da amostra. O grau de confiana de 95% identifica uma probabilidade de 5% de a mdia amostral estar localizada nas regies sombreadas e uma probabilidade de 1 - da mdia amostral estar localizada na regio no sombreada, nesse caso, conforme a tabela da distribuio normal, o Zc igual a 1,96.

FIGURA 5.1 Determinao do Zc para 95% de confiana Conforme [LIL 04], a frmula necessria para o clculo do nmero de experimentos apresentada na FIGURA 5.2. O n representa o tamanho da amostra, Zc corresponde ao Z crtico, s representa o desvio padro, e representa o erro aceitvel e x a mdia dos valores obtidos. Mais detalhadamente, o Zc, segundo [TRI 99], permite a separao dos valores das estatsticas amostrais mais provveis dos valores menos provveis. Isso importante para evitar que a execuo de processos no relacionados avaliao influencie no resultado final. O s a medio da variao dos valores em relao mdia, e o e.

53 representa a diferena mxima provvel (com probabilidade 1 - ) entre a mdia observada e a verdadeira mdia populacional . Destaca-se que na frmula para definio do nmero de amostras exigido o conhecimento dos valores do desvio padro e da mdia aritmtica; entretanto, no existe conhecimento prvio desses valores. Desse modo, conforme [LIL 04], possvel realizar um experimento com um pequeno nmero de amostras; para esse trabalho, os experimentos prvios utilizaram n = 30.

FIGURA 5.2 Frmula para o clculo do tamanho da amostra

5.3. Critrios de Avaliao


Os critrios utilizados para a anlise de desempenho correspondem a outros fatores fundamentais para um estudo adequado da tecnologia estudada. Tendo em vista que componentes EJB so objetos distribudos (ODs) foi realizada uma pesquisa em trabalhos anteriores para a definio de quais pontos seriam testados nesse trabalho. No artigo [JUR 04] foi proposto uma framework para analisar o desempenho de tecnologias de ODs (DOTs). Entre as tecnologias testadas, destacam-se Java IDL e RMI-IIOP, pois essas tecnologias so utilizadas em implementaes da especificao EJB e Java EE para prover acesso aos componentes EJB. Alm disso, uma srie de critrios para avaliao de desempenho so definidos para englobar todos os principais aspectos da anlise de ODs. Entre os critrios propostos destacam-se os seguintes: 1. RTT (Round Trip Time): utilizado para medir o tempo gasto do momento em que um cliente invoca um mtodo at o momento que ele recebe o resultado; 2. Data Throughput: utilizado para medir a eficincia na capacidade de transferncia de dados. Os dados so passados como parmetros pelo cliente e enviados pelo servidor como resposta; 3. Escalabilidade: utilizado para avaliar a degradao de performance quando mltiplos clientes interagem simultaneamente com o servidor; 4. Estratgia multi-threading: utilizado para avaliar a invocao de mtodos por mltiplos clientes de um objeto no servidor; 5. Binding overhead: utilizado para medir o tempo necessrio para obteno da referncia a um objeto remoto. Adicionalmente, no artigo [JUR 04], prope-se a realizao de medidas pelo cliente e, para isso, definem-se as atividades de um cliente a ser utilizado para avaliao dos testes. As principais atividades definidas para o cliente so as seguintes: Realiza um bind ao objeto a ser utilizado para a avaliao de desempenho; Abre a conexo a uma tabela na quais os resultados sero armazenados; Aloca memria para o armazenamento temporrio dos resultados obtidos; Realiza a medio; Calcula os resultados;

54 Grava os resultados na tabela. No artigo [HIR 98], a anlise de desempenho de ODs envolveu tecnologias como RMI, CORBA, socket Java e socket C para comparao. A motivao do trabalho foi a necessidade de saber qual delas utilizar para aquisio de dados em experincias fsicas. Destaca-se nesse trabalho que os autores utilizaram a abordagem de avaliar operaes primitivas dos objetos, pois eles partem do princpio que elas representam as caractersticas das tecnologias. As operaes primitivas que se destacam so as seguintes: 1. Criao de um objeto remoto: avalia o tempo para a criao de um objeto remoto dinamicamente realizado pelo cliente; 2. Invocao de um mtodo remoto: avalia o tempo de execuo de um mtodo que recebe como parmetro um conjunto de valores numricos do tipo Integer e retorna um Integer como resultado; 3. Transferncia de um array de objetos: avalia o tempo de execuo gasto na transferncia de um array de objetos do tipo Data. O tipo Data contm apenas um Integer como propriedade. Segundo [HIR 98], esse objeto foi criado com apenas um Integer por ter como objetivo a medio do desempenho de transferncia de um objeto e no de Integers.

5.4. Critrios de Avaliao Utilizados


Os critrios utilizados nesse trabalho foram construdos a partir dos critrios apresentados na seo 5.3. Entretanto, tendo em vista que a arquitetura EJB fornece uma srie de servios especficos, alguns critrios foram introduzidos para permitir a avaliao de desempenho quando esses servios so utilizados. Esses critrios buscam avaliar o desempenho do ponto de vista do usurio, pois o tempo de reposta sempre avaliado em relao a uma operao da tecnologia EJB. Em suma, essa avaliao busca identificar os benefcios ou custos trazidos para o usurio com a introduo da verso 3.0 dessa tecnologia. Os critrios utilizados foram os seguintes: 1. Lookup de componentes session bean: avalia o tempo de execuo necessrio para que um componente seja localizado no JNDI (lookup) e esteja pronto para ser utilizado pelo usurio; 2. Invocao de mtodos de componentes session bean: avalia o tempo de execuo necessrio para a execuo de um determinado mtodo de um componente EJB; 3. Invocao de mtodo transacional gerenciado pelo continer: avalia o tempo necessrio para a execuo de um mtodo que contm um determinado nmero de conexes a um banco de dados. Todas as conexes participam de uma transao gerenciada pelo continer; 4. Invocao de mtodo transacional gerenciado pelo bean: avalia o tempo necessrio para a execuo de um mtodo que contm um determinado nmero de conexes a um banco de dados. Todas as conexes participam de uma transao gerenciada pelo prprio desenvolvedor;

55 5. Localizao de um componente entity bean: avalia o tempo de execuo necessrio para que um componente do tipo entity bean seja localizado pelo continer EJB e retornado para um outro componente do tipo session bean.

5.5. Modelo de Cliente Utilizado


O modelo de cliente utilizado nesse trabalho usou como base o modelo proposto por [JUR 04]. Destaca-se que a arquitetura EJB foi desenvolvida para suportar aplicaes comercias. Devido a esse fator, foram realizados testes com um cliente e, adicionalmente, com mltiplos clientes simulados por Threads. Os seguintes grupos de clientes foram utilizados para a realizao dos testes: 1. Um nico cliente localizado na mesma mquina do servidor EJB; 2. Um nico cliente localizado em uma mquina remota acessando componentes na mquina do servidor EJB; 3. Cinco clientes simulados por Threads na mesma mquina do servidor EJB; 4. Cinco clientes simulados por Threads em uma mquina remota acessando componentes na mquina do servidor EJB.

56

6. Avaliao de Desempenho de Componentes EJB: Verses 2.1 e 3.0


O desenvolvimento da avaliao de desempenho, alm de necessitar da definio de uma metodologia, exige a definio dos recursos utilizados, estes recursos so apresentados nesse captulo. Alm disso, a medio do tempo necessita de certo grau de preciso, esse grau foi obtido atravs do uso de uma biblioteca auxiliar para esse fim. Aps a definio dos elementos citados acima, o procedimento de teste explicitado e os resultados obtidos so apresentados. Ao longo da apresentao dos resultados, so apresentadas possveis justificativas para os valores encontrados.

6.1. Recursos Utilizados


6.1.1. Hardware O hardware utilizado nos testes foi composto de dois notebooks com processadores Intel Pentium M de 1,73GHz, cada um com 1 GB de memria RAM DDR2. A conexo de 100 Mb/s entre os computadores foi realizada atravs de um cabo Ethernet do tipo cross-over. 6.1.2. Software O sistema operacional utilizado foi o Windows XP com Service Pack 2. Durante os testes somente aplicaes envolvidas com a avaliao de desempenho permaneceram habilitadas, o que evitou a influncia de aplicaes externas sobre os resultados obtidos. O desenvolvimento das aplicaes, que implementam os critrios propostos na seo 5.4, foi realizado utilizando o Java SDK 5.0, pois esta verso suporta as anotaes utilizadas no EJB 3.0. Para execuo dos componentes desenvolvidos para a verso 2.1 da arquitetura EJB foi utilizado o servidor EJB presente no servidor de aplicaes JOnAS, verso 4.7.4, da ObjectWeb. O servidor JOnAS utiliza o software GenIC para gerar o cdigo middleware necessrio para a utilizao de componentes EJB; este responsvel por processar o cdigo fonte fornecido pelo desenvolvedor e acrescentar o cdigo de middleware. Aps a gerao do cdigo fonte Java necessrio, a compilao dos componentes realizada utilizando o compilador Java. Para a execuo dos componentes desenvolvidos para a verso 3.0 da arquitetura EJB foi utilizado o servidor EJB denominado EasyBeans, verso Milestone 1, tambm desenvolvido pela ObjectWeb. Em razo da necessidade adicional de interpretao das anotaes inseridas pelo desenvolvedor e a necessidade de reduzir a quantidade de cdigo adicional de middleware introduzido para o funcionamento dos componentes, o EasyBeans substitui o GenIC pelo ASM da ObjectWeb. Essa nova aplicao passa a injetar diretamente no byte code gerado pela compilao dos componentes EJB, permitindo otimizar a quantidade de cdigo middleware utilizado. O protocolo de comunicao RMI-JRMP foi utilizado para comunicao entre os clientes e o servidor EJB.

57

6.2. Medio do Tempo


A utilizao do tempo como mtrica de desempenho torna fundamental uma alta preciso na medio tempo. A plataforma Java, fornece o mtodo currentTimeMillis() pertencente a classe System que retorna o tempo com preciso de milisegundos (ms). Entretanto, esse mtodo no fornece a preciso necessria para esse trabalho, pois algumas operaes podem ser realizadas em tempo inferior a um milisegundo. Por exemplo, o lookup de um componente. Para suprir essa necessidade, foi necessrio utilizar a biblioteca desenvolvida por [ROU 03], a qual fornece um timer que implementa dois mtodos nativos existentes no Windows. Os mtodos so denominados de QueryPerformanceCounter() e QueryPerformanceFrequency(). O primeiro responsvel por retornar o valor de um contador que indica o nmero de clocks desde a inicializao do sistema. O segundo responsvel por retornar a freqncia do contador utilizado no primeiro mtodo (ciclos por segundo). A partir desses dois mtodos, subtraindo-se o nmero de ciclos finais aps a execuo de um teste do nmero de ciclos antes da execuo, possvel calcular o nmero de ciclos gastos. Esse valor dividido pela freqncia do contador define o intervalo de tempo com preciso de microsegundos [ROU 03]. O processo de medio de tempo, ilustrado na FIGURA 6.1, inicia-se com o clculo do tempo gasto para acessar o timer. Logo aps o timer reinicializado e o tempo passa a ser contado novamente. No instante seguinte, a operao a ser testada realizada e, ao ser concluda, o timer encerrado. O tempo efetivamente gasto pela operao obtido pelo tempo gasto na operao subtrado do tempo necessrio para acessar o timer.
timer.start() timer.stop() latenciaTimer = timer.getDuration(); //Calcula o tempo gasto para acessar o timer. timer.reset(); //Inicio do clculo do tempo para execuo de uma operao. timer.start(); bean.empty(); //O teste verifica o tempo gasto para invocao de empty(); timer.stop(); tempoMetodo = timer.getDuration(); timer.reset(); tempoTeste = tempoMetodo latenciaTimer; //Tempo efetivo da invocao.

FIGURA 6.1 Clculo do tempo para uma operao.

6.3. Procedimento de Teste


Os testes efetuados nesse trabalho foram realizados utilizando-se um estgio de warm-up antes da medio efetiva do tempo. Esse estgio foi necessrio para garantir resultados repetveis. O perodo de aquecimento necessrio para aplicaes Java em razo dos processos relacionados a Java Virtual Machine, pois quando uma aplicao Java lanada a JVM

58 necessita carregar atravs do ClassLoader as classes utilizadas pela aplicao. Alm disso, durante a execuo de uma aplicao Java, conforme o nmero de vezes que uma regio do bytecode invocada, o compilador JIT realiza a compilao para cdigo nativo. Esse processo de compilao alterava significativamente os resultados dos testes. A partir de experimentos realizados nesse trabalho, identificou-se que a definio de um warm-up com n = 100 era suficiente para evitar que operaes relacionadas ao compilador JIT influenciassem nos resultados obtidos. Para um n = 100, foi necessrio adicionar o parmetro -XX:CompileThreshold=50 na execuo da JVM; esse parmetro define o limiar de compilao para cdigo nativo em um valor igual a 50, ou seja, cada regio do cdigo invocada 50 vezes era compilada para cdigo nativo. O valor 100 foi utilizado para evitar que operaes do garbage collector e a finalizao das operaes de compilao do JIT influenciassem nos resultados obtidos. A adio dos parmetros -ms768M -mx1024M evitou o aumento dinmico no tamanho do Heap evitando grandes variaes nos resultados dos testes.

6.4. Resultados Obtidos


Nessa seo so apresentados os resultados obtidos nos experimentos definidos ao longo desse captulo. Deve-se destacar que o EasyBeans, verso Milestone 1, disponvel para a realizao dos testes de componentes EJB 3.0 apresentou certos problemas que obrigaram algumas vezes o reincio das mquinas e, tambm, a repetio de alguns testes devido a bugs no servidor EJB. O JOnAS no apresentou qualquer instabilidade durante os testes de EJB 2.1. 6.4.1. Lookup de componentes Session Beans O primeiro critrio avaliado corresponde ao tempo para lookup de componentes session bean. Esse critrio foi dividido em dois tipos: lookup do tipo stateless e lookup do tipo stateful. O nmero de testes necessrios(n) e o tempo mdio so apresentados nas TABELA 6.1 e TABELA 6.2. A representao grfica dos resultados pode ser visualizada nas FIGURA 6.2 e FIGURA 6.3. TABELA 6.1 Tempo mdio de lookup do tipo stateless
Localizao Clientes Local Remoto Local Remoto 1 1 5 5 n 148,83 294,16 304,19 2 338,69 EJB 2.1 Tempo Mdio(ms) 1,752643609 2,302799441 4,449132666 5,638579077 n 165,36 178,24 602,38 33 067,30 EJB 3.0 Tempo Mdio(ms) 0,77338149 1,147083906 1,802950885 2,616422816

59

FIGURA 6.2 Lookup de um stateless session bean Conforme anlise da FIGURA 6.2, identifica-se que o EasyBeans aproximadamente 2 vezes mais rpido em relao ao JOnAS para todos os casos do tipo stateless. Ressalta-se que o desempenho do EasyBeans para esse tipo de teste deve apresentar melhoras nas suas prximas verses, pois, atualmente, somente o JOnAS apresenta a otimizao chamada de pooling, ou seja, a criao de uma certa quantidade de instncias de componentes stateless antes de sua invocao pelos usurios. TABELA 6.2 Tempo mdio de lookup do tipo stateful
EJB 2.1 Localizao Clientes Local Remoto Local Remoto 1 1 5 5 n 2 015,42 340,35 233,00 23 417,00 Tempo Mdio(ms) EJB 3.0 Tempo Mdio(ms) 0,644057648 1,094658917 2,285515794 2,579962754

n 160,29 1 061,45 507,88 24 195,23

2,129351687 3,006748530 6,206572837 8,006195368

FIGURA 6.3 - Lookup de um stateful session bean

60 O EasyBeans, conforme a anlise da FIGURA 6.3, apresenta um desempenho aproximadamente 2,5 vezes superior ao JOnAS para todos os casos de lookup de componentes do tipo stateful. A partir da anlise dos resultados de lookup para os dois tipos, identifica-se que o EasyBeans apresenta um melhor desempenho de modo geral na invocao de componentes session. Isso est relacionado, conforme descrito anteriormente, eliminao da obrigao de implementao dos mtodos relacionados ao ciclo de vida e, tambm, abordagem de criao de um proxy entre o cliente e o EasyBeans. O uso de proxy elimina a necessidade do uso do mtodo PortableRemoteObject.narrow(), obrigatrio na verso 2.1. 6.4.2. Invocao de mtodos de componentes Session Beans A avaliao da invocao de mtodos de componentes do tipo session foi dividida em trs tipos. A diferena entre os tipos est relacionada entre o parmetro que o mtodo recebe e o tipo de resposta que eles apresentam. O primeiro tipo definido pela invocao de um mtodo que no recebe parmetros e no apresenta um valor de retorno. Alm disso, ele no realiza processamento algum no lado do servidor. O segundo tipo caracterizado por no receber nenhum parmetro, mas apresenta como resposta um valor do tipo String. No servidor, o componente apenas retorna um valor constante definido no bean. O terceiro tipo consiste em um mtodo que recebe um valor do tipo String como parmetro e retorna esse mesmo valor para o cliente. No servidor, o componente apenas retorna o valor enviado pelo cliente. A partir da definio dos trs tipos avaliados, apresentam-se os resultados obtidos nas TABELA 6.3, TABELA 6.4 e TABELA 6.5. A representao grfica apresentada nas FIGURA 6.4, FIGURA 6.5 e FIGURA 6.6. O EasyBeans, apesar de ter apresentado um desempenho superior ao JOnAS para invocao de componentes, demonstrou-se ter um desempenho inferior para invocao de mtodos. Destaca-se que as maiores diferenas de desempenho foram encontradas no tratamento da invocao de mtodos quando mltiplos cliente foram utilizados, esse fato provavelmente est relacionado a estabilidade do JOnAS em relao ao EasyBeans. Enquanto o JOnAS j tem disponvel 4 verses estveis, o EasyBeans ainda no atingiu uma verso beta. Um comportamento interessante encontrado no JOnAS est relacionado ao terceiro tipo de invocao avaliado: mesmo apresentando parmetro e valor de retorno, esse tipo apresentou um melhor desempenho em relao ao outros dois tipos. Esse fato no se repetiu no EasyBeans. TABELA 6.3 Tempo mdio de invocao de um mtodo sem parmetro e resultado
Localizao Local Remoto Local Remoto Clientes 1 1 5 5 n 577,92 223,53 965,84 3 020,17 EJB 2.1 Tempo Mdio(ms) 0,420317993 0,537771032 0,467389012 0,571674784 n 218,47 14 033,14 563,71 11 592,45 EJB 3.0 Tempo Mdio(ms) 0,744100821 1,158926178 1,585841597 2,716758288

61

FIGURA 6.4 Invocao de um mtodo sem parmetro e sem resultado TABELA 6.4 Tempo mdio de invocao de um mtodo sem parmetro, mas com resultado
Localizao Local Remoto Local Remoto Clientes 1 1 5 5 n 372,87 139,88 958,31 1 021,19 EJB 2.1 Tempo Mdio(ms) 0,433930623 0,542964009 0,545019784 0,634928961 n 311,50 169,04 977,27 13 133,96 EJB 3.0 Tempo Mdio(ms) 0,756978837 1,173398263 2,545491085 2,775377312

FIGURA 6.5 Invocao de um mtodo sem parmetro, mas com resultado TABELA 6.5 Tempo mdio de invocao de um mtodo com parmetro e resultado
Localizao Local Remoto Local Remoto Clientes 1 1 5 5 n 195,08 228,68 1 250,16 585,61 EJB 2.1 Tempo Mdio(ms) 0,334473560 0,478877206 0,385148295 0,558071274 n 15 001,53 207,22 298,38 10 772,56 EJB 3.0 Tempo Mdio(ms) 0,762228471 1,422367901 1,813573987 2,799684836

62

FIGURA 6.6 Invocao de um mtodo com parmetro e com resultado 6.4.3. Invocao de mtodo transacional gerenciado pelo continer Esse critrio correspondeu a avaliao de um mtodo que utiliza um servio JDBC em um contexto transacional. O mtodo solicita uma conexo do servio JDBC e ento solicita o seu fechamento. Nesse critrio, conforme explicado anteriormente, o continer responsvel por gerenciar o commit da transao. Os resultados obtidos so apresentados na TABELA 6.6 e na FIGURA 6.7. Avaliando-se os valores obtidos, identificou-se que o JOnAS, novamente, apresenta um desempenho superior ao EasyBeans. Conforme descrito nos captulos anteriores, no houve mudanas significativas entre a verso 2.1 e 3.0 nesse tpico, em razo disso, espera-se que nas prximas verses o desempenho dos componentes EJB 3.0 apresentem uma melhora de desempenho. Um fato importante identificado est relacionado ao nmero de clientes utilizados nos testes. Para o JOnAS, o nmero de clientes no provoca grande variao no desempenho obtido, o que demonstra a estabilidade desse servidor. TABELA 6.6 Tempo mdio de invocao de um mtodo com transao demarcada pelo continer
Localizao Clientes Local Remoto Local Remoto 1 1 5 5 n 325,60 170,68 422,51 803,01 EJB 2.1 Tempo Mdio(ms) 0,432439815 0,724094423 0,692666021 0,727763371 n 182,41 577,21 2 158,37 8 108,26 EJB 3.0 Tempo Mdio(ms) 1,301373499 1,340843031 3,029385106 3,304095993

63

FIGURA 6.7 Invocao de um mtodo com transao demarcada pelo continer 6.4.4. Invocao de mtodo transacional gerenciado pelo bean Esse critrio de avaliao distingue-se do anterior devido ao modo de controle da transao. Nesse caso, o desenvolvedor, atravs do uso do objeto UserTransaction, demarca o incio e o fim da transao. Para os testes realizados, o mtodo invocado inicia uma transao, abre uma conexo ao servio JDBC, fecha a conexo ao servio JDBC e ento finaliza a transao com um commit. Desse modo, a nica diferena entre o critrio anterior a adio de um mtodo para demarcar o incio da transao e um mtodo para demarcar o fim da transao. Os resultados obtidos so apresentados na TABELA 6.7 e na FIGURA 6.8. A partir da anlise dos valores obtidos, destaca-se novamente o melhor desempenho de componentes EJB 2.1 no JOnAS em relao a componentes EJB 3.0 no EasyBeans. Em comparao ao critrio anterior, destaca-se um aumento de custo para o tratamento desse tipo de mtodo quando mltiplos clientes so utilizados. Para um nico cliente, o tipo BMT apresentou um desempenho superior ao CMT; entretanto, para mltiplos clientes o tipo BMT apresentou um desempenho inferior ao CMT. A utilizao desse tipo de demarcao permite que apenas uma regio do mtodo esteja contida em uma transao, o que torna mais flexvel essa abordagem em relao a demarcao pelo continer. TABELA 6.7 Tempo de invocao de um mtodo com transao demarcada pelo bean
Localizao Local Remoto Local Remoto Clientes 1 1 5 5 n 163,11 197,87 7 132,82 967,68 EJB 2.1 Tempo Mdio(ms) 0,417593200 0,706618057 0,825638244 0,824485572 n 261,45 528,09 9 103,01 15 894,60 EJB 3.0 Tempo Mdio(ms) 1,036123567 1,438785823 3,283691911 3,375917687

64

FIGURA 6.8 Invocao de um mtodo com transao demarcada pelo bean 6.4.5. Localizao de um componente Entity Bean A localizao de um componente entity bean foi construda utilizando-se um pattern do Java EE denominado de Session Facade. Esse pattern, segundo [SUN 06d], encapsula a complexidade de interao entre componentes participantes de um workflow. Os resultados so apresentados na TABELA 6.8 e na FIGURA 6.9. A partir da anlise dos valores obtidos, pode-se identificar um melhor desempenho para o componente EJB 3.0 no EasyBeans em relao ao componente EJB 2.1 no JOnAS. A razo pelo melhor desempenho de um componente EJB 3.0 est relacionada a simplificao existente na verso 3.0 e ao provedor de persistncia utilizado. Na verso 2.1, um componente do tipo entity era localizado pela realizao de um lookup no objeto home do componente e nesse objeto utilizando-se um mtodo do tipo select era possvel encontrar o entity desejado. Na verso 3.0, com a introduo do Entity Manager, a localizao de um componente pode ser feita atravs da criao de uma consulta pelo uso do mtodo createNamedQuery que recebe como parmetros os critrios de seleo e retorna um objeto do tipo Query. Nesse objeto, utilizando-se o mtodo getResultList pode-se obter o componente procurado. No JOnAS, o mecanismo de persistncia utilizado foi desenvolvido pela ObjectWeb. No EasyBeans, o mecanismo de persistncia acoplado para os testes foi o Hibernate verso 3.2.0.CR2. TABELA 6.8 Tempo mdio de localizao de um componente entity bean
Localizao Local Remoto Local Remoto Clientes 1 1 5 5 n 15 255,65 229,93 12 283,28 10 836,00 EJB 2.1 Tempo Mdio(ms) 1,444719059 1,693164827 5,685127157 5,822466261 n 285,82 161,22 5 268,58 9 376,57 EJB 3.0 Tempo Mdio(ms) 1,357104385 1,573466763 4,379730728 4,491084368

65

FIGURA 6.9 Localizao de um componente entity bean

66

7. Concluso
Os resultados desse trabalho indicam que a verso 3.0 traz importantes melhorias do ponto de visto do desenvolvedor. Essas melhorias representam um aspecto importante para o aumento da aceitao da arquitetura EJB. Alm disso, os resultados relacionados ao desempenho tambm indicam avanos nessa rea; entretanto, a verso 2.1 ainda apresenta melhores resultados em certos pontos. A partir da anlise textual desenvolvida nos captulos 3 e 4 foi possvel identificar as principais mudanas entre a verso 2.1 e 3.0 da arquitetura EJB, na qual se destaca o uso de anotaes para reduzir a quantidade de arquivos de configurao representados pelos descritores XML. Em adio, essa anlise textual permitiu uma viso objetiva das diferenas existente entre as duas verses, evitando-se a leitura de suas especificaes que so bastante extensas. Apesar da anlise textual, o desempenho de diferentes verses tambm se apresentou como um fator relevante na deciso de utilizao de uma tecnologia. Desse modo, uma anlise de desempenho foi realizada para atender a esse requisito e identificou-se que a evoluo da arquitetura tambm trouxe ganhos em certos pontos no quesito de desempenho. Inicialmente, a realizao dos testes de desempenho exigiu um estudo experimental para a garantia de estabilidade nos resultados obtidos. Esse estudo inicial permitiu a definio de configuraes na JVM para a garantia de resultados repetveis e a correo atravs de semforos de problemas de concorrncia encontrados no uso de mltiplos clientes com o EasyBeans. A partir do estudo inicial, com a realizao dos testes, pode-se identificar que o EasyBeans, implementao utilizada da verso 3.0 da arquitetura EJB, apresenta desempenho superior nos aspectos de lookup e localizao de componentes entity beans quando comparado ao JOnAS, implementao utilizada da verso 2.1 da arquitetura EJB. Entretanto, em relao invocao de componentes, os componentes na verso 2.1 apresentaram melhor desempenho. Em razo do atual nvel de desenvolvimento do EasyBeans, o qual ainda no atingiu uma verso beta, espera-se uma melhora no desempenho no fator de invocao de componentes. Para confirmar essa expectativa, como trabalho futuro, torna-se importante a repetio dos testes realizados sobre novas verses, possivelmente mais estveis que a verso utilizada. Alm disso, deve-se estender os testes para diferentes implementaes da arquitetura, o que permitiria uma viso mais global do desempenho das diferentes verses. Por fim, essa anlise identificou simplificaes relevantes na verso 3.0 da arquitetura EJB para a reduo significativa da complexidade para sua utilizao, alm de uma melhoria de desempenho em certos aspectos. Entretanto, devido recente publicao dessa nova verso, deve-se aguardar a finalizao das primeiras implementaes da verso 3.0 para que seja possvel, de maneira segura, tomar uma deciso sobre sua adoo atravs da realizao de novos estudos e testes.

67

Referncias Bibliogrficas
[CAS 06] CASTRO, E.S.E. de, SOUZA, G. P. Report of the "Projet de Fin dEtudes" - EasyBeans Conformance Test to the JSR 220: Enterprise JavaBeans, Version 3.0. Grenoble, 2006. [CEC 02] CECHET, E.; MARGUERITE, J.; ZWAENPOEL, W. Performance and Scalability of EJB Applications. Proceedings of the 17th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, Seattle, 2002. p. 246-261. [LIL 04] LILJA, D.J. Measuring Computer Performance A practitioners guide. 1st ed. Cambridge: Cambridge University Express, 2004. [HEI 01] HEINMAN, G.T. and Council, W. T. Component-based Software Engineering: Putting the pieces together. 1st ed. Massachusetts: Addison-Wesley Professional, 2001. [HER 98] HERICKO, M.; JURIC, M.; ZIVKOVIC, A.; ROZMAN, I.; DOMAJNKO, T.; KRISPER, M. Java and Distributed Object Models: An Analysis. SIGPLAN Notices, vol. 33, 1998. p. 57-65. [HIR 98] HIRANO, S; YASU, Y.; IGARASHI, H. Performance Evaluation of Popular Distributed Object Technologies for Java. Concurrency: Practice and Experience, vol. 10, 1998. p. 927-940. [JUR 99] JURIC, M.B; WELZER, T.; ROZMAN I.; HERICKO, M.; BRUMEN B.; DOMAJNKO, T.; ZIVKOVIC, A. Performance Assessment Frameworks for Distributed Object Architectures. Advances in Databases and Information Systems, Third East European Conference, ADBIS' Maribor, Slovenia, September 13-16, 99, 1999. p. 349-366. [KOB 00] KOBRYN, C. Modeling Components and Frameworks with UML. Communications of the ACM, vol 43, no. 10. Outubro de 2000. p. 31-38. [PAN 06] PANDA, D. Simplifying EJB Development with EJB 3.0. Disponvel http://www.oracle.com/technology/tech/java/newsletter/simplifying_ejb3.html. em Acessado em: jul. 2006 [PAW 04] PAWLAK, R; RETAILLE J.; SEINTURIER L. Programmation Oriente aspect pour Java/J2EE. 1m France: Groupe Eyrolles, 2004. [PET 05] PETER, Z.; KODALI, R. R. The Performance of EJB 3.0. Disponvel em http://java.sys-con.com/read/131767_2.htm. Acessado em: sep. 2006. [PRI 04] PRINTEZIS, T. Garbage Collection in the Java HotSpot Virtual Machine. Disponvel em http://www.devx.com/Java/Article/21977/0/page/1. Acessado em: sep. 2006. [ROM 05] ROMAN, E.; SRIGANESH, R.P.; BROSE, G. Mastering Enterprise JavaBeans. 3rd ed. Indiana: Wiley Publishing, 2005. p. 40. [SRI 06] SRIGANESH, R.P.; BROSE, G.; SILVERMAN, M. Mastering Enterprise JavaBeans. 4th ed. Indiana: Wiley Publishing, 2006.

68 [ROU 03] ROUBTSOV, V. My kingdom for a good timer: reach submillisecond timing precision in Java. Disponvel em: http://www.javaworld.com/javaqa/200301/01-qa-0110-timing_p.html. Acessado em: jun. 2006. [SUN 03] SUN MICROSYSTEMS. Enterprise JavaBeans Specification, v2.1, Final Release. Disponvel em: http://jcp.org/aboutJava/communityprocess/pr/jsr220/. Acessado em: mar. 2006. [SUN 05a] SUN MICROSYSTEMS. The Java 2 Platform Specification, v5.0, Public Review. Disponvel em: http://jcp.org/aboutJava/communityprocess/pr/jsr244/. Acessado em: abr. 2006. [SUN 05b] SUN MICROSYSTEMS. JSR220: Enterprise JavaBeans Specification, v3.0, EJB Core Contracts and Requeriments, v3.0 Proposed Final. Disponvel em: http://jcp.org/aboutJava/communityprocess/pr/jsr220/. Acessado em: mar. 2006. [SUN 05c] SUN MICROSYSTEMS. JSR220: Enterprise JavaBeans Specification, v3.0, Java Persistence API Proposed Final. Disponvel em: http://jcp.org/aboutJava/communityprocess/pr/jsr220/. Acessado em: mar. 2006. [SUN 05d] SUN MICROSYSTEMS. JSR220: Enterprise JavaBeans Specification, v3.0, Simplified API Proposed Final. Disponvel em: http://jcp.org/aboutJava/communityprocess/pr/jsr220/. Acessado em: mar. 2006. [SUN 06a] SUN MICROSYSTEMS. The Java EE 5 Tutorial. Disponvel em: http://java.sun.com/javaee/5/docs/tutorial/doc/. Acessado em: mai. 2006. [SUN 06b] SUN MICROSYSTEMS. JSR220: Enterprise JavaBeans Specification, v3.0, EJB Core Contracts and Requeriments, v3.0 Final Release. Disponvel em: http://jcp.org/aboutJava/communityprocess/pr/jsr220/. Acessado em: mai. 2006. [SUN 06c] SUN MICROSYSTEMS. JSR220: Enterprise JavaBeans Specification, v3.0, Java Persistence API Final Release. Disponvel em: http://jcp.org/aboutJava/communityprocess/pr/jsr220/. Acessado em: mai. 2006. [SUN 06d] SUN MICROSYSTEMS. Core J2EE Patterns. Disponvel em: http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html. Acessado em: jun. 2006. [TRI 99] TRIOLA, Mario F. Introduo Estatstica. Rio de Janeiro: LTC Livros Tcnicos e Cientficos Editora S.A., 1999. p. 208.

69

ANEXO 1 Exemplo de Anotaes de Metadados


@Stateless usada para indicar que o bean do tipo session stateless. @Remote indica que a interface de negcios que ser disponibilizada para clientes remotos corresponde a ItfSay.
@Stateless @Remote(ItfSay.class) public class HelloWorld implements ItfSay{ public String say (String s) { System.out.println("Say: "+s); } }

//Inteface ItfSay public interface ItfSay{ public String say (String s); }

Você também pode gostar