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

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

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

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

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

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

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

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

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 .

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

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

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

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

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

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

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

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

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

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

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

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

Apesar de a escalabilidade vertical ser mais barata e simples de se implementar. Esse tipo é bem mais custoso e complexo. ! Horizontalmente: consiste na adição de um ou mais servidores e. 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. 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. Já com a adição de mais servidores.24 tempo de resposta. com isso. provendo o aumento da performance do sistema. pode-se prover um ambiente bem mais tolerante a falhas e eficiente. pois somente adicionando capacidade de processamento não provê a tolerância a falha. prover uma forma de cluster para a aplicação. 24 . ela não é aconselhada para aplicações de missão critica.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mas sim ser uma aplicação que realize certas operações comuns em muitas aplicações web. o usuário é levado para a página inicial da aplicação. onde o mesmo tem duas opções: ele pode 80 . Tal projeto não tem como objetivo ser uma aplicação amigável para o usuário. Com o teste de carga. a escalabilidade está relacionada diretamente com a performance. é possível saber em quais pontos a aplicação pode apresentar falhas que podem comprometer a performance da aplicação. Com isso. Importância dos Testes de Carga O objetivo de testes de carga é determinar tanto a escalabilidade quanto a performance de aplicações web.2. Posteriormente.80 Figura 6. o administrador não consegue perceber se a aplicação é tão escalável quanto ela deveria ser. Sem testes de carga. 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.1: Interface do JMeter 6. Para a simulação de uma aplicação real foi desenvolvido tanto um projeto usando EJB quanto um projeto usando Spring.

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

3: Gráfico de resultados obtidos na aplicação que utiliza Spring Por sua vez. a tabela 6.2 e a figura 6.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.4 demonstram os resultados obtidos pela aplicação usando EJB. 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 GHz com 512 83 .2: Tabela comparativa na aplicação que utiliza EJB EJB – Usuário/tempo Tempo (ms) 16000 14000 12000 10000 8000 6000 4000 2000 0 2 10 20 50 100 300 500 Usuários Série1 Série2 Figura 6. e um Notebook Toshiba 2.83 Aplicação usando EJB Repetições Usuários 500 327 ms 767 ms 1071 ms 3500 ms 7038 ms 10447 ms 14523 ms 1000 255 ms 1360 ms 2253 ms 4234 ms 7632 ms 12983 ms 13678 ms 2 10 20 50 100 300 500 Tabela 6. Foi usado um Notebook Apple Power Book 1.64 GHz com 512 MB de Memória. É importante salientar que os testes foram realizados em computadores comuns.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.

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful