Agregando Frameworks de Infra-Estrutura em uma Arquitetura...

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ós-Graduaçã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ós-graduaçã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 Infra-Estrutura 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ão-

té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 74

Figura 3.6 - Mensagens Trocadas em Listas de Discussão (11/2005) 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 101

Figura 3.17 - Mensagens Trocadas em Listas de Discussão (11/2005) 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. 105

Figura 3.21 - Disponibilidade de Profissionais em 12/2005 Fonte: Jobs.net. 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 142

Figura 4.10 – Ofertas de Emprego Fonte: Manager Online, Outubro de 2005 142

Figura 4.11 - Disponibilidade de Profissionais com Habilidades nos Frameworks

Fonte: Monster.com, Junho de 2005 (Raible, 2005) 143


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. 150

Figura 5.2 – Arquitetura Técnica do AulaNet 3.0 Apresentada na Seção 1.3. 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.

COMUNICAÇÃO

COORDENAÇÃOCOOPERAÇÃO

gera compromissos gerenciados pela

organiza as tarefas para

demanda PercepçãoContexto

comum + açãoAção de tornar comum

co + ordem + açãoAção de organizar

em conjunto

co + operar + açãoAção de operar

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


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 incluem-

se 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


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 Co-

Autoria.

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)


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.

Debate Conferência

Correio p/ Turma

Correio paraParticipante

Bate-papo

COMUNICAÇÃOAssíncronaSíncrona

Informações

Acompanham.da Participação

Tarefas

COORDENAÇÃO

Co-autoria

COOPERAÇÃO

MensagemInstantânea

Aulas

Documentação

Bibliografia

Webliografia

Download

Avisos

Exame

Pesq. Opinião

Acompanham.da Navegação

Certificado

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


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


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údoWeb

Java

AplicaçõesServlets

Scriba

Servlets eClasses Java

PáginasHTML

Servidor deDebate

Servidor dePresenç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


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


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 infra-

estrutura (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


Arquitetura de POJOs descrita por Johnson (2002, 2004), é organizada nas

seguintes camadas: apresentação, negócios e recursos.

Façade

Data Access Object

V

M(DTO)

Camada deNegócios

Camada deApresentação

Camada deRecursos

C

SGBD

MailSender

Servidor deE-Mails

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


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


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.


Infrastructure Frameworks

.

Component

Framework

ServiceComponentFramework

CollaborationComponentFramework

Service X

3C Component A

3C Component B

Service Y

Framework

.

.

GroupwareApplication

Database

Groupware

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.


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

CoordenaçãoCooperação

Processo de Desenvolvimento de Groupware

Figura 1.8. Foco para o desenvolvimento de uma versão da

aplicação groupware com base no Modelo 3C de Colaboração


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.


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: public static void main(String args[]) {32: System.out.println("Olá, leitores!") ;33: }

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.


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


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 infra-

estrutura, 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


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


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


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


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 infra-

estrutura 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


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.


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.


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 infra-

estrutura 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


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 infra-

estrutura 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


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.


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 é


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 infra-

estrutura 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


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.


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


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


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


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


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


(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


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.

Message

-text:String

+getAuthor():User+setAuthor(user:User):void+getText():String+setText(text:String)void

User

-username:String-name:String

+getUsername():String+setUsername(username:String):void+getName():String+setName(name:String):void

11

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 infra-

estrutura. 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.


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. É


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, é


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

-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

User

-id:Long-username:String-name:String

+getId():Long+setId(id:Long):void+getUsername():String+setUsername(username:String):void+getName():String+setName(name:String):void

11

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: private Long id;03: private String text;04: private Date date;05: private User author;

06: public void setId(Long newValue) { id = newValue; }07: public Long getId() { return id; }

08: public void setText(String newValue) { text = newValue; }09: public String getText() { return text; }

10: public void setDate(Date newValue) { date = newValue; }11: public Date getDate() { return date; }

12: public void setAuthor(User newValue) { author = newValue; }13: public User getAuthor() { return author; }

14: } Listagem 3.1 – Classe Message


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: private Long id;17: private String username;18: private String name;


21: public void setUsername(String newValue) { username = newValue; }22: public String getUsername() { return username; }

23: public void setName(String newValue) { name = newValue; }24: 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.

26: <?xml version='1.0' encoding='utf-8'?>27: <!DOCTYPE hibernate-configuration28: 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/AulaNetDB35: </property>36: <property name="dialect">net.sf.hibernate.dialect.MySQLDialect</property>

37: 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.



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: <property name="username"54: type="string"55: column="USRNAME"56: length="50"57: 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


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.


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: <many-to-one name="author"82: class="User"83: column="AUTHOR_ID"84: not-null="true"85: 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


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: public static void main(String[] args) {090: SessionFactory sfactory = null;091: Session sess = null;092: Transaction tx = null;

093: try {094: sfactory = new Configuration().configure().buildSessionFactory();095: sess = sfactory.openSession();096: tx = sess.beginTransaction();

097: User usr = new User();098: usr.setUsername("johnd"); usr.setName("John Doe");099: Message msg = new Message();100: msg.setText("Test message"); msg.setDate(new Date());101 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


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.




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.



138: public static void main(String[] args) {139: SessionFactory sfactory = null;140: Session sess = null;

141: try {142: sfactory = new Configuration().configure().buildSessionFactory();143: sess = sfactory.openSession();

144: String queryStr = "from User where user.name like ?";145: Query qry = sess.createQuery(queryStr);146: qry.setString(0, "Mark%");147: Collection usrs = qry.list();

148: System.out.println(usrs.size() + " users selected.");149: for (Iterator i = usrs.iterator(); i.hasNext(); {150: User u = (User) i.next();151: System.out.println(u.getName());152: }

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.




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.


User

-username:String-password:String

+setUsername(username:String):void+getUsername():String+setPassword(password:String):void+getPassword():String

Administrator

- phone:String

+setPhone(phone:String):void+getPhone():String

Learner

-email: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


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 <joined-

subclass>.

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.


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-para-

muitos. 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.


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


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.


0

2

4

6

8

10

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.

0

20000

40000

60000

80000

100000


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.


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.

0

1000

2000

3000

4000

5000

Apache OJB Hibernate iBATIS

Figura 3.6 - Mensagens Trocadas em Listas de Discussão (11/2005)


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.

0

5

10

15


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.


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.

0

100

200300

400

500

600


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 norte-

americano. 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 empregos Manager Online

(http://www.manageronline.com.br/).


0

5

10

15

20


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.


0

250

500

750

1000

1250

1500


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.

0

50

100

150

200

250

300


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.


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 é


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.


ConferenceFacade

messageDAO:MessageDAO

ConferenceFacade():voidpostMessage(m:Message):voidlistMessages():Message[]

<<Interface>>MessageDAO

createMessage(m:Message):voidupdateMessage(m:Message):voidremoveMessage(m:Message):voidlistMessages():Message[]

MessageDAOImpl<<create>>

dao = new MessageDAOImpl();

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.

ConferenceFacade

dao:MessageDAO

ConferenceFacade():voidsetDAO(dao:MessageDAO):voidpostMessage(m:Message):voidlistMessages():Message[]



MessageDAOImpl

Assembler<<create>>

<<create and set>>

this.dao = dao;

Figura 3.13 - Dependências Configuradas com Dependency Injection


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.


ConferenceFacade

dao:MessageDAO

setDAO(dao:MessageDAO):voidpostMessage(m:Message):voidlistMessages():Message[]



MessageDAOImpl

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

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.



02: private Long id;03: private String text;04: private Date date;


07: public void setText(String newValue) { text = newValue; }08: public String getText() { return text; }

09: public void setDate(Date newValue) { date = newValue; }10: 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: public void createMessage(Message m);14: public void updateMessage(Message m);15: public void removeMessage(Message m);16: 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.


18: public class ConferenceFacade {

19: private MessageDAO messageDao;

20: public void setMessageDao(MessageDAO dao) { messageDao = dao; }

21: public void postMessage(Message m) {22: messageDao.createMessage(m);23: }

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.


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: <bean id="messageDAO"33: class="MessageDAOImpl">34: </bean>

35: <bean id="conferenceFacade"36: class="ConferenceFacade">37: <property name="messageDao">38: <ref local="messageDAO"/>39: </property>40: </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.


42: <?xml version="1.0" encoding="UTF-8"?>43: <!DOCTYPE web-app PUBLIC44: "-//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.ContextLoaderListener54: </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.


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.MySQLDialect23: </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.


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 HibernateDaoSupport36: implements MessageDAO {

37: public void createMessage(Message m) {38: getHibernateTemplate().save(m);39: }

40: public void updateMessage(Message m) {41: getHibernateTemplate().saveOrUpdateCopy(m);42: }

43: public void removeMessage(Message m) {44: getHibernateTemplate().delete(category);45: }

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.


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,


“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 sujas, não repetíveis e fantasmas.

ISOLATION_READ_COMMITTED que evita leituras 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.

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" class="org.springframework.jndi.JndiObjectFactoryBean">06: 07: </bean>08: <bean id="sessionFactory"09: class="org.springframework.orm.hibernate.LocalSessionFactoryBean">10: 11: </bean>

12: <bean id="txManager"13: class="org.springframework.orm.hibernate.HibernateTransactionManager">14: <property name="sessionFactory" ref="sessionFactory"/>15: </bean>

16: <bean id="messageDAOTarget"17: class="MessageDAOImpl">18: <property name="sessionFactory" ref="sessionFactory">19: </bean>

20: <bean id="messageDAO"21: class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">22: <property name="transactionManager" ref="txManager"/>23: <property name="target" ref="messageDAOTarget"/>24: <property name="proxyInterfaces">25: <value>MessageDAO</value>26: </property>27: <property name="transactionAttributes">28: <props>29: <prop key="list*">PROPAGATION_REQUIRED,readOnly</prop>30: <prop key="*">PROPAGATION_REQUIRED</prop>31: </props>32: </property>33: </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


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 é


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.

01: <beans>02: 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_MEDIATOR26: MessageDAO.updateMessage=ROLE_MEDIATOR27: MessageDAO.removeMessage=ROLE_MEDIATOR28: MessageDAO.list*=ROLE_APPRENTICE,ROLE_MEDIATOR29: </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_APPRENTICE47: mauro=abacate,ROLE_MEDIATOR48: </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


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


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.

01: <beans>02: 

03: <bean id="conferenceFacade" class="ConferenceFacadeImpl">04: <property name="messageDao" ref="messageDAO"/>05: </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).


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.


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.

0

5

10

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.

0

10000

20000

30000

40000

50000

60000


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


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.


0

20

40

60

80

100

120

140

Excalibur HiveMind NanoContainer ePicoContainer

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.


0

1

2

3

4

5

6

7


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.


0

100

200

300

400


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/).

0

1

2


Figura 3.20 - Vagas Abertas para cada Framework de Dependency Injection

Fonte: Manager Online, Dezembro de 2005.


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.

0

50

100

150

200


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.


0

10

20

30

40


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, pode-

se optar por um framework de componentes, como o Enterprise JavaBeans ou


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 infra-

estrutura 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,


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 infra-

estrutura 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.


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.


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.

M V

C1

32

4

5

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


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.

M V

C1

32

4

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


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


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


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.ActionServlet06: </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 chama-

se struts-config.xml, a parte variável da URL é mapeada em ações. A Listagem

4.2 exibe um exemplo deste arquivo.


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: <action20: 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: <forward26: name="success"27: path="/conference/postMessageSuccess.jsp"/>28: <forward29: 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.


34: public class PostMessageAction extends Action {

35: public ActionForward execute(ActionMapping mapping,36: ActionForm form, HttpServletRequest request,37: HttpServletResponse response) throws ServletException {

38: PostMessageForm formBean = (PostMessageForm) form;

39: try {40: ConferenceFacade facade = new ConferenceFacadeImpl();41: facade.postMessage(request.getRemoteUser(),42: formBean.getParentId(), formBean.getConferenceId(),43: 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 struts-

config.xml, é exibido na Listagem 4.4.


50: public class PostMessageForm extends ValidatorForm {

51: private String parentId;52: private String conferenceId;53: private String categoryId;54: private Message message;

55: public void setParentId(String newValue) {56: parentId = newValue;57: }58: public String getParentId() { return parentId; }

59: public void setConferenceId(String newValue) {60: conferenceId = newValue;61: }62: public String getConferenceId() { return conferenceId; }

63: public void setCategoryId(String newValue) {64: categoryId = newValue;65: }66: 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.


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.


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


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


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.


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


negócios. O controlador associado à requisição postMessage é mostrado na

Listagem 4.9.

39: public class PostMessageController extends SimpleFormController {

40: private ConferenceFacade confFacade;41: private String failureView;

42: public PostMessageController() {43: setCommandClass(Message.class);44: }

45: public void setConferenceFacade(ConferenceFacade newValue) {46: confFacade = newValue;47: }48: public void setFailureView(String newValue) {49: failureView = newValue;50: }

51: protected ModelAndView onSubmit(HttpServletRequest request,52: HttpServletResponse response, Object command, BindException errors)53: throws Exception {54: Message message = (Message) command;

55: try {56: facade.postMessage(request.getRemoteUser(),57: message.getParentId(), message.getConferenceId(),58: message.getCategoryId(), message);59: } catch (Exception e) {60: return new ModelAndView(failureView);61: }62: return new ModelAndView(getSuccessView());63: }64: }

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


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.


66: private String parentId;67: private String conferenceId;68: private String categoryId;69: private String message;70: private String subject;

71: public void setParentId(String newValue) { parentId = newValue; }72: public String getParentId() { return parentId; }

73: public void setConferenceId(String newValue) { conferenceId = newValue; }74: public String getConferenceId() { return conferenceId; }

75: public void setCategoryId(String newValue) { categoryId = newValue; }76: public String getCategory() { return categoryId; }

77: public void setMessage(String newValue) { message = newValue; }78: 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


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: public boolean supports(Class clazz) {84: return clazz.equals(Message.class);85: }

86: public void validate(Object command, Errors errors) {87: ValidationUtils.rejectIfEmptyOrWhitespace(errors, "categoryId",88: "postMessage.categoryId.required", "Category empty.");89: ValidationUtils.rejectIfEmptyOrWhitespace(errors, "conferenceId",90: "postMessage.conference.required", "Conference empty.");91: ValidationUtils.rejectIfEmptyOrWhitespace(errors, "message",92: "postMessage.message.required", " Message empty.");93: ValidationUtils.rejectIfEmptyOrWhitespace(errors, "subject",94: "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


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:message115: 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


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.


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.puc-

rio.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.


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.


37: public class MessageController {

38: private String parentId;39: private String conferenceId;40: private String categoryId;41: private Message message;

42: public void setParentId(String newValue) { parentId = newValue; }43: public String getParentId() { return parentId; }44: public void setConferenceId(String newValue) { conferenceId = newValue; }45: public String getConferenceId() { return conferenceId; }46: public void setCategoryId(String newValue) { categoryId = newValue; }47: public String getCategoryId() { return categoryId; }48: public void setMessage(Message message) { message = newValue; }49: public Message getMessage() { return message; }

50: public String postMessage() {

51: try {52: ConferenceFacade facade = new ConferenceFacadeImpl();53: FacesContext ctx = FacesContext.getCurrentInstance();54: String author = ctx.getExternalContext().getRemoteUser();55: facade.postMessage(author, parentId, conferenceId, categoryId, message);56: } catch (Exception e) {57: return "failure";58: }59: return "success";60: }61: }

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


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


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 “nome-

do-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


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.


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


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.

0

5

10

15

20

25

30

35

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).


0

1500

3000

4500

6000

7500

Cocoon Struts SpringMVC

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.


0

500

1000

1500

2000

2500

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).


0

2

4

6

8

10

12

14

16

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.


0

250

500

750

1000

1250

1500

1750

Cocoon Struts SpringMVC

WebWork Tapestry JSF

Outubro de 2004

Junho de 2005

Novembro de 2005

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).

0

10

20

30

40

50

60

Cocoon Struts Spring MVC WebWork Tapestry JSF

Figura 4.10 – Ofertas de Emprego

Fonte: Manager Online, Outubro de 2005


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.

0

100

200

300

400

500

600

700



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.


0

100

200

300

400

500

600

700



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


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).


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


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


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 infra-

estrutura 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


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.


.

Component

Framework

ServiceComponentFramework


Debate

Msg Manager

Msg Locator

Conferência

Component

.

.

AulaNet

Database

Groupware


Façade

Data Access Object

V

M(DTO)

Camada deNegócios


Camada deRecursos

C

SGBD

MailSender

Servidor deE-Mails

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).


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.



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.


.

.

.

Database

Component

Framework

GroupwareComponentFramework


Debate

Msg Manager

Msg Locator

Conferência

Component

Application

Hibernate

Spring


Façade

Spring/HibernateData Access Object

M(DTO)

Camada deNegócios


Camada deRecursos

ServletJSF Controller

MailSender

SGBDServidor deE-Mails

JSPComponenteJSF

Proxy (Spring)

XML

DTO.hbm.xml

IFaçade

IFaçade

Backing Bean

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


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.


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.


Façade


M(DTO)

Camada deNegócios


Camada deRecursos

AulaNetM

MailSender


Proxy (Spring)

XML

DTO.hbm.xml

IFaçade

IFaçade

Serviços Móveis

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


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.


Façade


M(DTO)

Camada deNegócios

Camada deRecursos

MailSender


Proxy (Spring)

XML

DTO.hbm.xml

IFaçade

IFaçade

Proxy Remoto (Spring)

ClienteGordo


JSFController

JSPComponenteJSF

Backing Bean

Serviços Móveis

Web Services

Camada de Apresentação+ Negócios

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.


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).


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 (agent-

communication 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).


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.


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


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.


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.


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).


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.


<< interface >>JadeLeapAdapter

+startContainer()+stopContainer()+isContainerRunning()+getContainerController():ContainerController+createAgent(def:AgentDefinitionByClassName):AgentController+createAgent(def:AgentDefinitionByAgentInstance):AgentController+killAgent(agentName:String)+getAgentController(agentName:String):AgentController

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)

org.springframework.beans.factory

<< interface >>BeanFactoryAware

+setBeanFactory(beanFactory:BeanFactory)

<< interface >>InitializingBean

+afterPropertiesSet()

<< interface >>DisposableBean

+destroy()

AgentDefinition

-name:String

+AgentDefinition()+AgentDefinition(name:String)+getName():String+setName(name:String)

AgentDefinitionByAgentInstance

+AgentDefinitionByAgentInstance()+AgentDefinitionByAgentInstance(agent:Agent)+AgentDefinitionByAgentInstance(agent:Agent, name:String)

AgentDefinitionByClassName

-className:String-arguments:Object[]

+getClassName():String+setClassName(className:String)+getArguments():Object[]+setArguments(args:Object[])

jade.core

Agent

0..1

0..*

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.


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


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 multi-

agentes “O Que Há de Novo na Conferência?” que tem pouca aplicação prática,


mas que é mostrado com mais detalhes por ser mais simples, e como

conseqüência mais didático. Na segunda parte é mostrado um sistema multi-

agentes “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 Jade-

Leap 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.


JADE-LEAPFront-End

Split Container

JADE-LEAPMain Container

Plataforma JADE

MobileAgent

JADE-LEAPBack-End

ConferenceAgent

AulaNet 3

Spring

Hibernate

JSFConector

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,


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: protected void setup() {04: addBehaviour(new WhatIsNewInConferenceBehaviour());05: }

06: protected void takeDown() {07: facade = null;08: }

09: public final ConferenceFacade getConferenceFacade() {10: return conferenceFacade;11: }

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.


16: public class WhatIsNewInConferenceBehaviour extends CyclicBehaviour {

17: private final Map lastConference = new HashMap();

18: public void action() {19: MessageTemplate mt = MessageTemplate.and(20: MessageTemplate.MatchPerformative(ACLMessage.QUERY_IF),21: MessageTemplate.MatchConversationId("conference-status"));

22: ACLMessage msg = myAgent.receive(mt);23: if (msg != null) {24: AID sender = msg.getSender();25: Conference oldConference = (Conference) lastConference.get(sender);26: String conferenceId = msg.getContent();27: ConferenceFacade ca = (ConferenceAgent) myAgent;28: ConferenceFacade facade = ca.getConferenceFacade();29: Conference newConference = facade .findConferenceById(conferenceId);

30: List newMessages = getNewMessages(oldConference, newConference);31: List deletedMessages = getDeletedMessages(oldConference, newConference);32: List categorizedMessages = getCategorizedMessages(oldConference, newConference);33: List evaluatedMessages = getEvalutatedMessages(oldConference, newConference);34: String content = buildReplyContent(newMessages, deletedMessages,35: 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.


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


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 é


implementado na classe ConferenceQueryBehaviour, 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: private int step = SEND_QUERY;090: private static final int SEND_QUERY = 1;091: private static final int RECEIVE_RESPONSE = 2;092: private static final int FINISH = 3;093: private String conferenceId;

094: public ConferenceQueryBehaviour(String conferenceId) {095: this.conferenceId = conferenceId;096: }

097: public void action() {098: switch (step) {099: case SEND_QUERY:100: AID receiver = new AID("Conference-Agent", AID.ISLOCALNAME);101: ACLMessage query = new ACLMessage(ACLMessage.QUERY_IF);102: query.addReceiver(receiver);103: query.setConversationId("conference-status");104: query.setContent(conferenceId);105: query.setReplyWith("query" + System.currentTimeMillis());106: myAgent.send(query);

107: template = MessageTemplate.and(108: MessageTemplate.MatchConversationId("conference-status"),109: MessageTemplate.MatchInReplyTo(query.getReplyWith()));110: step = RECEIVE_RESPONSE;111: break;112: case RECEIVE_RESPONSE:113: ACLMessage reply = myAgent.receive(template);

114: if (reply != null) {115: System.out.println(reply.getContent());116: step = FINISH;117: } else {118: block();119: }120: break;121: }122: }

123: public boolean done() {124: return step == FINISH;125: }126: }

Listagem 5.5 – Comportamento ConferenceQueryBehaviour


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.


Figura 5.10 – PDA Após a Inicialização

do Jade-Leap

Figura 5.11 – PDA Após a Primeira

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.


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


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.


Figura 5.13 – Informações Visuais no

AulaNetM

Figura 5.14 – Informações Estatísticas

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 é


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

AulaNetM

Figura 5.16 – Informações Estatísticas

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


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.


Façade


M(DTO)

Camada deNegócios


Camada deRecursos

JSFController

MailSender


JSPComponenteJSF

Proxy (Spring)

XML

DTO.hbm.xml

IFaçade

IFaçade

Backing Bean

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 é


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


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. Constatou-

se 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 (PUC-

Rio) 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 infra-

estrutura 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.


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


(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. Estima-

se 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


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,


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 disponível em <http://avalon.apache.org/>. Última visita em 11/12/2005.

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 disponível em <http://www.caucho.com/>. Última visita em 11/12/2005.

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 em <http://java.sun.com/products/ejb/index.jsp>. Última visita em 20/10/2005.

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 FIPA disponível em <http://www.fipa.org/>. Última visita em 5/1/2006.

Fowler, M. (2002): Patterns of Enterprise Application Architecture. Addison-Wesley, 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.


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


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 em <http://java.sun.com/j2me/index.jsp>. Última visita em 3/1/2006.

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 do padrão JavaBeans disponível em <http://java.sun.com/beans>.

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 em <http://java.sun.com/products/jdbc/index.jsp>. Última visita em 28/11/2005.

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 JNDI disponível em <http://java.sun.com/products/jndi/index.jsp >.

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.


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-many-java-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, LU-CS-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 disponível em <http://myfaces.apache.org/>. Última visita em: 25/10/2005.

NanoContainer (2005): Página oficial do framework NanoContainer disponível em <http://nanocontainer.codehaus.org/>. Última visita em 11/12/2005.


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.html>. Ú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, artigo disponível em <http://www.virtuas.com/osl-jwf-01.pdf>.

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.


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 em <http://www.springframework.org/>. Última visita em 9/10/2005.

Struts (2005): Página oficial do framework Struts disponível em <http://struts.apache.org/>. Última visita em 9/10/2005.

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 Object-Oriented Programming, Addison-Wesley, ISBN 0-201-17888-5

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.


VirtuaS (2006): Página oficial da empresa VirtuaS disponível em <http://www.virtuas.com/>. Última visita em 14/01/2006.

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


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.


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 Intra-Infrastructure 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


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 para Web Frameworks

correspondem aos dados da pesquisa de Raible (2005).

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


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

e PicoContainer

Lista de Discussão http://picocontainer.org/Mailing+lists

Spring Fórum e Lista de

Discussão

http://forum.springframework.org/

e https://lists.sourceforge.net/lists/listinfo/springframework-user

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).


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.

Agregando Frameworks de Infra-Estrutura em uma Arquitetura...

Documents

Transcript of Agregando Frameworks de Infra-Estrutura em uma Arquitetura...