P. 1
Tecnicas_de_planejamento_em_arquiteturas_-_solucoes_utilizando_J2EE_AOP_e_IoC[1]

Tecnicas_de_planejamento_em_arquiteturas_-_solucoes_utilizando_J2EE_AOP_e_IoC[1]

|Views: 262|Likes:
Published by moisesmoura1

More info:

Published by: moisesmoura1 on Nov 30, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/08/2011

pdf

text

original

Sections

  • 1.1. Arquitetura X Designer
  • 1.2. Arquitetura no Processo de Desenvolvimento de Sistemas
  • 1.3.1. Capacidades de uma arquitetura
  • 2.1. Padrões GoF
  • 2.2.1. Patterns da camada de apresentação
  • 2.2.2. Patterns de camada de negócios
  • 2.2.3. Patterns de camada de Integração
  • 2.3. Benefícios e Problemas do uso de Padrões de Projeto
  • 3.1. Container WEB em J2EE
  • 3.2. EJB e o modelo de container
  • 3.3. Performance com EJB
  • 3.4.1. Session Beans
  • 3.4.2. Entity Bean
  • 3.4.3. Message Driven Bean
  • 4.1.1. Aplicações Distribuídas e Escalabilidade
  • 4.1.2. Aplicações Distribuídas e Confiabilidade
  • 4.1.3.1. Gerenciamento de transações
  • 4.1.3.2. Aspectos negativos de EJB
  • 4.2. Acesso a dados em aplicações J2EE
  • 5.1. Diminuição de Acoplamento
  • 5.2.1.1. Setter Injection
  • 5.2.1.2. Constructor Injection
  • 5.2.1.3. Interface Injection
  • 5.2.2. Constructor Injection x Setter Injection
  • 5.3.1. Técnica Funcional
  • 5.3.2. Técnica Estrutural
  • 5.3.3.1. Testes Unitários no XP
  • 5.3.3.2 Testes de Aceitação
  • 5.3.4. Testes com EJB
  • 5.4.1. Utilizando Hibernate com Spring
  • 5.4.2. Utilizando IBatis com Spring
  • 5.5.1. Programação Orientada a Aspectos com Spring
  • 5.6. Gerenciamento robusto e elegante de Transações
  • 5.7. Uso de mensagens Assíncronas
  • 6.1. Testes de Carga
  • 6.2. Importância dos Testes de Carga

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

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

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

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

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

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

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

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

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 .

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

13 ABSTRACT In the current scene in the development of distributed systems. however. Amongst these techniques. in opposition to the current application servers. 13 . 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. and the use of Inversion of Control. Distributed Systems. EJB. Keywords: Software Architecture. Design Patterns. a series of rules appears becoming the development most bureaucratic. one perceives an arduous and bureaucratic necessity of codification and maintenance of code. With this. using of new concepts. Spring. J2EE. as light container. Current available architecture JÈE supplies to the developer architect a great variety of alternatives. Scalability. that promotes a great reduction of coupling between the system layers. such as Light Containers. 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. Inversion of Control. Inversion of Control and Aspects Orientation. This work aims at to clarify the negative points of J2EE architecture and to consider a simpler architecture.

entre outros. diversas empresas viram nesta grande rede uma forma de expor seus serviços para uma quantidade infinita de consumidores. Porém. 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). normalmente sistemas e hardware antigos de empresas que guardam uma grande quantidade de informação. diversos fatores devem ser levantados acerca de arquiteturas expostas para a Internet. as aplicações de legado3 com informações cruciais e que ainda estavam em produção. Além da popularização de bancos de dados relacionais e o surgimento de aplicações gráficas no cliente. 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. tampouco seria viável uma reescrita dessas aplicações. Antes da explosão da Internet. uma vez que uma quantidade enorme de acessos ao sistema não pode diminuir sua qualidade de resposta. visto que as mesmas funcionam perfeitamente. Nesse contexto. iniciou-se a demanda para aplicações mais ricas e mais agradáveis para o cliente. fica claro que não se podia abandonar os “Livros de Registros”. dedicado normalmente ao processamento de um volume grande de informações. a maioria das aplicações em produção eram centralizadas. Termo utilizado para evidenciar arquiteturas que não possuem grande processamento em seus clientes. para uma vasta gama de usuários acessando através de diversas formas interativas como Internet. 3 Termo com significado de herança. telefone celular. 14 . 1 2 Computador de grande porte. o processo de desenvolvimento de software está em constante evolução e mudança. Levando-se em consideração que essas interfaces eram extremamente pobres.14 Introdução Ao longo dos anos. Com a explosão da Internet. por volta dos anos 90. Mesmo com o “boom” causado pela Internet. 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. tornando-se uma ótima opção para arquitetos de software elaborar aplicações robustas e de qualidade. na maior parte das vezes rodavam em um mainframe1 com várias estações magras2 que apenas acessavam os dados.

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

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

• Criação ou seleção de uma arquitetura. o tempo de desenvolvimento. convertendo os objetos de domínio em um modelo de objeto técnico. • Representação da arquitetura e divulgação: os participantes envolvidos precisam entender a arquitetura.17 relacionamentos. enquanto que o projetista se preocupa com os casos de uso de negócios. 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 .1. considerando: o Identificação dos componentes e suas interações. é 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. a escolha ou elaboração de frameworks5 para o desenvolvimento de componentes. o Escolha de tecnologias que suportem a implementação. 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. Arquitetura X Designer Muitas pessoas levam a comparar o arquiteto com o designer (projetista) de software. O processo de arquitetura de software compreende muitas atividades. • Entendimento dos requisitos: o arquiteto deve contribuir com as técnicas de levantamento de requisitos a fim de obter o modelo do domínio. Portanto. Deve-se levar em consideração que o papel do arquiteto é a elaboração da estrutura do sistema. operando em um nível de abstração bem mais baixo visando à implementação de funcionalidades. seus design patterns4 arquiteturais. 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 Identificação das dependências de construção. o arquiteto se preocupa com a não funcionalidade do sistema em um nível de abstração muito elevado. Estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido. 1.

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

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. a transição entre as fases de engenharia de requisitos. conforme mostra a figura 1. Mesmo com a execução rigorosa das fases de engenharia de requisitos e de análise. análise e projeto é tranqüila. Figura 1. 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. é necessário que a fase anterior seja totalmente concluída. Para sistemas pequenos.19 1. 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. 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.2. satisfazendo a construção do 19 . Para que uma fase seja iniciada.2 mostra o ponto onde as atividades da arquitetura são mais visíveis dentro do processo de desenvolvimento de sistemas.1: Processo de desenvolvimento em cascata A figura 1.1. pois os modelos gerados nestas fases são suficientes para representar os requisitos necessários.

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.20 sistema. 20 .2: pontos onde as atividades de arquitetura são mais visíveis Segundo [JAZ2000]. Porém. 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. apenas uma fração dos requisitos específicos do sistema tem influência na arquitetura. 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. 1. Princípios de arquiteturas Para arquitetos de sistema.3 mostra uma representação das camadas arquitetônicas de um sistema. O desacoplamento ocorre dividindo o sistema em camadas. uma vez que esta resposta é muito dependente do domínio. Figura 1. Audiências diferentes exigem perspectivas diferentes 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.3. A figura 1.

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. A lógica de negócios reside em uma camada independente. Para que realmente se tenha êxito em separar os sistemas em camadas.3 mostra um típico sistema multicamadas. Essa arquitetura deve ser definida cuidadosamente devido a sua grande complexidade. 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. deve-se prever que as classes e objetos de uma camada devem depender estritamente de sua própria camada. que a camada cliente implementa somente a lógica de apresentação (cliente magro).21 Figura 1. tipicamente em um servidor de aplicação. com isso um sistema do tipo “espaguete”. A terceira camada reside entre a camada cliente e a camada de dados.3: Camadas arquitetônicas de um sistema. 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. localização transparente. Essa camada fornece o gerenciamento de processos em que a lógica de negócios é executada. pool de conexões de banco de dados e mais. os quais fazem com que pequenas alterações em uma camada se propaguem para praticamente todo o “cetim”. Adaptado de [JAZ2000] A figura 1. evitando. Em um ambiente multicamada percebe-se algumas características. A camada de acesso a dados fica também 21 . segundo [ALL2003].

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

da aplicação. A disponibilidade é o grau em que um sistema é operável em um estado saudável. Flexibilidade é a chave para uma aplicação disponível. Matematicamente a disponibilidade é um (1) menos a indisponibilidade. Tipicamente.23 funcionais da mesma. A seguir são apresentados alguns conceitos importantes sobre capacidades arquiteturais. 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 . gerenciabilidade. desempenho. controle de concorrência e gerenciamento do servidor. Disponibilidade Essa característica está sempre relacionada ao desempenho. Ela inclui segurança. Gerenciabilidade e Flexibilidade Gerenciabilidade se refere ao conjunto de serviços que assegura a integridade continuada. incluindo escalabilidade. Um exemplo métrico de gerenciabilidade seria a quantidade de horas de pessoal no mês gastas para atualizações no servidor. As medidas de qualidade de um sistema normalmente focalizam características de desempenho sob estudo. É a capacidade de realizar mudanças arquiteturais para conceber novos requisitos em uma maneira eficiente e não custosa. disponibilidade. ou correção. 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. confiável e escalonável. Um exemplo de disponibilidade é 100/168. O tempo de resposta e a taxa de resposta são importantes para uma aplicação. confiabilidade e segurança. 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. Desempenho Atualmente. A separação do sistema em camadas aumenta muito a flexibilidade de um sistema. o desempenho é a capacidade de executar funções suficientemente rápidas para atenderem aos objetivos.

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

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

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

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

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

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

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

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

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

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

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

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

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

41 Foi mostrado na seção anterior que os EJBs de sessão são modelados para realizar regras de negócio. Este processo de coordenação dos dados do banco de dados com a instância do bean é chamado de persistência. ele pode ser representado por várias. É muito mais fácil. Do outro lado. os beans de entidade são muito diferentes. 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.0 da especificação EJB. 3. devido na fase de design nem toda tabela de seu esquema de persistência necessita estar mapeada para um bean de entidade.4. Estes beans promovem um simples mecanismo de acesso e alteração de dados. 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). serviços para o cliente. algoritmos. executar um método para atualizar um campo de um entity do que fazer um comando SQL11 para isto. Quando um novo bean é criado. 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 . Já com relação ao mapeamento com as tabelas. estas mudanças devem estar sincronizadas com a base de dados. que é papel do session bean.3. Message Driven Bean Antes da versão 2. por exemplo. 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. É nesse contexto que entra a tecnologia dos entities beans. Conforme o bean é usado e seu estado é alterado. um bean de entidade não necessita estar mapeado para uma única tabela. 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). um novo registro deve ser inserido na base de dados e uma instância do bean associada a este dado. cada aplicação necessita ter seus objetos de modelo persistidos. Com relação aos beans de sessão. pois ao invés de se modelar um fluxo de controle (workflow).

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

o container é capaz de manipular as mensagens que chegam de uma forma muito mais eficiente e aumenta a escalabilidade das operações JMS. Por usar um pool de instância de beans.43 Como se pôde verificar. 43 . 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. As instâncias dos beans podem ser colocadas ou retiradas do pool dependendo das necessidades do container de atender as requisições.

Um container web J2EE provê uma camada intermediária para aplicações que possuem o browser como cliente. Entretanto isso pode ser questionado. cada um acessando um recurso como fonte de dados ou aplicações legadas inacessível em outro lugar na rede. Com isso. Como uma aplicação envolvendo vários containeres de EJB.1. De acordo com [JOH2004]. Aplicações Distribuídas e Escalabilidade O J2EE e desenvolvedores tendem a assumir que aplicações distribuídas oferecem uma escalabilidade inigualável. Esta é uma escolha potencialmente custosa.1. esse argumento não se aplica para aplicações com apenas interface web. • • Para se ganhar controle sobre onde cada componente distribuído está instalado. 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. Se a primeira ou segunda afirmação for válida. pois não se deve escolher uma arquitetura distribuída sem ter realmente bons motivos para tal. uma arquitetura distribuída baseada em EJB com interfaces remotas é a solução mais simples e ideal. 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.44 Capítulo 4 Aplicando a tecnologia J2EE e seus problemas 4. 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. • Quando aplicações necessitam integrar recursos distribuídos em uma empresa. aumentando com isso a escalabilidade e a confiabilidade. 44 . Em casos raros. 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. 4.1.

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

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

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

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

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

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

Um exemplo típico é o uso de JNDI. é necessário realizar a mesma consulta por JNDI. mesmo com a utilização do modelo de componentes EJBs. 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. Para um cliente acessar um EJB. que se responsabilizam pela camada de negócios e também a camada de dados possuem grande acoplamento a certas tecnologias. Além do uso de frameworks para a diminuição do trabalho. deixando o código ainda mais acoplado à 51 . Mensagens orientadas a objetos Java normais.1. é obrigado a utilizar o JNDI para realizar a busca pelo recurso. Inversão de controle. filas de mensagens. 5. fácil testabilidade.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. 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. ele deverá também fazer uma conversão para que recursos disponíveis do protocolo IIOP. uma API para a busca de recursos e localização de EJBs remotos ou não. tratando as devidas exceções provenientes da API. entre outros. para obter acesso a outros componentes. Tal arquitetura não adotará o modelo de componentes padrão do J2EE (EJBs). Dentre os conceitos. Tendo isto em mente. a arquitetura se baseia em alguns projetos de código aberto desenvolvidos pela própria comunidade Java. Diminuição de Acoplamento Um aspecto presente em diversas arquiteturas J2EE é o forte acoplamento entre as camadas. com isso. vem se tornando uma constante no campo de desenvolvimento de software no cenário brasileiro e mundial. como origens de dados. orientação a Aspectos. ou configurações específicas. a fim de alocarem profissionais ou comprar ferramentas. se o EJB for remoto. pode-se citar: gerenciamento declarativo de transações. Cada componente EJB.

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

ele surgiu com o princípio da inversão de dependência (Dependency Inversion Principle – DIP).2. De acordo com [WIK2006].2. 5. possui apenas o método “findAll”: 53 .1. Este princípio prega que “os módulos de alto nível não devem depender dos níveis mais baixos. que possui uma referência da interface “MovieFinder”. 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. Constructor Injection e Interface Injection. que é uma estrutura resultante do uso de dois princípios: Open-Closed Principle (OCP) e Liskov Substitution Principle (LSP). A interface. Estes devem depender das abstrações” [MAR1996]. 5.1. ficando o máximo possível independente uma classe da outra. 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. e implementa o método setter desta referência.1. o padrão de Inversão de Controle pode ser implementado através de três formas: Setter Injection. 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. Ambos devem depender de abstrações”. Segundo [MAL2005]. Ou seja. Inversão de Controle O conceito de inversão de controle não é atual. esta forma é muito útil quando se tem um objeto que necessita modificar suas propriedades várias vezes durante o seu ciclo de vida. temos um exemplo bem simples desta forma de Inversão de Controle. Este exemplo é mostrado a seguir: A classe “MovieLister” é um JavaBean simples. e também prega que “As abstrações não devem depender de detalhes. Em [FOW2004]. 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. por sua vez.53 5. utilizando a plataforma Java e o framework Spring. Formas de implementação de Inversão de Controle De acordo com [FOW2004].2. Este controle é delegado a um container”.

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

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

} Listagem 5.txt")}. pico.2. private MutablePicoContainer configureContainer() { MutablePicoContainer pico = new DefaultPicoContainer().class. 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. que recebe o arquivo texto como um parâmetro constante e registra as classes onde serão injetados os objetos. pico. ColonMovieFinder. [FOW2004] mostra um exemplo de utilização da Interface Injection.56 O arquivo de configuração. é um método Java. É nesta interface que os objetos irão ser injetados. Parameter[] finderParams = {new ConstantParameter("movies1. } Listagem 5.3. finderParams). Interface Injection Nesta forma de Inversão de Controle é criada uma Interface para o framework IoC (Inversion of Control).1.9: Interface que irá injetar objetos através do Interface Injection 56 .registerComponentImplementation(MovieFinder.registerComponentImplementation(MovieLister.8: Arquivo Java de configuração de injeção 5.class). nesse exemplo. 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). return pico. utilizando o framework Avalon: Primeiramente é criada uma interface que irá injetar os objetos. De acordo com [MAL2005].class. Da mesma maneira que as duas formas anteriores.

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

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

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

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

nestes testes são consideradas apenas as entradas e as saídas. erros de estrutura de dados ou de acesso a dados externos.3. Além disso. Técnica Funcional Como falado anteriormente.1. 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.61 caixa-branca. erros de interface. devido o trabalho de desenvolvimento de um software se basear em trabalhos anteriores. é extremamente importante testar uma aplicação frequentemente e desde o início do processo da mesma. é 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. além do custo dos erros crescer exponencialmente com o atraso na descoberta dos mesmos. erros de comportamento e erros de iniciação e término. É importante ressaltar que o objetivo dos testes é encontrar erros. também conhecida como caixa-preta. fazendo com que o testador sequer tenha acesso ao código-fonte. Além disso. pois os desenvolvedores tendem a cometer erros mais quando estão recolhendo requisitos do que durante o processo de desenvolvimento propriamente dito. Isto é. nos testes funcionais as aplicações são testadas com o objetivo de se encontrar cinco “tipos” de erros: funções incorretas ou omitidas. provavelmente o teste está errado. Além disso. Se um teste não encontra nenhum problema onde está testando. 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. as poucas ferramentas que implementam a técnica funcional (essa técnica.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. 5.

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

Na simplicidade. tem conhecimento do funcionamento interno das classes que irão ser testadas.2.3. Os testes se encaixam em três dos quatro princípios. os testes. No feedback.3.63 5. 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). são simplificados. mostra como funciona os testes estruturais (caixa branca) do tipo unitários: Figura 5. Ou seja. assim como os modelos e os códigos. não importando apenas as entradas e saídas.3. Esta metodologia é baseada em quatro princípios: Simplicidade. Feedback. tanto para ter o feedback para os desenvolvedores. ao contrário da técnica funcional. Coragem e Comunicação.2. como para o desenvolvedor poder gerar releases (versões) do sistema em um curto espaço de tempo sem os chamados 63 .3: Funcionamento de testes unitários 5. a técnica estrutural (ou caixa-branca). criador da metodologia XP). A figura 5. e sim todas as partes do código do sistema. é um desenvolvimento rápido e consistente com as reais necessidades do cliente e fácil manutenibilidade. 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. Técnica Estrutural Conforme dito anteriormente. há a necessidade de testes unitários.

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

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

os quais conectam com o servidor EJB e são executados em uma JVM (Java Virtual Machine) diferente da JVM utilizada pelo container EJB. Podese invocar os casos de teste normalmente.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. Dentre estas três alternativas. Este tipo de teste geralmente funciona apenas quando os EJBs possuem requisitos simples do container EJB. com a diferença de tomar cuidado em prover as propriedades JNDI apropriadas que permitem a conexão do container EJB”.66 Com isso. há três maneiras de se testar um EJB [JOH2004]: • • Desenvolver um teste que serve como um cliente remoto de um container EJB. a mais simples (ou menos complexa) é a primeira. como qualquer outro teste. escreve-se os casos de teste. Desenvolver e deploy um teste que será executado em um servidor de aplicação. [JOH2004] descreve como deve ser feito o teste nesta alternativa: “Primeiramente. A tabela 5. tornando um local Desvantagens • Não é possível testar interfaces locais 66 . • Testar com objetos stubs modificando objetos do container. Esta é uma boa estratégia para testar EJB em uma interface local.

além de o EJB ser bastante complexo e burocrático por si só. • Requer um framework de teste adicional ao JUnit • Os possuem complexa.2. Dois dos principais frameworks de acesso a dados existentes são o Hibernate [HIB2006] e o IBatis [IBA2006]. Camada de acesso a dados simplificada O acesso a dados de qualquer aplicação Web pode se tornar complexo. a segurança e o gerenciamento de serviços são difíceis de simular. 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. 5. Esta dificuldade de testar um EJB é um dos principais motivos que o tornam uma má alternativa de desenvolvimento. sendo que alguns acabam por diminuir a performance da aplicação.67 apropriado para testes • Em aplicações web. ambos serão discutidos em detalhes nas próximas 67 . dependendo de como for implementada. principalmente devido ao uso indevido por parte dos desenvolvedores. esta é uma possibilidade impraticável. devido à arquitetura EJB ser altamente complexa. Para facilitar este acesso.: 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. Alem disso. 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. Entretanto.4. • Devido não necessitar de um container. vários frameworks foram surgindo.

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

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

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

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

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

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

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

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

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

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

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

executando uma das aplicações que foi desenvolvida neste trabalho (a aplicação utilizando Spring. que é um projeto open-source de testes de carga da Apache© [JME2006]. como o JMeter. A figura 6. passos devem ser tomados a fim de descobrir tais problemas.1.1 mostra a interface do JMeter. Ela demonstra o momento em que a aplicação obteve uma estabilização no tempo de resposta. assim o servidor pode experimentar um grande número de atividades de uma forma controlada. 6. Se a performance da aplicação falhar. Nele são gravadas as requisições da aplicação que se deseja testar. 79 . e também se define a quantidade de vezes que se deseja que as requisições sejam executadas.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). 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. JMeter é uma ferramenta simples de utilizar. Testes de Carga Teste de carga no servidor é comumente usado para mensurar a performance de aplicações web. melhor explicada na próxima seção). Testes de carga é o processo de simular requisições clientes. momento este que foram coletados os dados para os gráficos mostrados na próxima seção. Normalmente quem executa testes de carga são ferramentas específicas para tal. com uma interface amigável para o usuário.

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

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

4 demonstram os resultados obtidos pela aplicação usando EJB.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. 82 .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.3: Gráfico de resultados obtidos na aplicação que utiliza Spring Por sua vez.2 e a figura 6.

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.64 GHz com 512 MB de Memória.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.4: Gráfico de resultados obtidos na aplicação que utiliza EJB Com a realização dos testes. pôde-se notar que não há uma grande diferença entre a performance das duas aplicações. Foi usado um Notebook Apple Power Book 1. É importante salientar que os testes foram realizados em computadores comuns.3 GHz com 512 83 .

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

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. Mostrou a importância de se planejar uma arquitetura para sistemas que tendem a crescer ao longo dos tempos. Diante desses fatores. No presente trabalho. adicionando ainda mais complexidade na arquitetura. que um servidor de aplicação. performance. pois existe um enorme legado e para aplicações que necessitem ser realmente distribuídas o uso de EJBs ainda é recomendado. proporciona diversas funcionalidades como segurança e gerenciamento declarativo de transações fora de 85 . Procurou-se mostrar novas técnicas usadas para a disponibilização de serviços e conceitos presentes na arquitetura robusta J2EE. disponibilizando. Porém. Diante dos estudos e testes realizados. além de outros fatores mencionados. Finalmente foi apresentado de forma bastante breve um teste de carga para evidenciar a performance e a escalabilidade de ambos os sistemas. entretanto simples. não se pode descartar por completo aplicações tradicionais J2EE. que ocasiona um fraco acoplamento entre camadas. 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. foram surgindo alternativas e novos conceitos para o desenvolvimento de sistemas escaláveis. como o IoC. com a apresentação de arquiteturas leves. e o AOP. 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. gerenciabilidade e disponibilidade. com isso. o uso de padrões de projeto em aplicações J2EE normalmente dita o fracasso do projeto caso sejam utilizados de forma incorreta. Com tais complexidades.85 Conclusão O presente trabalho mostrou diversos aspectos de arquiteturas de sistemas distribuídos (ou não) usando a plataforma J2EE. Porém.

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

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

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

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

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

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->