Documento - Groupware@LES - PUC-Rio
Transcrição
Documento - Groupware@LES - PUC-Rio
Celso Gomes Barreto Agregando Frameworks de Infra-Estrutura em uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet Dissertação de Mestrado Dissertação apresentada ao Programa de PósGraduação em Informática da PUC-Rio como requisito parcial para obtenção do título de Mestre em Informática. Orientador: Hugo Fuks Rio de Janeiro, março de 2006 Celso Gomes Barreto Junior Agregando Frameworks de Infra-Estrutura em uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet Dissertação apresentada como requisito parcial para a obtenção do grau de Mestre pelo Programa de Pósgraduação em Informática do Departamento de Informática do Centro Técnico e Científico da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada. Prof. Hugo Fuks Orientador Departamento de Informática – PUC-Rio Prof. Carlos José Pereira de Lucena Departamento de Informática – PUC-Rio Prof. Alberto Raposo Departamento de Informática – PUC-Rio Profa. Flávia Maria Santoro UNI-Rio Prof. José Eugenio Leal Coordenador Setorial do Centro Técnico Científico – PUC-Rio Rio de janeiro, 14 de Março de 2006 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador. Celso Gomes Barreto Graduou-se em Ciência da Computação na Universidade Federal do Rio de Janeiro em 2002. Durante a graduação atuou no projeto Enibam (Ensino Informatizado em Tópicos Básicos de Matemática). Durante o mestrado atuou no projeto AulaNet responsabilizando-se pela arquitetura e infra-estrutura técnica. Ficha Catalográfica Barreto, Celso Gomes Agregando frameworks de infra-estrutura em uma arquitetura baseada em componentes : um estudo de caso no ambiente AulaNet / Celso Gomes Barreto ; orientador: Hugo Fuks. – Rio de Janeiro : PUC, Departamento de Informática, 2006. 210 f. : il. ; 30 cm Dissertação (mestrado) – Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática Inclui referências bibliográficas. 1. Informática – Teses. 2. Desenvolvimento de groupware. 3. Componentes de software. 4. Arquiteturas multicamadas de software. 5. Frameworks. I. Fuks, Hugo. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. III. Título. Agradecimentos Ao professor Hugo Fuks por acreditar no meu potencial e pela inestimável orientação ao longo destes dois anos. Aos companheiros de consórcio, Marco Aurélio Gerosa e Mariano Gomes Pimentel, que me acompanharam nesta difícil jornada. Aos meus pais, Celso Gomes Barreto e Isaura Maria Moreira Barreto pelo apoio, incentivo e afeto. Aos meus colegas do LES e do projeto AulaNet pelo companheirismo. Em especial à Denise Del Re Filippo por me auxiliar na preparação para a defesa. A todos com quem já trabalhei. Em especial a Juliana Lucas de Rezende, pelo incentivo e aconselhamento. Aos professores da Universidade Federal do Rio de Janeiro por minha formação na graduação, sem a qual não teria chegado até aqui. A CAPES e à Fundação Padre Leonel Franca pelo apoio financeiro. E a todos aqueles que direta ou indiretamente contribuíram para a realização deste trabalho. Resumo Barreto, Celso Gomes; Fuks, Hugo. Agregando Frameworks de InfraEstrutura em uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet. Rio de Janeiro, 2006. 210p. Dissertação de Mestrado – Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro. Groupware é difícil de construir e de manter, pois envolve aspectos multidisciplinares. Além das dificuldades associadas ao desenvolvimento de aplicações colaborativas, usualmente o desenvolvedor de groupware deve se preocupar com outros aspectos de infra-estrutura. Nesta dissertação é proposta uma arquitetura multicamadas baseada em componentes para groupware, utilizando frameworks de infra-estrutura. Na camada de negócio são utilizados os frameworks Hibernate, responsável pela persistência dos dados da aplicação, e o framework Spring, que dentre outras coisas é responsável pelo controle de transações e pela exposição de serviços remotamente. Na camada de apresentação o framework JaveServer Faces provê meios para criar e reusar componentes de interface. Nesta dissertação também é apresentada uma forma de comparar frameworks de infra-estrutura, levando em consideração tanto aspectos técnicos, que definem se o framework atende aos requisitos da aplicação, quanto nãotécnicos, relacionados a aspectos como documentação disponível e aceitação no mercado. A arquitetura definida nesta dissertação é aplicada no AulaNet, groupware voltado para a aprendizagem desenvolvido no Laboratório de Engenharia de Software da PUC-Rio. Palavras-chave Desenvolvimento de groupware; componentes de software; arquiteturas multicamadas de software; frameworks. Abstract Barreto, Celso Gomes; Fuks, Hugo (Advisor). Adding System Intrastructure Frameworks in an Component Based Architecture: A Case Study within the AulaNet Environment Rio de Janeiro, 2006. 210p. M.Sc. Dissertation – Computer Science Department, Pontifical Catholic University of Rio de Janeiro. Groupware is difficult to develop and maintain because it involves multidisciplinary aspects in its construction. Besides the difficulties related to the development of collaborative applications, usually the developer must handle with other infrastructure aspects. In this dissertation, it is proposed a multilayer component based architecture with system infrastructure frameworks to deal with them. In the business layer, the Hibernate framework is responsible for the persistence of application data, and the Spring framework is responsible for, amongst others, transactions control and remote exposition of services. In the presentation layer the JaveServer Faces framework provides ways to create and to reuse user-interface components. This dissertation also presents a way to compare system infrastructure frameworks, considering both technical aspects, related to the application requirements fulfillment, and non-technical, related to aspects such as documentation availability and market acceptance. The architecture defined in this dissertation is applied to the AulaNet, which is a groupware for learning developed in the Software Engineering Laboratory of PUC-Rio. Keywords Groupware development; software components. multilayer software architecture; frameworks. Sumário 1 Introdução 16 1.1. Groupware e o Modelo 3C 16 1.1.1. Comunicação 17 1.1.2. Coordenação 18 1.1.3. Cooperação 19 1.2. O AulaNet 19 1.2.1. A Arquitetura do AulaNet 2.1 22 1.3. Consórcio de Pesquisa 23 1.3.1. Agregando Frameworks de Infra-Estrutura em uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet 24 1.3.2. Desenvolvimento de Groupware Componentizado com base no Modelo 3C de Colaboração 26 1.3.3. RUP-3C-Groupware: um Processo de Desenvolvimento de Groupware baseado no Modelo 3C de Colaboração 29 1.4. Organização da Escrita 30 2 Frameworks: Conceitos Gerais 33 2.1. Definições de Frameworks 33 2.2. Classificação dos Frameworks 34 2.2.1. Frameworks de Aplicações Orientado a Objetos 34 2.2.2. Frameworks de Componentes 36 2.3. Papéis Envolvidos no Uso e Desenvolvimento de um Framework 37 2.4. Conseqüências da Adoção de Frameworks 37 2.4.1. Benefícios Decorrentes da Utilização de Frameworks 38 2.4.2. Desafios Decorrentes da Utilização de Frameworks 39 2.5. Frameworks e Outras Abordagens 41 2.5.1. Frameworks e Aplicações Orientado a Objetos 41 2.5.2. Frameworks e Biblioteca de Classes 41 2.5.3. Frameworks e Padrões de Projeto 42 2.5.4. Frameworks e Componentes de Software 42 2.6. Conclusão 43 3 A Camada de Negócios 47 3.1. O Modelo de Componentes Enterprise JavaBeans 47 3.1.1. Vantagens Decorrentes do Uso de Enterprise JavaBeans 49 3.1.2. Desvantagens Decorrentes do Uso de Enterprise JavaBeans 50 3.1.3. O Futuro do Enterprise JavaBeans 52 3.2. Uma Arquitetura Usando POJOs 53 3.3. Questões Decorrentes do Mapeamento Objetos em Tabelas 54 3.3.1. Conflito de Paradigmas: Orientação a Objetos x Relacional 54 3.4. Frameworks ORM 57 3.4.1. O Framework Hibernate 58 3.4.1.1. Hibernate - Um Exemplo Prático 58 3.4.1.2. Hibernate e a Questão dos Subtipos 68 3.4.1.3. Hibernate e a Questão da Igualdade 70 3.4.1.4. Hibernate e as Questões dos Relacionamentos 71 3.4.1.5. Hibernate e a Questão do Grafo de Navegação 71 3.4.1.6. Considerações Finais Sobre o Hibernate 72 3.4.2. Outros Frameworks ORM 73 3.4.2.1. Quantidade de Documentação Disponível 73 3.4.2.2. Disponibilidade de Suporte 75 3.4.2.3. Disponibilidade de Ferramentas Compatíveis 76 3.4.2.4. Grau de Aceitação no Mercado 77 3.4.2.5. Disponibilidade de Profissionais 78 3.4.2.6. Resultado da Comparação entre Frameworks ORM 80 3.5. O Framework de Infra-Estrutura Spring 80 3.5.1. Dependency Injection 81 3.5.2. Dependency Injection com Spring 83 3.5.3. Integração do Hibernate com o Spring 88 3.5.4. Transações Declarativas com Spring 91 3.5.5. Gerenciamento de Segurança com Spring 94 3.5.6. Exposição de Serviços Remotos com Spring 97 3.5.7. Considerações Finais Sobre o Spring 99 3.5.8. Outros Frameworks Para Dependency Injection 100 3.5.8.1. Quantidade de Documentação Disponível 100 3.5.8.2. Disponibilidade de Suporte 102 3.5.8.3. Disponibilidade de Ferramentas Compatíveis 103 3.5.8.4. Grau de Aceitação no Mercado 104 3.5.8.5. Disponibilidade de Profissionais 106 3.5.8.6. Resultado da Comparação 107 3.6. Conclusão 107 4 A Camada de Apresentação 110 4.1. Vantagens e Desafios no Desenvolvimento de Interfaces HTML 110 4.2. Model View Controller 112 4.3. Características Comuns a Web Frameworks 114 4.4. Comparação Técnica entre Web Frameworks 115 4.4.1. Struts 116 4.4.2. Spring MVC 123 4.4.3. JavaServer Faces 130 4.4.4. Resultado da Análise Técnica 136 4.5. Comparação Não-Técnica entre Web Frameworks 137 4.5.1. Quantidade de Documentação Disponível 138 4.5.2. Disponibilidade de Suporte 139 4.5.3. Disponibilidade de Ferramentas Compatíveis 140 4.5.4. Grau de Aceitação no Mercado 141 4.5.5. Disponibilidade de Profissionais 143 4.5.6. Resultado da Análise 144 4.6. Conclusão 145 5 Arquitetura do AulaNet 3.0 149 5.1. Elementos Principais da Arquitetura do AulaNet 3.0 149 5.2. A Arquitetura do AulaNet 3.0 e os Frameworks de Infra-Estrutura 152 5.3. Arquitetura Técnica e Mobilidade 155 5.4. Arquitetura Técnica e Outros Frameworks: Jade 161 5.4.1. Agentes de Software 161 5.4.2. Aplicações de Sistemas Multi-Agentes 162 5.4.3. O Framework de Agentes Jade 163 5.4.4. Jade e a Arquitetura do AulaNet 3.0 167 5.4.5. Prova de Conceito com Agente Móvel 170 5.4.2.1. MAS 1: O Que Há de Novo na Conferência? 171 5.4.2.2. MAS 2: Alerta de Condições Indesejáveis 180 5.5. Conclusão 183 6 Conclusão 188 7 Referências Bibliográficas 194 Apêndice A Comunicações Pessoais 202 A.1. Comunicação com Christian Bauer 202 A.2. Comunicação com Rod Johnson 203 A.3. Comunicação com Matt Raible 205 Apêndice B Método Utilizado na Análise Não-Técnica 207 B.1. Quantidade de Documentação Disponível 207 B.2. Disponibilidade de Suporte 208 B.3. Disponibilidade de Ferramentas Compatíveis 209 B.4. Grau de Aceitação no Mercado 210 B.5. Disponiblidade de Profissionais 210 Lista de figuras Figura 1.1 – O Modelo 3C (Pimentel et al., 2005) 17 Figura 1.2 – Classificação dos Serviços do AulaNet segundo o Modelo 3C 20 Figura 1.3 – AulaNet no Desktop. 21 Figura 1.4– AulaNetM em um PDA. 21 Figura 1.5 – Arquitetura do AulaNet 2.0 (Barreto et al., 2005). 22 Figura 1.6 – Arquitetura Técnica do AulaNet 3.0. 25 Figura 1.7. A arquitetura de aplicação proposta 28 Figura 1.8. Foco para o desenvolvimento de uma versão da aplicação groupware com base no Modelo 3C de Colaboração 29 Figura 1.9 – Exemplo de uma Listagem de Código. 31 Figura 3.1 – Diagrama de Classes que Exemplifica a Questão do Grafo de Navegação 56 Figura 3.2 – Diagrama UML de Classes Persistidas no Exemplo 59 Figura 3.3 – Diagrama de Classes com Herança. 69 Figura 3.4 – Livros Publicados Para Cada Framework ORM Fonte: Amazon.com, Novembro de 2005 74 Figura 3.5 – Artigos e Tutoriais Para Cada Framework ORM Fonte: Google.com, Novembro de 2005 Figura 3.6 - Mensagens Trocadas em Listas de Discussão (11/2005) 74 75 Figura 3.7 – Ferramentas Compatíveis com os Frameworks ORM em 11/2005 76 Figura 3.8 – Ofertas de Emprego Abertas para cada Framework ORM Fonte: Dice.com, Dezembro de 2005 77 Figura 3.9 – Ofertas de Emprego Abertas para cada Framework ORM Fonte: Manager Online, Dezembro de 2005 78 Figura 3.10 – Disponibilidade de Profissionais Fonte: Jobs.net, Dezembro de 2005 79 Figura 3.11 - Disponibilidade de Profissionais Fonte: APInfo.com, Dezembro de 2005 79 Figura 3.12 – Dependências Configuradas sem Dependency Injection 82 Figura 3.13 - Dependências Configuradas com Dependency Injection 82 Figura 3.14 – Modelo de Classes do Exemplo do Spring 84 Figura 3.15 - Livros Publicados Para Cada Framework de Dependency Injection Fonte: Amazon.com, Dezembro de 2005 101 Figura 3.16 - Artigos e Tutoriais Para Cada Framework de Dependency Injection Fonte: Google.com, Dezembro de 2005 Figura 3.17 - Mensagens Trocadas em Listas de Discussão (11/2005) 101 103 Figura 3.18 – Ferramentas Compatíveis com os Frameworks para Dependency Injecton em 12/2005 104 Figura 3.19 – Ofertas de Emprego Abertas para cada Framework para Dependency Injection. Fonte: Dice.com, Dezembro de 2005 105 Figura 3.20 - Vagas Abertas para cada Framework de Dependency Injection Fonte: Manager Online, Dezembro de 2005. Figura 3.21 - Disponibilidade de Profissionais em 12/2005 Fonte: Jobs.net. 105 106 Figura 3.22 - Disponibilidade de Profissionais Fonte: APInfo.com, Dezembro de 2005. 107 Figura 4.1 – MVC clássico (Ramachandran, 2002) 113 Figura 4.2 – MVC pull (Johnson, 2002, 2004) 114 Figura 4.3 - Calendário 135 Figura 4.4 - Editor HTML 135 Figura 4.5 - Número de Livros Publicados 138 Figura 4.6 - Número de Tutoriais escritos 139 Figura 4.7 – Mensagens Trocadas em Listas de Discussão (Julho/2005) 140 Figura 4.8 – Ferramentas Compatíveis 141 Figura 4.9 - Oferta de Empregos nos Meses 10/2004, 7/2005 e 11/2005 Fonte: Dice.com, 10/2004, 07/2005 (Raible, 2005) e 11/2005 Figura 4.10 – Ofertas de Emprego Fonte: Manager Online, Outubro de 2005 142 142 Figura 4.11 - Disponibilidade de Profissionais com Habilidades nos Frameworks Fonte: Monster.com, Junho de 2005 (Raible, 2005) 143 Figura 4.12 - Disponibilidade de Profissionais com Habilidades nos Frameworks Fonte: APInfo.com, Novembro de 2005 144 Figura 5.1 - Arquitetura de Aplicação do AulaNet 3.0 (Gerosa, 2006) Apresentada na Seção 1.3. Figura 5.2 – Arquitetura Técnica do AulaNet 3.0 Apresentada na Seção 1.3. 150 151 Figura 5.3 - Arquitetura de Aplicação do AulaNet 3.0 (Gerosa, 2006) 153 Figura 5.4 - Arquitetura Técnica do AulaNet 3.0 com Frameworks. 154 Figura 5.5 – Arquitetura Técnica da Integração AulaNet 3.0 com AulaNetM por Reposição da Camada de Apresentação 157 Figura 5.6 - Arquitetura Técnica da Integração AulaNet 3.0 com AulaNetM por Exposição de Serviços Remotos 159 Figura 5.7 – Plataformas de Agentes Jade (Caire, 2003). 165 Figura 5.8 – Diagrama de Classes do Adaptador Jade-Leap para o Spring 168 Figura 5.9 – Plataforma de Execução do MAS 1 172 Figura 5.10 – PDA Após a Inicialização do Jade-Leap 179 Figura 5.11 – PDA Após a Primeira Consulta 179 Figura 5.12 - PDA Após a Segunda Consulta 180 Figura 5.13 – Informações Visuais no AulaNetM 182 Figura 5.14 – Informações Estatísticas no AulaNetM 182 Figura 5.15 – Informações Visuais no AulaNetM 183 Figura 5.16 – Informações Estatísticas no AulaNetM 183 Figura 5.17 – Arquitetura Técnica do AulaNet 3.0 com Frameworks 185 Listagens de Código Listagem 3.1 – Classe Message 59 Listagem 3.2 – Classe User 60 Listagem 3.3 – Arquivo hibernate.cfg.xml de Configuração do Hibernate 61 Listagem 3.4 – Arquivo User.hbm.xml de Mapeamento Objeto – Relacional 62 Listagem 3.5 - Arquivo Message.hbm.xml de Mapeamento Objeto – Relacional 63 Listagem 3.6 – Operação de Criação com o Hibernate 64 Listagem 3.7 – Operação de Atualização com o Hibernate 66 Listagem 3.8 – Operação de Consulta com o Hibernate Usando HQL 67 Listagem 3.9 – Operação de Remoção com o Hibernate 68 Listagem 3.10 – Classe Message. 85 Listagem 3.11 – Interface MessageDAO. 85 Listagem 3.12 – Classe ConferenceFacade. 86 Listagem 3.13 – Arquivo de Configuração do Spring 87 Listagem 3.14 – Descritor web.xml da Aplicação: Iniciando o Contexto Spring 88 Listagem 3.15 – Arquivo de Configuração do Spring: Integração com Hibernate. 89 Listagem 3.16 – Classe MessageDAOImpl. 90 Listagem 3.17 - Arquivo de Configuração do Spring: Transações Declarativas. 93 Listagem 3.18 - Arquivo de Configuração do Spring: Segurança Declarativa. 96 Listagem 3.19 - Arquivo de Configuração do Spring: Exposição de Serviços Remotos. 99 Listagem 4.1 – Declaração do Controlador do Struts na Instancia (web.xml) 117 Listagem 4.2 – Descritor struts-config.xml 118 Listagem 4.3 – Ação postMessage 119 Listagem 4.4 – Action Form da ação postMessage 120 Listagem 4.5 – Regras de Validação (validation.xml) 121 Listagem 4.6 – Página de Envio de Mensagens 122 Listagem 4.7 - Declaração do Controlador do Spring MVC na Instancia (web.xml) 124 Listagem 4.8 - Descritor SpringDispatcher-servlet.xml 125 Listagem 4.9 – Controlador Associado à Requisição postMessage 126 Listagem 4.10 – Bean de Formulário Associado ao Controlador postMessage 127 Listagem 4.11 – Classe de Validação para o Controlador postMessage 128 Listagem 4.12 - Página de Envio de Mensagem 129 Listagem 4.13 - Declaração do Controlador do JSF na Instancia (web.xml) 131 Listagem 4.14 – Arquivo de Configuração faces-config.xml 132 Listagem 4.15 – Backing Bean do Comando postMessage 133 Listagem 4.16 – Página de Envio De Mensagens (JSF) 134 Listagem 5.1 – Agente Conferência 173 Listagem 5.2 – Comportamento WhatIsNewInConferenceBehaviour 174 Listagem 5.3 – Configuração no Spring do Adaptador Jade-Leap 175 Listagem 5.4 – Agente Móvel 176 Listagem 5.5 – Comportamento ConferenceQueryBehaviour 177 1 Introdução Ao desenvolver groupware, o desenvolvedor depara-se com inúmeros desafios. Além de entender de seu domínio de aplicação, ou seja, colaboração, este deve lidar com aspectos de infra-estrutura de baixo nível, como o gerenciamento de transações, a persistência dos dados da aplicação e a validação dos dados de entrada do usuário. O desenvolvimento de groupware já é difícil por si só devido a seu caráter multidisciplinar e a heterogeneidade dos diversos grupos de trabalho (Gerosa et al., 2004) e não deve ser complicado por questões de baixo nível. A introdução frameworks de infra-estrutura como o Hibernate (2005), o Spring (2005) e o JSF (2005) possibilita que o desenvolvedor de groupware concentre-se em seu domínio e lide com estas questões a partir de uma perspectiva mais alto nível. O AulaNet (Lucena & Fuks, 2000) é um groupware (Fuks et al., 2005) usado no ensino/aprendizagem colaborativo. Este é desenvolvido no Laboratório de Engenharia de Software (LES) da Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). O objetivo da pesquisa que resultou nesta dissertação de mestrado é elaborar uma arquitetura técnica para groupware que ofereça uma base de serviços independentes de domínio, tomando como estudo de caso o ambiente AulaNet. Esta introdução apresenta conceitos fundamentais sobre groupware. Também são apresentadas as arquiteturas do AulaNet 2.1 e 3.0. Por fim, são descritas as teses consorciadas a este trabalho e a organização do texto. 1.1. Groupware e o Modelo 3C Groupware é software que apóia a interação entre indivíduos que trabalham para a realização de um objetivo comum (Rezende, 2003). Trabalhando colaborativamente, pelo menos potencialmente, pode-se produzir melhores resultados do que individualmente (Fuks et al., 2002). Capitulo 1. Introdução 17 O modelo 3C é usado para analisar a colaboração. Segundo este modelo, para colaborar, indivíduos devem se comunicar, coordenar e cooperar de forma adequada. A Figura 1.1esquematiza o modelo 3C. comum + ação Ação de tornar comum COMUNICAÇÃO demanda COOPERAÇÃO co + operar + ação Ação de operar em conjunto gera compromissos gerenciados pela Percepção Contexto COORDENAÇÃO organiza as tarefas para co + ordem + ação Ação de organizar em conjunto Figura 1.1 – O Modelo 3C (Pimentel et al., 2005) Para que os objetivos sejam atingidos, um grupo precisa se comunicar, o que gera compromissos. Para garantir que estes sejam cumpridos e lidar com eventuais conflitos que possam surgir, é preciso que os compromissos gerados pela comunicação sejam coordenados. Coordenados, os integrantes do grupo podem cooperar, operando em conjunto e realizando o trabalho colaborativo. A cooperação demanda comunicação e o ciclo recomeça. Para desenvolver groupware de qualidade, é necessário entender de colaboração (Pimentel et al., 2005). Utilizando o modelo 3C pode-se mapear características de um serviço em cada um dos “Cs” e, desta forma, melhorar a ferramenta através da modificação de um dos “Cs”. Pode-se também identificar deficiências de um groupware a partir da análise da colaboração baseada no modelo 3C, acrescentando ou removendo serviços de comunicação, coordenação e cooperação (Pimentel, 2006) de acordo com a necessidade do grupo de trabalho. 1.1.1. Comunicação Participantes de uma equipe de trabalho devem se comunicar para conseguir realizar tarefas relacionadas, que necessitem de negociação ou que se encontram parcialmente descritas (Rezende, 2003). A comunicação em groupware pode ser efetuada de diversas formas. Alguns exemplos de ferramentas de comunicação disponíveis no AulaNet são o Debate e a Mensagem Instantânea, ferramentas de Capitulo 1. Introdução 18 comunicação síncrona, e a Conferência e o Correio para Turma, ferramentas de comunicação assíncrona. As ferramentas de comunicação síncrona privilegiam a interação entre os participantes, já que o tempo entre o envio de uma mensagem e a resposta do receptor é curto. Já as ferramentas de comunicação assíncronas valorizam a reflexão, pois os participantes têm mais tempo para formular suas mensagens. Segundo o modelo 3C de colaboração, a comunicação é dita bem sucedida quando a mensagem tem o seu significado entendido pelo receptor (Fuks et al., 2005). A comunicação é realizada com o objetivo de gerar compromissos, porém uma mensagem mal interpretada pode gerar conflitos. A leitura da mensagem altera o conhecimento do receptor e gera compromissos, que resultam em ações. Para ter indicações de que a mensagem foi compreendida o emissor deve observar as ações e o discurso do receptor (Fuks et al., 2005). Uma vez gerados os compromissos, é necessário coordenar o grupo para garantir o cumprimento dos compromissos. 1.1.2. Coordenação Para que um grupo cumpra uma tarefa de forma eficiente, para que o trabalho em grupo produza um resultado melhor que a soma dos trabalhos individuais, os membros do grupo precisam ser coordenados (Fussell et al., 1998). A coordenação organiza o grupo para evitar que esforços de comunicação e cooperação sejam perdidos e que as tarefas sejam realizadas na ordem correta, no tempo correto e cumprindo as restrições e objetivos (Raposo et al., 2001). Alguns exemplos de ferramentas de coordenação disponíveis no AulaNet são o serviço de Avisos e o Acompanhamento de Participação. A coordenação de tarefas envolve a pré-articulação, o gerenciamento das atividades e a pós-articulação. Durante a pré-articulação são realizadas todas as ações necessárias de preparação para a colaboração. Dentre estas tarefas incluemse a definição dos objetivos, o mapeamento dos objetivos em tarefas, a seleção dos participantes e a distribuição das tarefas entre os participantes. Normalmente a fase da pré-articulação termina antes do início da cooperação. O gerenciamento das atividades consiste no controle das interdependências das tarefas executadas Capitulo 1. Introdução 19 para alcançar o objetivo. A pós-articulação ocorre após a conclusão das tarefas e envolve uma análise dos resultados e a documentação do processo colaborativo (Fuks et al., 2005). Trabalhar colaborativamente demanda esforço para a coordenação dos membros de um grupo. Sem coordenação, parte dos esforços de comunicação não são aproveitados na cooperação. Para que o grupo possa operar em conjunto (cooperar) de forma satisfatória é necessário que os compromissos assumidos na comunicação entre os participantes sejam coordenados (Rezende, 2003). 1.1.3. Cooperação Cooperação é o ato de operar em conjunto. Membros de um grupo cooperam, manipulando e organizando informação, construindo e refinando objetos de cooperação como documentos de texto, planinhas, gráficos entre outros. Mecanismos de cooperação provêem meios para gerenciar estes artefatos no espaço compartilhado, através do gerenciamento de versões, controle de acesso, busca, etc (Fuks et al., 2005). Alguns exemplos de ferramentas de cooperação disponíveis no AulaNet são o serviço de Aulas e o serviço de CoAutoria. O registro da informação na forma de objetos de cooperação visam aumentar o entendimento entre pessoas reduzindo a incerteza, relacionada à ausência de informação, e à equivocalidade, relacionada à ambigüidade e a existência de informações conflitantes (Fuks et al., 2002). Ao salvar as informações trocadas, o grupo pode armazenar a história de uma discussão que resultou em uma decisão. Contando com a memória coletiva, em um tempo futuro esta história pode ser consultada, retomando os motivos que levaram decisão. 1.2. O AulaNet Dá-se o nome de learningware a um groupware que dá suporte a aprendizagem colaborativa (Santoro et al., 1999). O AulaNet é um learningware baseado na web desenvolvido pelo Laboratório de Engenharia de Software (LES) Capitulo 1. Introdução 20 da Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) desde junho de 1997. Participam de seu desenvolvimento alunos de graduação, mestrado e doutorado que também o usam para aplicar suas pesquisas e escrever artigos, monografias, dissertações e teses. Atualmente o AulaNet está disponível em português, inglês e espanhol. Seu código fonte é fechado, mas sua distribuição é feita gratuitamente pela empresa EduWeb (2005). Esta empresa também realiza customizações no AulaNet para uso nos seus diversos clientes. Os serviços do AulaNet são categorizados segundo sua classificação de acordo com o modelo 3C em serviços de comunicação, coordenação e cooperação. COMUNICAÇÃO Síncrona Assíncrona Mensagem C orreio para Instantânea Participante Bate-papo C orreio p/ Turma Debate C onferência Aulas Informações Documentação Avisos Bibliografia Tarefas Webliografia Exame Download Pesq. Opinião C o-autoria Acompanham. da Participação Acompanham. da Navegação C ertificado COOPERAÇÃO COORDENAÇÃO Figura 1.2 – Classificação dos Serviços do AulaNet segundo o Modelo 3C (Pimentel et al., 2005) Os serviços de comunicação oferecem ferramentas com as quais os aprendizes dos cursos do AulaNet podem se comunicar de forma síncrona ou assíncrona. Os serviços de coordenação provêem serviços usados na gerência e controle das atividades de grupo. Os serviços de cooperação incluem serviços que Capitulo 1. Introdução 21 oferecem suporte ao conteúdo bibliográfico dos cursos, co-autoria entre aprendizes e outros. Recentemente iniciou-se o desenvolvimento do AulaNetM, uma extensão dos serviços do AulaNet para dispositivos móveis. Esta iniciativa tem como objetivo explorar o uso do m-learning no AulaNet (Filippo et al., 2005a, b). A Figura 1.3 mostra a tela principal do AulaNet 3.0 e a Figura 1.4 a lista de mensagens da conferência do AulaNetM. Figura 1.3 – AulaNet no Desktop. Figura 1.4– AulaNetM em um PDA. Ao longo dos 8 anos que o AulaNet vem sendo desenvolvido, foram escritos 4 livros ou capítulos de livros, 15 artigos em revistas, 57 artigos em conferências e workshops, 2 teses de doutorado, 9 dissertações de mestrado e 5 monografias de fim de curso relacionadas de alguma forma ao AulaNet. Além disso, o AulaNet está presente em várias universidades no Brasil, como a PUC-Rio, a Federal do Rio de Janeiro, a Federal da Bahia entre outras, e em várias universidades do resto do mundo, dentre elas Universidade Tecnológica do Panamá e Universidade da Madeira (Portugal). O AulaNet também é usado em empresas, entre elas a Rede Globo, NEXTEL e SENAC. Os mesmos desenvolvedores do AulaNet mantêm os cursos Engenharia de Groupware, onde ele é usado como repositório de informações e o curso Tecnologias de Informação Aplicada A Educação (TIAE), onde ele é usado integralmente em um curso totalmente à distância. Estes cursos são ministrados semestralmente e estão disponíveis para alunos da graduação e pós-graduação da PUC-Rio. A experiência com estes cursos fornece subsídios usados na melhoria constante do AulaNet. O AulaNet é um learningware desenvolvido pelo LES desde 1997 e é usado em diversas empresas e universidades. O AulaNet também é usado para testar Capitulo 1. Introdução 22 hipóteses de pesquisas em diversos trabalhos de alunos da graduação, mestrado e doutorado da PUC-Rio. Atualmente, a versão distribuída do AulaNet é a 2.1. Sua arquitetura é descrita na seção a seguir. 1.2.1. A Arquitetura do AulaNet 2.1 O AulaNet é desenvolvido desde junho de 1997. Inicialmente seu código era escrito em LUA (Ierusalimschy et al., 1996). O código evoluiu rapidamente e então decidiu-se utilizar a linguagem de programação Java, de modo a melhorar a integração com o mercado de desenvolvedores e aproveitar a robustez, portabilidade e recursos desta plataforma. O AulaNet foi então totalmente reformulado e sua versão 2.0 escrita em Java foi lançada. Desde então, a sua arquitetura não sofreu alterações significativas. Atualmente, a versão de produção do AulaNet é a 2.1 que possui a mesma arquitetura da 2.0. Esta é baseada no paradigma cliente-servidor e é fortemente dependente da tecnologia Scriba (Fuks et al., 2003). A Figura 1.5 exibe o esquema da arquitetura do AulaNet 2.1. Conteúdo Web Java Servlets Scriba P á gina s HTML Se rvle ts e C la sse s Ja va Aplicações Se rvido r de De ba te Se rvido r de P re se nça BD Figura 1.5 – Arquitetura do AulaNet 2.0 (Barreto et al., 2005). A tecnologia Scriba é constituída por uma linguagem de script que é embutida em arquivos HTML e um Servlet que interpreta os arquivos HTML. O Scriba possibilita, dentre outras coisas, chamadas a classes Java, acesso a banco de dados e definições de variáveis. A maior parte das páginas HTML/Scriba está relacionada a classes Java, que acessam o banco de dados, realizam algum processamento e constroem a representação gráfica do resultado. O código que representa a lógica da aplicação Capitulo 1. Introdução 23 não é separado do código que representa a interface com o usuário e encontra-se espalhado tanto nas páginas HTML/Scriba quanto nas classes Java. Os principais problemas desta arquitetura são a baixa modularidade, o uso de um paradigma procedural, a não aderência a tecnologias e boas práticas atuais e a não separação da lógica da aplicação da interface com o usuário. O código do AulaNet 2.1 vem sendo desenvolvido ao longo destes anos através de prototipação. Isto, aliado a rotativade dos desenvolvedores do projeto, com o passar do tempo resultou em um código pouco modular e não padronizado. Como conseqüência, o código do AulaNet hoje apresenta um baixo grau de reuso. Apesar de usar a linguagem Java, que é orientada a objetos, o código presente no AulaNet 2.1 assemelha-se à abordagem funcional, sem que seja utilizado uma modelagem de classes. Desta forma, muitas das vantagens inerentes ao paradigma OO não são aplicáveis ao AulaNet 2.1. Muitas das tecnologias e das boas práticas presentes hoje não estavam presentes quando o AulaNet 2.1 foi desenvolvido. Um exemplo disto é a tecnologia JSP, que surge em meados de 1999 e oferece recursos semelhantes à tecnologia Scriba. O uso de tecnologias proprietárias como o Scriba dificulta a integração com outras equipes de desenvolvimento, como a EduWeb, que precisa treinar cada novo funcionário nesta tecnologia. Por fim, a falta de uma separação clara entre a lógica da aplicação e a interface com o usuário dificulta o reuso, pois a lógica de negócios não pode ser reutilizada separadamente. A soma destes problemas resultou em um AulaNet cuja atividade de manutenção é muito cara e cuja entrada de novos desenvolvedores ou integração com outros grupos de desenvolvedores é difícil. Para solucionar estes problemas, o consórcio de teses Groupware@LES propôs uma nova arquitetura para o AulaNet. 1.3. Consórcio de Pesquisa Para investigar o desenvolvimento de groupware e sua aplicação no desenvolvimento do AulaNet 3.0, nosso grupo de pesquisa Groupware@LES consorciou três trabalhos: esta dissertação de mestrado propõe a integração de Capitulo 1. Introdução 24 frameworks na constituição da arquitetura técnica do AulaNet; Gerosa (2006), em sua tese de doutorado, propõe a montagem de groupware a partir da agregação de serviços e componentes baseados no Modelo 3C de Colaboração; e Pimentel (2006), em sua tese de doutorado, propõe um processo de desenvolvimento de groupware usando o Modelo 3C de Colaboração em diferentes etapas do processo. Estes trabalhos consorciados reduzem a distância semântica entre a implementação e os conceitos do domínio referentes à colaboração, o que favorece a manutenção e a evolução do groupware. Com o objetivo de contextualizar os três trabalhos, esta seção é replicada na introdução da dissertação e das teses resultantes. As subseções seguintes resumem cada trabalho. 1.3.1. Agregando Frameworks de Infra-Estrutura em uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet No desenvolvimento de um groupware, o projetista se depara com desafios em diferentes níveis: entender do domínio e lidar com questões de infra-estrutura. O desenvolvimento de groupware é difícil devido ao seu caráter multidisciplinar e à heterogeneidade dos diversos grupos de trabalho. O desenvolvedor deveria se concentrar mais nos aspectos funcionais utilizando uma infra-estrutura que trate as questões técnicas. Nesta dissertação, foi elaborada uma arquitetura técnica multicamadas que faz uso do padrão MVC (Fowler, 2002) e que integra frameworks de infraestrutura (Fayad & Schmidt, 1997; Fayad et al. 1999a, b; Fayad & Johnson, 2000). A abordagem multicamadas com o padrão MVC proporciona a separação entre a lógica da aplicação e a interface com o usuário, considerada uma boa prática de design de software (Fowler, 2002). Frameworks de infra-estrutura proporcionam uma maneira de lidar com as questões de baixo nível como persistências de dados, controle de transações, segurança, etc. O diagrama esquematizado na Figura 1.6 mostra a arquitetura técnica proposta para o AulaNet 3.0. As setas indicam o fluxo de controle da aplicação, os retângulos representam classes, os círculos representam as interfaces, e as linhas pontilhadas representam a divisão entre as camadas. Esta arquitetura, baseada na Capitulo 1. Introdução 25 Arquitetura de POJOs descrita por Johnson (2002, 2004), é organizada nas seguintes camadas: apresentação, negócios e recursos. Camada de Apresentação V C Camada de Negócios Façade M (DTO) Mail Sender Data Access Object Camada de Recursos Servidor de E-Mails SGBD Figura 1.6 – Arquitetura Técnica do AulaNet 3.0. A camada de recursos relaciona os recursos externos necessários para que a aplicação seja executada. Na arquitetura do AulaNet 3.0 estão previstos o uso de banco de dados relacional (SGBD) e um servidor de e-mails. A camada de negócios implementa a lógica da aplicação utilizando POJOs (POJO, 2005) (Plain Old Java Objects). “O termo [POJO] foi cunhado enquanto eu [Martin Fowler], Rebbecca Parsons e Josh MacKenzie estávamos nos preparando para uma conferência em Setembro de 2000. Na palestra estávamos levantando os vários benefícios de codificar a lógica de negócios usando objetos Java comuns em vez de usar Beans de Entidade [EJB]. Questionávamos por que as pessoas eram tão contra usar objetos comuns em seus sistemas, e concluímos que era pela falta de um nome pomposo para os objetos simples. Então inventamos um, e o termo pegou muito bem.” (POJO, 2005) Na camada de negócios, o modelo (representado no diagrama da Figura 1.6 pela letra M do MVC) é implementado por classes que realizam o padrão de projetos Data Transfer Object (Fowler, 2002), usadas para transportar os dados das entidades de negócio entre camadas. O acesso à base de dados é encapsulado através de classes que implementam o padrão de projetos Data Access Objects (DAO) (Alur et al., 2001), o que possibilita variar a maneira de persistir as classes Capitulo 1. Introdução 26 do modelo sem que seja preciso reescrever o código cliente. Mail Sender é a classe para enviar e-mails que, de forma similar ao DAO, encapsula o acesso ao servidor de e-mails. A lógica de negócios é exposta para a camada de apresentação através de um Façade (Gamma et al., 1995), que é o padrão de projeto para prover uma interface para acesso às funcionalidades de um serviço. A camada de apresentação expõe a lógica de negócios ao usuário-final. Na arquitetura do AulaNet 3.0, esta camada é composta pelo controlador (representado no diagrama da Figura 1.6 pela letra C do MVC) e por páginas JSP que implementam a camada de Visão (representado no diagrama da Figura 1.6 pela letra V do MVC). O controlador chama os métodos do Façade, acessando a camada de negócios. Os DTOs resultantes de operações são passados à visão que exibe as informações ao usuário. Frameworks de infra-estrutura foram selecionados e acrescentados a esta arquitetura para prover persistência de dados, gerenciamento de transações entre outros aspectos. Estes frameworks possibilitam ao desenvolvedor tratar estes aspectos com uma visão em alto nível, concentrando-se em seu domínio de aplicação, no caso, colaboração. 1.3.2. Desenvolvimento de Groupware Componentizado com base no Modelo 3C de Colaboração Um groupware é composto de ferramentas colaborativas como Fórum, Agenda, Documentação, etc. Estas ferramentas, disponíveis em diversas aplicações groupware, compartilham funcionalidades relativas ao suporte computacional à colaboração, tais como canal de comunicação, gerenciamento de participantes, registro de informações, etc. Na tese de Gerosa (2006), para dar suporte ao desenvolvimento de groupware, foram estabelecidos dois níveis de componentização. O primeiro nível é constituído de serviços colaborativos que, por sua vez, são montados com componentes 3C (segundo nível) que implementam funcionalidades relacionadas à colaboração. Estes componentes são distribuídos em component kits organizados em função do modelo 3C de colaboração para que desenvolvedores montem aplicações colaborativas. Nesta abordagem, cada serviço usa componentes de comunicação, coordenação e de cooperação independentemente da classificação Capitulo 1. Introdução 27 3C do serviço. Foi aplicado um método de Engenharia do Domínio para elaborar o conjunto de componentes. Os componentes são iterativamente refinados em função da realimentação obtida com o desenvolvimento dos serviços do AulaNet 3.0 e em função de estudos de caso variando as configurações do suporte à colaboração. Component frameworks (Syzperski, 1997) são usados para oferecer suporte ao gerenciamento e à execução dos componentes. Conforme apresentado na Figura 1.7, na tese de Gerosa (2006) foi elaborado um component framework para cada nível de componentização (serviço e componente 3C). Os serviços são acoplados no Service Component Framework, e os componentes 3C são acoplados no Collaboration Component Framework. Estes component frameworks são responsáveis por tratar a instalação, remoção, atualização, ativação, desativação, localização, configuração e monitoramento de componentes. O Service Component Framework gerencia as instâncias dos serviços e a ligação com os componentes de colaboração correspondentes. O Collaboration Component Framework gerencia as instâncias dos componentes de colaboração, que são provenientes do Collaboration Component Kit. Algumas funcionalidades dos component frameworks são recorrentes, sendo então elaborado um framework para instanciar os component frameworks. Este tipo de framework é chamado de component framework framework (CFF) (Szyperski, 1997, p.277). Um component framework framework é visto como um component framework de segunda ordem, onde seus componentes são component frameworks (Szyperski, 1997, p.276). Na arquitetura da aplicação, o component framework de segunda ordem foi denominado Groupware Component Framework Framework. Capitulo 1. Introdução 28 Groupware Application Groupware Component Framework Framework Service Component Framework Service X Service Y Collaboration Component Framework . . 3C Component A 3C Component B Infrastructure Frameworks Database . Figura 1.7. A arquitetura de aplicação proposta Os component frameworks, serviços e componentes 3C oferecem suporte computacional aos conceitos do modelo 3C de colaboração, instrumentando o desenvolvimento da camada de negócio. A arquitetura de aplicação proposta estrutura os componentes do domínio, representando um projeto lógico de alto nível independente da tecnologia de suporte (D’Souza & Wills, 1998). Já os aspectos de infra-estrutura, tratados nesta dissertação, são independentes do domínio de aplicação. Os componentes da arquitetura de aplicação são implementados segundo a arquitetura técnica. Os serviços do AulaNet são criados com um único Façade que expõe as operações deste serviço para a camada de apresentação. Os componentes de colaboração por sua vez, podem utilizar vários DTOs e DAOs, dependendo da complexidade do componente. Estes componentes podem ainda usar “código cola” (Szyperski, 1997) e adaptadores (D’Souza & Wills, 1998) para possibilitar a integração com componentes e outros sistemas que não são compatíveis por construção. Capitulo 1. Introdução 29 1.3.3. RUP-3C-Groupware: um Processo de Desenvolvimento de Groupware baseado no Modelo 3C de Colaboração Os frameworks de infra-estrutura selecionados nesta dissertação se encarregam de soluções para aspectos de infra-estrutura de baixo nível, visando possibilitar o desenvolvedor se concentrar nos aspectos funcionais. Os kits de serviços e componentes 3C elaborados por Gerosa (2006) fornecem os elementos para compor um groupware. O processo elaborado na tese de Pimentel (2006) estabelece os passos a serem seguidos na montagem do groupware, pois ainda que se construa uma aplicação groupware para um grupo com uma determinada dinâmica, com o tempo surgem novas situações onde são identificados novos problemas. A aplicação necessitará ser modificada para não se manter inadequada. Um processo organiza, em linhas gerais, uma seqüência de passos onde são incorporadas diretrizes e boas práticas que, quando seguidas, levam à produção de um software razoável (Sommerville, 2003; Beck, 2004; Philippe, 2003). Coexistem abordagens diferentes para o desenvolvimento de software, dentre elas, o desenvolvimento baseado em componentes, que é uma estratégia recente que tem se tornado cada vez mais usada (Sommerville, 2003; Gimenes & Huzita, 2005). Seguindo esta abordagem, tornaram-se conhecidos processos como Catalysis (D’Souza e Wills, 1998), UML Components (Cheesman & Daniels, 2001) e RUP – Rational Unified Process (Philippe, 2003). O processo formalizado na tese de Pimentel (2006), denominado RUP-3C-Groupware, também faz uso da abordagem baseada em componentes, estendendo o RUP para o desenvolvimento específico de aplicações groupware. Comunicação Processo de Desenvolvimento de Groupware Cooperação Coordenação Figura 1.8. Foco para o desenvolvimento de uma versão da aplicação groupware com base no Modelo 3C de Colaboração Capitulo 1. Introdução 30 No processo proposto, o Modelo 3C de Colaboração é usado nas diferentes etapas do processo: na análise de domínio para classificação das aplicações groupware e de seus elementos; na construção de componentes (Gerosa, 2006); e no foco dado para o desenvolvimento de cada versão. De acordo com essa prática, a aplicação groupware é desenvolvida resolvendo um problema de comunicação, de coordenação ou de cooperação, um a cada versão ao longo do ciclo de desenvolvimento, esquematizado na Figura 1.8. 1.4. Organização da Escrita O texto desta dissertação está estruturado em 7 capítulos e 1 apêndice. No capítulo 2 são apresentados conceitos importantes sobre frameworks. Este capítulo apresenta definições, classificações e outras características de frameworks pesquisadas na literatura. No capítulo 3 a camada de negócios da arquitetura do AulaNet 3.0 é detalhada. É feita uma breve descrição do modelo de componentes EJB, levantando suas vantagens, desvantagens e a perspectiva para seu futuro. Neste capítulo, após uma análise e comparação criteriosa, são escolhidos o framework Hibernate (2005) e o Spring (2005) para serem acrescentados à camada de negócios do AulaNet 3.0. No capítulo 4 o foco é a camada de apresentação. O grande número de web frameworks disponíveis no mercado demanda uma análise mais detalhada entre os concorrentes desta categoria de framework. Ao término da comparação, o web framework JavaServer Faces (JSF, 2005) é incorporado a camada de apresentação do AulaNet 3.0. O capítulo 5 retoma a descrição da arquitetura do AulaNet 3.0 apresentada neste capítulo, complementando-a com os frameworks analisados tanto no capítulo 3 quanto no capítulo 4. Também é apresentado neste capítulo como a arquitetura do AulaNet 3.0 provê suporte a dispositivos móveis e que novos frameworks podem ser incorporados a arquitetura, tomando como estudo de caso o framework de agentes Jade (2005). Este capítulo mostra ainda os benefícios que o paradigma de agentes de software pode trazer ao AulaNet. Capitulo 1. Introdução 31 O capítulo 6 apresenta as conclusões finais e as contribuições desta pesquisa enquanto que o capítulo 7 apresenta as referencias bibliográficas. O apêndice A é adicionado com a transcrição dos e-mails trocados com outros pesquisadores, que gentilmente cederam dados tornando esta pesquisa mais precisa. O apêndice B fornece detalhes sobre o método utilizado para comparação de frameworks utilizando critérios não-técnicos. Ao longo desta dissertação são apresentadas várias listagens de código. Para destacar as listagens do texto da dissertação são usadas caixas especiais. A Figura 1.9 mostra um exemplo destas caixas. 30: public class HelloReaders { 31: 32: 33: public static void main(String args[]) { System.out.println("Olá, leitores!") ; } 14: } Figura 1.9 – Exemplo de uma Listagem de Código. O início de cada linha é precedido de uma numeração, para facilitar a referência no texto. Linhas em branco não são numeradas. Dentro de uma seção a numeração sempre começa do fim da numeração da listagem anterior. Por exemplo, a listagem acima começa na linha 30, então se supõem que haveria uma listagem anterior cuja última linha seria 29. Numerando as linhas desta forma o texto torna-se mais claro, pois citações de linhas não se confundem quando há mais de uma listagem muito próxima. As listagens de código seguem as convenções de código definidas no Sun Java Code Conventions (SJCC, 2006) sempre que possível, mas eventualmente podem fugir do padrão para tornar a listagem mais clara. Alguns detalhes, como declarações e importações de pacotes são omitidos pelo bem da clareza. Toda a pesquisa que resultou nesta dissertação foi baseada em pesquisas teóricas e aplicações práticas. Um protótipo do serviço da Conferência do AulaNet foi implementado utilizando os principais frameworks apresentados nesta dissertação. As listagens de código presentes nesta dissertação são baseadas em código extraído destes protótipos, simplificadas para fins didáticos. Capitulo 1. Introdução 32 Nesta dissertação, os frameworks também são analisados sob um ponto de vista não-técnico. São comparados os seguintes critérios: disponibilidade de documentação, de suporte e de ferramentas compatíveis, grau de aceitação no mercado e disponibilidade de profissionais aptos a trabalhar com cada framework. Apesar de ser muito difícil obter resultados absolutos para estes critérios, Raible (2005) apresenta um método para colher indícios. A quantidade de documentação pode ser checada através de uma busca por livros sobre o framework na página da livraria Amazon e por artigos disponíveis na web sobre o framework através da ferramenta de busca Google. A disponibilidade de suporte é verificada contabilizando o volume de mensagens trocadas nas listas de discussões oficiais de cada framework. Dessa forma, obtém-se um indício do grau de atividade da comunidade que oferece suporte ao framework. A compatibilidade com ferramentas é verificada analisando um conjunto de ferramentas, verificando a documentação destas uma a uma e checando se são compatíveis com o framework. O grau de aceitação no mercado é verificado através de buscas em sites de empregos, procurando por vagas que solicitem habilidades em cada framework. Por fim, a disponibilidade de profissionais é verificada através de buscas realizadas em sites que hospedam currículos. São contabilizados os currículos de profissionais que se declaram aptos a trabalhar com cada framework. 2 Frameworks: Conceitos Gerais Um dos principais objetivos da Engenharia de Software é o reuso. Através da reutilização de software obtém-se o aumento da qualidade e redução do esforço de desenvolvimento (Gimenes & Huzita, 2005). A orientação a objetos fornece funcionalidades para que classes possam ser reutilizadas, bem como métodos por meio de seus mecanismos de herança e polimorfismo (Lundberg & Mattsson 1996). Componentes de software definem unidades reutilizáveis que oferecem serviços através de interfaces bem definidas (Gimenes & Huzita, 2005). Padrões de Projeto (Design Patterns) (Gamma et al., 1995) é outra abordagem mais abstrata que objetiva a reutilização de projetos de soluções para problemas recorrentes. Além destas formas de reutilização, a tecnologia de frameworks possibilita que uma família de produtos seja gerada a partir de uma única estrutura que captura os conceitos mais gerais da família de aplicações (Pinto, 2000). Este capítulo apresenta os principais conceitos sobre frameworks encontrados na literatura. Primeiramente, são revistas algumas definições sobre frameworks. Logo após, os frameworks são classificados em duas categorias: frameworks de aplicação orientado a objetos e frameworks de componentes. São apresentados os papéis envolvidos no desenvolvimento e uso de frameworks e os benefícios e desafios decorrentes da adoção de frameworks. O capítulo é encerrado com uma comparação entre frameworks e outras abordagens que visam o reuso. 2.1. Definições de Frameworks A literatura é repleta de definições de frameworks. As principais são descritas a seguir. Capitulo 2. Frameworks: Conceitos Gerais 34 Para Fayad et al (1999b) e Johnson & Foote (1988), um framework é um conjunto de classes que constitui um projeto abstrato para a solução de uma família de problemas. Segundo Mattsson (1996, 2000), um framework é uma arquitetura desenvolvida com o objetivo de atingir a máxima reutilização, representada como um conjunto de classes abstratas e concretas, com grande potencial de especialização. Para Johnson (1991) e Gamma et al (1995), um framework é um conjunto de objetos que colaboram com o objetivo de atender a um conjunto de responsabilidades para uma aplicação específica ou um domínio de aplicação. Já segundo Buschmann et al. (1996), Pree (1995) e Pinto (2000) um framework é definido como um software parcialmente completo projetado para ser instanciado. O framework define uma arquitetura para uma família de subsistemas e oferece os construtores básicos para criá-los. Também são explicitados os lugares ou pontos de extensão (hot-spots) nos quais adaptações do código para um funcionamento específico de certos módulos devem ser feitas. Apesar de diferentes, as definições encontradas na literatura não são contraditórias. A definição adotada nesta dissertação é a de Buschmann et al. (1996), Pree (1995) e Pinto (2000). 2.2. Classificação dos Frameworks Frameworks podem ser classificados de diversas formas. Inicialmente, são classificados em dois grupos principais: frameworks de aplicação orientado a objetos (Fayad et al., 1999a, b; Fayad & Johnson, 2000) e framework de componentes (Szyperski, 1997). 2.2.1. Frameworks de Aplicações Orientado a Objetos Frameworks de aplicação orientado a objetos, também chamados de frameworks de aplicação, geram famílias de aplicações orientadas a objetos. Seus pontos de extensão são definidos como classes abstratas ou interfaces, que são estendidas ou implementadas por cada instância da família de aplicações. Segundo Capitulo 2. Frameworks: Conceitos Gerais 35 Fayad et al (1999b), frameworks de aplicação são classificados quanto ao seu escopo em frameworks de infra-estrutura de sistemas, frameworks de integração de middleware e frameworks de aplicações corporativas. Frameworks de infra-estrutura de sistemas simplificam o desenvolvimento de sistemas de infra-estrutura portáveis e eficientes, como sistemas operacionais, frameworks de comunicação, de interfaces gráficas e ferramentas de processamento de linguagens. Frameworks de integração de middleware são usados para integrar aplicações e componentes distribuídos. Estes frameworks escondem o baixo nível da comunicação entre componentes distribuídos, possibilitando que os desenvolvedores trabalhem em um ambiente distribuído de forma semelhante a que trabalham em um ambiente não distribuído. São exemplos de frameworks de integração de middleware Java RMI (RMI-IIOP, 2005) e frameworks ORB (Object Request Broker). Frameworks de aplicações corporativas, ao contrário dos frameworks de infra-estrutura e de integração de middleware, são voltados para um domínio de aplicação específico, como por exemplo, os domínios da aviação, telecomunicações e financeiro. Frameworks de aplicações corporativas são mais caros de serem desenvolvidos ou comprados quando comparados com os de integração de middleware e de infra-estrutura, pois são necessários especialistas do domínio de aplicação para construí-lo. Entretanto, eles podem prover um retorno substancial já que eles encapsulam o conhecimento sobre o domínio onde a instituição atua (Fayad et al., 1999b). Frameworks de infra-estrutura e de integração de middleware fornecerem mecanismos para integrar componentes distribuídos e tratar aspectos de infraestrutura, o desenvolvedor da aplicação abstrai os detalhes em baixo nível e concentra-se no objetivo principal da aplicação. Estes frameworks tratam aspectos comuns a diversos domínios de aplicação de forma que quase sempre são encontradas soluções disponíveis no mercado e na maior parte das vezes é mais vantajoso buscar uma solução existente do que desenvolvê-la internamente. Além da classificação por escopo, segundo Fayad et al (1999b) frameworks podem ainda ser classificados quanto à forma usada para estendê-los. Frameworks caixa branca, ou white box, são instanciados usando herança, através da implementação de Template Methods (Gamma et al., 1995), métodos abstratos Capitulo 2. Frameworks: Conceitos Gerais 36 que são implementados na subclasse, ou da redefinição de métodos ganchos (hook methods) (Pree, 1995), métodos com uma implementação padrão que pode ser redefinida na subclasse. Frameworks caixa preta, ou black box, são instanciados através de configurações e composições, através da definição de classes que implementam uma determinada interface ou contrato. Os pontos de extensão dos frameworks caixa preta freqüentemente são definidos seguindo o padrão de projetos Strategy (Gamma et al., 1995). Frameworks caixa branca exigem que o desenvolvedor responsável pela instanciação do framework possua um bom conhecimento sobre sua estrutura interna e normalmente são mais difíceis de usar. Por outro lado, frameworks caixa preta não exigem tanto conhecimento sobre a estrutura interna do framework, mas são menos flexíveis. Frameworks caixa cinza, ou gray box, possuem as características conjuntas dos frameworks caixa branca e preta, de forma a tentar evitar as desvantagens dos dois. 2.2.2. Frameworks de Componentes Segundo Szyperski (1997), um framework de componentes é uma entidade de software que provê suporte a componentes que seguem um determinando modelo e possibilita que instâncias destes componentes sejam plugadas no framework de componentes. Ele estabelece as condições necessárias para um componente ser executado e regula a interação entre as instâncias destes componentes. Um framework de componente pode ser único na aplicação, criando uma ilha de componentes ao seu redor, ou pode cooperar com outros componentes ou frameworks de componentes. Alguns exemplos de frameworks de componentes são o OpenDoc (2005) e o BlackBox (Oberon, 2005). A principal diferença entre frameworks de aplicação orientado a objetos e framework de componentes é que, enquanto frameworks de aplicações definem uma solução inacabada que gera uma família de aplicações, um framework de componentes estabelece um contrato para plugar componentes. Usando uma analogia, um framework de aplicação equivale ao quadro de uma bicicleta. Há lugares específicos (os pontos de extensão) onde o guidão, as rodas, o banco e os pedais (implementações dos pontos de extensão) podem ser encaixados. Bicicletas Capitulo 2. Frameworks: Conceitos Gerais 37 diferentes (instâncias do framework) podem ser compostas variando estes itens: bicicletas com marchas, com amortecedores, etc., mas apenas os pontos previstos podem variar e o produto final será sempre uma bicicleta. Por outro lado, frameworks de componentes podem ser vistos como uma placa de circuito integrado com slots onde os chips (componentes) podem ser encaixados para criar uma instância. Como os frameworks de componentes, as placas são utilizadas para compor soluções para diversos domínios como por exemplo, uma placa de vídeo ou um modem. 2.3. Papéis Envolvidos no Uso e Desenvolvimento de um Framework Há vários profissionais envolvidos na criação, manutenção e uso (instanciação) de um framework. Estes papéis, que não precisam necessariamente ser exercidos por pessoas diferentes, são segundo Froehlich et al. (1997a), Froehlich et al (1997b) e Pinto (2000): projetista do framework, mantenedor do framework e o desenvolvedor de aplicações (usuário do framework). O projetista do framework é responsável pelo desenvolvimento da estrutura básica do framework. O projetista determina os pontos de extensão do frameworks (hot spots) e realiza o levantamento de requisitos. O mantenedor do framework é responsável por redefinir e acrescentar novas funcionalidades ao projeto do framework, possibilitando que novas características sejam incorporadas ao framework no momento da instanciação pelos desenvolvedores de aplicação. O desenvolvedor de aplicações usa o framework. Ele satisfaz os pontos de extensão para gerar a aplicação, instância do framework. 2.4. Conseqüências da Adoção de Frameworks A utilização de frameworks no desenvolvimento de aplicações traz benefícios, originados de suas características principais: são modulares, reusáveis, extensíveis e eventualmente assumem o controle da execução invocando métodos da aplicação quando necessário (inversão de controle). Por outro lado, há certos Capitulo 2. Frameworks: Conceitos Gerais 38 desafios na criação e uso de frameworks que não podem ser ignorados. Esta seção lista as principais vantagens e desafios decorrente da adoção de frameworks. 2.4.1. Benefícios Decorrentes da Utilização de Frameworks Os principais benefícios decorrentes da utilização de frameworks, segundo Fayad et al. (1999b) e Pinto (2000) advêm da modularidade, reusabilidade, extensibilidade e inversão de controle que os frameworks proporcionam. Frameworks encapsulam detalhes de implementação voláteis através de seus pontos de extensão, interfaces estáveis e bem definidas, aumentando a modularidade da aplicação. Os locais de mudanças de projeto e implementação da aplicação construída usando o framework são localizados, diminuindo o esforço para entender e manter a aplicação. Além disso, frameworks incentivam o reuso, pois capturam o conhecimento de desenvolvedores em determinado domínio ou aspecto de infra-estrutura ou de integração de middleware. As interfaces do framework promovem pontos de extensão que as aplicações estendem gerando instâncias que compartilham as funcionalidades definidas no framework. Desta forma, aumentam a produtividade dos desenvolvedores, pois o processo não começa do zero, a qualidade e a confiabilidade do produto final, pois idealmente as funcionalidades do framework já foram testadas em várias instâncias, e a interoperabilidade de software, pois as instâncias de uma mesma família compartilham características em comum. Frameworks oferecem pontos de extensão explícitos que possibilitam aos desenvolvedores estenderem suas funcionalidades para gerar uma aplicação. Os pontos de extensão desacoplam as interfaces estáveis do framework e o comportamento de um determinado domínio de aplicação das variações requeridas por uma determinada aplicação em um dado contexto. Por fim, alguns frameworks apresentam inversão de controle (Inversion of Controll – IoC). Inversão de controle, também é conhecida como princípio de Hollywood : “Don’t call us, we will call you” (Larman, 2004). Trata-se de transferir o controle da execução da aplicação para o framework, que chama a aplicação em determinados momentos como na ocorrência de um evento. Através da IoC o framework controla quais métodos da aplicação e em que contexto eles Capitulo 2. Frameworks: Conceitos Gerais 39 serão chamados em decorrência de eventos, como eventos de janela, um pacote enviado para determinada porta, entre outros. 2.4.2. Desafios Decorrentes da Utilização de Frameworks Quando usado em conjunto com padrões de projetos, bibliotecas de classes, componentes, entre outros, frameworks de aplicação têm o potencial para aumentar a qualidade de software e reduzir o esforço de desenvolvimento. Contudo, instituições que tentam construir ou usar frameworks freqüentemente falham a menos que resolvam os seguintes desafios: esforço de desenvolvimento, curva de aprendizagem, integração, eficiência, manutenção, validação e remoção de defeitos e falta de padrões (Fayad et al., 1999b). Destes desafios, o esforço de desenvolvimento afeta principalmente os projetistas de frameworks. A curva de aprendizagem, a integração e a eficiência afetam principalmente os desenvolvedores de aplicação. A manutenção e validação e remoção de defeitos afetam tanto desenvolvedores de aplicação quanto mantenedores de frameworks e a falta de padrões afetam a todos envolvidos no desenvolvimento e uso dos frameworks. O desafio do esforço de desenvolvimento ocorre devido à alta complexidade envolvida no projeto de um framework. Se desenvolver aplicações complexas é difícil, desenvolver frameworks que sejam de alta qualidade, extensíveis e reusáveis para domínios de aplicações complexos ou para tratar aspectos de infraestrutura ou de integração de middleware é ainda mais difícil. Projetistas de frameworks devem estar cientes dos custos decorrentes do desenvolvimento de frameworks de aplicação. Quanto à curva de aprendizagem, aprender a usar um framework de aplicação leva tempo e incorre em custos. A menos que o esforço de aprendizado possa ser amortizado através do uso do framework em muitos projetos, ou em projetos duradouros, o investimento pode não compensar. Deve ser analisado se os benefícios trazidos pelo framework compensam os custos com o treinamento da equipe de desenvolvimento. O desafio da integração ocorre quando diversos frameworks são usados com outras tecnologias e com sistemas legados não previstos pela arquitetura do Capitulo 2. Frameworks: Conceitos Gerais 40 framework. Antes de usar um framework o desenvolvedor de aplicações deve analisar possíveis problemas que possam surgir ao incorporar novos frameworks à aplicação. Além disso, aplicações usando frameworks podem apresentar desempenho inferior a aplicações específicas. Para tornarem-se extensíveis, frameworks de aplicações adicionam níveis de indireção. Aplicações genéricas tendem a obter desempenho inferior a aplicações específicas (Fayad et al., 1999b). Desta forma o desenvolvedor de aplicações deve considerar se os ganhos advindos do reuso compensam uma potencial perda de desempenho. Frameworks inevitavelmente precisam ser mantidos. A manutenção em frameworks toma diversas formas como, correção de erros de programação, acréscimo ou remoção de funcionalidades, acréscimos ou remoção de pontos de extensão, etc. A manutenção é realizada pelos mantenedores do framework, que precisam ter um conhecimento profundo sobre os componentes internos e suas interdependências. Em alguns casos, a própria instância do framework sofre manutenção para acompanhar a evolução do framework. Cabe ao desenvolvedor da aplicação considerar o esforço de manutenção gasto para obter os benefícios de uma nova versão do framework. Além disso, a validação e remoção de erros de um framework ou de uma aplicação que usa um framework é um desafio, pois o framework é uma aplicação inacabada, o que torna difícil tanto para os mantenedores de frameworks quando para os desenvolvedores de aplicação testar, respectivamente, o framework e a instância do framework isoladamente. Aplicações que usam framework costumam ser mais difíceis de depurar, pois devido a IoC, o controle da execução oscila entre a aplicação e o framework. Por fim, ainda não há um padrão amplamente aceito para desenvolver, documentar, implementar e adaptar frameworks. Todos os papéis envolvidos no desenvolvimento e uso do framework são afetados por este desafio, sendo que os mais afetados são os mantenedores do framework e o desenvolvedor de aplicações. O primeiro, pois precisa ter um conhecimento profundo sobre os componentes internos e suas interdependências. O segundo, pois a falta de um padrão de documentação de frameworks dificulta o seu uso. Capitulo 2. Frameworks: Conceitos Gerais 41 2.5. Frameworks e Outras Abordagens Esta seção realiza uma breve comparação entre frameworks e outras técnicas de desenvolvimento de software que objetivam o reuso. Dentre elas, são analisadas o projeto de aplicações orientado a objetos, biblioteca de classes, padrões de projeto e componentes de software (Pinto, 2000). 2.5.1. Frameworks e Aplicações Orientado a Objetos Uma aplicação orientada a objetos descreve um programa executável completo, atendendo aos requisitos definidos nos documentos de especificação. Já os frameworks são incompletos e não são executáveis. Eles capturam funcionalidades comuns a diversas aplicações, mas declaram pontos de extensão que devem ser preenchidos pela aplicação que instancia o framework. Frameworks geram famílias de aplicações orientadas a objetos através do preenchimento dos pontos de extensão, mas aplicações orientadas a objetos não geram famílias de frameworks. 2.5.2. Frameworks e Biblioteca de Classes Bibliotecas de classes são conjuntos de classes relacionadas com um propósito geral. Por outro lado, as classes de um framework estão relacionadas a um determinado domínio ou a algum determinado aspecto de infra-estrutura ou de integração de middleware. Além disso, as classes da biblioteca são reutilizadas individualmente enquanto que as classes de um framework são reutilizadas em conjunto. Frameworks tendem a ter um impacto maior do que bibliotecas de classes na arquitetura da aplicação. Frameworks ativos (calling frameworks) (Matsson, 2000), que utilizam inversão de controle, podem assumir o controle de execução da aplicação ao contrário de bibliotecas de classes que são sempre passivas. Capitulo 2. Frameworks: Conceitos Gerais 42 2.5.3. Frameworks e Padrões de Projeto Padrões de projeto são soluções mais abstratas do que um framework. Frameworks são normalmente implementados utilizando linguagens orientadas a objetos como Java, C++, etc. Padrões de projeto descrevem o projeto de uma solução para um problema recorrente, podendo incluir um exemplo de implementação. Além disso, frameworks são mais específicos que padrões de projetos, pois estão relacionados a um domínio de aplicação, um aspecto de infraestrutura ou de integração de middleware. Já padrões de projetos são mais gerais e podem ser usado em diversas situações independente de domínio de aplicação. Por fim, frameworks são construções mais complexas que padrões de projeto. Enquanto um framework pode possuir vários padrões de projeto, o contrário não é verdadeiro. 2.5.4. Frameworks e Componentes de Software Componentes de software podem ser definidos como unidades independentes, que encapsulam dentro de si seu projeto e implementação e oferecem serviços para o meio externo através de interfaces bem definidas (Gimenes & Huzita, 2005). Componentes podem fornecer dois tipos de interface: as interfaces fornecidas, que expõem seus serviços e as interfaces requeridas, por onde o componente explicita suas dependências. Frameworks também fornecem interfaces bem definidas, os pontos de extensão, que as aplicações devem estender. Contudo, enquanto um framework possui necessariamente pontos de extensão, um componente totalmente autocontido não possui interfaces requeridas. Além disso, um componente deve ser plugado a uma interface requerida de outro componente enquanto que os pontos de extensão dos frameworks são menos exigentes, possibilitando que sejam plugados componentes, classes ou qualquer artefato que realiza o contrato definido. Por fim, componentes podem ser desenvolvidos usando frameworks e frameworks podem ser desenvolvidos usando componentes. Estas duas Capitulo 2. Frameworks: Conceitos Gerais 43 tecnologias são complementares de forma que frameworks podem ser usados para auxiliar o desenvolvimento de componentes e vice e versa (Szyperski, 1997). 2.6. Conclusão Um dos principais objetivos da engenharia de software é o reuso. Através da reutilização de software obtém-se o aumento da qualidade e redução do esforço de desenvolvimento. Frameworks possibilitam o desenvolvimento de família de aplicações, geradas a partir de uma estrutura que captura os conceitos mais gerais das aplicações. São encontradas na literatura várias definições de frameworks. A usada nesta dissertação é a de Buschmann et al (1996), Pree (1995) e Pinto (2000) na qual um framework é um software parcialmente completo projetado para ser instanciado. Isto define uma arquitetura para uma família de subsistemas e oferece os construtores básicos para criá-los. Também são explicitados os pontos de extensão nos quais adaptações do código para um funcionamento específico de certos módulos devem ser feitas. Frameworks podem ser classificados segundo Fayad et al (1999a), (1999b) e (2000) em framework de aplicação orientado a objetos ou segundo Szyperski (1997) em framework de componentes. O primeiro define uma estrutura para o desenvolvimento de aplicações orientadas a objetos enquanto que o segundo define uma infra-estrutura de execução onde componentes podem ser plugados. Frameworks de aplicação podem ser classificados quanto ao seu escopo como frameworks de infra-estrutura, que simplificam o desenvolvimento de sistemas de infra-estrutura portáveis e eficientes, de integração de middleware, usados para integrar aplicações e componentes distribuídos, e de aplicações corporativas, voltados para um domínio de aplicação específica. Ao longo desta dissertação é apresentado como frameworks de aplicação, em especial frameworks de infra-estrutura, podem ser combinados para fornecer uma infraestrutura com serviços de gerenciamento de persistência de objetos, controle de transações, etc. para um groupware. Frameworks de aplicação podem ainda ser classificados quanto ao seu uso como frameworks caixa branca, que exige um bom conhecimento da estrutura Capitulo 2. Frameworks: Conceitos Gerais 44 interna do framework por parte do usuário do framework, caixa preta, que é menos flexível que o framework caixa branca, mas possibilita o seu uso sem que o desenvolvedor precise conhecer a estrutura interna do framework, e caixa cinza, que tenta combinar as vantagens dos frameworks caixa branca e preta. Há três papéis envolvidos no uso e desenvolvimento de frameworks: o projetista do framework, responsável pela estrutura interna do framework, pelo levantamento de requisitos e pela definição dos pontos de extensão; o mantenedor do framework, responsável por redefinir e acrescentar novas funcionalidades ao projeto do framework e o desenvolvedor de aplicações que instancia o framework. Nesta dissertação os frameworks são analisados sobre a ótica do desenvolvedor de aplicações. O desenvolvimento com frameworks traz benefícios. Frameworks diminuem o esforço para entender e manter a aplicação. Frameworks incentivam o reuso, pois capturam o conhecimento de desenvolvedores em determinado domínio ou aspecto de infra-estrutura ou de integração de middleware. Além disso, frameworks são expansíveis por construção e, por fim, o uso de inversão de controle simplifica o desenvolvimento de aplicações. Ao longo desta dissertação são analisados frameworks de aplicação incorporados à arquitetura técnica do AulaNet 3.0. Estes frameworks são usados para compor uma base de serviços de infra-estrutura sobre a qual groupwares podem ser desenvolvidos. Dessa forma, o desenvolvedor de groupware pode concentrar-se no seu domínio enquanto que os frameworks de infra-estrutura cuidam de aspectos técnicos, como persistência de dados, por exemplo. No capítulo 3 são analisados frameworks para a camada de negócios enquanto que no capítulo 4 são analisados frameworks para a camada de apresentação. Apesar dos benefícios decorrentes do uso de frameworks, também são impostos desafios ao desenvolvimento de frameworks e de aplicações que usem os frameworks. Dentre eles, o esforço de desenvolvimento, imposto aos projetistas de frameworks, a curva de aprendizagem, a integração e a eficiência, que afetam principalmente os desenvolvedores de aplicação, a manutenção e validação e remoção de defeitos, que afetam tanto desenvolvedores de aplicação quanto mantenedores de frameworks e o desafio da falta de padrões que afetam a todos envolvidos no desenvolvimento e uso de frameworks. Capitulo 2. Frameworks: Conceitos Gerais 45 O desafio da curva de aprendizagem é o principal ao considerar as características do AulaNet, pois ele é desenvolvido por alunos de graduação, mestrado e doutorado da PUC-Rio. Além a empresa EduWeb desenvolve customizações no AulaNet para seus clientes. Para lidar com este desafio, é considerada a quantidade de documentação disponível para cada framework além da disponibilidade de suporte. Além disso, é considerada a quantidade de mão de obra disponível no mercado já apta a trabalhar com o framework, eliminando assim o custo com o treinamento, e a quantidade de ferramentas compatíveis disponíveis, pois elas auxiliam o uso do framework, suavizando a curva de aprendizado. Quanto à falta de padrões, sob a ótica do desenvolvedor este não é um desafio crítico, desde que haja uma quantidade de documentação suficiente, mesmo que não padronizada, sobre o framework. Como o AulaNet 3.0 é desenvolvido sem reutilizar o código legado do AulaNet 2.1, sistemas legados não são problema e o desafio da integração se resume a integração com outros frameworks. Para lidar com este desafio, os frameworks são analisados tecnicamente para que a compatibilidade possa ser verificada. Além disso, considera-se o grau de intrusão dos frameworks, pois, quanto menos intrusivos, mais facilmente os artefatos do framework podem ser usados em outro contexto. Quanto ao desafio da eficiência, este não é um problema crítico para o AulaNet. Os principais problemas presentes na arquitetura do AulaNet 2.1 e que levaram à especificação de uma nova arquitetura referem-se à manutenibilidade que ao longo dos anos tornou-se muito custosa. Sendo assim, considera-se que vale a pena sacrificar um pouco a eficiência para ganhar na manutenibilidade. Além disso, como está sendo adotada uma abordagem de desenvolvimento baseada em componentes, um problema crítico de eficiência decorrente do uso de determinado framework em um componente pode ser resolvido substituindo o componente por outro que não use o framework, de maneira pontual sem afetar os outros componentes que obtém eficiência satisfatória. Por fim, é importante lidar com os desafios da manutenção, validação e remoção de defeitos. Frameworks pouco usados correm o risco de serem descontinuados enquanto que frameworks muito usados tendem a permanecer em desenvolvimento, recebendo manutenção e tendo seus erros corrigidos. Isto é Capitulo 2. Frameworks: Conceitos Gerais 46 particularmente verdade em se tratando de frameworks de código aberto onde, mesmo que os projetistas originais do framework decidam não realizar mais manutenção nele, haverá desenvolvedores dispostos a assumir a tarefa. Ao verificar o grau de aceitação de mercado dos frameworks, apenas frameworks de grande aceitação são incorporados à arquitetura do AulaNet 3.0. 3 A Camada de Negócios O objetivo da camada de negócios é implementar a lógica da aplicação, expondo esta lógica para a camada de apresentação ou para outras aplicações clientes remotas, por exemplo, clientes móveis, através de interfaces bem definidas. Alternativas para a implementação da camada de negócios envolvem o modelo de componentes Enterprise JavaBeans (EJB, 2005) e o uso de POJOs (POJO, 2005) com frameworks de infra-estrutura. Neste capítulo, é apresentado um resumo das principais características do framework de componentes Enterprise JavaBeans, focando os serviços de infraestrutura que este oferece e apresentando as vantagens e desvantagens decorrentes do seu uso. Logo depois, são analisados os frameworks de infra-estrutura Hibernate (2005) e Spring (2005), que oferecem serviços de infra-estrutura similares aos do EJB. Por fim, são oferecidos argumentos que fundamentam a escolha de uma arquitetura com POJOs e frameworks de infra-estrutura ao invés de uma arquitetura com Enterprise JavaBeans. 3.1. O Modelo de Componentes Enterprise JavaBeans Enteprise JavaBeans (EJB) é uma tecnologia da Sun Microsystems que possibilita o desenvolvimento de componentes distribuídos para a camada de negócios. EJB é um modelo de componentes, isto é, define uma especificação para a construção de componentes (Szyperski, 1997). Servidores de aplicações compatíveis com a especificação J2EE trazem frameworks de componentes que implementam este modelo. EJB também pode ser classificado como um framework de integração de middleware, pois provê suporte à comunicação remota entre componentes através de RMI-IIOP (2005) e também como framework de infra-estrutura, pois trata aspectos como, por exemplo, persistência, segurança e controle de transações, típicos de infra-estrutura. Capitulo 3. A Camada de Negócios 48 Há 3 tipos de componentes EJB: os beans de sessão (Session Beans), que representam processos síncronos de negócios, os beans de entidade (Entity Beans) que representam entidades persistentes e os beans orientados a mensagem (Message Driven Beans) que representam processos de negócios assíncronos. Esta seção destaca os aspectos de infra-estrutura mais relevantes do EJB. Componentes EJB podem ser distribuídos em várias máquinas virtuais Java, neste caso diz-se que os componentes têm interfaces remotas, ou podem estar contidos na mesma máquina virtual, diz-se que têm interfaces locais. Opcionalmente um componente oferece os dois tipos de interfaces. Cabe ao desenvolvedor do componente programar a classe do bean e as interfaces, sejam elas remotas ou locais. Beans de entidade usam persistência gerenciada pelo bean (bean managed persistency - BMP), onde o próprio desenvolvedor do componente programa o código que persiste os dados, ou persistência gerenciada pelo container (container managed persistency - CMP), onde o container gera o código que persiste os dados. Beans de entidade podem usar relacionamentos gerenciados pelo container (container managed relationship - CMR) onde o container mantém a integridade referencial dos relacionamentos entre beans de entidade. De forma similar, Enterprise JavaBeans oferece suporte às transações gerenciadas pelo bean (bean managed transaction – BMT) e às transações gerenciadas pelo container (container managed transaction – CMT). Com BMT, não aplicável a beans de entidade, o desenvolvedor delimita programaticamente o início e o fim de cada transação. Já com CMT o desenvolvedor declara em um arquivo descritor o escopo das transações. Além destes aspectos, EJB também trata questões relacionadas à segurança. Através do uso da API de segurança do Enterprise JavaBeans, o acesso a um componente ou a um determinado conjunto de operações de um componente pode ser restrito a um grupo de usuários. Este controle é feito de forma declarativa ou de forma programática. Por fim, o container Enterprise JavaBeans é responsável por gerenciar o ciclo de vida das instâncias dos EJBs. Utilizando pool de objetos, o container é capaz de reutilizar instâncias de beans, reduzindo a necessidade de criar novas instâncias e aumentando assim o desempenho da aplicação. O container também Capitulo 3. A Camada de Negócios 49 medeia o acesso aos componentes, evitando problemas decorrentes do acesso simultâneo de várias threads a uma mesma instância de componente. EJB oferece uma série de características que oferecem suporte aos aspectos de infra-estrutura de uma aplicação. O principal objetivo da incorporação de aspectos de infra-estrutura a um framework de componentes é possibilitar que o desenvolvedor de componentes concentre-se no domínio em que ele é especialista (no caso do AulaNet, colaboração) deixando aspectos como persistência de dados, por exemplo, para outros especialistas. EJB consegue em parte atingir estes objetivos. Nas próximas seções são vistas as principais vantagens e desvantagens decorrentes do uso de Enterprise JavaBeans. 3.1.1. Vantagens Decorrentes do Uso de Enterprise JavaBeans Como visto na seção anterior, EJB é um modelo de componentes que também trata de aspectos de infra-estrutura. As principais vantagens do uso de EJB decorrem principalmente da incorporação destes aspectos. O uso tanto de persistência gerenciada pelo container (CMP) quanto de relacionamentos gerenciados pelo container (CMR) em beans de entidade possibilitam que o desenvolvedor concentre-se na lógica de negócio em vez de concentrar-se na tecnologia que persiste os dados. Além do mais, o código da aplicação fica independente do SGBD (sistema de gerenciamento de banco de dados), pois todos os comandos para consultar, salvar, atualizar e remover entidades são gerados pelo container. Além disso, o uso de transações declarativas possibilita que o desenvolvedor de componentes construa o componente sem precisar demarcar transações, incentivando o reuso já que o escopo da transação é determinado sem que seja necessário recompilar o código fonte do componente. O uso de CMT também evita a introdução de erros que surgem decorrentes do esquecimento de sessões com o banco de dados abertas e não confirmadas, já que o container se encarrega disto. Da mesma forma, o uso de segurança declarativa incentiva o reuso, pois o componente é customizado com uma política de segurança mais ou menos rígida, dependendo do escopo onde é usado, sem necessidade de mudanças no código fonte. Capitulo 3. A Camada de Negócios 50 EJB também possibilita que componentes instalados em máquinas virtuais diferentes se comuniquem, de modo que os componentes da camada de negócio de uma aplicação podem ser instalados em máquinas diferentes. Este tipo de distribuição de componentes é útil, por exemplo, nos casos em que um componente reside no mesmo servidor em que está disponível um recurso de que ele necessita (por exemplo, quando um componente precisa acessar um recurso que só aceita conexões locais), no caso de componentes que demandam muito processamento (o componente pode ter um servidor dedicado a ele, não atrapalhando o desempenho dos outros componentes da aplicação) ou quando um componente precisa acessar outro componente do qual os desenvolvedores só tem acesso às interfaces (por exemplo, quando um componente precisa acessar um sistema de cartões de crédito). O uso de Entreprise JavaBeans traz uma série de vantagens relacionadas a aspectos de infra-estrutura porém há uma série de desvantagens inerentes ao seu modelo de componentes, que são discutidas a seguir. 3.1.2. Desvantagens Decorrentes do Uso de Enterprise JavaBeans A principal desvantagem decorrente do uso de EJBs é o grande número de arquivos, incluindo código fonte escrito em Java e descritores XML, que precisam ser mantidos para definir os beans de sessão e de entidade, os tipos de beans mais usados no desenvolvimento de aplicações com EJB. Para desenvolver um destes componentes é preciso pelo menos 3 arquivos de código fonte: a interface do componente, a interface home a classe do componente. Eventualmente, este número pode chegar a 6 arquivos de código fonte, contando apenas as classes previstas na especificação do modelo de componentes EJB. A interface do componente define os serviços prestados pelo componente e pode ser local ou remota. Se a interface do componente for local, ela deverá estender a interface javax.ejb.EJBLocalObject, se for remota deverá estender a interface javax.ejb.EJBObject. A interface home é responsável por criar instâncias de componentes ou localizar instâncias existentes, no caso de beans de entidade. A interface home é definida como local ou remota, de acordo com a definição da interface do Capitulo 3. A Camada de Negócios 51 componente. Se a interface home do componente for local, ela deverá estender a interface javax.ejb.EJBLocalHome, se for remota deverá estender a interface javax.ejb.EJBHome. A classe do componente encapsula as regras de negócio e implementa também a interface javax.ejb.SessionBean no caso de beans de sessão ou a interface javax.ejb.EntityBean no caso de beans de entidade. A classe do componente pode, mas não é obrigada a implementar a interface do componente (a local ou a remota, sendo impossível implementar as duas). Se o desenvolvedor de componentes optar por desenvolver a classe do componente sem implementar a interface do componente, a sincronização entre interface e implementação deve ser realizada manualmente sem o suporte da linguagem Java, o que pode resultar em erros. Por outro lado, se o desenvolvedor de componentes optar por desenvolver a classe do componente implementando a interface do componente, ele deverá implementar os métodos definidos nas interfaces EJBObject, se o componente for remoto, ou EJBLocalObject, se o componente for local. A implementação destes métodos nunca é executada, pois eles são sobrescritos pelo container em tempo de implantação. A classe do componente deve ainda implementar métodos de callback definidos na especificação do EJB, como o ejbCreate e o ejbPostCreate por exemplo. Além destes arquivos, no caso de beans de entidade com chave primária composta é preciso mais uma classe para representar esta chave. Todos os enterprise beans também precisam ser acompanhados de um arquivo descritor em formato XML, onde são declaradas as regras de transação, segurança, etc. Dependendo do servidor de aplicações usado, podem ser necessários outros descritores, onde são declaradas regras como o mapeamento de beans de entidade em tabelas do banco de dados, mapeamento de beans orientado a mensagens ao dispositivo de mensagem entre outros. Esta grande quantidade de arquivos traz problemas de manutenção. Esta desvantagem pode ser em parte amenizada pelo uso de ferramentas como o XDoclets (2005), porém permanece sendo uma solução mais complexa do que usar uma interface Java e uma classe que a implementa. Além da grande quantidade de arquivos que precisam ser mantidos, componentes Enterprise JavaBeans precisam ser executados dentro de um container EJB. Isto implica em um leque de opções menor na hora de escolher o Capitulo 3. A Camada de Negócios 52 servidor de aplicações. Alguns servidores populares como o Tomcat (2005) não podem ser usados, pois não possuem container EJB e servidores comerciais que possuem container EJB em geral são mais caros. Além disso, os componentes EJB são dependentes do container, com diversos métodos de callback chamados pelo container EJB ao longo de seu ciclo de vida. Desta forma, componentes EJB são mais difíceis de testar unitariamente, pois precisam estar em execução dentro do container para serem testados. No caso de componentes com interfaces locais, o próprio código de teste deve ser implantado junto com o componente para que este possa ser testado. No capítulo 25.1.2 da especificação do EJB 2.1 (EJB, 2003) são descritas várias restrições impostas aos componentes EJB, como por exemplo, proibição de escrita ou leitura de arquivos no disco, do uso de campos estáticos não finais e do uso da palavra reservada this como referência para a instância do componente em um método, seja como parâmetro ou valor de retorno. Estas restrições se seguidas rigorosamente impossibilitam a realização de atividades corriqueiras como, por exemplo, escrita de arquivos de logs para auditoria ou a implementação do padrão de projeto Singleton (Gamma et al., 1995). Além disso, desenvolvedores Java estão habituados a usar this para referenciar a instância do componente e podem ser introduzidos erros de programação decorrentes deste hábito. Todavia na prática, servidores de aplicação como o JBoss (2005) costumam relaxar algumas destas restrições para possibilitar operações como o log de ações. O uso de EJBs na camada de negócio ao mesmo tempo que traz vantagens por tratar aspectos de infra-estrutura traz uma série de desvantagens expostas nesta seção. Em novembro de 2005, a especificação corrente do EJB era a 2.1, porém a especificação 3.0 estava em desenvolvimento, aberta ao público para discussões. 3.1.3. O Futuro do Enterprise JavaBeans Apesar da especificação da versão 3.0 do Enterprise JavaBeans ainda não estar completamente definida, a tendência que pode ser percebida através das especificações desta nova versão é tornar o desenvolvimento com EJB menos complexo. Através do uso de anotações, um recurso inserido no J2SE 1.5 que Capitulo 3. A Camada de Negócios 53 provê suporte a meta-informação no código fonte, o número de arquivos que precisam ser mantidos tende a diminuir. Nota-se também que o criador do framework Hibernate, Gavin King, é membro do grupo de especialistas da especificação 3.0 do EJB (JSR 220, 2005) e tem exercido influência, tornando o modelo dos beans de entidade mais similar ao modelo de POJOs usado no framework Hibernate. Além disso, um suporte a Dependency Injection similar ao do framework Spring, porém mais limitado, está previsto na especificação (Johnson, 2004). Levará um tempo considerável até que seja viável usar EJB 3.0 em projetos. É preciso esperar que a especificação final seja lançada, que os servidores de aplicação tornem-se compatíveis com a especificação e que as instituições se atualizem com esta nova tecnologia. Deve-se considerar também que as versões das especificações anteriores do EJB frustraram arquitetos e desenvolvedores devido à sua complexidade e que, mesmo que a nova versão amenize os problemas legados, será preciso reconquistá-los (Johnson, 2004; Fowler, 2002; Tate et al., 2003; Sharp et al., 2002). 3.2. Uma Arquitetura Usando POJOs Enquanto o futuro do EJB permanece incerto, uma arquitetura que utilize POJOs (Plain Old Java Objects) em conjunto com frameworks de infra-estrutura é mais adequada para uso no AulaNet 3.0. O framework Hibernate (2005) provê o mapeamento de POJOs em tabelas de bancos de dados, fornecendo uma funcionalidade similar a dos beans de entidade com persistência e relacionamentos gerenciados pelo container e (CMP/CMR). Já o framework Spring (2005) complementa o Hibernate fornecendo a POJOs serviços de gerenciamento de transações, gerenciamento de segurança declarativa e exportação de serviços remotos, além de outras vantagens não presentes no EJB. Em conjunto estes dois frameworks têm a maior parte das vantagens trazidas pelo EJB, eliminando a maior parte das desvantagens (Johnson, 2004). Nas próximas seções são analisadas com mais detalhes as questões decorrentes do mapeamento de objetos em tabelas de banco de dados e como o framework Hibernate trata destas questões provendo funcionalidades similares às Capitulo 3. A Camada de Negócios 54 dos beans de entidade para uma arquitetura de POJOs. Posteriormente é visto como o framework Spring prove um conjunto de funcionalidades possibilitando o uso de segurança, transações declarativas e exposição de serviços remotos. 3.3. Questões Decorrentes do Mapeamento Objetos em Tabelas Quase todo tipo de aplicação requer que seus dados sejam persistidos de alguma forma. Um sistema de gerenciamento de banco de dados (SGBD) relacional não é especifico para Java tampouco destinado para uma aplicação específica. A tecnologia relacional provê uma forma de compartilhar dados entre aplicações diferentes e entre tecnologias diferentes usadas em uma mesma aplicação, por exemplo, um sistema gerador de relatórios e um sistema de gerenciamento de cadastro. Devido a estas características, os SGBDs são o meio de persistir dados das entidades de negócios mais utilizado em aplicações (King & Bauer, 2005). Quando a tecnologia envolvida é Java, a forma mais baixo nível que esta plataforma oferece para enviar comandos ao SGBD é através da API Java DataBase Connectivity (JDBC, 2005). Através do JDBC uma aplicação Java é capaz de enviar comandos SQL para um SGBD e assim realizar operações de consulta, atualização, inserção e remoção de dados. O código JDBC fica responsável por realizar a conversão dos dados provenientes do SGBD em classes orientadas a objeto escritas em Java. Escrever código de acesso a banco de dados, realizando as conversões necessárias do paradigma relacional para o paradigma OO é uma tarefa onerosa, repetitiva e algumas vezes propensa a erros devido à diferença entre estes paradigmas. Para entender o framework Hibernate, é preciso antes entender o conflito dos paradigmas OO e relacional, que ele se propõe a mediar. 3.3.1. Conflito de Paradigmas: Orientação a Objetos x Relacional Ao migrar de um paradigma para outro surgem questões que devem ser resolvidas. Dentre elas, as principais são: a questão dos subtipos, a questão da igualdade, as questões dos relacionamentos e a questão do grafo de navegações Capitulo 3. A Camada de Negócios 55 (King & Bauer, 2005). Esta seção não se propõe a apresentar as soluções destas questões, mas apenas apresentá-las. Posteriormente, é mostrado como o Hibernate trata destas questões. A questão dos subtipos surge, pois o paradigma OO possibilita que classes herdem de outras classes, podendo compor modelos complexos através de herança. Os sistemas de gerenciamento de banco de dados relacionais não oferecem suporte a heranças entre tabelas. A questão de igualdade surge quando é necessário verificar se um objeto é igual ao outro. Em Java, há duas maneiras de verificar a igualdade de objetos: através do conceito de identidade de objetos, que define que um objeto é igual ao outro se ambos ocupam o mesmo espaço de memória (é checado com o operador de igualdade ‘a == b’) e através do conceito de equivalência de objetos, que é determinada através do método equals() quando este é implementado (é checado através de ‘a.equals(b)’). No paradigma relacional a identidade de uma linha de uma tabela é definida através do valor da chave primária. Relacionamentos em linguagens OO são expressos através de referências a objetos ou coleções de referências a objetos. Já no paradigma relacional os relacionamentos são expressos na forma de chaves estrangeiras. As questões dos relacionamentos surgem a partir das diferenças destas duas formas de representar relacionamentos. Relacionamentos no paradigma OO são direcionais, ou seja, são definidos de uma classe para outra. Para criar um relacionamento bidirecional no paradigma OO é preciso definir dois relacionamentos unidirecionais, um em cada uma das classes envolvidas. A noção de direção em relacionamentos não existe no paradigma relacional. Além disto, classes no paradigma OO, podem ser definidas tendo relacionamentos com multiplicidades um-para-um, um-para-muitos ou muitos-para-muitos enquanto que no paradigma relacional os relacionamentos entre tabelas são sempre um-para-muitos, definidos usando chaves estrangeiras, ou um-para-um, definidos usando chaves estrangeiras únicas. Relacionamentos muitos-para-muitos são feitos através de uma tabela extra, chamada tabela de ligação (link table) que não aparece no modelo OO. Finalmente, há a questão do grafo de navegações. O diagrama UML da Figura 3.1 apresenta duas classes: a classe Message, representando uma mensagem que possui uma propriedade text que armazena o texto da mensagem e Capitulo 3. A Camada de Negócios 56 a classe User com duas propriedades, username que representa a identificação do usuário e name, que representa o nome do usuário. A classe Message tem um relacionamento unidirecional com multiplicidade um-para-um com a classe User. User Message -text:String +getAuthor():User +setAuthor(user:User):void +getText():String +setText(text:String)void 1 -username:String 1 -name:String +getUsername():String +setUsername(username:String):void +getName():String +setName(name:String):void Figura 3.1 – Diagrama de Classes que Exemplifica a Questão do Grafo de Navegação Em um paradigma orientado a objetos, a forma natural de acessar dados em objetos relacionados é através da técnica onde se navega de um objeto para outro usando o operador de navegação. Por exemplo, em Java para obter o nome do autor de uma mensagem realiza-se a seguinte operação sobre um objeto do tipo Message: message.getAuthor().getName(). Entretanto, esta não é a forma mais eficiente de recuperar dados em um SGBD relacional e pode levar ao problema conhecido como “n + 1 select problem” (King & Bauer, 2005) onde para cada navegação no grafo de objetos é realizada uma consulta na base de dados. Recuperar o grafo inteiro de objetos de uma só vez implicará em problemas de performance e escalabilidade, que tornam-se mais evidentes à medida que a massa de dados da base aumenta e os relacionamentos entre os objetos tornam-se mais complexos. A questão do grafo de navegação envolve então equilibrar estes fatores, determinando qual porção do grafo de navegação deve ser recuperada imediatamente e qual deve ser recuperada sob demanda. Muitas questões devem ser consideradas quando é preciso converter um objeto em tabelas. Esta tarefa é repetitiva, propensa a erros e independente do domínio da aplicação, portando é susceptível à aplicação de frameworks de infraestrutura. O modelo de componentes EJB, visto na seção 3.1, soluciona algumas destas questões com os beans de entidade. Outras questões, como o mapeamento de subtipos, não são tratadas. Nas próximas seções é visto como Frameworks de mapeamento objeto/relacional (Object/Relational Mapping – ORM) como o Hibernate tratam estas questões. Capitulo 3. A Camada de Negócios 57 3.4. Frameworks ORM Mapeamento objeto/relacional (object/relational mapping – ORM) é o nome dado para a persistência automática e transparente de classes de uma aplicação em tabelas de bancos de dados relacionais, transformando a representação de dados de um paradigma para o outro (King & Bauer, 2005). Um framework ORM é um framework de infra-estrutura que fornece serviços de ORM. Mark Fussel (1997), um pesquisador no campo da ORM, define quatro níveis de maturidade para soluções ORM: relacional puro (pure relational), mapeamento leve (light object mapping), mapeamento médio (medium object mapping) e mapeamento completo (full object mapping). Em soluções relacionais puras, a aplicação inteira, incluindo a interface com o usuário, é afetada pelo modelo relacional e por operações envolvendo acesso direto à base de dados relacional com JDBC e SQL. Esta solução pode ser adequada para sistemas pequenos onde um baixo grau de reuso de código é tolerado. Cada consulta SQL pode ser ajustada para se obter melhor performance, o que afeta a manutenabilidade. Está é a solução utilizada na arquitetura do AulaNet 2.1. Com soluções de mapeamento leve, classes são mapeadas manualmente em tabelas relacionais. O código SQL/JDBC responsável pela persistência das classes é isolado da lógica de negócios através do uso de padrões de projeto bem conhecidos como o Data Access Object (DAO) (Alur et al., 2001). Esta solução é adequada para aplicações de porte pequeno, com um pequeno número de entidades. Soluções de mapeamento médio são desenvolvidas ao redor de um modelo de objetos. O código SQL responsável pela persistência dos objetos é gerado automaticamente em tempo de compilação por uma ferramenta ou em tempo de execução pelo framework ORM. Este nível de solução oferece suporte a relacionamento entre objetos e fornece uma linguagem orientada a objetos para realização de consultas. Esta solução é adequada para aplicações de médio porte, principalmente quando a aplicação deve permanecer independente dos SGBDs. É Capitulo 3. A Camada de Negócios 58 o nível de maturidade atingido pelos beans de entidade da especificação 2.1 do EJB. Já soluções de mapeamento completo oferecem suporte a modelos complexos de objetos, envolvendo composição e herança. A persistência é transparente, ou seja, as classes persistidas não herdam de uma classe ou implementam uma interface do framework. Além disso, o framework implementa estratégias de otimização, como por exemplo o cache de entidades. É o nível de maturidade atingido pelo Hibernate, utilizado na arquitetura do AulaNet 3.0. Uma solução ORM com mapeamento completo consiste de 3 módulos principais: uma API para realização de operações de consultas, atualizações, inserções e remoção de objetos de classes persistentes; uma linguagem ou API para especificação de consultas referentes a classes e a propriedades de classes; um recurso para especificação de metadados de mapeamento de objetos. A próxima seção apresenta o Hibernate como exemplo deste tipo de solução. 3.4.1. O Framework Hibernate Hibernate é um framework ORM adotado na arquitetura do AulaNet 3.0 para persistir os objetos de negócio. Hibernate fornece mapeamento completo (Fussel, 1997) e, ao contrário do EJB, trata de todas as questões relativas ao mapeamento de objetos em tabelas levantadas na seção 3.3.1. Através da API do Hibernate são realizadas operações de inserção, atualização, remoção e consulta de objetos, e através da linguagem de consulta do Hibernate (Hibernate Query Language - HQL), consultas mais complexas são realizadas. Os metadados de mapeamento de objetos são definidos em arquivos XML. 3.4.1.1. Hibernate - Um Exemplo Prático Para melhor compreensão do Hibernate esta seção apresenta um exemplo prático que ilustra o seu funcionamento. O modelo de objetos a ser persistido escolhido é o mesmo apresentado na figura 3.1, com algumas alterações para tornar o exemplo mais ilustrativo: O campo id, identificador único do objeto, é Capitulo 3. A Camada de Negócios 59 acrescentado em ambas as classes e o campo date, data da mensagem, é acrescentado na classe Message. O diagrama modificado é exibido na Figura 3.2. Message User -id:Long -text:String -date:Date +getId():Long +setId(id:Long):void +getAuthor():User +setAuthor(user:User):void +getText():String +setText(text:String):void +getDate():Date +setDate(date:Date):void 1 -id:Long -username:String 1 -name:String +getId():Long +setId(id:Long):void +getUsername():String +setUsername(username:String):void +getName():String +setName(name:String):void Figura 3.2 – Diagrama UML de Classes Persistidas no Exemplo A implementação das classes Message e User é realizada usando POJOs, sem quaisquer dependências com classes ou interfaces da API do Hibernate. A Listagem 3.1 exibe o código fonte da classe Message e a Listagem 3.2 exibe o código fonte da classe User. 01: public class Message { 02: 03: 04: 05: private Long id; private String text; private Date date; private User author; 06: 07: public void setId(Long newValue) { id = newValue; } public Long getId() { return id; } 08: 09: public void setText(String newValue) { text = newValue; } public String getText() { return text; } 10: 11: public void setDate(Date newValue) { date = newValue; } public Date getDate() { return date; } 12: 13: public void setAuthor(User newValue) { author = newValue; } public User getAuthor() { return author; } 14: } Listagem 3.1 – Classe Message Capitulo 3. A Camada de Negócios 60 Os trechos entre as linhas 02 e 04 definem as propriedades id, text e date da classe Message. Na linha 05, o relacionamento de mensagem para autor é definido. Os métodos definidos entre as linhas 06 e 13 constituem métodos de acesso para a variável de relacionamento author e para as propriedades id, text e date. 15: public class User { 16: 17: 18: private Long id; private String username; private String name; 19: 20: public void setId(Long newValue) { id = newValue; } public Long getId() { return id; } 21: 22: public void setUsername(String newValue) { username = newValue; } public String getUsername() { return username; } 23: 24: public void setName(String newValue) { name = newValue; } public String getName() { return name; } 25: } Listagem 3.2 – Classe User O trecho entre as linhas 16 e 18 definem as propriedades id, username e name enquanto que os trechos entre as linhas 19 e 24 definem os métodos de acesso para estas propriedades. O próximo passo é configurar o Hibernate. A configuração do Hibernate pode ser feita de três formas: através de um arquivo de propriedades chamado hibernate.properties, instalado no classpath da aplicação, através de um arquivo XML chamado hibernate.cfg.xml, também deve instalado no classpath da aplicação, ou através da API do Hibernate. A Listagem 3.3 mostra um exemplo do arquivo XML de configuração do Hibernate. Capitulo 3. A Camada de Negócios 61 26: <?xml version='1.0' encoding='utf-8'?> 27: <!DOCTYPE hibernate-configuration 28: PUBLIC "-//Hibernate/Hibernate Configuration DTD//EN" 29: "http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd"> 30: <hibernate-configuration> 31: <session-factory> 32: <property name="show_sql">true</property> 33: <property name="connection.datasource"> 34: java:/comp/env/jdbc/AulaNetDB 35: </property> 36: <property name="dialect">net.sf.hibernate.dialect.MySQLDialect</property> 37: <!-- Mapping files --> 38: <mapping resource="Message.hbm.xml"/> 39: <mapping resource="User.hbm.xml"/> 40: </session-factory> 41: </hibernate-configuration> Listagem 3.3 – Arquivo hibernate.cfg.xml de Configuração do Hibernate O trecho entre a linha 26 e 29 define o esquema do documento XML, para que ele possa ser validado por ferramentas de parser. A linha 31 inicia a seção que configura um SessionFactory, classe que será explicada mais adiante. Na linha 32 a propriedade show_sql é definida com o valor true. Desta forma, o código SQL gerado pelo Hibernate será logado. Esta opção é útil para fins didáticos e para ajustes de performance. O DataSource, que provê conexões com o banco de dados, é configurado no trecho entre as linhas 33 e 35. Na linha 36 o dialeto do Hibernate é configurado. Através do dialeto, o Hibernate gera comandos SQL para diversos tipos de bancos de dados relacionais. Por último, nas linhas 38 e 39 é definido o nome dos arquivos de metadados de mapeamento para, respectivamente, as classes Message e User. Através destes arquivos o Hibernate realiza o mapeamento de objetos em tabelas. A Listagem 3.4 mostra o arquivo responsável pelo mapeamento da classe User. Capitulo 3. A Camada de Negócios 62 42: <?xml version='1.0' encoding='utf-8'?> 43: <!DOCTYPE hibernate-configuration 44: PUBLIC "-//Hibernate/Hibernate Configuration DTD//EN" 45: "http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd"> 46: <hibernate-mapping> 47: <class name="User" table="TBL_USER"> 48: <id name="id" 49: column="USR_ID" 50: type="long"> 51: <generator class="native"/> 52: </id> 53: 54: 55: 56: 57: <property name="username" type="string" column="USRNAME" length="50" not-null="true"/> 58: <property name="name" 59: type="string" 60: column="NAME" 61: length="100"/> 62: </class> 63: </hibernate-mapping> Listagem 3.4 – Arquivo User.hbm.xml de Mapeamento Objeto – Relacional O trecho entre a linha 42 e 45 define o esquema do documento XML, para que ele possa ser validado por ferramentas de parser. A linha 47 indica que este arquivo se refere ao mapeamento da classe User na tabela TBL_USER. Entre as linhas 48 e 52 são definidas as características do identificador do objeto. A linha 48 indica que o nome da propriedade que identifica o objeto é id. A linha 49 indica que esta propriedade é mapeada na coluna USR_ID da tabela TBL_USER Já a linha 50 indica que a propriedade é do tipo long, que o Hibernate converterá para o tipo mais apropriado para a base de dados segundo o dialeto configurado. A linha 51 indica que o Hibernate usa o mecanismo nativo do banco de dados para gerar chaves primárias (campos auto incrementáveis no MySQL, seqüências no Oracle e assim por diante). Entre as linhas 53 e 57 a propriedade username é mapeada para a coluna USRNAME. Nota-se que na linha 56 esta propriedade é definida como tendo tamanho máximo 50 caracteres e que na linha 57 a propriedade é definida como requerida, isto é, não pode receber valor nulo. Estas duas características são usadas pela ferramenta hbm2ddl, usada para gerar o esquema da base de dados Capitulo 3. A Camada de Negócios 63 automaticamente. Por fim, o trecho entre as linhas 58 e 61 define o mapeamento da propriedade name na coluna NAME de tamanho máximo 100 caracteres. A Listagem 3.5 descreve o arquivo responsável pelo mapeamento da classe Message. 64: <?xml version='1.0' encoding='utf-8'?> 65: <!DOCTYPE hibernate-configuration 66: PUBLIC "-//Hibernate/Hibernate Configuration DTD//EN" 67: "http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd"> 68: <hibernate-mapping> 69: <class name="Message" table="TBL_MESSAGE"> 70: <id name="id" 71: column="MSG_ID" 72: type="long"> 73: <generator class="native"/> 74: </id> 75: <property name="text" 76: type="string" 77: column="MSG_TXT"/> 78: <property name="date" 79: type="date" 80: column="MSG_DATE"/> 81: 82: 83: 84: 85: <many-to-one name="author" class="User" column="AUTHOR_ID" not-null="true" cascade="save-update"/> 86: </class> 87: </hibernate-mapping> Listagem 3.5 - Arquivo Message.hbm.xml de Mapeamento Objeto – Relacional Neste arquivo a classe Message é mapeada na tabela TBL_MESSAGE (linha 69). O arquivo também define o identificador com nome id e tipo long, mapeado na coluna MSG_ID (trecho entre as linhas 70 e 74), a propriedade text do tipo string mapeada na coluna MSG_TXT (trecho entre as linhas 75 e 77) e a propriedade date do tipo date, mapeada na coluna MSG_DATE (trecho entre as linhas 78 e 80). O trecho entre as linhas 81 e 85 define o relacionamento entre as classes Message e User. Apesar de ser um relacionamento um-para-um, ele é definido como muitos-para-um, pois a classe Message não é capaz de determinar a cardinalidade do lado “User” do relacionamento. O nome da propriedade da classe Capitulo 3. A Camada de Negócios 64 Message que referencia a classe User é listado na linha 81. A classe User, com a qual a classe Message se relaciona, é definido na linha 82. O campo AUTHOR_ID definido na linha 83 indica que este é o nome da chave estrangeira armazenada na tabela TBL_MESSAGE, que referencia a tabela TBL_USER. O atributo not-null é definido como true na linha 84 indica que o relacionamento é obrigatório. Por fim, o atributo cascade é configurado com o valor “save-update” na linha 83, indicando que as operações de inserção e atualização de entidades devem ser realizadas também para as instâncias relacionadas. Com todas as configurações feitas, o próximo passo é usar a API do Hibernate para realizar as operações de inserção, atualização, consulta e remoção, também conhecidas com operações CRUD (Creation, Retrieval, Update, Deletion). A Listagem 3.6 exibe um exemplo de operação de inserção de um objeto persistente. 088: public class CRUDOperations01 { 089: 090: 091: 092: 093: 094: 095: 096: 097: 098: 099: 100: 101 public static void main(String[] args) { SessionFactory sfactory = null; Session sess = null; Transaction tx = null; try { sfactory = new Configuration().configure().buildSessionFactory(); sess = sfactory.openSession(); tx = sess.beginTransaction(); User usr = new User(); usr.setUsername("johnd"); usr.setName("John Doe"); Message msg = new Message(); msg.setText("Test message"); msg.setDate(new Date()); msg.setAuthor(usr); 102: sess.save(message); 103: tx.commit(); 104: sess.close(); 105: } catch (Exception e) { 106: try { 107: tx.rollback(); 108: sess.close(); 109: } catch (HibernateException e1) { } 110: e.printStackTrace(); 111: } 112: } 113: } Listagem 3.6 – Operação de Criação com o Hibernate Capitulo 3. A Camada de Negócios 65 Na linha 091 uma variável do tipo Session é declarada. A interface net.sf.hibernate.Session é a principal interface da API do Hibernate. A sessão do Hibernate, também chamada de gerenciador de persistência, pode ser vista como um gerenciador de objetos relacionados a uma mesma unidade de trabalho. A sessão é capaz de inserir, consultar, atualizar e remover objetos assim como detectar mudanças nos objetos pertencentes à unidade, atualizando seus estados persistentes quando a sessão é fechada. A sessão é um objeto leve, ou seja, não ocupa muito espaço em memória e não leva muito tempo para ser criado e destruído. Geralmente a sessão possui um tempo de vida curto. Na linha 090 uma variável do tipo SessionFactory é declarada. A interface net.sf.hibernate.SessionFactory define como objetos de sessão são criados. Este é um objeto pesado quando comparado com a sessão, mas a aplicação só precisa criar uma instância deste para cada base de dados. Uma variável do tipo Transaction é declarada na linha 092. A interface net.sf.hibernate.Transaction representa uma abstração de transações. Através desta interface podem ser usadas transações JDBC, JTA (2005), etc. O objeto SessionFactory é instanciado na linha 094. A partir deste objeto, a sessão do Hibernate é criada na linha 095. A transação é iniciada na linha 096 a partir da sessão. Entre as linhas 097 e 100 um objeto Message e um objeto User são criados e inicializados. Na linha 101, o relacionamento entre o objeto Message e o objeto User é configurado. Na linha 102 o objeto é salvo na sessão. Finalmente, a transação é confirmada na linha 103 e a sessão é fechada na linha 104. Como o atributo cascade do relacionamento é definido como save-update (linha 85 da listagem 3.5), o objeto User associado à classe Message também é salvo. O trecho de código entre as linhas 105 e 111 trata eventuais erros que podem ocorrer durante a operação. Para efetuar a atualização de objetos é necessário recuperar o objeto que será atualizado, alterar seu estado e fechar a sessão. A Listagem 3.7 apresenta um exemplo da operação de atualização com o Hibernate. Capitulo 3. A Camada de Negócios 66 114: public class CRUDOperations02 { 115: 116: 117: 118: public static void main(String[] args) { SessionFactory sfactory = null; Session sess = null; Transaction tx = null; 119: try { 120: sfactory = new Configuration().configure().buildSessionFactory(); 121: sess = sfactory.openSession(); 123: tx = sess.beginTransaction(); 124: Message msg = (Message) sess.load(Message.class, new Long(1)); 125: msg.setText("Message text changed!"); 126: tx.commit(); 127: sess.close(); 128: } catch (Exception e) { 129 try { 130: tx.rollback(); 131: sess.close(); 132: } catch (HibernateException e1) { } 133: e.printStackTrace(); 134: } 135: } 136: } Listagem 3.7 – Operação de Atualização com o Hibernate A linha 124 mostra um mecanismo usado pelo Hibernate para recuperar instâncias de classes persistidas a partir de sua chave primária. Na linha 125 o texto da mensagem é alterado e na linha 127, quando o objeto Session é fechado, a alteração realizada no objeto é salva, pois ele faz parte da unidade de trabalho gerenciado pela instância da sessão. Embora prático, o mecanismo utilizado na linha 124 para recuperar uma mensagem com um determinado identificador não contempla a maior parte das necessidades reais de consultas. Freqüentemente é necessário realizar consultas em uma aplicação que retornem um objeto ou uma coleção de objetos segundo algum critério. Hibernate possibilita que consultas complexas sejam realizadas através do HQL (Hibernate Query Language). O HQL é de certa forma similar ao SQL, mas agrega conceitos de orientação a objetos, possibilitando a seleção de objetos em vez de tabelas. A Listagem 3.8 exemplifica uma consulta onde todos os usuários com o primeiro nome “Mark” são selecionados. Capitulo 3. A Camada de Negócios 67 137: public class CRUDOperations03 { 138: 139: 140: 141: 142: 143: public static void main(String[] args) { SessionFactory sfactory = null; Session sess = null; try { sfactory = new Configuration().configure().buildSessionFactory(); sess = sfactory.openSession(); 144: 145: 146: 147: String queryStr = "from User where user.name like ?"; Query qry = sess.createQuery(queryStr); qry.setString(0, "Mark%"); Collection usrs = qry.list(); 148: 149: 150: 151: 152: System.out.println(usrs.size() + " users selected."); for (Iterator i = usrs.iterator(); i.hasNext(); { User u = (User) i.next(); System.out.println(u.getName()); } 153: sess.close(); 154: } catch (Exception e) { 155: e.printStackTrace(); 156: } 157: } 158: } Listagem 3.8 – Operação de Consulta com o Hibernate Usando HQL Nota-se que não há a necessidade de usar transações dado que apenas a consulta é realizada. A string com o comando HQL executado é criada na linha 144. Um parâmetro é usado no lugar para a propriedade name, de modo a tornar a consulta mais genérica. Na linha 145 um objeto Query é criado a partir da sessão. O parâmetro é configurado na linha 146 para que apenas os usuários com nome começando com “Mark” sejam selecionados e a consulta é realizada na linha 147. O trecho de código entre as linhas 148 e 152 imprime o resultado da consulta. Encerrando o exemplo, a Listagem 3.9 apresenta um exemplo de remoção de uma entidade persistente. Capitulo 3. A Camada de Negócios 68 159: public class CRUDOperations04 { 160: 161: 162: 163: public static void main(String[] args) { SessionFactory sfactory = null; Session sess = null; Transaction tx = null; 164: try { 165: sfactory = new Configuration().configure().buildSessionFactory(); 166: sess = sfactory.openSession(); 167: tx = sess.beginTransaction(); 168: Message msg = (Message) sess.load(Message.class, new Long(1)); 169: sess.delete(msg); 170: tx.commit(); 171: sess.close(); 172: } catch (Exception e) { 173: try { 174: tx.rollback(); 175: sess.close(); 176: } catch (HibernateException e1) { } 177: e.printStackTrace(); 178: } 179: } 180: } Listagem 3.9 – Operação de Remoção com o Hibernate Em primeiro lugar é preciso recuperar o objeto que será removido (linha 168). Depois, na linha 169, é chamado o método delete do objeto Session, sinalizando que o objeto recém recuperado deve ser removido. Quando a sessão é encerrada (linha 171) o objeto é efetivamente removido da base de dados. Esta seção exemplificou como realizar operações de inserção, consulta, atualização e remoção de entidades de negócios com o framework ORM Hibernate. Nas próximas seções é mostrado como são tratadas outras questões decorrentes do conflito de paradigmas OO e relacional. 3.4.1.2. Hibernate e a Questão dos Subtipos Como catalogado em Ambler (2002), há três maneiras de representar uma hierarquia de herança em uma linguagem orientada a objetos: usando uma tabela para cada classe concreta, uma tabela por hierarquia de classes e uma tabela por subclasse. O diagrama de classes da Figura 3.3 exemplifica uma hierarquia de herança com uma superclasse User e duas subclasses, Administrator e Learner. Capitulo 3. A Camada de Negócios 69 User -username:String -password:String +setUsername(username:String):void +getUsername():String +setPassword(password:String):void +getPassword():String Administrator Learner - phone:String -email:String +setPhone(phone:String):void +getPhone():String +setEmaile(email:String):void +getEmail():String Figura 3.3 – Diagrama de Classes com Herança. Ao aplicar o mapeamento usando uma tabela para cada classe concreta, são geradas duas tabelas: a tabela ADMINISTRATOR, com as colunas USERNAME, PASSWORD e PHONE além da tabela LEARNER, com as colunas USERNAME, PASSWORD e EMAIL. Os principais problemas desta abordagem são que ela não oferece suporte a consultas com polimorfismo e a dificuldade em manter o esquema das tabelas no banco de dados, já que os atributos da superclasse são replicados em cada tabela. O mapeamento usando uma tabela por hierarquia de classes resulta em uma tabela com todas as propriedades em todas as classes e um identificador que determina o tipo da subclasse a qual a linha da tabela se refere. No exemplo da Figura 3.3, uma tabela seria criada com as propriedades USERNAME, PASSWORD, PHONE, EMAIL E USER_TYPE. A propriedade USER_TYPE é usada para discriminar a qual subclasse cada linha pertence. Esta abordagem possibilita o uso de consultas com polimorfismo e facilita a manutenção, contudo há um problema: os atributos referentes às subclasses não podem ser declarados como não nulos já que a mesma tabela armazena as instâncias das duas subclasses. O mapeamento usando uma tabela por subclasse resulta que cada classe, abstrata ou concreta, seja mapeada em uma tabela. A ligação entre as superclasses e as subclasses é feita através de relacionamentos de chave estrangeira. O mapeamento do modelo descrito na Figura 3.3 resultaria em 3 tabelas: a tabela Capitulo 3. A Camada de Negócios 70 USER, com as propriedades USER_ID, USERNAME e PASSWORD; a tabela ADMINISTRATOR, com as propriedades PHONE e USER_ID, que é chave estrangeira para a tabela USER; a tabela LEARNER, com as propriedades EMAIL e USER_ID, também chave estrangeira. A principal vantagem desta técnica é que ela resulta num modelo relacional normalizado ao mesmo tempo em que possibilita o uso de consultas com polimorfismo. Contudo, é uma técnica mais complexa do que as duas outras anteriormente citadas. O Hibernate possibilita o uso das três técnicas, conforme a necessidade da aplicação. A técnica “uma tabela para cada classe concreta” pode ser aplicada naturalmente, sem que seja preciso qualquer configuração especial nos arquivos de mapeamento do Hibernate. A técnica “uma tabela por hierarquia de classes” é aplicada usando o elemento <subclass> no arquivo de mapeamento enquanto que a técnica “uma tabela por subclasse” é aplicada usando elemento <joinedsubclass>. 3.4.1.3. Hibernate e a Questão da Igualdade Conforme visto na seção 3.3.1, há duas maneiras de representar igualdade em Java: através do conceito de identidade e de equivalência enquanto que no paradigma relacional a igualdade é determinada através de chaves primárias. A identidade de objetos no Hibernate é determinada pelo valor do campo identificador, representado pelo elemento <id> no arquivo de mapeamento, mapeado para uma chave primária de uma tabela. Para checar se dois objetos representam a mesma entidade, pode-se consultar o método de acesso do identificador na classe de negócio (getId() no caso das classes Message e User do exemplo da sessão 3.4.1.1.) ou utilizar o método Session.getIdentifier(Object o). Os identificadores podem ser naturais, com algum significado para o modelo de negócios, ou surrogates, sem significado para a lógica de negócios. O Hibernate fornece várias estratégias usadas para gerar identificadores surrogates, entre eles a estratégia sequence, que utiliza seqüências, incremente, que utiliza campos auto incrementáveis e uuid.hex, que gera um identificador único, mesmo quando ocorre processamento paralelo em várias máquinas. Capitulo 3. A Camada de Negócios 71 3.4.1.4. Hibernate e as Questões dos Relacionamentos O Hibernate possibilita o uso de relacionamentos unidirecionais ou bidirecionais, com cardinalidade um-para-um, um-para-muitos ou muito-paramuitos. Há várias formas de mapear relacionamentos com o Hibernate e descrever todas seria excessivamente complexo e fugiria ao escopo desta dissertação. Contudo, o exemplo da seção 3.4.1.1. exemplifica o uso de relacionamentos direcionais um-para-um. O Hibernate impõe uma limitação em classes com relacionamentos com cardinalidade de muitos: a variável do relacionamento deve ser determinada em função da interface da coleção em vez da classe concreta. Por exemplo, a interface java.util.List deve ser usada em vez da classe java.util.LinkedList. O Hibernate usa sua própria implementação de coleções, que oferece recursos como, por exemplo, busca tardia, que é vista na próxima seção. Esta limitação, contudo não é um problema já que programar para interfaces é uma conhecida boa prática de programação (Bloch, 2002). 3.4.1.5. Hibernate e a Questão do Grafo de Navegação Uma das principais questões em ORM é fornecer acesso eficiente a uma base de dados relacional através de um grafo de objetos (King & Bauer, 2005). Conforme visto na seção 3.3.1., é importante determinar a porção do grafo de objetos recuperada em cada consulta. Para lidar com esta questão, Hibernate define quatro estratégias possíveis de busca que podem ser usadas em quaisquer relacionamentos: busca imediata (immediate fetching), busca tardia (lazy fetching), busca antecipada (eager fetching) e busca em lote (batch fetching). Com a estratégia da busca imediata, logo que uma entidade é recuperada da base de dados a entidade do relacionamento é recuperada através de uma consulta à base de dados ou então ao cache de entidades. Esta estratégia não costuma ser eficiente a não ser que as entidades relacionadas estejam quase sempre no cache. A estratégia de busca tardia possibilita que a entidade relacionada seja recuperada sob demanda, apenas quando for necessário consultá-la. A busca tardia é um conceito fundamental para que uma performance adequada seja alcançada. Capitulo 3. A Camada de Negócios 72 Com a estratégia de busca antecipada, as entidades relacionadas são recuperadas em uma mesma consulta através do uso do comando SQL OUTER JOIN. Otimizações em uma aplicação que usa Hibernate geralmente envolvem a configuração de relacionamentos, escolhendo a estratégia de busca antecipada para classes que quase sempre são usadas em conjunto. A estratégia de busca em lote é uma técnica que pode aumentar a performance de relacionamentos com a estratégia de busca tardia ou imediata. Usualmente, ao recuperar um objeto da base de dados, uma consulta SQL é realizada com uma cláusula WHERE, especificando o identificador do objeto recuperado. Se a estratégia da busca em lote for usada, sempre que uma consulta for realizada, o Hibernate procura por outros objetos na mesma unidade de trabalho da sessão recuperáveis usando a mesma consulta, mas com valores múltiplos para a cláusula WHERE. Quase sempre a estratégia de busca tardia é mais eficiente que esta estratégia, porém a busca em lote é mais adequada para usuários do Hibernate que não desejam ou não podem usar seu tempo para ajustar a aplicação com uma combinação de busca tardia e antecipada. Como visto nesta seção, o Hibernate fornece os meios para a resolução da questão do grafo de navegação, porém cabe ao desenvolvedor configurar os atributos dos relacionamentos na aplicação de forma a obter uma performance satisfatória. 3.4.1.6. Considerações Finais Sobre o Hibernate Hibernate possibilita o uso de persistência de POJOs de uma forma similar aos beans de entidades do EJB. Hibernate oferece vantagens sobre EJB. Hibernate é uma solução de mapeamento completo enquanto que os beans de entidade de EJB oferecem mapeamento médio (Fussel,1997). Por outro lado, EJB oferece outros serviços de infra-estrutura como, por exemplo, transações gerenciadas pelo container. Na seção 3.5 é visto como o Hibernate aliado ao Spring oferece também estes serviços. Há outros frameworks ORM além do Hibernate disponíveis no mercado. Alguns gratuitos, outros comercias. A próxima seção apresenta um apanhado Capitulo 3. A Camada de Negócios 73 destes frameworks, justificando a escolha do Hibernate para a arquitetura do AulaNet 3.0. 3.4.2. Outros Frameworks ORM Segundo o artigo Object Relational tool comparision disponível em http://c2.com/cgi/wiki?ObjectRelationalToolComparison há cerca de 29 frameworks ORM disponíveis para Java atualmente, 14 deles são comerciais enquanto que 15 são gratuitos. Como o AulaNet é distribuído gratuitamente, os frameworks ORM comerciais são imediatamente descartados. Dentre os 15 frameworks ORM gratuitos, 7 exigem que as classes persistidas estendam alguma classe ou implemente alguma interface, resultando em um forte acoplamento entre as classes do modelo e o framework, por isto também são descartados. Entre os restantes, apenas o Hibernate (2005), iBATIS (2005), Apache OJB (OJB, 2005) e JDOMax (2005), uma implementação da especificação JDO (2005) são soluções de mapeamento completo. Para confirmar a escolha do Hibernate em face destas outras opções é realizada uma pesquisa, considerando aspectos não técnicos. Raible (2005) realiza uma comparação entre web frameworks, apresentada no capítulo 4, onde são considerados os seguintes itens: quantidade de documentação disponível, disponibilidade de suporte, disponibilidade de ferramentas compatíveis, grau de aceitação no mercado e disponibilidade de profissionais aptos a trabalhar com os frameworks. Nesta seção é feita uma comparação similar, porém entre frameworks ORM. 3.4.2.1. Quantidade de Documentação Disponível Há duas formas de contabilizar a disponibilidade de documentação acessível sobre uma tecnologia: verificando o número de livros publicados sobre a tecnologia ou verificando o número de tutoriais disponíveis na web. O gráfico da Figura 3.4 mostra o número de livros publicados para cada framework ORM segundo uma pesquisa realizada em novembro de 2005 no site da Amazon. Capitulo 3. A Camada de Negócios 74 10 8 6 4 2 0 Apache OJB Hibernate iBATIS JDO Figura 3.4 – Livros Publicados Para Cada Framework ORM Fonte: Amazon.com, Novembro de 2005 Para contabilizar o número de tutoriais disponíveis na web sobre cada framework ORM, é feita uma consulta na ferramenta de busca Google. O resultado da pesquisa realizada em março de 2006 é apresentado no gráfico da Figura 3.5. 100000 80000 60000 40000 20000 0 Apache OJB Hibernate iBATIS JDO Figura 3.5 – Artigos e Tutoriais Para Cada Framework ORM Fonte: Google.com, Março de 2006 Há uma quantidade significativamente maior de documentação disponível para o Hibernate, tanto na forma de livros quanto na forma de tutoriais e artigos com o JDO ocupando a segunda colocação. Capitulo 3. A Camada de Negócios 75 3.4.2.2. Disponibilidade de Suporte É importante que o framework ORM escolhido disponha de suporte para resolver questões não tratadas pela documentação disponível. Os frameworks ORM Apache OJB e iBATIS possuem comunidades ativas que se comunicam através de listas de discussão, trocando informações e provendo suporte gratuito. Para mensurar a disponibilidade de suporte destes frameworks, realiza-se uma pesquisa contabilizando o volume de mensagem trocado nestas listas de discussão em determinado período de tempo. O Hibernate também possui comunidade ativa, mas a troca de mensagem é feita por fórum. Como o fórum não fornece nenhum mecanismo para selecionar as mensagens enviadas em um determinado período de tempo, para mensurar o volume de mensagens trocado foi realizada comunicação pessoal com os administradores do fórum através de e-mail. Estes, que possuem mais privilégios que os usuários comuns, forneceram o número de mensagens trocadas no período especificado. O apêndice A apresenta uma transcrição dos e-mails trocados com os administradores do fórum. O framework JDOMax não possui nenhuma comunidade que ofereça suporte a ele e a única maneira de obter qualquer tipo de auxílio é entrando em contato diretamente com os desenvolvedores. O gráfico da Figura 3.6 mostra o volume de mensagens trocadas nas listas de discussão oficiais das comunidades do Apache OJB e iBATIs e no fórum do Hibernate durante o mês de novembro de 2005. 5000 4000 3000 2000 1000 0 Apache OJB Hibernate iBATIS Figura 3.6 - Mensagens Trocadas em Listas de Discussão (11/2005) Capitulo 3. A Camada de Negócios 76 A comunidade do Hibernate é a mais ativa. Vale ressaltar que o Hibernate é desenvolvido pelo mesmo grupo responsável pelo desenvolvimento do servidor de aplicações JBoss (2005), que também oferece suporte e treinamento comercial. 3.4.2.3. Disponibilidade de Ferramentas Compatíveis Ferramentas compatíveis com um framework ORM auxiliam o desenvolvimento. A ferramenta pode fornecer editores gráficos, automatizar tarefas repetitivas, etc. Para contabilizar o número de ferramentas compatíveis com cada framework ORM foi verificada a quantidade de plugins disponíveis para as plataformas Eclipse e NetBeans, a compatibilidade com as IDEs Java mais populares (IBM WSAD, Sun Java Studio Enterprise, Borland JBuilder, Oracle JDeveloper, BEA Workshop e InteliJ IDEA), a compatibilidade com as ferramentas de produtividade Middlegen e XDoclets além das ferramentas disponíveis nos web sites dos próprios frameworks. A Figura 3.7 mostra o número de ferramentas disponíveis compatíveis com cada framework ORM, conforme pesquisa realizada em novembro de 2005. 15 10 5 0 Apache OJB Hibernate iBATIS JDO Figura 3.7 – Ferramentas Compatíveis com os Frameworks ORM em 11/2005 A pesquisa realizada em novembro de 2005 demonstra que o Hibernate é o framework ORM que possui mais ferramentas compatíveis, com o JDO em segundo lugar. Capitulo 3. A Camada de Negócios 77 3.4.2.4. Grau de Aceitação no Mercado Ao selecionar um framework ORM é necessário realizar uma sondagem no mercado para saber qual tem sido mais requisitado por empresas. Para obter um indicativo do grau de aceitação no mercado para um framework, faz-se uma busca em sites especializados por ofertas de emprego abertas que solicitem desenvolvedores com habilidades em um determinado framework ORM. A Figura 3.8 mostra o resultado da pesquisa realizado no site Dice.com em dezembro de 2005. 600 500 400 300 200 100 0 Apache OJB Hibernate iBATIS JDO Figura 3.8 – Ofertas de Emprego Abertas para cada Framework ORM Fonte: Dice.com, Dezembro de 2005 Segundo a pesquisa o Hibernate é o framework ORM mais solicitado em ofertas de emprego com o JDO em segundo, com uma pequena vantagem sobre o iBATIS em terceiro lugar. Este resultado reflete o estado do mercado norteamericano. Para tomar um indicativo do grau de aceitação dos frameworks ORM no mercado brasileiro apresenta-se uma pesquisa realizada em dezembro de 2005 no site nacional de (http://www.manageronline.com.br/). empregos Manager Online Capitulo 3. A Camada de Negócios 78 20 15 10 5 0 Apache OJB Hibernate iBATIS JDO Figura 3.9 – Ofertas de Emprego Abertas para cada Framework ORM Fonte: Manager Online, Dezembro de 2005 A pesquisa realizada em dezembro de 2005 revela que há pouco mais que 15 vagas abertas requisitando habilidade com o Hibernate e que não há vagas abertas requisitando habilidade com OJB, iBATIS e JDO. 3.4.2.5. Disponibilidade de Profissionais É preciso considerar a disponibilidade de profissionais habilitados no mercado para trabalhar com o framework ORM antes de efetuar uma escolha. A escolha de um framework com poucos profissionais aptos disponíveis no mercado implica em custos de treinamento mais elevados. Para verificar esta disponibilidade faz-se uma consulta em sites que hospedam currículos. A Figura 3.10 mostra o resultado da pesquisa realizada em dezembro de 2005 no site Jobs.net que reflete a realidade do mercado de trabalho norte-americano. Capitulo 3. A Camada de Negócios 79 1500 1250 1000 750 500 250 0 Apache OJB Hibernate iBATIS JDO Figura 3.10 – Disponibilidade de Profissionais Fonte: Jobs.net, Dezembro de 2005 O Hibernate é o framework ORM com mais profissionais aptos no mercado norte-americano. A Figura 3.11 reflete a realidade do mercado brasileiro, obtido através de uma busca no site brasileiro APInfo.com, realizada em dezembro de 2005. 300 250 200 150 100 50 0 Apache OJB Hibernate iBATIS JDO Figura 3.11 - Disponibilidade de Profissionais Fonte: APInfo.com, Dezembro de 2005 O mercado nacional segue o mesmo padrão do mercado norte-americano com o Hibernate sendo o framework ORM com mais profissionais habilitados disponíveis, seguido do JDO. Capitulo 3. A Camada de Negócios 80 3.4.2.6. Resultado da Comparação entre Frameworks ORM A análise mostra que o Hibernate é o framework ORM com mais documentação disponível, incluindo livros publicados e tutoriais disponíveis na web, com mais ferramentas compatíveis e com a comunidade mais ativa. Além disso, a análise mostrou que o Hibernate é o framerwork ORM mais presente tanto em ofertas de empregos quanto nos currículos de candidatos, nos mercados norte-americano e brasileiro. Com isto em vista e dado que o Hibernate atende às necessidades de persistência de dados do AulaNet, ele é incorporado à arquitetura do AulaNet 3.0. Enterprise JavaBeans não é incluído nesta análise por dois motivos: porque ele não é uma solução de mapeamento completo (Fussel,1997) e porque os critérios técnicos já o haviam descartado. Vale lembrar que o EJB também fornece outros serviços de infra-estrutura como, por exemplo, segurança, transações declarativas e exposição de serviços remotos. Na próxima seção é visto como o Spring, incorporado à arquitetura do AulaNet 3.0, complementa o Hibernate fornecendo estes serviços. 3.5. O Framework de Infra-Estrutura Spring Spring é um framework de infra-estrutura adotado na arquitetura do AulaNet 3.0 para complementar o Hibernate. Este Spring oferece os serviços de controle de transações, segurança e exposição de serviços remotos. O Spring também simplifica o desenvolvimento com o Hibernate através do uso de métodos template e contribui para um baixo acoplamento entre as classes da aplicação. O Spring pode ser classificado como um framework de infra-estrutura, pois provê serviços como gerencia de transações e de segurança além de se integrar com frameworks ORM, que fornecem serviços de persistência. Spring também é usualmente chamado de container leve ou “lightweight container” (Walls & Breidenbach, 2005). O termo container é usado, pois Spring gerencia o ciclo de vida dos objetos configurados nele, assim como o container EJB. Porém é considerado um container leve, pois ao contrário do container EJB, ele não é Capitulo 3. A Camada de Negócios 81 intrusivo e as classes da aplicação tipicamente não possuem dependências com o Spring. Spring é um framework dividido em vários módulos usados de acordo com as necessidades da aplicação. Através do seu módulo de Dependency Injection (Fowler, 2004), consegue-se um baixo grau de acoplamento entre as classes da aplicação e através do módulo de programação orientada a aspectos (Aspect Oriented Programming – AOP) (Jacobson & Ng, 2004), pode-se usar AOP sem que seja necessário o aprendizado de uma nova linguagem ou a incorporação de uma nova ferramenta ao projeto. Por fim, o módulo de integração ORM possibilita a integração do Hibernate ao Spring. A subseção a seguir descreve Dependency Injection, o principal conceito por trás do Spring. 3.5.1. Dependency Injection O termo Dependency Injection (Fowler, 2004) é usado para classificar um tipo específico de inversão de controle onde a responsabilidade de configurar dependências entre classes é assumida por um terceiro objeto. Desta forma, atinge-se um acoplamento mais fraco entre as classes e por conseqüência maior reuso. A Figura 3.12 mostra um diagrama de classes com a classe ConferenceFacade, representando o Façade (Gamma et al., 1995) dos serviços da Conferência e a classe MessageDAOImpl e sua interface, que implementam o DAO (Alur et al., 2001) responsável por efetuar as operações de persistência na base de dados. Capitulo 3. A Camada de Negócios 82 dao = new MessageDAOImpl(); <<Interface>> MessageDAO ConferenceFacade messageDAO:MessageDAO ConferenceFacade():void postMessage(m:Message):void listMessages():Message[] createMessage(m:Message):void updateMessage(m:Message):void removeMessage(m:Message):void listMessages():Message[] MessageDAOImpl <<create>> Figura 3.12 – Dependências Configuradas sem Dependency Injection Apesar da classe ConferenceFacade referenciar a interface MessageDAO, ela é dependente da implementação da interface pois precisa instanciá-la para poder usá-la. Através de Dependency Injection, um terceiro objeto denominado Montador (Assembler) é inserido. Este objeto é responsável por instanciar e configurar as dependências das classes relacionadas. A Figura 3.13 exemplifica o mesmo modelo da Figura 3.12, mas desta vez usando Dependency Injection. this.dao = dao; <<Interface>> MessageDAO ConferenceFacade dao:MessageDAO createMessage(m:Message):void updateMessage(m:Message):void removeMessage(m:Message):void listMessages():Message[] ConferenceFacade():void setDAO(dao:MessageDAO):void postMessage(m:Message):void listMessages():Message[] <<create and set>> MessageDAOImpl Assembler <<create>> Figura 3.13 - Dependências Configuradas com Dependency Injection Capitulo 3. A Camada de Negócios 83 Com a introdução do objeto Montador a classe ConferenceFacade passa a depender apenas da interface MessageDAO. O montador é responsável por instanciar a implementação adequada da interface e configurar a dependência da classe ConferenceFacade. Spring e frameworks similares exercem a função do montador no Dependency Injection e como as classes relacionadas dependem apenas das interfaces, o Spring pode passar Decorators ou Proxys (Gamma et al., 1995) acrescentando funcionalidades de infra-estrutura. 3.5.2. Dependency Injection com Spring Para melhor compreensão do Spring esta seção apresenta um exemplo que ilustra o funcionamento do seu módulo de Dependency Injection. Neste exemplo é implementado o modelo de classes apresentado na Figura 3.14. Nas seções seguintes, este exemplo será incrementado através da ilustração do uso de serviços de infra-estrutura com o Spring. Capitulo 3. A Camada de Negócios 84 Message -id:Long -text:String -date:Date +getId():Long +setId(id:Long):void +getText():String +setText(text:String):void +getDate():Date +setDate(date:Date):void ConferenceFacade <<Interface>> MessageDAO dao:MessageDAO setDAO(dao:MessageDAO):void postMessage(m:Message):void listMessages():Message[] createMessage(m:Message):void updateMessage(m:Message):void removeMessage(m:Message):void listMessages():Message[] MessageDAOImpl Figura 3.14 – Modelo de Classes do Exemplo do Spring O modelo da Figura 3.14 corresponde ao modelo da Figura 3.13, com o Spring funcionando como o montador. A classe Message também é acrescentada ao modelo para tornar o exemplo mais ilustrativo. O exemplo desta seção se limita a mostrar o funcionamento básico do módulo de Dependency Injection do Spring. Nas próximas seções este exemplo é incrementado para exemplificar as outras funcionalidades de infra-estrutura que o Spring provê. A Listagem 3.1 apresenta a implementação da classe Message. Capitulo 3. A Camada de Negócios 85 01: public class Message { 02: 03: 04: private Long id; private String text; private Date date; 05: 06: public void setId(Long newValue) { id = newValue; } public Long getId() { return id; } 07: 08: public void setText(String newValue) { text = newValue; } public String getText() { return text; } 09: 10: public void setDate(Date newValue) { date = newValue; } public Date getDate() { return date; } 11: } Listagem 3.10 – Classe Message. Como pode ser visto, a classe Message é implementada normalmente sem nenhuma dependência com o Spring. As propriedades da classe são definidas entre as linhas 02 e 04 e os métodos de acesso são definidos entre as linhas 05 e 10. A Listagem 3.11 apresenta o código fonte da interface MessageDAO. 12: public interface MessageDAO { 13: 14: 15: 16: public void createMessage(Message m); public void updateMessage(Message m); public void removeMessage(Message m); public Message[] listMessages(); 17: } Listagem 3.11 – Interface MessageDAO. A interface MessageDAO também é construída se qualquer acoplamento com o Spring. A implementação da classe MessageDAOImpl, que implementa a interface MessageDAO, é apresentada na seção 3.5.4 onde é apresentada a integração do Hibernate ao Spring. A listagem abaixo apresenta o código da classe ConferenceFacade. Capitulo 3. A Camada de Negócios 86 18: public class ConferenceFacade { 19: private MessageDAO messageDao; 20: public void setMessageDao(MessageDAO dao) { messageDao = dao; } 21: 22: 23: public void postMessage(Message m) { messageDao.createMessage(m); } 24: public Message listMessages() { 25: return messageDao.listMessages(); 26: } 27: } Listagem 3.12 – Classe ConferenceFacade. A variável que armazena a dependência com a interface MessageDAO é declarada na linha 19. A linha 20 explicita o método de acesso usado para configurar a dependência. O método de envio de mensagens é declarado no trecho entre a linha 21 e a linha 23 enquanto que o método que lista as mensagens da conferência é declarado entre as linhas 24 e 26. Os métodos de negócio nos Façades apenas delegam as chamadas recebidas para o DAO configurado. Um exemplo mais realista envolveria várias chamadas de métodos para um ou mais DAOs. A dependência entre a classe ConferenceMessage e a interface MessageDAO deve ser configurada no arquivo de configuração do Spring para que este atue como o montador. A Listagem 3.13 apresenta este arquivo de configuração do Spring, que por padrão tem o nome applicationContext.xml. Capitulo 3. A Camada de Negócios 87 28: <?xml version="1.0" encoding="UTF-8"?> 29: <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 30: "http://www.springframework.org/dtd/spring-beans.dtd"> 31: <beans> 32: 33: 34: <bean id="messageDAO" class="MessageDAOImpl"> </bean> 35: 36: 37: 38: 39: 40: <bean id="conferenceFacade" class="ConferenceFacade"> <property name="messageDao"> <ref local="messageDAO"/> </property> </bean> 41: </beans> Listagem 3.13 – Arquivo de Configuração do Spring O trecho entre as linhas 32 e 34 define o bean messageDAO. O id, definido na linha 32, identifica unicamente este bean no contexto da aplicação Spring. A propriedade class, definida na linha 33, especifica a classe do bean. O trecho entre as linhas 35 e 40 declaram o bean conferenceFacade. A dependência com o bean messageDAO é configurada no trecho entre as linhas 37 e 39. Na linha 37 é descrito que a propriedade que armazena a dependência se chama messageDao e na linha 38 é descrito que esta propriedade recebe o bean messageDAO, definido anteriormente no mesmo arquivo. Os beans definidos no arquivo de configuração do Spring ficam acessíveis pela interface org.springframework.context.ApplicationContext. Há varias formas de iniciar o contexto do Spring. A mais comum em aplicações web como o AulaNet é através de um tratador de eventos executado automaticamente quando a aplicação é iniciada no servidor de aplicações. Para configurar este tratador de eventos, é preciso configurar o arquivo descritor da aplicação web.xml conforme o exemplo da Listagem 3.14. Capitulo 3. A Camada de Negócios 88 42: <?xml version="1.0" encoding="UTF-8"?> 43: <!DOCTYPE web-app PUBLIC 44: "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" 45: "http://java.sun.com/dtd/web-app_2_3.dtd"> 46: <web-app> 47: <context-param> 48: <param-name>contextConfigLocation</param-name> 49: <param-value>/WEB-INF/applicationContext.xml</param-value> 50: </context-param> 51: <listener> 52: <listener-class> 53: org.springframework.web.context.ContextLoaderListener 54: </listener-class> 55: </listener> 56: </web-app> Listagem 3.14 – Descritor web.xml da Aplicação: Iniciando o Contexto Spring Na linha 49 o nome do arquivo de configuração do Spring é configurado. Neste exemplo optou-se pelo nome padrão, mas qualquer nome poderia ser usado ou mesmo uma lista separada por vírgulas com vários arquivos de configuração. O trecho entre as linhas 51 e 55 declara o tratador de eventos que inicia o contexto Spring. Além de promover o acoplamento fraco entre classes através do módulo de Dependency Injection, o Spring também fornece serviços de infra-estrutura. A próxima seção mostra como o Spring integrado ao Hibernate provê serviços relacionados à persistência dos dados. 3.5.3. Integração do Hibernate com o Spring Ao integrar o Hibernate ao Spring, a configuração do Hibernate que antes era feita separadamente passa a ser feita através do próprio Spring. Desta forma, a manutenção do arquivo de configuração da aplicação é feita em um só arquivo com uma sintaxe única. A Listagem 3.15 apresenta o arquivo de configuração do Spring onde é configurada a integração com o Hibernate. Capitulo 3. A Camada de Negócios 89 01: <?xml version="1.0" encoding="UTF-8"?> 02: <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 03: "http://www.springframework.org/dtd/spring-beans.dtd"> 04: <beans> 05: <bean id="dataSource" 06: class="org.springframework.jndi.JndiObjectFactoryBean"> 07: <property name="jndiName"> 08: <value>java:/comp/env/jdbc/AulaNetDB</value> 09: </property> 10: </bean> 11: <bean id="sessionFactory" 12: class="org.springframework.orm.hibernate.LocalSessionFactoryBean"> 13: <property name="dataSource" ref="dataSource"/> 14: <property name="mappingResources"> 15: <list> 16: <value>Message.hbm.xml</value> 17: </list> 18: </property> 19: <property name="hibernateProperties"> 20: <props> 21: <prop key="hibernate.dialect"> 22: net.sf.hibernate.dialect.MySQLDialect 23: </prop> 24: <prop key="hibernate.show_sql">false</prop> 25: </props> 26: </property> 27: </bean> 28: <bean id="messageDAO" class="MessageDAOImpl"> 29: <property name="sessionFactory" ref="sessionFactory"> 30: </bean> 31: <bean id="conferenceFacade" class="ConferenceFacade"> 32: <property name="messageDao" ref="messageDAO"/> 33: </bean> 34: </beans> Listagem 3.15 – Arquivo de Configuração do Spring: Integração com Hibernate. O trecho entre as linhas 05 e 10 define a base de dados acessada pelo Hibernate para persistir os dados. A fábrica de sessões do Hibernate é configurada no trecho de código entre as linhas 11 e 27. Na linha 13 a fábrica é configurada com a fonte de dados previamente configurada. Na linhas 16 a fábrica é configurada para reconhecer os arquivos de mapeamento do Hibernate para a classe Message. O dialeto é configurada na linha 22 e na linha 24 a opção de log dos comandos SQL gerados é desabilitada. O bean messageDAO é configurado no trecho entre as linhas 28 e 30. Na linha 29 ele é configurado com a fábrica de sessões do Hibernate. Capitulo 3. A Camada de Negócios 90 A classe org.springframework.orm.hibernate.support.HibernateDaoSupport do Spring provê suporte para a implementação de DAOs usando Hibernate. Esta classe gerencia o acesso do DAO à fábrica de sessões e possibilita a criação de instâncias da classe org.springframework.orm.hibernate.HibernateTemplate, que fornece vários templates que facilitam a execução das tarefas mais usuais com o Hibernate. A Listagem 3.16 exibe a implementação da classe MessageDAOImpl. 35: public class MessageDAOImpl extends HibernateDaoSupport 36: implements MessageDAO { 37: 38: 39: public void createMessage(Message m) { getHibernateTemplate().save(m); } 40: 41: 42: public void updateMessage(Message m) { getHibernateTemplate().saveOrUpdateCopy(m); } 43: 44: 45: public void removeMessage(Message m) { getHibernateTemplate().delete(category); } 46: public Message[] listMessages() { 47: List messages = getHibernateTemplate().find("from Message m"); 48: } 49: } Listagem 3.16 – Classe MessageDAOImpl. Na linha 35 a classe é declarada estendendo a classe HibernateDaoSupport e na linha 36 é declarado que a classe implementa a interface do MessageDAO. O método getHibernateTemplate retorna instâncias da classe HibernateTemplate sobre a qual as operações de criação (linha 38), atualização (linha 41), remoção (linha 44) e busca (linha 47) são executadas. O código resultante é consideravelmente menor do que o listado na seção 3.4.1.1., pois a classe HibernateTemplate do Spring se responsabiliza por abrir e fechar sessões além de efetuar o tratamento de erros, convertendo possíveis exceções em outras que não exigem tratamento. O código também não apresenta marcação de transações, que são feitas declarativamente e são apresentadas na próxima seção. Capitulo 3. A Camada de Negócios 91 3.5.4. Transações Declarativas com Spring Spring possibilita o uso de transações declarativas que são descritas no arquivo de configuração sem que seja preciso alterar o código fonte. O controle das transações é realizado através de um gerenciador de transações. Há implementações do gerenciador para a API JDBC, para os frameworks ORM Hibernate, OJB, JDO, iBATIs e para a API JTA, que deve ser usada quando for preciso controlar transações entre bancos de dados distintos. Configurado o gerenciador de transações, é preciso especificar a política de transação para os métodos das classes envolvidas. A política envolve um ou mais dos seguintes atributos: escopo de propagação da transação, nível de isolamento, dicas de somente leitura, tempo limite da transação e tolerância a erros. O escopo de propagação da transação especifica o comportamento da transação quando um método que participa de uma transação chama outro. Spring possibilita que os seguintes valores sejam configurados para o escopo de propagação da transação: PROPAGATION_MANDATORY, uma exceção é lançada se um método marcado com este atributo é chamado fora de um contexto de transação; PROPAGATION_NESTED, um método marcado com este atributo deve sempre ser executado em um novo contexto de transação; PROPAGATION_NEVER, uma exceção é levantada se um método marcado com este atributo é chamado em um contexto de transação; PROPAGATION_NOT_SUPPORTED, indica que o método marcado com este atributo é executado fora de um contexto transacional sempre; PROPAGATION_REQUIRED, um método marcado com este atributo é sempre executado dentro de uma transação, ou seja, se este método é chamado dentro de uma transação, ele participa dela e no caso contrário é criada uma nova transação; PROPAGATION_REQUIRES_NEW indica que o método sempre é executado em seu próprio contexto de transação e PROPAGATION_SUPPORTS indica que um método só roda em um contexto de transação se ele for chamado dentro de um. O nível de isolamento da transação especifica o comportamento entre transações concorrentes que podem levar a problemas de “leituras sujas”, quando uma transação lê um dado alterado por outra transação ainda não confirmada, Capitulo 3. A Camada de Negócios 92 “leituras não repetitivas”, quando uma transação realiza uma mesma consulta duas vezes e obtém resultados diferentes e “leituras fantasmas”, quando uma transação realiza uma consulta uma vez, obtém um número determinado de linhas e repetindo a consulta obtém um número diferente de linhas. Quanto maior o nível de isolamento menor o desempenho da transação. Spring possibilita o uso de cinco níveis de isolamento: ISOLATION_DEFAULT é usado o nível de isolamento padrão da base de dados; ISOLATION_READ_UNCOMMITTED, que pode resultar em leituras ISOLATION_READ_COMMITTED sujas, que não repetíveis evita e leituras fantasmas. sujas; ISOLATION_REPEATEBLE_READ que evita leituras sujas e não repetíveis e ISOLATION_SERIALIZABLE que evita todos os problemas de concorrência listados anteriormente. Dicas de somente leitura podem ser acrescentadas à política de transação possibilitando um melhor desempenho em consultas que recuperam dados apenas para leitura e o tempo limite da transação é usado para evitar que uma transação espere infinitamente para ser concluída. A tolerância a erros pode ser configurada de forma que a transação não seja abortada quando uma determinada exceção ocorrer. A Listagem 3.17 apresenta o arquivo de configuração onde o gerenciador de transação e os dados da política de transação são configurados. Capitulo 3. A Camada de Negócios 93 01: <?xml version="1.0" encoding="UTF-8"?> 02: <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 03: "http://www.springframework.org/dtd/spring-beans.dtd"> 04: <beans> 05: 06: 07: 08: 09: 10: 11: <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean"> <!-- Declaração da Fonte de Dados --> </bean> <bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean"> <!-- Declaração da fábrica de sessões --> </bean> 12: 13: 14: 15: <bean id="txManager" class="org.springframework.orm.hibernate.HibernateTransactionManager"> <property name="sessionFactory" ref="sessionFactory"/> </bean> 16: 17: 18: 19: <bean id="messageDAOTarget" class="MessageDAOImpl"> <property name="sessionFactory" ref="sessionFactory"> </bean> 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: <bean id="messageDAO" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <property name="transactionManager" ref="txManager"/> <property name="target" ref="messageDAOTarget"/> <property name="proxyInterfaces"> <value>MessageDAO</value> </property> <property name="transactionAttributes"> <props> <prop key="list*">PROPAGATION_REQUIRED,readOnly</prop> <prop key="*">PROPAGATION_REQUIRED</prop> </props> </property> </bean> 34: <bean id="conferenceFacade" 35: class="ConferenceFacade"> 36: <property name="messageDao" ref="messageDAO"/> 37: </bean> 38: </beans> Listagem 3.17 - Arquivo de Configuração do Spring: Transações Declarativas. O gerenciador de transações para o Hibernate é configurado no trecho entre as linhas 12 e 15. A classe MessageDAOImpl é configurada no trecho de código entre as linhas 16 e 19. A dependência da classe ConferenceFacade com a interface MessageDAO é configurada com um Proxy dinâmico gerado pelo Spring que acrescenta os serviços de transação e depois delega a chamada para o bean messageDAOTarget. Este Proxy é declarado entre as linhas 20 e 33. Na linha 22 o Proxy é configurado com o gerenciador de transação apropriado e na linha 23, o bean messageDAOTarget para o qual o Proxy delega chamadas é configurado. Na linha 25 é declarado que o Proxy gerado pelo Spring dinamicamente deve implementar a interface MessageDAO, desta forma a classe Capitulo 3. A Camada de Negócios 94 ConferenceFacade pode usar o Proxy da mesma forma que usaria a implementação concreta. Na linha 29 a política de transação PROPAGATION_REQUIRED com a dica de somente leitura para todos os métodos começando com “list” e na linha 30 a política de transação PROPAGATION_REQUIRED é especificada para os outros métodos. O uso de transações declarativas resulta em um código mais limpo e com um maior grau de reuso já que classes podem ter seu comportamento transacional modificado sem que seja necessário mudar o código. Na próxima seção é apresentado outro serviço de infra-estrutura provido pelo Spring: gerenciamento de segurança. 3.5.5. Gerenciamento de Segurança com Spring O módulo de programação orientada a aspectos do Spring possibilita que o desenvolvedor crie seus próprios aspectos, porém há vários aspectos que podem ser usados em situações corriqueiras. Dentre eles, há o aspecto que possibilita o uso de segurança declarativa onde se pode restringir o acesso aos métodos de uma classe a determinados usuários. Para que o Spring possa prover segurança declarativa é preciso que sejam configurados um gerenciador de autenticação e um gerenciador de controle de acesso. O gerenciador de autenticação é responsável por autenticar que o usuário é quem diz ser. Tipicamente esta checagem é feita através de um par identificador – senha. O gerenciador de controle de acesso é responsável pela autorização, ou seja, ele decide se o usuário autenticado tem permissão para executar a operação. O gerenciador de autenticação implementa a interface org.acegisecurity.AuthenticationManager. O Spring possui uma implementação desta interface chamada gerenciador de provedores (ProviderManager) cuja função é realizar autenticação em diversos “provedores de autenticação”. Há diversos tipos de provedores que podem ser usados para autenticar um usuário em uma base de dados, usando um serviço remoto de autenticação, um servidor LDAP, etc. O gerenciador de controle de acesso é responsável por contabilizar os votos dos org.acegisecurity.vote.AccessDecisionVoter e tomar a decisão se o acesso é Capitulo 3. A Camada de Negócios 95 garantido ou negado. Um AccesDecisionVoter é uma classe que vota se o acesso a um recurso é garantido, negado ou opcionalmente pode se abster da votação. Exemplo: o RoleVoter vota para garantir acesso sempre que o usuário possuir um papel com o qual ele está configurado. Há 3 implementações do gerenciador de controle de acesso disponíveis no Spring: o AffirmativeBased, que garante acesso se houver pelo menos um voto a favor, ConsensusBased que garante acesso apenas se todos votarem a favor e UnanimousBased que garante acesso se não houver votos contra. A Listagem 3.18 mostra o arquivo de configuração do Spring modificado para prover segurança declarativa para a classe MessageDAOImpl. Capitulo 3. A Camada de Negócios 96 01: <beans> 02: <!-- Declaração de Outros Beans --> 03: <bean id="conferenceFacadeTarget" class="ConferenceFacade"> 04: <property name="messageDao" ref="messageDAO"/> 05: </bean> 06: <bean id="messageDAOTarget" 07: class="MessageDAOImpl"> 08: <property name="sessionFactory" ref="sessionFactory"/> 09: </bean> 10: <bean id="messageDAO" 11: class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"> 12: <property name="interceptorNames"> 13: <list><value>securityInterceptor</value></list> 14: </property> 15: <property name="beanNames"> 16: <list><value>messageDAOTarget</value></list> 17: </property> 18: </bean> 19: <bean id='securityInterceptor' 20: class='net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor'> 21: <property name='authenticationManager' ref='authenticationManager'/> 22: <property name='accessDecisionManager' ref='accessDecisionManager'/> 23: <property name='objectDefinitionSource'> 24: <value> 25: MessageDAO.createMessage=ROLE_APPRENTICE,ROLE_MEDIATOR 26: MessageDAO.updateMessage=ROLE_MEDIATOR 27: MessageDAO.removeMessage=ROLE_MEDIATOR 28: MessageDAO.list*=ROLE_APPRENTICE,ROLE_MEDIATOR 29: </value> 30: </property> 31: </bean> 32: <bean id='authenticationManager' 33: class='net.sf.acegisecurity.providers.ProviderManager'> 34: <property name='providers'> 35: <list><ref bean='authenticationProvider'/></list> 36: </property> 37: </bean> 38: <bean id='authenticationProvider' 39: class='net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider'> 40: <property name='authenticationDao' ref='memoryAuth'/> 41: </bean> 42: <bean id='authenticationDao' 43: class='net.sf.acegisecurity.providers.dao.memory.InMemoryDaoImpl'> 44: <property name='userMap'> 45: <value> 46: paulo=123456,ROLE_APPRENTICE 47: mauro=abacate,ROLE_MEDIATOR 48: </value> 49: </property> 50: </bean> 51: <bean id='accessDecisionManager' 52: class='net.sf.acegisecurity.vote.AffirmativeBased'> 53: <property name='decisionVoters'> 54: <list><ref bean='roleVoter'/></list> 55: </property> 56: </bean> 57: <bean id='roleVoter' class='net.sf.acegisecurity.vote.RoleVoter'/> 58: </beans> Listagem 3.18 - Arquivo de Configuração do Spring: Segurança Declarativa. O trecho entre as linhas 10 e 18 define o proxy que acrescenta o aspecto segurança a classe MessageDAOImpl sendo que o interceptador relativo a este proxy é configurado na linha 13 e declarado no trecho entre as linhas 19 e 31. O Capitulo 3. A Camada de Negócios 97 gerenciador de autenticação é configurado na linha 21 e o gerenciador de controle de acesso na linha 22. As linhas 25 e 28 indicam que os métodos de criação e listagem de mensagens estão disponíveis tanto para aprendizes quanto para mediadores. Já as linhas 26 e 27 indicam que apenas mediadores podem apagar ou atualizar mensagens. O trecho entre as linhas 32 e 50 referem-se à configuração do gerenciador de autenticação e o trecho entre as linhas 51 e 56 se referem à configuração do gerenciador de controle de acesso. O framework Spring possibilita um serviço de segurança declarativa para POJOs, de forma similar ao dos EJBs. Este framework fornece ainda meios de expor serviços remotamente, como é visto na próxima seção. 3.5.6. Exposição de Serviços Remotos com Spring Eventualmente é necessário expor as funcionalidades da camada de negócio de uma aplicação remotamente para outras aplicações e para outros clientes, inclusive clientes móveis. Spring possibilita a exposição de seus beans remotamente de quatro formas diferentes: através do uso de RMI (RMI-IIOP. 2005), de Hessian/Burlap (Caucho, 2005), do HttpInvoker (Spring, 2005) e de serviços web JAX-RPC (Singh et al., 2004). RMI ou Remote Method Invocation é uma tecnologia que possibilita a chamada a métodos de componentes remotos, também usada no Enterprise JavaBeans. Sua principal vantagem é que ela é eficiente quando a comunicação é feita entre duas plataformas Java. Modelos complexos de objetos podem ser enviados através do mecanismo de serialização da plataforma Java. Sua principal desvantagem é que ela usa portas arbitrárias para se comunicar, o que exige esforço extra de configuração em firewalls, e não possibilita a comunicação de Java com outras plataformas. Hessian e Burlap são protocolos desenvolvidos pelo grupo Caucho (2005) que possibilitam a comunicação remota entre serviços. Ao contrário do RMI, Hessian e Burlap são construídos sobre o HTTP e, portanto não costumam demandar configuração extra em firewall. Além disso, Hessian/Burlap possibilita a comunicação entre as plataformas Java, PHP, Python, C++ e C#. Hessian utiliza Capitulo 3. A Camada de Negócios 98 um protocolo binário, ideal quando a largura da banda é limitada e Burlap utiliza um protocolo baseado em XML, ideal quando é preciso que as mensagens trocadas sejam lidas por pessoas. Estes dois protocolos usam técnicas próprias para enviar objetos pela rede que podem ser ineficientes quando se usa um modelo complexo de classes. O HttpInvoker é um protocolo desenvolvido exclusivamente para o Spring e soluciona este problema. Assim como Hessian/Burlap ele usa HTTP e, portanto não demanda configurações extras de firewall. Assim como o RMI, ele usa a tecnologia de objetos serializáveis da plataforma Java, que é capaz de enviar modelos complexos de objetos pela rede. HttpInvoker é a opção ideal quando é preciso integrar duas aplicações que usam o framework Spring pela internet. A tecnologia de serviços web possibilita a chamada de métodos remotos através da troca de arquivos XML, a descoberta automática de serviços dentre outras vantagens. Esta tecnologia é executada sobre o HTTP então firewalls não costumam ser um empecilho e, como utiliza um padrão bem conhecido, é viável realizar a comunicação entre diversas plataformas. Por outro lado, das quatro tecnologias para exposição de serviços remotos, é a mais pesada e sua performance pode não ser adequada em alguns cenários. Spring possibilita que serviços sejam expostos sem que seja necessário alterar o código fonte da aplicação. Para expor um serviço usando RMI, é preciso configurar o Proxy adequado no arquivo de configuração. Para expor um serviço com Hessian/Burlap ou HttpInvoker, além de configurar o Proxy no arquivo de configuração é preciso declarar um servlet que trata as conexões HTTP. A exposição de serviços como serviços web é mais trabalhosa, pois envolve também a criação do arquivo descritor do serviço WSDL. Para fins de demonstração, a Listagem 3.19 apresenta o arquivo de configuração do Spring onde o serviço Conferência é exposto utilizando a tecnologia RMI, a mesma usada pelo Enterprise JavaBeans. Capitulo 3. A Camada de Negócios 99 01: <beans> 02: <!-- Declaração de Outros Beans --> 03: 04: 05: <bean id="conferenceFacade" class="ConferenceFacadeImpl"> <property name="messageDao" ref="messageDAO"/> </bean> 06: <bean class="org.springframework.remoting.rmi.RmiServiceExporter"> 07: <property name="serviceName" value="Conference"/> 08: <property name="service" ref="conferenceFacade"/> 09: <property name="serviceInterface" value="ConferenceFacade"/> 10: <property name="registryPort" value="1199"/> 11: </bean> 12: </beans> Listagem 3.19 - Arquivo de Configuração do Spring: Exposição de Serviços Remotos. O bean da conferência é declarado entre as linhas 03 e 05. Neste caso, considera-se que ConferenceFacadeImpl é a classe da conferência que implementa a interface ConferenceFacade. O uso de interfaces é obrigatório quando se lida com Proxys do Spring. O trecho entre as linhas 06 e 11 declara o Proxy dinâmico responsável por expor o serviço Conferência remotamente usando RMI. Na linha 07 é associado um nome ao serviço que será usado para cadastrá-lo no registro RMI. Na linha 08 é especificado o bean cujos serviços são expostos pelo Proxy, no caso, o bean conferenceFacade. Na linha 09 é declarada a interface que este Proxy dinâmico implementa e na linha 10, a porta em que o serviço e exposto. O framework Spring possibilita que serviços sejam expostos declarativamente, sem que seja necessário alterar o código fonte. Como conseqüência, pode-se trocar o mecanismo de comunicação sem alterar o código, aumentando o reuso. 3.5.7. Considerações Finais Sobre o Spring Spring é capaz de prover serviços de infra-estrutura como o controle de transações, segurança e exposição de serviços remotos assim como Enterprise JavaBeans mas, diferentemente do EJB, Spring não é intrusivo. As classes gerenciadas pelo Spring não dependem necessariamente do Spring (Johnson, 2004). Capitulo 3. A Camada de Negócios 100 Além disso, o módulo de Dependency Injection promove o acoplamento fraco entre componentes. Graças a este fraco acoplamento as classes são mais fáceis de testar unitariamente. As dependências são explicitadas e podem ser substituídas por mock objects (Mackinnon et al., 2000), objetos que imitam objetos reais e os substituem em testes. Finalmente, por ser um framework modular, apenas os módulos que interessam à aplicação precisam ser selecionados. Desta forma, evita-se complexidade desnecessária. 3.5.8. Outros Frameworks Para Dependency Injection Spring não é o único framework/container leve disponível no mercado. Há o Avalon (2005), o HiveMind (2005), NanoContainer (2005) e o PicoContainer (2005). Todos estes frameworks são gratuitos e, possíveis substitutos para o Spring. O projeto Avalon foi encerrado em 2004 e transformado no projeto Excalibur (2005). O projeto PicoContainer provê apenas o suporte essencial para um framework de Dependency Injection e tem suas funcionalidades estendidas pelo NanoContainer. O HiveMind é o mais similar ao Spring, provendo também um módulo de programação orientada a aspectos. Spring aliado ao Hibernate oferece vários recursos de infra-estrutura. Para reforçar a escolha do Spring é feita uma análise similar a que é feita com os frameworks ORM: é verificado a quantidade de documentação disponível, a disponibilidade de suporte, a disponibilidade de ferramentas compatíveis, o grau de aceitação no mercado e a disponibilidade de profissionais com habilidades nos frameworks comparados. 3.5.8.1. Quantidade de Documentação Disponível Pode-se ter uma idéia da quantidade de documentação disponível sobre um framework considerando o número de livros publicados e realizando uma consulta em uma ferramenta de busca para contabilizar o número de tutoriais disponíveis sobre este. Capitulo 3. A Camada de Negócios 101 O gráfico apresentado na Figura 3.15 mostra o número de livros publicados para cada um dos frameworks para Dependency Injection segundo uma pesquisa realizada em dezembro de 2005 no site Amazon. 10 5 0 Excalibur HiveMind NanoContainer PicoContainer Spring Figura 3.15 - Livros Publicados Para Cada Framework de Dependency Injection Fonte: Amazon.com, Dezembro de 2005 Só há livros publicados sobre o Spring. O gráfico exibido na Figura 3.16 mostra o resultado de uma busca por tutorias na ferramenta de busca Google em março de 2006. 60000 50000 40000 30000 20000 10000 0 Excalibur HiveMind NanoContainer PicoContainer Spring Figura 3.16 - Artigos e Tutoriais Para Cada Framework de Dependency Injection Fonte: Google.com, Março de 2006 Há um número tão pequeno de tutoriais disponíveis sobre o NanoContainer, que não é possível visualizar sua contribuição no gráfico. Os frameworks Capitulo 3. A Camada de Negócios 102 Excalibur, HiveMid e PicoContainer também possuem um número pequeno de tutoriais quando comparados com o Spring. Spring é claramente o framework para Dependency Injection com mais documentação disponível, levando em consideração os livros publicados e tutoriais disponíveis na web. 3.5.8.2. Disponibilidade de Suporte É importante considerar a disponibilidade de suporte para cada framework antes de efetuar uma decisão. Excalibur e HiveMind possuem listas de discussão mantidas pela comunidade onde pode-se obter suporte gratuito. PicoContainer e o NanoContainer compartilham a mesma lista de discussão. Já o Spring conta com um fórum de discussão oficial e uma lista de discussão não-oficial onde podem ser obtidos suporte da comunidade além de suporte comercial fornecido pela empresa Interface 21 (2005). Para mensurar a disponibilidade de suporte destes frameworks, realiza-se uma pesquisa contabilizando o volume de mensagem trocado nestas listas de discussão em determinado período de tempo. Infelizmente não é possível mensurar o volume de mensagens trocadas no fórum do Spring, pois este não possibilita a seleção de mensagens em um determinado período de tempo. Tentei entrar em comunicação pessoal com os responsáveis pela administração do fórum, mas até a data de fechamento deste texto não houve resposta (os e-mails trocados estão transcritos no apêndice A) e, portanto, serão contabilizados os dados da lista de discussão não-oficial. O gráfico exibido na Figura 3.17 mostra o resultado da análise realizada em novembro de 2005. Capitulo 3. A Camada de Negócios 103 140 120 100 80 60 40 20 0 Excalibur HiveMind NanoContainer e PicoContainer Spring Figura 3.17 - Mensagens Trocadas em Listas de Discussão (11/2005) Mesmo em uma lista não-oficial, o Spring se mostrou o framework para Dependency Injection com a comunidade mais ativa, tendo o HiveMind em segundo lugar. As listas de discussão dos frameworks Excalibur, NanoContainer e PicoContainer apresentou um volume consideravelmente pequeno de mensagens trocadas no mês de Novembro indicando que pode ser difícil obter suporte da comunidade para estes frameworks e que provavelmente há poucas pessoas usando estes frameworks. 3.5.8.3. Disponibilidade de Ferramentas Compatíveis Ferramentas compatíveis com um framework auxiliam o desenvolvimento, automatizando tarefas repetíveis, possibilitando a edição de documentos com ferramentas gráficas e a criação de artefatos com formulários estilo wizard, etc. Para contabilizar o número de ferramentas compatíveis com cada framework foram verificados a quantidade de plugins disponíveis para as plataformas Eclipse e NetBeans, a compatibilidade com as IDEs Java mais populares (IBM WSAD, Sun Java Studio Enterprise, Borland JBuilder, Oracle JDeveloper, BEA Workshop e InteliJ IDEA), a compatibilidade com a ferramenta XDoclets além das ferramentas disponíveis nos web sites dos próprios frameworks. A Figura 3.18 mostra o número de ferramentas disponíveis compatíveis com cada framework em uma análise realizada em dezembro de 2005. Capitulo 3. A Camada de Negócios 104 7 6 5 4 3 2 1 0 Excalibur HiveMind NanoContainer PicoContainer Spring Figura 3.18 – Ferramentas Compatíveis com os Frameworks para Dependency Injecton em 12/2005 Constata-se que não há ferramentas que oferecem suporte ao desenvolvimento com Excalibur, NanoContainer e PicoContainer. Há 1 ferramenta que oferece suporte ao desenvolvimento com HiveMind e 6 que dão suporte ao desenvolvimento com o Spring. 3.5.8.4. Grau de Aceitação no Mercado É importante saber o que outras instituições estão usando antes de tomar a decisão a respeito de um framework. Um framework com boa aceitação pelo mercado estimula outros fatores como a disponibilidade de ferramentas compatíveis, a disponibilidade de suporte, etc. Por outro lado, um framework que não é aceito pelo mercado corre o risco de desaparecer. Para obter um indicativo do grau de aceitação do mercado para um framework, faz-se uma busca em sites de empregos, procurando por ofertas de emprego abertas que solicitem desenvolvedores com habilidades em um determinado framework. A Figura 3.19 mostra o resultado da pesquisa realizado em dezembro de 2005 no site Dice.com. Capitulo 3. A Camada de Negócios 105 400 300 200 100 0 Excalibur HiveMind NanoContainer PicoContainer Spring Figura 3.19 – Ofertas de Emprego Abertas para cada Framework para Dependency Injection. Fonte: Dice.com, Dezembro de 2005 Spring é o framework com mais vagas abertas no mercado de trabalho norte-americano. Não há vagas abertas exigindo conhecimento com os Frameworks NanoContainer e PicoContainer. O número de vagas abertas demandando habilidades com Excalibur (2 vagas) e o HiveMind (1 vaga) e tão pequeno que não pode ser notada nitidamente no gráfico. O site Dice.com revela um retrato do mercado norte-americano, mas não representa necessariamente a realidade do mercado brasileiro. Para verificar se a realidade do mercado brasileiro é similar, realizou-se uma busca em dezembro de 2005 no site nacional Manager Online (http://www.manageronline.com.br/). 2 1 0 Excalibur HiveMind NanoContainer PicoContainer Spring Figura 3.20 - Vagas Abertas para cada Framework de Dependency Injection Fonte: Manager Online, Dezembro de 2005. Capitulo 3. A Camada de Negócios 106 A pesquisa revela que só há 1 vaga aberta para o framework Spring segundo a busca feita no site ManagerOnline. O número consideravelmente pequeno dificulta qualquer comparação. 3.5.8.5. Disponibilidade de Profissionais Para diminuir gastos com treinamento é importante verificar a disponibilidade de mão de obra no mercado de trabalho com aptidão a trabalhar com os frameworks comparados. Para verificar esta disponibilidade faz-se uma consulta em sites que hospedam currículos. A Figura 3.21 mostra o resultado da busca realizada em dezembro de 2005 no site Jobs.net que reflete a realidade do mercado de trabalho norte-americano. 200 150 100 50 0 Excalibur HiveMind NanoContainer PicoContainer Spring Figura 3.21 - Disponibilidade de Profissionais em 12/2005 Fonte: Jobs.net. Há pouco mais que 150 profissionais que se dizem aptos a trabalhar com o framework Spring em seus currículos. Há um número consideravelmente pequeno de profissionais aptos a trabalhar com o HiveMind e nenhum profissional apto a para trabalhar com os outros frameworks. Para validar se a realidade do mercado norte-americano é compatível com a realidade do mercado brasileiro realizou-se uma busca no site nacional APInfo.com em dezembro de 2005. Capitulo 3. A Camada de Negócios 107 40 30 20 10 0 Excalibur HiveMind NanoContainer PicoContainer Spring Figura 3.22 - Disponibilidade de Profissionais Fonte: APInfo.com, Dezembro de 2005. Segundo a busca no site APInfo só o Spring possui profissionais que se declaram aptos a trabalhar com o framework em seus currículos. 3.5.8.6. Resultado da Comparação Após comparar todos os critérios chega-se a conclusão que Spring é a opção mais adequada para ser usada na arquitetura do AulaNet 3.0. Todos os outros frameworks são carentes em vários aspectos. Spring possui farta documentação disponível, suporte da comunidade e comercial e ferramentas compatíveis que auxiliam o desenvolvimento. Além disso, Spring tem recebido uma boa aceitação no mercado (principalmente no norte-americano) e há profissionais aptos a trabalhar com ele disponíveis. O EJB novamente não é incluído na análise, pois ele não é um framework para Dependency Injection e porque ele é descartado na análise técnica ao considerar suas desvantagens. 3.6. Conclusão O objetivo da camada de negócios é implementar a lógica da aplicação, expondo esta lógica para a camada de apresentação ou para outras aplicações clientes remotas, por exemplo, clientes móveis. Para cumprir este objetivo, podese optar por um framework de componentes, como o Enterprise JavaBeans ou Capitulo 3. A Camada de Negócios 108 pode-se criar o próprio framework de componentes a partir de uma arquitetura com POJOs (Plain Old Java Objects). EJB traz vantagens relacionadas a aspectos de infra-estrutura tratados por ele. Dentre estes aspectos os principais são: persistência automática dos beans de entidade, componentes representando entidades de negócio. A persistência automática livra o desenvolvedor de escrever código JDBC de baixo nível e possibilita que a aplicação seja executada em bancos de dados diferentes; controle de transações declarativo, a demarcação das transações é feita fora do código fonte, tornando o código mais limpo e incentivando o reuso; gerenciamento de segurança com demarcações declarativas que assim como a transação declarativa incentiva o reuso já que componentes podem ter seu acesso controlado sem que seja necessário alterar o código fonte e exposição de serviços remotos, que possibilita que aplicações externas acessem o componente. Contudo, EJB também traz desvantagens. Dentre elas, as principais são: a grande quantidade de arquivos que precisam ser mantidos para definir um componente; a dependência com servidores de aplicações compatíveis com EJB que usualmente são mais caros e mais difíceis de configurar; elevado grau de intrusão que dificulta a execução de testes unitários em componentes EJB e restrições de programação impostas pela especificação que impossibilitam a realização de atividades corriqueiras. Ao invés de usar EJB, é possível criar um framework de componentes próprio a partir de uma arquitetura com POJOs, agregando frameworks de infraestrutura que provêm as mesmas vantagens do EJB sem a maior parte das desvantagens. Para realizar a persistência de objetos, foi escolhido o Hibernate, um framework ORM que trata a persistência de objetos em base de dados relacionais. Ao contrário do EJB que é uma solução de mapeamento médio, Hibernate é uma solução de mapeamento completo, isto é, possibilita o mapeamento de modelos complexos envolvendo estruturas de herança de forma transparente, sem que as classes persistidas precisem estender classes ou implementar interfaces do framework. Hibernate trata também questões complexas relativas ao conflito de paradigmas objeto/relacional. Outros frameworks ORM de mapeamento completo gratuitos disponíveis são: Apache OJB, iBATIs e JDO. Contudo, Hibernate possui mais documentação disponível, um maior número de ferramentas compatíveis, Capitulo 3. A Camada de Negócios 109 maior disponibilidade de suporte, melhor aceitação no mercado de trabalho e maior quantidade de mão de obra disponível. Sozinho o Hibernate não oferece todos os serviços de infra-estrutura presentes no EJB, por isto ele deve ser combinado com o framework Spring. Este último integra-se ao Hibernate provendo também suporte a transações declarativas, gerenciamento de segurança declarativa e exposição de serviços remotos. Além disso, através de Dependency Injection, Spring promove o acoplamento fraco entre classes, facilitando a criação de testes unitários e incentivando o reuso. Há outros frameworks similares ao Spring, dentre eles o Excalibur, HiveMind, PicoContainer e o NanoContainer. Porém estes são carentes em quantidade de documentação disponível, ferramentas compatíveis, suporte da comunidade ou comercial, grau de aceitação no mercado e quantidade de profissionais disponíveis aptos a trabalhar com cada um. O par Hibernate e Spring possibilita a incorporação de serviços de infraestrutura a arquitetura do AulaNet 3.0, possibilitando que o desenvolvedor de componentes de groupware concentre-se em seu domínio ao invés de se preocupar com serviços de baixo nível. Por se tratar de uma tecnologia aplicada a POJOs, classes normais que não seguem nenhuma especificação rígida, pode também ser aplicada a um framework de componentes desenvolvido para gerar componentes de groupware. Este capítulo apresentou como um groupware se beneficia de frameworks de infra-estrutura quando aplicados na camada de negócios. No próximo capítulo é mostrado como a camada de apresentação também obtem benefícios da incorporação destes frameworks. 4 A Camada de Apresentação O objetivo da camada de apresentação em uma aplicação multicamadas é de expor a lógica de negócios ao usuário e possibilitar a interação do usuário com a aplicação. Em aplicações baseadas na internet como o AulaNet, esta camada também costuma ser chamada de camada web. Neste capítulo são apresentadas vantagens e desafios decorrentes do uso de interfaces HTML. Logo depois são vistos os benefícios obtidos com a adoção do padrão de arquitetura Model View Controller (MVC) (Fowler, 2002). São apresentados e comparados frameworks de infra-estrutura que implementam o MVC e fornecem recursos para contornar os desafios citados, concluindo a seção com a escolha de um deles para o AulaNet 3.0. 4.1. Vantagens e Desafios no Desenvolvimento de Interfaces HTML HTML é a linguagem usada no desenvolvimento da interface com o usuário da maior parte das aplicações baseadas em web atualmente. O uso de interfaces HTML traz vantagens. Segundo Johnson (2002) e (2004) estas a seguir são as principais: V1. A aplicação é instalada no servidor. O usuário usa o navegador instalado em seu computador que funciona como um cliente universal; V2. Desacopla o usuário da tecnologia usada no servidor; V3. Geralmente firewalls são configurados para liberar o trafego de rede na porta utilizada pelo servidor de páginas HTML, diminuindo o esforço de configuração; V4. Impõem restrições de configurações de hardware mais modestas às máquinas dos usuários já que a maior parte do processamento ocorre no servidor. Capitulo 4. A Camada de Apresentação 111 Contudo, o desenvolvimento de aplicações baseadas na internet com HTML/HTTP impõe uma série de desafios: D1. A interface de aplicações web muda freqüentemente sem que necessariamente a lógica de negócios seja alterada. É comum, por exemplo, que um cliente solicite a EduWeb mudanças no visual do AulaNet para que ele se identifique com sua marca; D2. Uma interface HTML é limitada pelo modelo de requisição e resposta, diferentemente de outras tecnologias de construção de interface como o Swing (Topley, 1999), usada comumente em aplicações Java Desktop, onde um componente de interface pode ser atualizado automaticamente quando ocorre alguma mudança no modelo; D3. Interfaces web costumam apresentar marcações complexas como tabelas aninhadas e extensos trechos de código JavaScript sendo que apenas uma pequena parte desta marcação se destina a conteúdo gerado dinamicamente. O código de marcação que constrói o layout da interface deve ser separado do código que efetua as operações de negócio de forma a possibilitar a separação em papéis: desenvolvedor e web designer; D4. Requisições HTTP carregam apenas parâmetros do tipo String, que freqüentemente precisam ser convertidos para outros tipos; D5. Interfaces HTML tornam a validação da entrada do usuário mais importante, pois a aplicação tem controle limitado sobre o navegador onde o usuário insere os dados; D6. HTML oferece um conjunto limitado e não expansível de componentes de interface; D7. Garantir que uma aplicação tenha o mesmo visual em todos os navegadores é custoso, devido as variações na aderência aos padrões HTML, JavaScript e CSS; D8. Questões de desempenho e concorrência devem ser consideradas, pois é impossível prever o número de usuários acessando uma aplicação web simultaneamente; D9. Interfaces web são executadas no navegador, ao qual se tem controle limitado. Por conseqüência, são difíceis de testar e depurar. Capitulo 4. A Camada de Apresentação 112 A divisão da aplicação em camadas, com uma delas destinada a apresentação e interface com o usuário, contribui para a solução de alguns destes desafios. Como uma camada só depende de outra imediatamente inferior, a camada de apresentação pode ser alterada sem que a de negócios sofra alterações (D1). Além disso, o web designer pode concentrar-se na camada de apresentação enquanto o programador concentra-se na camada de negócios (D3). Finalmente, a lógica de negócios não depende da camada web e cada camada pode ser testada, depurada e otimizada isoladamente (D8 e D9). Contudo, apenas a divisão em camadas não basta para solucionar estes desafios. Para que isto ocorra é preciso também que a camada de apresentação seja limpa, isto é, o fluxo de controle e a chamada dos métodos de negócios são separados da visão, e magra, ou seja, não deve possuir mais código do que o necessário para chamar a camada de negócios. Para garantir que seja limpa, usa-se o padrão de arquitetura Model View Controller (MVC), discutido na próxima seção. Para garantir que seja magra é importante disciplinar os desenvolvedores e realizar auditorias periódicas no código. 4.2. Model View Controller O padrão de arquitetura Model View Controller (MVC) surgiu pela primeira vez na década de 70 em um framework desenvolvido por Trygve Reenskaug para a plataforma Smalltalk (Lalonde, 1994) e desde então tem influenciado a maior parte dos frameworks voltados para interface com o usuário e a maneira de pensar o design de interfaces (Fowler, 2002). O MVC divide os elementos da camada de apresentação em três tipos: o controlador (controller), encarregado de receber a entrada do usuário, acessar a camada de negócios para manipular o modelo e selecionar a visão; o modelo (model), um objeto representando uma parte do domínio e que provê os dados que a visão vai exibir. É o contrato entre o controlador e a visão; a visão (view), encarregada de exibir os dados do modelo para o usuário. Capitulo 4. A Camada de Apresentação 113 A Figura 4.1 mostra o fluxo do MVC clássico, usado em aplicações desktop. Este modelo é adotado em aplicações web com poucas modificações, com é visto mais adiante. C 2 3 1 4 M 5 V Figura 4.1 – MVC clássico (Ramachandran, 2002) 1) A visão notifica o controlador. Ocorre quando um formulário em uma aplicação web é submetido ou quando um botão é clicado em uma aplicação desktop, por exemplo. 2) O controlador acessa a lógica de negócios e atualiza o modelo. Corresponde a chamada de um método do Façade na arquitetura do AulaNet 3.0. 3) O controlador seleciona a visão mais adequada, passando para ela o estado do modelo que ela deve exibir. O controlador pode, por exemplo, selecionar uma visão caso a operação tenha sido bem sucedida ou outra visão em caso de erro. 4) A visão consulta o estado do modelo e exibe as informações ao usuário. Por exemplo, a visão exibe as mensagens postadas em uma conferência. 5) O estado do modelo é alterado. O modelo dispara um evento e a visão se atualiza. Por exemplo, quando um aprendiz envia uma mensagem em um debate. Os outros aprendizes têm sua tela atualizada sem que seja necessário solicitar atualizações ao servidor. Em aplicações para a internet com interface HTML, como o AulaNet, o modelo de requisição e resposta (Desafio 2) é um impedimento para que o modelo atualize a visão. Neste caso, usa-se o MVC modificado que costuma ser chamado de MVC Web ou de MVC pull, pois a visão “puxa” informações do modelo Capitulo 4. A Camada de Apresentação 114 enquanto que no MVC clássico, ou MVC push, o modelo “empurra” atualizações para a visão. A Figura 4.2 exibe o fluxo no MVC pull. C 2 3 1 4 M V Figura 4.2 – MVC pull (Johnson, 2002, 2004) 1) A visão notifica o controlador. 2) O controlador acessa a lógica de negócios e atualiza o modelo. 3) O controlador seleciona a visão mais adequada, passando a ela o modelo que ela irá exibir. 4) A visão consulta o modelo e exibe as informações ao usuário. A única diferença entre os MVC push e pull é que no segundo o modelo não atualiza a visão. Na plataforma J2EE, o modelo costuma ser implementado com JavaBeans, a visão com páginas JSP e o controlador com servlets. Embora seja possível implementar uma solução ad hoc que implante o MVC, há vários frameworks que trazem uma estrutura MVC e tratam alguns dos desafios listados na seção anterior, dentre eles, são analisados nas seções a seguir três destes frameworks: JavaServer Faces (JSF, 2005), Struts (2005) e Spring MVC, o módulo MVC do framework Spring (2005) apresentado no capítulo anterior. Estes frameworks, comumente chamados de web frameworks, possuem diversas características em comum, descritas a seguir. 4.3. Características Comuns a Web Frameworks Há cerca de 54 frameworks para o desenvolvimento web em plataforma Java gratuitos disponíveis atualmente (Manageability, 2005). Este número é ainda maior se contabilizados os frameworks comerciais. Boa parte destes frameworks implementam o MVC de forma similar e têm características comuns que visam Capitulo 4. A Camada de Apresentação 115 solucionar alguns dos desafios descritos na seção 4.1. Estas características assim como o comportamento destes frameworks são descritos a seguir. O framework usualmente traz o controlador do MVC pronto. Este é implementado através de um servlet que deve ser configurado ao instanciar o framework. O controlador mapeia requisições em classes da instância que realizam o padrão de projeto comando (Command) (Gamma et al., 1995). A visão é programada pela instância, mas o framework fornece componentes que auxiliam a sua construção. Já o modelo é implementado inteiramente pela instância e não deve possuir nenhum tipo de dependência com o framework escolhido, já que ele também é usado em outras camadas. Ao receber uma requisição o controlador assume o controle da aplicação. Cabe a ele extrair os parâmetros da requisição, que são do tipo String, convertêlos para tipos mais específicos da aplicação (desafio 4), que podem ser tipos primitivos mais restritos como inteiros e boleanos ou objetos do modelo, e validálos (desafio 5). Em caso de erro de validação, o controlador exibe novamente a visão que causou o erro. Componentes fornecidos pelo framework são usados na visão, para repovoar os campos preenchidos e exibir mensagens sobre os erros ocorridos. Quando não ocorre erro de validação, o controlador chama o comando que aciona a camada de negócios para modificar o modelo. Terminada a operação, o comando sinaliza para o controlador, através do valor de retorno, por exemplo, qual visão deve ser exibida e este finaliza a requisição mostrando esta visão. Para que o controlador extraia os dados da requisição e transforme-os em tipos específicos da instância, o framework fornece um mecanismo que mapeia os campos de um formulário a propriedades destes tipos. Este é o comportamento geral da maioria dos web frameworks disponíveis atualmente. Cada um deles implementa estas características a sua maneira, além de oferecer recursos extras. 4.4. Comparação Técnica entre Web Frameworks Com tantos web frameworks disponíveis no mercado, uma solução ad hoc para a camada de apresentação foi descartada. Faz-se necessário escolher 1 dentre Capitulo 4. A Camada de Apresentação 116 os 54 web frameworks disponíveis. Para poder escolher um deles, é preciso analisá-los e compará-los. Devido ao grande número de opções, sentiu-se a necessidade de realizar uma comparação mais aprofundada do que as comparações realizadas no capítulo 3. Contudo, analisar todos estes web frameworks seria excessivamente custoso e fugiria do escopo deste trabalho. Em vez disto, foram selecionados três: Struts, Spring MVC e JSF. Struts foi escolhido para ser analisado, pois como será visto em mais detalhes na seção 4.5, é o mais popular. Spring MVC foi escolhido porque o Spring já é usado para a camada de negócios. Usá-lo também para a camada de apresentação reduziria o esforço de aprendizado e possibilitaria uma melhor integração entre as camadas de negócios e apresentação. Por fim, JSF foi escolhido porque é um padrão da Sun Microsystems e define um modelo de componentes. Estes três frameworks podem ser usados com o Spring e o Hibernate, de forma que não há problemas decorrentes da integração. Nesta seção, estes três web frameworks são apresentados seguidos de uma comparação técnica entre eles. 4.4.1. Struts Por ter sido um dos primeiros web frameworks desenvolvidos, o Struts (2005) também é um dos mais populares entre os desenvolvedores. Contudo, o surgimento de tantos outros é um indicativo de que o Struts não satisfez completamente as necessidades das aplicações. Nesta seção é visto como o Struts implementa as funcionalidades comuns aos web frameworks. Comandos no Struts são chamados de Ações (Actions), que devem estender a classe org.apache.struts.action.Action ou uma de suas subclasses. Ações podem vir acompanhadas de Action Forms que são objetos que representam os dados de um formulário e que devem estender a classe org.apache.struts.action.ActionForm ou uma de suas subclasses. O mapeamento entre requisições e ações é feito através da URL da requisição. A configuração da URL que chama o servlet controlador do Struts, inserida no descritor web.xml da instância, deve conter uma parte fixa, que serve Capitulo 4. A Camada de Apresentação 117 para identificar o controlador do Struts, e uma parte variável, que identifica qual ação será executada. A Listagem 4.1 exibe um fragmento do descritor da aplicação que registra o controlador do Struts. O mapeamento realizado na linha 10, “*.do” indica que a parte fixa é “.do” e a parte variável é o que quer que venha antes. 01: <web-app> 02: <servlet> 03: <servlet-name>Struts Controller</servlet-name> 04: <servlet-class> 05: org.apache.struts.action.ActionServlet 06: </servlet-class> 07: </servlet> 08: <servlet-mapping> 09: <servlet-name>Struts Controller</servlet-name> 10: <url-pattern>*.do</url-pattern> 11: </servlet-mapping> 12: </web-app> Listagem 4.1 – Declaração do Controlador do Struts na Instancia (web.xml) Exemplo: uma requisição para http://aulanet.les.inf.puc- rio.br/postMessage.do, “http://aulanet.les.inf.puc-rio.br/” identifica o servidor que trata a requisição, “.do” identifica que o controlador do Struts será executado e “postMessage” identifica a ação que o controlador irá executar. Através do arquivo XML de configuração do Struts, que por padrão chamase struts-config.xml, a parte variável da URL é mapeada em ações. A Listagem 4.2 exibe um exemplo deste arquivo. Capitulo 4. A Camada de Apresentação 118 13: <struts-config> 14: <form-beans> 15: <form-bean name="postMessageForm" 16: type="br.puc-rio.inf.les.aulanet.PostMessageForm"/> 17: </form-beans> 18: <action-mappings> 19: <action 20: path="/postMessage" 21: type="br.puc-rio.inf.les.aulanet.PostMessageAction" 22: name="postMessageForm" 23: scope="request" validate="true" 24: input="/conference/postMessage.jsp"> 25: <forward 26: name="success" 27: path="/conference/postMessageSuccess.jsp"/> 28: <forward 29: name="failure" 30: path="/conference/postMessageFailure.jsp"/> 31: </action> 32: </action-mappings> 33: </struts-config> Listagem 4.2 – Descritor struts-config.xml Entre as linhas 19 e 31 encontra-se a definição de uma ação. Através do atributo path na linha 20, é indicado ao controlador do Struts que ação deve ser executada sempre que a parte variável da URL for “postMessage”. O atributo type na linha 21 identifica a classe que implementa a ação e que é chamada pelo controlador do Struts. A Listagem 4.3 mostra o exemplo de uma classe de ação. Capitulo 4. A Camada de Apresentação 119 34: public class PostMessageAction extends Action { 35: 36: 37: public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws ServletException { 38: PostMessageForm formBean = (PostMessageForm) form; 39: 40: 41: 42: 43: try { ConferenceFacade facade = new ConferenceFacadeImpl(); facade.postMessage(request.getRemoteUser(), formBean.getParentId(), formBean.getConferenceId(), formBean.getCategoryId(), formBean.getMessage()); 44: } catch (Exception e) { 45: return mapping.findForward("failure"); 46: } 47: return mapping.findForward("success"); 48: } 49: } Listagem 4.3 – Ação postMessage Na linha 38, a ação realiza uma conversão de tipo para o Action Form especificado na linha 22 do arquivo struts-config.xml (Listagem 4.2). Na linha 41, o Façade é instanciado. Na linha 41, a ação chama a camada de negócios para atualizar o modelo. Na linha 47, o controlador é notificado para mostrar a vista de sucesso ou, caso aconteça algum erro, a vista de fracasso na linha 45. O Action Form para esta ação, descrito entre as linhas 15 e 16 do descritor strutsconfig.xml, é exibido na Listagem 4.4. Capitulo 4. A Camada de Apresentação 120 50: public class PostMessageForm extends ValidatorForm { 51: 52: 53: 54: private String parentId; private String conferenceId; private String categoryId; private Message message; 55: 56: 57: 58: public void setParentId(String newValue) { parentId = newValue; } public String getParentId() { return parentId; } 59: 60: 61: 62: public void setConferenceId(String newValue) { conferenceId = newValue; } public String getConferenceId() { return conferenceId; } 63: 64: 65: 66: public void setCategoryId(String newValue) { categoryId = newValue; } public String getCategory() { return categoryId; } 67: public void setMessage(Message newValue) { 68: message = newValue; 69: } 70: public Message getMessage() { return message; } 71: } Listagem 4.4 – Action Form da ação postMessage O Action Form é uma classe que não precisa implementar nenhum método especial além dos métodos gets e sets que definem propriedades JavaBeans (2005). Na linha 50 é declarado que este Action Form estende a classe ValidatorForm, uma subclasse de ActionForm que possibilita o uso de validações declarativas no Struts. Usando o esquema de validação do Struts, são executadas validações tanto no lado do cliente quanto no lado do servidor através de regras declaradas em um arquivo descritor chamado validation.xml. A validação no lado do cliente é feita por JavaScript e evita que requisições desnecessárias sejam enviadas. Por outro lado, o JavaScript do navegador do usuário pode ser desabilitado então esta deve ser realizada também no lado do servidor, para garantir a integridade dos dados. A Listagem 4.5 exibe um exemplo de arquivo validation.xml. Capitulo 4. A Camada de Apresentação 121 72: <form-validation> 73: <formset> 74: <form name="postMessageForm"> 75: <field property="categoryId" depends="required"> 76: <msg name="required" key="postMessage.category.required"/> 77: <arg0 key="postMessageForm.categoryId"/> 78: </field> 79: <field property="conferenceId" depends="required"> 80: <msg name="required" key="postMessage.conference.required"/> 81: <arg0 key="postMessageForm.conferenceId"/> 82: </field> 83: <field property="message.subject" depends="required"> 84: <msg name="required" key="postMessage.message.subject.required"/> 85: <arg0 key="postMessageForm.message.subject"/> 86: </field> 87: <field property="message.text" depends="required"> 88: <msg name="required" key="postMessage.message.text.required"/> 89: <arg0 key="postMessageForm.message.text"/> 90: </field> 91: </form> 92: </form-set> 93: </form-validation> Listagem 4.5 – Regras de Validação (validation.xml) A linha 74 declara um conjunto de regras de validação para o Action Form postMessageForm. Os trechos entre as linhas 75 e 78 definem que o campo categoryId é requirido. Assim como os trechos entre as linhas 79 e 82, 83 e 86, 87 e 90 fazem o mesmo para os campos confereceId, message.subject e message.text. Há outras regras de validações não usadas neste exemplo, como por exemplo, validar a sintaxe de e-mails e URLs, validar se um número pertence a uma determinar faixa, dentre outras. O Struts também fornece um conjunto de bibliotecas de tags usadas nas páginas JSP que compõem a visão. Estas bibliotecas contêm tags que possibilitam o vínculo de campos de um formulário com atributos dos Action Forms e também tags especializadas em mostrar erros de validação. A Listagem 4.6 mostra como a página de envio de mensagens é construída, usando as tags do Struts. Capitulo 4. A Camada de Apresentação 122 094: <%@ taglib uri="http://jakarta.apache.org/struts/tags-html" prefix="html"%> 095: <%@ taglib uri="http://jakarta.apache.org/struts/tags-logic" prefix="logic"%> 096: <%@ taglib uri="http://jakarta.apache.org/struts/tags-bean" prefix="bean"%> 097: <html> 098: <head> 099: <title>Envio de Mensagem</title> 100: <html:javascript formName="PostMessageForm"/> 101: </head> 102: <body> 103: <html:form action="/postMessage" method="POST" 104: onsubmit="return validatePostMessageForm(this);"> 105: <html:hidden property="conferenceId" value="${param.conferenceId}"/> 106: <html:hidden property="messageId" value="${param.messageId}"/> 107: <logic:messagesPresent> 108: <html:messages id="error"> 109: <bean:write name="error"/> 110: </html:messages> 111: </logic:messagesPresent> 112: Categoria: 113: <html:select property="categoryId"> 114: <html:option value="1">Questão</html:option> 115: <html:option value="2">Seminário</html:option> 116: <html:option value="3">Argumentação</html:option> 117: </html:select><br> 118: Assunto: 119: <html:text property="message.subject" size="83" maxlength="100" /><br> 120: Mensagem: <br> 121: <html:textarea property="message.text" cols="65" rows="16" style="wrap" /> 122: </html:form> 123: </body> 124: </html> Listagem 4.6 – Página de Envio de Mensagens Entre as linhas 094 e 096 é feita a declaração das bibliotecas de tags do Struts. Na linha 100 a tag html:javascript gera o código JavaScript responsável pela validação no lado cliente. Já na linha 103 a tag html:form gera o formulário que submete a requisição da ação postMessage. É importante notar que na linha 104, a propriedade onsubmit é definida com o valor validatePostMessageForm(this). Se este atributo não for configurado desta forma, o código de validação no lado cliente é gerado, mas nunca executado. O trecho de código entre as linhas 107 e 111 geram a lista de erros de validação. A tag logic:messagesPresent é usada para evitar que uma lista sem itens seja exibida quando não há erros de validação. A tag html:messages é usada para Capitulo 4. A Camada de Apresentação 123 iterar sobre a lista de erros de validação. Finalmente a tag bean:write, é usada para escrever a mensagem de erro na página. Nota-se na listagem 4.6 que cada uma das tags de formulário HTML (<form>, <input>, etc.) possui uma tag análoga na biblioteca de tags HTML do Struts. Estas tags são responsáveis por criar o vinculo entre o campo do formulário e a propriedade do Action Form. 4.4.2. Spring MVC O Spring (2005), apresentado no capítulo 3 e que foi escolhido para ser usado na camada de negócios possui um módulo que implementa o MVC. Desta forma, é um candidato natural a ser usado também na camada de apresentação. Os comandos no Spring MVC recebem o mesmo nome do controlador do Model View Controller e devem implementar a interface org.springframework.web.servlet.mvc.Controller. Geralmente não é necessário implementar esta interface diretamente. O Spring MVC possui classes apropriadas para situações específicas, como a submissão de um formulário web (classe SimpleFormController) ou então um conjunto de telas no formato de Wizard (classe AbstractWizardFormController). Ambas estão localizadas no pacote org.springframework.web.servlet.mvc. De forma similar ao Struts, os controladores do Spring MVC podem vir acompanhados de classes que representam os dados submetidos em um formulário. Estas classes recebem o nome de Comandos (Commands) no Spring MVC. Este termo é inadequado, pois remete ao padrão de projeto Comando (Gamma et al., 1995). Para preservar a clareza do texto, nesta dissertação os comandos do Spring MVC serão chamados de beans de formulário. O mapeamento entre requisições e controladores é feito de forma similar ao Struts. O servlet controlador é associado a uma URL com uma parte fixa e outra variável. A parte fixa serve para especificar que o servlet controlador do Spring MVC deve ser executado. A parte variável serve para identificar qual controlador deve ser executado. A Listagem 4.7 exibe o mapeamento do servlet controlador no descritor da aplicação web.xml. Nota-se que o mapeamento realizado na linha Capitulo 4. A Camada de Apresentação 124 08, “*.spring”, indica que a parte fixa é “.spring” e a parte variável é o que quer que venha antes. 01: <web-app> 02: <servlet> 03: <servlet-name>SpringDispatcher</servlet-name> 04: <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> 05: </servlet> 06: <servlet-mapping> 07: <servlet-name>SpringDispatcher</servlet-name> 08: <url-pattern>*.spring</url-pattern> 09: </servlet-mapping> 10: </web-app> Listagem 4.7 - Declaração do Controlador do Spring MVC na Instancia (web.xml) Exemplo: em uma requisição enviada para http://aulanet.les.inf.puc- rio.br/postMessage.spring, “http://aulanet.les.inf.puc-rio.br/” identifica o servidor que atende a requisição, “.spring” identifica que o controlador do Spring MVC será executado e “postMessage” identifica que o controlador associado a ação “postMessage” será executado. Através do arquivo XML de configuração do Spring MVC mostrado na Listagem 4.8 a parte variável da URL é mapeada aos controladores. Capitulo 4. A Camada de Apresentação 125 11: <beans> 12: <bean id="postMessageController" 13: class="br.pucrio.inf.les.aulanet.PostMessageController"> 14: <property name="conferenceFacade"> 15: <ref bean="conferenceFacade"/> 16: </property> 17: <property name="formView"> 18: <value>/protected/conference/postMessage.jsp</value> 19: </property> 20: <property name="successView"> 21: <value>/conference/postMessageSuccess.jsp</value> 22: </property> 23: <property name="failureView"> 24: <value>/conference/postMessageFailure.jsp</value> 25: </property> 26: <property name="validator"> 27: <bean class="br.pucrio.inf.les.aulanet.PostMessageValidator"/> 28: </property> 29: </bean> 30: <bean id="urlMapping" 31: class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> 32: <property name="mappings"> 33: <props> 34: <prop key="/postMessage.spring">postMessageController</prop> 35: </props> 36: </property> 37: </bean> 38: </beans> Listagem 4.8 - Descritor SpringDispatcher-servlet.xml Este arquivo por padrão chama-se <Nome da Servlet>-servlet.xml, onde <Nome da Servlet> é o nome da servlet declarado na linha 03 da Listagem 4.7. Na linha 34 da Listagem 4.8 a requisição “postMessage” é mapeada para o controlador de nome “postMessageController”, declarado no mesmo arquivo entre as linhas 12 e 29. Neste exemplo são configuradas cinco propriedades importantes do controlador: entre as linhas 14 e 16 é configurado o Façade usado para executar a lógica de negócios. Entre as linhas 17 e 19 é configurado a página de entrada, ou seja, a tela que origina a requisição. Entre as linhas 20 e 22 é configurada a página de sucesso, exibida quando a operação é executada corretamente. Por fim, entre as linhas 23 e 25 é configurada a página de erros, executada quando ocorre algum problema durante o acesso à camada de negócios. Entre as linhas 26 e 28 o controlador é mapeado ao seu validador, que será explicado mais adiante. Vale ressaltar que a sintaxe usada neste descritor é a mesma dos descritores dos outros módulos do Spring usados na camada de Capitulo 4. A Camada de Apresentação 126 negócios. O controlador associado à requisição postMessage é mostrado na Listagem 4.9. 39: public class PostMessageController extends SimpleFormController { 40: 41: private ConferenceFacade confFacade; private String failureView; 42: 43: 44: public PostMessageController() { setCommandClass(Message.class); } 45: 46: 47: 48: 49: 50: public void setConferenceFacade(ConferenceFacade newValue) { confFacade = newValue; } public void setFailureView(String newValue) { failureView = newValue; } 51: 52: 53: 54: protected ModelAndView onSubmit(HttpServletRequest request, HttpServletResponse response, Object command, BindException errors) throws Exception { Message message = (Message) command; 55: 56: 57: 58: 59: 60: 61: 62: 63: } 64: } try { facade.postMessage(request.getRemoteUser(), message.getParentId(), message.getConferenceId(), message.getCategoryId(), message); } catch (Exception e) { return new ModelAndView(failureView); } return new ModelAndView(getSuccessView()); Listagem 4.9 – Controlador Associado à Requisição postMessage Na linha 39 da Listagem 4.9 a classe do controlador estende a classe SimpleFormController, indicando que este controlador responde à submissão de um formulário. As linhas 40 e 41 apresentam as propriedades para, respectivamente, o Façade e a página exibida quando ocorre erro. Os métodos de acesso para estas propriedades são definidos entre as linhas 45 e 50. Na linha 43, o bean de formulário Message é associado a este controlador. Entre as linhas 51 e 63 encontra-se o código do controle que é executado quando o formulário é submetido. Primeiro, é realizada uma conversão de tipos na Capitulo 4. A Camada de Apresentação 127 linha 54. Depois, o Façade é chamado na linha 56. Diferentemente do Struts, o Façade é configurado através de Dependency Injection ao invés de ser instanciado, o que leva a um menor acoplamento entre a camada de apresentação e a implementação da camada de negócios. Se a operação for bem sucedida, é retornado um objeto ModelAndView que encapsula o modelo e a visão apontando para a tela de sucesso (linha 62). Se ocorrer algum erro durante a execução da lógica de negócios, a tela de erros é exibida (linha 60). Diferentemente do Struts, os beans de formulário no Spring MVC não estendem uma classe do framework. Dessa forma, os beans de formulário não possuem dependências com o Spring MVC, podendo inclusive ser reusadas classes do modelo como beans de formulário sempre que for adequado. A Listagem 4.10 mostra o bean de formulário usado pelo controlador postMessage. 65: public class Message { 66: 67: 68: 69: 70: private String parentId; private String conferenceId; private String categoryId; private String message; private String subject; 71: 72: public void setParentId(String newValue) { parentId = newValue; } public String getParentId() { return parentId; } 73: 74: public void setConferenceId(String newValue) { conferenceId = newValue; } public String getConferenceId() { return conferenceId; } 75: 76: public void setCategoryId(String newValue) { categoryId = newValue; } public String getCategory() { return categoryId; } 77: 78: public void setMessage(String newValue) { message = newValue; } public String getMessage() { return message; } 79: public void setSubject(String newValue) { subject = newValue; } 80: public String getSubject() { return subject; } 81: } Listagem 4.10 – Bean de Formulário Associado ao Controlador postMessage Com relação a validação, quando este capítulo foi escrito em novembro de 2005, o esquema de validação do Spring MVC não se encontrava num estado de maturidade tão elevado quanto o do Struts. Além de não oferecer validação no Capitulo 4. A Camada de Apresentação 128 lado do servidor, o esquema do Spring MVC não é baseado em regras descritivas, ou seja, a validação precisa ser programada e associada à classe do controlador. Atualmente há uma iniciativa para se criar um esquema de validação similar ao do Struts para o Spring MVC, mas ainda não há previsão de quando haverá uma versão estável. A Listagem 4.11 mostra a classe de validação para o controlador postMessage. 82: public class SendMessageValidator implements Validator { 83: 84: 85: public boolean supports(Class clazz) { return clazz.equals(Message.class); } 86: 87: 88: 89: 90: 91: 92: 93: 94: public void validate(Object command, Errors errors) { ValidationUtils.rejectIfEmptyOrWhitespace(errors, "categoryId", "postMessage.categoryId.required", "Category empty."); ValidationUtils.rejectIfEmptyOrWhitespace(errors, "conferenceId", "postMessage.conference.required", "Conference empty."); ValidationUtils.rejectIfEmptyOrWhitespace(errors, "message", "postMessage.message.required", " Message empty."); ValidationUtils.rejectIfEmptyOrWhitespace(errors, "subject", "postMessage.subject.required", "Subject empty."); 95: } 96: } Listagem 4.11 – Classe de Validação para o Controlador postMessage Na linha 84 o validador especifica os tipos de beans de formulário que ele valida, neste caso apenas o bean Message. Nas linhas 87 e 88 é validado se o campo categoryId é vazio. O mesmo é feito nas linhas 89 e 90 para a propriedade conferenceId, nas linhas 91 e 92 para a propriedade message e nas linhas 93 e 94 para a propriedade subject. O Spring MVC também oferece um conjunto de tags usadas para exibir mensagens de erro de validação na camada de apresentação, mas ao contrário do Struts, possibilita que sejam usadas as tags do próprio HTML para gerar os campos de entrada dos formulários. O vínculo entre as propriedades dos beans de formulário e o formulário é feito com outras tags do Spring MVC. Esta abordagem deixa as telas da camada de apresentação menos acopladas com o web Capitulo 4. A Camada de Apresentação 129 framework. A Listagem 4.12 exibe o código fonte da página de envio de mensagens. 097: <%@ taglib uri="http://www.springframework.org/tags" prefix="spring" %> 098: <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> 099: <html> 100: <head><title>Envio de Mensagem</title></head> 101: <body> 102: <form action="sendMessage.spring" method="POST"> 103: <spring:bind path="command.conferenceId"> 104: <input type="hidden" name='<c:out value="${status.expression}"/>' 105: value='${param.conferenceId}'/> 106: </spring:bind> 107: <spring:bind path="command.parentId"> 108: <input type=hidden name='<c:out value="${status.expression}"/>' 109: value='${param.messageId}'/> 110: </spring:bind> 111: <spring:hasBindErrors name="command"> 112: <ul> 113: <c:forEach items="${errors.allErrors}" var="error"> 114: <li><spring:message 115: code="${error.code}" 116: text="${error.defaultMessage}" 117: arguments="${error.arguments}"/></li> 118: </c:forEach> 119: </ul> 120: </spring:hasBindErrors> 121: Categoria: 122: <spring:bind path="command.categoryId"> 123: <select name='<c:out value="${status.expression}"/>'> 124: <option value="1">Questão</option> 125: <option value="2">Seminário</option> 126: </select><br> 127: </spring:bind> 128: Assunto: 129: <spring:bind path="command.subject"> 130: <input type="text" name='<c:out value="${status.expression}"/>' 131: value='<c:out value="${status.value}"/>' 132: size="83" maxlength="100"/> 133: </spring:bind> 134: Mensagem: <br> 135: <spring:bind path="command.message"> 136: <textarea name='<c:out value="${status.expression}"/>' rows="15" 137: cols="60" cols=65 rows=16 wrap> 138: <c:out value="${status.value}"/> 139: </textarea> 140: </spring:bind> 141: </form> 142: </body> 143: </html> Listagem 4.12 - Página de Envio de Mensagem Capitulo 4. A Camada de Apresentação 130 Nota-se o uso constante da tag spring:bind, que é usada para vincular as propriedades do bean de formulário aos campos do formulário html. Outro ponto que deve ser observado é o uso das tag spring:hasBindErrors e spring:message usadas para listar os erros de validação quando estes houverem. 4.4.3. JavaServer Faces JavaServer Faces (JSF, 2005) é diferente dos web frameworks apresentados até então pois além de ser um framework de infra-estrutura, também pode ser classificado como um framework de componentes, pois define um modelo de componentes para serem usados na camada de apresentação. Há três tipos principais de componentes no JSF: componentes de interface, usado para compor interfaces com o usuário, componentes de conversão de dados, usados para converter os dados inseridos pelo usuário em tipos da aplicação e componentes de validação de dados, usados para validar a entrada do usuário. JSF vem com um conjunto padrão de componentes, que podem ser estendidos. Os comandos no JSF recebem o nome de backing beans ou managed beans. Estes não precisam implementar interfaces específicas ou estender classes, bastando que o método do comando seja público, não receba parâmetros e tenha o tipo de retorno String. Componentes de interface vinculam hyperlinks ou botões a ações de comando. Os backing beans contém os dados dos formulários relacionados de forma que não é necessário criar classes extras, como beans de formulário ou Action Forms para isto. O mapeamento entre requisições e controladores é feito através de campos escondidos em formulários, inseridos automaticamente pelos componentes de comando. Assim como no Spring MVC e no Struts, as URLs de requisição são divididas em uma parte fixa e uma parte variável. A parte fixa serve para associar a URL de requisição ao Servlet controlador do JSF e a parte variável da URL serve para identificar qual página JSP que contém componentes JSF será executada. A Listagem 4.13 exibe o mapeamento do servlet controlador no descritor da aplicação web.xml. Nota-se que o mapeamento realizado na linha 08, “*.jsf”, indica que a parte fixa é “.jsf” e a parte variável é o que quer que venha antes. Capitulo 4. A Camada de Apresentação 131 01: <web-app> 02: <servlet> 03: <servlet-name>Faces Servlet</servlet-name> 04: <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> 05: </servlet> 06: <servlet-mapping> 07: <servlet-name>Faces Servlet</servlet-name> 08: <url-pattern>*.jsf</url-pattern> 09: </servlet-mapping> 10: </web-app> Listagem 4.13 - Declaração do Controlador do JSF na Instancia (web.xml) Exemplo: em uma requisição enviada para http://aulanet.les.inf.pucrio.br/postMessage.jsf, “http://aulanet.les.inf.puc-rio.br/” identifica o servidor que atende a requisição, “.jsf” identifica que o controlador do JSF será executado e “postMessage” identifica a página JSP com componentes JSF associados solicitada. Através do arquivo XML de configuração do JSF são configurados casos de navegação, backing beans, componentes de validação e de conversão de tipos. A Listagem 4.14 exibe um exemplo deste arquivo, que tem como nome padrão faces-config.xml. Capitulo 4. A Camada de Apresentação 132 11: <faces-config> 12: <navigation-rule> 13: <from-view-id>/conference/postMessage.jsp</from-view-id> 14: <navigation-case> 15: <from-outcome>success</from-outcome> 16: <to-view-id>/conference/postMessageSuccess.jsp</to-view-id> 17: </navigation-case> 18: <navigation-case> 19: <from-outcome>failure</from-outcome> 20: <to-view-id>/conference/postMessageFailure.jsp</to-view-id> 21: </navigation-case> 22: </navigation-rule> 23: <managed-bean> 24: <managed-bean-name>messageController</managed-bean-name> 25: <managed-bean-class>MessageController</managed-bean-class> 26: <managed-bean-scope>request</managed-bean-scope> 27: <managed-property> 28: <property-name>conferenceId</property-name> 29: <value>#{param['conferenceId']}</value> 30: </managed-property> 31: <managed-property> 32: <property-name>parentId</property-name> 33: <value>#{param['parentId']}</value> 34: </managed-property> 35: </managed-bean> 36: </faces-config> Listagem 4.14 – Arquivo de Configuração faces-config.xml Entre as linhas 12 e 22 são declarados dois casos de navegação a partir da página /conference/postMessage.jsp. O caso entre as linhas 14 e 17 é executado quando a operação é executada com sucesso enquanto que o caso entre as linhas 18 e 21 é executado quando ocorre algum erro durante a execução da operação. O backing bean responsável pelo comando postMessage é declarado entre as linhas 23 e 37. Na linha 24 o nome do backing bean é definido, enquanto que na linha 25 é configurada a classe. Nota-se também que este bean tem duas propriedades gerenciadas (managed properties) definidas entre as linhas 27 e 34. O JSF se encarrega de configurar estas propriedades em tempo de execução, antes de executar o método do backing bean. A Listagem 4.15 exibe o código fonte deste backing bean. Capitulo 4. A Camada de Apresentação 133 37: public class MessageController { 38: 39: 40: 41: private String parentId; private String conferenceId; private String categoryId; private Message message; 42: 43: 44: 45: 46: 47: 48: 49: public void setParentId(String newValue) { parentId = newValue; } public String getParentId() { return parentId; } public void setConferenceId(String newValue) { conferenceId = newValue; } public String getConferenceId() { return conferenceId; } public void setCategoryId(String newValue) { categoryId = newValue; } public String getCategoryId() { return categoryId; } public void setMessage(Message message) { message = newValue; } public Message getMessage() { return message; } 50: public String postMessage() { 51: 52: 53: 54: 55: 56: 57: 58: 59: 60: } 61: } try { ConferenceFacade facade = new ConferenceFacadeImpl(); FacesContext ctx = FacesContext.getCurrentInstance(); String author = ctx.getExternalContext().getRemoteUser(); facade.postMessage(author, parentId, conferenceId, categoryId, message); } catch (Exception e) { return "failure"; } return "success"; Listagem 4.15 – Backing Bean do Comando postMessage Entre as linhas 38 e 41 são declaradas as propriedades parentId, conferenceId, categoryId e message e entre as linhas 42 e 49 são declarados os métodos de acesso a estas propriedades. O método que executa o comando é declarado entre as linhas 50 e 60. Na linha 52, a referência para o Façade que acessa a camada de negócios é obtida. Na linha 54, é recuperado o nome de usuário logado a partir do contexto Faces recuperado na linha 53. A lógica de negócios é executada na linha 55 e, caso haja sucesso, o comando aciona o caso de navegação “success” (linha 59). Se houver algum erro na execução da lógica de negócios, a tela de erro é acionada (linha 57). Apesar de não precisar implementar interfaces especificas do JSF, o backing bean não está totalmente desacoplado do framework. Na linha 53, o contexto Capitulo 4. A Camada de Apresentação 134 faces (FacesContext) é recuperado para posteriormente o nome do usuário logado ser recuperado. A declaração das regras de validação assim como o vínculo entre campos de formulário e propriedades do backing bean, e entre os componentes de comando e os métodos de comando nos backing beans são feitas no arquivo JSP. A Listagem 4.16 mostra a página JSP usada no comando postMessage. 62: <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 63: <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 64: <f:view> 65: <html> 66: <head> 67: <title>Envio de Mensagem</title> 68: </head> 69: <body> 70: <h:form> 71: <h:inputHidden id="conferenceId" value="#{param['conferenceId']}"/> 72: <h:inputHidden id="parentId" value="#{param['parentId']}"/> 73: <h:messages/><br> 74: Categoria: 75: <h:selectOneListbox value="#{messageController.categoryId}" 76: required="true"> 77: <f:selectItem itemLabel="Questão" itemValue="1"/> 78: <f:selectItem itemLabel="Seminário" itemValue="2"/> 79: <f:selectItem itemLabel="Argumentação" itemValue="3"/> 80: </h:selectOneListbox><br> 81: Assunto: 82: <h:inputText value="#{messageController.message.subject}" 83: size="83" maxlength="100" required="true"> 84: <f:validateLength minimum="10"/> 85: </h:inputText><br> 86: Mensagem: <br> 87: <h:inputTextarea value="#{messageController.message.text}" rows="15" cols="60" cols="65" rows="16" 88: required="true"/> 89: </h:form> 90: </body> 91: </html> 92: </f:view> Listagem 4.16 – Página de Envio De Mensagens (JSF) As bibliotecas de tags definidas nas linhas 62 e 63 possibilitam que JSF seja usado em conjunto com JSP. A tag f:view (linha 64) serve para demarcar árvore de componentes JSF. A tag h:form (linha 70) é usada para definir um formulário Capitulo 4. A Camada de Apresentação 135 de dados. As linhas 71 e 72 inserem campos escondidos, com as propriedades conferenceId e parentId. Expressões delimitadas por “#{“ e “}” demarcam o uso da linguagem de expressões do JSF e servem para criar vínculos. No caso destas expressões, o uso de “#{param[’nome-do-parametro’]}” indica o vínculo do valor dos componentes com as propriedade de requisição indicadas pelo nome “nomedo-parametro”. O item entre as linhas 75 e 80 delimita um componente do tipo lista onde apenas um item pode ser selecionado. O atributo value na linha 75 vincula o valor do item selecionado a propriedade categoryId do backing bean messageController. Ainda na linha 75, o atributo required=”true” demarca que o atributo é requerido, gerando regras de validação automaticamente. JSF ainda não gera regras de validação do lado do cliente, mas há como integrar o módulo de validação no lado cliente do Struts ao JSF, conforme descrito em Geary & Horstmann (2005). A linha 84 indica uma validação de tamanho mínimo, indicando que o campo associado a esta só será válido se tiver um tamanho mínimo de 10 caracteres. JSF possibilita que novos componentes sejam criados caso os componentes padrão não satisfaçam as necessidades da aplicação. Projetos como o MyFaces (2005) e WebGalileo Faces (WebGalileo, 2005) disponibilizam componentes, como por exemplo, um que possibilita que o usuário selecione uma data em um calendário (Figura 4.3) ou um que apresenta um editor de textos HTML estilo What You See Is What You Get (Figura 4.4), que já foi solicitado por diversos usuários do AulaNet (Barreto et al., 2005). Figura 4.3 - Calendário Figura 4.4 - Editor HTML Além disso, JSF foi desenvolvido visando à integração com ferramentas de produtividade. Consequentemente há uma boa quantidade de ferramentas Capitulo 4. A Camada de Apresentação 136 compatíveis com JSF no mercado conforme descrito na seção 4.5.3, apesar deste ser o mais novo dos 3 web frameworks analisados. 4.4.4. Resultado da Análise Técnica Após analisar tecnicamente os web frameworks Struts, Spring MVC e JSF percebe-se que cada um tem suas vantagens e desvantagens. Struts é o mais antigo dos três e, portanto, o mais maduro. Seu módulo de validação baseado em regras capaz de validar dados tanto no lado do cliente quanto no servidor é sua principal vantagem. Entretanto, o Struts força um grau elevado de acoplamento entre a camada de apresentação e o web framework usado ao impor que tanto Actions quanto Action Forms estendam classes próprias do frameworks. Além disso, o Struts exige que sejam criadas classes específicas para representar os dados inseridos em formulários, mesmo quando uma classe do modelo é mais apropriada. Spring MVC por outro lado apresenta um fraco grau de acoplamento. Os beans de formulário não precisam estender classes ou implementar classes do framework, podendo ser aproveitadas classes do modelo para esta função. Spring MVC também fornece a melhor solução para integração entre os controladores na camada de apresentação e os Façades na camada de negócios, através de Dependency Injection (Fowler, 2004). Contudo, seu mecanismo de validação é sua principal desvantagem, sendo o pior dos 3 analisados. JSF se difere dos três por ser um framework de componentes. JSF não possui um grau de acoplamento tão forte quanto o Struts e nem tão fraco quanto o o Spring MVC. Seu módulo de validação é baseado em regras, como o do Struts, mas não fornece validação do lado do cliente. O que torna JSF a escolha técnica mais adequada ao AulaNet 3.0 é o fato dele ser um framework de componentes. JSF possibilita que componentes de interfaces sejam criados e aproveitados (desafio 6). Além disso, como foi visto em seções anteriores, já há um mercado de componentes compostos por projetos gratuitos (por exemplo, MyFaces (2005) e WebGalileo Faces (WebGalileo, 2005)) e comerciais (por exemplo, WebCharts (2005)) que complementam o conjunto padrão de componentes JSF, diminuindo a necessidade de criar novos. Capitulo 4. A Camada de Apresentação 137 JSF apresenta um custo inicial de adoção superior aos dos outros web frameworks analisados, pois exige que componentes sejam criados. Este custo é inerente à abordagem de desenvolvimento baseado a componentes e é reduzido à medida que o projeto evolui até atingir massa crítica, quando há componentes de variedade suficiente e quando a necessidade de criar um novo componente diminui (Szyperski, 1997). Como o AulaNet encontra-se em constante desenvolvimento espera-se que após a massa crítica ser atingida o custo do desenvolvimento com JSF seja menor do que com os outros web frameworks. Apesar de não gerar validação no lado do cliente, principal vantagem do Struts, há maneiras de usar este esquema de validação junto com o JSF caso seja necessário (Geary & Horstmann, 2005). Quanto ao seu grau de acoplamento superior ao do Spring MVC não é um motivo suficientemente forte para abandoná-lo tendo em vista suas outras vantagens. Somente a comparação técnica entre frameworks não é suficiente para tomar a decisão sobre qual dos web frameworks é mais adequado às necessidades de um projeto. No caso do AulaNet, como foi visto anteriormente, deve se levar em conta que ele é desenvolvido por alunos de graduação, mestrado e doutorado no Laboratório de Engenharia de Software da PUC-Rio e que EduWeb realiza customizações para seus clientes. Na próxima seção são analisados os seguintes fatores não-técnicos: como, por exemplo, a documentação disponível sobre cada web framework e a quantidade de profissionais habilitados a trabalhar com este web framework. Ao considerar estes fatores, evita-se a escolha de um web framework com custo de adoção proibitivo para o LES ou para a EduWeb. 4.5. Comparação Não-Técnica entre Web Frameworks Além de analisar como os web frameworks funcionam tecnicamente, a escolha do web framework mais adequado para um projeto deve levar em considerações outros fatores, como: quantidade de documentação disponível, disponibilidade de suporte (seja um suporte oficial ou da comunidade que usa o framework), disponibilidade de ferramentas compatíveis, grau de aceitação de mercado e disponibilidade de profissionais com habilidades nos frameworks. Raible (2005) apresenta dados importantes que ajudarão esta análise, comparando Capitulo 4. A Camada de Apresentação 138 os frameworks que foram analisados tecnicamente na seção 4.4 e mais outros 3 web frameworks: Cocoon (2005), WebWork (2005) e Tapestry (2005). Para uma análise mais precisa dos dados, foi necessário realizar comunicação pessoal com o autor que gentilmente cedeu os dados de sua pesquisa. Além disso, Matt Raible forneceu atualizações nos dados referentes à disponibilidade de suporte. As transcrições dos e-mails trocados com Raible estão disponíveis no apêndice A. 4.5.1. Quantidade de Documentação Disponível Para medir a quantidade da documentação disponível faz-se uma pesquisa na quantidade de livros publicados e de tutoriais escritos sobre cada web framework. O resultado da pesquisa realizada por Raible (2005) no verão (hemisfério norte) de 2005 é apresentado na Figura 4.5 e Figura 4.6. 35 30 25 20 15 10 5 0 Cocoon Struts Spring MVC WebWork JSF Tapestry Figura 4.5 - Número de Livros Publicados Fonte: Amazon.com (Raible, 2005), Verão de 2005 (hemisfério norte) Há mais livros publicados sobre o Struts, com JSF vindo em segundo lugar e Spring MVC em terceiro. A Figura 4.6 mostra o número de tutoriais disponíveis na web para cada web framework segundo a pesquisa realizada no Google por Raible (2005) no verão de 2005 (hemisfério norte). Capitulo 4. A Camada de Apresentação 139 7500 6000 4500 3000 1500 0 Cocoon Struts Spring MVC WebWork JSF Tapestry Figura 4.6 - Número de Tutoriais escritos Fonte: Google.com (Raible, 2005), Verão de 2005 (hemisfério norte) Struts tem cerca de 7 mil artigos e tutoriais disponíveis na web, com o JSF vindo em segundo lugar com cerca de 620 e seguido por Tapestry e Cocoon praticamente empatados, com aproximadamente 570 artigos e tutoriais disponíveis cada um. Nota-se que há uma quantidade significantemente maior de documentação disponível sobre o Struts, muito provavelmente devido a este ter sido um dos primeiros web frameworks a serem criados, com o JSF vindo em segundo lugar. 4.5.2. Disponibilidade de Suporte Ao optar por um web framework é importante ter disponível algum tipo de suporte, para solucionar questões não respondidas em livros e tutoriais. Todos os web frameworks analisados têm comunidades ativas que oferecem suporte gratuitamente. A Figura 4.7 mostra a quantidade de mensagens trocadas sobre cada web framework nas listas de discussões mantidas pelas comunidades segundo a pesquisa realizada por Raible (2005) em julho de 2005. Capitulo 4. A Camada de Apresentação 140 2500 2000 1500 1000 500 0 Cocoon Struts WebWork Tapestry MyFaces Figura 4.7 – Mensagens Trocadas em Listas de Discussão (Julho/2005) (Raible, 2005) A comunidade mais ativa é a do Struts com cerca de 2200 mensagens, sendo seguida pela comunidade do Tapestry com cerca de 1400 mensagens e depois pelas comunidades do MyFaces (implementação de JSF do grupo Jakarta) com aproximadamente 1000 mensagens. Nota-se que Spring MVC não aparece entre os listados. Isto porque o suporte do Spring MVC é feito através de um fórum, que não fornece meios de amostrar a quantidade de mensagens trocadas em determinado mês. Ainda que pudesse se amostrar o volume de e-mails trocados na lista de discussão não oficial do Spring (como feito no capítulo 4) não haveria como distinguir quantas mensagens dizem respeito ao módulo MVC do Spring e quantas dizem respeito aos outros módulos. Todavia, além do suporte prestado no fórum o Spring conta com suporte comercial prestado pela empresa Interface 21 (2005). 4.5.3. Disponibilidade de Ferramentas Compatíveis Ferramentas compatíveis com um web framework auxiliam o desenvolvimento, diminuindo a necessidade de produção de código repetitivo que passa a ser feito pela ferramenta. A Figura 4.8 mostra o número de ferramentas disponíveis compatíveis com cada web framework, segundo pesquisa realizada por Raible (2005) no verão de 2005 (hemisfério norte). Capitulo 4. A Camada de Apresentação 141 16 14 12 10 8 6 4 2 0 Cocoon Struts Spring MVC WebWork Tapestry JSF Figura 4.8 – Ferramentas Compatíveis (Raible, 2005), Verão de 2005 (hemisfério norte) Percebe-se que há mais ferramentas compatíveis com JSF, o que não é surpresa já que o JSF é um padrão aberto que foi desenvolvido objetivando compatibilidade com ferramentas de produtividade. Logo em seguida vem o Struts e em terceiro lugar o Spring MVC. 4.5.4. Grau de Aceitação no Mercado Ao analisar o grau de aceitação que um web framework recebe no mercado pode ser inferido o rumo que a comunidade está tomando e desta forma, evitar uma decisão destoante da realidade do mercado. Para analisar o grau de aceitação de um web framework foi feita uma pesquisa nas ofertas de empregos que exigem conhecimento em cada um dos frameworks. A tendência do mercado pode ser observada ao comparar a variação do grau de aceitação dos web Frameworks em vários períodos de tempo. Para analisar este critério Raible (2005) faz uma busca no site de empregos Dice.com. Os dados da pesquisa referem-se aos meses de outubro de 2004 e junho de 2005. Realizando uma busca em novembro de 2005 no mesmo site e reproduzindo o experimento de Raible complementei os dados da pesquisa com valores mais atuais. A Figura 4.9 mostra o resultado da pesquisa. Capitulo 4. A Camada de Apresentação 142 1750 1500 1250 Outubro de 2004 1000 Junho de 2005 750 Novembro de 2005 500 250 0 Cocoon Struts Spring MVC WebWork Tapestry JSF Figura 4.9 - Oferta de Empregos nos Meses 10/2004, 7/2005 e 11/2005 Fonte: Dice.com, 10/2004, 07/2005 (Raible, 2005) e 11/2005 Percebe-se claramente que o Struts é o framework mais mencionado em ofertas de empregos no site Dice.com, mas que JSF foi o web framework cujo número de ofertas de emprego mais cresceu ao longo do período analisado. Estes dados representam à realidade do mercado norte-americano. Uma busca feita em novembro de 2005 no site brasileiro Manager Online (http://www.manageronline.com.br/) revela a realidade do mercado nacional (figura 4.11). 60 50 40 30 20 10 0 Cocoon Struts Spring MVC WebWork Figura 4.10 – Ofertas de Emprego Fonte: Manager Online, Outubro de 2005 Tapestry JSF Capitulo 4. A Camada de Apresentação 143 Novamente há uma discrepância entre o número de vagas disponíveis que pedem conhecimentos em Struts e as que pedem conhecimento dos outros web frameworks. Spring MVC encontra-se em segundo lugar com uma vantagem pouco significativa sobre JSF. 4.5.5. Disponibilidade de Profissionais Antes de escolher um web framework é importante conhecer a disponibilidades de mão de obra no mercado de trabalho que esteja preparada para trabalhar com o framework. Escolher um web framework pouco conhecido implicará em custos de treinamento de pessoal. Para avaliar a disponibilidade de profissionais habilitados a lidar com estes frameworks foi feito uma pesquisa em sites que hospedam currículos. A Figura 4.11 mostra uma pesquisa feita em junho de 2005 por Raible (2005) no site Jobs.net que reflete a realidade do mercado norte-americano. 700 600 500 400 300 200 100 0 Cocoon Struts Spring MVC WebWork JSF Tapestry Figura 4.11 - Disponibilidade de Profissionais com Habilidades nos Frameworks Fonte: Monster.com, Junho de 2005 (Raible, 2005) Struts segue com clara liderança seguido pelo Spring e JSF que seguem empatados. A figura abaixo mostra uma pesquisa similar realizada no site brasileiro APInfo.com em novembro de 2005, revelando a disponibilidade de profissionais com habilidades nos web frameworks no mercado nacional. Capitulo 4. A Camada de Apresentação 144 700 600 500 400 300 200 100 0 Cocoon Struts Spring MVC WebWork JSF Tapestry Figura 4.12 - Disponibilidade de Profissionais com Habilidades nos Frameworks Fonte: APInfo.com, Novembro de 2005 O gráfico da Figura 4.12 mostra que, no Brasil, Struts também é o web framework com mais profissionais aptos disponíveis no mercado de trabalho. O JSF ocupa a segunda colocação com uma pequena vantagem sobre o Spring MVC. Nota-se também que a quantidade de profissionais no Brasil e nos EUA é muito próxima, enquanto que nas pesquisas para as outras categorias de frameworks encontrou-se um número menor de profissionais aptos no Brasil. Isto pode ter ocorrido por diversos motivos: os profissionais brasileiros utilizam mais os web frameworks do que frameworks ORM e frameworks para Dependency Injection; os dados de Raible (2005) são referentes a junho de 2005 enquanto que a pesquisa no mercado nacional foi realizada em novembro de 2005 e entre estes meses pode ter ocorrido a inserção de novos profissionais; Raible (2005) utilizou o site americano Monster.com, que é pago, enquanto que eu utilizei o site americano Jobs.net, que possibilita a visualização do número de currículos que satisfazem o critério de busca gratuitamente. 4.5.6. Resultado da Análise Ao analisar os dados, nota-se que Struts liderou todas as categorias exceto na categoria de ferramentas compatíveis. JSF, que liderou esta categoria, ficou em Capitulo 4. A Camada de Apresentação 145 segundo lugar em todas as outras exceto na categoria de disponibilidade de suporte, onde foi terceiro. É importante ressaltar que o Struts é desenvolvido desde 2000 e já se encontra num estado de maturidade elevado. Boa parte de seus bons resultados podem ser atribuídos a este fato. Por outro lado, JSF teve sua primeira versão lançada em 2004 e mesmo assim, assumiu uma boa colocação em todas as análises, mostrando crescimento bastante acentuado no número de posições disponíveis requerendo profissionais com habilidade neste web framework. 4.6. Conclusão O objetivo da camada de apresentação é de expor a lógica de negócios ao usuário e possibilitar a interação do usuário com a aplicação. Esta camada também costuma ser chamada de camada web no caso das aplicações baseadas na internet. Atualmente, HTML é a linguagem mais usada na construções de interfaces de aplicações disponíveis na web. HTML oferece várias vantagens, dentre elas: HTML é executado em navegadores padrões e, portanto, não necessita que novas aplicações sejam instalados na máquina cliente; desacoplam o cliente da tecnologia usado no servidor; costumam trafegar livremente por firewalls e impõem restrições de configurações modestas já que a maior parte do processamento ocorre no lado do servidor. Contudo também são impostos uma série de desafios, dentre eles: a interface com o usuário muda sem que a lógica de negócios necessariamente mude (D1); o modelo de requisição e resposta impede que a camada de apresentação seja notificada de mudanças no modelo (D2); é necessário separar o código de layout estático do código gerado dinamicamente (D3); requisições HTTP só carregam parâmetros do tipo String que precisam ser convertidos em tipos mais específicos da aplicação (D4) e validados (D5); possui um conjunto limitado de componentes (D6); difícil garantir que a aplicação terá o mesmo visual em todos os navegadores (D7); questões de desempenho e concorrência tornam-se mais críticas, pois a aplicação está sujeita a um maior número de usuários (D8) e são difíceis de testar (D9). Capitulo 4. A Camada de Apresentação 146 A divisão em camadas, com uma camada de apresentação limpa e magra, contribui para solução dos desafios D1, D3, D8 e D9. Para que a camada de apresentação seja limpa, usa-se o padrão de arquitetura MVC. Para que seja magra, é preciso disciplinar os desenvolvedores e realizar auditorias periódicas no código. O padrão de arquitetura MVC divide os elementos da camada de apresentação em visão (View), que recebe a entrada do usuário e exibe o resultado da operação, Controlador (Controller), que acessa a camada de negócios manipulando o modelo e selecionando a visão apropriada, e o Modelo (Model), objeto representando parte do domínio e que provê os dados para a visão. Apesar de ser possível construir uma solução ad hoc, há vários frameworks, denominados web frameworks, que se propõe a prover uma solução MVC e a resolver alguns dos desafios decorrentes do uso de HTML. Há cerca de 54 web frameworks gratuitos disponíveis para a plataforma Java. Estes frameworks implementam o MVC e oferecem meios para superar os desafios D4 e D5. Dentre estes. Foram escolhidos o Struts, por ser mais popular, o Spring MVC, pois o Spring já foi selecionado para a camada de negócios, e o JavaServer Faces, que fornece um padrão para desenvolvimento de componentes de interface. Ao analisar tecnicamente os web frameworks, conclui-se que o Struts apresenta um elevado grau de intrusão, pois as ações e os Action Forms precisam estender classes do framework e as páginas devem ser construídas utilizando tags do Struts que emulam as tags do HTML. Este elevado grau de intrusão torna difícil uma possível migração do Struts para outro web framework, caso seja necessário. Por outro lado, seu esquema de validação é o melhor, possibilitando que a validação dos dados de entrada seja executada no lado do cliente e do servidor a partir de um conjunto de regras declarativas. Validações no lado do cliente ajudam a reduzir o trafego entre o navegador e o servidor, mas podem ser desabilitadas pelo usuário e, portanto, validações no lado do servidor também são importantes. Já o Spring MVC possui o pior módulo de validação entre os três analisados, exigindo que as regras sejam programadas ao invés de declaradas. Além disso, ocorre validação apenas no lado do servidor. Entretanto Spring MVC é o menos intrusivo dos web frameworks analisados. Seus beans de formulários Capitulo 4. A Camada de Apresentação 147 não precisam estender nenhuma classe específica, seus controladores estendem classes conforme o tipo de operação a ser realizada (submissão de formulário, conjunto de telas estilo wizard, etc.) e não precisam instanciar diretamente o Façade, pois eles são configurados através de Dependency Injection. As páginas são compostas com as próprias tags HTML, diminuindo o acoplamento das páginas com Spring MVC. O JSF por outro lado é mais intrusivo que o Spring MVC, porém menos intrusivo que o Struts. Seus backing beans não precisam estender classes específicas, mas eventualmente precisam obter uma referência do contexto faces (FacesContext) o que acopla o backing bean ao JSF. As visões são construídas utilizando componentes de interface JSF. O principal diferencial é que o JSF define um modelo de componentes reusáveis que pode ser estendido (desafio D6 da seção 4.1). Além disso, por ser um padrão aberto, a tendência é que surjam componentes de terceiros que possam ser reaproveitados, tendência que já se confirma com o surgimento de projetos como o MyFaces (2005) e WebGalileo Faces (2005) gratuitos e WebCharts (2005) comercial. A análise não-técnica indica que Struts é o web framework mais aceito pela comunidade, mas o JSF também tem boa aceitação, sendo o web framework com mais ferramentas compatíveis disponíveis no mercado e o web framework cujo número de empregos mais cresceu no mercado norte-americano segundo as pesquisas realizadas. Após concluir a análise técnica e a não-técnica, julga-se que o JSF é o web framework mais adequado para ser usado na camada de apresentação do AulaNet 3.0. O critério decisivo para a efetivação desta escolha é técnico: apenas o JSF define um modelo de componentes. A criação de componentes de interfaces para o AulaNet 3.0 auxiliará na padronização das interfaces e contribuirá para o desenvolvimento rápido de interfaces. Além disso, podem ser aproveitados componentes desenvolvidos por terceiros, sejam estes desenvolvidos especificamente para o AulaNet ou não. Ao considerar os desafios listados no início deste capítulo, constata-se que a abordagem de divisão em camadas, com uma camada de apresentação limpa e magra, contribuiu para a superação dos desafios D1, D3, D8 e D9. A utilização de um web framework baseado em componentes, o JSF, contribuiu para a superação dos desafios D4, D5 e D6. O desafio D2 não pode ser resolvido, pois é intrínseco Capitulo 4. A Camada de Apresentação 148 ao modelo de requisição e resposta utilizado nas aplicações web. Já o desafio D7 não é solucionado pelo AulaNet 3.0, pois o custo para obter uma interface padronizada em todos os navegadores é muito alto e implica em muitos testes em diferentes navegadores. Como o navegador Internet Explorer detém 85,31% de participação no mercado, segundo pesquisa realizada em janeiro de 2006 (MarketShare, 2006), os testes e desenvolvimentos no AulaNet 3 serão voltados em um primeiro momento para este navegador. 5 Arquitetura do AulaNet 3.0 Conforme apresentado no Capitulo 1, a arquitetura do AulaNet 3.0 pode ser vista através de duas perspectivas: a da arquitetura de aplicação e a da arquitetura técnica. A arquitetura de aplicação apresenta uma visão mais alto nível. A estrutura lógica do sistema é descrita como uma coleção de componentes relacionados e os tipos e operações obtidos na especificação são distribuídos através dos componentes. Já a arquitetura técnica apresenta uma visão mais baixo nível e inclui as partes do sistema independentes do domínio como a infraestrutura de comunicação de componentes (ex. CORBA ou Java/RMI), a plataforma de hardware e a plataforma de software (D’Souza & Wills, 1998). Este Capítulo retoma a especificação da arquitetura do AulaNet 3.0 descrita no Capítulo 1, para em seguida incrementá-la através do acréscimo dos frameworks de infra-estrutura analisados nos capítulos 3 e 4. É visto também como a arquitetura é adaptada para possibilitar serviços a dispositivos móveis como PDAs (Personal Digital Assistant) e, por fim, é visto como a arquitetura possibilita a agregação de outros frameworks, tomando como exemplo o framework de agentes de software Jade (2005) e uma prova de conceito envolvendo um dispositivo móvel. 5.1. Elementos Principais da Arquitetura do AulaNet 3.0 A arquitetura de aplicação do AulaNet 3.0 possui 2 níveis de componentização: o de serviços e o de componentes de colaboração. Os serviços podem ser plugados e desplugados de forma a montar um ambiente customizado para cada grupo (Gerosa et al., 2005). O gerenciamento dos componentes é realizado através de frameworks de componentes, conforme a Figura 5.1 mostra. Capitulo 5. A Arquitetura do AulaNet 3.0 150 AulaNet Groupware Component Component Framework Service Component Framework Debate Conferência Collaboration Component Framework . . Msg Manager Msg Locator Infrastructure Frameworks Database . Figura 5.1 - Arquitetura de Aplicação do AulaNet 3.0 (Gerosa, 2006) Apresentada na Seção 1.3. O Service Component Framework provê os contratos que os serviços de groupware, por exemplo, o Debate e a Conferência, devem implementar para serem plugados na arquitetura do AulaNet. Já o Collaboration Component Framework estabelece os contratos para criar componentes 3C com os quais os serviços de groupware são criados. Por exemplo, o serviço Conferência é criado utilizando os componentes 3C gerenciador de mensagens, localizador de mensagens, etc. (Gerosa, 2006). Os componentes são implementados segundo a arquitetura técnica que usa uma abordagem em três camadas e também o padrão MVC (Fowler, 2002). O diagrama esquematizado na Figura 5.2 mostra a arquitetura técnica do AulaNet 3.0, baseada na arquitetura de POJOs descrita em Johnson (2002, 2004). As setas indicam o fluxo de controle da aplicação, retângulos representam classes e círculos representam interfaces. Linhas pontilhadas representam a divisão entre as camadas. Capitulo 5. A Arquitetura do AulaNet 3.0 Camada de Apresentação 151 V C Camada de Negócios Façade M (DTO) Data Access Object Mail Sender Camada de Recursos Servidor de E-Mails SGBD Figura 5.2 – Arquitetura Técnica do AulaNet 3.0 Apresentada na Seção 1.3. A camada de recursos relaciona os recursos externos necessários para a execução da aplicação. Na arquitetura do AulaNet 3.0 são usados um sistema de gerenciamento de banco de dados relacional (SGBD) e um servidor de e-mails. A lógica da aplicação é implementada na camada de negócios. As classes do modelo (M do MVC) realizam o padrão de projetos Data Transfer Object (Fowler, 2002) e são usadas para transportar os dados das entidades de negócio entre camadas. O acesso à base de dados é encapsulado através de classes que realizam o padrão de projetos Data Access Objects (DAO) (Alur et al., 2001), desta forma a maneira de persistir o modelo pode variar trocando componentes, sem que seja preciso reescrever o código cliente. O componente Mail Sender, de forma similar ao DAO, encapsula o acesso ao servidor de e-mails. A lógica de negócios é exposta para a camada de apresentação através de um Façade, que provê uma interface única para acesso às funcionalidades de um serviço (Gamma et al., 1995). Capitulo 5. A Arquitetura do AulaNet 3.0 152 Os serviços plugados no Service Component Framework são criados com um único Façade, que expõe as operações deste serviço para a camada de apresentação. Os componentes de colaboração plugados no Collaboration Component Framework por sua vez, podem utilizar vários DTOs e DAOs, dependendo da complexidade do componente. Estes componentes podem ainda usar “código cola” (Szyperski et al., 1997) e adaptadores (D’Souza & Wills, 1998) para possibilitar a integração com componentes e outros sistemas que não são compatíveis por construção. A camada de apresentação, que no caso de aplicações voltadas para a internet também costuma ser chamada de camada web, expõe a lógica de negócios ao usuário e possibilita a interação do usuário com a aplicação. Na arquitetura do AulaNet 3.0, a camada web é composta pelo controlador, o C do MVC além de páginas JSP, que correspondem ao V do MVC. O controlador chama os métodos do Façade, acessando a camada de negócios. Os DTOs resultantes de operações são passados a visão que exibe suas informações ao usuário. Esta seção reviu a arquitetura definida para o AulaNet 3.0, do ponto de vista da arquitetura técnica e de aplicação. Ao longo desta dissertação frameworks de infra-estrutura foram acrescentados a esta arquitetura, provendo uma base de serviços que tratam aspectos como persistência de dados, gerenciamento de transações entre outros. Na próxima seção a arquitetura do AulaNet 3.0 é reformulada através do acréscimo destes frameworks. 5.2. A Arquitetura do AulaNet 3.0 e os Frameworks de Infra-Estrutura Spring e Hibernate formam a base com os frameworks de infra-estrutura que oferecem suporte ao desenvolvimento de componentes de negócios. Eles provêm serviços de infra-estrutura, como por exemplo, persistência de dados e gerenciamento de transações para os componentes desenvolvidos com o Service Component Framework e o Collaboration Component Framework. A Figura 5.3 mostra o novo diagrama da arquitetura de aplicação do AulaNet 3.0 após a incorporação dos frameworks de infra-estrutura. Capitulo 5. A Arquitetura do AulaNet 3.0 153 Application Groupware Component Framework Component Component Framework Debate Conferência . Collaboration Component Framework . Msg Manager Msg Locator Spring Hibernate Infrastructure Frameworks Database . Figura 5.3 - Arquitetura de Aplicação do AulaNet 3.0 (Gerosa, 2006) O JavaServer Faces não é mostrado no diagrama da arquitetura de aplicação pois este não contempla a camada de apresentação. A Figura 5.4 exibe o diagrama da arquitetura técnica, com os frameworks de infra-estrutura. Capitulo 5. A Arquitetura do AulaNet 3.0 Camada de Apresentação Componente JSF Backing Bean Camada de Negócios 154 JSP Servlet JSF Controller IFaçade Proxy (Spring) IFaçade Façade M (DTO) Mail Sender Spring/Hibernate Data Access Object XML DTO.hbm.xml Camada de Recursos Servidor de E-Mails SGBD Figura 5.4 - Arquitetura Técnica do AulaNet 3.0 com Frameworks. Na camada de apresentação, a visão é construída com páginas JSP compostas por componentes JSF. Estes podem ser componentes de validação, de conversão de dados e de interface com o usuário. O Servlet JSF Controller é usado como controlador do MVC. Ao receber uma requisição, o controlador chama o backing bean, que acessa a camada de negócios. A entrada para a camada de apresentação é feita através do Proxy (Gamma et al., 1995) do Spring. Como o Proxy implementa a mesma interface do Façade (inteface IFaçade), o código cliente não precisa ser modificado para usar o Proxy em vez da implementação direta do Façade. O Proxy do Spring acrescenta serviços de controle de transações e gerenciamento de segurança. Para cada DTO representando uma entidade de negócios, um arquivo de mapeamento do Hibernate é gerado. Este arquivo possui os metadados de mapeamento objeto/relacional que possibilitam que o Hibernate realize a ponte entre os Capitulo 5. A Arquitetura do AulaNet 3.0 155 paradigmas objeto e relacional. Por fim, os DAOs são construídos usando tanto o Hibernate, que possibilita o mapeamento de objetos em base de dados relacionais, quanto o Spring, que gerencia a abertura e o fechamento de sessões do Hibernate e oferece métodos template, simplificando o desenvolvimento e reduzindo a ocorrência de erros. O Spring também atua na configuração das dependências dos componentes da camada de negócio. Como é mostrado nesta seção, a arquitetura de POJOs do AulaNet 3.0 possibilita o acréscimo de frameworks de infra-estrutura. Estes frameworks por sua vez, possibilitam que o desenvolvedor de groupware concentre-se em seu domínio, ou seja, groupware, deixando aspectos de infra-estrutura para outros frameworks especialistas. A arquitetura do AulaNet 3.0 também provê suporte a outros tipos de aplicações clientes, por exemplo, clientes móveis, como é visto a seguir. 5.3. Arquitetura Técnica e Mobilidade Com o crescimento da utilização de equipamentos móveis e redes sem fio, o potencial de uso de serviços tradicionais, como a navegação na web e e-mail aumentou bem como serviços não tradicionais e específicos de aplicações móveis, como aqueles que fazem uso da informação física do usuário. Através da adoção destas tecnologias espera-se que seja possível comunicar-se e ter acesso a informações e serviços em qualquer lugar e a qualquer instante. Neste contexto, a educação deverá incluir soluções que façam uso destes recursos (Filippo et al., 2005a). Com o objetivo de investigar mecanismos para aumentar a colaboração na aprendizagem através do uso de equipamentos móveis, iniciou-se o desenvolvimento de uma extensão do ambiente AulaNet específica para este fim, denominada AulaNetM (Filippo et al., 2005a). A versão atual do AulaNetM integra-se ao AulaNet 2.1 no nível de dados. A arquitetura do AulaNet 3.0 foi projetada para possibilitar integração no nível de serviços, aumentando assim a reutilização entre os dois projetos. Há duas formas de possibilitar a integração da arquitetura do AulaNet 3.0 no nível de serviços com o AulaNetM: através da reposição da camada de apresentação e da exposição de serviços remotamente. Capitulo 5. A Arquitetura do AulaNet 3.0 156 A técnica da reposição da camada de apresentação consiste em reaproveitar todo o código da camada de negócios e combiná-lo com uma nova camada de apresentação, desenvolvida especificamente para o dispositivo móvel. A aplicação resultante é executada independentemente do AulaNet 3.0 e serve aplicações clientes magras, ou seja, clientes que rodam em navegadores HTML no caso de PDAs ou WML no caso de celulares. Esta aplicação pode ser instalada no mesmo servidor do AulaNet (em um contexto diferente) ou em outro servidor. Opcionalmente, são acrescentados serviços específicos para clientes móveis, como serviços sensíveis a contexto ou a localização. Os projetistas da aplicação móvel têm controle limitado sobre o navegador utilizado no dispositivo e quase sempre não há suporte computacional para recuperar dados como a localização do PDA e o nível de carga da bateria. Torna-se necessário então que a aplicação questione o usuário sobre estas informações para poder prover estes serviços. A Figura 5.5 exibe a arquitetura do AulaNetM integrada ao AulaNet 3.0, usando esta técnica. Capitulo 5. A Arquitetura do AulaNet 3.0 157 Camada de Apresentação AulaNetM Camada de Negócios IFaçade Serviços Móveis Proxy (Spring) IFaçade Façade M (DTO) Mail Sender Spring/Hibernate Data Access Object XML DTO.hbm.xml Camada de Recursos Servidor de E-Mails SGBD Figura 5.5 – Arquitetura Técnica da Integração AulaNet 3.0 com AulaNetM por Reposição da Camada de Apresentação A não ser pela adição dos serviços móveis, que é opcional, a camada de negócios é a mesma usada na arquitetura do AulaNet 3.0. A camada de apresentação, assim como os serviços específicos de mobilidade, são implementadas pelos projetistas do AulaNetM. O uso de MVC não é obrigatório, mas é recomendado. Esta forma de integração atua em nível de serviço, mas em instâncias diferentes da camada de negócios, pois a camada de negócios precisa ser implantada no servidor do AulaNet 3.0 e do AulaNetM. A principal vantagem desta técnica é que as duas aplicações usam o mesmo código, da mesma forma com a exceção dos serviços específicos relativos à mobilidade. Equipes trabalhando em um projeto tendem a encontrar mais facilidade para mudar para outro já que estão habituadas as mesmas interfaces da camada de negócios. A Capitulo 5. A Arquitetura do AulaNet 3.0 158 principal desvantagem é que as informações do dispositivo como estado da conexão, carga da bateria, localização, etc., não podem ser recuperadas de forma transparente para o usuário. Além disso, é despendido um esforço extra para manter os dois projetos sincronizados, já que quando ocorrerem mudanças na camada de negócio, é preciso implantar a nova versão nos servidores do AulaNetM e AulaNet 3.0. A técnica da exposição de serviços remotos consiste em expor os serviços do AulaNet 3.0 remotamente para outras aplicações clientes. Esta técnica pode ser aplicada tanto para clientes magros quanto para clientes gordos, ou seja, clientes escritos em J2ME (2005), SuperWaba (2005) ou qualquer outra tecnologia usada para programar em dispositivos móveis. O desenvolvedor tem total controle sobre clientes gordos, sendo assim, estes tipos de clientes têm acesso a informações de contexto como localização, nível da bateria do dispositivo e estado da conexão, desde que a tecnologia utilizada para o desenvolvimento do cliente ofereça suporte a estas informações. Contudo, eles precisam ser instalados diretamente no dispositivo. A Figura 5.6 exibe a arquitetura do AulaNetM integrada ao AulaNet 3.0, usando a técnica de exposição de serviços remotos. Capitulo 5. A Arquitetura do AulaNet 3.0 159 Camada de Apresentação + Negócios Cliente Gordo Camada de Apresentação Componente JSF JSP Web Services JSF Controller Backing Bean Camada de Negócios IFaçade Proxy Remoto (Spring) Proxy (Spring) IFaçade Serviços Móveis Façade M (DTO) Mail Sender Spring/Hibernate Data Access Object XML DTO.hbm.xml Camada de Recursos Servidor de E-Mails SGBD Figura 5.6 - Arquitetura Técnica da Integração AulaNet 3.0 com AulaNetM por Exposição de Serviços Remotos Um cliente gordo tem a sua camada de apresentação implementada com tecnologias como o J2ME, mas também pode ter uma camada de negócios extra, onde há serviços independentes do acesso ao AulaNet 3.0, como um serviço despertador. Através de Serviços Web o cliente acessa a lógica de negócios do AulaNet 3.0. No caso de clientes magros, não mostrados na figura acima, a camada de apresentação é implementada utilizando HTML ou WML através das tecnologias JSP e Servlets, que acessam a camada de negócios do AulaNet 3.0 através de Serviços Web. Capitulo 5. A Arquitetura do AulaNet 3.0 160 Como é visto no capítulo 3, o Spring possibilita a exposição de serviços de diversas formas. A forma escolhida para integração com AulaNetM a princípio é por Serviços Web (Web Services), pois possibilitam a integração com aplicações clientes escritos em várias linguagens de programação além do Java. O Spring também possibilita que outros Proxys remotos sejam acrescentados, dando suporte ao uso de outros protocolos, como o RMI (RMI-IIOP, 2005), o Hessian/Burlap (Caucho, 2005) e o HttpInvoker (Spring, 2005). Vale lembrar que o uso de Proxys no Spring é feito através de configurações no descritor da aplicação, sem que seja necessário alterar o código dos componentes. Os Proxys remotos recebem as chamadas remotas e as encaminham para os métodos da camada de negócios ou para os componentes que provêm serviços específicos de mobilidade. A arquitetura do AulaNet 3.0 não sofre alteração substancial com o acréscimo dos serviços remotos. A principal vantagem do uso da técnica de exposição de serviços remotos é que ela dá suporte à construção de clientes gordos, que têm mais controle sobre o dispositivo móvel. A principal desvantagem é que chamadas remotas de métodos são mais caras que chamadas locais, tanto no que diz respeito ao desempenho quanto à complexidade adicionada a programação. Esta técnica pode ser usada tanto com clientes gordos quanto com clientes magros, mas em se tratando de clientes magros, é mais vantajoso usar a técnica da reposição da camada de apresentação que utilizam chamadas locais. Apesar das promessas de ensino e aprendizagem em qualquer lugar e a qualquer instante, a educação através de dispositivos móveis (m-learning) está sujeita a alguns desafios: a conexão é intermitente e lenta; pouco poder de processamento de dispositivos móveis; fontes de energias limitadas que de tempos em tempos necessitam ser recarregadas; adaptação das aplicações a um determinado aprendiz, ao contexto em que ele esta situado, à sua localização, etc. Estes desafios são inerentes às características dos dispositivos móveis e podem ser considerados também como desafios para outros tipos de groupware executados em dispositivos móveis. Sistemas de agentes inteligentes têm um grande potencial para solucionar estes desafios (Kinshuk & Lin, 2004). Capitulo 5. A Arquitetura do AulaNet 3.0 161 5.4. Arquitetura Técnica e Outros Frameworks: Jade Apenas os frameworks Spring, Hibernate e JSF foram selecionados para fazer parte da base de serviços de infra-estrutura da arquitetura do AulaNet 3.0, contudo esta pode ser estendida para incorporar outros frameworks. Como estudo de caso esta seção mostra como a arquitetura do AulaNet 3.0 foi estendida para incorporar o framework de desenvolvimento de agentes Jade (Bellifemine et al., 2003). 5.4.1. Agentes de Software O termo agente tem sido amplamente usado por pesquisadores em áreas similares, o que torna difícil obter uma definição precisa e amplamente aceita. Segundo Wooldridge & Jennings (1995) agentes pode ser definido seguindo uma noção fraca ou forte. Segundo a definição fraca, agente é definido como um sistema computacional com as seguintes propriedades: autonomia, agentes operam sem a intervenção de seres humanos e possuem controle sobre suas ações e estado interno; habilidade social, agentes interagem com outros agentes e possivelmente com seres humanos através de uma linguagem de comunicação de agentes (agentcommunication language - ACL); reatividade, agentes percebem seu ambiente (que pode ser o ambiente físico, a internet, a interface gráfica com o usuário) e são capazes de reagirem a mudanças neste ambiente; e pró-atividade, agentes tomam a iniciativa de agem, sem receber ordem externa. Já a noção forte, usada principalmente por pesquisadores na área de inteligência artificial, acrescenta às propriedades descritas na noção fraca características que geralmente são associadas a seres humanos. Por exemplo, Shoham (1993) adiciona as noções de conhecimento, crenças, intenções e obrigações aos agentes. Para esta dissertação, a definição fraca de Wooldridge & Jennings (1995) é adotada. É considerado também que agentes possuem a característica da mobilidade, que possibilita que agentes se movam pela rede (White, 1994). Capitulo 5. A Arquitetura do AulaNet 3.0 162 Pesquisas de sistemas multi-agentes (Multi Agent Systems - MAS) seguem duas linhas (Torres & Lucena, 2001). A primeira considera agentes como elementos de primeira ordem. Pesquisadores desta linha vêem MAS como o elemento fundamental de uma nova engenharia de software para a qual devem ser desenvolvidas novas linguagens, metodologias e técnicas de modelagem. Já pesquisadores da segunda consideram agentes uma abstração que deve ser usada para complementar o paradigma da orientação a objetos. Pretende-se seguir a segunda linha de pesquisas ao acrescentar um framework de agentes ao AulaNet. 5.4.2. Aplicações de Sistemas Multi-Agentes Como é visto na seção 5.3, o m-learning está sujeito a alguns desafios: o acesso ao conteúdo estudado é lento e intermitente, dispositivos móveis têm poder de processamento modesto e fontes de energias limitadas, a aplicação móvel pode se adaptar a um determinado contexto. Agentes aplicados em dispositivos móveis lidam com muitos destes desafios impostos ao m-learning. Agentes podem realizar download antecipado do conteúdo do estudo baseado no histórico do aprendiz. A qualidade da conexão é usada por agentes para tomar atitudes que diminuam o volume de dados trafegado como, por exemplo, compactar os dados ou não baixar as imagens de uma página HTML. Além disso, o usuário pode executar algumas operações off-line, como enviar uma mensagem mesmo com a conexão indisponível, que serão completadas pelo agente assim que ele tome conhecimento que a rede está novamente acessível. Desta forma, os problemas causados pela intermitência e velocidade da rede são amenizados. A capacidade de mobilidade dos agentes pode evitar as limitações dos dispositivos móveis. Os agentes móveis migram para um container de agentes em um servidor na rede fixa, realizam um processamento complexo e retornam ao dispositivo móvel com os resultados do processamento. Agentes em execução dentro do PDA têm acesso a informações de contexto, como localização e carga da bateria. Desta forma, agentes oferecem serviços específicos que atendem às características de um ambiente com mobilidade e modificam seu próprio comportamento com base nestas informações. Capitulo 5. A Arquitetura do AulaNet 3.0 163 Além do m-learning, agentes inteligentes podem ser usados em uma grande variedade de aplicações. Agentes são particularmente úteis em aplicações distribuídas envolvendo comunicação ponto-a-ponto. Alguns exemplos de domínios onde sistemas multi-agentes podem ser aplicados incluem aplicações de comércio eletrônico (Ripper et al., 2000), assistentes pessoais para gerenciamento de compromissos (Modi et al., 2004), simuladores (Drogoul & Ferber, 1992) entre outros. Além das aplicações de agentes no AulaNetM, também são vislumbradas aplicações ou tópicos de pesquisa onde agentes podem ser usados no AulaNet 3.0. Dentre elas, algumas são: o Agente Notificador, o Agente Moderador, o Agente Mediador, o Agente Formador de Grupos e o Agente Tutor. O Agente Notificador poderia ser configurado pelo aprendiz ou mediador para enviar notificações sempre que ocorrer algum evento relacionado ao curso. Este agente poderia, por exemplo, ser configurado para notificar o aprendiz sempre que uma mensagem sua for respondida na conferência. O Agente Moderador seria usado para conduzir a dinâmica de um debate. Um terceiro exemplo seria o do uso de um Agente Mediador, que animaria discussões em conferências. Este agente, por exemplo, enviaria mensagens polêmicas se percebesse um longo período de inatividade na conferência. O Agente Formador de Grupos, baseado em critérios como performance dos aprendizes, conhecimento e grau de afinidade, sugeriria a formação de grupos de trabalho. Finalmente, o Agente Tutor poderia propor conteúdos e cursos relacionados de acordo com o perfil do aprendiz. Sistemas multi-agentes é um tópico de pesquisa “quente” na área de sistemas de informação (Kinshuk & Lin, 2004) e que, como foi visto, pode trazer vantagens tanto para o AulaNet quanto para o AulaNetM. Desta forma, é desejável que a arquitetura do AulaNet 3.0 forneça suporte ao desenvolvimento de sistemas multi-agentes. Para prover este suporte pode ser usado o framework Jade (Bellifemine et al., 2003), como mostrado na seção a seguir. 5.4.3. O Framework de Agentes Jade Jade é um framework de aplicação orientada a objeto direcionado para o desenvolvimento de sistemas multi-agentes em conformidade com a especificação Capitulo 5. A Arquitetura do AulaNet 3.0 164 definida pela FIPA (Foundation for Intelligent Physical Agents) (FIPA, 2005), uma organização reconhecida pelo IEEE que promove tecnologias baseada em agentes e a interoperabilidade de suas especificações com outras tecnologias (Bellifemine et al., 2005). Jade foi escolhido para mostrar que a arquitetura do AulaNet 3.0 pode ser estendida com outros frameworks pois ele é um framework de agentes que encontra-se em estado de relativa maturidade, é compatível com a especificação da FIPA, é usado comercialmente em algumas empresas como a Telecom Italia LAB, Whitestein Technologies AG e Acklin B.V. (Jade, 2005), é escrito em Java e possibilita o uso de agentes tanto em dispositivos móveis quanto servidores desktops através do pacote de extensão Leap. Além do framework para desenvolvimento de agentes, o Jade inclui também um ambiente de execução para os agentes, denominado container, e uma ferramenta gráfica onde são realizadas as operações administrativas e o monitoramento do estado dos agentes. Um conjunto de containeres Jade, executando na mesma máquina ou em máquinas distintas, fazem parte de uma plataforma. Agentes em uma mesma plataforma podem se comunicar, opcionalmente usando ontologias. Agentes podem ainda migrar de um container para outro ou clonar-se, gerando um novo agente idêntico (Caire, 2003). Em uma plataforma, o primeiro container iniciado é denominado o container principal (Main Container). Sempre que algum novo container for iniciado na plataforma, ele deve registrar-se neste container. O container principal também é responsável por hospedar os agentes AMS (Agent Management System) e DF (Directory Facilitator). O primeiro é responsável pelo serviço de nomes que garante que agentes terão nomes únicos em uma plataforma e possibilita a criação e remoção de agentes em outros containeres. O segundo fornece um serviço de páginas amarelas onde agentes podem procurar por outros atentes que prestam serviços necessários para que seus objetivos sejam alcançados. A Figura 5.7 ilustra a execução de duas plataformas de agentes Jade. Capitulo 5. A Arquitetura do AulaNet 3.0 165 Figura 5.7 – Plataformas de Agentes Jade (Caire, 2003). A figura mostra duas plataformas. A primeira, denominada Plataform 1, contém três containeres. Os agentes AMS (Agent Management System), DF (Directory Facilitator) e o agente com o nome A1 se hospedam no container principal. Os agentes A2 e A3 se hospedam no container 1 e o agente A4 se hospeda no container 2. Tanto o container 1 quanto o container 2 se registram no container principal, unindo-se à primeira plataforma. A segunda plataforma possui apenas o container principal, onde se hospedam os agentes AMS, DF e um outro agente chamado A5. Agentes são construídos estendendo a classe jade.core.Agent. As ações que um agente realiza são especificadas através de comportamentos, classes que estendem jade.core.behaviours.Behaviour ou uma de suas subclasses. Há subclasses específicas para comportamentos que devem ser executados continuamente (CyclicBehaviour), que devem ser executados de tempos em tempos (TickerBehaviour), que são executados apenas uma vez (OneShotBehaviour) e outras. Agentes são identificados pelo seu nome e pela sua plataforma de execução através da classe jade.core.AID. Capitulo 5. A Arquitetura do AulaNet 3.0 166 Com a adição do pacote de extensão Leap, o container Jade pode ser executado em dispositivos móveis e em servidores Java. O pacote Leap substitui partes do núcleo do Jade que passa a se chamar Jade-Leap e possibilita a implantação de containeres Jade-Leap em ambientes J2SE, que é usado em servidores, Personal Java/J2ME CDC, que é usado em PDAs e MIDP, que é usado em telefones celulares (Caire, 2005). Devido às limitações de hardware em dispositivos como PDAs e telefones celulares, o Jade-Leap possui algumas limitações quando executado nestes ambientes. No ambiente PJAVA/J2ME CDC, a interface gráfica de administração não pode ser usada, pois ela depende da biblioteca Swing apenas disponível em servidores J2SE. Além disso, não é possível usar os agentes Sniffer e Introspector, utilizados para depuração, em containeres executando no modo stand-alone. O modo de execução stand-alone é explicado mais adiante. Finalmente, os serviços de replicação do container principal, usado para adicionar tolerância à falhas, e de entrega persistente de mensagens, que garante que mensagens são entregues mesmo quando o agente não está disponível, não podem ser usados. Já no ambiente J2ME MIDP, são impostas as mesmas limitações impostas aos dispositivos PJAVA/J2ME CDC e mais algumas. Não há suporte à mobilidade e à clonagem de agentes nestes ambientes. Comportamentos de agentes que usem threads são proibidos. Por fim, o pacote jade.wrapper e os métodos não estáticos da classe jade.core.Runtime não estão disponíveis e algumas classes do pacote de ontologias não funcionam, pois dependem da API de reflexão do Java que não esta disponível na plataforma MIDP. Jade-Leap pode ser executado em dispositivos móveis de duas formas: no modo split e no modo stand-alone. No modo stand-alone um container Jade-Leap completo é executado no aparelho e no modo split, o container é dividido em dois containeres, o back-end, executado em um servidor J2SE e o front-end, executado no dispositivo móvel. O modo de execução split possui inicialização mais rápida e diminui a quantidade de informação trafegada pela rede sem fio. Contudo, não é oferecido suporte à mobilidade e à clonagem de agentes em containeres executando no modo split. Desde a versão 3.3 do Jade-Leap o modo de execução stand-alone não é mais mantido nem testado e seu uso é desencorajado pelos projetistas do framework (Caire, 2005). Capitulo 5. A Arquitetura do AulaNet 3.0 167 5.4.4. Jade e a Arquitetura do AulaNet 3.0 Como visto no Capítulo 4, o Spring é o framework responsável por configurar as dependências entre os componentes. Este é um dos principais elementos da camada de negócios do AulaNet 3.0. Se um framework pode ser integrado ao Spring, então este pode ser integrado com sucesso a arquitetura do AulaNet 3.0. Jade é um framework para a camada de negócios e, portanto, se integrado ao Spring pode ser incorporado a camada de negócios do AulaNet 3.0. Como o Spring não oferece suporte nativo à integração com o Jade, é desenvolvido um adaptador que possibilita a integração de ambos. Este adaptador possibilita que o container Jade seja iniciado dentro de uma aplicação que utiliza o Spring e também que agentes criados com o Jade beneficiem-se dos recursos oferecidos pelo Spring, como por exemplo, a configuração de dependências através de Dependency Injection. O diagrama de classes do adaptador é mostrado na Figura 5.8. Capitulo 5. A Arquitetura do AulaNet 3.0 168 org.springframework.beans.factory << interface >> BeanFactoryAware +setBeanFactory(beanFactory:BeanFactory) << interface >> InitializingBean << interface >> DisposableBean +afterPropertiesSet() +destroy() << interface >> JadeLeapAdapter JadeLeapAdapterImpl -mainContainer:boolean -containerName:String -containerAddress:String -containerPort:int -autoInit:boolean -mainContainerAddress:String -mainContainerPort:int + isMainContainer():boolean +setMainContainer(main:boolean) +getContainerName():String +setContainerName(name:String) +getContainerAddress():String +setContainerAddress(address:String) +getContainerPort():int +setContainerPort(port:int) + isAutoInit():boolean +setAutoInit(autoInit:boolean) +getMainContainerAddress():String +setMainContainerAddress(address:String) +getMainContainerPort():int +setMainContainerPort(port:int) +startContainer() +stopContainer() +isContainerRunning() +getContainerController():ContainerController +createAgent(def:AgentDefinitionByClassName):AgentController +createAgent(def:AgentDefinitionByAgentInstance):AgentController +killAgent(agentName:String) +getAgentController(agentName:String):AgentController AgentDefinition 0..* -name:String +AgentDefinition() +AgentDefinition(name:String) +getName():String +setName(name:String) AgentDefinitionByClassName AgentDefinitionByAgentInstance -className:String -arguments:Object[] +getClassName():String +setClassName(className:String) +getArguments():Object[] +setArguments(args:Object[]) +AgentDefinitionByAgentInstance() +AgentDefinitionByAgentInstance(agent:Agent) +AgentDefinitionByAgentInstance(agent:Agent, name:String) jade.core 0..1 Agent Figura 5.8 – Diagrama de Classes do Adaptador Jade-Leap para o Spring A classe AgentDefinition e suas subclasses são usadas para definir um agente. Estas definições são usadas pelo adaptador para criar agentes e adicionálos ao container Jade. A classe abstrata AgentDefinition utiliza apenas o nome do agente para defini-lo, e não é suficiente para adicionar um agente a um container Jade, logo uma de suas subclasses precisa ser utilizada. A subclasse AgentDefinitionByClassName é usada para definir um agente com base no nome da classe que implementa o agente e os argumentos que devem ser passados a ela. A subclasse AgentDefinitionByAgentInstance define um agente através de uma instância da classe jade.core.Agent. Capitulo 5. A Arquitetura do AulaNet 3.0 169 A interface JadeLeapAdapter define os métodos do adaptador que realiza a ponte de integração do Jade-Leap ao Spring. São definidos métodos para iniciar o container Jade (método startContainer()), parar o container (método stopContainer()), verificar se o container está em execução (método isContainerRunning()) e recuperar o controle do container (método getContainerController()) com o qual operações mais complexas podem ser realizadas sobre o container Jade. Além disso, há métodos para criar um agente, segundo a descrição pelo nome da classe ou pela instância (métodos createAgent()), destruir um agente (killAgent()) ou recuperar o controlador do agente usado para executar operações como o acréscimo de comportamentos aos agentes. A classe concreta que implementa a interface JadeLeapAdapter é a JadeLeapAdapterImpl. Além de implementar a interface JadeLeapAdapter, ela implementa também as interfaces BeanFactoryAware, InitializingBean e DisposableBean do Spring. A primeira define o método setBeanFactory(), que é chamado pelo Spring para passar a fábrica de beans (BeanFactory) responsável pela criação do adaptador. Através desta fábrica, outros beans definidos no Spring podem ser recuperados pelos agentes criados a partir da definição baseada no nome da classe (AgentDefinitionByClassName). Os agentes criados pela definição baseada na instância do agente (AgentDefinitionByAgentInstance) não necessitam da fábrica pois acessam os outros beans definidos no Spring pelo mecanismo de Dependency Injection. A interface InitializingBean define o método afterPropertiesSet() chamado quando o adaptador é inicializado e é usada para iniciar o container Jade automaticamente. A interface DisposableBean define o método destroy(), que é chamado pouco antes do adaptador ser destruído, usada para encerrar o container Jade automaticamente. Além disso, a classe JadeLeapAdapterImpl define propriedades que possibilitam que o modo de execução do Jade seja configurado. A propriedade mainContainer indica se o container a ser executado é um container principal. No caso desta propriedade ser configurada como falsa, as propriedades mainContainerAddress e mainContainerPort devem ser configuradas com o endereço e a porta do container principal. As propriedades containerName, containerAddress e containerPort são usadas para especificar, respectivamente, o nome, endereço e porta do container iniciado pelo adaptador. O vetor Capitulo 5. A Arquitetura do AulaNet 3.0 170 agentDefinitions é configurado com os agentes criados quando o container é iniciado e a propriedade autoInit define se o container é iniciado automaticamente quando o adaptador é criado. Apesar de possibilitar a integração do Jade ao Spring, o adaptador desenvolvido tem algumas limitações. Ao migrar para outra máquina, as referências que um agente possui para serviços locais tornam-se inconsistentes. O mesmo ocorre com agentes clonados em outras máquinas. Para superar esta limitação, o agente com mobilidade ao retornar para o AulaNet deve comunicar-se com um outro agente sem mobilidade, para que este possa lhe fornecer a referência perdida. Além disso, agentes criados a partir da definição baseada no nome da classe não podem fazer uso do módulo de Dependency Injection do Spring, pois eles são instanciados pelo Jade e não pelo Spring. Para contornar este problema o adaptador adiciona a fábrica de beans (BeanFactory) do Spring na última posição do vetor de argumentos passados ao agente. Desta forma, o agente recupera instâncias de beans definidos no Spring. O adaptador deve ser configurado no arquivo de configuração do Spring, como será visto na seção a seguir. Como nenhuma API específica do Jade ou do JadeLeap é usada na construção do adaptador, este pode ser usado tanto em um quanto no outro. O adaptador não foi desenvolvido para dar suporte ao modo de execução split em dispositivos móveis, pois Spring foi desenvolvido para dar suporte apenas aos ambientes J2SE e J2EE, e portanto não funciona em dispositivos móveis. Contudo isto não é empecilho para que um agente em execução em container em um ambiente J2SE ou J2EE com Spring se comunique com outro agente em um dispositivo móvel MIDP ou PJAVA/J2ME CDC, como é visto na próxima seção. 5.4.5. Prova de Conceito com Agente Móvel Para testar a integração entre o Jade e o Spring através do adaptador, bem como a viabilidade do uso de agentes em dispositivos móveis se comunicando com outros agentes em servidores, desenvolveu-se uma prova de conceito. Esta prova é dividida em duas partes. Na primeira parte, é mostrado o sistema multiagentes “O Que Há de Novo na Conferência?” que tem pouca aplicação prática, Capitulo 5. A Arquitetura do AulaNet 3.0 171 mas que é mostrado com mais detalhes por ser mais simples, e como conseqüência mais didático. Na segunda parte é mostrado um sistema multiagentes “Assistente do Mediador” que tem mais aplicação prática, pois é construído para superar alguns problemas reportados por usuários do AulaNetM. Este não é mostrado com tantos detalhes devido a sua complexidade. 5.4.2.1. MAS 1: O Que Há de Novo na Conferência? Esta aplicação é usada para obter atualizações sobre uma determinada conferência. A cada solicitação do usuário do PDA, a aplicação informa as mensagens novas, que foram removidas, que tiveram suas categorias alteradas e que foram avaliadas desde a última consulta do usuário. Para implementar esta aplicação são utilizados dois agentes. O primeiro, denominado Agente Móvel (MobileAgent), é hospedado por um container JadeLeap em execução em um PDA iPAQ 5555, utilizando a máquina virtual J2ME CDC CrEme (2005). O modo de execução é o split e o container neste dispositivo atua como front-end. O segundo agente, denominado Agente Conferência (ConferenceAgent), é hospedado por um container Jade-Leap em execução no servidor J2EE JBoss em conjunto com o protótipo do serviço Conferência desenvolvido a partir da arquitetura definida para o AulaNet 3.0. Este container funciona como o back-end. O container principal da plataforma é executado separadamente, para facilitar a depuração do sistema. A Figura 5.9 ilustra a interação entre os containeres. Capitulo 5. A Arquitetura do AulaNet 3.0 172 AulaNet 3 Plataforma JADE Split Container JADE-LEAP Back-End JADE-LEAP Front-End Conference Agent Mobile Agent JSF Conector Spring Hibernate JADE-LEAP Main Container Figura 5.9 – Plataforma de Execução do MAS 1 O Agente Móvel, quando acionado pela aplicação, se comunica com o Agente Conferência para buscar atualizações sobre uma determinada conferência. O Agente Conferência então acessa a camada de negócios do AulaNet 3.0, recuperando o estado dela e envia de volta ao Agente Móvel a lista das mensagens novas, das mensagens que foram removidas, das mensagens que tiveram sua categoria alterada e das mensagens que foram avaliadas desde a última consulta do Agente móvel. O Agente Conferência é implementado da mesma forma que qualquer outro agente seria implementado na plataforma JadeLeap. A única diferença é que, Capitulo 5. A Arquitetura do AulaNet 3.0 173 como ele é executado em conjunto com o Spring, obtém os benefícios proporcionados por este framework. A Listagem 5.1 mostra o código do agente. 01: public class ConferenceAgent extends Agent { 02: private ConferenceFacade facade; 03: 04: 05: protected void setup() { addBehaviour(new WhatIsNewInConferenceBehaviour()); } 06: 07: 08: protected void takeDown() { facade = null; } 09: 10: 11: public final ConferenceFacade getConferenceFacade() { return conferenceFacade; } 12: public final void setConferenceFacade(ConferenceFacade cf) { 13: facade = cf; 14: } 15: } Listagem 5.1 – Agente Conferência Na linha 01, a classe do agente estende a classe jade.core.Agent. Todos os agentes do Jade devem estender esta classe. Na linha 02 é declarada a variável para o Façade da conferência. O método setup(), chamado pelo container Jade para configurar o agente quando este é adicionado ao container, é declarado entre as linhas 03 e 05. Na linha 04 o comportamento WhatIsNewInConferenceBehaviour, que é descrito mais adiante, é acrescentado ao agente. O método takeDown(), chamado quando o agente é removido do container, é declarado no trecho entre as linhas 06 e 08. No trecho entre as linhas 09 e 14 são declarados os métodos de acesso para a propriedade facade. Esta propriedade é configurada pelo Spring por Dependency Injection. O comportamento WhatIsNewInConferenceBehaviour é responsável por responder ao Agente Móvel o que há de novo na conferência. O código fonte deste comportamento é listado a seguir. Capitulo 5. A Arquitetura do AulaNet 3.0 174 16: public class WhatIsNewInConferenceBehaviour extends CyclicBehaviour { 17: private final Map lastConference = new HashMap(); 18: 19: 20: 21: public void action() { MessageTemplate mt = MessageTemplate.and( MessageTemplate.MatchPerformative(ACLMessage.QUERY_IF), MessageTemplate.MatchConversationId("conference-status")); 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: ACLMessage msg = myAgent.receive(mt); if (msg != null) { AID sender = msg.getSender(); Conference oldConference = (Conference) lastConference.get(sender); String conferenceId = msg.getContent(); ConferenceFacade ca = (ConferenceAgent) myAgent; ConferenceFacade facade = ca.getConferenceFacade(); Conference newConference = facade .findConferenceById(conferenceId); List newMessages = getNewMessages(oldConference, newConference); List deletedMessages = getDeletedMessages(oldConference, newConference); List categorizedMessages = getCategorizedMessages(oldConference, newConference); List evaluatedMessages = getEvalutatedMessages(oldConference, newConference); String content = buildReplyContent(newMessages, deletedMessages, categorizedMessages, evaluatedMessages); 36: ACLMessage reply = msg.createReply(); 37: reply.setContent(content); 38: myAgent.send(reply); 39: lastConference.put(sender, newConference); 40: } else { 41: block(); 42: } 43: } 44: } Listagem 5.2 – Comportamento WhatIsNewInConferenceBehaviour Na linha 16 o comportamento é declarado como CyclicBehaviour, o que significa que ele é executado indefinidamente. A variável lastConference é um mapa que guarda um espelho das últimas consultas dos Agentes Móveis. No trecho entre as linhas 18 e 21 é declarado um template de mensagem, que indica o formato da mensagem que o agente espera receber. Na linha 22, uma mensagem em conformidade com o template é solicitada. O remetente da mensagem é recuperado na linha 24 e a partir dele é recuperada o status da conferência em sua última consulta na linha 25. A partir do id da conferência recuperado na linha 26, o estado atual da conferência é recuperado através do Façade na linha 29. Os comandos no trecho entre as linhas 30 e 35 chamam métodos que calculam as mensagens novas, as removidas, as que tiveram sua categoria modificada e as que foram avaliadas e depois compõem a resposta que será enviada. Estes métodos não são exibidos por motivos de clareza. Capitulo 5. A Arquitetura do AulaNet 3.0 175 Na linha 36 a resposta é criada. O conteúdo dela é configurado na linha 37 e ela é enviada na linha 38. Na linha 39 o mapa das conferências passadas é atualizado. Para que a dependência do agente com o Façade da conferência seja satisfeita, é preciso que o arquivo de configuração do Spring seja configurado apropriadamente. É também através do arquivo de configuração do Spring que o adaptador do Jade-Leap é configurado. A Listagem 5.3 mostra o arquivo de configuração do Spring. 45: <beans> 46: <bean id="jadeContainerConnector" class="JadeLeapConnectorImpl"> 47: <property name="mainContainer"> 48: <value>false</value> 49: </property> 50: <property name="autoInit"> 51: <value>true</value> 52: </property> 53: <property name="containerName"> 54: <value>SpringBackEnd</value> 55: </property> 56: <property name="containerPort"> 57: <value>2999</value> 58: </property> 59: <property name="mainContainerAddress"> 60: <value>127.0.0.1</value> 61: </property> 62: <property name="mainContainerPort"> 63: <value>1999</value> 64: </property> 65: <property name="agentDefinitions"> 66: <list> 67: <bean class="AgentDefinitionByAgentInstance"> 68: <property name="name"> 69: <value>Conference-Agent</value> 70: </property> 71: <property name="agentInstance"> 72: <bean class="ConferenceAgent"> 73: <property name="facade"> 74: <ref bean="conferenceFacade"/> 75: </property> 76: </bean> 77: </property> 78: </bean> 79: </list> 80: </property> 81: </bean> 82: </beans> Listagem 5.3 – Configuração no Spring do Adaptador Jade-Leap Capitulo 5. A Arquitetura do AulaNet 3.0 176 O adaptador do Jade-Leap é configurado no trecho entre as linhas 45 e 81. Por motivos de clareza o bean conferenceFacade não é exibido na listagem. No trecho entre as linhas 47 e 49 a propriedade mainContainer é definida como false, indicando que o container executado não é principal e entre as linhas 50 e 52 a propriedade autoInit é configurada como true, o que indica que o container é inicializado automaticamente. O nome do container é declarado como SpringBackEnd no trecho entre as linhas 53 e 55 e a porta em que o container executa é declara como 2999 no trecho entre as linhas 56 e 58. Entre as linhas 59 e 61 o endereço do container principal é configurado para 127.0.0.1 e entre as linhas 62 e 64 a porta é configurada para 1999. No trecho entre as linhas 65 e 80, a definição dos agentes é declarada. Neste exemplo, apenas o Agente Conferência é configurado. Na linha 67 é declarado que a definição de agentes usada é a definição por instância de agente. Desta forma, é possível usar a funcionalidade de Dependency Injection do Spring. O nome do agente, ConferenceAgente, é declarado na linha 69 e a instância do agente é declarada entre as linhas 72 e 76. A classe do agente é definida na linha 72 e a dependência com o Façade da conferência é configurada no trecho entre as linhas 73 e 75. O Agente Móvel é implementado usando J2ME CDC e, portanto, não usa o Spring e seu adaptador para o Jade-Leap. Seu código é exibido na Listagem 5.4. O Código responsável pela criação da interface no PDA é omitido por questões de clareza. 83: public class MobileAgent extends Agent { 84: protected void setup() { 85: System.out.println("Agent created.\n"); 86: } 87: } Listagem 5.4 – Agente Móvel O código do Agente Móvel é pequeno, mas é necessário, pois a classe Agent é abstrata e não pode ser instanciada. Tudo que esta classe faz é imprimir uma mensagem indicando que o agente foi criado. O comportamento do agente é Capitulo 5. A Arquitetura do AulaNet 3.0 implementado na classe ConferenceQueryBehaviour, 177 responsável pela comunicação com o Agente Conferência. Este comportamento, cujo código é mostrado na Listagem 5.5, é adicionado ao agente dinamicamente quando um usuário aciona o botão de atualização. 088: public class ConferenceQueryBehaviour extends Behaviour { 089: 090: 091: 092: 093: private int step = SEND_QUERY; private static final int SEND_QUERY = 1; private static final int RECEIVE_RESPONSE = 2; private static final int FINISH = 3; private String conferenceId; 094: 095: 096: public ConferenceQueryBehaviour(String conferenceId) { this.conferenceId = conferenceId; } 097: 098: 099: 100: 101: 102: 103: 104: 105: 106: public void action() { switch (step) { case SEND_QUERY: AID receiver = new AID("Conference-Agent", AID.ISLOCALNAME); ACLMessage query = new ACLMessage(ACLMessage.QUERY_IF); query.addReceiver(receiver); query.setConversationId("conference-status"); query.setContent(conferenceId); query.setReplyWith("query" + System.currentTimeMillis()); myAgent.send(query); 107: 108: 109: 110: 111: 112: 113: template = MessageTemplate.and( MessageTemplate.MatchConversationId("conference-status"), MessageTemplate.MatchInReplyTo(query.getReplyWith())); step = RECEIVE_RESPONSE; break; case RECEIVE_RESPONSE: ACLMessage reply = myAgent.receive(template); 114: 115: 116: 117: 118: 119: 120: 121: 122: if (reply != null) { System.out.println(reply.getContent()); step = FINISH; } else { block(); } break; } } 123: public boolean done() { 124: return step == FINISH; 125: } 126: } Listagem 5.5 – Comportamento ConferenceQueryBehaviour Capitulo 5. A Arquitetura do AulaNet 3.0 178 Como é visto na linha 088 a classe ConferenceQueryBehaviour, estende a classe Behaviour que se encontra no topo da hierarquia das classes que oferecem suporte à construção de comportamentos. Esta classe é útil para a construção de comportamentos que funcionam como máquina de estados. O trecho entre as linhas 097 e 122 declara o método action, executado toda vez que o comportamento é chamado e o trecho entre as linhas 123 e 125 declara o método done, que testa se o comportamento deve ser chamado novamente. A variável que armazena o estado é declarada na linha 089. Constantes representando os estados enviar pergunta (SEND_QUERY), receber resposta (RECEIVE_RESPONSE) e final (FINISH) são declaradas entre as linhas 090 e 092. Na linha 093 é declarada a variável que armazena o id da conferência para a qual serão obtidas as atualizações. Um construtor que recebe o id da conferência como parâmetro é declarado no trecho entre as linhas 094 e 096. O estado enviar pergunta é delimitado pelas linhas 099 e 111. O endereço do destinatário é criado na linha 100 e a mensagem é criada na linha 101. O destinatário é adicionado à mensagem na linha 102 e o identificador da conversa é configurado na linha 103. O id da conferência para a qual se deseja obter atualizações é adicionado como conteúdo da mensagem na linha 104. Na linha 105, um número único é acrescentado a mensagem, para evitar o tratamento de mensagens falsas. A mensagem é enviada na linha 106 e no trecho entre as linhas 107 e 109 um template de mensagem com o formato da resposta aguardada é criado. O estado enviar pergunta é delimitado pelas linhas 112 e 120. A mensagem é recebida na linha 113 e seu conteúdo é exibido na tela (linha 115). A interface gráfica desenvolvida para o PDA possui 6 botões divididos em duas linhas. Na primeira linha encontram-se os botões para iniciar o container Jade, parar o container e ativar o agente (acrescentar o comportamento ConferenceQueryBehaviour a ele). Na segunda linha encontram-se os botões para limpar a tela, configurar a aplicação e fechar o programa. A Figura 5.10 e a Figura 5.11 mostram o programa em execução. Capitulo 5. A Arquitetura do AulaNet 3.0 179 Figura 5.10 – PDA Após a Inicialização Figura 5.11 – PDA Após a Primeira do Jade-Leap Consulta A Figura 5.10 mostra a aplicação após o botão “Start Cont.” ser clicado, resultando no início do container Jade. Já na Figura 5.11, é mostrado o estado da aplicação após o botão “Activate Agent”, responsável pela ativação do agente, ser acionado. Como é a primeira consulta realizada, todas as mensagens da conferência são retornadas como mensagens novas. A Figura 5.12 mostra uma nova ativação do agente. Capitulo 5. A Arquitetura do AulaNet 3.0 180 Figura 5.12 - PDA Após a Segunda Consulta Como a segunda ativação é realizada logo em seguida da primeira, sem que haja mudança na conferência, o agente não detecta alterações. Este exemplo, apesar de didático, possui pouca aplicação prática já que não apresenta nenhuma evolução dos serviços já existentes no AulaNet e AulaNetM. Na próxima seção é vista a segunda parte da prova de conceito, com uma aplicação baseada em um problema real encontrado por mediadores do AulaNet. 5.4.2.2. MAS 2: Alerta de Condições Indesejáveis A aplicação desenvolvida nesta segunda parte tem como objetivo alertar o mediador de um curso quando uma condição indesejável estiver ocorrendo no serviço Conferências. São verificadas quatro condições que normalmente são indesejáveis. A primeira refere-se ao seu nível de atividade, o que gera uma notificação caso seja detectada a ausência de mensagens em um intervalo de tempo maior do que um período previamente estabelecido. A segunda informação verifica se uma questão está sendo pouco debatida ou se está polarizando a conferência em detrimento das outras. Neste caso, o mediador é notificado caso alguma mensagem categorizada como “Questão” possua uma quantidade de Capitulo 5. A Arquitetura do AulaNet 3.0 181 respostas menor ou maior que um limite pré-configurado. Isto só é feito a partir de 12 horas após o início da conferência, dando tempo para os aprendizes iniciarem a discussão. A terceira informação refere-se ao nível de atividade dos aprendizes: uma notificação é gerada quando um aprendiz apresentar uma participação que possa ser considerada muito baixa segundo os critérios do curso. A quarta e última informação disponibiliza uma medida para o mediador estimar o nível de interatividade da conferência: por exemplo, uma notificação é gerada toda vez que a porcentagem de folhas da estrutura da árvore da conferência for maior que 50%, ou seja, quando mais da metade das mensagens não estiverem sendo respondidas. Devido às diferentes características das turmas e dos propósitos das conferências, os valores dos parâmetros para que as notificações sejam acionadas devem ser configurados pelos mediadores para cada conferência através de uma interface específica para este fim. Ao receber estas notificações os mediadores podem tomar decisões que mudem o rumo da conferência, contornando as situações indesejáveis. O AulaNetM provê meios para a verificação destas situações através de informações visuais (Figura 5.13) e estatísticas (Figura 5.14), porém, o processo de detecção das condições indesejáveis não é automatizado, isto é, os Mediadores precisam acessar diretamente o AulaNetM para obter a informação. Conseqüentemente, na maior parte dos casos os mediadores tomam conhecimento da condição tardiamente. Além disso, mediadores entrevistados reclamaram da dificuldade de estabelecer conexão e de mantê-la uma vez estabelecida. Pesquisas revelaram indícios de que os mediadores passavam mais tempo tentando conectar-se ou reconectar-se do que analisando a conferência. Capitulo 5. A Arquitetura do AulaNet 3.0 182 Figura 5.13 – Informações Visuais no Figura 5.14 – Informações Estatísticas AulaNetM no AulaNetM Para contornar estes problemas uma MAS foi desenvolvido. Os mediadores não precisam mais monitorar o estado da conferência, pois os agentes já fazem isto e o mecanismo de tolerância a falhas presente no Jade possibilita que mensagens não entregues devido a falhas na conexão sejam adiadas e entregues ao retomar a conexão de forma transparente ao usuário. A aplicação consiste em um sistema multi-agentes constituído por dois tipos de agentes diferentes: o Conference Agent e o Mediator Assistant. O Conference Agent é o mesmo descrito na seção anterior, mas a ele é adicionado os comportamentos que permitem detectar as condições indesejáveis na conferência. O Conference Agent é pró-ativo e reativo, e permanece monitorando a Conferência do AulaNet na tentativa de detectar situações indesejáveis. Como cada curso no AulaNet pode ter várias conferências, cada nova conferência ganha um Conference Agent na sua ativação e, na sua desativação, este agente é destruído. O Mediator Assistant é executado dentro de um container Jade-Leap em execução dentro de um PDA iPAQ 5555, o mesmo ambiente utilizado na aplicação da seção anterior. Este agente permanece em execução no PDA initerrupdamente, esperando por mensagens do Agente Conference Agent. Ao receber uma mensagem, o agente Mediator Assistant emite um alerta, comunicando ao seu usuário a situação indesejada ocorrida. Este agente é Capitulo 5. A Arquitetura do AulaNet 3.0 183 autônomo, e pode optar por não mostrar um alerta em determinados casos, como a desabilitação explícita de um determinado tipo de alerta pelo mediador ou a excessiva repetição do alerta. As figuras Figura 5.15 e Figura 5.16 mostram o Mediator Assistant em execução. Figura 5.15 – Informações Visuais no Figura 5.16 – Informações Estatísticas AulaNetM no AulaNetM A Figura 5.15 mostra a tela do agente Mediator Assistant e a Figura 5.16 mostra o agente após receber vários alertas. Esta aplicação é capaz de alertar os mediadores tão logo a condição seja detectada e assim, estes são capazes de tomar atitudes mais cedo para contornar a condição indesejável com mais rapidez. 5.5. Conclusão Capitulo 5. A Arquitetura do AulaNet 3.0 184 A arquitetura do AulaNet 3.0 pode ser vista através de duas perspectivas: a da arquitetura de aplicação, que apresenta uma visão mais alto nível e a da arquitetura técnica, que apresenta uma visão mais baixo nível. Quando contemplada do ponto de vista da arquitetura de aplicação, a arquitetura do AulaNet 3.0 apresenta dois níveis de componentização: o dos serviços e o dos componentes de colaboração com os quais os serviços são construídos. A arquitetura de aplicação apresenta dois frameworks de componentes: o Service Component Framework, que provê os contratos que os serviços de groupware devem implementar e o Collaboration Component Framework, que fornece os contratos para criar componentes 3C com os quais os serviços de groupware são construídos. Tanto os serviços quanto os componentes 3C são desenvolvidos segundo a arquitetura técnica. A arquitetura técnica segue uma abordagem em três camadas e também o padrão MVC (Fowler, 2002). A camada de recursos relaciona os recursos necessários para à execução do AulaNet, por exemplo o banco de dados relacional. A camada de negócios é onde a lógica da aplicação é implementada. Nela encontram-se Data Transfer Objects (DTOs) (Fowler, 2005), classes do modelo que representam entidades de negócio e são usadas para transportar dado entre camadas (correspondem ao M do MVC), Data Access Objects (DAOs) (Alur et al., 2001), classes que encapsulam o acesso ao banco de dados e Façades (Gamma et al., 1995), classes que servem como ponto de entrada para a camada de negócios. A camada de apresentação, que expõe a lógica de negócios ao usuário, é composta pelo controlador, o C do MVC além de páginas JSP, que correspondem ao V do MVC. Ao longo desta dissertação foram vistos como vários frameworks podem ser acrescentados proporcionando uma base de serviços de infra-estrutura. Após o acréscimo destes frameworks, a arquitetura é descrita segundo a Figura 5.17. Capitulo 5. A Arquitetura do AulaNet 3.0 Camada de Apresentação Componente JSF Backing Bean Camada de Negócios 185 JSP JSF Controller IFaçade Proxy (Spring) IFaçade Façade M (DTO) Mail Sender Spring/Hibernate Data Access Object XML DTO.hbm.xml Camada de Recursos Servidor de E-Mails SGBD Figura 5.17 – Arquitetura Técnica do AulaNet 3.0 com Frameworks Com o crescimento do uso de dispositivos móveis e com o advento das redes sem fio, espera-se que seja possível ter acesso a informações, comunicação e serviços em qualquer lugar e a qualquer instante. Com o objetivo de investigar o uso de equipamentos móveis na aprendizagem colaborativa, iniciou-se o desenvolvimento de uma extensão do ambiente AulaNet para dispositivos móveis denominada AulaNetM. Atualmente o AulanetM integra-se ao AulaNet 2.1 no nível de dados. A arquitetura do AulaNet 3.0 foi projetada para possibilitar a integração em nível de serviços, proporcionando um maior reuso. A integração pode ser alcançada através da técnica reposição da camada de apresentação ou da exposição de serviços remotamente. Pela técnica da reposição da camada de apresentação, a camada de negócios de negócios é totalmente reaproveitada enquanto que a camada de apresentação é Capitulo 5. A Arquitetura do AulaNet 3.0 186 substituída por uma outra mais adequada ao dispositivo móvel, utilizando HTML ou WML. Esta técnica é adequada a clientes magros e sua principal vantagem é a maior facilidade que equipes de um projeto tendem a encontrar ao participar de outro, já que ambos usam as mesmas interfaces de negócios. A maior desvantagem é que clientes magros não têm acesso direto a informações como a localização do PDA, por exemplo, dificultando a implementação de serviços específicos de mobilidade de forma transparente. A técnica da exposição de serviços remotos é implementada através da adição de Proxys do Spring que exportam os serviços remotamente. Clientes magros ou gordos acessam os serviços do AulaNet através destes Proxys. A principal vantagem desta técnica é que clientes gordos têm acesso às informações do dispositivo, como por exemplo, a localização. Desta forma, podem dar suporte a serviços específicos de mobilidade de forma transparente. A principal desvantagem é que as chamadas remotas são mais complexas de serem feitas e oferecem desempenho inferior. Apesar de prover suporte tanto para clientes magros quanto gordos, esta técnica é mais adequada para os gordos. Apesar das inegáveis vantagens do uso de dispositivos móveis, o desenvolvimento de sistemas nestes ambientes oferece desafios devido à baixa capacidade de processamento do aparelho, conexão intermitente e de baixa qualidade, bateria que precisa ser recarregada, etc. Segundo Kinshuk & Lin (2004), sistemas de agentes inteligentes têm um grande potencial para solucionar estes desafios. Além das aplicações de agentes para dispositivos móveis, há várias outras possíveis para o AulaNet 3.0. Por isto, decidiu-se que a arquitetura do AulaNet 3.0 deveria possibilitar o uso de agentes. Para evidenciar que a arquitetura do AulaNet 3.0 pode ser estendida com outros frameworks e que pode dar suporte ao uso de agentes, decidiu-se investigar a integração do AulaNet ao framework de agentes Jade. Para que um framework seja integrado a arquitetura do AulaNet, é preciso que este seja compatível com o Spring. Como o Spring não oferece suporte nativo de integração com o Jade, foi necessário criar um adaptador. Através do adaptador, podem ser realizadas operações sobre o container Jade e sobre agentes. Como os agentes são instanciados pelo Spring, eles podem fazer uso das Capitulo 5. A Arquitetura do AulaNet 3.0 187 funcionalidades proporcionadas por ele, incluindo Dependency Injection com outras classes. Para testar a integração do Jade com o Spring bem como a viabilidade do uso de agentes em dispositivos móveis foi realizada uma prova de conceito em duas etapas. Ambas envolveram agentes em ambientes móveis comunicando-se com agentes no AulaNet. O teste de conceito foi implementado com sucesso e com ele, constatou-se que a arquitetura do AulaNet 3.0 pode ter outros frameworks não previstos inicialmente incorporados, desde que eles sejam compatíveis com o Spring ou possam ser adaptados através de um adaptador para uso com o Spring. Constatouse também que é possível desenvolver agentes em dispositivos móveis usando Jade e que eles podem se comunicar com outros agentes localizados em servidores. 6 Conclusão Trabalhando colaborativamente, pelo menos potencialmente, pode-se produzir melhores resultados do que se os membros do grupo atuassem individualmente (Fuks et al., 2002). Groupware é um tipo de software que oferece suporte à interação entre indivíduos possibilitando o trabalho colaborativo. Learningware é um tipo de groupware usado no aprendizado colaborativo. Um groupware envolve aspectos multidisciplinares em sua construção e é difícil de aplicar e testar, sendo especialmente vulnerável a falhas (Gerosa et al., 2004). Como cada grupo tem suas próprias necessidades que se modificam ao longo do tempo, é importante que o groupware seja desenvolvido de forma iterativa e que a experiência do seu uso seja usada para guiar seu desenvolvimento, criando novos serviços ou melhorando as funcionalidades dos serviços existentes. Através de uma arquitetura componentizada, o groupware pode ser adaptado plugando e desplugando componentes, compondo uma aplicação que melhor satisfaça um grupo de trabalho. O AulaNet é um learningware desenvolvido pelo Laboratório de Engenharia de Software (LES) da Pontifícia Universidade Católica do Rio de Janeiro (PUCRio) desde 1997 e desde o lançamento da versão 2.0 a sua arquitetura nunca sofreu reengenharia. Alunos de graduação, mestrado e doutorado desenvolvem suas monografias, dissertações e teses usando o AulaNet para realizar suas pesquisas. O AulaNet é usado no curso Engenharia de Groupware, onde atua como repositório de informações, e no curso Tecnologias de Informação Aplicada A Educação (TIAE), onde é usado integralmente a distância. O AulaNet é distribuído pela EduWeb, que também realiza customizações para atender as demandas de seus clientes. Atualmente o AulaNet é usado em diversas universidades e empresas no mundo inteiro. Com o passar do tempo o AulaNet acumulou código legado que não segue as principais boas práticas e tecnologias conhecidas atualmente. Como conseqüência, as equipes do LES e da EduWeb vêm enfrentando dificuldades para desenvolver novos serviços e manter os Capítulo 6. Conclusão 189 existentes, sendo apontadas causas como a baixa modularidade e o uso de um paradigma funcional (Pimentel et al., 2005). Para solucionar estas questões, iniciou-se o desenvolvimento de uma nova versão, o AulaNet 3.0. Gerosa (2006) em sua pesquisa de doutorado na PUC-Rio concebeu uma arquitetura baseada em componentes para o AulaNet 3.0. Esta arquitetura possui dois níveis de componentização: o de serviços e o dos componentes 3C. Os serviços, como a Conferência e o Debate são plugados e desplugados em um framework de componentes, o Groupware Component Framework, compondo um groupware especifico que atenda às necessidades de um grupo de trabalho. Os serviços por sua vez são compostos por componentes 3C, que são reusados na construção de diversos serviços. Ao desenvolver componentes, o desenvolvedor se depara com inúmeros desafios. Além de entender do seu domínio de conhecimento ele deve lidar com questões como persistências de dados, controle de transações, segurança e muitas outras. O desenvolvimento de groupware já é difícil por si só devido a seu caráter multidisciplinar e a heterogeneidade dos diversos grupos de trabalho e não deveria ser complicado por questões de baixo nível. Frameworks de infra-estrutura de sistemas simplificam o desenvolvimento de sistemas de infra-estrutura portáveis e eficientes (Fayad et al., 1999b). Estes frameworks possibilitam uma visão mais alto nível destas questões. Nesta dissertação, foi visto como estes frameworks oferecem serviços que simplificam o desenvolvimento de groupwares. Tomando uma abordagem em camadas, foram vistos frameworks usados na camada de negócios e frameworks usados na camada de apresentação. Ao buscar por frameworks para lidar com determinada questão de infraestrutura muitas vezes o arquiteto de software se depara com diversos frameworks similares que se propõe a realizar a mesma coisa. A leitura da documentação do fabricante pode ajudar na escolha, mas muitas vezes as informações fornecidas pelo fabricante são subjetivas. Realizando uma análise técnica, possivelmente implementando uma prova de conceito, o arquiteto obtém indícios sobre qual framework atende melhor a suas necessidades. Entretanto nem sempre a implementação da prova de conceito é possível devido à limitação natural de tempo e recursos que todo projeto tem. Capítulo 6. Conclusão 190 Além de identificar se o framework atende às necessidades técnicas do projeto, há outros fatores importantes que devem ser considerados. É importante saber se há documentação disponível, se há suporte disponível, se há ferramentas compatíveis com o framework, se o framework está sendo usado por outras instituições e se há profissionais aptos a trabalhar com o framework. Estas questões não-técnicas usualmente são tão importantes quanto as questões técnicas, principalmente no caso do AulaNet devido à rotatividade de desenvolvedores no LES e a integração com a equipe da EduWeb. Esta dissertação apresentou uma forma de comparar estes fatores. Na camada de negócios, as principais questões de infra-estrutura resolvidas por frameworks são: persistência de dados, gerenciamento de transações, gerenciamento de segurança e exposição de serviços remotamente. Estas questões são tratadas no framework de componentes Enterprise Java Beans (EJB) e, por isso, ele foi avaliado como opção. Após a análise técnica do EJB chegou-se a conclusão que ele apresentava inúmeras desvantagens. É preciso manter uma grande quantidade de arquivos para realizar manutenção em um componente EJB. Componentes EJB dependem de servidores de aplicação que possuam containeres EJB que geralmente são mais caros e complexos. Além disso, o modelo EJB resulta em componentes altamente intrusivos e consequentemente mais difíceis de serem testados unitariamente. As restrições de programação impostas pela especificação EJB 2.1 impossibilitam a realização de atividades corriqueiras. A especificação EJB 3.0 vem se inspirado em um modelo de POJOs e frameworks como o Hibernate para solucionar estas questões mas, como seu futuro é incerto, optou-se por seguir uma arquitetura de POJOs com frameworks. Para tratar a persistência de dados e dos desafios decorrentes do conflito dos paradigmas Objeto/Relacional, é usado o framework Object Relational Mapping (ORM) Hibernate (2005). Antes de adotar o Hibernate foi realizada uma análise técnica onde foram analisadas as características deste framework. Após a implementação de uma prova de conceito, um protótipo do serviço Conferências do AulaNet, percebeu-se que este framework supria as necessidades de persistência do AulaNet. Após a análise técnica foi realizada a análise não-técnica, que iniciou-se pela seleção dos concorrentes. Os frameworks ORM iBATIS (2005), Apache OJB Capítulo 6. Conclusão 191 (OJB, 2005) e JDOMax (2005), uma implementação da especificação JDO (2005) são soluções de mapeamento completo (Fussel,1997) e gratuitos. A análise determinou o Hibernate como o framework com mais documentação disponível, com mais suporte disponível (é a comunidade mais ativa e possui suporte pago), com mais ferramentas compatíveis, com mais empresas usando e com mais profissionais aptos a trabalhar com ele disponíveis no mercado. Como os outros não apresentavam nenhuma vantagem técnica significativa, a escolha do Hibernate se manteve. Para solucionar às questões de gerenciamento de transações, gerenciamento de segurança e exposição de serviços remotamente, foi escolhido o framework Spring (2005). A análise técnica mostrou que o Spring fornecia meios para lidar com estas questões e, além disso, fornecia um módulo de Dependency Injection que torna os componentes mais fracamente acoplados e mais fáceis de serem testados unitariamente. Spring possui também um módulo de Programação Orientada a Aspectos, possibilitando que pesquisas nesta área sejam realizadas com o AulaNet. Spring também integra-se ao Hibernate, facilitando o seu uso. O Spring também se manteve após a na análise não-técnica. Foram encontrados 4 frameworks gratuitos com características similares ao Spring: Avalon (2005), que se transformou no projeto Excalibur (2005), o HiveMind (2005), NanoContainer (2005) e o PicoContainer (2005). A análise mostrou que o Spring é superior em todas as categorias e, novamente, a escolha se manteve. Na camada de apresentação, há uma família de frameworks denominada web frameworks que oferecem uma implementação do padrão de projetos Model View Controller (MVC) (Fowler, 2002), além de tratar também desafios decorrentes do uso do HTML na construção de interfaces com o usuário. Estimase que há 54 web frameworks disponíveis gratuitamente na plataforma Java (Manageability, 2005). Devido ao grande número de web frameworks disponíveis, foi preciso adotar uma outra abordagem. Foram selecionados 3 para serem analisados tecnicamente. O Struts (2005), por ser o mais popular, o Spring MVC, módulo do framework Spring (2005), por ter sido escolhido para a camada de apresentação, e o JavaServer Faces (JSF) (2005), por especificar um modelo de componentes e ser um padrão da Sun. A análise técnica indicou cada um com suas vantagens. O Spring MVC, o menos intrusivo de todos, o Struts, com o melhor módulo de validação de entrada Capítulo 6. Conclusão 192 de dados e o JSF sendo o único dos três a especificar um modelo de componentes. Após a análise técnica, escolheu-se o JSF, pois ele aparenta ser um modelo de componentes promissor e porque começa a se desenhar um mercado de componentes JSF com o surgimento de projetos como MyFaces (2005) e WebGalileo Faces (WebGalileo, 2005), que são gratuitos, e o WebCharts (2005), que é comercial. Alguns destes componentes, como o editor HTML encontrado no projeto MyFaces, atendem a demandas atuais de usuários do AulaNet. Ao realizar a análise não-técnica notou-se que Struts liderou todas as categorias exceto a categoria de ferramentas compatíveis. JSF, que liderou esta categoria, ficou em segundo lugar em todas as outras exceto a categoria de disponibilidade de suporte onde foi terceiro. JSF foi também o framework cujo número de oportunidades requerendo habilidade no framework mais cresceu ao longo das pesquisas. O bom desempenho do JSF na análise técnica foi crucial para que ele se mantivesse como escolha para a camada de apresentação. Mesmo tendo a sua primeira versão estável lançada em 2004, JSF ficou atrás apenas do Struts, que parece ser o web framework mais aceito atualmente, mas que não define um modelo de componentes e por isso não será usado. Apesar da arquitetura do AulaNet 3.0 prever apenas estes 3 frameworks, é possível incorporar outros frameworks, oferecendo infra-estrutura para tratar questões não previstas. Nesta dissertação foi visto como incorporar o framework de agentes Jade a arquitetura do AulaNet 3.0. Para integrar um novo framework na camada de negócios da arquitetura do AulaNet 3.0 é preciso integrá-lo ao Spring. Como o String não é intrusivo e é baseado em boas práticas, como a programação para interfaces (Bloch, 2005) e encapsulamento através de propriedades JavaBeans (2005), normalmente isto não é um problema. Como visto nesta dissertação, o Jade pode ser integrado à arquitetura através de um adaptador construído com poucas classes, possibilitando o uso de agentes de software no AulaNet tanto para fins de pesquisa quanto para fins de mercado. Além disso, através dos Proxys remotos do Spring é oferecido suporte a aplicações móveis. Com a nova arquitetura, é possível integrar o AulaNet e o AulaNetM, extensão do AulaNet para dispositivos móveis, no nível de serviços, aumentando o reuso entre os dois projetos. Desenvolver groupware é complexo e não deveria se tornar mais complexo devido a aspectos de infra-estrutura de baixo nível como persistência de dados, Capítulo 6. Conclusão 193 gerenciamento de transações, etc. Frameworks de infra-estrutura simplificam estes aspectos ao tratarem os problemas em baixo nível e fornecerem interfaces em alto nível. Estes frameworks são projetados e desenvolvidos por especialistas nesta área enquanto que os componentes de groupware são projetados por especialistas em groupware. Esta pesquisa mostrou como uma arquitetura em três camadas pode se beneficiar pelo uso de frameworks de infra-estrutura. Mostrou-se também uma forma de avaliar frameworks que leva em conta tanto aspectos técnicos quanto não-técnicos. Espera-se que esta pesquisa possa auxiliar arquitetos de groupware e de software a construir aplicações, auxiliando na tomada de decisões sobre a estruturação da arquitetura técnica e na escolha de frameworks de aplicação que tratem de aspectos de infra-estrutura de baixo nível. Espera-se também que este trabalho guie os desenvolvedores LES/EduWeb na construção do AulaNet 3.0, para que este possa continuar rendendo mais uma década de pesquisas e aprendizagem. 7 Referências Bibliográficas Alur D., Crupi & J., Malks, D. (2001): Core J2EE Patterns: Best Practices and Design Strategies. Publisher: Prentice Hall / Sun Microsystems Press, 2001. Ambler, S. (2002): Mapping Objects to Relational Databases. AmbySoft Inc. Artigo disponível em <www.ambysoft.com/mappingObjects.html>. Última visita em 28/11/2005. Avalon (2005): Página oficial do framework Avalon <http://avalon.apache.org/>. Última visita em 11/12/2005. disponível em Barreto, C. G., Fuks, H. & Lucena, C. J. P. (2005): Agregando Frameworks em uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet. Anais do 5º Workshop de Desenvolvimento Baseado em Componentes WDBC 2005, 7-9 de novembro de 2005, Juiz de Fora, MG, ISBN 85-88279-47-9, pp. 25-32. Beck, K. (2004): Programação extrema explicada: acolha as mudanças. Porto Alegre: Bookman. Bellifemine, F., Caire, G., Poggi, A. & Rimassa, G. (2003): Jade – A White Paper. EXP in search of innovation Volume 3 - n. 3 - September 2003– Special issue on Jade.pp. 6-19. Bellifemine, F., Caire, G., Trucco & T, Rimassa, G. (2005): Jade Programmer’s guide, 2005. Bloch, J. (2002): Effective Java Programming Language Guide. Addison Wesley, 2002. Brown, S., Dalton, S., Jepp, D., Johnson, D., Li, S., Raible, M. (2005): Pro JSP, Fourth Edition, Appress, 2005. Buschmann, F., Meunier, R., Rohnert, H., Sommerland, P. & Stal, M (1996): Pattern-Oriented Software Architectur A System of Patterns, John Wiley & Sons, 1996 Caire, C. (2003): Jade Tutorial - Jade Programming for Beginners, 2003. Caire, C. (2005): Leap User Guide, 2005. Caucho (2005): Página oficial do grupo Caucho <http://www.caucho.com/>. Última visita em 11/12/2005. disponível em Cheesman, J. e Daniels, J. (2001): UML Components. EUA: Addison-Wesley, 2001 Cocoon (2005): Página oficial do framework Cocoon disponível em <http://cocoon.apache.org/>. Última visita em 2/11/2005. Capítulo 7. Referências 195 CrEme (2005): Página oficial da máquina virtual J2ME/CDC/Personal Profile CrEme dispónivel em <http://www.nsicom.com/Default.aspx?tabid=138>. Última visita em 5/1/2006. Drogoul, A. & Ferber, J. (1992): Multi-Agent Simulation as a Tool for Modeling Societies: Application to Social Differentiation in Ant Colonies. In: preproceedings MAAMAW92: 4th European Workshop on Modelling Autonomous Agents in a Multi-Agent World, Italy. D’Souza, D. F. & Wills, A. C. (1998): Objects, Components, and Frameworks with UML : The Catalysis Approach. Addison Wesley, 1998. EduWeb (2005): Site da empresa EduWeb disponível em <http://www.eduweb.com.br/portugues/home.asp>. Última visita: 18/03/2006. EJB (2003): Sun Microsystems Enterprise JavaBeans Specification, Version 2.1, Novembro de 2003. EJB (2005): Enterprise JavaBeans. Site oficial disponível <http://java.sun.com/products/ejb/index.jsp>. Última visita em 20/10/2005. em Excalibur (2005): Página oficial do framework Excalibur disponível em <http://excalibur.apache.org/>. Última visita em 11/12/2005. Fayad, M. E. & Schmidt, D. C. (1997): Object-oriented application frameworks, Communications of the ACM, v.40 n.10, p.32-38, Oct. 1997 Fayad, M. E., Schimidt & D. C., Johnson, R. E. (1999a): Implementing application frameworks: object-oriented frameworks at work. New York: J. Wiley, c1999. 729 p. ISBN 0471252018. Fayad, M. E., Schimidt & D. C., Johnson, R. E. (1999b): Building application frameworks: object-oriented foundations of framework design. New York: J. Wiley, c1999. 664 p. ISBN 0471248754. Fayad, M. E. & Johnson, R. E. (2000): Domain-specific application frameworks: frameworks experience by industry. New York: J. Wiley, c2000. 681 p. ISBN 0471332801. Filippo,D., Fuks, H. & Lucena, C. J. P. (2005a): AulaNetM: Extension of the AulaNet Environment to PDAs, CONTEXT 2005, 5th International and Interdisciplinary Conference on Modeling and Using Context, Workshop 10: Context and Groupware, CEUR Workshop Proceedings, ISSN 1613, vol 133, Paris, France, 5-8 July, 2005. Filippo., D., Fuks, H. & Lucena, C. J. .P. (2005b): AulaNetM: Extensão do Serviço de Conferências do AulaNet destinada a usuários de PDAs, Anais do XVI Simpósio Brasileiro de Informática na Educação – SBIE 2005, 07-11 de Novembro, Juiz de Fora, MG, ISBN 85-88279-48-7, pp. 623-633. FIPA (2005): Página oficial da organização <http://www.fipa.org/>. Última visita em 5/1/2006. FIPA disponível em Fowler, M. (2002): Patterns of Enterprise Application Architecture. AddisonWesley, 2002 Fowler, M. (2004): Inversion of Control Containers and the Dependency Injection pattern: Artigo disponível em <http://martinfowler.com/articles/injection.html>. Última visita em: 2/11/2005. Capítulo 7. Referências 196 Froehlich, G., Hoover, H. J., Liu, L. & Sorenson, P. (1997a): Hooking into Object-Oriented Application Frameworks, To appear in the Proceedings of the 1997 International Conference on Software Engineering. Boston (May 1997). Froehlich, G., Hoover, H. J., Liu, L. & Sorenson, P. (1997b): Reusing Application Frameworks Through Hooks, Communications of the ACM special issue on object-oriented frameworks, 1997. Fuks, H., Gerosa, M. A. & Lucena, C. J. P. (2002): The Development and Application of Distance Learning on the Internet, The Journal of Open and Distance Learning, Vol. 17, N. 1, ISSN 0268-0513, Fevereiro 2002, pp. 23-38. Fuks, H., Raposo, A. B., Gerosa, M.A. (2002): Engenharia de Groupware: Desenvolvimento de Aplicações Colaborativas, XXI Jornada de Atualização em Informática, Anais do XXII Congresso da Sociedade Brasileira de Computação, V2, Cap. 3, ISBN 85-88442-24-8, pp 89-128, 2002. Fuks, H., Gerosa, M. A., Pimentel, M. G., Raposo, A. B., Mitchell, L. H. R. G. & Lucena, C. J. P. (2003): Evoluindo para uma Arquitetura de Groupware Baseada em Componentes: o Estudo de Caso do Learningware AulaNet, WDBC 2003 - III Workshop de Desenvolvimento Baseado em Componentes, Anais Eletrônicos, São Carlos-SP, 10 a 12 de setembro de 2003. Fuks, H., Raposo, A. B., Gerosa, M.A., Lucena, C. J. P. (2005) Applying the 3C Model to Groupware Development, International Journal of Cooperative Information Systems (IJCIS), v.14, n.2-3, Jun-Sep 2005, World Scientific, pp. 299-328. Fussel, M. L. (1997): Foundations of Object Relational Mapping. ChiMu Coorporation. Artigo disponível em <www.chimu.com/publications/objectRelational/>. Última visita em 28/11/2005. Fussel, S. R., Kraut, R. E., Learch, F. J., Scherlis, W. L., Mcnally, M. M., Cadiz, J. J. (1998): Coordination, overload and team performance: effects of team communication strategies, Proceedings of CSCW '98, Seattle, USA, p. 275-284. ISBN 1-58113-009-0. Gamma, E., Helm, R., Johnson & R., Vlissides, J. (1995): Design patterns: elements of reusable object-oriented software. Addison-Wesley, Reading, MA, 1995. Geary, D. & Horstmann, C. (2005): Core JavaServer Faces, Sun Microsystems, Inc, 2005. Gerosa (2006): Desenvolvimento de Groupware Componentizado Baseado no Modelo 3C de Colaboração. Tese de doutorado a ser defendida em 16/03/2006. Gerosa, M. A., Barreto, C. G., Raposo, A. B., Fuks, H. & Lucena, C. J. P. (2004): O Uso de uma Arquitetura Baseada em Componentes para Incrementar um Serviço do Ambiente AulaNet. Anais do 4º Workshop de Desenvolvimento Baseado em Componentes - WDBC 2004, 15-17 de Setembro, João Pessoa-PB, ISBN 85-7669-001-2, pp. 55-60, 2004. Gerosa, M. A., Pimentel, M., Filippo, D., Barreto, C. G., Raposo, A. B., Fuks, H. & Lucena, C. J. P. (2005): Componentes Baseados no Modelo 3C para o Desenvolvimento de Ferramentas Colaborativas. Anais do 5º Workshop de Capítulo 7. Referências 197 Desenvolvimento Baseado em Componentes - WDBC 2005, 7-9 de novembro de 2005, Juiz de Fora, MG, ISBN 85-88279-47-9, pp. 109-112. Gimenes, I. M. S (org.), & Huzita, E.H.M (org.) (2005): Desenvolvimento Baseado em Componentes: Conceitos e Técnicas. Rio de Janeiro: Ciência Moderna, 2005. Hibernate (2005): Página oficial do framework Hibernate disponível em <http://www.hibernate.org/>. Última visita em 20/10/2005. HiveMind (2005): Página oficial do framework HiveMind disponível em <http://jakarta.apache.org/hivemind/>. Última visita em 11/12/2005. iBATIS (2005): Página oficial do framework Hibernate disponível em <http://ibatis.apache.org/>. Última visita em 10/12/2005. Ierusalimschy, R., Figueiredo, L.H. & Celes, W (1996). Lua – an extensible extension language. Software: Practice & Experience, 26(6), 635-652. Interface 21 (2005): Página oficial da empresa Interface 21 disponível em <http://www.springframework.com/>. Última visita em 2/11/2005. J2ME (2005): Página oficial da tecnologia J2ME disponível <http://java.sun.com/j2me/index.jsp>. Última visita em 3/1/2006. em Jacobson, I. & Ng, P. (2004): Aspect-Oriented Software Development with Use Cases. Addison-Wesley, 2004. Jade (2005): Página official do framework Java Agent Development (Jade) disponível em <http://jade.tilab.com/>. Última visita em 2/1/2006. JavaBeans (2005): Especificação <http://java.sun.com/beans>. do padrão JavaBeans disponível em JBoss (2005): Página oficial do servidor de aplicações JBoss disponível em <http://www.jboss.com/developers/index>. Última visita em 20/11/2005. JDBC (2005): Documentação da tecnologia JDBC disponível <http://java.sun.com/products/jdbc/index.jsp>. Última visita em 28/11/2005. em JDO (2005): Documentação da tecnologia Java Data Objects (JDO) disponível em < http://java.sun.com/products/jdo/index.jsp>. Última visita em 28/11/2005. JDOMax (2005): Documentação do framework JDOMax disponível em <http://www.jdomax.com/index.html>. Última visita em 10/12/2005. JNDI (2005): Documentação da tecnologia <http://java.sun.com/products/jndi/index.jsp >. JNDI disponível em Johnson, R. E & Foote, B. (1988): Designing Reusable Classes, Journal of Object-Oriented Programming, June 1988. Johnson, R. E. (1991): Reusing Object-Oriented Design, University of Illinois, Technical Report UIUCDCS 91-1696, 1991. Johnson, R. (2002): Expert One-on-One J2EE Design and Development. Reading: Wiley Publishing Inc., 2002. Johnson, R. (2004): Expert One-on-One J2EE Development without EJB. Wiley Publishing Inc., 2004. Capítulo 7. Referências 198 JSF (2005): JavaServer Faces. Implementação de referência da Sun disponível em <http://java.sun.com/j2ee/javaserverfaces/>. Última visita em 8/10/2005. JSR 220 (2005): JSR 220: Enterprise JavaBeansTM,Version 3.0 - Sun Microsystems Enterprise JavaBeans Specification, Version 3.0, Junho de 2005. JTA (2005): Documentação da tecnologia Java Transaction API (JTA) disponível em <http://java.sun.com/products/jta/index.html>. Última visita em 10/12/2005. Kinshuk & Lin T. (2004). Improving mobile learning environments by applying mobile agents technology. Third Pan Commonwealth Forum on Open Learning, 4-8 July 2004, Dunedin, New Zealand. King, G. & Bauer, C. (2005): Hibernate in Action. Manning Publishing Co., 2005. Lalonde, W (1994): Discovering Smalltalk. The Benjamin/Cummings Publishing Company, Inc, 1994. Larman, C. (2004) Utilizando UML e Padrões: Uma introdução à análise e ao projeto orientados a objetos e ao Processo Unificado, 2ª edição, Bookman, Porto Alegre. Lucena, C. J. P., Fuks, H. (2000) Professores e Aprendizes na Web: A Educação na Era da Internet. Rio de Janeiro, Editora Clube do Futuro, 2000. Lundberg, C. & Mattsson, M. (1996): On Using Legacy Software Components with Object-Oriented Frameworks, Proceedings of Systemarkitekturer'96, Borås, Sweden, 1996. Mackinnon, T., Freeman & S., Craig, P. (2000): Endo-Testing: Unit Testing with Mock Objects. Artigo publicado na conferência “eXtreme Programming and Flexible Processes in Software Engineering - XP2000”. Manageability (2005): Artigo “How Many Java Web Frameworks Can You Name?” disponível em <http://www.manageability.org/blog/stuff/how-manyjava-web-frameworks/view>. Última visita em 9/10/2005. MarketShare (2006): Market Share by Net Applications. Comparação de participação de Mercado entre os navegadores. Artigo disponível em <http://marketshare.hitslink.com/>. Última visita em 5/2/2006. Mattsson, M. (1996): Object-oriented Frameworks - A survey of methodological issues”, Licentiate Thesis, Department of Computer Science, Lund University, CODEN: LUTEDX/(TECS-3066)/1-130/(1996), also as Technical Report, LUCS-TR: 96-167, Department of Computer Science, Lund University, 1996. Mattsson. M. (2000): Evolution and Composition Object-Oriented Frameworks, PhD Thesis, University of Karlskrona/Ronneby, Department of Software Engineering and Computer Science, 2000. Modi, P. J., Veloso, M., Smith, S. F. & Oh, J. (2004) CMRadar: A Personal Assistant Agent for Calendar Management. In 6th International Workshop on Agent-Oriented Information Systems (AOIS), pages 134-148, 2004. MyFaces (2005): Página oficial do MyFaces <http://myfaces.apache.org/>. Última visita em: 25/10/2005. disponível em NanoContainer (2005): Página oficial do framework NanoContainer disponível em <http://nanocontainer.codehaus.org/>. Última visita em 11/12/2005. Capítulo 7. Referências 199 Oberon (2005): Oberon Microsystems, Inc., BlackBox Developer and BlackBox Component Framework, URL <http://www.oberon.ch/>. Última visita em 26/12/2005. OJB (2005): Página oficial do framework Apache OJB disponível em <http://db.apache.org/ojb/>. Última visita em 10/12/2005. OpenDoc (2005): Documentação do framework de componentes OpenDoc disponível em <http://developer.apple.com/documentation/macos8/Legacy/OpenDoc/opendoc.ht ml>. Última visita em 26/12/2005. Philippe, K. (2003): Introdução ao RUP – Rational Unified Process. Rio de Janeiro: Ciência Moderna. PicoContainer (2005): Página oficial do framework PicoContainer disponível em <www.picocontainer.org/>. Última visita em 11/12/2005. Pimentel (2006): RUP – 3C – Groupware: Processo de Desenvolvimento de Groupware Baseado no Modelo 3C de Colaboração. Tese de doutorado a ser defendida em 22/03/2006. Pimentel, M., Gerosa, M. A., Filippo, D., Barreto, C. G., Raposo, A. B., Fuks, H. & Lucena, C. J. P. (2005): AulaNet 3.0: desenvolvendo aplicações colaborativas baseadas em componentes 3C. WCSCW 2005 - Workshop Brasileiro de Tecnologias para Colaboração, 7 e 8 de Novembro 2005. Em Anais XVI Simpósio Brasileiro de Informática na Educação, v. 2, ISBN 85-88279-48-7. Juiz de Fora - MG: UFJF, 8 a 11 de Novembro 2005. p. 761-770. Pinto, S. C. C. S. (2000): Composição em WebFrameworks, tese de doutorado, Departamento de Informática PUC-Rio. POJO (2005): Trecho do blog do Martin Fowler onde o termo Plain Old Java Object é explicado disponível em <http://www.martinfowler.com/bliki/POJO.html>. Última visita em 20/10/2005. Pree, W. (1995): Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995. Raible, M. (2004): Spring Live. Sourcebeat, LLC, ISBN: 0974884375, 2004. Raible, M. (2005): Java Web Frameworks, <http://www.virtuas.com/osl-jwf-01.pdf>. artigo disponível em Ramachandran, V. (2002): Design Patterns for Building Flexible and Maintainable J2EE Applications. Artigo disponível em <http://java.sun.com/developer/technicalArticles/J2EE/despat/index.html>. Última visita em: 2/11/2005. Raposo, A. B., Magalhães, L. P., Ricarte, I. L. M., Fuks, H. (2001): Coordination of collaborative activities: A framework for the definition of tasks interdependencies. 7th International Workshop on Groupware - CRIWG 2001, 170-179, 2001. Rezende, J. L. (2003): Aplicando Técnicas de Comunicação para a Facilitação de Debates no Ambiente AulaNet. Dissertação de Mestrado, Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio), março 2003. Capítulo 7. Referências 200 Ripper, P. S., Fontoura, M. F., Neto, A. M. & Lucena, C. J. P. (2000): V-Market: A framework for agent e-commerce systems, World Wide Web, Volume 3, Issue 1, Mar 2000, Pages 43 - 52 RMI-IIOP (2005): Documentação da tecnologia RMI-IIOP disponível em <http://java.sun.com/products/rmi-iiop/>. Última visita em 20/10/2005. Santoro, F., Borges, M. & Santos, N. (1999): Computer-Supported Cooperative Learning Environments: A Framework for Analysis. In Kommers, P., & Richards, G. (Eds.), Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications 1999 (pp. 62-67). Chesapeake, VA: AACE. Sharp R., Fancellu, D. & Stephens M. (2002): EJB's 101 Damnations. Artigo disponível em <http://www.softwarereality.com/programming/ejb/index.jsp>. Última visita em 10/12/2005. Sommerville, I. (2003): Engenharia de Software. 6 ed. São Paulo: Addison Wesley, 2003. Singh, I., Stearns, B., Brydon, S., Murray, G. & Ramachandran, V. (2004): Designing Web Services with J2EE 1.4 Plataform. Pearson Education, 2004. SJCC (2006): Sun Java Code Conventions (SJCC). Documento que especifica convenções de código disponível em <http://java.sun.com/docs/codeconv/>. Última visita em 14/01/2006. Shoham, Y. (1993). Agent-oriented programming. Artificial Intelligence, 60(1):51-92. Spring (2005): Página oficial do framework Spring disponível <http://www.springframework.org/>. Última visita em 9/10/2005. em Struts (2005): Página oficial do framework Struts <http://struts.apache.org/>. Última visita em 9/10/2005. em disponível SuperWaba (2005): Página official da tecnologia SuperWaba disponível em <http://www.superwaba.com.br/en/default.asp>. Última visita em 3/1/2006. Szyperski, C., Bosch, J. & Weck, W. (1997): Sumary of the Second International Workshop on Component-Oriented Programming. In: Second International Workshop on Component-Oriented Programming (WCOP'97), 1997, Jyväskylä. Szyperski, C. (1997): Component Software: Beyond Programming, Addison-Wesley, ISBN 0-201-17888-5 Object-Oriented Tapestry (2005): Página oficial do framework Tapestry disponível em <http://jakarta.apache.org/tapestry/index.html>. Última visita em 2/11/2005. Tate, B., Clark, M., Lee, B. & Linskey, B. (2003): Bitter EJB. Manning Publications Co, 2003. Tomcat (2005): Página oficial do servidor de aplicações Tomcat disponível em <http://tomcat.apache.org/>. Última visita em 20/11/2005. Topley, K. (1999): Core Swing: Advanced Programming. Pearson Education, 1999. Torres, V. S. & Lucena, C. J. P. (2001): Um modelo orientado a objetos para sistemas multi-agentes. 14 p. Port. PUC-RioInf.MCC30/01. Capítulo 7. Referências VirtuaS (2006): Página oficial da empresa VirtuaS <http://www.virtuas.com/>. Última visita em 14/01/2006. 201 disponível em Walls, C. & Breidenbach, R. (2005): Spring in Action. Manning Publishing Co., 2005. WebCharts (2005): Biblioteca de Componentes Adicionais JSF WebCharts disponível em <http://www.webcharts3d.com/>. Última visita em 22/11/06. WebGalileo (2005): Biblioteca de Componentes Adicionais JSF WebGalileo Faces disponível em <http://www.jscape.com/webgalileofaces/index.html>. Última visita em 2/11/06. WebWork (2005): Página oficial do framework WebWork disponível em <http://www.opensymphony.com/webwork/>. Última visita em 2/11/2005. White, J. E. (1994): Telescript technology: The foundation for the electronic marketplace. White paper, General Magic, Inc., 2465 Latham Street, Mountain View, CA 94040. Wooldridge, M. & Jennings, N. R. (1995): Intelligent agents: theory and practice. The Knowledge Engineering Review, 10(2), 11 5-1 52. XDoclets (2005): Página oficial do XDoclet disponível em <http://xdoclet.sourceforge.net/xdoclet/index.html>. Última visita em 20/11/2005. Apêndice A Comunicações Pessoais Durante a pesquisa que resultou nesta dissertação foi necessário entrar em contato com outros pesquisadores para obter dados relevantes para as análises. Este apêndice trás a transcrição dos e-mails trocados com estes pesquisadores. A.1. Comunicação com Christian Bauer Christian Bauer é membro do grupo de desenvolvimento do Hibernate e também é responsável pela página oficial deste framework e pela documentação. Bauer trabalha como desenvolvedor e consultor para o grupo JBoss Inc. (JBoss, 2005) e é co-autor do livro Hibernate in Action (King & Bauer, 2005). Foi preciso entrar em contato com os administradores da página oficial do Hibernate para obter dados sobre o volume de mensagens trocadas no fórum. Inicialmente foi enviada uma mensagem para o e-mail do administrador da página oficial do Hibernate. A mensagem enviada em 10/12/2005 com o assunto “Hibernate Forum” tem o texto transcrito a seguir. Hi, I am writing an article comparing frameworks ORM (Apache OJB, Hibernate, iBATIS and JDOMax). In a section of the article I compare the availability of support of framework ORM like Hibernate, listing the volume of messages exchanged in mailing list in November/2005. Unfortunately I couldn’t meter the amount of messages exchanged in the Hibernate forum (because I can’t list the messages ordered by date). My question is: Is there any possible way of you count the number of messages exchanged in November/2005 at Hibernate Forum (English language only) and send it to me? (Maybe making a select on database or using an administrative interface of the Forum, I don’t know). Apêndice A. Comunicações Pessoais 203 It would add value for my article. Thanks, Celso Jr Bauer respondeu um dia depois de forma sucinta ao e-mail. O texto de sua resposta é transcrito a seguir. 4703 Sua resposta possibilitou uma análise mais detalhada na análise demográfica dos frameworks ORM, no critério disponibilidade de suporte. A.2. Comunicação com Rod Johnson Rod Johnson é um dos fundadores do framework Spring (Spring, 2005), autor dos livros Expert one-on-one J2EE Design and Development (Johnson, 2002) e Expert one-on-one J2EE Development without EJB (Johnson, 2004) e CEO da empresa Interface 21 (2005), que presta suporte comercial para o Spring. Foi preciso entrar em contato com Rod Johnson para obter dados sobre o volume de mensagens trocadas no fórum, pois o site do Spring não oferece a funcionalidade para entrar em contato com o administrador. A mensagem enviada em 27/01/2006 com o assunto “Spring Forum” tem o texto transcrito a seguir. Dear Rod Johnson, I am a master degree student in the IT department of PUC-Rio (http://www.inf.puc-rio.br), a highly prestigious university in Brazil. In my thesis I compare some well-know web frameworks (Spring MVC, Coccon, Struts, Webwork, Tapestry and JSF) and dependency injection frameworks (Spring, PicoCotainer, Excalibur and Hivemind). In the comparison I analyze them technically and non-technically. Inspired by the article “Java Web Frameworks” from Matt Raible I compare the availability of community support for each of these frameworks. The comparison is made by counting the amount of messages Apêndice A. Comunicações Pessoais 204 posted in foruns or mailing list in a given period of time. I was able to collect the number of messages posted on all web frameworks and dependency injection frameworks mailing lists but I couldn’t count the number of messages posted in the Spring forum because the interface of the forum don't list the messages in a given month. Can you, or anyone working with Spring, or somebody you know working at www.springframework.org web site, count the number of messages posted in November/2005 at springframework.org forum, and the amount of messages posted on the Web thread in July/2005 on the springframework.org forum? Or maybe you can put me with contact with the administrators of the forum that probably have access to some kind of administrator interface of the Forum or can mak e a select statement direct on the database? It would add value for the comparison and form my research. Best regards, Celso Gomes Barreto No mesmo dia Rod Johnson respondeu com cópia para Colin Sampaleanu, um de seus funcionários. O texto de sua resposta é transcrito a seguir. Colin, Is this info easy to get at? Rgds Rod Colin Sampaleanu respondeu também no mesmo dia. O texto de sua resposta é transcrito a seguir. I don't think I can get it through the vBulletin management interface, on a month by month basis, but I may be able to do it via a SQL Query. To some extent that depends on the schema. I'll take a look this weekend... Infelizmente não houve resposta desde então, o que leva a crer que Colin Sampaleanu não conseguiu recuperar os dados. Apêndice A. Comunicações Pessoais 205 A.3. Comunicação com Matt Raible Matt Raible é consultor J2EE para a empresa VirtuaS (2006), autor dos livro Spring Live (Raible, 2004) e co-autor do livro Pro JSP (Brown et al., 2005). Raible também possui um blog onde discute assuntos técnicos que recebe mais de três milhões de visitas por mês, disponível em http://raibledesigns.com. Raible escreveu o artigo Java Web Frameworks (Raible, 2005) onde vários web frameworks são comparados. Este arquivo serviu como base para as comparações demográficas realizadas ao longo desta dissertação. Como os gráficos do artigo original eram coloridos e não seguiam o mesmo layout dos outros gráficos usados na dissertação, foi preciso entrar em contato com Raible para obter os dados originais da pesquisa. O e-mail enviado para M. Raible em 2/11/2005 com o assunto Java Web Frameworks é transcrito a seguir. Dear Matt, I read your article “Java Web Frameworks” and I found it very good, specially the part where you compare the articles/books published, jobs counts, tools available, traffic in mailing lists and resumes posted. In fact, I am willing to quote your research in my master’s degree dissertation. My problem is that I can’t just copy and paste your graphics because the have to be black and white (dissertations are printed in black and white in my university) and they have to follow the pattern of the other graphics I am using (I made a research similar you had in resume/employees sites in my country). I would be very glad if you could send me the raw data you used to build your graphics so that I can reproduce them with precision. I am a master degree student in the IT department of PUC-Rio (http://www.inf.puc-rio.br), a highly prestigious university in Brazil. I am also member of a group that makes studies about groupware (http://groupware.les.inf.puc-rio.br/). My dissertation is about “Applying IntraInfrastructure Frameworks to Groupware Systems” with a study case on AulaNet, a learningware environment we develop and use since 1997. In the chapter about Web Frameworks I investigate a set of web frameworks and in the end of the chapter I choose the one that best fits the AulaNet needs. Your research fits well in this chapter because it gives me a non-technical way to compare the web frameworks. Yours faithfully, Celso Gomes Barreto Apêndice A. Comunicações Pessoais 206 Raible respondeu no mesmo dia, oferecendo o arquivo com seus gráficos em dois formatos: Keynote ou PowerPoint, de onde os dados de sua pesquisa poderiam ser extraídos. O texto de seu e-mail é transcrito a seguir. Do you have a Mac with Keynote - or possible PowerPoint? If so, I can send you a presentation with the graphs so you can see the raw data. Matt No dia 3/11/2005 respondi ao Matt, agradecendo a rápida resposta e solicitando o arquivo em formato PowerPoint. O texto deste e-mail é transcrito a seguir. Hi Matt Thanks for your quick answer. I have access to a machine with PowerPoint installed so PowerPoint would be fine. Thanks a lot. Yours faithfully, Celso Gomes Barreto Novamente Matt respondeu no mesmo dia, enviando o arquivo. Este continha ainda atualizações referentes à disponibilidade de suporte. A transcrição do último e-mail enviado por Matt, com o arquivo anexado, é transcrita a seguir. Hopefully this comes through OK. Apêndice B Método Utilizado na Análise Não-Técnica Nesta dissertação foi utilizado um método de comparação entre frameworks que considera os seguintes aspectos de mercado: quantidade de documentação disponível, disponibilidade de suporte, disponibilidade de ferramentas compatíveis com os frameworks comparados, grau de aceitação no mercado e disponibilidade de profissionais. O método utilizado nesta análise é baseado em Raible (2005) é descrito neste apêndice. B.1. Quantidade de Documentação Disponível A categoria “Quantidade de Documentação Disponível” analisa a quantidade de conteúdo disponível, em forma de livros e tutoriais disponíveis na internet. Este método de análise não considera a qualidade da documentação. Para a busca de livros, é realizada uma busca no site de livros www.amazon.com. A chave de busca utilizada é o nome do próprio framework e os resultados são analisados um a um, confirmando se o livro trata do assunto buscado. Para a busca de tutoriais, é realizada uma busca na ferramenta de buscas www.google.com. É impossível validar se cada um dos sites retornados pela busca é realmente um tutorial para o framework desejado, pois a pesquisa pode retornar milhares de resultados. Por isto, a chave de busca foi elaborada de forma a minizar o número de resultados falsos. A chave de busca utilizada para a pesquisa por tutoriais para frameworks ORM é: “orm framework tutorial nome_do_framework” (todas as páginas que contenham todas estas palavras, sendo que nome_do_framework é o nome do framework pesquisado). Já com os frameworks para Dependency Injection foi utilizada a chave de busca “dependency injection framework tutorial nome_do_framework”. Os dados apresentandos correspondem aos dados da pesquisa de Raible (2005). para Web Frameworks Apêndice B. Método Utilizado na Análise Não-Técnica 208 B.2. Disponibilidade de Suporte A categoria “Disponibilidade de Suporte” considera a disponibilidade de suporte técnico oferecido pela comunidade de cada framework. Esta análise não considera a qualidade do suporte prestado. A maior parte dos frameworks possui algum veículo onde os usuários e desenvolvedores do framework podem postar dúvidas, sugerir mudanças e fazer comentários. Em alguns casos este veículo é uma lista de discussão e em outros um fórum de discussão. Para analisar a disponibilidade de suporte pada um determinado framework, analisa-se o volume de mensagens trocadas em um determinado mês. Quanto mais este número mais ativa é a comunidade e, por conseqüência, maior a disponibilidade de suporte. A maior parte das listas de discussão possue interfaces web por onde pode-se acessar o arquivo de mensagens trocadas, desta forma pode-se contabilizar o número de mensagens enviadas em um determinado mês. Já os fóruns não costumam oferecer interfaces para contabilizar as mensagens trocadas em um determinado período. Nestes casos, entra-se em contato com os administradores do fórum que algumas vezes possuem outros meios para efetuar este cálculo. A Tabela B.1 lista os endereços das listas de discussões e Fóruns considerados na pesquisa dos frameworks ORM. Framework Veículo de Suporte Endereço Apache OJB Lista de Discussão http://www.mail-archive.com/ojb-user%40db.apache.org/ Hibernate Fórum http://forum.hibernate.org/ iBATIS Lista de Discussão http://www.mail-archive.com/[email protected]/ JDO Max Nenhum Nenhum Tabela B.1 – Veículos de Suporte dos Frameworks ORM Os frameworks Apache OJB e iBATIS possuem listas de discussão com interfaces onde é possível contabilizar o número de mensagens trocadas em determinado mês. Como o Hibernate oferece suporte através de fórum, foi necessário entrar em contato com os administradores para obter o volume de mensagens trocadas. O JDO Max não possui veículo de suporte. A Tabela B.2 Apêndice B. Método Utilizado na Análise Não-Técnica 209 lista os endereços das listas de discussões e Fóruns considerados na pesquisa dos frameworks para Dependency Injection. Framework Veículo de Suporte Endereço Excalibur Lista de Discussão http://excalibur.apache.org/mail-lists.html HiveMind Lista de Discussão http://mail-archives.apache.org/mod_mbox/jakarta-hivemind-user/ NanoContainer Lista de Discussão http://picocontainer.org/Mailing+lists Fórum e Lista de http://forum.springframework.org/ Discussão e https://lists.sourceforge.net/lists/listinfo/springframework-user e PicoContainer Spring Tabela B.2 – Veículos de Suporte dos Frameworks para Dependency Injection Os frameworks Excalibur e HiveMind oferecem suporte através de listas de discussão. Já o NanoContainer e o PicoContainer compartilham a mesma lista de discussão onde o suporte é oferecido. Por fim, o Spring oferece um Fórum de discussão oficial e uma lista de discussão não oficial onde o suporte é oferecido. Para os Web Frameworks, são usados os dados coletados em Raible (2005). B.3. Disponibilidade de Ferramentas Compatíveis A categoria “Disponibilidade de Ferramentas Compatíveis” analisa a quantidade de ferramentas disponíveis para cada um dos frameworks analisados. São analisados ambientes de desenvolvimento (IBM WSAD, Sun Java Studio Enterprise, Borland JBuilder, Oracle JDeveloper, BEA Workshop e InteliJ IDEA), plugins para as plataformas Eclipse e Netbeans, ferramentas de produtividade (XDoclets e Middlegen) além de outras ferramentas disponíveis nos sites dos próprios frameworks. A pesquisa é realizada analisando a documentação provida por cada ferramenta. Se a ferramenta oferece recursos para o desenvolvimento com o framework como, por exemplo, editores visuais e geradores de código, a ferramenta é considerada compatível. O resultado da análise é a soma de todas as ferramentas compatíveis com o framework. Este método é aplicado tanto para Frameworks ORM quanto para frameworks para Dependency Injection. Para os Web Frameworks, são usados os dados da pesquisa de Raible (2005). Apêndice B. Método Utilizado na Análise Não-Técnica 210 B.4. Grau de Aceitação no Mercado O “Grau de Aceitação no Mercado” analisa se o mercado aceita ou rejeita um determinado framework. Para efetuar esta análise é feita uma pesquisa em sites de oferta de emprego, procurando por vagas que demandem aptidão nos frameworks comparados. São realizadas buscas no site americano Dice.com (www.dice.com) e no nacional Manager Online (www.manageronline.com.br). Para minimizar os resultados falsos, a chave de busca utilizada é “java framework nome_do_framework” onde nome_do_framework corresponde ao nome do framework analisado. B.5. Disponiblidade de Profissionais A “Disponibilidade de Profissionais” analisa o número de desenvolvedores que se consideram aptos a trabalhar com os frameworks comparados. Para isto, são analisadas buscas em sites que hospedam currículos. São analisados o site americano Jobs.net (www.jobs.net) e o site nacional APInfo.com (www.apinfo.com). Raible (2005) utiliza o site americano Monster.com (www.monster.com), contudo este é um site pago e não pode ser usado na pesquisa que resultou nesta dissertação. São usadas as mesmas chaves de pesquisa utilizadas na categoria “Grau de Aceitação do Mercado” para minimizar os resultados falsos.
Documentos relacionados
framework de aplicações web para plataformas e - FACOM
O governo, em suas diferentes esferas (municipal, estadual e federal), tem o desafio de utilizar a Tecnologia de Informação e Comunicação para compartilhar informações, dar maior transparência na g...
Leia mais