UNIVERSIDADE FEDERAL DO PARÁ CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

Helder Klemp Correa da Silva Viviane Soares Grieco

TÉCNICAS DE PLANEJAMENTO EM ARQUITETURAS: SOLUÇÕES UTILIZANDO J2EE, AOP E IOC

Belém - PA 2006

UNIVERSIDADE FEDERAL DO PARÁ CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

Helder Klemp Correa da Silva Viviane Soares Grieco

TÉCNICAS DE PLANEJAMENTO EM ARQUITETURAS: SOLUÇÕES UTILIZANDO J2EE, AOP E IOC

Trabalho

de

Conclusão

de

Curso

apresentado para obtenção do grau em Bacharel em Ciência da Computação. Orientador: Prof. Esp. Fernando Nazareno Nascimento Farias

Belém - PA 2006

UNIVERSIDADE FEDERAL DO PARÁ CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

Helder Klemp Correa da Silva Viviane Soares Grieco

NOVAS TÉCNICAS DE PLANEJAMENTO EM ARQUITETURAS DISTRIBUÍDAS: SOLUÇÕES UTILIZANDO J2EE, AOP E IOC

Trabalho de Conclusão de Curso apresentado para obtenção do grau em Bacharel em Ciência da Computação Data da defesa: 25 de abril de 2006. Conceito:

Banca Examinadora: Prof. Esp. Fernando Nazareno Nascimento Farias Departamento de Informática / UFPA – Orientador Prof. MsC. Alfredo Braga Furtado Departamento de Informática / UFPA – Membro Prof. MsC. Arnaldo Prado Jr. Departamento de Informática / UFPA – Membro

que sempre estiveram ao meu lado. Às minhas irmãs. carinho e companheirismo. Aos meus amigos. que me mostraram o caminho a seguir. [Viviane]: Agradeço a Deus. Ao meu noivo pela ajuda. Aos professores da UFPA. Aos meus irmãos pelo exemplo a ser seguido e pela força. amor. Aos amigos que aprendi e aprendo sempre. e que me ajudou no presente trabalho. me dando forças e saúde para seguir em frente. E um agradecimento especial à minha noiva. pelo companheirismo e incentivo. carinho e paciência sempre presente.AGRADECIMENTOS [Helder]: Agradeço a Deus. Aos meus pais. auxiliando no meu crescimento profissional. que sempre me acompanhou nas difíceis jornadas da vida. pela ajuda e paciência no desenvolvimento deste trabalho. À minha mãe. que me deram a melhor herança que se pode ter. que sempre esteve e estará ao meu lado. Aos professores. me deram educação e respeito. pelos ensinamentos ao longo dos cinco anos de curso. . Ao meu orientador. que está presente em todas as ocasiões boas e ruins. pelo amor.

"Cada momento da nossa vida é um ensaio para o que vem a seguir". Marcio Giulierme .

..........................65 5..... Programação Orientada a Aspectos....1..... Arquitetura X Designer ......4...........2...................................................1..........39 3................1..... EJB e o modelo de container ........................2...3.... Interface Injection................3............................................................. Técnica Estrutural........................71 5......................48 4..................................... Utilizando IBatis com Spring ..............3......47 4....... Patterns de camada de Integração....................................... Técnica Funcional......................................... Arquiteturas J2EE........ Inversão de Controle ............................. Padrões J2EE ......................................18 1.................. Acesso a dados em aplicações J2EE .......15 Capítulo 1..................... Princípios Arquiteturais ....................................4....... Padrões GoF..........20 1.24 Capítulo 2.......1............... Princípios de arquiteturas.. Aplicando a tecnologia J2EE e seus problemas .3........................................................ Session Beans....3...........54 5................... Entity Bean .72 6 ................................. Uso de arquiteturas leves com a adoção de novos conceitos.......2..31 2.............................. 26 2.....................66 5........2.48 4...................... Gerenciamento de transações ........1..........30 2..... Benefícios e Problemas do uso de Padrões de Projeto .........45 4................... Quando aplicações distribuídas são apropriadas?.........................1............2.....................................3.41 3............................... Aplicações Distribuídas e Escalabilidade ................ 17 1........3.. Camada de acesso a dados simplificada ........1..................... Testes na metodologia Extreme Programing (XP)..3.................1...3.....64 5.......... Constructor Injection x Setter Injection .4.1.....56 5............ 45 4..... Capacidades de uma arquitetura.....................2............................ Formas de implementação de Inversão de Controle ......................... Constructor Injection .1.....1.................................. Aspectos negativos de EJB.........2......32 Capítulo 3......4.........37 3.........54 5................... 34 3......39 3.................................................3.......................4................. Utilizando Hibernate com Spring ........................2................66 5.....................2................2 Testes de Aceitação. Aplicações Distribuídas e Confiabilidade ...................................3..................3........................2.......54 5...............2....52 5..............50 Capítulo 5.. Setter Injection .......................................................49 4........4......................2........................2...1.................................1............................4.35 3... Arquitetura no Processo de Desenvolvimento de Sistemas....1.......61 5........................................................3.......................1........2......................................................45 4......................................... Quando se deve usar EJB? ...2................................. Message Driven Bean ...........................3....................................... Testabilidade em Aplicações J2EE....57 5............................................................................3.................................... Testes Unitários no XP................ 52 5........1......................... Padrões de Projetos e melhores práticas para projetos J2EE ...........2..............................................3............................................1.......................................................................1.......................34 3.............................. Performance com EJB .......1.........................................3........................................ Patterns da camada de apresentação ......................3..........21 1..............2...............4....27 2........................................1..............................2.....64 5............69 5...........28 2........................................................................................................... Testes com EJB.....28 2.............68 5.................................................1.... Tipos de EJB...........6 SUMÁRIO Introdução.............2. Container WEB em J2EE ..................................................3.......2..............................................5.... Diminuição de Acoplamento ..............42 Capítulo 4.1...............3....................... Patterns de camada de negócios ................................60 5...........................................................................62 5.......................2....1..

..7...................86 Referências Bibliográficas ..............78 Capítulo 6........................... Gerenciamento robusto e elegante de Transações.........................74 5....................1.....................................1.......................7 5. Realização de testes de carga em aplicações usando arquiteturas EJB e arquiteturas leves em J2EE............................................. Importância dos Testes de Carga .....1...............6.... Uso de mensagens Assíncronas.....................................................76 5............. Message Driven Pojos (MDP)......................................................2.87 7 ...................................5............................................73 5.......................................................................................................81 Conclusão ..................................80 6...................7.... Testes de Carga ........80 6......................... Programação Orientada a Aspectos com Spring .....................

.4: Gráfico de resultados obtidos na aplicação que utiliza EJB.........1: Processo de desenvolvimento em cascata...2: Modelo de Pools de EJB de sessão...................3: Camadas arquitetônicas de um sistema..................3: Gráfico de resultados obtidos na aplicação que utiliza Spring................................................2: Fluxo da aplicação desenvolvida......... 19 20 21 Figura 3... 40 Figura 3..............2: pontos onde as atividades de arquitetura são mais visíveis....... Figura 5.............. Figura 6..............................................................................................1: Funcionamento dos testes funcionais.1: Arquitetura J2EE robusta e escalável.................. Figura 5.............. 43 47 62 63 76 80 81 83 Figura 5.. 78 Figura 6...................................... Figura 4......... 34 Figura 3.......... Figura 1.................... Figura 5....................................................................................4: Funcionamento do MDP................. Figura 6....................................3: Arquitetura básica de uma JMS........................... Figura 1............................................1: Interface do JMeter......................................................3: Funcionamento de um Message Driven Bean..2: Funcionamento de testes unitários............................. 82 8 ...............8 LISTA DE FIGURAS Figura 1...... Figura 6.............1: Interação entre cliente e servidor Web.............................

2: Tabela comparativa na aplicação que utiliza EJB.1: Tabela comparativa na aplicação que utiliza Spring... 62 Tabela 5.......................2: Tabela comparativa das três alternativas de testes com EJB. 81 82 9 ............. 67 Tabela 6..........................1: Comparativo entre ferramentas de teste funcional...... Tabela 6..................9 LISTA DE TABELAS Tabela 5...............

...................xml).... Listagem 5............................................1: Código de acesso a componentes EJB..: Arquivo Java de configuração de injeção......: Classe onde será feita a injeção através do construtor.........xml)..........10 LISTAGENS Listagem 5................... Listagem 5...............3......12................... Listagem 5...............................: Arquivo XML com configuração da injeção....................7.................................9.........................xml)....................... Listagem 5............................................................................. Listagem 5.....11..........................................10................................... 70 Listagem 5.......... Listagem 5........: Exemplo de classe que implementa o método setter.......... Listagem 5......4.... passa a ter a lógica no seu construtor.........................: Classe que implementa a interface do interface injection................... 75 71 70 57 57 57 69 55 56 56 54 55 Listagem 5.......................6... Listagem 5.....................................2: Exemplo de Interface com método findAll.....................................: Interface que irá injetar objetos através do Interface Injection.. 55 52 54 54 Listagem 5....................... Listagem 5..............: Classe que implementa a interface da listagem 5.......................... Listagem 5....8...................................................................18: Arquivo de configuração de demarcação transacional para os métodos do serviço..14: Configuração de DataSource para uso de Spring com hibernate............................5........: Classe onde ao invés de receber um atributo............11... Listagem 5.....13.......................................: Arquivo de configuração para o Interface Injection....................17: Exemplo de arquivo de mapeamento de um determinado Bean (Client.......16: Trecho do arquivo de declaração dos mapeamentos (sqlMapConfig.......................................................................: Exemplo de classe que possui um atributo posteriormente injetado................................................. Listagem 5.. Listagem 5.15: Trecho do arquivo de configuração do Spring com IBatis (strutsconfig............... Listagem 5................: Interface que deverá ser implementada..... 58 10 ......

11 LISTA DE SIGLAS AOP API ASP BMP CMP DAO DBMS EIS EJB GOF HQL HTML http IDE IIOP IOC J2EE JDBC JMS JNDI JSP JTA LDAP LRU MDB MDP MVC POJO RMI RPC SQL XML XP 11 Programação Orientada a Aspectos Application Programming Interface Active Server Pages Bean Manager Persistence Container Manager Persistence Data Acess Object Database Manager System Enterprise Information System Enterprise Java Beans Gang Of Four Hibernate Query Language Hyper Text Markup Language HyperText Transfer Protocol Integrated Development Environments Internet Inter-Orb Protocol Inversion of Control Java2 Platform Enterprise Edition Java Database Connectivity Java Message Service Java Naming and Directory Interface Java Server Pages Java Transaction API Lightweight Directory Acess Protocol Last Recent Used Message Driven Bean Message Driven Pojo Model-View-Controller Plain Old Java Objects Remote Method Invocation Remote Procedure Call Structured Query Language Extensible Markup Language Extreme Programing .

vem se tornando cada vez mais presente o uso de técnicas que visam um menor esforço para a arquitetura e o desenvolvimento de sistemas distribuídos. em oposição aos atuais servidores de aplicação. Palavras-chaves: Arquitetura de Software. Spring. como Inversão de Controle. Sistemas Distribuídos. agregado a isso. Escalabilidade. usando de novos conceitos. podem-se citar o uso de padrões de projeto para evitar a repetição desnecessária de código e aumentar a modularização aliado à conceitos novos de arquiteturas de software. Inversão de Controle.12 RESUMO No cenário atual do desenvolvimento de sistemas distribuídos. tal como Containeres Leves. Com isso. 12 . Dentre essas técnicas. que promove uma grande diminuição de acoplamento entre as camadas de um sistema. uma série de regras surgem tornando o desenvolvimento mais burocrático. A atual arquitetura J2EE disponível fornece ao arquiteto desenvolvedor uma grande variedade de alternativas. porém. EJB. e a prática de Inversão de Controle. O presente trabalho visa esclarecer os pontos negativos da arquitetura J2EE e propor uma arquitetura mais simples. percebe-se uma árdua e burocrática necessidade de codificação e manutenção de código. Padrões de Projeto. container leve e Orientação a Aspectos. J2EE.

J2EE. in opposition to the current application servers. as light container.13 ABSTRACT In the current scene in the development of distributed systems. one perceives an arduous and bureaucratic necessity of codification and maintenance of code. Distributed Systems. a series of rules appears becoming the development most bureaucratic. using of new concepts. that promotes a great reduction of coupling between the system layers. can be cited the use of design patterns to prevent the unnecessary code duplication and to increase the modularity ally to the new concepts of software architectures. added to this. Scalability. such as Light Containers. Current available architecture JÈE supplies to the developer architect a great variety of alternatives. Inversion of Control and Aspects Orientation. With this. 13 . Amongst these techniques. Spring. Inversion of Control. however. Design Patterns. EJB. it comes if becoming each more present time the use of techniques that aim at a lesser effort for the architecture and the development of distributed systems. This work aims at to clarify the negative points of J2EE architecture and to consider a simpler architecture. Keywords: Software Architecture. and the use of Inversion of Control.

Mesmo com o “boom” causado pela Internet. tornando-se uma ótima opção para arquitetos de software elaborar aplicações robustas e de qualidade. as aplicações de legado3 com informações cruciais e que ainda estavam em produção. Nesse contexto. Termo utilizado para evidenciar arquiteturas que não possuem grande processamento em seus clientes.14 Introdução Ao longo dos anos. visto que as mesmas funcionam perfeitamente. diversas empresas viram nesta grande rede uma forma de expor seus serviços para uma quantidade infinita de consumidores. Antes da explosão da Internet. na maior parte das vezes rodavam em um mainframe1 com várias estações magras2 que apenas acessavam os dados. iniciou-se a demanda para aplicações mais ricas e mais agradáveis para o cliente. Com a explosão da Internet. diversos fatores devem ser levantados acerca de arquiteturas expostas para a Internet. Levando-se em consideração que essas interfaces eram extremamente pobres. tornou-se padrão o desenvolvimento de arquiteturas em duas camadas (uma sendo o servidor de banco de dados e a outra seria a camada de apresentação). a arquitetura J2EE vem se mostrando um padrão aberto de especificações que contemplam uma fácil conectividade com outras aplicações como interação maleável com o usuário e um modelo flexível de componentes de negócio. dedicado normalmente ao processamento de um volume grande de informações. tampouco seria viável uma reescrita dessas aplicações. normalmente sistemas e hardware antigos de empresas que guardam uma grande quantidade de informação. 1 2 Computador de grande porte. Uma solução para a disponibilização dos “livros de registros” e para o desenvolvimento de novas funcionalidades para a Internet é uma arquitetura que se conecte facilmente a dados existentes. o processo de desenvolvimento de software está em constante evolução e mudança. Porém. fica claro que não se podia abandonar os “Livros de Registros”. para uma vasta gama de usuários acessando através de diversas formas interativas como Internet. Além da popularização de bancos de dados relacionais e o surgimento de aplicações gráficas no cliente. telefone celular. entre outros. uma vez que uma quantidade enorme de acessos ao sistema não pode diminuir sua qualidade de resposta. a maioria das aplicações em produção eram centralizadas. 14 . por volta dos anos 90. 3 Termo com significado de herança.

percebeu-se que. solucionando alguns problemas encontrados no capítulo 4. porém de uma forma bem mais elegante e fácil de desenvolver e testar. Já o capítulo 4. dando ênfase em seu modelo de container usando os componentes EJB. à burocracia de seu desenvolvimento e manutenção e a pouca testabilidade de aplicações. que propõe uma arquitetura mais leve. Para se ter uma idéia. mostra as dificuldades encontradas no desenvolvimento de um sistema J2EE. Logo em seguida. no capítulo 6. por sua vez. além de solucionar de forma elegante diversos problemas da indústria de software. além desta introdução e da conclusão. 15 . são mostrados resultados comparativos de testes feitos em uma aplicação desenvolvida utilizando tanto os conceitos J2EE completos como arquiteturas leves. onde são apresentados conceitos básicos da arquitetura de um sistema. Dentre tais objetivos este documento está organizado em seis (6) seções. surgiram ao longo do tempo alguns problemas relacionados. Finalmente. o capítulo 1 apresenta os princípios arquiteturais. Uma série de novos conceitos é apresentada. além de apontar suas desvantagens e propor melhores práticas de desenvolvimento para amenizar a curva de esforço em sua fase de construção. O capítulo 3. com a adoção de plataformas J2EE. cujas soluções para estas dificuldades são propostas no capítulo 5. O presente trabalho aborda os princípios arquiteturais do J2EE. a fim de elaborar uma arquitetura que apresente todos os fundamentos do J2EE por completo. o capítulo 2 enfatiza os principais padrões de projeto utilizados.15 Porém. principalmente. apresenta uma proposta de arquitetura de sistemas voltados para a Web.

Com esta formalização. construir. faz-se necessária uma explanação sobre sua origem e seu significado tanto na área tecnológica como em outras áreas originais. a arquitetura de software é colocada como uma ferramenta para lidar com a complexidade do software e enfatizam que arquitetura deve satisfazer os requisitos funcionais e não-funcionais do sistema.16 Capítulo 1 Princípios Arquiteturais Muito se fala de arquiteturas de software. Eles criam a planta para os requisitos de sistema funcionais e não-funcionais. sejam edifícios. suas propriedades externas e os relacionamentos entre eles. A definição clássica de arquitetura apresentada por [SHA1996] diz que arquitetura de software define o que é o sistema em termos de componentes computacionais e os relacionamentos entre estes componentes. com a publicação do livro “Software Architecture. arquitetar e modelar. O termo era usado na Grécia antiga para designar o mestre de obras dos antigos templos gregos. A palavra “Arquiteto” tem origem grega. mas não registradas até então. para que não haja dúvidas seguintes no trabalho. A necessidade de várias visões e vários níveis de abstração na modelagem dos requisitos que serão implementados era percebida pelos projetistas. os arquitetos visualizam o comportamento de um sistema. auxiliando o gerenciamento da complexidade. constituindo uma abstração do sistema. surge também o papel do arquiteto de software. Semelhante a esta definição. porém. a formalização da arquitetura como uma disciplina de engenharia para o desenvolvimento de software começou com Mary Shaw e David Garlan. incrementando a definição de que arquitetura de software é o conjunto de componentes e seus 16 . Esta abstração suprime detalhes de componentes que não afetam a forma como eles são usados ou como eles usam outros componentes. Perspectives on an Emerging Discipline”. em 1996 [SHA1996]. Pode-se dizer que o objetivo do arquiteto é sempre reorganizar o ambiente. Mas qual seria o propósito do arquiteto nos dias de hoje? Segundo [ALL2003]. que significa “construtor chefe”. instituições ou teorias. Nesse contexto. Para [JAZ2000]. [BAS1998] diz que arquitetura de software são as estruturas que incluem componentes. vem de Architekton.

considerando: o Identificação dos componentes e suas interações.1. enquanto que o projetista se preocupa com os casos de uso de negócios. operando em um nível de abstração bem mais baixo visando à implementação de funcionalidades. as restrições de mercado (público-alvo) e interfaces com outros sistemas para que a arquitetura possa alcançar os objetivos do negócio. o arquiteto se preocupa com a não funcionalidade do sistema em um nível de abstração muito elevado. é possível notar que a arquitetura de software é mais do que a descrição dos componentes que a compõem e do relacionamento entre eles. • Entendimento dos requisitos: o arquiteto deve contribuir com as técnicas de levantamento de requisitos a fim de obter o modelo do domínio. Estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido. O processo de arquitetura de software compreende muitas atividades. a escolha ou elaboração de frameworks5 para o desenvolvimento de componentes. o Identificação das dependências de construção. • Criação ou seleção de uma arquitetura. convertendo os objetos de domínio em um modelo de objeto técnico. Deve-se levar em consideração que o papel do arquiteto é a elaboração da estrutura do sistema. dentre as quais é possível destacar [BAS1998]: • Elaboração do modelo de negócio para o sistema: o arquiteto deve contribuir com o seu conhecimento para analisar o custo do sistema. o Escolha de tecnologias que suportem a implementação. • Representação da arquitetura e divulgação: os participantes envolvidos precisam entender a arquitetura. 1. 17 . o tempo de desenvolvimento. Arquitetura X Designer Muitas pessoas levam a comparar o arquiteto com o designer (projetista) de software. seus design patterns4 arquiteturais. Portanto. A arquitetura é a interface entre duas partes distintas: o problema de negócio e a solução técnica [AST1998]. Os desenvolvedores e testadores necessitam compreender o trabalho que lhes foi atribuído e 4 5 Conceito visto no capítulo 2.17 relacionamentos.

riscos e dificuldades. • Implementação do sistema baseado na arquitetura: os desenvolvedores devem se restringir às estruturas e protocolos definidos na arquitetura. como subdivisão e sincronia. identificador de outros requisitos não-funcionais que a arquitetura deve atender e acompanhante do processo de desenvolvimento da arquitetura proposta. os modelos arquiteturais devem ser finalizados pelo arquiteto líder ou por uma equipe pequena de arquitetos. como módulos implementáveis e processo. 18 . Ela compreende outros tipos de estrutura. arquitetura de software. Isto significa que há mais que um tipo de componente. Arquiteto: criador da arquitetura do sistema (partição. há papéis bem definidos que são associados às pessoas que participam deste processo. Estas informações contribuem para a evolução da arquitetura em versões posteriores do sistema.18 o gestor deve entender as implicações do planejamento estratégico sugerido pelo arquiteto. divulgação). A importância disto se deve ao fato da arquitetura servir de apoio e guia para a construção do sistema. como ambiente de desenvolvimento e ambiente de operação [BAS1998]. registrando impactos. Os participantes (também referenciados como stakeholders) identificados são [BEN1996]: • • Analista de requisitos: identificador de requisitos funcionais e nãofuncionais do sistema. e mais que um contexto. • Análise ou avaliação da arquitetura: os arquitetos devem supervisionar e verificar a adequação da arquitetura. com um deles exercendo a liderança. prevenção de mudanças e evoluções. mostrando que arquitetura é mais do que o resultado de requisitos técnicos que implicam no desenho de infra-estrutura do sistema. Apesar de existirem vários participantes com papéis distintos na definição da arquitetura. mais que um tipo de interação entre os componentes. • Projetista (designer) e/ou Desenvolvedor: implementador dos componentes propostos no particionamento de acordo com a plataforma tecnológica escolhida. Isto contribui para a evolução da disciplina. Para cada uma das atividades que o processo da arquitetura de software propõe.

A diferença entre as fases de análise e de projeto e as atividades de arquitetura só são evidentes quando se trata de sistemas grandes e complexos.2 mostra o ponto onde as atividades da arquitetura são mais visíveis dentro do processo de desenvolvimento de sistemas. é necessário que a fase anterior seja totalmente concluída. conforme mostra a figura 1.19 1. a transição entre as fases de engenharia de requisitos. Para que uma fase seja iniciada. Para sistemas pequenos.2. pois os modelos gerados nestas fases são suficientes para representar os requisitos necessários. a experiência na construção de sistemas mostra que ainda existe uma lacuna de informações a serem especificadas para prosseguir com a fase de projeto. Arquitetura no Processo de Desenvolvimento de Sistemas O processo clássico de desenvolvimento de sistemas chamado waterfall (ou cascata) [PRE2001] que é encontrado na disciplina de Engenharia de Software possui uma seqüência de fases bem definidas que guiam o desenvolvimento de um sistema. Mesmo com a execução rigorosa das fases de engenharia de requisitos e de análise.1. Figura 1.1: Processo de desenvolvimento em cascata A figura 1. satisfazendo a construção do 19 . Isto significa que especificar e modelar o que o sistema deve fazer não é suficiente para saber como o sistema deve ser estruturado e organizado para satisfazer os requisitos funcionais e os atributos de qualidade. análise e projeto é tranqüila.

toda e qualquer técnica de decompor (dividir um objeto grande em porções menores) sistemas de software abordam interesses principais: • • A maioria dos sistemas é muito complexa para ser compreendida em sua totalidade.20 sistema.2: pontos onde as atividades de arquitetura são mais visíveis Segundo [JAZ2000]. 20 . muitos engenheiros acreditam que a arquitetura é determinada pelos requisitos e por isso esperam que a fase de engenharia dos requisitos esteja finalizada para então iniciar a definição da arquitetura. Princípios de arquiteturas Para arquitetos de sistema. uma vez que esta resposta é muito dependente do domínio. A identificação dos requisitos que são significantes para a arquitetura pode ser respondida através de um framework conceitual desenvolvido especialmente para um domínio específico. 1.3. Porém. A figura 1.3 mostra uma representação das camadas arquitetônicas de um sistema. Estas são sistemas em si mesmos e fazem o que todos eles fazem: obtêm uma entrada a partir de seu ambiente e fornecem uma saída para o mesmo. apenas uma fração dos requisitos específicos do sistema tem influência na arquitetura. Figura 1. O desacoplamento ocorre dividindo o sistema em camadas. Audiências diferentes exigem perspectivas diferentes de um sistema.

tipicamente em um servidor de aplicação. Para que realmente se tenha êxito em separar os sistemas em camadas. A lógica de negócios reside em uma camada independente. A camada de acesso a dados fica também 21 .3 mostra um típico sistema multicamadas. Essa camada fornece o gerenciamento de processos em que a lógica de negócios é executada. deve-se prever que as classes e objetos de uma camada devem depender estritamente de sua própria camada. Adaptado de [JAZ2000] A figura 1. que a camada cliente implementa somente a lógica de apresentação (cliente magro). A terceira camada reside entre a camada cliente e a camada de dados.21 Figura 1.3: Camadas arquitetônicas de um sistema. pool de conexões de banco de dados e mais. A arquitetura de três níveis de software surgiu na década de 1990 para superar as limitações das arquiteturas de dois níveis cliente-servidor. e pode acomodar milhares de usuários (em comparação a centenas de usuários comportados na arquitetura de dois níveis) fornecendo serviços como conexão a filas de mensagens. Em um ambiente multicamada percebe-se algumas características. segundo [ALL2003]. A arquitetura de N camadas é a mesma que a arquitetura de três camadas exceto pelo fato de se ter mais de um servidor de aplicação atuando como camada de regra de negócio de banco de dados. os quais fazem com que pequenas alterações em uma camada se propaguem para praticamente todo o “cetim”. Essa arquitetura deve ser definida cuidadosamente devido a sua grande complexidade. com isso um sistema do tipo “espaguete”. evitando. localização transparente.

que permitem ao desenvolvedor compartilhar a lógica de negócios isolando-a do sistema real tipicamente em um servidor de aplicação. etc. • Um ou mais componentes de camada intermediárias. como um celular. a camada de apresentação não deverá ser atualizada.1. • As conexões com bancos de dados podem ser organizadas em filas para prover uma maior performance. diferentemente na arquitetura de duas camadas (cliente-servidor) onde cada alteração na camada servidora (tipicamente um banco de dados) deveria ser refletida na camada cliente. 1. Como exemplo pode-se citar uma camada Web ou uma camada de dispositivo móvel. As três camadas a seguir definem uma arquitetura multicamada. diretórios de domínios. capacidades de uma arquitetura são as qualidades não6 7 Camada de uma aplicação que interage com o usuário. 22 . o cliente pode acessar facilmente os dados sem saber onde estão e como recuperá-los. capaz de fornecer acesso a serviços dedicados como servidor de banco de dados.22 em uma camada específica. Camada de armazenamento de dados em uma arquitetura de N camadas. Dentre as vantagens que se pode alcançar em sistemas multicamadas podemos citar: • As alterações na lógica de apresentação ou na lógica de negócios são totalmente isoladas permitindo uma maior flexibilidade na hora de desenvolver novos requisitos. por isso se reduz drasticamente o tempo para licenciar o usuário ao banco de dados. aplicações legadas. • Um componente de back-end7. • Um componente de front-end6 capaz de fornecer lógica de apresentação de uma forma portável. • O Cliente é isolado da origem de dados e de operações como rede. Capacidades de uma arquitetura Segundo [ALL2003].3. • Quando se deve alterar uma regra de negócio.

se a unidade for capaz de ser utilizada por 100 horas em uma semana [ALL2003]. uma aplicação flexível é uma aplicação de fácil manutenibilidade. gerenciabilidade. Um exemplo métrico de gerenciabilidade seria a quantidade de horas de pessoal no mês gastas para atualizações no servidor. Desempenho Atualmente. Matematicamente a disponibilidade é um (1) menos a indisponibilidade. incluindo escalabilidade.23 funcionais da mesma. confiável e escalonável. o desempenho é a capacidade de executar funções suficientemente rápidas para atenderem aos objetivos. A disponibilidade é a relação entre o tempo total em que uma unidade funcional é capaz de utilizar durante um determinado intervalo e a extensão do intervalo. disponibilidade. confiabilidade e segurança. A separação do sistema em camadas aumenta muito a flexibilidade de um sistema. É a capacidade de realizar mudanças arquiteturais para conceber novos requisitos em uma maneira eficiente e não custosa. Um exemplo de disponibilidade é 100/168. Gerenciabilidade e Flexibilidade Gerenciabilidade se refere ao conjunto de serviços que assegura a integridade continuada. Tipicamente. da aplicação. Escalabilidade Escalabilidade é a capacidade de suportar de uma maneira eficiente o aumento da demanda de requisições sem afetar drasticamente a performance e com isso o 23 . A disponibilidade é o grau em que um sistema é operável em um estado saudável. Ela inclui segurança. A seguir são apresentados alguns conceitos importantes sobre capacidades arquiteturais. controle de concorrência e gerenciamento do servidor. Disponibilidade Essa característica está sempre relacionada ao desempenho. ou correção. Flexibilidade é a chave para uma aplicação disponível. As medidas de qualidade de um sistema normalmente focalizam características de desempenho sob estudo. desempenho. O tempo de resposta e a taxa de resposta são importantes para uma aplicação.

com isso. provendo o aumento da performance do sistema. tipicamente adicionando mais memória e capacidade de armazenamento para o servidor do sistema. Apesar de a escalabilidade vertical ser mais barata e simples de se implementar. ! Horizontalmente: consiste na adição de um ou mais servidores e. 24 . ela não é aconselhada para aplicações de missão critica. podendo com isso também prover alguma forma de balanceamento de carga. Já com a adição de mais servidores.24 tempo de resposta. Esse tipo é bem mais custoso e complexo. pois somente adicionando capacidade de processamento não provê a tolerância a falha. prover uma forma de cluster para a aplicação. pode-se prover um ambiente bem mais tolerante a falhas e eficiente. Pode-se prover a escalabilidade a um sistema de duas maneiras: ! Verticalmente: é considerada a maneira mais fácil e barata para prover escalabilidade. ainda com isso o sistema terá apenas um ponto de falha.

mas. tampouco surgiu com a então chamada “indústria de software”. a idéia de reutilizar soluções já anteriormente desenvolvidas não é atual. [LEI2005]. e não apenas a reutilização de código” [LEI2005]. Após isto.25 Capítulo 2 Padrões de Projetos e melhores práticas para projetos J2EE Muito se ouve falar de padrões de projeto. Porém. com a publicação de dois livros de Christopher Alexander: “A Pattern Language” em 1977 e “A Timeless Way of Building” em 1979. Com isto. sendo os maiores incentivadores dos design patterns. Atualmente. Em seu livro “A Times Way of Building”. divididos em três categorias: padrões de criação. Nestes livros ele descrevia problemas e suas soluções para a arquitetura. É por isso que “os padrões de projetos têm chamado a atenção e despertado o interesse dos projetistas de software. em 1995. os projetistas de software raramente solucionam problemas a partir de princípios elementares ou do início do processo. instantaneamente está passando a utilizar os padrões. Estas similaridades foram chamadas por ele de “padrões”. Ao contrário. seja por influência de outras pessoas ou por estudos e necessidade. Erich Gama. devido a sua grande ramificação surge um pergunta: “qual padrão de projeto utilizar?”. Estes quatro autores ficaram conhecidos como “a gangue dos quatro” (Gang of Four – GoF). Os padrões de projeto (design patterns) representam a idéia de evitar a “perda de tempo” pensando em soluções a problemas que já foram anteriormente enfrentados e solucionados. estruturais e de comportamento. Este livro descreve 23 padrões de projeto. pois o mundo do desenvolvimento de Software. que expressa uma relação entre um determinado contexto. ele descobriu que se ele procurasse estruturas que resolvessem problemas similares. um 25 . Esta idéia surgiu no final da década de 70. por proporcionar elementos que conduzem ao reaproveitamento de soluções para projetos. Richard Helm. eles reutilizam soluções que já funcionaram anteriormente e as adaptam para o problema em questão. lançado em 1979. ele poderia discernir similaridades entre projetos de alta qualidade. Christopher Alexandre fez a primeira definição de padrão de projeto: “Cada padrão é uma regra de três partes. Ralph Johnson e John Vlissides se uniram e lançaram o livro “Design Patterns: Elements of Reusable Object-Oriented Software”.

Composite. Prototype e Singleton. esses padrões surgiram quando Erich Gama. Observer. Mediator. Iterator. Unindo as duas definições. estes patterns ajudam a tornar um comportamento complexo gerenciável. Command. padrão de projeto é “uma solução geral para um problema comum no projeto de software”. independente de linguagem de programação. os patterns desta categoria devem ser utilizados no momento em que uma classe é instanciada. o problema e a solução. pode-se dizer que para entender os padrões de projeto é necessário entender suas três partes: o contexto. 2. Ralph Johnson e John Vlissides se uniram e lançaram um livro descrevendo 23 padrões de projeto. Flyweight e Proxy. Interpreter.1. Onze padrões são descritos por esta categoria: Chain of Responsability. Builder. Já de acordo com [WIK2006]. State. 26 . ou seja. • Patterns Estruturais: Esta categoria possui patterns que dizem respeito à composição das classes e dos objetos. Cinco padrões são descritos por esta categoria: Abstract Factory. Strategy. Os padrões de projeto não são uma projeção final que será transpassada para o código do desenvolvedor de software. mesmo que em projetos distintos (como citado anteriormente. Decorator. por exemplo). Eles são soluções abstratas de como resolver determinados problemas do projeto de software. Sete padrões são descritos por esta categoria: Adapter. Padrões GoF Como mostrado anteriormente. Factory Method. linguagens de programação diferentes. ou seja. sendo possível ter a solução recorrente para um problema em um contexto. Bridge. Facade. Patterns Estruturais e Patterns Comportamentais.26 problema e uma solução”. Richard Helm. Memento. • Patterns Comportamentais: Esta categoria possui patterns que dizem respeito à interação e responsabilidade de objetos. • Patterns Criacionais: Essa categoria possui os patterns que são utilizados para criar objetos. Estes padrões são divididos em três categorias: Patterns Criacionais.

Além disso. Padrões J2EE Assim como para os padrões GoF. Eles são divididos em três categorias.1. o J2EE apresenta uma divisão em seus padrões.27 Template Method e Visitor. com a diferença de que ele realiza mais processamento antes de despachar a requisição. com o objetivo de diminuir as responsabilidades e permitir o reuso dos componentes. Não entraremos em detalhes com relação aos padrões GoF. enquanto que o Dispatcher View realiza mais processamentos depois de despachar a requisição. devido eles não serem relevantes a este trabalho. 27 .2. • Dispatcher View: Este patterns tem por objetivo combinar padrões de apresentação e encapsular a lógica de navegação. Front Controller: Este padrão é utilizado quando se precisa centralizar o processamento de requisições para tratamento da solicitação do cliente. Patterns da Camada de Negócios e Patterns da Camada de Integração. de acordo com camada [ALL2003]: Patterns da Camada de Apresentação.2. 2. Há sete padrões descritos por esta camada [ALL2003]: • Composite View: Este padrão é utilizado quando se deseja construir um componente de visualização através de subcomponentes de visualização. além de permitir um processamento centralizado e compartilhado através de requisições. para que toda a lógica fique transparente para o mesmo. 2. • • Intercepting Filter: O objetivo do Intercepting Filter é permitir o pré e o pósprocessamento de uma requisição do cliente. ele também permite criar uma interface genérica com o intuito de delegar o processamento do controlador para os componentes auxiliares. Os padrões desta camada interceptam as requisições vindas do (e para o) usuário. • Service to Worker: Este padrão tem o mesmo objetivo do Dispatcher View. Patterns da camada de apresentação A camada de apresentação é responsável por encapsular a lógica relacionada à interface do usuário.

Um exemplo de framework que implementa o padrão MVC é o Struts. A principal função do MVC é a divisão de responsabilidades. Um sistema MVC é dividido em um modelo de dados. representa os dados e o comportamento da lógica de negócios. Por exemplo. em uma aplicação padrão. uma visão (view) pode usar o modelo (model) para exibir resultados de determinada consulta ao banco de dados (também feita pelo modelo). É utilizado quando a aplicação precisa encapsular a lógica da formatação de dados relacionada à apresentação. Uma maneira de se implementar o processamento de negócios é através do uso de Enterprise Java Beans (EJB). por sua vez. HTML. As visões fornecem a interface do usuário e. A principal vantagem do MVC é que o desenvolvimento de aplicações que o implementem pode se tornar mais simples e rápido. além de encapsular. um conjunto de visões e um conjunto de controladores. pois com a divisão das camadas. • Model View Controller (MVC): Este padrão fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação. pois pode tornar o projeto mais demorado. devido requerer uma maior quantidade de tempo para análise e modelagem do sistema [SIE2004]. Esta camada de visão é responsável por receber os dados fornecidos pelo usuário e apresentar os resultados. Ele controla e mapeia as ações do usuário e da camada de modelo. consistem de JSP. XML.28 • View Helper: Tem por objetivo separar o código da interface do usuário do processamento de dados necessários à construção da View. 2. Patterns de camada de negócios A camada de negócios encapsula a lógica central da aplicação. Porém. etc.2.2. é ele que interpreta as ações do usuário e as mapeia para chamadas do modelo. fornecendo serviços requeridos pelos clientes. mas a visão não é responsável por atualizar o banco de dados. O controlador define o comportamento da aplicação. pode-se desenvolver paralelamente as três camadas. vale ressaltar que ele não é aconselhável para projetos pequenos. Oito padrões são descritos por esta camada [SIE2004]: 28 . ASP. manipular e gerar os dados. A lógica de negócio pode ser representada tanto pela camada de modelo como pela camada de controle (controller). O controlador é geralmente implementado como um ou mais servlets Java. O modelo.

Este padrão acaba por funcionar como proxy ou fachada para cada Session Bean (conceituado no capítulo 3). objetos. gerenciar e representar um conjunto de objetos persistentes relacionados. Há duas estratégias de implementação do Business Delegate: • Delegate Proxy Strategy: Nesta estratégia. Além disso. e para melhorar a performance. o Business Delegate pode armazenar os serviços de negócios em cache para os clientes e também disponibiliza uma interface simples. O Business Delegate oculta os detalhes de implementação por trás do serviço de negócios. também quando se deseja ocultar a complexidade da pesquisa de componente do EJB. • Composite Entity: Este padrão tem como objetivo modelar. • Session Façade: Este padrão é responsável por acessar recursos. • Transfer Object: Este padrão é utilizado quando se precisa obter vários dados de um determinado objeto. Para isso. ele serve para diminuir o acoplamento entre as camadas. como detalhes de pesquisa e acesso da arquitetura EJB. redes e serviços). Além disso. Também é utilizado para se reduzir o tráfego de rede entre os clientes e seus componentes EJB. atualizar dados e realizar a transação com uma interação limitada com o cliente. ao invés de representar como objetos distintos. ele pode ser usado para abstrair o uso de JNDI (Java Naming and Directory Interface. que é uma API J2EE que fornece uma interface padrão para localizar usuários. os Entity Beans devem modelar apenas os objetos principais. O seu objetivo é fornecer uma interface simples e única para todos os clientes. • Service Locator: Este padrão é utilizado quando se precisa fornecer um método uniforme para pesquisa e criação de serviço. o tráfego na rede e a 29 .29 • Business Delegate: Este padrão é utilizado para reduzir o acoplamento entre os clientes da camada de apresentação e os serviços de negócios. o Business Delegate permite a comunicação com sistemas heterogêneos. • Delegate Adapter Strategy: Nesta estratégia. o Business Delegate utiliza o Lookup Service. a chamada dos entity beans para os seus objetos não deve ser interceptada pelo container. Para ocultar estes detalhes. que é um componente que pode ser implementado tanto como parte do Business Delegate como separadamente. desta forma. máquinas. reduzindo. Ele reduz a quantidade de requisições feitas para recuperar estes dados.

Apenas dois padrões pertencem a esta categoria: • Service Activator: O principal objetivo deste padrão é receber e processar mensagens assíncronas do cliente. Se o desenvolvedor for colocar o acesso ao dado diretamente no código. além de melhorar a performance da rede. ou seja. serve para encapsular os dados de negócios. por exemplo. e também se deseja fazer cache dos resultados do lado do servidor.2.30 duplicação de código.3. utilizando vários Transfer Objects para recuperar os dados dos objetos necessários ao modelo que o cliente deseja. Normalmente essa camada fica acoplada com a camada de negócios. Com isso. como através de banco de dados. ou através de um arquivo XML. 2. Ele acaba por reduzir o acoplamento existente entre os clientes e o modelo da aplicação. ela melhora a performance da rede. que esconde toda a complexidade relativa à interação com a fonte de dados. Existem várias formas de se acessar dados. Patterns de camada de Integração Esta camada encapsula a lógica relacionada com a integração do sistema com a camada de informação distribuída. Ele recebe as mensagens e as repassa para os métodos correspondentes a atender a requisição. • Value List Handler: Deve-se utilizar este padrão quando se quer ter controle sobre a busca. • Transfer Object Assembler: O objetivo deste padrão é construir um modelo de dados requerido pelo cliente. Um componente de negócio fica exposto apenas a esta interface. Os padrões pertencentes a esta categoria são responsáveis por acessar recursos e sistemas externos. • Value Object: Este padrão surgiu com o intuito de minimizar o número de chamadas remotas que são necessárias quando está usando EJB. haverá um grande acoplamento entre a lógica de negócio e a implementação do acesso a dados. e precisa fornecer recursos de processamento de listas. O DAO oferece uma interface comum a todos os tipos de acesso a dados. o seu objetivo é abstrair e encapsular todo o acesso a uma fonte de dados. Como a interface de um DAO não se altera quando sua implementação precisa ser 30 . isto é. assim como em outros padrões. • Data Access Object (DAO): Este é um dos padrões mais utilizados. ele irá ter que modificar uma grande quantidade de código caso o modo de acesso a dados modifique.

um benefício complementa o outro. ao invés de facilitar o desenvolvimento. fácil manutenção.3. O principal problema existente no uso de padrões de projeto é o mau uso dos mesmos. facilita a migração de uma fonte de dados a outra. além tornar a manutenção e o entendimento do sistema mais simples. 31 . O uso dos padrões trouxe inúmeros benefícios para o desenvolvedor. Na verdade. tornando o código-fonte grande e complexo. 2. Outro benefício apontado por [MAI2005] é que o uso de padrões torna a comunicação entre os desenvolvedores mais eficiente. De acordo com [MAI2005]. facilitando o desenvolvimento de módulos coesos [MAC2005]. Benefícios e Problemas do uso de Padrões de Projeto Sem dúvidas. Os desenvolvedores podem solucionar algum problema de outro desenvolvedor mais rapidamente se ele já conhecer algum padrão de projeto que solucionou algum problema semelhante anteriormente. O uso deste padrão resulta na transparência da aplicação quanto a fonte de dados. o mau uso dos mesmos pode acarretar em problemas. onde ficará centralizado o acesso a dados. além de criar uma nova camada. este padrão permite alterar a fonte de dados sendo utilizada numa aplicação sem afetar os componentes de negócios que fazem uso deste. dificultá-lo. Em suma. Além disso. alguns dos principais benefícios dos padrões são: maior flexibilidade. os padrões de projeto possuem dois principais benefícios: o uso de padrões de projeto auxilia o desenvolvedor a solucionar problemas que já foram solucionados anteriormente por outras pessoas. Porém. Utilizar padrões de projeto em um projeto muito pequeno pode. Isto porque o objetivo do uso dos padrões é o de facilitar o processo de desenvolvimento de sistemas grandes. os padrões de projeto surgiram com o intuito de facilitar o processo de desenvolvimento de software. o uso de padrões torna o sistema mais fácil de entender e de manter. fornecem um vocabulário comum entre o software e os desenvolvedores.31 modificada. pode ser aplicado a diversas tecnologias. além de enfatizar e apoiar a reutilização de código.

ao passo que se pode aprender a não repetir estas falhas. possivelmente resultada de uma inexperiência em se resolver um tipo de problema em particular ou na aplicação de um padrão de projeto em um contexto errado. descobrindo suas causas. numa aplicação web. O AntiPattern então enfatiza esta solução. Ao contrário dos padrões de projeto. o antipattern começa com uma “solução ruim” já existente. seus sintomas e conseqüências. pois a simples alteração de um nome pode resultar em dezenas de alterações em diversos documentos. Com a experiência que os desenvolvedores vão adquirindo com o tempo. é muito comum. acabam incorporando práticas e vícios que prejudicam o entendimento. Por exemplo. isto dificulta a manutenção. a manutenção e a performance dos sistemas que desenvolvem.32 Em contradição. as páginas se referenciarem diretamente [LOZ2003]. Com o crescimento da aplicação. as limita. existem os chamados antipatterns. ou "soluções negativas" são valiosas. O Antipattern então apresenta uma nova solução que refatora o sistema visando maximizar os benefícios e minimizar as conseqüências. que. de modo que permita o reconhecimento da mesma. através do estudo aprofundado. ao invés de aumentar a qualidade do software. Estas falhas. 32 .

33

Capítulo 3
Arquiteturas J2EE
Com o avanço de aplicações voltadas para a Internet, foram necessárias aplicações que necessitavam ser escaláveis e ininterruptas. A plataforma J2EE assegura esses requisitos sendo um conjunto de especificações que permitem um desenvolvimento de aplicações em N camadas, providenciando além de um conjunto de APIs, uma infra-estrutura de runtime para hospedar a aplicação. A arquitetura J2EE é dividida em quatro containers, sendo: o container de aplicação cliente, o container de applets, o container de desenvolvimento web e o container de negócios chamado de container de Enterprise Java Beans. Como mostrado no capítulo 1, sobre arquiteturas separadas em camadas, percebe-se que para aumentar a escalabilidade e diminuir acoplamento de uma arquitetura complexa, é necessário projetar cada uma dessas camadas e prover uma desacoplada forma de integração entre elas.

3.1. Container WEB em J2EE
Para a execução de aplicações dinâmicas para a Web, a plataforma J2EE disponibiliza o conceito de contêiner web que podem pertencer a dois grupos: [SUN2006]. • Orientada a apresentação: uma aplicação web orientada a apresentação gera uma interativa forma de resposta ao cliente, usando alguma forma de linguagem de marcação, como o HTML e o XML, e uma resposta dinâmica para os clientes. • Orientada a Serviço. Em aplicações orientadas a serviços, existe uma implementação de endpoint para um Serviço Web. As aplicações orientadas a apresentação são, em sua maioria, os clientes de aplicações orientados a serviço. Em suma, os componentes web podem ser implementados tanto usando tecnologias Java Servlet quanto Java Server Pages, ou endpoints de serviços. A interação entre um cliente e o servidor web está ilustrado na figura 3.1. 33

34

Figura 3.1: Interação entre cliente e servidor Web. Adaptado de [JAZ2000]

Como mostra a figura 3.1, o cliente manda um HTTPRequest (1.) para o servidor web. Essa requisição é recebida pelo Web Server, que encapsula a requisição em um objeto chamado HTTPServletRequest e entrega-o a um objeto servlet (2.) que interage com JavaBeans, com banco de dados ou outro componente web pra que ele possa gerar a resposta dinâmica para o usuário. O componente web pode gerar objetos chamados HTTPServletResponse (5.) ou pode passar a requisição para outro componente que então gere a resposta. O servidor, então, converte esse objeto em uma resposta simples HTTP e retorna para o cliente. [SUN2006]

3.2. EJB e o modelo de container
Após discutir rapidamente a camada web de servidores J2EE, é importante discutir também a camada de negócios sugerida pela especificação J2EE. Esta camada é implementada usando componentes de negócios distribuídos chamados de Enterprise Java Beans. Com a necessidade de se desenvolver soluções distribuídas objetivando atender um principio básico de qualidade de serviço, o da tolerância à falhas, 34

35

iniciaram-se vários esforços para seu desenvolvimento. Na plataforma Java, o desenvolvedor trabalha de uma maneira distribuída através de RMI8 (Remote Method Invocation). O RMI atua como um RPC9 (Remote Procedure Call), porém de uma forma orientada a objetos, podendo transportar além de simples caracteres, objetos complexos. Entretanto, percebeu-se que desenvolvendo aplicações distribuídas usando RMI era extremamente desgastante, o desenvolvedor se ocupava mais com problemas de comunicação da rede, problemas de segurança, administração da performance e da propagação de transações do que as regras de negócio do próprio sistema. Diante desses problemas, foram elaborados os componentes de negócios da arquitetura J2EE para abstrair todos os problemas referentes à infra-estrutura dos desenvolvedores, fazendo com que eles apenas se preocupassem com a regra de negócio propriamente dita. Os EJBs podem ser conceituados como sendo componentes de negócios que habitam sempre um servidor de aplicação e que o desenvolvedor tem a obrigação apenas de desenvolvê-lo, outros recursos burocráticos são tarefas do servidor de aplicação. Dentre esses recursos abstratos do desenvolvedor podemos citar: • Localização de recursos: O Servidor de aplicação oferece uma plataforma para que os EJBs descubram serviços hospedados no servidor de aplicação através de JNDI10, esses serviços podem ser uma conexão a uma fonte de dados, a uma fila de mensagens assíncronas, a outros EJBs, a um Mainframe, a fontes LDAP, etc. • Segurança: a segurança em aplicações J2EE é implementada no servidor de aplicação, significando que o desenvolvedor deve declarar quais recursos são visíveis e accessíveis. Chamadas não autorizadas a componentes de negócios ou a páginas web podem ser interceptadas bastando ao desenvolvedor definir os perfis e o acesso aos mesmos. • Performance: um grande fator na adoção de servidores de aplicação é quanto ao fator escalabilidade. Para um servidor de aplicação ser considerado um servidor J2EE, ele deve implementar no mínimo as regras
Forma prática de se implementar um Sistema Distribuído em plataforma Java. Tipo de protocolo para chamada remota de procedimentos em qualquer lugar da rede ou uma chamada de função para o método de transferência de controle de parte de um processo para outra, permite a divisão de um software em várias partes, compartilhamento de arquivos e diretórios. 10 API para acesso a serviços de diretórios. Permite que aplicações cliente descubram e obtenham dados ou objetos através de um nome
9 8

35

36

inclusas na especificação J2EE. Dentre essas regras, pode-se citar o gerenciamento do ciclo de vida dos EJBs. • Controle Transacional: em aplicações extremamente complexas, o quesito “transação” não faz parte apenas do banco de dados. Com isso, deve-se proporcionar uma maneira simples e eficaz de tratar transações, e o servidor de aplicação atua como o implementador baixo nível, fornecendo ao desenvolvedor EJB um nível amigável de utilização das mesmas. • Persistência: Através do EJB CMP, que será discutido posteriormente, o servidor de aplicação pode gerenciar a forma como seus objetos de domínio serão armazenados em algum meio persistente, dando total abstração para o desenvolvedor e causando uma independência de origem de dados.

3.3. Performance com EJB
Performance é um tópico essencial para qualquer aplicação que necessite ter um número satisfatório de usuários. Com o crescimento do uso da Internet para diversos fins, a demanda para aplicações com alta performance foi aumentando consideravelmente. Porém, não faz sentido termos somente performance para um número pequeno de usuários. O que aconteceria de esse numero de usuários dobrasse rapidamente e em seguida triplicasse? Será que o desempenho seria o mesmo do início do processo? Será que o tempo de resposta seria aceitável? É neste ponto que entra o conceito de escalabilidade. Como visto no capítulo 1, escalabilidade é “a capacidade de suportar de uma maneira eficiente o aumento da demanda de requisições sem afetar drasticamente a performance”. Com isso, para que o sistema possa ser escalável, seu aumento de carga não pode comprometer muito o seu desempenho. Tendo esse conceito em mente, os servidores de aplicação gerenciam o ciclo de vida de seus componentes EJB para prover um melhor gerenciamento de recursos refletindo diretamente em um tempo de resposta ainda mais aceitável. O ciclo de vida de um componente EJB não é administrado por seu desenvolvedor, e sim pelo servidor de aplicação. Mas, por quê? Como o processo 36

37

de criação e manutenção de um EJB é uma tarefa dispendiosa de recursos, o servidor de aplicação aplica certas regras para disponibilizá-los aos clientes. A primeira etapa consiste na criação dos EJBs. Muitos desenvolvedores acham que o EJB somente é criado quando algum usuário o invoca, entretanto, percebe-se que isso não está correto, por motivos de , tipicamente ao se iniciar o servidor de aplicação instancia-se algumas dezenas ou centenas de EJBs e os colocam em um pool de EJBs. A escalabilidade provém justamente do pool de EJBs, que por sua vez é uma fila, repositório contendo instâncias de EJBs prontas para serem usadas, e no caso de EJBs sem estados, discutidos posteriormente, quando um usuário solicita um EJB, o container o retira do pool e entrega para ser usado. Quando o cliente não precisa mais de seus serviços, ao invés dele ser descartado, ele retorna para o pool causando com isso uma grande velocidade de resposta, pois não há o gasto de criação e destruição sempre na aplicação. O container também é responsável por retirar ou não do pool de EJBs. Caso o sistema esteja com poucos recursos, uma boa técnica é retornar do pool alguns EJBs não usados recentemente, através, por exemplo, do algoritmo de LRU, que consiste em escolher menos usado recentemente. Além de prover um pool para EJBs, o servidor de aplicação deve também fornecer um pool de conexão para origens de dados, pois é extremante dispendioso cada cliente criar uma conexão direta com o banco de dados, o que certamente deixaria o sistema inacessível com uma quantidade razoavelmente de usuários. Com um pool de conexões de dados, as conexões ficam no pool até que um cliente a requisite. Se vários clientes acessarem o pool para recuperar uma conexão e não existir uma disponível, o cliente fica em uma fila de espera aguardando que algum recurso seja liberado. Tais técnicas permitem afirmar que a plataforma J2EE é escalável. Porém, para aumentar a performance de sistemas existem duas opções: Escalabilidade Horizontal e Escalabilidade Vertical. Para prover uma escalabilidade horizontal em um sistema, é necessário adicionar máquinas à aplicação, tipicamente colocando-as em cluster, com isso aumentará o nível de complexidade e gerenciabilidade do sistema, mas provê uma grande melhoria na tolerância à falhas, pois se uma máquina ficar inacessível o sistema rodará normalmente na outra, além de prover um balanceamento de carga. O balanceamento de carga funciona interceptando as requisições aos 37

e entre os métodos subseqüentes e o cliente. O tipo de conversação é o fator determinante para separar os dois tipos de EJBs. os session beans podem ser usados para processamento de venda. Neste trabalho. os de entidade e os dirigidos por mensagens. então se deve redirecionar a requisição para a máquina seguinte.4. iremos explorar também seus subtipos: stateless session beans (componentes de sessão sem estado). Pode-se dizer que conversação é a interação entre o cliente e o componente. container manager persistence (persistência gerenciada pelo container). Em suma. que normalmente é o tempo de sessão que um cliente utiliza. 3.4. etc. Session Beans Os sessions beans representam o trabalho sendo realizado pelo cliente que o chama. com estado conversacional e sem 38 . pode-se dividir os componentes EJBs em três tipos: os de sessão. Todos os EJBs possuem um grau de conversação com algum tipo de cliente. statefull session beans (componentes sessão com estado). com isso. Geralmente eles têm um ciclo de vida curto. 3. transações bancárias. Tipos de EJB Segundo [ROM2004]. Por exemplo. cálculos complexos. operações de banco de dados. pois consiste em adicionar componentes de hardware na máquina atual a fim de aumentar seu poder de processamento. eles são componentes reusáveis que implementam lógicas de negócios. Eles são objetos de processo de negócios que implementam as regras de negócio. bean manager persistence (persistência gerenciada pelo bean). As instâncias de session beans não são compartilhados com outros clientes. Se essa máquina estiver com carga máxima. Esta técnica é bem mais barata que a horizontal e praticamente não afeta a aplicação. Para uma escalabilidade vertical o processo é bem mais simples.38 servidores e verificando como está a carga do possível alvo.1. algoritmos ou workflows. o sistema tem apenas um ponto de falha e se essa maquina parar. [ROM2004] Uma grande diferença entre os session beans e os outros tipos de EJBs está em seu ciclo de vida. a aplicação ficará indisponível. porém.

Portanto um bean de sessão com estado é requerido [ALL2003]. voltar para o pool de beans. 39 .39 estado conversacional. pode ser recriado ou pode. Na figura 3. o container que o gerencia normalmente após a chamada do método o bean pode ser destruído. deve-se reter o estado do objeto do usuário por todas as chamadas subseqüentes. Naturalmente os processos de negócios são realizados usando apenas uma simples e única requisição de conversação com o cliente. Um session bean representa o trabalho realizado por um único cliente. Como o processo é concebido através de apenas um método. Como visto anteriormente. o cliente somente faz uma chamada e o componente o devolve a resposta ao cliente. Esse trabalho pode ser realizado dentro de uma única invocação de método ou pode englobar diversas invocações de métodos. o cliente pode adicionar ou remover itens no carrinho. Um típico exemplo de bean com estado conversacional é uma aplicação de ecommerce que possui um carrinho de compras. na maioria das vezes.2 pode-se ter uma idéia do modelo de pool de EJBs de sessão. uma simples chamada ao método de negócio pelo cliente não requer estado conversacional. Tal lógica poderia ser implementada usando statefull session beans. Um exemplo de uso de beans sem estado é um componente que realiza uma consulta em algum ambiente de armazenamento de dados e o retorna para o cliente. Ao longo da navegação. Se o trabalho abranger mais de um método.

Quando cada atributo do objeto é armazenado. Normalmente.2. Entity Bean Uma das grandes vantagens de EJB é o poder de se usar entity beans. devido sua facilidade e produtividade. Ao invés de serializar o objeto em arquivos binários. Por exemplo. ao contrário do mapeamento direto usando JDBC. IBatis. como MySQL. O mapeamento objeto-relacional pode ser realizado de duas maneiras: diretamente dentro do código usando a API padrão JDBC ou através de algum tipo de produto externo como TopLink. Normalmente se recupera as linhas resultantes da consulta e mapeia-se de volta para objetos Java. dentre outros. Hibernate. Para recuperar objetos armazenados. significando que se pode modelar objetos de negócio fundamentais com entity beans. O processo de mapear objetos a banco de dados relacional chama-se Mapeamento Objeto-relacional [ROM2004]. ele é armazenado em um campo separado. o processo é parecido.40 Figura 3. Entity Beans são objetos persistentes que são armazenados em algum meio persistente. Esses produtos têm alcançado uma enorme popularidade.2: Modelo de Pools de EJB de sessão. Uma clássica maneira de se armazenar objetos Java é através do uso de banco de dados relacionais. pode-se decompor o objeto em partes e armazenar cada parte separadamente. SyBase. 40 . um objeto Aluno possui atributos nome e matrícula. entre outros.4. quando armazena objetos Java. usa-se a API JDBC [JDB2006] para mapear o objeto ao banco de dados relacional. Oracle. normalmente um banco de dados. Adaptado de [JAZ2000] 3.

ele pode ser representado por várias. Beans de Entidade modelam conceitos de negócios que podem ser expressos por nomes e esta é uma regra importante quando na sua modelagem de sistema o desenvolvedor precisa eleger um candidato a ser um Bean de Entidade. eles são responsáveis pelos dados de negócios (Core Business Data). A partir disto pode-se ter o questionamento: Porque não acessar o banco de dados diretamente? Existem muitas vantagens em se usar Beans de Entidade ao invés de acessar a base de dados diretamente. um bean de entidade não necessita estar mapeado para uma única tabela. um novo registro deve ser inserido na base de dados e uma instância do bean associada a este dado. serviços para o cliente.3. pois ao invés de se modelar um fluxo de controle (workflow). Um bean de entidade pode ser considerado como de vida longa (long-lived) porque sobrevive a um crash no servidor de aplicativos e por sua característica em um modelo N-tier ficaria mais próximo do DBMS (Database Manager System). Quando um novo bean é criado. que é papel do session bean. Estes tipos de beans modelam realmente um dado no banco de dados onde uma instância representa uma linha na tabela de um banco de dados.41 Foi mostrado na seção anterior que os EJBs de sessão são modelados para realizar regras de negócio. por exemplo. estas mudanças devem estar sincronizadas com a base de dados. Message Driven Bean Antes da versão 2. Com relação aos beans de sessão. É muito mais fácil. Estes beans promovem um simples mecanismo de acesso e alteração de dados. executar um método para atualizar um campo de um entity do que fazer um comando SQL11 para isto. a maioria dos consumidores de mensagens JMS (Java Message Service) foi construída como simples programas 11 sintaxe usada para a definição e manipulação de dados em um banco de dados relacional.4. os beans de entidade são muito diferentes. Conforme o bean é usado e seu estado é alterado. algoritmos. 3. cada aplicação necessita ter seus objetos de modelo persistidos. Do outro lado. 41 .0 da especificação EJB. Este processo de coordenação dos dados do banco de dados com a instância do bean é chamado de persistência. devido na fase de design nem toda tabela de seu esquema de persistência necessita estar mapeada para um bean de entidade. Já com relação ao mapeamento com as tabelas. É nesse contexto que entra a tecnologia dos entities beans.

Porém.3. A figura 3. na medida exata. Existia um programa Java que era ativado e conectado a um destino JMS que ficava esperando as mensagens. Baseados nisto. Então.42 Java fora do container J2EE.3: Funcionamento de um Message Driven Bean 42 . ou seja. Basicamente. A grande diferença entre beans orientados a mensagens e os beans de sessão ou de entidade é que os beans orientados a mensagens não possuem interfaces home nem interface remote. ficaria difícil fazer um algoritmo que. consumiria as mensagens sem perda de performance com muitas threads e sem perda destas mensagens no caso de poucas threads. Figura 3. podemos deduzir que estes beans são completamente escondidos do cliente. a especificação não definia este tipo de bean. e se este volume variasse muito. O único meio dos clientes comunicarem com os beans orientados a mensagens seria enviando uma mensagem para um destinatário JMS. o que fazia com que cada vendedor tivesse um padrão. demonstra o funcionamento dos beans orientados a mensagens. esta solução gerava vários outros problemas e o maior seria a escalabilidade. Quando o número de mensagens na fila aumentava.1. consomem mensagens JMS através da tecnologia EJB. Embora a construção de consumidores de mensagens por meio de aplicações Java fosse uma das melhores soluções para o problema. beans orientados a mensagens processam alguma lógica de negócios usando mensagens JMS enviadas para uma destinação particular. haveria a necessidade de se executar um programa Java multithreads para promover a escalabilidade da leitura destas mensagens. alguns vendedores de EJB pensaram nesta funcionalidade na versão 1.

Por usar um pool de instância de beans. 43 . o container é capaz de manipular as mensagens que chegam de uma forma muito mais eficiente e aumenta a escalabilidade das operações JMS. um cliente envia uma mensagem JMS para um destino e o container passa esta mensagem JMS para uma instância do bean orientado a mensagens que tem se registrado como um receptor de mensagens para uma destinação particular.43 Como se pôde verificar. As instâncias dos beans podem ser colocadas ou retiradas do pool dependendo das necessidades do container de atender as requisições.

De acordo com [JOH2004]. Se a primeira ou segunda afirmação for válida.1. Um container web J2EE provê uma camada intermediária para aplicações que possuem o browser como cliente. cada um acessando um recurso como fonte de dados ou aplicações legadas inacessível em outro lugar na rede. Esta é uma escolha potencialmente custosa. pois não se deve escolher uma arquitetura distribuída sem ter realmente bons motivos para tal. esse argumento não se aplica para aplicações com apenas interface web. Com isso. Em casos raros. • • Para se ganhar controle sobre onde cada componente distribuído está instalado. Entretanto isso pode ser questionado. 44 . aumentando com isso a escalabilidade e a confiabilidade. uma arquitetura distribuída baseada em EJB com interfaces remotas é a solução mais simples e ideal. Quando aplicações distribuídas são apropriadas? Uma das grandes decisões arquitetônicas é se a aplicação deve ser distribuída ou se todos os componentes devem ficar em um único servidor rodando a aplicação. Como uma aplicação envolvendo vários containeres de EJB. Aplicações Distribuídas e Escalabilidade O J2EE e desenvolvedores tendem a assumir que aplicações distribuídas oferecem uma escalabilidade inigualável. abaixo seguem algumas principais vantagens em se usar arquiteturas distribuídas: • Suportar tecnologias clientes J2EE como aplicações Swing dando a ela uma camada de negócio. 4.44 Capítulo 4 Aplicando a tecnologia J2EE e seus problemas 4. Os autores acreditam que existe certa tendência em aplicar a plataforma distribuída de J2EE na maioria dos projetos sem realmente estudá-los a fundo antes da escolha arquitetônica. • Quando aplicações necessitam integrar recursos distribuídos em uma empresa.1. deve-se escolher uma aplicação distribuída para se adicionar um firewall entre o servidor web e o servidor de regras de negócio.1.

a qualidade do suporte a cluster (roteamento e gerenciamento de estado) do servidor web irá ditar a escalabilidade do sistema. O EJB não pode ser considerado uma “bala da prata” que faz com que o problema da replicação de estado se resolva tão facilmente. Nesses raros cenários. Uma aplicação distribuída com interfaces remotas somente será mais escalável que aplicações com máquina virtual única somente nesses casos: • Os objetos acessados remotamente não possuem estado (stateless).45 Soluções com apenas uma máquina virtual Java (JVM) tem uma performance mais alta que aplicações distribuídas. Uma aplicação que não requer armazenamento de estado no servidor pode crescer linearmente e indefinidamente sem o uso de chamadas remotas. o container EJB terá uma dificuldade semelhante. Se nós carregarmos o estado da aplicação no servidor web (através do objeto HttpSession). em statefull session beans. esse não é um requisito apenas de containeres EJB. mesmo que o estado seja mantido na camada web. No contexto de J2EE isso significa que as regras de negócios serão implementadas usando stateless session beans. Se carregarmos o estado no container EJB. • 45 Os objetos de negócio realizam um trabalho bem superior que a camada . • Muitos dos objetos de negócio consumem recursos que não podem ser alocados em qualquer servidor ou em qualquer camada. Quando o armazenamento de estado é requerido. mesmo adotando uma solução distribuída [JOH2004]. acoplando a camada web com a camada de negócios tem-se uma limitação de escalabilidade comparada a arquiteturas cliente-servidor. devido ao fato da latência de invocações remotas. Containeres web de alta qualidade oferecem funcionalidades de cluster. aplicações com JVM únicas podem ser clusterizadas facilmente. a escalabilidade torna-se limitada. Usando o balanceamento de carga através de hardware tem-se a vantagem de igual funcionamento em qualquer servidor J2EE. Além disso. Apenas adicionando uma camada remota (como uma camada EJB) em uma aplicação Web não necessariamente torna o sistema mais escalável. Vantagens como balanceamento de carga de requisições HTTP pode ser realizada por elementos do cluster oferecidos pelo servidor J2EE ou por componentes como o Cisco Loader Balance.

a menos que a sessão tenha sido replicada com sucesso. Com o uso de statefull session beans. Aplicações Distribuídas e Confiabilidade As aplicações distribuídas. Um modelo de objetos de negócio sem estado é considerado altamente escalável. não importa se os objetos de negócio estiverem em outro servidor que ainda esteja rodando. pois se pode adicionar quantos containeres EJBs quanto desejado.2. Somente se tivermos uma arquitetura na qual o armazenamento de estado seja mantido na camada web e os objetos de negócio seja sem estado. Desenvolver uma aplicação distribuída não soluciona esse problema. sem aumentar com isso o número de containeres web ou o overhead de algum tipo de replicação de estado que possa ser requerida na camada web. 46 . na qual se tornará statefull. Entretanto. na qual cada usuário é associado a um servidor em particular. arquitetos J2EE e desenvolvedores tendem a assumir isso. Se a aplicação mantiver o estado no servidor. nós apenas movemos esse problema para o container EJB. A figura 4. Se tivermos uma camada web com estado.1 mostra uma arquitetura J2EE robusta e escalável. a arquitetura distribuída torna-se mais robusta e escalável que aplicações simples. necessariamente são mais robustas que aplicações simples (com um único servidor)? Novamente. esse conceito é questionável. ela será referenciada na camada web. os EJBs com estado tendem a ser menos robustos que o tratamento de estado pelo objeto httpSession. essa arquitetura somente será mais escalável que uma arquitetura simples se a carga entre a camada de negócio e a camada web for pequena [JOH2004].46 web Nesse cenário será necessário rodar as regras de negócios em mais containeres EJB. Segundo [JOH2004]. Se um usuário estiver associado a um servidor e esse vir a quebrar. O usuário encontrará problemas da mesma maneira. poderá ser confiável dependendo diretamente da tecnologia usada no cluster do servidor web. a aplicação.1. Entretanto. Qualquer aplicação com armazenamento de estado sofre do problema de server afinity. 4. sendo distribuída ou não.

Como mostrado no capítulo 3. Se o caso for desenvolver uma aplicação baseado em RMI/IIOP.1. O servidor J2EE é responsável por toda a infra-estrutura para o uso e propagação de transações. Quando se deve usar EJB? Essa é uma das decisões mais importantes acerca do projeto.1.1: Arquitetura J2EE robusta e escalável. Gerenciamento de transações Se o uso de EJB não é requerido para arquiteturas distribuídas.3. como tempo de desenvolvimento. existe ainda um outro bom motivo para o uso de EJB. Adaptado de [JOH2004] 4. ferramentas produtivas etc. necessariamente difícil de implementar. Ele coordena em um nível considerado baixo os protocolos transacionais.1. Uma das promessas de J2EE era deixar o baixo nível de implementação de 47 . experiência da equipe. 4. EJB é a tecnologia J2EE que mais é indicada para a implementação.3. Com o uso de EJB com interfaces remotas. pois envolve muitos pontos cruciais. facilidade de testes. O servidor também é responsável pela propagação das transações entre os dispositivos J2EE. sendo esses locais ou distribuídos. o gerenciamento de transações pelo container (Container Manager Transaction) é provavelmente uma das maiores causas de uso de EJB. e provadamente muito mais difícil de manter. nós deixamos o servidor J2EE tratar toda a comunicação remota da aplicação. A alternativa de se criar seu próprio servidor RMI não é aconselhável por diversos motivos: não padronizado. O uso de EJB deve ser ditado se a aplicação será distribuída ou não.47 Figura 4.

Percebe-se claramente que o desenvolvimento de EJBs é bem mais complexo que o desenvolvimento de classes Java normais chamadas de POJOS (Plain Old 48 . O servidor deve prover a implementação dessas interfaces em tempo de deploy.48 transações dos EJBs). Aspectos negativos de EJB Fora o uso de EJBs orientados a mensagens. Recomenda-se o uso de demarcações declarativas. cujo qual é considerado bastante complexo.ejb. os métodos de ciclo de vida do EJBs. ou programática (dentro Os EJBs são os componentes de negócios de J2EE que são capazes de administrar transações.1. cada grupo de EJB é instalado no servidor de aplicação através de um arquivo comprimido chamado ejb-jar. o servidor de aplicação é responsável por gerar algumas partes do componente EJB.2.3. O container deve prover a implementação dessas classe em tempo de deploy de acordo com a classe de implementação do EJB. com isso. Estes apenas usam de forma declarativa. para cada EJB é necessário o desenvolvedor implementar pelo menos três classes Java. Essa interface provê os métodos de negócio que os clientes são capazes de acessar no EJB. • Classe de implementação do EJB. Essa classe deve implementar a interface javax. além de definir a implementação da interface de negócio. definindo. Essa interface permite a localização e criação de componentes EJBs. Em tempo de execução.EntityBean. pois ficam independentes da implementação do EJB e podem ser mudadas sem que haja uma recompilacão da classe do EJB.SessionBean ou javax. deixando isso totalmente abstrato aos desenvolvedores. como os stubs e esqueletos presentes em qualquer aplicação distribuída. que deve possuir um ou mais arquivos de configuração XML. • Interface home local ou remota. ou podem ser demarcadas dentro de métodos do próprio EJB usando a interface UserTransaction oriunda da API JTA. a cargo do servidor. Além desses requisitos.ejb. Essas transações podem ser demarcadas de uma maneira declarativa através do descritos dos EJBs. • Interface de negócios local ou remota. 4.

4.1 do EJB. assegurando que a escolha correta de contexto transacional seja fornecida [JOH2004]. Na especificação 1. com a nova especificação 2.0. gerenciando com isso seus acessos. Com isso. o container precisa ter total controle das instâncias em tempo de execução. os componentes CMP passaram a ter uma maior performance. Mas por que tudo isso é necessário? Para se entregar serviços com um gerenciamento transparente de transações. a plataforma J2EE dispõe de componentes chamados beans de entidade que podem ser gerenciados por container ou pelo desenvolvedor. além de ser extremamente mais simples de desenvolver que beans gerenciados pelo desenvolvedor. O uso de classes geradas pelo container permite que as chamadas a métodos EJBs sejam interceptadas pelo servidor. Muitas vezes é dada uma infra-estrutura enorme que não necessariamente será usada por completo. visto que trabalhar com EJB é bem mais burocrático que 49 . Como mencionado na seção de EJBs. além de tratar uma série de exceções da plataforma. para o acesso a dados.2. os autores afirmam que o custo de se desenvolver e manter uma aplicação EJB não é vantajoso o suficiente para muitas aplicações. Porém sempre é válido escolher o uso de entities beans para o acesso a dados em aplicações? Alguns pontos são levantados acerca do uso de EJB para a camada de persistência: • O uso de beans de entidade representa uma clara separação entre a camada de acesso a dados e a camada de negócio. os componentes BMP eram considerados mais performáticos. Entretanto. Os clientes. Acesso a dados em aplicações J2EE O acesso a dados é vital para uma aplicação distribuída ou não. A performance da fonte de dados irá implicar diretamente na escalabilidade e performance da aplicação. porém a escolha de EJB na camada de dados afetará a comunicação feita na camada de negócios.49 Java Objects). uma tarefa extremamente importante de arquitetos é a separação do que pertence à camada de negócios e à camada de dados. para acessarem EJBs precisam fazer consultas através de JNDI. porém.

Porém. como o custo de manutenção. com isso. Comparado com frameworks de mapeamento objeto-relacional. um melhor meio de acesso. pode-se concluir que a escolha de se usar EJBs é bem custosa e não aplicável na maioria dos casos. os CMPs oferecem poucas funcionalidades. • • • O ciclo de vida dos beans de entidade é bem rígido. que na maioria das vezes é desenvolvido em um tempo mínimo e com diminuição de gastos.50 trabalhar com simples objetos Java. em contraste com o CMP e BMP dos beans de entidade. porém pode-se escolher um framework objeto-relacional ou simplesmente usar algumas classes helpers em conjunto com o padrão DAO (visto no capítulo 2). deve-se perceber que os EJBs de entidade podem ser efetivos em algumas aplicações J2EE. Neste sentido. Pode-se continuar usando EJBs de sessão para manipular as regras de negócios. conforme pode-se verificar no capítulo 5. Com o levantamento dos problemas acima. É difícil implementar beans de granularidade grossa com EJB. desenvolvimento e treinamento para um projeto. a elaboração de uma arquitetura capaz de suprir os requisitos suportados pelos EJBs deve ser cuidadosamente elaborada e explicada. Comparado com o gasto de se usar EJBs de sessão (gerenciamento transparente de transação. Apesar de muitos serviços oferecidos pelos servidores de aplicação. Como veremos a seguir. apesar de ela não ser a melhor escolha entre a camada de negócios e a camada física de armazenamento. [JOH2004]. Essa técnica também é chamada de Session Managed Persistence (SMP). algumas alternativas podem ser escolhidas para proporcionar uma camada de acesso a dados mais simples e flexível. o preço alto que se paga não vale a pena. proporcionando. segurança) os beans de entidade oferecem maior complexidade. Um uso típico de entity beans é o uso de EJBs de sessão como fachada para o acesso. 50 .

é obrigado a utilizar o JNDI para realizar a busca pelo recurso. vem se tornando uma constante no campo de desenvolvimento de software no cenário brasileiro e mundial. Inversão de controle. se o EJB for remoto. uma API para a busca de recursos e localização de EJBs remotos ou não.51 Capítulo 5 Uso de arquiteturas leves com a adoção de novos conceitos A demanda por projetos com um prazo cada vez menor e com poucos recursos. Além do uso de frameworks para a diminuição do trabalho. os autores pretendem mostrar detalhes da elaboração de uma arquitetura bem mais viável para o desenvolvimento de software. Fica praticamente inviável a elaboração de arquiteturas com grau de complexidade elevado. a utilização de novos conceitos será fundamental para a disponibilização de recursos que antes eram apenas possíveis dentro de um servidor de aplicação através de EJBs. Cada componente EJB. deixando o código ainda mais acoplado à 51 . orientação a Aspectos.1. 5. pode-se citar: gerenciamento declarativo de transações. Mensagens orientadas a objetos Java normais. ele deverá também fazer uma conversão para que recursos disponíveis do protocolo IIOP. tratando as devidas exceções provenientes da API. que se responsabilizam pela camada de negócios e também a camada de dados possuem grande acoplamento a certas tecnologias. Para um cliente acessar um EJB. Diminuição de Acoplamento Um aspecto presente em diversas arquiteturas J2EE é o forte acoplamento entre as camadas. é necessário realizar a mesma consulta por JNDI. como origens de dados. ou configurações específicas. a arquitetura se baseia em alguns projetos de código aberto desenvolvidos pela própria comunidade Java. Um exemplo típico é o uso de JNDI. entre outros. a fim de alocarem profissionais ou comprar ferramentas. mesmo com a utilização do modelo de componentes EJBs. com isso. para obter acesso a outros componentes. fácil testabilidade. Dentre os conceitos. Tendo isto em mente. Tal arquitetura não adotará o modelo de componentes padrão do J2EE (EJBs). filas de mensagens.

env.naming:org. ele possui um fábrica de beans que pode disponibilizar varias instâncias ou uma única instância de um bean para a aplicação (Singleton). nota-se que não se trata de uma tarefa trivial.1 temos um exemplo de código de acesso a componentes EJBs por um cliente comum. pode-se minimizar o esforço de manutenção do código.println(hello.hello())."org. a necessidade de recompilacão quando uma eventual mudança de configuração for necessária.52 tecnologia J2EE.pkgs". É um framework orientado a POJOS.put("java. Usando conceitos como inversão de controle.jnp. HelloHome home HelloHome)PortableRemoteObject.interfaces.url".factory. Os autores entendem que se deve procurar diminuir o acoplamento a camadas de um sistema.jboss.naming.narrow(obj. Hashtable env = new Hashtable(). env. a manutenibilidade e uma eventual mudança podem se tornar tarefas bastante custosas.NamingContextFactory").initial". System.put("java.HelloHome. Hello hello=home. Os detalhes sobre Inversão de controle serão explicados na próxima seção.1: Código de acesso a componentes EJB Com um código muito acoplado a certas tecnologias. InitialContext context = new InitialContext(env).provider.url.jnp. env."org. os autores dão ênfase ao framework Spring [SPR2006] para a administração dos recursos.out. Object obj=ctx. minimizando.naming. Os componentes são registrados e configurados em um arquivo XML.class). Listagem 5. 52 . o Spring diminui o acoplamento entre módulos e entre componentes. Com a adoção de frameworks para o gerenciamento de componentes de uma forma limpa.interfaces")."localhost"). assim.create(). Context ctx = new InitialContext(env).put("java. além do ciclo de vida dos componentes.lookup("java:comp/env/Hello"). O Spring trabalha com a idéia de classes simples Java fornecerem funcionalidades para qualquer sistema. Para o gerenciamento de beans. Na listagem 5.factory. No presente trabalho.naming.

Ambos devem depender de abstrações”. que é uma estrutura resultante do uso de dois princípios: Open-Closed Principle (OCP) e Liskov Substitution Principle (LSP).2. A interface.1. que possui uma referência da interface “MovieFinder”. e implementa o método setter desta referência. possui apenas o método “findAll”: 53 . De acordo com [WIK2006]. Formas de implementação de Inversão de Controle De acordo com [FOW2004]. utilizando a plataforma Java e o framework Spring. Ou seja.2. ficando o máximo possível independente uma classe da outra. Setter Injection Esta é uma forma de implementação de Inversão de Controle que utiliza os métodos “setter” para injetar o objeto referenciado no objeto corrente. Inversão de Controle O conceito de inversão de controle não é atual. ele surgiu com o princípio da inversão de dependência (Dependency Inversion Principle – DIP). Este princípio prega que “os módulos de alto nível não devem depender dos níveis mais baixos. por sua vez. Constructor Injection e Interface Injection.1.53 5. temos um exemplo bem simples desta forma de Inversão de Controle.1. o padrão inversão de controle (Inversion of Control – IoC) é um padrão que “mostra” como o desenvolvedor deve projetar suas classes e suas interdependências de uma maneira que tenha um baixo acoplamento. Este controle é delegado a um container”. e também prega que “As abstrações não devem depender de detalhes. esta forma é muito útil quando se tem um objeto que necessita modificar suas propriedades várias vezes durante o seu ciclo de vida. Inversão de controle é “o nome dado ao padrão de desenvolvimento de software onde o controle de chamadas de métodos não é determinado pelo programador. 5. Segundo [MAL2005].2. Em [FOW2004]. Este exemplo é mostrado a seguir: A classe “MovieLister” é um JavaBean simples. A principal desvantagem do Setter Injection é que ele burla os princípios da orientação a objetos: o encapsulamento e o ocultamento de informações. 5. Estes devem depender das abstrações” [MAR1996]. o padrão de Inversão de Controle pode ser implementado através de três formas: Setter Injection.

<beans> <bean id="MovieLister" class="MovieLister"> <property name="finder"> <ref local="MovieFinder"/> </property> </bean> <bean id="MovieFinder" class="ColonMovieFinder"> 54 . } } Listagem 5.54 public interface MovieFinder { List findAll(). A configuração também poderia ser feita através de código. onde será ditada a injeção.filename = filename. public class ColonMovieFinder { private String filename. que possui apenas um atributo do tipo String onde irá posteriormente ser injetado um arquivo (neste exemplo.finder = finder. public void setFilename(String filename) { this. } } Listagem 5.3. public void setFinder(MovieFinder finder) { this. um arquivo texto). há um arquivo XML que possui toda a configuração.: Exemplo de classe que implementa o método setter Há também uma classe denominada “ColonMovieFinder”.4: Exemplo de classe que possui um atributo posteriormente injetado Por fim. } Listagem 5.2: Exemplo de Interface com método findAll public class MovieLister { private MovieFinder finder.

ao invés de usar o framework Spring. ele utiliza o framework PicoContainer: A classe “MovieLister” será modificada.1.2.txt</value> </property> </bean> </beans> Listagem 5. com a diferença de que.7: Classe a lógica fica localizada no seu construtor 55 . Seguindo o exemplo do Setter Injection. ao invés de ter um atributo do tipo “MovieFinder” (definido anteriormente). } } Listagem 5. onde as propriedades do objeto referenciado são públicas.filename = filename.5: Arquivo XML com configuração da injeção 5. a classe “ColonMovieFinder” também deixa de ter um atributo do tipo String. diferentemente do Setter Injection.6: Classe onde será feita a injeção através do construtor Da mesma forma. [FOW2004] também mostra um exemplo simples do uso do Constructor Injection. Constructor Injection Esta é uma forma de Inversão de Controle que utiliza o construtor da classe para injetar a referência ao objeto.2. e passar a receber no seu construtor um parâmetro deste atributo: public class ColonMovieFinder { public ColonMovieFinder(String filename) { this. terá um construtor que recebe como parâmetro este atributo: public class MovieLister { public MovieLister(MovieFinder finder) { this. } } Listagem 5.55 <property name="filename"> <value>movies1. A principal vantagem do Constructor Injection é que apenas o criador da classe conhece as propriedades do objeto referenciado. onde.finder = finder.

De acordo com [MAL2005]. Da mesma maneira que as duas formas anteriores. private MutablePicoContainer configureContainer() { MutablePicoContainer pico = new DefaultPicoContainer(). } Listagem 5.2.56 O arquivo de configuração. return pico. Interface Injection Nesta forma de Inversão de Controle é criada uma Interface para o framework IoC (Inversion of Control).txt")}. que recebe o arquivo texto como um parâmetro constante e registra as classes onde serão injetados os objetos. utilizando o framework Avalon: Primeiramente é criada uma interface que irá injetar os objetos.class. pico. a principal desvantagem desta forma de inversão de controle é que a criação da interface faz com que a aplicação fique presa a determinado framework.1.registerComponentImplementation(MovieFinder. pico. nesse exemplo. Parameter[] finderParams = {new ConstantParameter("movies1.9: Interface que irá injetar objetos através do Interface Injection 56 .registerComponentImplementation(MovieLister.class). É nesta interface que os objetos irão ser injetados. ColonMovieFinder. } Listagem 5.class. [FOW2004] mostra um exemplo de utilização da Interface Injection.8: Arquivo Java de configuração de injeção 5.3. finderParams). Esta interface terá um método que recebe como parâmetro um atributo do tipo “MovieFinder” (definido anteriormente): public interface InjectFinder { void injectFinder(MovieFinder finder). é um método Java.

filename = filename.12: Classe que implementa a interface da listagem 5. de acordo com a regra. que irá implementar uma interface “InjectFinderFilename”. e. é criada uma classe de configuração. Esta classe irá registrar as classes que possuem os objetos a serem injetados. também há um método que registra as interfaces definidas: 57 .11: Interface que deverá ser implementada public class ColonMovieFinder implements MovieFinder. } } Listagem 5.57 A classe “MovieLister” é modificada novamente. e. a classe terá que implementar o(s) método(s) definidos na interface: public class MovieLister implements InjectFinder { public void injectFinder(MovieFinder finder) { this. public interface InjectFinderFilename { void injectFilename (String filename).10: Classe que implementa a interface do interface injection Da mesma forma para a classe “ColonMovieFinder”. } Listagem 5.finder = finder. Além disso. igualmente como ocorre com o Constructor Injection. conseqüentemente. Desta vez. o método definido na interface. esta classe irá implementar a interface definida acima. } } Listagem 5. InjectFinderFilename { public void injectFilename(String filename) { this.11 Por fim.

[FOW2004] trata a Inversão de Controle como um sinônimo de dependency Injection.registerComponent("MovieLister".58 public class Config { private Container container.class). sempre que falar de Dependency Injection estará falando de Inversão de Controle. private void configureContainer() { container = new Container(). MovieLister. } private void registerComponents() { container. Dependency Injection é um subtipo de Inversão de Controle. Neste sentido. ColonMovieFinder. container.class.class). new FinderFilenameInjector()). container.registerComponent("MovieFinder". nem sempre que falar de Inversão de Controle estará falando de Dependency Injection. Para [HAR2005]. já [HAR2005] mostra que são conceitos distintos.start(). porém. 58 . container. container. } private void registerInjectors() { container. } } Listagem 5. ou seja.13: Arquivo de configuração para o Interface Injection Porém. registerInjectors(). [HAR2005] cita que a Inversão de Controle é dividido em duas partes: Dependency Injection e Dependency Lookup.class. registerComponents().registerInjector( InjectFinderFilename.registerInjector( InjectFinder.lookup("MovieFinder")).

2. ambos conceituados anteriormente. Aslak Hellesoy. que diz que “os construtores com parâmetros mostram um enunciado claro do que significa criar um objeto válido em um lugar óbvio”. • Dependency Pull: Este tipo de Dependency Lookup é comum para os desenvolvedores Java. Outra diferença entre eles é que com o Dependency Lookup o componente deve obrigatoriamente adquirir uma referência da dependência. E o Dependency Injection é dividido em Setter Injection e Constructor Injection.. portanto. Para ele..2. No Dependency Pull. ambos conceituados a seguir. o Constructor Injection é 59 . enquanto que o Dependency Injection é mais atual. desenvolvedor Sênior da empresa ThoughtWorks Inc. o lookup é executado de acordo com o container que gerencia o recurso. por exemplo. Uma das vantagens do Constructor Injection foi mostrada por [BEC1996]. Porém.. os mais utilizados são o Constructor Injection e o Setter Injection. e também mais flexível e usado que o outro. a dependência é conseguida através de registros. Por este motivo há os métodos-Fábrica. que podem combinar construtores privados com métodos setter. o que torna o código muito confuso. ao invés de conseguir a dependência através de um registro. Entretanto também há problemas com a utilização desses métodos: normalmente eles são métodos estáticos. Em uma entrevista dada para [SER2006]. pode haver casos em que seja preciso a existência de muitos construtores. e. [FOW2004] faz uma comparação interessante entre as duas formas de Inversão de Controle. • Contextualized Dependency Lookup: Este tipo é bastante similar ao anterior. porém. pois eles normalmente utilizam-no para acessar um EJB. diz que “. Cada subtipo de Inversão de Controle possui subtipos também. Constructor Injection x Setter Injection Apesar de haver vários tipos e subtipos de Inversão de Controle. e no Dependency Injection a dependência é injetada no componente através do container IoC. não há diferenças muito grandes entre o Constructor Injection e o Setter Injection”. não podem ser usados em interfaces [FOW2004]. O Dependency Lookup é dividido em Dependency Pull e Contextualized Dependency Lookup (CDL).. 5.59 O Dependency Lookup é um conceito mais antigo.

Neste sentido. principalmente. mas também tem que lembrar de invocar os métodos setter. o usuário só pode criar os componentes que irão utilizar esta forma de Inversão de Controle depois de passar tudo o que ela irá precisar. produzindo saídas corretas para entradas que geram defeitos. Testabilidade em Aplicações J2EE O uso de testes em qualquer aplicação. com o intuito de evitar que o usuário invoque o método setter inadequadamente. identificação de problemas. onde pode haver vários construtores.60 melhor. tornando o código confuso. Outro fator que contribui para que uma aplicação tenha uma baixa testabilidade é quando os requisitos desta são incompletos ou desatualizados. mais simples de utilizar e. Além disso. o usuário pode criar o componente que vai utilizar esta forma de Inversão de Controle. já está pronta para ser usada. Já com o Setter Injection. primeiramente. Atualmente. a maioria oferece suporte apenas ao teste estrutural (neste tipo de teste. Uma aplicação tem baixa testabilidade se ela tende a ocultar as falhas detectadas durante os testes. no entanto. nas suas opiniões. pelo motivo mostrado anteriormente. pois. Com a crescente complexidade dos softwares. custoso e propenso a erros e ferramentas que apóiem essa atividade são essenciais. se houver objetos imutáveis na classe. 5. Outro motivo dado por Hellesoy é também conhecido como “bom cidadão” (termo dado por Josh Bloch). pode-se citar como as maiores motivações para testar uma aplicação: Validação de código. encontram-se disponíveis diversas ferramentas que buscam atender a esse propósito. que diz que quando uma classe é instanciada. em geral. pois os testes ajudam a aplicação a conter menos erros. Os autores deste trabalho e [HAR2005] preferem usar o Setter Injection. pode-se dizer que uma aplicação tem alta testabilidade se ela tende a expor suas falhas durante os testes com entradas que geram defeitos. com o Setter Injection. também conhecido com 60 . aumentando a qualidade da aplicação.3. devido ser. é muito importante. seja ela Web ou Desktop. bugs drásticos e verificação de comportamentos sobre condições específicas. Com o Constructor Injection. terá que ter várias flags indicando se o objeto é nulo ou não. O teste de software é. torna-se fundamental a utilização de ferramentas de teste visando a automatização dessa atividade.

erros de estrutura de dados ou de acesso a dados externos. as poucas ferramentas que implementam a técnica funcional (essa técnica. além do custo dos erros crescer exponencialmente com o atraso na descoberta dos mesmos.1 mostra como funcionam os testes funcionais (caixa preta): 61 . diferentemente do teste estrutural) desconsideram seus principais critérios e não permitem análise de cobertura apropriada. é verificado se a estrutura interna da unidade está correta e se todos os caminhos internos possíveis do objeto devem ou não ser percorridos). A figura 5. Técnica Funcional Como falado anteriormente.61 caixa-branca. É importante ressaltar que o objetivo dos testes é encontrar erros. possui os testes que encaram o sistema a ser testado como uma função que mapeia um conjunto de valores de entrada em um conjunto de valores de saída sem se preocupar com a forma como esse mapeamento foi implementado. Além disso. provavelmente o teste está errado. devido o trabalho de desenvolvimento de um software se basear em trabalhos anteriores. Além disso. fazendo com que o testador sequer tenha acesso ao código-fonte. pois os desenvolvedores tendem a cometer erros mais quando estão recolhendo requisitos do que durante o processo de desenvolvimento propriamente dito. também conhecida como caixa-preta. Além disso.1. 5. nestes testes são consideradas apenas as entradas e as saídas. erros de interface.3. erros de comportamento e erros de iniciação e término. é extremamente importante testar uma aplicação frequentemente e desde o início do processo da mesma. Se um teste não encontra nenhum problema onde está testando. nos testes funcionais as aplicações são testadas com o objetivo de se encontrar cinco “tipos” de erros: funções incorretas ou omitidas. a técnica funcional (caixa-preta) tem como objetivo encontrar diferenças entre o comportamento que o sistema está desenvolvendo e o comportamento proposto na sua especificação. Isto é.

3. apesar de não apoiar nenhuma técnica de teste específica. Já a especificação de valores-limite é uma complementação da anterior. Tabela 5. A tabela 5. duas características não têm suporte (Especificação de classes de equivalência e Especificação de valores-limite). Além disso.62 Figura 5. XDE tester [XDE2006] e o framework JUnit [JUN2006].1.2: Funcionamento dos testes funcionais A maioria das ferramentas que auxiliam os testes oferece apoio apenas para o teste estrutural (mostrado em 5. Na especificação de classes de equivalência. como TestComplete [TES2006]. A divisão é feita em classes de equivalência válidas e inválidas. este. enfatizando suas características principais com relação aos testes funcionais. ambas são características específicas dos testes funcionais. o domínio de entrada de dados é dividido em classes de dados. SPACES [DAN2006].2).: Comparativo entre ferramentas de teste funcional [DAN2006] Como mostra a tabela. Jtest [JTE2006]. mostra um comparativo entre as ferramentas acima citadas. a tabela mostra claramente que as ferramentas JTest e SPACES são as mais completas. 62 . pode ser utilizado para especificação e execução dos casos de teste [DAN2006]. porém algumas ferramentas específicas para testes funcionais encontram-se disponíveis.1. através de casos de teste que exercitam os valores limítrofes.

há a necessidade de testes unitários. são simplificados. Há basicamente dois tipos de testes que fazem parte da técnica estrutural: os testes unitários (que testam cada componente por vez) e os testes de integração (que testam um conjunto de componentes conjuntamente).2. os testes. ao contrário da técnica funcional.3. A figura 5.3. Esta metodologia é baseada em quatro princípios: Simplicidade. tanto para ter o feedback para os desenvolvedores. assim como os modelos e os códigos. Técnica Estrutural Conforme dito anteriormente. e sim todas as partes do código do sistema. Testes na metodologia Extreme Programing (XP) Extreme Programing é uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança (Kent Beck. permitindo que o software seja modificado à medida que as necessidades do negócio se alteram ou ampliam. como para o desenvolvedor poder gerar releases (versões) do sistema em um curto espaço de tempo sem os chamados 63 . No feedback. não importando apenas as entradas e saídas. Ou seja. tem conhecimento do funcionamento interno das classes que irão ser testadas. Feedback. é um desenvolvimento rápido e consistente com as reais necessidades do cliente e fácil manutenibilidade. Coragem e Comunicação. criador da metodologia XP).3: Funcionamento de testes unitários 5. Os testes se encaixam em três dos quatro princípios.63 5. Na simplicidade.3. mostra como funciona os testes estruturais (caixa branca) do tipo unitários: Figura 5.2. a técnica estrutural (ou caixa-branca).

3. Consertar pequenos problemas assim que são encontrados. escritos pelos desenvolvedores e têm a finalidade de testar uma classe individual ou um pequeno grupo de classes. que. na comunicação. em geral. e o teste antes da codificação é um destes requisitos. Testes unitários são. pois são criados antes do código e armazenados em um repositório junto ao código que será testado. Já os testes de aceitação são usualmente escritos pelos próprios clientes ou por uma equipe de teste externa (com a ajuda dos desenvolvedores) e têm a finalidade de testar todo o sistema. A XP possui doze requisitos básicos. devem ser realizados antes da fase de codificação. É relevante considerar que descobrir todos os problemas que podem ocorrer durante o desenvolvimento consome uma grande quantidade de tempo.3. serão simplificados e precisos. Finalmente. é a economia de custo que podem proporcionar ao identificar e oferecer proteção contra erros. E à medida que um novo código é adicionado. especialmente se estes forem automatizados. Nesta etapa os desenvolvedores criam e executam testes unitários toda vez que um código é escrito ou modificado. de ponta-a-ponta. a criação de testes unitários antes do código provê uma melhor compreensão dos requisitos e direciona o foco dos desenvolvedores. além de oferecerem o estado e o comportamento da aplicação.64 bugs. leva menos tempo do que consertar grandes problemas a poucas horas do prazo final. principalmente. e o código é construído com o propósito de satisfazer os resultados esperados. e não no último mês do projeto. Além disso. pois cada parte do sistema com possibilidade de falha precisa ser verificada. As atividades de teste são realizadas durante todo o processo de desenvolvimento. 5. baseados em códigos simples (como dito anteriormente na simplicidade). Outro benefício dos testes unitários automatizados é a possibilidade de combinar um conjunto de alterações com a última versão liberada 64 . tornando-se necessário que um conjunto completo de testes unitários esteja disponível logo no início. novos testes devem ser realizados para assegurar que não ocorram impactos negativos [JOH2004]. Testes Unitários no XP Os testes unitários são um dos elementos chave em XP [WEL2005]. são feitos os testes unitários propriamente ditos.1. Um código que não possua seu respectivo teste unitário não deve ser liberado. Um fator importante para a utilização de testes unitários. e. Os testes em XP são divididos em duas categorias: testes unitários e testes de aceitação. em geral.

5. o Enterprise JavaBean (EJB) possui serviços de container. e checar cada incremento no ciclo XP para verificar se o valor de negócio está presente [CRI2000]. gerenciados pelo container. Devido o EJB depender destes serviços. são testes ponta-a-ponta sob a perspectiva do cliente. gerentes e desenvolvedores a confiança de que o produto inteiro está progredindo na direção certa. Em ambos os casos XP requerem que o desenvolvimento tenha uma relação muito próxima com QA.2 Testes de Aceitação Os testes de aceitação constituem uma das principais diferenças entre o XP e os processos de desenvolvimento tradicionais. ou a equipe de desenvolvimento não deverá reportar progresso. com a assistência de um indivíduo da equipe responsável por testar o software. Com o EJB não se pode simplesmente instanciá-lo e testá-lo como se faz com classes Java. enquanto em outros QA é integrada à própria equipe de desenvolvimento. a Garantia de Qualidade (QA) é uma parte essencial do processo XP. Após a implementação da user story. 5.3. testar um EJB é um trabalho árduo. Testes de aceitação são testes de sistema de caixa preta e cada um deles representa algum resultado esperado.4. Durante uma iteração. difícil e bem mais complexo do que testar classes Java comuns. e ela não é considerada completa até que tenha passado por esses testes de aceitação. que são responsabilidade do testador e do cliente. Isso significa que novos testes de aceitação devem ser criados a cada iteração. Testes de aceitação também são usados como testes de regressão anteriores à liberação de uma versão do software.3. Uma user story pode ter um ou mais testes de aceitação para assegurar que a sua funcionalidade esteja de acordo com a especificação. Os testes de aceitação. pois os EJB são objetos gerenciáveis. Testes com EJB Como mostrado no capítulo 3. as user stories selecionadas durante a reunião de planejamento de iteração serão traduzidas em testes de aceitação. são escritos pelos clientes ou usuários finais através das user stories [WEL2005]. 65 . Nesse contexto.3. Em geral. e não testes que verificam cada caminho possível no código (essa é a finalidade dos testes unitários). Em alguns projetos QA é realizada por um grupo especializado. Dentre as principais metas dos testes de aceitação estão: fornecer aos clientes. o cliente especifica cenários para serem testados.65 e liberar novas versões em um curto espaço de tempo.

Podese invocar os casos de teste normalmente. Esta é uma boa estratégia para testar EJB em uma interface local. Dentre estas três alternativas. • Testar com objetos stubs modificando objetos do container. Este tipo de teste geralmente funciona apenas quando os EJBs possuem requisitos simples do container EJB. como qualquer outro teste. a mais simples (ou menos complexa) é a primeira. com a diferença de tomar cuidado em prover as propriedades JNDI apropriadas que permitem a conexão do container EJB”. [JOH2004] descreve como deve ser feito o teste nesta alternativa: “Primeiramente. Desenvolver e deploy um teste que será executado em um servidor de aplicação. A tabela 5. tornando um local Desvantagens • Não é possível testar interfaces locais 66 .2 mostra as vantagens e desvantagens da utilização de cada uma destas três alternativas: Alternativa Vantagens • Fácil de escrever e executar testes • Pode usar a estrutura padrão do Teste como um cliente remoto de um container EJB JUnit • As interfaces remotas expostas pelo EJB em uma aplicação distribuída normalmente expõe uma lógica de negócio da aplicação.66 Com isso. os quais conectam com o servidor EJB e são executados em uma JVM (Java Virtual Machine) diferente da JVM utilizada pelo container EJB. escreve-se os casos de teste. há três maneiras de se testar um EJB [JOH2004]: • • Desenvolver um teste que serve como um cliente remoto de um container EJB.

Para facilitar este acesso. vários frameworks foram surgindo. principalmente devido ao uso indevido por parte dos desenvolvedores. sendo que alguns acabam por diminuir a performance da aplicação. Esta dificuldade de testar um EJB é um dos principais motivos que o tornam uma má alternativa de desenvolvimento.2. devido à arquitetura EJB ser altamente complexa. Entretanto. Dois dos principais frameworks de acesso a dados existentes são o Hibernate [HIB2006] e o IBatis [IBA2006]. provavelmente os testes terão o mesmo Teste executado em um servidor de aplicação acesso a um EJB como as aplicações que usam o EJB propriamente dito.67 apropriado para testes • Em aplicações web. deve-se escrever muito código que simula o container testes uma implementação mais • É possível executar os Testes com objetos stubs modificando objetos do container testes sem um container EJB • É possível reusar estruturas de componentes em várias aplicações Tabela 5.: Tabela comparativa das três alternativas de testes com EJB Outra possibilidade de testar um EJB é simular um container para prover os serviços necessários para um EJB funcionar. além de o EJB ser bastante complexo e burocrático por si só. esta é uma possibilidade impraticável. a segurança e o gerenciamento de serviços são difíceis de simular. Camada de acesso a dados simplificada O acesso a dados de qualquer aplicação Web pode se tornar complexo. 5. • Requer um framework de teste adicional ao JUnit • Os possuem complexa. dependendo de como for implementada. • Devido não necessitar de um container. ambos serão discutidos em detalhes nas próximas 67 . Alem disso.4.

4. ocorreu o surgimento de frameworks. O hibernate trabalhando juntamente com o Spring. Por exemplo. com IBatis as inner classes não são utilizadas. pois todo o script SQL é feito manualmente. como o MySQL.68 seções. Além dos frameworks. citaremos a Java Database Connectivity (JDBC). Um exemplo é mostrado na Listagem 5. torna a aplicação menos complexa e com menor quantidade de código-fonte. Outro framework. devido ele proporcionar um controle completo da seleção dos dados. Por isso. responsável por definir a conexão com o banco de dados. uma API que faz o envio de instruções SQL para qualquer Banco de Dados relacional. a junção dos dois tem uma grande vantagem que é a não preocupação por parte dos desenvolvedores em gerenciar a abertura e o fechamento de Sessions. é necessário efetuar algumas configurações: Primeiramente. Tanto o Hibernate. que auxilia no mapeamento objeto-relacional.14.) de uma aplicação. Como este trabalho é desenvolvido sobre a plataforma Java. 68 . novo no mercado. e no próprio desenvolvimento. Alem disso. apesar dos frameworks auxiliarem bastante os desenvolvedores nos quesitos do mapeamento objeto-relacional. deve-se criar um arquivo XML onde se configura o datasource. é o Pérola [PER2006]. há também Application Program Interface (APIs) que auxiliam no acesso a dados. onde se aplicam à maioria dos bancos de dados existentes atualmente. e todas as características padrões do banco de dados se tornam facilmente acessíveis. o IBatis como o JDBC funcionam com o Spring.1. Utilizando Hibernate com Spring Uma das maiores desvantagens do JDBC é que o desenvolvimento com ele exige uma grande quantidade de código. interface responsável por realizar a conexão com o banco de dados. 5. etc. porém não entraremos em maiores detalhes sobre ele. De acordo com [HAR2005]. tornando o entendimento da aplicação mais complexo. Para poder utilizar os dois frameworks em conjunto. Oracle. Todos os frameworks citados são responsáveis por realizar o mapeamento objeto-relacional (responsável por fazer a “transição” de uma aplicação orientada a objetos ou orientada a aspectos para um banco de dados relacional. como o Hibernate. o JDBC se torna melhor para acessar os dados.

jdbc. 1-N.springframework. é possível fazer todos os procedimentos de um banco de dados. Já a grande vantagem do uso do mesmo é que o tempo de desenvolvimento se torna menor com o mesmo. normalizações (1-1. DriverManagerDataSource"> <property name="driverClassName"> <value>org. utilizada para se fazer as consultas no banco de dados. o Hibernate possui uma linguagem própria.org/dtd/spring-beans.69 <?xml version="1.dtd"> <beans> <bean id="dataSource" class="org. Além disso. 69 . chamada Hibernate Query Language (HQL). Uma das principais desvantagens do uso do Hibernate é que ele diminui a performance da aplicação. N-N).jdbcDriver</value> </property> <property name="url"> <value>jdbc:hsqldb:db/app</value> </property> <property name="username"><value>sa</value></property> <property name="password"><value></value></property> </bean> </beans> Listagem 5. como transações.hsqldb. Pode-se usar tanto o HQL como o próprio SQL (Structured Query Language) para se fazer as consultas no banco de dados.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.datasource.14: Configuração de DataSource para uso de Spring com hibernate Com o Hibernate. concorrência e lock. assim como a manutenção do código-fonte da aplicação que o utiliza. mas normalmente é aconselhado que se use o HQL.springframework. além de não ser tão simples manipular os dados que estão sendo buscados numa consulta.

Com o IBatis. Neste mesmo arquivo também é declarado o DataSource. finalmente.2.15. no IBatis a configuração é feita através de um arquivo XML.xml</value> </property> </bean> Listagem 5.xml”/> <sqlMapConfig> Listagem 5. 70 .70 5. também é necessário um arquivo XML que declara os arquivos de mapeamento. <sqlMapConfig> <sqlMap resource=”Client. assim como o Hibernate.. é necessário um arquivo XML para cada mapeamento (normalmente para cada Bean que será mapeado). o desenvolvedor pode escrever sintaxes SQL normalmente.xml”/> <sqlMap resource=”Boss.16: Trecho do arquivo de declaração dos mapeamentos (sqlMapConfig. <bean id = “sqlMapClient” class = “. é um framework que executa o mapeamento objeto-relacional de acesso ao banco de dados. conforme exemplo na Listagem 5. com o SQL propriamente dito.xml) E.15: Trecho do arquivo de configuração do Spring com IBatis (struts-config. Utilizando IBatis com Spring O IBatis. conforme exemplo na Listagem 5.17.4.xml) Além disso. Assim como no Hibernate.SqlMapClientFactoryBean”> <property name = “configLocation”> <value>sqlMapConfig. da mesma forma que no Hibernate. já que com isso a performance da aplicação fica bem melhor. o que torna o IBatis bastante interessante.16. conforme exemplo na Listagem 5..

com.xml) A principal vantagem do IBatis é que ele não gera nenhum código. no Hibernate). ela permite que as classes possuam apenas o código fonte necessário para si. aumentando sua modularização.5. etc. como auditoria. já que o IBatis utiliza o próprio SQL.71 <sqlMap> <typeAlias alias="client" type="br. #nome”) </insert> <select id="listarPorPK" resultClass="client" parameterClass="int"> SELECT ID as id . segurança.sistema. foi utilizado o IBatis em conjunto com o Spring. 5. de não ser necessário o desenvolvedor aprender nenhuma linguagem (como o HQL. Programação Orientada a Aspectos A Programação Orientada a Aspectos (AOP) ajuda os desenvolvedores a modificar dinamicamente seu modelo estático para incluir um código requerido para cumprir os requerimentos secundários sem ter que modificar o modelo estático original. através da clara separação dos chamados requisitos funcionais 71 . Pode-se dizer que a AOP complementa a programação Orientada a Objetos com a grande vantagem da redução da complexidade do projeto.Client"/> <insert id=" gravar" parameterClass="client"> INSERT INTO CLIENT (ID. Além disso. sem a necessidade de possuir blocos “auxiliares” para outros objetivos. além. que cumpram com os seus objetivos. Na aplicação desenvolvida neste trabalho.NOME as nome FROM CLIENT WHERE ID = #id# </select> <delete id="excluir" parameterClass="int"> DELETE FROM CLIENT WHERE ID = #id# </delete> </sqlMap> Listagem 5. NOME) VALUES (#id#.17: Exemplo de arquivo de mapeamento de um determinado Bean (Client.

JBossAOP [JBO2005] e o Spring Framework [SPR2006]. deixando de lado aspectos de projeto. As classes passam a possuir apenas a regra de negócio. reutilização.1. Separação na implementação e testes. mas sim tem a preocupação de mostrar como usar aspectos para solucionar requisitos do cotidiano de uma aplicação e. e extensibilidade de software. Alterações nos aspectos de projeto não geram impacto nas classes. podem-se obter algumas vantagens. O framework Spring fornece um módulo de seu projeto todo voltado a programação orientada a aspectos.5. como: • • • • • • • • Códigos mais simples. Apóia o desenvolvimento com IDEs (Integrated Development Environments).72 (denominados Objetos) e não-funcionais ou entrelaçados (denominados Aspectos). Não há ainda nenhuma linguagem que possua suporte nativo à Orientação a Aspectos. outros componentes no Spring. usando o modelo de componentes EJB. como a presença de demarcação declarativa de transações. provém um serviço baseado em AOP para a simplificação de tarefas em sua arquitetura. como gerenciamento declarativo de transações e classes auxiliares para EJB. Útil para implementar distribuição. Modularidade. Produtividade. Neste trabalho nos aprofundaremos apenas no Spring Framework. sobretudo implementar funcionalidades antes presentes apenas em servidores de aplicação. Além disso. uma vez que as classes possuem apenas as regras de negócio. e persistência. Maior produtividade na manutenção. controle de concorrência. com uma série de serviços que fazem o uso de AOP bem mais simples. AspectWerkz [ASP2005]. conforme descrito na próxima seção. como AspectJ [ASP2006]. 72 . Programação Orientada a Aspectos com Spring O trabalho não visa um aprofundamento nos conceitos de aspectos. Com a separação destes blocos. uma vez que um mesmo aspecto pode ser aplicado às diferentes classes de um projeto. 5. surgiram vários frameworks para auxiliar na mesma. Por este motivo.

73 5. com isso o framework assegura que exista uma transação apropriada para o contexto quando o método for chamado. Gerenciamento robusto e elegante de Transações Como mencionado anteriormente. O uso de transações globais sem o uso do Spring normalmente é feito através da API JTA12. Assim. uma importante decisão deve ser tomada em uma arquitetura quando se usa transações: Devem-se usar transações globais ou locais? Transações locais são especificas a um simples recurso transacional (uma conexão JDBC. por exemplo). acarretando.6. Declarativo nesse contexto significa que se declara para o Spring se um método possui um escopo transacional. o foco na seção de AOP será para mostrar como funciona o gerenciamento declarativo de transações que o framework Spring proporciona. os pontos de transações locais terão que ser abandonadas. uma grande quantidade de código de gerenciamento de transação em diversos pontos do código. [HAR2005] Na maioria das ocasiões. que é considerada bem complexa e depende da API JNDI. A grande vantagem de se usar a forma declarativa de demarcação de transações é que não é necessário modificar o código para se alterar a definição transacional. com JTA é possível utilizar EJB e sua funcionalidade de gerenciamento declarativo de transações. 12 API para tratamento de transações na plataforma Java. há um exemplo de configuração de demarcação transacional para os métodos do serviço. Na listagem 5. com isso.18. já uma transação global é gerenciada por um container e pode ter diversos recursos transacionais. sistemas pequenos e simples. proveniente de um servidor de aplicação. Se o desenvolvedor optar por usar Spring ou não. além de que se no futuro for necessário usar um esquema global de transação. significando que é necessário o uso de um servidor de aplicação. 73 . Com a utilização do framework Spring. uma escolha de transações locais é normal. pode-se tirar proveito do suporte a transações globais de forma declarativa. Utilizando fortemente interceptores nas chamadas de métodos por AOP [HAR2005].

JtaTransactionManager" /> <bean id="uc" abstract="true" class="org.ibatis.BMSBusinessException</prop> </props> </property> </bean> <!-- Datasource da aplicação --> <bean id="dataSource" class="org.jndi.springframework.orm.ISOLATION_DEFAULT.springframework.TransactionProxyFactoryB ean"> <property name="transactionManager"> <ref bean="transactionManager" /> </property> <property name="transactionAttributes"> <props> <prop key="*">PROPAGATION_REQUIRED.transaction.springframework.springframework.interceptor.JndiObjectFactoryBean"> <property name="jndiName" value="java:comp/env/jdbc/mes" /> </bean> <bean id="sqlMapClient" class="org.xml</value> </property> <property name="dataSource"> <ref bean="dataSource" /> </property> </bean> 74 .dtd"> <beans> <bean id="transactionManager" class="org.org/dtd/spring-beans.transaction.jta.springframework.74 <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.SqlMapClientFactoryBean"> <property name="configLocation"> <value>classpath:br/com/bms/mes/aci/eis/data/daoimpl/ibatis/sql-mapconfig.

nesse exemplo. o uso de mensagens assíncronas é bastante importante em aplicações distribuídas. pois dependendo do tipo e complexidade da requisição feita 75 . Por fim. 5. O primeiro passo é a declaração de nosso gerenciador de transações (transactionManager). muito menos o uso de EJBs. o proxy entre em ação e intervenha atribuindo ou não o contexto transacional no contexto.75 <bean id="dao" abstract="true"> <property name="sqlMapClient"> <ref bean="sqlMapClient" /> </property> </bean> </beans> Listagem 5. os autores acreditam que se pode ter um ambiente com contexto transacional declarativo sem a necessidade de um servidor de aplicação.7. criamos uma classe abstrata uc referente a todas as nossas classes de negócio.18: Arquivo de configuração de demarcação transacional para os métodos do serviço No trecho acima percebemos alguns beans sendo configurados. entre outras). o tipo de isolamento das transações e por último as exceções que automaticamente darão rollback na transação se for lançada no método configurado. percebemos a propriedade injetada por IoC transactionAttributes. que tipo de contexto transacional será usado (usar uma transação existente. A seguir. Aumentando. é usado um proxy para que quando alguém tente chamar alguma vez uma classe de negócio. a qualidade e integridade da camada de negócios gerenciada pelo framework Spring. No bean uc. novamente sem o uso de um servidor de aplicação para o envio e o consumo de mensagens tanto síncronas com assíncronas. Uso de mensagens Assíncronas Atualmente. criar sempre uma nova transação. que define quais métodos serão beneficiados pelo contexto transacional. falaremos do uso de mensagens em uma arquitetura leve. com isso. Com isso. posteriormente.

e que permitem utilizar características do software menos evidentes ao usuário tradicional. mesmo que ele não esteja disponível no momento do envio da mensagem. A arquitetura de uma JMS é dividida basicamente em três partes: • JMS Providers: São servidores que implementam as interfaces da JMS. recebimento e leitura de mensagens. Estes clientes podem consumir tanto mensagens síncronas como mensagens assíncronas. entre outros. A figura abaixo mostra como funciona a arquitetura básica de uma JMS: Figura 5. as mensagens assíncronas (e as síncronas também) são implementadas através da API13 Java Message Service (JMS). como MQSeries [MQS2006]. Ela é composta por uma série de funções acessíveis somente por desenvolvedores. Há vários JMS Providers. É através deles que as mensagens passam de um cliente a outro. envio. bastando apenas que tenham um destinatário em comum e uma mensagem compartilhada. Os providers são responsáveis também por garantir que a mensagem será entregue a um cliente. • • Mensagens: São os objetos que são trocados entre os clientes. Clientes JMS: São os sistemas (componentes) que recebem e/ou enviam as mensagens.4: Arquitetura básica de uma JMS Conjunto de rotinas e padrões estabelecidos por um software para utilização de suas funcionalidades. a comunicação entre sistemas (aplicações ou módulos). além da criação. a JMS não é e-mail. Sempre haverá um provider entre eles para transportar as mensagens. além de a JMS trabalhar na comunicação entre sistemas e o e-mail na comunicação entre pessoas. Na plataforma Java. Uma das grandes diferenças entre a JMS e o e-mail é que com a JMS há a garantia de que o receptor irá receber a mensagem. a aplicação não pode ficar parada. Vale ressaltar que dois clientes não interagem diretamente entre si. Esta API permite. SonicMQ [SON2006] e o OpenJms [OPE2006]. 13 76 .76 pelo cliente. Ao contrário do que se pode imaginar.

O Spring referencia o MDP. o JCA container provê um eficiente gerenciamento de filas do JMS e processa mensagens paralelamente. Além disso. porém para simples JavaBeans (classes simples de Java). o que torna o MDB bastante aliado a arquitetura. e o Message Driven Pojos14 15 (MDP). Com isso. defende que o MDP é um MDB. que será visto na próxima seção. processa a mensagem e envia para o cliente. Com Spring. 5. pois é ele quem cria as filas e chama o MDP POJOs são objetos Java que seguem a estrutura de um JavaBean. neste trabalho irá ser aprofundado o Message Driven Bean (MDB) e o Message Driven Pojos (MDP). O MDB já foi discutido no capítulo 3.1. Já o MDP pode ser executado em qualquer arquitetura. que por sua vez. que é utilizado pelo Spring e pelo Java Connector Architecture (JCA).77 Há também alguns elementos que se localizam entre o JMS Provider e os clientes. Craig Walls. Como exemplos desses elementos. autor de um livro sobre Spring (Spring in Action). 15 O JCA provê uma solução para a conectividade entre os servidores de aplicação e os sistemas de informação corporativos. Quando o JMS Provider recebe uma mensagem. Este processamento de mensagens paralelas (concorrentes) é uma das principais características do JCA. o ambiente de desenvolvimento não é composto por servidores de aplicação. Há duas formas de utilização de MDP: Através do Spring e através do JCA. Esse processamento é feito através de um pool de conexões e sessões de JMS. pode-se dizer que a principal diferença entre eles é que o MDB deve obrigatoriamente ser executado em um container EJB. pode-se citar o Message Driven Bean (MDB). Com JCA. Ao se fazer uma comparação entre MDP e MDB. Message Driven Pojos (MDP) Como dito anteriormente. ela dispara essa mensagem para o MDP (gerenciado pelo Spring). com o MDP. que não possuem nenhum conhecimento de código de infra-estrutura. bastando apenas que haja um JMS Provider.7. e sim as mensagens são enviadas a um canal que o bean escuta. mas vale ressaltar que não é possível enviar uma mensagem diretamente a um MDB. O Spring acaba por atuar como coordenador de todo o processo. o MDP pode utilizar todas as características providas pelo Spring. e um container Web (como o Tomcat. 14 77 . onde ambas se complementam e podem ser utilizadas conjuntamente. que é utilizado pelo EJB e já foi discutido no capítulo 3. por exemplo) possui um JMS Provider.

5: Funcionamento do MDP 78 .78 quando existirem mensagens.4 demonstra como funciona o processo. A figura 5. Figura 5.

79 . com uma interface amigável para o usuário. 6. Ela demonstra o momento em que a aplicação obteve uma estabilização no tempo de resposta.1.1 mostra a interface do JMeter. Testes de carga é o processo de simular requisições clientes. melhor explicada na próxima seção). como o JMeter. momento este que foram coletados os dados para os gráficos mostrados na próxima seção. Testes de Carga Teste de carga no servidor é comumente usado para mensurar a performance de aplicações web. que é um projeto open-source de testes de carga da Apache© [JME2006]. passos devem ser tomados a fim de descobrir tais problemas. executando uma das aplicações que foi desenvolvida neste trabalho (a aplicação utilizando Spring.79 Capítulo 6 Realização de testes de carga em aplicações usando arquiteturas EJB e arquiteturas leves em J2EE Com o intuito de finalizar as discussões sobre a adoção ou não de novas técnicas de arquiteturas. além de se definir a quantidade de threads as quais serão executadas (trabalhando como quantidade de usuários simultâneos que acessam a aplicação). Normalmente quem executa testes de carga são ferramentas específicas para tal. Se a performance da aplicação falhar. assim o servidor pode experimentar um grande número de atividades de uma forma controlada. JMeter é uma ferramenta simples de utilizar. foram elaboradas duas aplicações usando as melhores técnicas de padrões de projetos para uma aplicação usando EJB e outra usando o framework Spring. A figura 6. e também se define a quantidade de vezes que se deseja que as requisições sejam executadas. Nele são gravadas as requisições da aplicação que se deseja testar.

Escalabilidade é a habilidade de o sistema tratar o aumento de carga sem ter uma grande perda de performance. O fluxo de ambos os sistemas consiste no login de usuários previamente cadastrados. o usuário é levado para a página inicial da aplicação. onde o mesmo tem duas opções: ele pode 80 . Com o teste de carga.2. é possível saber em quais pontos a aplicação pode apresentar falhas que podem comprometer a performance da aplicação.1: Interface do JMeter 6.80 Figura 6. Com isso. Importância dos Testes de Carga O objetivo de testes de carga é determinar tanto a escalabilidade quanto a performance de aplicações web. a escalabilidade está relacionada diretamente com a performance. Para a simulação de uma aplicação real foi desenvolvido tanto um projeto usando EJB quanto um projeto usando Spring. o administrador não consegue perceber se a aplicação é tão escalável quanto ela deveria ser. mas sim ser uma aplicação que realize certas operações comuns em muitas aplicações web. Sem testes de carga. Posteriormente. Tal projeto não tem como objetivo ser uma aplicação amigável para o usuário.

1 e a figura 6. cadastrar. com isso.3 demonstram os resultados obtidos pela aplicação usando Spring. O tempo do gráfico refere-se ao tempo total da execução do processo total do sistema. iniciamos os testes de carga. A figura 6. Com o fluxo presente.2 mostra o fluxo descrito acima. a carga que o sistema pode ter. usamos o JMeter como um proxy para que gravasse o fluxo de operações listadas acima. A ferramenta permite que as operações gravadas sejam repetidas por diversas threads (cada thread equivale a um usuário). 81 . ou pode listar os usuários previamente cadastrados. por sua vez. O usuário. simulando. é a quantidade de usuários simultâneos que acessaram a aplicação. editar e excluir usuários.2: Fluxo da aplicação desenvolvida A tabela 6. que é de logar. listar. Uma vez gravado esse fluxo.81 cadastrar um novo usuário. Figura 6.

2 e a figura 6.4 demonstram os resultados obtidos pela aplicação usando EJB.82 Aplicação usando Spring Repetições Usuários 500 65 ms 353 ms 708 ms 1745 ms 2900 ms 9253 ms 10652 ms 1000 106 ms 1342 ms 1975 ms 4012 ms 7600 ms 9996 ms 13056 ms 2 10 20 50 100 300 500 Tabela 6. 82 .1: Tabela comparativa na aplicação que utiliza Spring Spring – Usuário/Tempo Tempo (ms) 14000 12000 10000 8000 6000 4000 2000 0 0 200 400 Usuários 600 Série1 Série2 Figura 6. a tabela 6.3: Gráfico de resultados obtidos na aplicação que utiliza Spring Por sua vez.

64 GHz com 512 MB de Memória.3 GHz com 512 83 .4: Gráfico de resultados obtidos na aplicação que utiliza EJB Com a realização dos testes. Foi usado um Notebook Apple Power Book 1.2: Tabela comparativa na aplicação que utiliza EJB EJB – Usuário/tempo Tempo (ms) 16000 14000 12000 10000 8000 6000 4000 2000 0 2 10 20 50 100 300 500 Usuários Série1 Série2 Figura 6. e um Notebook Toshiba 2.83 Aplicação usando EJB Repetições Usuários 500 327 ms 767 ms 1071 ms 3500 ms 7038 ms 10447 ms 14523 ms 1000 255 ms 1360 ms 2253 ms 4234 ms 7632 ms 12983 ms 13678 ms 2 10 20 50 100 300 500 Tabela 6. pôde-se notar que não há uma grande diferença entre a performance das duas aplicações. É importante salientar que os testes foram realizados em computadores comuns.

apenas de amostragem para fins didáticos do presente trabalho.84 MB de memória. Ou seja. então. 84 . servindo. não demonstram a plataforma de hardware real de servidores de aplicações.

disponibilizando. entretanto simples. Mostrou a importância de se planejar uma arquitetura para sistemas que tendem a crescer ao longo dos tempos. Porém. e o AOP. que um servidor de aplicação. além de outros fatores mencionados. performance. pois existe um enorme legado e para aplicações que necessitem ser realmente distribuídas o uso de EJBs ainda é recomendado. Diante dos estudos e testes realizados. No presente trabalho. o uso de padrões de projeto em aplicações J2EE normalmente dita o fracasso do projeto caso sejam utilizados de forma incorreta. Porém. com a apresentação de arquiteturas leves. Com tais complexidades. os autores acreditam que as novas aplicações usando frameworks leves são uma alternativa viável para arquiteturas que necessitem ser escaláveis e robustas. proporciona diversas funcionalidades como segurança e gerenciamento declarativo de transações fora de 85 . não se pode descartar por completo aplicações tradicionais J2EE. com isso. foram surgindo alternativas e novos conceitos para o desenvolvimento de sistemas escaláveis. Procurou-se mostrar novas técnicas usadas para a disponibilização de serviços e conceitos presentes na arquitetura robusta J2EE. Finalmente foi apresentado de forma bastante breve um teste de carga para evidenciar a performance e a escalabilidade de ambos os sistemas. torna-se interessante em trabalhos futuros o aprofundamento de um estudo dessas arquiteturas para que cada vez mais ela possa prover serviços ainda presentes na arquitetura somente na arquitetura J2EE. foi evidenciado que a forma tradicional de se desenvolver aplicações distribuídas usando a plataforma J2EE é bastante burocrática e pode impactar no sucesso de sistemas que não possuem profissionais experientes. conceitos como escalabilidade. que ocasiona um fraco acoplamento entre camadas. gerenciabilidade e disponibilidade. adicionando ainda mais complexidade na arquitetura.85 Conclusão O presente trabalho mostrou diversos aspectos de arquiteturas de sistemas distribuídos (ou não) usando a plataforma J2EE. como o IoC. Diante desses fatores.

Manning Publications Co. [CRI2000] CRISPIN.86 Referências Bibliográficas [ALL2003] ALLEN. 240 p. 1. 648 p.codehaus. 1. Kent. [BEN1996] BENNETT. 86 . Acesso em: Dezembro de 2005. 1996. The Need for Speed: Automating Acceptance testing in an Extreme Programming Environment.pdf/Crispin.Guia Oficial de Certificação. [AST1998] ASTUDILLO. CLEMENTS.org/aspectj>. Smalltalk Best Pratice Patterns. HAMMER. [ASP2006] Site oficial do projeto AspectJ. WADE. Prentice Hall PTR. 1996. Joseph. 512 p.ed. Editora Campus. Douglas. Software Architecture in Practice. BAMBARA. Addison Wesley. Hernán.. KAZMAN. Carol. Understanding the Architect's Job. Acesso em: Dezembro de 2005. Lisa. Disponível em: <http://www. Paul.com/QualWeek/QWE2K/Papers.pdf>. [BAS1998] BASS. [BEC1996] BECK. 350 p. 1998. Len. Rick.eclipse.Plain Java AOP. 1998. 2003. Paul. Sun Certified Enterprise Architect for J2EE .org>. Disponível em: <http://aspectwerkz. Acesso em: Janeiro de 2006. Software Architecture Workshop of OOPSLA'98.soft. Disponível em: <http://www. [ASP2005] AspectWerkz . Stuart.ed. Designing Hard Software: The Essential Tasks.

[JDB2006] Site oficial da API JDBC.com/portal/jbossaop>. Site oficial do framework Hibernate.ibatis. RAN.87 [DAN2006] ROCHA.hibernate. 2000. Laboratório de Engenharia de Software. Pro Spring. MASIERO. Addison Wesley. Mehdi.martinfowler. [JAZ2000] JAZAYERI.html>. Disponível em: <http://www. Disponível em: <http://www. Acesso em: Janeiro de 2006. Adenilso da Silva.org>. Uma ferramenta baseada em aspectos para o teste funcional de programas Java. José Carlos. Rob. 257 p. Acesso em: Janeiro de 2006. Acesso em: Janeiro de 2006 [IBA2006] Site oficial do framework IBatis. Jan. 832 p. [HAR2005] [HIB2006] HARROP. Disponível em: <http://www. [JME2006] Site oficial da ferramenta JMeter. Alexander. MALDONADO.org/jmeter/>. Disponível em: <http://labs. Acesso em: Dezembro de 2005. Acesso em: Fevereiro de 2006. Paulo César. 87 . Martin.com/articles/injection. Acesso em: Março de 2006. MACHACEK. LINDEN.sun.com/products/jdbc/>. [FOW2004] FOWLER. Disponível em: <http://java.org>. 2005.jboss. André Dantas. Apress. Inversion of Control Containers and the Dependency Injection pattern. Software Architecture for Product Families. Disponível em: <http://jakarta. [JBO2005] Site oficial do framework JBoss AOP. SIMÃO. Frank van der. Instituto de Ciências Matemáticas e de computação da Universidade de São Paulo.apache.

[MAC2005] MACORATTI. [LOZ2003] LOZANO.net/vb_pd1.junit.pdf>. 576 p. Acesso em: Fevereiro de 2006.br>. Acesso em: Janeiro de 2006.parasoft. Acesso em: Dezembro de 2005. Fernando. Robert C.devmedia.eti. Padrões de Projeto . [JUN2006] Site oficial do framework JUnit. Expert One-on-One J2EE Development without EJB. Disponível em: <http://www. Disponível em: <http://www.htm>.aspx?comp=957& site=3>. Wiley Publishers.com/design/article. The Dependency Inversion Principle. Disponível em: <http://www. [MAI2005] MAIORIELLO.objectmentor. Patterns e anti-patterns para o desenvolvimento em PHP. James.org>. Alessandro Ferreira. Acesso em: Dezembro de 2005. Disponível em: <http://www.macoratti. Juergen. Acesso em: Dezembro de 2005. Rod. Disponível em: <http://www. [JTE2006] Site oficial da ferramenta JTest.br/visualizacomponente.php/1474561>. 88 . Acesso em: Dezembro de 2005. José Carlos. HOELLER. What are Design Patterns and do I need them? Disponível em: <http://www. [LEI2005] LEITE. Padrões de Projeto.com.com/jtest>.com/resources/articles/dip. 2004. [MAR1996] MARTIN.lozano. Disponível em: <http://www.88 [JOH2004] JOHNSON.Design Patterns. Acesso em: Fevereiro de 2006.developer.

sourceforge. Ed. 2004. Acesso em: Janeiro de 2006. Aslak.ed.net/projects/perola/>. 2004. [SHA1996] SHAW. Mani. Wiley Publishers. GARLAN.ibm. Tech Talk Vídeo. 242 p. A beginners guide to Dependency Injection. Mary.ed.net>.com/talks/videos/AslakHellesoy/interview. 3. [SER2005] NENE. Disponível em: <http://www. Kathy. 5.ed. [ROM2004] ROMAN. Software Architecture Perspectives on an Emerging Discipline. 1. Disponível em: <http://www. David. 1996. FREEMAN.com/software/mqseries/. 839 p. Roger. 89 .ed. [OPE2006] Site oficial do OpenJMS. Eric. Acesso em: Janeiro de 2006. [MQS2006] Site oficial do MQSeries.ts s?bandwidth=real>. SRIGANESH. Acesso em: Fevereiro de 2006. Mastering Enterprise JavaBeans.theserverside. FREEMAN. Disponível em: <http://www.com/Java/Article/27583>. Gerald. Software Engineering: A Practitioner's Approach. Elisabeth. BROSE. [PER2006] Site oficial do framework Perola. Disponível em: <http://sourceforge.89 [MAL2005] MALARVANNAN. Bert.theserverside. 2001. McGraw Hill. Dhananjay. O'Reilly Media. Rima Patel.devx.tss?l=IOCBeginners>.com/articles/article. Acesso em: Janeiro de 2006. 1. Prentice Hall. Head First Design Patterns. Design Better Software with the Inversion of Control Pattern. Acesso em: Janeiro de 2006. Inc. Acesso em: Janeiro de 2006. [SER2006] HELLESOY. Disponível em: http://www. BATES. [SIE2004] SIERRA. [PRE2001] PRESSMAN. 676 p. Disponível em: <http://openjms.

Acesso em: Fevereiro de 2006. [XDE2006] Site oficial da ferramenta XDE Tester. Don. Spring in Action.com/software/awdtools/tester/functional/>. Extreme Programming: A gentle introduction. Manning Publications Co. Kim. JENDROCK. Disponível em: <http://www. CARSON. The Java EE 5 Tutorial.90 [SON2006] SonicMQ: OpenEdge Integration Portfolio.com>. Jennifer.ibm.asp>. Disponível em: <http://www. Disponível em: <http://www. Debbie Bode. [SUN2006] BALL.org/>. Disponível em: <http://www. BREIDENBACH.wikipedia.automatedqa. 472 p.com/javaee/5/docs/tutorial/doc/>. Disponível em: <http://www306. [WEL2005] WELLS. [WAL2005] WALLS.org>. HAASE. Acesso em: Fevereiro de 2006.sun.org>. Ian.progress. Craig. Acesso em: Fevereiro de 2006. 90 . Disponível em: <http://java. the free encyclopedia. Ryan. Disponível em: <http://en. Acesso em: Janeiro de 2006. 2005. Eric. Acesso em: Fevereiro de 2006. Acesso em: Março de 2006. EVANS. [WIK2006] Wikipedia. [SPR2006] Site oficial do framework Spring.springframework. [TES2006] Site oficial da ferramenta TestComplete. Acesso em: Novembro de 2005.extremeprogramming.com/products/testcomplete/index.

Sign up to vote on this title
UsefulNot useful