Documento - Groupware@LES - PUC-Rio

Transcrição

Celso Gomes Barreto
Agregando Frameworks de Infra-Estrutura
em uma Arquitetura Baseada em Componentes:
Um Estudo de Caso no Ambiente AulaNet
Dissertação de Mestrado
Dissertação apresentada ao Programa de PósGraduação em Informática da PUC-Rio como
requisito parcial para obtenção do título de Mestre
em Informática.
Orientador: Hugo Fuks
Rio de Janeiro, março de 2006
Celso Gomes Barreto Junior
Agregando Frameworks de Infra-Estrutura
em uma Arquitetura Baseada em Componentes:
Um Estudo de Caso no Ambiente AulaNet
Dissertação apresentada como requisito parcial para a
obtenção do grau de Mestre pelo Programa de Pósgraduação em Informática do Departamento de
Informática do Centro Técnico e Científico da PUC-Rio.
Aprovada pela Comissão Examinadora abaixo assinada.
Prof. Hugo Fuks
Orientador
Departamento de Informática – PUC-Rio
Prof. Carlos José Pereira de Lucena
Prof. Alberto Raposo
Profa. Flávia Maria Santoro
UNI-Rio
Prof. José Eugenio Leal
Coordenador Setorial do Centro
Técnico Científico – PUC-Rio
Rio de janeiro, 14 de Março de 2006
Todos os direitos reservados. É proibida a reprodução total
ou parcial do trabalho sem autorização da universidade, do
autor e do orientador.
Celso Gomes Barreto
Graduou-se em Ciência da Computação na Universidade
Federal do Rio de Janeiro em 2002. Durante a graduação
atuou no projeto Enibam (Ensino Informatizado em Tópicos
Básicos de Matemática). Durante o mestrado atuou no
projeto AulaNet responsabilizando-se pela arquitetura e
infra-estrutura técnica.
Ficha Catalográfica
Barreto, Celso Gomes
Agregando frameworks de infra-estrutura em uma
arquitetura baseada em componentes : um estudo de caso
no ambiente AulaNet / Celso Gomes Barreto ; orientador:
Hugo Fuks. – Rio de Janeiro : PUC, Departamento de
Informática, 2006.
210 f. : il. ; 30 cm
Dissertação (mestrado) – Pontifícia Universidade
Católica do Rio de Janeiro, Departamento de Informática
Inclui referências bibliográficas.
1. Informática – Teses. 2. Desenvolvimento de
groupware. 3. Componentes de software. 4. Arquiteturas
multicamadas de software. 5. Frameworks. I. Fuks, Hugo.
II. Pontifícia Universidade Católica do Rio de Janeiro.
Departamento de Informática. III. Título.
Agradecimentos
Ao professor Hugo Fuks por acreditar no meu potencial e pela inestimável
orientação ao longo destes dois anos.
Aos companheiros de consórcio, Marco Aurélio Gerosa e Mariano Gomes
Pimentel, que me acompanharam nesta difícil jornada.
Aos meus pais, Celso Gomes Barreto e Isaura Maria Moreira Barreto pelo apoio,
incentivo e afeto.
Aos meus colegas do LES e do projeto AulaNet pelo companheirismo. Em
especial à Denise Del Re Filippo por me auxiliar na preparação para a defesa.
A todos com quem já trabalhei. Em especial a Juliana Lucas de Rezende, pelo
incentivo e aconselhamento.
Aos professores da Universidade Federal do Rio de Janeiro por minha formação
na graduação, sem a qual não teria chegado até aqui.
A CAPES e à Fundação Padre Leonel Franca pelo apoio financeiro.
E a todos aqueles que direta ou indiretamente contribuíram para a realização deste
trabalho.
Resumo
Barreto, Celso Gomes; Fuks, Hugo. Agregando Frameworks de InfraEstrutura em uma Arquitetura Baseada em Componentes: Um Estudo
de Caso no Ambiente AulaNet. Rio de Janeiro, 2006. 210p. Dissertação de
Mestrado – Departamento de Informática, Pontifícia Universidade Católica
do Rio de Janeiro.
Groupware é difícil de construir e de manter, pois envolve aspectos
multidisciplinares. Além das dificuldades associadas ao desenvolvimento de
aplicações colaborativas, usualmente o desenvolvedor de groupware deve se
preocupar com outros aspectos de infra-estrutura. Nesta dissertação é proposta
uma arquitetura multicamadas baseada em componentes para groupware,
utilizando frameworks de infra-estrutura. Na camada de negócio são utilizados os
frameworks Hibernate, responsável pela persistência dos dados da aplicação, e o
framework Spring, que dentre outras coisas é responsável pelo controle de
transações e pela exposição de serviços remotamente. Na camada de apresentação
o framework JaveServer Faces provê meios para criar e reusar componentes de
interface. Nesta dissertação também é apresentada uma forma de comparar
frameworks de infra-estrutura, levando em consideração tanto aspectos técnicos,
que definem se o framework atende aos requisitos da aplicação, quanto nãotécnicos, relacionados a aspectos como documentação disponível e aceitação no
mercado. A arquitetura definida nesta dissertação é aplicada no AulaNet,
groupware voltado para a aprendizagem desenvolvido no Laboratório de
Engenharia de Software da PUC-Rio.
Palavras-chave
Desenvolvimento de groupware; componentes de software; arquiteturas
multicamadas de software; frameworks.
Abstract
Barreto, Celso Gomes; Fuks, Hugo (Advisor). Adding System
Intrastructure Frameworks in an Component Based Architecture: A
Case Study within the AulaNet Environment Rio de Janeiro, 2006. 210p.
M.Sc. Dissertation – Computer Science Department, Pontifical Catholic
University of Rio de Janeiro.
Groupware is difficult to develop and maintain because it involves
multidisciplinary aspects in its construction. Besides the difficulties related to the
development of collaborative applications, usually the developer must handle with
other infrastructure aspects. In this dissertation, it is proposed a multilayer
component based architecture with system infrastructure frameworks to deal with
them. In the business layer, the Hibernate framework is responsible for the
persistence of application data, and the Spring framework is responsible for,
amongst others, transactions control and remote exposition of services. In the
presentation layer the JaveServer Faces framework provides ways to create and to
reuse user-interface components. This dissertation also presents a way to compare
system infrastructure frameworks, considering both technical aspects, related to
the application requirements fulfillment, and non-technical, related to aspects such
as documentation availability and market acceptance. The architecture defined in
this dissertation is applied to the AulaNet, which is a groupware for learning
developed in the Software Engineering Laboratory of PUC-Rio.
Keywords
Groupware development; software components. multilayer software
architecture; frameworks.
Sumário
1 Introdução
16
1.1. Groupware e o Modelo 3C
16
1.1.1. Comunicação
17
1.1.2. Coordenação
18
1.1.3. Cooperação
19
1.2. O AulaNet
19
1.2.1. A Arquitetura do AulaNet 2.1
22
1.3. Consórcio de Pesquisa
23
1.3.1. Agregando Frameworks de Infra-Estrutura em uma Arquitetura
Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet 24
1.3.2. Desenvolvimento de Groupware Componentizado com base no
Modelo 3C de Colaboração
26
1.3.3. RUP-3C-Groupware: um Processo de Desenvolvimento de
Groupware baseado no Modelo 3C de Colaboração
29
1.4. Organização da Escrita
30
2 Frameworks: Conceitos Gerais
33
2.1. Definições de Frameworks
33
2.2. Classificação dos Frameworks
34
2.2.1. Frameworks de Aplicações Orientado a Objetos
34
2.2.2. Frameworks de Componentes
36
2.3. Papéis Envolvidos no Uso e Desenvolvimento de um Framework
37
2.4. Conseqüências da Adoção de Frameworks
37
2.4.1. Benefícios Decorrentes da Utilização de Frameworks
38
2.4.2. Desafios Decorrentes da Utilização de Frameworks
39
2.5. Frameworks e Outras Abordagens
41
2.5.1. Frameworks e Aplicações Orientado a Objetos
41
2.5.2. Frameworks e Biblioteca de Classes
41
2.5.3. Frameworks e Padrões de Projeto
42
2.5.4. Frameworks e Componentes de Software
42
2.6. Conclusão
43
3 A Camada de Negócios
47
3.1. O Modelo de Componentes Enterprise JavaBeans
47
3.1.1. Vantagens Decorrentes do Uso de Enterprise JavaBeans
49
3.1.2. Desvantagens Decorrentes do Uso de Enterprise JavaBeans
50
3.1.3. O Futuro do Enterprise JavaBeans
52
3.2. Uma Arquitetura Usando POJOs
53
3.3. Questões Decorrentes do Mapeamento Objetos em Tabelas
54
3.3.1. Conflito de Paradigmas: Orientação a Objetos x Relacional
54
3.4. Frameworks ORM
57
3.4.1. O Framework Hibernate
58
3.4.1.1. Hibernate - Um Exemplo Prático
58
3.4.1.2. Hibernate e a Questão dos Subtipos
68
3.4.1.3. Hibernate e a Questão da Igualdade
70
3.4.1.4. Hibernate e as Questões dos Relacionamentos
71
3.4.1.5. Hibernate e a Questão do Grafo de Navegação
71
3.4.1.6. Considerações Finais Sobre o Hibernate
72
3.4.2. Outros Frameworks ORM
73
3.4.2.1. Quantidade de Documentação Disponível
73
3.4.2.2. Disponibilidade de Suporte
75
3.4.2.3. Disponibilidade de Ferramentas Compatíveis
76
3.4.2.4. Grau de Aceitação no Mercado
77
3.4.2.5. Disponibilidade de Profissionais
78
3.4.2.6. Resultado da Comparação entre Frameworks ORM
80
3.5. O Framework de Infra-Estrutura Spring
80
3.5.1. Dependency Injection
81
3.5.2. Dependency Injection com Spring
83
3.5.3. Integração do Hibernate com o Spring
88
3.5.4. Transações Declarativas com Spring
91
3.5.5. Gerenciamento de Segurança com Spring
94
3.5.6. Exposição de Serviços Remotos com Spring
97
3.5.7. Considerações Finais Sobre o Spring
99
3.5.8. Outros Frameworks Para Dependency Injection
100
3.5.8.1. Quantidade de Documentação Disponível
100
3.5.8.2. Disponibilidade de Suporte
102
3.5.8.3. Disponibilidade de Ferramentas Compatíveis
103
3.5.8.4. Grau de Aceitação no Mercado
104
3.5.8.5. Disponibilidade de Profissionais
106
3.5.8.6. Resultado da Comparação
107
3.6. Conclusão
107
4 A Camada de Apresentação
110
4.1. Vantagens e Desafios no Desenvolvimento de Interfaces HTML
110
4.2. Model View Controller
112
4.3. Características Comuns a Web Frameworks
114
4.4. Comparação Técnica entre Web Frameworks
115
4.4.1. Struts
116
4.4.2. Spring MVC
123
4.4.3. JavaServer Faces
130
4.4.4. Resultado da Análise Técnica
136
4.5. Comparação Não-Técnica entre Web Frameworks
137
4.5.1. Quantidade de Documentação Disponível
138
4.5.2. Disponibilidade de Suporte
139
4.5.3. Disponibilidade de Ferramentas Compatíveis
140
4.5.4. Grau de Aceitação no Mercado
141
4.5.5. Disponibilidade de Profissionais
143
4.5.6. Resultado da Análise
144
4.6. Conclusão
145
5 Arquitetura do AulaNet 3.0
149
5.1. Elementos Principais da Arquitetura do AulaNet 3.0
149
5.2. A Arquitetura do AulaNet 3.0 e os Frameworks de Infra-Estrutura 152
5.3. Arquitetura Técnica e Mobilidade
155
5.4. Arquitetura Técnica e Outros Frameworks: Jade
161
5.4.1. Agentes de Software
161
5.4.2. Aplicações de Sistemas Multi-Agentes
162
5.4.3. O Framework de Agentes Jade
163
5.4.4. Jade e a Arquitetura do AulaNet 3.0
167
5.4.5. Prova de Conceito com Agente Móvel
170
5.4.2.1. MAS 1: O Que Há de Novo na Conferência?
171
5.4.2.2. MAS 2: Alerta de Condições Indesejáveis
180
5.5. Conclusão
183
6 Conclusão
188
7 Referências Bibliográficas
194
Apêndice A Comunicações Pessoais
202
A.1. Comunicação com Christian Bauer
202
A.2. Comunicação com Rod Johnson
203
A.3. Comunicação com Matt Raible
205
Apêndice B Método Utilizado na Análise Não-Técnica
207
B.1. Quantidade de Documentação Disponível
207
B.2. Disponibilidade de Suporte
208
B.3. Disponibilidade de Ferramentas Compatíveis
209
B.4. Grau de Aceitação no Mercado
210
B.5. Disponiblidade de Profissionais
210
Lista de figuras
Figura 1.1 – O Modelo 3C (Pimentel et al., 2005)
17
Figura 1.2 – Classificação dos Serviços do AulaNet segundo o Modelo 3C
20
Figura 1.3 – AulaNet no Desktop.
21
Figura 1.4– AulaNetM em um PDA.
21
Figura 1.5 – Arquitetura do AulaNet 2.0 (Barreto et al., 2005).
22
Figura 1.6 – Arquitetura Técnica do AulaNet 3.0.
25
Figura 1.7. A arquitetura de aplicação proposta
28
Figura 1.8. Foco para o desenvolvimento de uma versão da aplicação groupware
com base no Modelo 3C de Colaboração
29
Figura 1.9 – Exemplo de uma Listagem de Código.
31
Figura 3.1 – Diagrama de Classes que Exemplifica a Questão do Grafo de
Navegação
56
Figura 3.2 – Diagrama UML de Classes Persistidas no Exemplo
59
Figura 3.3 – Diagrama de Classes com Herança.
69
Figura 3.4 – Livros Publicados Para Cada Framework ORM Fonte: Amazon.com,
Novembro de 2005
74
Figura 3.5 – Artigos e Tutoriais Para Cada Framework ORM Fonte: Google.com,
Novembro de 2005
Figura 3.6 - Mensagens Trocadas em Listas de Discussão (11/2005)
74
75
Figura 3.7 – Ferramentas Compatíveis com os Frameworks ORM em 11/2005 76
Figura 3.8 – Ofertas de Emprego Abertas para cada Framework ORM Fonte:
Dice.com, Dezembro de 2005
77
Figura 3.9 – Ofertas de Emprego Abertas para cada Framework ORM Fonte:
Manager Online, Dezembro de 2005
78
Figura 3.10 – Disponibilidade de Profissionais Fonte: Jobs.net, Dezembro de 2005
79
Figura 3.11 - Disponibilidade de Profissionais Fonte: APInfo.com, Dezembro de
2005
79
Figura 3.12 – Dependências Configuradas sem Dependency Injection
82
Figura 3.13 - Dependências Configuradas com Dependency Injection
82
Figura 3.14 – Modelo de Classes do Exemplo do Spring
84
Figura 3.15 - Livros Publicados Para Cada Framework de Dependency Injection
Fonte: Amazon.com, Dezembro de 2005
101
Figura 3.16 - Artigos e Tutoriais Para Cada Framework de Dependency Injection
Fonte: Google.com, Dezembro de 2005
101
103
Figura 3.18 – Ferramentas Compatíveis com os Frameworks para Dependency
Injecton em 12/2005
104
Figura 3.19 – Ofertas de Emprego Abertas para cada Framework para
Dependency Injection. Fonte: Dice.com, Dezembro de 2005
105
Figura 3.20 - Vagas Abertas para cada Framework de Dependency Injection
Fonte: Manager Online, Dezembro de 2005.
Figura 3.21 - Disponibilidade de Profissionais em 12/2005 Fonte: Jobs.net.
105
106
Figura 3.22 - Disponibilidade de Profissionais Fonte: APInfo.com, Dezembro de
2005.
107
Figura 4.1 – MVC clássico (Ramachandran, 2002)
113
Figura 4.2 – MVC pull (Johnson, 2002, 2004)
114
Figura 4.3 - Calendário
135
Figura 4.4 - Editor HTML
135
Figura 4.5 - Número de Livros Publicados
138
Figura 4.6 - Número de Tutoriais escritos
139
Figura 4.7 – Mensagens Trocadas em Listas de Discussão (Julho/2005)
140
Figura 4.8 – Ferramentas Compatíveis
141
Figura 4.9 - Oferta de Empregos nos Meses 10/2004, 7/2005 e 11/2005 Fonte:
Dice.com, 10/2004, 07/2005 (Raible, 2005) e 11/2005
Figura 4.10 – Ofertas de Emprego Fonte: Manager Online, Outubro de 2005
142
142
Figura 4.11 - Disponibilidade de Profissionais com Habilidades nos Frameworks
Fonte: Monster.com, Junho de 2005 (Raible, 2005)
143
Fonte: APInfo.com, Novembro de 2005
144
Figura 5.1 - Arquitetura de Aplicação do AulaNet 3.0 (Gerosa, 2006)
Apresentada na Seção 1.3.
Figura 5.2 – Arquitetura Técnica do AulaNet 3.0 Apresentada na Seção 1.3.
150
151
153
Figura 5.4 - Arquitetura Técnica do AulaNet 3.0 com Frameworks.
154
Figura 5.5 – Arquitetura Técnica da Integração AulaNet 3.0 com AulaNetM por
Reposição da Camada de Apresentação
157
Figura 5.6 - Arquitetura Técnica da Integração AulaNet 3.0 com AulaNetM por
Exposição de Serviços Remotos
159
Figura 5.7 – Plataformas de Agentes Jade (Caire, 2003).
165
Figura 5.8 – Diagrama de Classes do Adaptador Jade-Leap para o Spring
168
Figura 5.9 – Plataforma de Execução do MAS 1
172
Figura 5.10 – PDA Após a Inicialização do Jade-Leap
179
Figura 5.11 – PDA Após a Primeira Consulta
179
Figura 5.12 - PDA Após a Segunda Consulta
180
Figura 5.13 – Informações Visuais no AulaNetM
182
Figura 5.14 – Informações Estatísticas no AulaNetM
182
Figura 5.15 – Informações Visuais no AulaNetM
183
Figura 5.16 – Informações Estatísticas no AulaNetM
183
Figura 5.17 – Arquitetura Técnica do AulaNet 3.0 com Frameworks
185
Listagens de Código
Listagem 3.1 – Classe Message
59
Listagem 3.2 – Classe User
60
Listagem 3.3 – Arquivo hibernate.cfg.xml de Configuração do Hibernate
61
Listagem 3.4 – Arquivo User.hbm.xml de Mapeamento Objeto – Relacional
62
Listagem 3.5 - Arquivo Message.hbm.xml de Mapeamento Objeto – Relacional 63
Listagem 3.6 – Operação de Criação com o Hibernate
64
Listagem 3.7 – Operação de Atualização com o Hibernate
66
Listagem 3.8 – Operação de Consulta com o Hibernate Usando HQL
67
Listagem 3.9 – Operação de Remoção com o Hibernate
68
Listagem 3.10 – Classe Message.
85
Listagem 3.11 – Interface MessageDAO.
85
Listagem 3.12 – Classe ConferenceFacade.
86
Listagem 3.13 – Arquivo de Configuração do Spring
87
Listagem 3.14 – Descritor web.xml da Aplicação: Iniciando o Contexto Spring 88
Listagem 3.15 – Arquivo de Configuração do Spring: Integração com Hibernate.
89
Listagem 3.16 – Classe MessageDAOImpl.
90
Listagem 3.17 - Arquivo de Configuração do Spring: Transações Declarativas. 93
Listagem 3.18 - Arquivo de Configuração do Spring: Segurança Declarativa.
96
Listagem 3.19 - Arquivo de Configuração do Spring: Exposição de Serviços
Remotos.
99
Listagem 4.1 – Declaração do Controlador do Struts na Instancia (web.xml)
117
Listagem 4.2 – Descritor struts-config.xml
118
Listagem 4.3 – Ação postMessage
119
Listagem 4.4 – Action Form da ação postMessage
120
Listagem 4.5 – Regras de Validação (validation.xml)
121
Listagem 4.6 – Página de Envio de Mensagens
122
Listagem 4.7 - Declaração do Controlador do Spring MVC na Instancia (web.xml)
124
Listagem 4.8 - Descritor SpringDispatcher-servlet.xml
125
Listagem 4.9 – Controlador Associado à Requisição postMessage
126
Listagem 4.10 – Bean de Formulário Associado ao Controlador postMessage 127
Listagem 4.11 – Classe de Validação para o Controlador postMessage
128
Listagem 4.12 - Página de Envio de Mensagem
129
Listagem 4.13 - Declaração do Controlador do JSF na Instancia (web.xml)
131
Listagem 4.14 – Arquivo de Configuração faces-config.xml
132
Listagem 4.15 – Backing Bean do Comando postMessage
133
Listagem 4.16 – Página de Envio De Mensagens (JSF)
134
Listagem 5.1 – Agente Conferência
173
Listagem 5.2 – Comportamento WhatIsNewInConferenceBehaviour
174
Listagem 5.3 – Configuração no Spring do Adaptador Jade-Leap
175
Listagem 5.4 – Agente Móvel
176
Listagem 5.5 – Comportamento ConferenceQueryBehaviour
177
1
Introdução
Ao desenvolver groupware, o desenvolvedor depara-se com inúmeros
desafios. Além de entender de seu domínio de aplicação, ou seja, colaboração,
este deve lidar com aspectos de infra-estrutura de baixo nível, como o
gerenciamento de transações, a persistência dos dados da aplicação e a validação
dos dados de entrada do usuário. O desenvolvimento de groupware já é difícil por
si só devido a seu caráter multidisciplinar e a heterogeneidade dos diversos grupos
de trabalho (Gerosa et al., 2004) e não deve ser complicado por questões de baixo
nível. A introdução frameworks de infra-estrutura como o Hibernate (2005), o
Spring (2005) e o JSF (2005) possibilita que o desenvolvedor de groupware
concentre-se em seu domínio e lide com estas questões a partir de uma perspectiva
mais alto nível.
O AulaNet (Lucena & Fuks, 2000) é um groupware (Fuks et al., 2005)
usado no ensino/aprendizagem colaborativo. Este é desenvolvido no Laboratório
de Engenharia de Software (LES) da Pontifícia Universidade Católica do Rio de
Janeiro (PUC-Rio). O objetivo da pesquisa que resultou nesta dissertação de
mestrado é elaborar uma arquitetura técnica para groupware que ofereça uma base
de serviços independentes de domínio, tomando como estudo de caso o ambiente
AulaNet.
Esta introdução apresenta conceitos fundamentais sobre groupware.
Também são apresentadas as arquiteturas do AulaNet 2.1 e 3.0. Por fim, são
descritas as teses consorciadas a este trabalho e a organização do texto.
1.1.
Groupware e o Modelo 3C
Groupware é software que apóia a interação entre indivíduos que trabalham
para a realização de um objetivo comum (Rezende, 2003). Trabalhando
colaborativamente, pelo menos potencialmente, pode-se produzir melhores
resultados do que individualmente (Fuks et al., 2002).
Capitulo 1. Introdução
17
O modelo 3C é usado para analisar a colaboração. Segundo este modelo,
para colaborar, indivíduos devem se comunicar, coordenar e cooperar de forma
adequada. A Figura 1.1esquematiza o modelo 3C.
comum + ação
Ação de tornar comum
COMUNICAÇÃO
demanda
COOPERAÇÃO
co + operar + ação
Ação de operar
em conjunto
gera compromissos
gerenciados pela
Percepção
Contexto
COORDENAÇÃO
organiza as tarefas para
co + ordem + ação
Ação de organizar
em conjunto
Figura 1.1 – O Modelo 3C (Pimentel et al., 2005)
Para que os objetivos sejam atingidos, um grupo precisa se comunicar, o
que gera compromissos. Para garantir que estes sejam cumpridos e lidar com
eventuais conflitos que possam surgir, é preciso que os compromissos gerados
pela comunicação sejam coordenados. Coordenados, os integrantes do grupo
podem cooperar, operando em conjunto e realizando o trabalho colaborativo. A
cooperação demanda comunicação e o ciclo recomeça.
Para desenvolver groupware de qualidade, é necessário entender de
colaboração (Pimentel et al., 2005). Utilizando o modelo 3C pode-se mapear
características de um serviço em cada um dos “Cs” e, desta forma, melhorar a
ferramenta através da modificação de um dos “Cs”. Pode-se também identificar
deficiências de um groupware a partir da análise da colaboração baseada no
modelo 3C, acrescentando ou removendo serviços de comunicação, coordenação e
cooperação (Pimentel, 2006) de acordo com a necessidade do grupo de trabalho.
1.1.1.
Comunicação
Participantes de uma equipe de trabalho devem se comunicar para conseguir
realizar tarefas relacionadas, que necessitem de negociação ou que se encontram
parcialmente descritas (Rezende, 2003). A comunicação em groupware pode ser
efetuada de diversas formas. Alguns exemplos de ferramentas de comunicação
disponíveis no AulaNet são o Debate e a Mensagem Instantânea, ferramentas de
18
comunicação síncrona, e a Conferência e o Correio para Turma, ferramentas de
comunicação assíncrona. As ferramentas de comunicação síncrona privilegiam a
interação entre os participantes, já que o tempo entre o envio de uma mensagem e
a resposta do receptor é curto. Já as ferramentas de comunicação assíncronas
valorizam a reflexão, pois os participantes têm mais tempo para formular suas
mensagens.
Segundo o modelo 3C de colaboração, a comunicação é dita bem sucedida
quando a mensagem tem o seu significado entendido pelo receptor (Fuks et al.,
2005). A comunicação é realizada com o objetivo de gerar compromissos, porém
uma mensagem mal interpretada pode gerar conflitos.
A leitura da mensagem altera o conhecimento do receptor e gera
compromissos, que resultam em ações. Para ter indicações de que a mensagem foi
compreendida o emissor deve observar as ações e o discurso do receptor (Fuks et
al., 2005). Uma vez gerados os compromissos, é necessário coordenar o grupo
para garantir o cumprimento dos compromissos.
1.1.2.
Coordenação
Para que um grupo cumpra uma tarefa de forma eficiente, para que o
trabalho em grupo produza um resultado melhor que a soma dos trabalhos
individuais, os membros do grupo precisam ser coordenados (Fussell et al., 1998).
A coordenação organiza o grupo para evitar que esforços de comunicação e
cooperação sejam perdidos e que as tarefas sejam realizadas na ordem correta, no
tempo correto e cumprindo as restrições e objetivos (Raposo et al., 2001). Alguns
exemplos de ferramentas de coordenação disponíveis no AulaNet são o serviço de
Avisos e o Acompanhamento de Participação.
A coordenação de tarefas envolve a pré-articulação, o gerenciamento das
atividades e a pós-articulação. Durante a pré-articulação são realizadas todas as
ações necessárias de preparação para a colaboração. Dentre estas tarefas incluemse a definição dos objetivos, o mapeamento dos objetivos em tarefas, a seleção
dos participantes e a distribuição das tarefas entre os participantes. Normalmente a
fase da pré-articulação termina antes do início da cooperação. O gerenciamento
das atividades consiste no controle das interdependências das tarefas executadas
19
para alcançar o objetivo. A pós-articulação ocorre após a conclusão das tarefas e
envolve uma análise dos resultados e a documentação do processo colaborativo
(Fuks et al., 2005).
Trabalhar colaborativamente demanda esforço para a coordenação dos
membros de um grupo. Sem coordenação, parte dos esforços de comunicação não
são aproveitados na cooperação. Para que o grupo possa operar em conjunto
(cooperar) de forma satisfatória é necessário que os compromissos assumidos na
comunicação entre os participantes sejam coordenados (Rezende, 2003).
1.1.3.
Cooperação
Cooperação é o ato de operar em conjunto. Membros de um grupo
cooperam, manipulando e organizando informação, construindo e refinando
objetos de cooperação como documentos de texto, planinhas, gráficos entre
outros. Mecanismos de cooperação provêem meios para gerenciar estes artefatos
no espaço compartilhado, através do gerenciamento de versões, controle de
acesso, busca, etc (Fuks et al., 2005). Alguns exemplos de ferramentas de
cooperação disponíveis no AulaNet são o serviço de Aulas e o serviço de CoAutoria.
O registro da informação na forma de objetos de cooperação visam
aumentar o entendimento entre pessoas reduzindo a incerteza, relacionada à
ausência de informação, e à equivocalidade, relacionada à ambigüidade e a
existência de informações conflitantes (Fuks et al., 2002).
Ao salvar as informações trocadas, o grupo pode armazenar a história de
uma discussão que resultou em uma decisão. Contando com a memória coletiva,
em um tempo futuro esta história pode ser consultada, retomando os motivos que
levaram decisão.
1.2.
O AulaNet
Dá-se o nome de learningware a um groupware que dá suporte a
aprendizagem colaborativa (Santoro et al., 1999). O AulaNet é um learningware
baseado na web desenvolvido pelo Laboratório de Engenharia de Software (LES)
20
da Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) desde junho de
1997. Participam de seu desenvolvimento alunos de graduação, mestrado e
doutorado que também o usam para aplicar suas pesquisas e escrever artigos,
monografias, dissertações e teses.
Atualmente o AulaNet está disponível em português, inglês e espanhol. Seu
código fonte é fechado, mas sua distribuição é feita gratuitamente pela empresa
EduWeb (2005). Esta empresa também realiza customizações no AulaNet para
uso nos seus diversos clientes.
Os serviços do AulaNet são categorizados segundo sua classificação de
acordo com o modelo 3C em serviços de comunicação, coordenação e
cooperação.
COMUNICAÇÃO
Síncrona
Assíncrona
Mensagem
C orreio para
Instantânea
Participante
Bate-papo
C orreio p/ Turma
Debate
C onferência
Aulas
Informações
Documentação
Avisos
Bibliografia
Tarefas
Webliografia
Exame
Download
Pesq. Opinião
C o-autoria
Acompanham.
da Participação
Acompanham.
da Navegação
C ertificado
COOPERAÇÃO
COORDENAÇÃO
Figura 1.2 – Classificação dos Serviços do AulaNet segundo o Modelo 3C
(Pimentel et al., 2005)
Os serviços de comunicação oferecem ferramentas com as quais os
aprendizes dos cursos do AulaNet podem se comunicar de forma síncrona ou
assíncrona. Os serviços de coordenação provêem serviços usados na gerência e
controle das atividades de grupo. Os serviços de cooperação incluem serviços que
21
oferecem suporte ao conteúdo bibliográfico dos cursos, co-autoria entre
aprendizes e outros.
Recentemente iniciou-se o desenvolvimento do AulaNetM, uma extensão
dos serviços do AulaNet para dispositivos móveis. Esta iniciativa tem como
objetivo explorar o uso do m-learning no AulaNet (Filippo et al., 2005a, b). A
Figura 1.3 mostra a tela principal do AulaNet 3.0 e a Figura 1.4 a lista de
mensagens da conferência do AulaNetM.
Figura 1.3 – AulaNet no Desktop.
Figura 1.4– AulaNetM em um PDA.
Ao longo dos 8 anos que o AulaNet vem sendo desenvolvido, foram escritos
4 livros ou capítulos de livros, 15 artigos em revistas, 57 artigos em conferências e
workshops, 2 teses de doutorado, 9 dissertações de mestrado e 5 monografias de
fim de curso relacionadas de alguma forma ao AulaNet. Além disso, o AulaNet
está presente em várias universidades no Brasil, como a PUC-Rio, a Federal do
Rio de Janeiro, a Federal da Bahia entre outras, e em várias universidades do resto
do mundo, dentre elas Universidade Tecnológica do Panamá e Universidade da
Madeira (Portugal). O AulaNet também é usado em empresas, entre elas a Rede
Globo, NEXTEL e SENAC.
Os mesmos desenvolvedores do AulaNet mantêm os cursos Engenharia de
Groupware, onde ele é usado como repositório de informações e o curso
Tecnologias de Informação Aplicada A Educação (TIAE), onde ele é usado
integralmente em um curso totalmente à distância. Estes cursos são ministrados
semestralmente e estão disponíveis para alunos da graduação e pós-graduação da
PUC-Rio. A experiência com estes cursos fornece subsídios usados na melhoria
constante do AulaNet.
O AulaNet é um learningware desenvolvido pelo LES desde 1997 e é usado
em diversas empresas e universidades. O AulaNet também é usado para testar
22
hipóteses de pesquisas em diversos trabalhos de alunos da graduação, mestrado e
doutorado da PUC-Rio. Atualmente, a versão distribuída do AulaNet é a 2.1. Sua
arquitetura é descrita na seção a seguir.
1.2.1.
A Arquitetura do AulaNet 2.1
O AulaNet é desenvolvido desde junho de 1997. Inicialmente seu código era
escrito em LUA (Ierusalimschy et al., 1996). O código evoluiu rapidamente e
então decidiu-se utilizar a linguagem de programação Java, de modo a melhorar a
integração com o mercado de desenvolvedores e aproveitar a robustez,
portabilidade e recursos desta plataforma. O AulaNet foi então totalmente
reformulado e sua versão 2.0 escrita em Java foi lançada.
Desde então, a sua arquitetura não sofreu alterações significativas.
Atualmente, a versão de produção do AulaNet é a 2.1 que possui a mesma
arquitetura da 2.0. Esta é baseada no paradigma cliente-servidor e é fortemente
dependente da tecnologia Scriba (Fuks et al., 2003). A Figura 1.5 exibe o esquema
da arquitetura do AulaNet 2.1.
Conteúdo
Web
Java
Servlets
Scriba
P á gina s
HTML
Se rvle ts e
C la sse s Ja va
Aplicações
Se rvido r de
De ba te
Se rvido r de
P re se nça
BD
Figura 1.5 – Arquitetura do AulaNet 2.0 (Barreto et al., 2005).
A tecnologia Scriba é constituída por uma linguagem de script que é
embutida em arquivos HTML e um Servlet que interpreta os arquivos HTML. O
Scriba possibilita, dentre outras coisas, chamadas a classes Java, acesso a banco
de dados e definições de variáveis.
A maior parte das páginas HTML/Scriba está relacionada a classes Java, que
acessam o banco de dados, realizam algum processamento e constroem a
representação gráfica do resultado. O código que representa a lógica da aplicação
23
não é separado do código que representa a interface com o usuário e encontra-se
espalhado tanto nas páginas HTML/Scriba quanto nas classes Java.
Os principais problemas desta arquitetura são a baixa modularidade, o uso
de um paradigma procedural, a não aderência a tecnologias e boas práticas atuais
e a não separação da lógica da aplicação da interface com o usuário.
O código do AulaNet 2.1 vem sendo desenvolvido ao longo destes anos
através de prototipação. Isto, aliado a rotativade dos desenvolvedores do projeto,
com o passar do tempo resultou em um código pouco modular e não padronizado.
Como conseqüência, o código do AulaNet hoje apresenta um baixo grau de reuso.
Apesar de usar a linguagem Java, que é orientada a objetos, o código
presente no AulaNet 2.1 assemelha-se à abordagem funcional, sem que seja
utilizado uma modelagem de classes. Desta forma, muitas das vantagens inerentes
ao paradigma OO não são aplicáveis ao AulaNet 2.1.
Muitas das tecnologias e das boas práticas presentes hoje não estavam
presentes quando o AulaNet 2.1 foi desenvolvido. Um exemplo disto é a
tecnologia JSP, que surge em meados de 1999 e oferece recursos semelhantes à
tecnologia Scriba. O uso de tecnologias proprietárias como o Scriba dificulta a
integração com outras equipes de desenvolvimento, como a EduWeb, que precisa
treinar cada novo funcionário nesta tecnologia.
Por fim, a falta de uma separação clara entre a lógica da aplicação e a
interface com o usuário dificulta o reuso, pois a lógica de negócios não pode ser
reutilizada separadamente.
A soma destes problemas resultou em um AulaNet cuja atividade de
manutenção é muito cara e cuja entrada de novos desenvolvedores ou integração
com outros grupos de desenvolvedores é difícil. Para solucionar estes problemas,
o consórcio de teses Groupware@LES propôs uma nova arquitetura para o
AulaNet.
1.3.
Consórcio de Pesquisa
Para investigar o desenvolvimento de groupware e sua aplicação no
desenvolvimento do AulaNet 3.0, nosso grupo de pesquisa Groupware@LES
consorciou três trabalhos: esta dissertação de mestrado propõe a integração de
24
frameworks na constituição da arquitetura técnica do AulaNet; Gerosa (2006), em
sua tese de doutorado, propõe a montagem de groupware a partir da agregação de
serviços e componentes baseados no Modelo 3C de Colaboração; e Pimentel
(2006), em sua tese de doutorado, propõe um processo de desenvolvimento de
groupware usando o Modelo 3C de Colaboração em diferentes etapas do processo.
Estes
trabalhos
consorciados
reduzem
a
distância
semântica
entre
a
implementação e os conceitos do domínio referentes à colaboração, o que
favorece a manutenção e a evolução do groupware. Com o objetivo de
contextualizar os três trabalhos, esta seção é replicada na introdução da
dissertação e das teses resultantes. As subseções seguintes resumem cada trabalho.
1.3.1.
Agregando Frameworks de Infra-Estrutura em uma Arquitetura
Baseada em Componentes: Um Estudo de Caso no Ambiente
AulaNet
No desenvolvimento de um groupware, o projetista se depara com desafios
em diferentes níveis: entender do domínio e lidar com questões de infra-estrutura.
O desenvolvimento de groupware é difícil devido ao seu caráter multidisciplinar e
à heterogeneidade dos diversos grupos de trabalho. O desenvolvedor deveria se
concentrar mais nos aspectos funcionais utilizando uma infra-estrutura que trate as
questões técnicas.
Nesta dissertação, foi elaborada uma arquitetura técnica multicamadas que
faz uso do padrão MVC (Fowler, 2002) e que integra frameworks de infraestrutura (Fayad & Schmidt, 1997; Fayad et al. 1999a, b; Fayad & Johnson,
2000). A abordagem multicamadas com o padrão MVC proporciona a separação
entre a lógica da aplicação e a interface com o usuário, considerada uma boa
prática de design de software (Fowler, 2002). Frameworks de infra-estrutura
proporcionam uma maneira de lidar com as questões de baixo nível como
persistências de dados, controle de transações, segurança, etc.
O diagrama esquematizado na Figura 1.6 mostra a arquitetura técnica
proposta para o AulaNet 3.0. As setas indicam o fluxo de controle da aplicação, os
retângulos representam classes, os círculos representam as interfaces, e as linhas
pontilhadas representam a divisão entre as camadas. Esta arquitetura, baseada na
25
Arquitetura de POJOs descrita por Johnson (2002, 2004), é organizada nas
seguintes camadas: apresentação, negócios e recursos.
Camada de
Apresentação
V
C
Camada de
Negócios
Façade
M
(DTO)
Mail
Sender
Data Access Object
Camada de
Recursos
Servidor de
E-Mails
SGBD
Figura 1.6 – Arquitetura Técnica do AulaNet 3.0.
A camada de recursos relaciona os recursos externos necessários para que a
aplicação seja executada. Na arquitetura do AulaNet 3.0 estão previstos o uso de
banco de dados relacional (SGBD) e um servidor de e-mails.
A camada de negócios implementa a lógica da aplicação utilizando POJOs
(POJO, 2005) (Plain Old Java Objects).
“O termo [POJO] foi cunhado enquanto eu [Martin Fowler], Rebbecca Parsons e
Josh MacKenzie estávamos nos preparando para uma conferência em Setembro de
2000. Na palestra estávamos levantando os vários benefícios de codificar a lógica
de negócios usando objetos Java comuns em vez de usar Beans de Entidade [EJB].
Questionávamos por que as pessoas eram tão contra usar objetos comuns em seus
sistemas, e concluímos que era pela falta de um nome pomposo para os objetos
simples. Então inventamos um, e o termo pegou muito bem.” (POJO, 2005)
Na camada de negócios, o modelo (representado no diagrama da Figura 1.6
pela letra M do MVC) é implementado por classes que realizam o padrão de
projetos Data Transfer Object (Fowler, 2002), usadas para transportar os dados
das entidades de negócio entre camadas. O acesso à base de dados é encapsulado
através de classes que implementam o padrão de projetos Data Access Objects
(DAO) (Alur et al., 2001), o que possibilita variar a maneira de persistir as classes
26
do modelo sem que seja preciso reescrever o código cliente. Mail Sender é a
classe para enviar e-mails que, de forma similar ao DAO, encapsula o acesso ao
servidor de e-mails. A lógica de negócios é exposta para a camada de
apresentação através de um Façade (Gamma et al., 1995), que é o padrão de
projeto para prover uma interface para acesso às funcionalidades de um serviço.
A camada de apresentação expõe a lógica de negócios ao usuário-final. Na
arquitetura do AulaNet 3.0, esta camada é composta pelo controlador
(representado no diagrama da Figura 1.6 pela letra C do MVC) e por páginas JSP
que implementam a camada de Visão (representado no diagrama da Figura 1.6
pela letra V do MVC). O controlador chama os métodos do Façade, acessando a
camada de negócios. Os DTOs resultantes de operações são passados à visão que
exibe as informações ao usuário.
Frameworks de infra-estrutura foram selecionados e acrescentados a esta
arquitetura para prover persistência de dados, gerenciamento de transações entre
outros aspectos. Estes frameworks possibilitam ao desenvolvedor tratar estes
aspectos com uma visão em alto nível, concentrando-se em seu domínio de
aplicação, no caso, colaboração.
1.3.2.
Desenvolvimento de Groupware Componentizado com base no
Modelo 3C de Colaboração
Um groupware é composto de ferramentas colaborativas como Fórum,
Agenda, Documentação, etc. Estas ferramentas, disponíveis em diversas
aplicações groupware, compartilham funcionalidades relativas ao suporte
computacional à colaboração, tais como canal de comunicação, gerenciamento de
participantes, registro de informações, etc.
Na tese de Gerosa (2006), para dar suporte ao desenvolvimento de
groupware, foram estabelecidos dois níveis de componentização. O primeiro nível
é constituído de serviços colaborativos que, por sua vez, são montados com
componentes 3C (segundo nível) que implementam funcionalidades relacionadas
à colaboração. Estes componentes são distribuídos em component kits organizados
em função do modelo 3C de colaboração para que desenvolvedores montem
aplicações colaborativas. Nesta abordagem, cada serviço usa componentes de
comunicação, coordenação e de cooperação independentemente da classificação
27
3C do serviço. Foi aplicado um método de Engenharia do Domínio para elaborar
o conjunto de componentes. Os componentes são iterativamente refinados em
função da realimentação obtida com o desenvolvimento dos serviços do AulaNet
3.0 e em função de estudos de caso variando as configurações do suporte à
colaboração.
Component frameworks (Syzperski, 1997) são usados para oferecer suporte
ao gerenciamento e à execução dos componentes. Conforme apresentado na
Figura 1.7, na tese de Gerosa (2006) foi elaborado um component framework para
cada nível de componentização (serviço e componente 3C). Os serviços são
acoplados no Service Component Framework, e os componentes 3C são
acoplados no Collaboration Component Framework. Estes component frameworks
são responsáveis por tratar a instalação, remoção, atualização, ativação,
desativação, localização, configuração e monitoramento de componentes. O
Service Component Framework gerencia as instâncias dos serviços e a ligação
com os componentes de colaboração correspondentes. O Collaboration
Component Framework gerencia as instâncias dos componentes de colaboração,
que são provenientes do Collaboration Component Kit. Algumas funcionalidades
dos component frameworks são recorrentes, sendo então elaborado um framework
para instanciar os component frameworks. Este tipo de framework é chamado de
component framework framework (CFF) (Szyperski, 1997, p.277). Um component
framework framework é visto como um component framework de segunda ordem,
onde seus componentes são component frameworks (Szyperski, 1997, p.276). Na
arquitetura da aplicação, o component framework de segunda ordem foi
denominado Groupware Component Framework Framework.
28
Groupware
Application
Groupware
Component
Framework
Framework
Service
Component
Framework
Service X
Service Y
Collaboration
Component
Framework
.
.
3C Component A
3C Component B
Infrastructure Frameworks
Database
.
Figura 1.7. A arquitetura de aplicação proposta
Os component frameworks, serviços e componentes 3C oferecem suporte
computacional aos conceitos do modelo 3C de colaboração, instrumentando o
desenvolvimento da camada de negócio. A arquitetura de aplicação proposta
estrutura os componentes do domínio, representando um projeto lógico de alto
nível independente da tecnologia de suporte (D’Souza & Wills, 1998). Já os
aspectos de infra-estrutura, tratados nesta dissertação, são independentes do
domínio de aplicação.
Os componentes da arquitetura de aplicação são implementados segundo a
arquitetura técnica. Os serviços do AulaNet são criados com um único Façade que
expõe as operações deste serviço para a camada de apresentação. Os componentes
de colaboração por sua vez, podem utilizar vários DTOs e DAOs, dependendo da
complexidade do componente. Estes componentes podem ainda usar “código
cola” (Szyperski, 1997) e adaptadores (D’Souza & Wills, 1998) para possibilitar a
integração com componentes e outros sistemas que não são compatíveis por
construção.
29
1.3.3.
RUP-3C-Groupware: um Processo de Desenvolvimento de
Groupware baseado no Modelo 3C de Colaboração
Os frameworks de infra-estrutura selecionados nesta dissertação se
encarregam de soluções para aspectos de infra-estrutura de baixo nível, visando
possibilitar o desenvolvedor se concentrar nos aspectos funcionais. Os kits de
serviços e componentes 3C elaborados por Gerosa (2006) fornecem os elementos
para compor um groupware. O processo elaborado na tese de Pimentel (2006)
estabelece os passos a serem seguidos na montagem do groupware, pois ainda que
se construa uma aplicação groupware para um grupo com uma determinada
dinâmica, com o tempo surgem novas situações onde são identificados novos
problemas. A aplicação necessitará ser modificada para não se manter inadequada.
Um processo organiza, em linhas gerais, uma seqüência de passos onde são
incorporadas diretrizes e boas práticas que, quando seguidas, levam à produção de
um software razoável (Sommerville, 2003; Beck, 2004; Philippe, 2003).
Coexistem abordagens diferentes para o desenvolvimento de software, dentre elas,
o desenvolvimento baseado em componentes, que é uma estratégia recente que
tem se tornado cada vez mais usada (Sommerville, 2003; Gimenes & Huzita,
2005). Seguindo esta abordagem, tornaram-se conhecidos processos como
Catalysis (D’Souza e Wills, 1998), UML Components (Cheesman & Daniels,
2001) e RUP – Rational Unified Process (Philippe, 2003). O processo formalizado
na tese de Pimentel (2006), denominado RUP-3C-Groupware, também faz uso da
abordagem baseada em componentes, estendendo o RUP para o desenvolvimento
específico de aplicações groupware.
Comunicação
Processo de Desenvolvimento de Groupware
Cooperação
Coordenação
Figura 1.8. Foco para o desenvolvimento de uma versão da
aplicação groupware com base no Modelo 3C de Colaboração
30
No processo proposto, o Modelo 3C de Colaboração é usado nas diferentes
etapas do processo: na análise de domínio para classificação das aplicações
groupware e de seus elementos; na construção de componentes (Gerosa, 2006); e
no foco dado para o desenvolvimento de cada versão. De acordo com essa prática,
a aplicação groupware é desenvolvida resolvendo um problema de comunicação,
de coordenação ou de cooperação, um a cada versão ao longo do ciclo de
desenvolvimento, esquematizado na Figura 1.8.
1.4.
Organização da Escrita
O texto desta dissertação está estruturado em 7 capítulos e 1 apêndice.
No capítulo 2 são apresentados conceitos importantes sobre frameworks.
Este capítulo apresenta definições, classificações e outras características de
frameworks pesquisadas na literatura.
No capítulo 3 a camada de negócios da arquitetura do AulaNet 3.0 é
detalhada. É feita uma breve descrição do modelo de componentes EJB,
levantando suas vantagens, desvantagens e a perspectiva para seu futuro. Neste
capítulo, após uma análise e comparação criteriosa, são escolhidos o framework
Hibernate (2005) e o Spring (2005) para serem acrescentados à camada de
negócios do AulaNet 3.0.
No capítulo 4 o foco é a camada de apresentação. O grande número de web
frameworks disponíveis no mercado demanda uma análise mais detalhada entre os
concorrentes desta categoria de framework. Ao término da comparação, o web
framework JavaServer Faces (JSF, 2005) é incorporado a camada de apresentação
do AulaNet 3.0.
O capítulo 5 retoma a descrição da arquitetura do AulaNet 3.0 apresentada
neste capítulo, complementando-a com os frameworks analisados tanto no
capítulo 3 quanto no capítulo 4. Também é apresentado neste capítulo como a
arquitetura do AulaNet 3.0 provê suporte a dispositivos móveis e que novos
frameworks podem ser incorporados a arquitetura, tomando como estudo de caso
o framework de agentes Jade (2005). Este capítulo mostra ainda os benefícios que
o paradigma de agentes de software pode trazer ao AulaNet.
31
O capítulo 6 apresenta as conclusões finais e as contribuições desta pesquisa
enquanto que o capítulo 7 apresenta as referencias bibliográficas. O apêndice A é
adicionado com a transcrição dos e-mails trocados com outros pesquisadores, que
gentilmente cederam dados tornando esta pesquisa mais precisa. O apêndice B
fornece detalhes sobre o método utilizado para comparação de frameworks
utilizando critérios não-técnicos.
Ao longo desta dissertação são apresentadas várias listagens de código. Para
destacar as listagens do texto da dissertação são usadas caixas especiais. A Figura
1.9 mostra um exemplo destas caixas.
30: public class HelloReaders {
31:
32:
33:
public static void main(String args[]) {
System.out.println("Olá, leitores!") ;
}
14: }
Figura 1.9 – Exemplo de uma Listagem de Código.
O início de cada linha é precedido de uma numeração, para facilitar a
referência no texto. Linhas em branco não são numeradas. Dentro de uma seção a
numeração sempre começa do fim da numeração da listagem anterior. Por
exemplo, a listagem acima começa na linha 30, então se supõem que haveria uma
listagem anterior cuja última linha seria 29. Numerando as linhas desta forma o
texto torna-se mais claro, pois citações de linhas não se confundem quando há
mais de uma listagem muito próxima. As listagens de código seguem as
convenções de código definidas no Sun Java Code Conventions (SJCC, 2006)
sempre que possível, mas eventualmente podem fugir do padrão para tornar a
listagem mais clara. Alguns detalhes, como declarações e importações de pacotes
são omitidos pelo bem da clareza.
Toda a pesquisa que resultou nesta dissertação foi baseada em pesquisas
teóricas e aplicações práticas. Um protótipo do serviço da Conferência do
AulaNet foi implementado utilizando os principais frameworks apresentados nesta
dissertação. As listagens de código presentes nesta dissertação são baseadas em
código extraído destes protótipos, simplificadas para fins didáticos.
32
Nesta dissertação, os frameworks também são analisados sob um ponto de
vista não-técnico. São comparados os seguintes critérios: disponibilidade de
documentação, de suporte e de ferramentas compatíveis, grau de aceitação no
mercado e disponibilidade de profissionais aptos a trabalhar com cada framework.
Apesar de ser muito difícil obter resultados absolutos para estes critérios,
Raible (2005) apresenta um método para colher indícios. A quantidade de
documentação pode ser checada através de uma busca por livros sobre o
framework na página da livraria Amazon e por artigos disponíveis na web sobre o
framework através da ferramenta de busca Google. A disponibilidade de suporte é
verificada contabilizando o volume de mensagens trocadas nas listas de
discussões oficiais de cada framework. Dessa forma, obtém-se um indício do grau
de atividade da comunidade que oferece suporte ao framework. A compatibilidade
com ferramentas é verificada analisando um conjunto de ferramentas, verificando
a documentação destas uma a uma e checando se são compatíveis com o
framework. O grau de aceitação no mercado é verificado através de buscas em
sites de empregos, procurando por vagas que solicitem habilidades em cada
framework. Por fim, a disponibilidade de profissionais é verificada através de
buscas realizadas em sites que hospedam currículos. São contabilizados os
currículos de profissionais que se declaram aptos a trabalhar com cada framework.
2
Frameworks: Conceitos Gerais
Um dos principais objetivos da Engenharia de Software é o reuso. Através
da reutilização de software obtém-se o aumento da qualidade e redução do esforço
de desenvolvimento (Gimenes & Huzita, 2005). A orientação a objetos fornece
funcionalidades para que classes possam ser reutilizadas, bem como métodos por
meio de seus mecanismos de herança e polimorfismo (Lundberg & Mattsson
1996). Componentes de software definem unidades reutilizáveis que oferecem
serviços através de interfaces bem definidas (Gimenes & Huzita, 2005). Padrões
de Projeto (Design Patterns) (Gamma et al., 1995) é outra abordagem mais
abstrata que objetiva a reutilização de projetos de soluções para problemas
recorrentes.
Além destas formas de reutilização, a tecnologia de frameworks possibilita
que uma família de produtos seja gerada a partir de uma única estrutura que
captura os conceitos mais gerais da família de aplicações (Pinto, 2000).
Este capítulo apresenta os principais conceitos sobre frameworks
encontrados na literatura. Primeiramente, são revistas algumas definições sobre
frameworks. Logo após, os frameworks são classificados em duas categorias:
frameworks de aplicação orientado a objetos e frameworks de componentes. São
apresentados os papéis envolvidos no desenvolvimento e uso de frameworks e os
benefícios e desafios decorrentes da adoção de frameworks.
O capítulo é
encerrado com uma comparação entre frameworks e outras abordagens que visam
o reuso.
2.1.
Definições de Frameworks
A literatura é repleta de definições de frameworks. As principais são
descritas a seguir.
Capitulo 2. Frameworks: Conceitos Gerais
34
Para Fayad et al (1999b) e Johnson & Foote (1988), um framework é um
conjunto de classes que constitui um projeto abstrato para a solução de uma
família de problemas.
Segundo Mattsson (1996, 2000), um framework é uma arquitetura
desenvolvida com o objetivo de atingir a máxima reutilização, representada como
um conjunto de classes abstratas e concretas, com grande potencial de
especialização.
Para Johnson (1991) e Gamma et al (1995), um framework é um conjunto
de objetos que colaboram com o objetivo de atender a um conjunto de
responsabilidades para uma aplicação específica ou um domínio de aplicação.
Já segundo Buschmann et al. (1996), Pree (1995) e Pinto (2000) um
framework é definido como um software parcialmente completo projetado para
ser instanciado. O framework define uma arquitetura para uma família de
subsistemas e oferece os construtores básicos para criá-los. Também são
explicitados os lugares ou pontos de extensão (hot-spots) nos quais adaptações do
código para um funcionamento específico de certos módulos devem ser feitas.
Apesar de diferentes, as definições encontradas na literatura não são
contraditórias. A definição adotada nesta dissertação é a de Buschmann et al.
(1996), Pree (1995) e Pinto (2000).
2.2.
Classificação dos Frameworks
Frameworks podem ser classificados de diversas formas. Inicialmente, são
classificados em dois grupos principais: frameworks de aplicação orientado a
objetos (Fayad et al., 1999a, b; Fayad & Johnson, 2000) e framework de
componentes (Szyperski, 1997).
2.2.1.
Frameworks de Aplicações Orientado a Objetos
Frameworks de aplicação orientado a objetos, também chamados de
frameworks de aplicação, geram famílias de aplicações orientadas a objetos. Seus
pontos de extensão são definidos como classes abstratas ou interfaces, que são
estendidas ou implementadas por cada instância da família de aplicações. Segundo
35
Fayad et al (1999b), frameworks de aplicação são classificados quanto ao seu
escopo em frameworks de infra-estrutura de sistemas, frameworks de integração
de middleware e frameworks de aplicações corporativas.
Frameworks de infra-estrutura de sistemas simplificam o desenvolvimento
de sistemas de infra-estrutura portáveis e eficientes, como sistemas operacionais,
frameworks de comunicação, de interfaces gráficas e ferramentas de
processamento de linguagens.
Frameworks de integração de middleware são usados para integrar
aplicações e componentes distribuídos. Estes frameworks escondem o baixo nível
da comunicação entre componentes distribuídos, possibilitando que os
desenvolvedores trabalhem em um ambiente distribuído de forma semelhante a
que trabalham em um ambiente não distribuído. São exemplos de frameworks de
integração de middleware Java RMI (RMI-IIOP, 2005) e frameworks ORB
(Object Request Broker).
Frameworks de aplicações corporativas, ao contrário dos frameworks de
infra-estrutura e de integração de middleware, são voltados para um domínio de
aplicação
específico,
como
por
exemplo,
os
domínios
da
aviação,
telecomunicações e financeiro. Frameworks de aplicações corporativas são mais
caros de serem desenvolvidos ou comprados quando comparados com os de
integração de middleware e de infra-estrutura, pois são necessários especialistas
do domínio de aplicação para construí-lo. Entretanto, eles podem prover um
retorno substancial já que eles encapsulam o conhecimento sobre o domínio onde
a instituição atua (Fayad et al., 1999b).
Frameworks de infra-estrutura e de integração de middleware fornecerem
mecanismos para integrar componentes distribuídos e tratar aspectos de infraestrutura, o desenvolvedor da aplicação abstrai os detalhes em baixo nível e
concentra-se no objetivo principal da aplicação. Estes frameworks tratam aspectos
comuns a diversos domínios de aplicação de forma que quase sempre são
encontradas soluções disponíveis no mercado e na maior parte das vezes é mais
vantajoso buscar uma solução existente do que desenvolvê-la internamente.
Além da classificação por escopo, segundo Fayad et al (1999b) frameworks
podem ainda ser classificados quanto à forma usada para estendê-los. Frameworks
caixa branca, ou white box, são instanciados usando herança, através da
implementação de Template Methods (Gamma et al., 1995), métodos abstratos
36
que são implementados na subclasse, ou da redefinição de métodos ganchos (hook
methods) (Pree, 1995), métodos com uma implementação padrão que pode ser
redefinida na subclasse. Frameworks caixa preta, ou black box, são instanciados
através de configurações e composições, através da definição de classes que
implementam uma determinada interface ou contrato. Os pontos de extensão dos
frameworks caixa preta freqüentemente são definidos seguindo o padrão de
projetos Strategy (Gamma et al., 1995).
Frameworks caixa branca exigem que o desenvolvedor responsável pela
instanciação do framework possua um bom conhecimento sobre sua estrutura
interna e normalmente são mais difíceis de usar. Por outro lado, frameworks caixa
preta não exigem tanto conhecimento sobre a estrutura interna do framework, mas
são menos flexíveis. Frameworks caixa cinza, ou gray box, possuem as
características conjuntas dos frameworks caixa branca e preta, de forma a tentar
evitar as desvantagens dos dois.
2.2.2.
Frameworks de Componentes
Segundo Szyperski (1997), um framework de componentes é uma entidade
de software que provê suporte a componentes que seguem um determinando
modelo e possibilita que instâncias destes componentes sejam plugadas no
framework de componentes. Ele estabelece as condições necessárias para um
componente ser executado e regula a interação entre as instâncias destes
componentes. Um framework de componente pode ser único na aplicação, criando
uma ilha de componentes ao seu redor, ou pode cooperar com outros componentes
ou frameworks de componentes. Alguns exemplos de frameworks de
componentes são o OpenDoc (2005) e o BlackBox (Oberon, 2005).
A principal diferença entre frameworks de aplicação orientado a objetos e
framework de componentes é que, enquanto frameworks de aplicações definem
uma solução inacabada que gera uma família de aplicações, um framework de
componentes estabelece um contrato para plugar componentes. Usando uma
analogia, um framework de aplicação equivale ao quadro de uma bicicleta. Há
lugares específicos (os pontos de extensão) onde o guidão, as rodas, o banco e os
pedais (implementações dos pontos de extensão) podem ser encaixados. Bicicletas
37
diferentes (instâncias do framework) podem ser compostas variando estes itens:
bicicletas com marchas, com amortecedores, etc., mas apenas os pontos previstos
podem variar e o produto final será sempre uma bicicleta. Por outro lado,
frameworks de componentes podem ser vistos como uma placa de circuito
integrado com slots onde os chips (componentes) podem ser encaixados para criar
uma instância. Como os frameworks de componentes, as placas são utilizadas para
compor soluções para diversos domínios como por exemplo, uma placa de vídeo
ou um modem.
2.3.
Papéis Envolvidos no Uso e Desenvolvimento de um Framework
Há vários profissionais envolvidos na criação, manutenção e uso
(instanciação) de um framework. Estes papéis, que não precisam necessariamente
ser exercidos por pessoas diferentes, são segundo Froehlich et al. (1997a),
Froehlich et al (1997b) e Pinto (2000): projetista do framework, mantenedor do
framework e o desenvolvedor de aplicações (usuário do framework).
O projetista do framework é responsável pelo desenvolvimento da estrutura
básica do framework. O projetista determina os pontos de extensão do
frameworks (hot spots) e realiza o levantamento de requisitos.
O mantenedor do framework é responsável por redefinir e acrescentar novas
funcionalidades ao projeto do framework, possibilitando que novas características
sejam incorporadas ao framework no momento da instanciação pelos
desenvolvedores de aplicação.
O desenvolvedor de aplicações usa o framework. Ele satisfaz os pontos de
extensão para gerar a aplicação, instância do framework.
2.4.
Conseqüências da Adoção de Frameworks
A utilização de frameworks no desenvolvimento de aplicações traz
benefícios, originados de suas características principais: são modulares, reusáveis,
extensíveis e eventualmente assumem o controle da execução invocando métodos
da aplicação quando necessário (inversão de controle). Por outro lado, há certos
38
desafios na criação e uso de frameworks que não podem ser ignorados. Esta seção
lista as principais vantagens e desafios decorrente da adoção de frameworks.
2.4.1.
Benefícios Decorrentes da Utilização de Frameworks
Os principais benefícios decorrentes da utilização de frameworks, segundo
Fayad et al. (1999b) e Pinto (2000) advêm da modularidade, reusabilidade,
extensibilidade e inversão de controle que os frameworks proporcionam.
Frameworks encapsulam detalhes de implementação voláteis através de seus
pontos de extensão, interfaces estáveis e bem definidas, aumentando a
modularidade da aplicação. Os locais de mudanças de projeto e implementação da
aplicação construída usando o framework são localizados, diminuindo o esforço
para entender e manter a aplicação.
Além disso, frameworks incentivam o reuso, pois capturam o conhecimento
de desenvolvedores em determinado domínio ou aspecto de infra-estrutura ou de
integração de middleware. As interfaces do framework promovem pontos de
extensão que as aplicações estendem gerando instâncias que compartilham as
funcionalidades definidas no framework. Desta forma, aumentam a produtividade
dos desenvolvedores, pois o processo não começa do zero, a qualidade e a
confiabilidade do produto final, pois idealmente as funcionalidades do framework
já foram testadas em várias instâncias, e a interoperabilidade de software, pois as
instâncias de uma mesma família compartilham características em comum.
Frameworks oferecem pontos de extensão explícitos que possibilitam aos
desenvolvedores estenderem suas funcionalidades para gerar uma aplicação. Os
pontos de extensão desacoplam as interfaces estáveis do framework e o
comportamento de um determinado domínio de aplicação das variações requeridas
por uma determinada aplicação em um dado contexto.
Por fim, alguns frameworks apresentam inversão de controle (Inversion of
Controll – IoC). Inversão de controle, também é conhecida como princípio de
Hollywood : “Don’t call us, we will call you” (Larman, 2004). Trata-se de
transferir o controle da execução da aplicação para o framework, que chama a
aplicação em determinados momentos como na ocorrência de um evento. Através
da IoC o framework controla quais métodos da aplicação e em que contexto eles
39
serão chamados em decorrência de eventos, como eventos de janela, um pacote
enviado para determinada porta, entre outros.
2.4.2.
Desafios Decorrentes da Utilização de Frameworks
Quando usado em conjunto com padrões de projetos, bibliotecas de classes,
componentes, entre outros, frameworks de aplicação têm o potencial para
aumentar a qualidade de software e reduzir o esforço de desenvolvimento.
Contudo, instituições que tentam construir ou usar frameworks freqüentemente
falham a menos que resolvam os seguintes desafios: esforço de desenvolvimento,
curva de aprendizagem, integração, eficiência, manutenção, validação e remoção
de defeitos e falta de padrões (Fayad et al., 1999b).
Destes desafios, o esforço de desenvolvimento afeta principalmente os
projetistas de frameworks. A curva de aprendizagem, a integração e a eficiência
afetam principalmente os desenvolvedores de aplicação. A manutenção e
validação e remoção de defeitos afetam tanto desenvolvedores de aplicação
quanto mantenedores de frameworks e a falta de padrões afetam a todos
envolvidos no desenvolvimento e uso dos frameworks.
O desafio do esforço de desenvolvimento ocorre devido à alta complexidade
envolvida no projeto de um framework. Se desenvolver aplicações complexas é
difícil, desenvolver frameworks que sejam de alta qualidade, extensíveis e
reusáveis para domínios de aplicações complexos ou para tratar aspectos de infraestrutura ou de integração de middleware é ainda mais difícil. Projetistas de
frameworks devem estar cientes dos custos decorrentes do desenvolvimento de
frameworks de aplicação.
Quanto à curva de aprendizagem, aprender a usar um framework de
aplicação leva tempo e incorre em custos. A menos que o esforço de aprendizado
possa ser amortizado através do uso do framework em muitos projetos, ou em
projetos duradouros, o investimento pode não compensar. Deve ser analisado se
os benefícios trazidos pelo framework compensam os custos com o treinamento
da equipe de desenvolvimento.
O desafio da integração ocorre quando diversos frameworks são usados com
outras tecnologias e com sistemas legados não previstos pela arquitetura do
40
framework. Antes de usar um framework o desenvolvedor de aplicações deve
analisar possíveis problemas que possam surgir ao incorporar novos frameworks à
aplicação.
Além disso, aplicações usando frameworks podem apresentar desempenho
inferior a aplicações específicas. Para tornarem-se extensíveis, frameworks de
aplicações adicionam níveis de indireção. Aplicações genéricas tendem a obter
desempenho inferior a aplicações específicas (Fayad et al., 1999b). Desta forma o
desenvolvedor de aplicações deve considerar se os ganhos advindos do reuso
compensam uma potencial perda de desempenho.
Frameworks inevitavelmente precisam ser mantidos. A manutenção em
frameworks toma diversas formas como, correção de erros de programação,
acréscimo ou remoção de funcionalidades, acréscimos ou remoção de pontos de
extensão, etc. A manutenção é realizada pelos mantenedores do framework, que
precisam ter um conhecimento profundo sobre os componentes internos e suas
interdependências. Em alguns casos, a própria instância do framework sofre
manutenção para acompanhar a evolução do framework. Cabe ao desenvolvedor
da aplicação considerar o esforço de manutenção gasto para obter os benefícios de
uma nova versão do framework.
Além disso, a validação e remoção de erros de um framework ou de uma
aplicação que usa um framework é um desafio, pois o framework é uma aplicação
inacabada, o que torna difícil tanto para os mantenedores de frameworks quando
para os desenvolvedores de aplicação testar, respectivamente, o framework e a
instância do framework isoladamente. Aplicações que usam framework costumam
ser mais difíceis de depurar, pois devido a IoC, o controle da execução oscila
entre a aplicação e o framework.
Por fim, ainda não há um padrão amplamente aceito para desenvolver,
documentar, implementar e adaptar frameworks. Todos os papéis envolvidos no
desenvolvimento e uso do framework são afetados por este desafio, sendo que os
mais afetados são os mantenedores do framework e o desenvolvedor de
aplicações. O primeiro, pois precisa ter um conhecimento profundo sobre os
componentes internos e suas interdependências. O segundo, pois a falta de um
padrão de documentação de frameworks dificulta o seu uso.
41
2.5.
Frameworks e Outras Abordagens
Esta seção realiza uma breve comparação entre frameworks e outras
técnicas de desenvolvimento de software que objetivam o reuso. Dentre elas, são
analisadas o projeto de aplicações orientado a objetos, biblioteca de classes,
padrões de projeto e componentes de software (Pinto, 2000).
2.5.1.
Frameworks e Aplicações Orientado a Objetos
Uma aplicação orientada a objetos descreve um programa executável
completo, atendendo aos requisitos definidos nos documentos de especificação. Já
os frameworks são incompletos e não são executáveis. Eles capturam
funcionalidades comuns a diversas aplicações, mas declaram pontos de extensão
que devem ser preenchidos pela aplicação que instancia o framework.
Frameworks geram famílias de aplicações orientadas a objetos através do
preenchimento dos pontos de extensão, mas aplicações orientadas a objetos não
geram famílias de frameworks.
2.5.2.
Frameworks e Biblioteca de Classes
Bibliotecas de classes são conjuntos de classes relacionadas com um
propósito geral. Por outro lado, as classes de um framework estão relacionadas a
um determinado domínio ou a algum determinado aspecto de infra-estrutura ou de
integração de middleware. Além disso, as classes da biblioteca são reutilizadas
individualmente enquanto que as classes de um framework são reutilizadas em
conjunto.
Frameworks tendem a ter um impacto maior do que bibliotecas de classes
na arquitetura da aplicação. Frameworks ativos (calling frameworks) (Matsson,
2000), que utilizam inversão de controle, podem assumir o controle de execução
da aplicação ao contrário de bibliotecas de classes que são sempre passivas.
42
2.5.3.
Frameworks e Padrões de Projeto
Padrões de projeto são soluções mais abstratas do que um framework.
Frameworks são normalmente implementados utilizando linguagens orientadas a
objetos como Java, C++, etc. Padrões de projeto descrevem o projeto de uma
solução para um problema recorrente, podendo incluir um exemplo de
implementação. Além disso, frameworks são mais específicos que padrões de
projetos, pois estão relacionados a um domínio de aplicação, um aspecto de infraestrutura ou de integração de middleware. Já padrões de projetos são mais gerais e
podem ser usado em diversas situações independente de domínio de aplicação.
Por fim, frameworks são construções mais complexas que padrões de
projeto. Enquanto um framework pode possuir vários padrões de projeto, o
contrário não é verdadeiro.
2.5.4.
Frameworks e Componentes de Software
Componentes
de
software
podem
ser
definidos
como
unidades
independentes, que encapsulam dentro de si seu projeto e implementação e
oferecem serviços para o meio externo através de interfaces bem definidas
(Gimenes & Huzita, 2005). Componentes podem fornecer dois tipos de interface:
as interfaces fornecidas, que expõem seus serviços e as interfaces requeridas, por
onde o componente explicita suas dependências.
Frameworks também fornecem interfaces bem definidas, os pontos de
extensão, que as aplicações devem estender. Contudo, enquanto um framework
possui necessariamente pontos de extensão, um componente totalmente
autocontido não possui interfaces requeridas. Além disso, um componente deve
ser plugado a uma interface requerida de outro componente enquanto que os
pontos de extensão dos frameworks são menos exigentes, possibilitando que
sejam plugados componentes, classes ou qualquer artefato que realiza o contrato
definido.
Por fim, componentes podem ser desenvolvidos usando frameworks e
frameworks podem ser desenvolvidos usando componentes. Estas duas
43
tecnologias são complementares de forma que frameworks podem ser usados para
auxiliar o desenvolvimento de componentes e vice e versa (Szyperski, 1997).
2.6.
Conclusão
Um dos principais objetivos da engenharia de software é o reuso. Através da
reutilização de software obtém-se o aumento da qualidade e redução do esforço de
desenvolvimento. Frameworks possibilitam o desenvolvimento de família de
aplicações, geradas a partir de uma estrutura que captura os conceitos mais gerais
das aplicações.
São encontradas na literatura várias definições de frameworks. A usada
nesta dissertação é a de Buschmann et al (1996), Pree (1995) e Pinto (2000) na
qual um framework é um software parcialmente completo projetado para ser
instanciado. Isto define uma arquitetura para uma família de subsistemas e oferece
os construtores básicos para criá-los. Também são explicitados os pontos de
extensão nos quais adaptações do código para um funcionamento específico de
certos módulos devem ser feitas.
Frameworks podem ser classificados segundo Fayad et al (1999a), (1999b) e
(2000) em framework de aplicação orientado a objetos ou segundo Szyperski
(1997) em framework de componentes. O primeiro define uma estrutura para o
desenvolvimento de aplicações orientadas a objetos enquanto que o segundo
define uma infra-estrutura de execução onde componentes podem ser plugados.
Frameworks de aplicação podem ser classificados quanto ao seu escopo
como frameworks de infra-estrutura, que simplificam o desenvolvimento de
sistemas de infra-estrutura portáveis e eficientes, de integração de middleware,
usados para integrar aplicações e componentes distribuídos, e de aplicações
corporativas, voltados para um domínio de aplicação específica. Ao longo desta
dissertação é apresentado como frameworks de aplicação, em especial
frameworks de infra-estrutura, podem ser combinados para fornecer uma infraestrutura com serviços de gerenciamento de persistência de objetos, controle de
transações, etc. para um groupware.
Frameworks de aplicação podem ainda ser classificados quanto ao seu uso
como frameworks caixa branca, que exige um bom conhecimento da estrutura
44
interna do framework por parte do usuário do framework, caixa preta, que é
menos flexível que o framework caixa branca, mas possibilita o seu uso sem que o
desenvolvedor precise conhecer a estrutura interna do framework, e caixa cinza,
que tenta combinar as vantagens dos frameworks caixa branca e preta.
Há três papéis envolvidos no uso e desenvolvimento de frameworks: o
projetista do framework, responsável pela estrutura interna do framework, pelo
levantamento de requisitos e pela definição dos pontos de extensão; o mantenedor
do framework, responsável por redefinir e acrescentar novas funcionalidades ao
projeto do framework e o desenvolvedor de aplicações que instancia o framework.
Nesta dissertação os frameworks são analisados sobre a ótica do desenvolvedor de
aplicações.
O desenvolvimento com frameworks traz benefícios. Frameworks
diminuem o esforço para entender e manter a aplicação. Frameworks incentivam o
reuso, pois capturam o conhecimento de desenvolvedores em determinado
domínio ou aspecto de infra-estrutura ou de integração de middleware. Além
disso, frameworks são expansíveis por construção e, por fim, o uso de inversão de
controle simplifica o desenvolvimento de aplicações.
Ao longo desta dissertação são analisados frameworks de aplicação
incorporados à arquitetura técnica do AulaNet 3.0. Estes frameworks são usados
para compor uma base de serviços de infra-estrutura sobre a qual groupwares
podem ser desenvolvidos. Dessa forma, o desenvolvedor de groupware pode
concentrar-se no seu domínio enquanto que os frameworks de infra-estrutura
cuidam de aspectos técnicos, como persistência de dados, por exemplo. No
capítulo 3 são analisados frameworks para a camada de negócios enquanto que no
capítulo 4 são analisados frameworks para a camada de apresentação.
Apesar dos benefícios decorrentes do uso de frameworks, também são
impostos desafios ao desenvolvimento de frameworks e de aplicações que usem
os frameworks. Dentre eles, o esforço de desenvolvimento, imposto aos
projetistas de frameworks, a curva de aprendizagem, a integração e a eficiência,
que afetam principalmente os desenvolvedores de aplicação, a manutenção e
validação e remoção de defeitos, que afetam tanto desenvolvedores de aplicação
quanto mantenedores de frameworks e o desafio da falta de padrões que afetam a
todos envolvidos no desenvolvimento e uso de frameworks.
45
O desafio da curva de aprendizagem é o principal ao considerar as
características do AulaNet, pois ele é desenvolvido por alunos de graduação,
mestrado e doutorado da PUC-Rio. Além a empresa EduWeb desenvolve
customizações no AulaNet para seus clientes. Para lidar com este desafio, é
considerada a quantidade de documentação disponível para cada framework além
da disponibilidade de suporte. Além disso, é considerada a quantidade de mão de
obra disponível no mercado já apta a trabalhar com o framework, eliminando
assim o custo com o treinamento, e a quantidade de ferramentas compatíveis
disponíveis, pois elas auxiliam o uso do framework, suavizando a curva de
aprendizado.
Quanto à falta de padrões, sob a ótica do desenvolvedor este não é um
desafio crítico, desde que haja uma quantidade de documentação suficiente,
mesmo que não padronizada, sobre o framework.
Como o AulaNet 3.0 é desenvolvido sem reutilizar o código legado do
AulaNet 2.1, sistemas legados não são problema e o desafio da integração se
resume a integração com outros frameworks. Para lidar com este desafio, os
frameworks são analisados tecnicamente para que a compatibilidade possa ser
verificada. Além disso, considera-se o grau de intrusão dos frameworks, pois,
quanto menos intrusivos, mais facilmente os artefatos do framework podem ser
usados em outro contexto.
Quanto ao desafio da eficiência, este não é um problema crítico para o
AulaNet. Os principais problemas presentes na arquitetura do AulaNet 2.1 e que
levaram à especificação de uma nova arquitetura referem-se à manutenibilidade
que ao longo dos anos tornou-se muito custosa. Sendo assim, considera-se que
vale a pena sacrificar um pouco a eficiência para ganhar na manutenibilidade.
Além disso, como está sendo adotada uma abordagem de desenvolvimento
baseada em componentes, um problema crítico de eficiência decorrente do uso de
determinado framework em um componente pode ser resolvido substituindo o
componente por outro que não use o framework, de maneira pontual sem afetar os
outros componentes que obtém eficiência satisfatória.
Por fim, é importante lidar com os desafios da manutenção, validação e
remoção de defeitos. Frameworks pouco usados correm o risco de serem
descontinuados enquanto que frameworks muito usados tendem a permanecer em
desenvolvimento, recebendo manutenção e tendo seus erros corrigidos. Isto é
46
particularmente verdade em se tratando de frameworks de código aberto onde,
mesmo que os projetistas originais do framework decidam não realizar mais
manutenção nele, haverá desenvolvedores dispostos a assumir a tarefa. Ao
verificar o grau de aceitação de mercado dos frameworks, apenas frameworks de
grande aceitação são incorporados à arquitetura do AulaNet 3.0.
3
A Camada de Negócios
O objetivo da camada de negócios é implementar a lógica da aplicação,
expondo esta lógica para a camada de apresentação ou para outras aplicações
clientes remotas, por exemplo, clientes móveis, através de interfaces bem
definidas. Alternativas para a implementação da camada de negócios envolvem o
modelo de componentes Enterprise JavaBeans (EJB, 2005) e o uso de POJOs
(POJO, 2005) com frameworks de infra-estrutura.
Neste capítulo, é apresentado um resumo das principais características do
framework de componentes Enterprise JavaBeans, focando os serviços de infraestrutura que este oferece e apresentando as vantagens e desvantagens decorrentes
do seu uso. Logo depois, são analisados os frameworks de infra-estrutura
Hibernate (2005) e Spring (2005), que oferecem serviços de infra-estrutura
similares aos do EJB. Por fim, são oferecidos argumentos que fundamentam a
escolha de uma arquitetura com POJOs e frameworks de infra-estrutura ao invés
de uma arquitetura com Enterprise JavaBeans.
3.1.
O Modelo de Componentes Enterprise JavaBeans
Enteprise JavaBeans (EJB) é uma tecnologia da Sun Microsystems que
possibilita o desenvolvimento de componentes distribuídos para a camada de
negócios. EJB é um modelo de componentes, isto é, define uma especificação
para a construção de componentes (Szyperski, 1997). Servidores de aplicações
compatíveis com a especificação J2EE trazem frameworks de componentes que
implementam este modelo. EJB também pode ser classificado como um
framework de integração de middleware, pois provê suporte à comunicação
remota entre componentes através de RMI-IIOP (2005) e também como
framework de infra-estrutura, pois trata aspectos como, por exemplo, persistência,
segurança e controle de transações, típicos de infra-estrutura.
Capitulo 3. A Camada de Negócios
48
Há 3 tipos de componentes EJB: os beans de sessão (Session Beans), que
representam processos síncronos de negócios, os beans de entidade (Entity Beans)
que representam entidades persistentes e os beans orientados a mensagem
(Message Driven Beans) que representam processos de negócios assíncronos. Esta
seção destaca os aspectos de infra-estrutura mais relevantes do EJB.
Componentes EJB podem ser distribuídos em várias máquinas virtuais Java,
neste caso diz-se que os componentes têm interfaces remotas, ou podem estar
contidos na mesma máquina virtual, diz-se que têm interfaces locais.
Opcionalmente um componente oferece os dois tipos de interfaces. Cabe ao
desenvolvedor do componente programar a classe do bean e as interfaces, sejam
elas remotas ou locais.
Beans de entidade usam persistência gerenciada pelo bean (bean managed
persistency - BMP), onde o próprio desenvolvedor do componente programa o
código que persiste os dados, ou persistência gerenciada pelo container (container
managed persistency - CMP), onde o container gera o código que persiste os
dados. Beans de entidade podem usar relacionamentos gerenciados pelo container
(container managed relationship - CMR) onde o container mantém a integridade
referencial dos relacionamentos entre beans de entidade.
De forma similar, Enterprise JavaBeans oferece suporte às transações
gerenciadas pelo bean (bean managed transaction – BMT) e às transações
gerenciadas pelo container (container managed transaction – CMT). Com BMT,
não aplicável a beans de entidade, o desenvolvedor delimita programaticamente o
início e o fim de cada transação. Já com CMT o desenvolvedor declara em um
arquivo descritor o escopo das transações.
Além destes aspectos, EJB também trata questões relacionadas à segurança.
Através do uso da API de segurança do Enterprise JavaBeans, o acesso a um
componente ou a um determinado conjunto de operações de um componente pode
ser restrito a um grupo de usuários. Este controle é feito de forma declarativa ou
de forma programática.
Por fim, o container Enterprise JavaBeans é responsável por gerenciar o
ciclo de vida das instâncias dos EJBs. Utilizando pool de objetos, o container é
capaz de reutilizar instâncias de beans, reduzindo a necessidade de criar novas
instâncias e aumentando assim o desempenho da aplicação. O container também
49
medeia o acesso aos componentes, evitando problemas decorrentes do acesso
simultâneo de várias threads a uma mesma instância de componente.
EJB oferece uma série de características que oferecem suporte aos aspectos
de infra-estrutura de uma aplicação. O principal objetivo da incorporação de
aspectos de infra-estrutura a um framework de componentes é possibilitar que o
desenvolvedor de componentes concentre-se no domínio em que ele é especialista
(no caso do AulaNet, colaboração) deixando aspectos como persistência de dados,
por exemplo, para outros especialistas. EJB consegue em parte atingir estes
objetivos. Nas próximas seções são vistas as principais vantagens e desvantagens
decorrentes do uso de Enterprise JavaBeans.
3.1.1.
Vantagens Decorrentes do Uso de Enterprise JavaBeans
Como visto na seção anterior, EJB é um modelo de componentes que
também trata de aspectos de infra-estrutura. As principais vantagens do uso de
EJB decorrem principalmente da incorporação destes aspectos.
O uso tanto de persistência gerenciada pelo container (CMP) quanto de
relacionamentos gerenciados pelo container (CMR) em beans de entidade
possibilitam que o desenvolvedor concentre-se na lógica de negócio em vez de
concentrar-se na tecnologia que persiste os dados. Além do mais, o código da
aplicação fica independente do SGBD (sistema de gerenciamento de banco de
dados), pois todos os comandos para consultar, salvar, atualizar e remover
entidades são gerados pelo container.
Além disso, o uso de transações declarativas possibilita que o desenvolvedor
de componentes construa o componente sem precisar demarcar transações,
incentivando o reuso já que o escopo da transação é determinado sem que seja
necessário recompilar o código fonte do componente. O uso de CMT também
evita a introdução de erros que surgem decorrentes do esquecimento de sessões
com o banco de dados abertas e não confirmadas, já que o container se encarrega
disto. Da mesma forma, o uso de segurança declarativa incentiva o reuso, pois o
componente é customizado com uma política de segurança mais ou menos rígida,
dependendo do escopo onde é usado, sem necessidade de mudanças no código
fonte.
50
EJB também possibilita que componentes instalados em máquinas virtuais
diferentes se comuniquem, de modo que os componentes da camada de negócio
de uma aplicação podem ser instalados em máquinas diferentes. Este tipo de
distribuição de componentes é útil, por exemplo, nos casos em que um
componente reside no mesmo servidor em que está disponível um recurso de que
ele necessita (por exemplo, quando um componente precisa acessar um recurso
que só aceita conexões locais), no caso de componentes que demandam muito
processamento (o componente pode ter um servidor dedicado a ele, não
atrapalhando o desempenho dos outros componentes da aplicação) ou quando um
componente precisa acessar outro componente do qual os desenvolvedores só tem
acesso às interfaces (por exemplo, quando um componente precisa acessar um
sistema de cartões de crédito).
O uso de Entreprise JavaBeans traz uma série de vantagens relacionadas a
aspectos de infra-estrutura porém há uma série de desvantagens inerentes ao seu
modelo de componentes, que são discutidas a seguir.
3.1.2.
Desvantagens Decorrentes do Uso de Enterprise JavaBeans
A principal desvantagem decorrente do uso de EJBs é o grande número de
arquivos, incluindo código fonte escrito em Java e descritores XML, que precisam
ser mantidos para definir os beans de sessão e de entidade, os tipos de beans mais
usados no desenvolvimento de aplicações com EJB. Para desenvolver um destes
componentes é preciso pelo menos 3 arquivos de código fonte: a interface do
componente, a interface home a classe do componente. Eventualmente, este
número pode chegar a 6 arquivos de código fonte, contando apenas as classes
previstas na especificação do modelo de componentes EJB.
A interface do componente define os serviços prestados pelo componente e
pode ser local ou remota. Se a interface do componente for local, ela deverá
estender a interface javax.ejb.EJBLocalObject, se for remota deverá estender a
interface javax.ejb.EJBObject.
A interface home é responsável por criar instâncias de componentes ou
localizar instâncias existentes, no caso de beans de entidade. A interface home é
definida como local ou remota, de acordo com a definição da interface do
51
componente. Se a interface home do componente for local, ela deverá estender a
interface javax.ejb.EJBLocalHome, se for remota deverá estender a interface
javax.ejb.EJBHome.
A classe do componente encapsula as regras de negócio e implementa
também a interface javax.ejb.SessionBean no caso de beans de sessão ou a
interface javax.ejb.EntityBean no caso de beans de entidade. A classe do
componente pode, mas não é obrigada a implementar a interface do componente
(a local ou a remota, sendo impossível implementar as duas). Se o desenvolvedor
de componentes optar por desenvolver a classe do componente sem implementar a
interface do componente, a sincronização entre interface e implementação deve
ser realizada manualmente sem o suporte da linguagem Java, o que pode resultar
em erros. Por outro lado, se o desenvolvedor de componentes optar por
desenvolver a classe do componente implementando a interface do componente,
ele deverá implementar os métodos definidos nas interfaces EJBObject, se o
componente for remoto, ou EJBLocalObject, se o componente for local. A
implementação destes métodos nunca é executada, pois eles são sobrescritos pelo
container em tempo de implantação. A classe do componente deve ainda
implementar métodos de callback definidos na especificação do EJB, como o
ejbCreate e o ejbPostCreate por exemplo. Além destes arquivos, no caso de beans
de entidade com chave primária composta é preciso mais uma classe para
representar esta chave.
Todos os enterprise beans também precisam ser acompanhados de um
arquivo descritor em formato XML, onde são declaradas as regras de transação,
segurança, etc. Dependendo do servidor de aplicações usado, podem ser
necessários outros descritores, onde são declaradas regras como o mapeamento de
beans de entidade em tabelas do banco de dados, mapeamento de beans orientado
a mensagens ao dispositivo de mensagem entre outros. Esta grande quantidade de
arquivos traz problemas de manutenção. Esta desvantagem pode ser em parte
amenizada pelo uso de ferramentas como o XDoclets (2005), porém permanece
sendo uma solução mais complexa do que usar uma interface Java e uma classe
que a implementa.
Além da grande quantidade de arquivos que precisam ser mantidos,
componentes Enterprise JavaBeans precisam ser executados dentro de um
container EJB. Isto implica em um leque de opções menor na hora de escolher o
52
servidor de aplicações. Alguns servidores populares como o Tomcat (2005) não
podem ser usados, pois não possuem container EJB e servidores comerciais que
possuem container EJB em geral são mais caros.
Além disso, os componentes EJB são dependentes do container, com
diversos métodos de callback chamados pelo container EJB ao longo de seu ciclo
de vida. Desta forma, componentes EJB são mais difíceis de testar unitariamente,
pois precisam estar em execução dentro do container para serem testados. No caso
de componentes com interfaces locais, o próprio código de teste deve ser
implantado junto com o componente para que este possa ser testado.
No capítulo 25.1.2 da especificação do EJB 2.1 (EJB, 2003) são descritas
várias restrições impostas aos componentes EJB, como por exemplo, proibição de
escrita ou leitura de arquivos no disco, do uso de campos estáticos não finais e do
uso da palavra reservada this como referência para a instância do componente em
um método, seja como parâmetro ou valor de retorno. Estas restrições se seguidas
rigorosamente impossibilitam a realização de atividades corriqueiras como, por
exemplo, escrita de arquivos de logs para auditoria ou a implementação do padrão
de projeto Singleton (Gamma et al., 1995). Além disso, desenvolvedores Java
estão habituados a usar this para referenciar a instância do componente e podem
ser introduzidos erros de programação decorrentes deste hábito. Todavia na
prática, servidores de aplicação como o JBoss (2005) costumam relaxar algumas
destas restrições para possibilitar operações como o log de ações.
O uso de EJBs na camada de negócio ao mesmo tempo que traz vantagens
por tratar aspectos de infra-estrutura traz uma série de desvantagens expostas
nesta seção. Em novembro de 2005, a especificação corrente do EJB era a 2.1,
porém a especificação 3.0 estava em desenvolvimento, aberta ao público para
discussões.
3.1.3.
O Futuro do Enterprise JavaBeans
Apesar da especificação da versão 3.0 do Enterprise JavaBeans ainda não
estar completamente definida, a tendência que pode ser percebida através das
especificações desta nova versão é tornar o desenvolvimento com EJB menos
complexo. Através do uso de anotações, um recurso inserido no J2SE 1.5 que
53
provê suporte a meta-informação no código fonte, o número de arquivos que
precisam ser mantidos tende a diminuir.
Nota-se também que o criador do framework Hibernate, Gavin King, é
membro do grupo de especialistas da especificação 3.0 do EJB (JSR 220, 2005) e
tem exercido influência, tornando o modelo dos beans de entidade mais similar ao
modelo de POJOs usado no framework Hibernate. Além disso, um suporte a
Dependency Injection similar ao do framework Spring, porém mais limitado, está
previsto na especificação (Johnson, 2004).
Levará um tempo considerável até que seja viável usar EJB 3.0 em projetos.
É preciso esperar que a especificação final seja lançada, que os servidores de
aplicação tornem-se compatíveis com a especificação e que as instituições se
atualizem com esta nova tecnologia. Deve-se considerar também que as versões
das especificações anteriores do EJB frustraram arquitetos e desenvolvedores
devido à sua complexidade e que, mesmo que a nova versão amenize os
problemas legados, será preciso reconquistá-los (Johnson, 2004; Fowler, 2002;
Tate et al., 2003; Sharp et al., 2002).
3.2.
Uma Arquitetura Usando POJOs
Enquanto o futuro do EJB permanece incerto, uma arquitetura que utilize
POJOs (Plain Old Java Objects) em conjunto com frameworks de infra-estrutura é
mais adequada para uso no AulaNet 3.0. O framework Hibernate (2005) provê o
mapeamento de POJOs em tabelas de bancos de dados, fornecendo uma
funcionalidade
similar
a
dos
beans
de
entidade
com persistência
e
relacionamentos gerenciados pelo container e (CMP/CMR). Já o framework
Spring (2005) complementa o Hibernate fornecendo a POJOs serviços de
gerenciamento de transações, gerenciamento de segurança declarativa e
exportação de serviços remotos, além de outras vantagens não presentes no EJB.
Em conjunto estes dois frameworks têm a maior parte das vantagens trazidas pelo
EJB, eliminando a maior parte das desvantagens (Johnson, 2004).
Nas próximas seções são analisadas com mais detalhes as questões
decorrentes do mapeamento de objetos em tabelas de banco de dados e como o
framework Hibernate trata destas questões provendo funcionalidades similares às
54
dos beans de entidade para uma arquitetura de POJOs. Posteriormente é visto
como o framework Spring prove um conjunto de funcionalidades possibilitando o
uso de segurança, transações declarativas e exposição de serviços remotos.
3.3.
Questões Decorrentes do Mapeamento Objetos em Tabelas
Quase todo tipo de aplicação requer que seus dados sejam persistidos de
alguma forma. Um sistema de gerenciamento de banco de dados (SGBD)
relacional não é especifico para Java tampouco destinado para uma aplicação
específica. A tecnologia relacional provê uma forma de compartilhar dados entre
aplicações diferentes e entre tecnologias diferentes usadas em uma mesma
aplicação, por exemplo, um sistema gerador de relatórios e um sistema de
gerenciamento de cadastro. Devido a estas características, os SGBDs são o meio
de persistir dados das entidades de negócios mais utilizado em aplicações (King &
Bauer, 2005).
Quando a tecnologia envolvida é Java, a forma mais baixo nível que esta
plataforma oferece para enviar comandos ao SGBD é através da API Java
DataBase Connectivity (JDBC, 2005). Através do JDBC uma aplicação Java é
capaz de enviar comandos SQL para um SGBD e assim realizar operações de
consulta, atualização, inserção e remoção de dados. O código JDBC fica
responsável por realizar a conversão dos dados provenientes do SGBD em classes
orientadas a objeto escritas em Java.
Escrever código de acesso a banco de dados, realizando as conversões
necessárias do paradigma relacional para o paradigma OO é uma tarefa onerosa,
repetitiva e algumas vezes propensa a erros devido à diferença entre estes
paradigmas. Para entender o framework Hibernate, é preciso antes entender o
conflito dos paradigmas OO e relacional, que ele se propõe a mediar.
3.3.1.
Conflito de Paradigmas: Orientação a Objetos x Relacional
Ao migrar de um paradigma para outro surgem questões que devem ser
resolvidas. Dentre elas, as principais são: a questão dos subtipos, a questão da
igualdade, as questões dos relacionamentos e a questão do grafo de navegações
55
(King & Bauer, 2005). Esta seção não se propõe a apresentar as soluções destas
questões, mas apenas apresentá-las. Posteriormente, é mostrado como o Hibernate
trata destas questões.
A questão dos subtipos surge, pois o paradigma OO possibilita que classes
herdem de outras classes, podendo compor modelos complexos através de
herança. Os sistemas de gerenciamento de banco de dados relacionais não
oferecem suporte a heranças entre tabelas.
A questão de igualdade surge quando é necessário verificar se um objeto é
igual ao outro. Em Java, há duas maneiras de verificar a igualdade de objetos:
através do conceito de identidade de objetos, que define que um objeto é igual ao
outro se ambos ocupam o mesmo espaço de memória (é checado com o operador
de igualdade ‘a == b’) e através do conceito de equivalência de objetos, que é
determinada através do método equals() quando este é implementado (é checado
através de ‘a.equals(b)’). No paradigma relacional a identidade de uma linha de
uma tabela é definida através do valor da chave primária.
Relacionamentos em linguagens OO são expressos através de referências a
objetos ou coleções de referências a objetos. Já no paradigma relacional os
relacionamentos são expressos na forma de chaves estrangeiras. As questões dos
relacionamentos surgem a partir das diferenças destas duas formas de representar
relacionamentos.
Relacionamentos no paradigma OO são direcionais, ou seja, são definidos
de uma classe para outra. Para criar um relacionamento bidirecional no paradigma
OO é preciso definir dois relacionamentos unidirecionais, um em cada uma das
classes envolvidas. A noção de direção em relacionamentos não existe no
paradigma relacional. Além disto, classes no paradigma OO, podem ser definidas
tendo relacionamentos com multiplicidades um-para-um, um-para-muitos ou
muitos-para-muitos enquanto que no paradigma relacional os relacionamentos
entre tabelas são sempre um-para-muitos, definidos usando chaves estrangeiras,
ou um-para-um, definidos usando chaves estrangeiras únicas. Relacionamentos
muitos-para-muitos são feitos através de uma tabela extra, chamada tabela de
ligação (link table) que não aparece no modelo OO.
Finalmente, há a questão do grafo de navegações. O diagrama UML da
Figura 3.1 apresenta duas classes: a classe Message, representando uma
mensagem que possui uma propriedade text que armazena o texto da mensagem e
56
a classe User com duas propriedades, username que representa a identificação do
usuário e name, que representa o nome do usuário. A classe Message tem um
relacionamento unidirecional com multiplicidade um-para-um com a classe User.
User
Message
-text:String
+getAuthor():User
+setAuthor(user:User):void
+getText():String
+setText(text:String)void
1
-username:String
1 -name:String
+getUsername():String
+setUsername(username:String):void
+getName():String
+setName(name:String):void
Figura 3.1 – Diagrama de Classes que Exemplifica a Questão do Grafo de Navegação
Em um paradigma orientado a objetos, a forma natural de acessar dados em
objetos relacionados é através da técnica onde se navega de um objeto para outro
usando o operador de navegação. Por exemplo, em Java para obter o nome do
autor de uma mensagem realiza-se a seguinte operação sobre um objeto do tipo
Message: message.getAuthor().getName(). Entretanto, esta não é a forma mais
eficiente de recuperar dados em um SGBD relacional e pode levar ao problema
conhecido como “n + 1 select problem” (King & Bauer, 2005) onde para cada
navegação no grafo de objetos é realizada uma consulta na base de dados.
Recuperar o grafo inteiro de objetos de uma só vez implicará em problemas de
performance e escalabilidade, que tornam-se mais evidentes à medida que a massa
de dados da base aumenta e os relacionamentos entre os objetos tornam-se mais
complexos. A questão do grafo de navegação envolve então equilibrar estes
fatores, determinando qual porção do grafo de navegação deve ser recuperada
imediatamente e qual deve ser recuperada sob demanda.
Muitas questões devem ser consideradas quando é preciso converter um
objeto em tabelas. Esta tarefa é repetitiva, propensa a erros e independente do
domínio da aplicação, portando é susceptível à aplicação de frameworks de infraestrutura. O modelo de componentes EJB, visto na seção 3.1, soluciona algumas
destas questões com os beans de entidade. Outras questões, como o mapeamento
de subtipos, não são tratadas. Nas próximas seções é visto como Frameworks de
mapeamento objeto/relacional (Object/Relational Mapping – ORM) como o
Hibernate tratam estas questões.
57
3.4.
Frameworks ORM
Mapeamento objeto/relacional (object/relational mapping – ORM) é o nome
dado para a persistência automática e transparente de classes de uma aplicação em
tabelas de bancos de dados relacionais, transformando a representação de dados
de um paradigma para o outro (King & Bauer, 2005). Um framework ORM é um
framework de infra-estrutura que fornece serviços de ORM.
Mark Fussel (1997), um pesquisador no campo da ORM, define quatro
níveis de maturidade para soluções ORM: relacional puro (pure relational),
mapeamento leve (light object mapping), mapeamento médio (medium object
mapping) e mapeamento completo (full object mapping).
Em soluções relacionais puras, a aplicação inteira, incluindo a interface com
o usuário, é afetada pelo modelo relacional e por operações envolvendo acesso
direto à base de dados relacional com JDBC e SQL. Esta solução pode ser
adequada para sistemas pequenos onde um baixo grau de reuso de código é
tolerado. Cada consulta SQL pode ser ajustada para se obter melhor performance,
o que afeta a manutenabilidade. Está é a solução utilizada na arquitetura do
AulaNet 2.1.
Com soluções de mapeamento leve, classes são mapeadas manualmente em
tabelas relacionais. O código SQL/JDBC responsável pela persistência das classes
é isolado da lógica de negócios através do uso de padrões de projeto bem
conhecidos como o Data Access Object (DAO) (Alur et al., 2001). Esta solução é
adequada para aplicações de porte pequeno, com um pequeno número de
entidades.
Soluções de mapeamento médio são desenvolvidas ao redor de um modelo
de objetos. O código SQL responsável pela persistência dos objetos é gerado
automaticamente em tempo de compilação por uma ferramenta ou em tempo de
execução pelo framework ORM. Este nível de solução oferece suporte a
relacionamento entre objetos e fornece uma linguagem orientada a objetos para
realização de consultas. Esta solução é adequada para aplicações de médio porte,
principalmente quando a aplicação deve permanecer independente dos SGBDs. É
58
o nível de maturidade atingido pelos beans de entidade da especificação 2.1 do
EJB.
Já soluções de mapeamento completo oferecem suporte a modelos
complexos de objetos, envolvendo composição e herança. A persistência é
transparente, ou seja, as classes persistidas não herdam de uma classe ou
implementam uma interface do framework. Além disso, o framework implementa
estratégias de otimização, como por exemplo o cache de entidades. É o nível de
maturidade atingido pelo Hibernate, utilizado na arquitetura do AulaNet 3.0.
Uma solução ORM com mapeamento completo consiste de 3 módulos
principais: uma API para realização de operações de consultas, atualizações,
inserções e remoção de objetos de classes persistentes; uma linguagem ou API
para especificação de consultas referentes a classes e a propriedades de classes;
um recurso para especificação de metadados de mapeamento de objetos. A
próxima seção apresenta o Hibernate como exemplo deste tipo de solução.
3.4.1.
O Framework Hibernate
Hibernate é um framework ORM adotado na arquitetura do AulaNet 3.0
para persistir os objetos de negócio. Hibernate fornece mapeamento completo
(Fussel, 1997) e, ao contrário do EJB, trata de todas as questões relativas ao
mapeamento de objetos em tabelas levantadas na seção 3.3.1. Através da API do
Hibernate são realizadas operações de inserção, atualização, remoção e consulta
de objetos, e através da linguagem de consulta do Hibernate (Hibernate Query
Language - HQL), consultas mais complexas são realizadas. Os metadados de
mapeamento de objetos são definidos em arquivos XML.
3.4.1.1.
Hibernate - Um Exemplo Prático
Para melhor compreensão do Hibernate esta seção apresenta um exemplo
prático que ilustra o seu funcionamento. O modelo de objetos a ser persistido
escolhido é o mesmo apresentado na figura 3.1, com algumas alterações para
tornar o exemplo mais ilustrativo: O campo id, identificador único do objeto, é
59
acrescentado em ambas as classes e o campo date, data da mensagem, é
acrescentado na classe Message. O diagrama modificado é exibido na Figura 3.2.
Message
User
-id:Long
-text:String
-date:Date
+getId():Long
+setId(id:Long):void
+getAuthor():User
+setAuthor(user:User):void
+getText():String
+setText(text:String):void
+getDate():Date
+setDate(date:Date):void
1
-id:Long
-username:String
1 -name:String
+getId():Long
+getName():String
+setName(name:String):void
Figura 3.2 – Diagrama UML de Classes Persistidas no Exemplo
A implementação das classes Message e User é realizada usando POJOs,
sem quaisquer dependências com classes ou interfaces da API do Hibernate. A
Listagem 3.1 exibe o código fonte da classe Message e a Listagem 3.2 exibe o
código fonte da classe User.
01: public class Message {
02:
03:
04:
05:
private Long id;
private String text;
private Date date;
private User author;
06:
07:
public void setId(Long newValue) { id = newValue; }
public Long getId() { return id; }
08:
09:
public void setText(String newValue) { text = newValue; }
public String getText() { return text; }
10:
11:
public void setDate(Date newValue) { date = newValue; }
public Date getDate() { return date; }
12:
13:
public void setAuthor(User newValue) { author = newValue; }
public User getAuthor() { return author; }
14: }
Listagem 3.1 – Classe Message
60
Os trechos entre as linhas 02 e 04 definem as propriedades id, text e date da
classe Message. Na linha 05, o relacionamento de mensagem para autor é
definido. Os métodos definidos entre as linhas 06 e 13 constituem métodos de
acesso para a variável de relacionamento author e para as propriedades id, text e
date.
15: public class User {
16:
17:
18:
private Long id;
private String username;
private String name;
19:
20:
21:
22:
public void setUsername(String newValue) { username = newValue; }
public String getUsername() { return username; }
23:
24:
public void setName(String newValue) { name = newValue; }
public String getName() { return name; }
25: }
Listagem 3.2 – Classe User
O trecho entre as linhas 16 e 18 definem as propriedades id, username e
name enquanto que os trechos entre as linhas 19 e 24 definem os métodos de
acesso para estas propriedades. O próximo passo é configurar o Hibernate.
A configuração do Hibernate pode ser feita de três formas: através de um
arquivo de propriedades chamado hibernate.properties, instalado no classpath da
aplicação, através de um arquivo XML chamado hibernate.cfg.xml, também deve
instalado no classpath da aplicação, ou através da API do Hibernate. A Listagem
3.3 mostra um exemplo do arquivo XML de configuração do Hibernate.
61
26: <?xml version='1.0' encoding='utf-8'?>
27: <!DOCTYPE hibernate-configuration
28: PUBLIC "-//Hibernate/Hibernate Configuration DTD//EN"
29: "http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd">
30: <hibernate-configuration>
31: <session-factory>
32:
<property name="show_sql">true</property>
33:
<property name="connection.datasource">
34:
java:/comp/env/jdbc/AulaNetDB
35:
</property>
36:
<property name="dialect">net.sf.hibernate.dialect.MySQLDialect</property>
37:

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.
62
46: <hibernate-mapping>
47: <class name="User" table="TBL_USER">
48:
<id name="id"
49:
column="USR_ID"
50:
type="long">
51:
<generator class="native"/>
52:
</id>
53:
54:
55:
56:
57:
<property name="username"
type="string"
column="USRNAME"
length="50"
not-null="true"/>
58:
<property name="name"
59:
type="string"
60:
column="NAME"
61:
length="100"/>
62: </class>
63: </hibernate-mapping>
Listagem 3.4 – Arquivo User.hbm.xml de Mapeamento Objeto – Relacional
O trecho entre a linha 42 e 45 define o esquema do documento XML, para
que ele possa ser validado por ferramentas de parser. A linha 47 indica que este
arquivo se refere ao mapeamento da classe User na tabela TBL_USER. Entre as
linhas 48 e 52 são definidas as características do identificador do objeto. A linha
48 indica que o nome da propriedade que identifica o objeto é id. A linha 49
indica que esta propriedade é mapeada na coluna USR_ID da tabela TBL_USER
Já a linha 50 indica que a propriedade é do tipo long, que o Hibernate converterá
para o tipo mais apropriado para a base de dados segundo o dialeto configurado. A
linha 51 indica que o Hibernate usa o mecanismo nativo do banco de dados para
gerar chaves primárias (campos auto incrementáveis no MySQL, seqüências no
Oracle e assim por diante).
Entre as linhas 53 e 57 a propriedade username é mapeada para a coluna
USRNAME. Nota-se que na linha 56 esta propriedade é definida como tendo
tamanho máximo 50 caracteres e que na linha 57 a propriedade é definida como
requerida, isto é, não pode receber valor nulo. Estas duas características são
usadas pela ferramenta hbm2ddl, usada para gerar o esquema da base de dados
63
automaticamente. Por fim, o trecho entre as linhas 58 e 61 define o mapeamento
da propriedade name na coluna NAME de tamanho máximo 100 caracteres. A
Listagem 3.5 descreve o arquivo responsável pelo mapeamento da classe
Message.
68: <hibernate-mapping>
69: <class name="Message" table="TBL_MESSAGE">
70:
<id name="id"
71:
column="MSG_ID"
72:
type="long">
73:
<generator class="native"/>
74:
</id>
75:
<property name="text"
76:
type="string"
77:
column="MSG_TXT"/>
78:
<property name="date"
79:
type="date"
80:
column="MSG_DATE"/>
81:
82:
83:
84:
85:
<many-to-one name="author"
class="User"
column="AUTHOR_ID"
not-null="true"
cascade="save-update"/>
86: </class>
87: </hibernate-mapping>
Listagem 3.5 - Arquivo Message.hbm.xml de Mapeamento Objeto – Relacional
Neste arquivo a classe Message é mapeada na tabela TBL_MESSAGE
(linha 69). O arquivo também define o identificador com nome id e tipo long,
mapeado na coluna MSG_ID (trecho entre as linhas 70 e 74), a propriedade text
do tipo string mapeada na coluna MSG_TXT (trecho entre as linhas 75 e 77) e a
propriedade date do tipo date, mapeada na coluna MSG_DATE (trecho entre as
linhas 78 e 80).
O trecho entre as linhas 81 e 85 define o relacionamento entre as classes
Message e User. Apesar de ser um relacionamento um-para-um, ele é definido
como muitos-para-um, pois a classe Message não é capaz de determinar a
cardinalidade do lado “User” do relacionamento. O nome da propriedade da classe
64
Message que referencia a classe User é listado na linha 81. A classe User, com a
qual a classe Message se relaciona, é definido na linha 82. O campo
AUTHOR_ID definido na linha 83 indica que este é o nome da chave estrangeira
armazenada na tabela TBL_MESSAGE, que referencia a tabela TBL_USER. O
atributo not-null é definido como true na linha 84 indica que o relacionamento é
obrigatório. Por fim, o atributo cascade é configurado com o valor “save-update”
na linha 83, indicando que as operações de inserção e atualização de entidades
devem ser realizadas também para as instâncias relacionadas.
Com todas as configurações feitas, o próximo passo é usar a API do
Hibernate para realizar as operações de inserção, atualização, consulta e remoção,
também conhecidas com operações CRUD (Creation, Retrieval, Update,
Deletion). A Listagem 3.6 exibe um exemplo de operação de inserção de um
objeto persistente.
088: public class CRUDOperations01 {
089:
090:
091:
092:
093:
094:
095:
096:
097:
098:
099:
100:
101
public static void main(String[] args) {
SessionFactory sfactory = null;
Session sess = null;
Transaction tx = null;
try {
sfactory = new Configuration().configure().buildSessionFactory();
sess = sfactory.openSession();
tx = sess.beginTransaction();
User usr = new User();
usr.setUsername("johnd"); usr.setName("John Doe");
Message msg = new Message();
msg.setText("Test message"); msg.setDate(new Date());
msg.setAuthor(usr);
102:
sess.save(message);
103:
tx.commit();
104:
sess.close();
105:
} catch (Exception e) {
106:
try {
107:
tx.rollback();
108:
sess.close();
109:
} catch (HibernateException e1) { }
110:
e.printStackTrace();
111:
}
112: }
113: }
Listagem 3.6 – Operação de Criação com o Hibernate
65
Na linha 091 uma variável do tipo Session é declarada. A interface
net.sf.hibernate.Session é a principal interface da API do Hibernate. A sessão do
Hibernate, também chamada de gerenciador de persistência, pode ser vista como
um gerenciador de objetos relacionados a uma mesma unidade de trabalho. A
sessão é capaz de inserir, consultar, atualizar e remover objetos assim como
detectar mudanças nos objetos pertencentes à unidade, atualizando seus estados
persistentes quando a sessão é fechada. A sessão é um objeto leve, ou seja, não
ocupa muito espaço em memória e não leva muito tempo para ser criado e
destruído. Geralmente a sessão possui um tempo de vida curto.
Na linha 090 uma variável do tipo SessionFactory é declarada. A interface
net.sf.hibernate.SessionFactory define como objetos de sessão são criados. Este é
um objeto pesado quando comparado com a sessão, mas a aplicação só precisa
criar uma instância deste para cada base de dados.
Uma variável do tipo Transaction é declarada na linha 092. A interface
net.sf.hibernate.Transaction representa uma abstração de transações. Através desta
interface podem ser usadas transações JDBC, JTA (2005), etc.
O objeto SessionFactory é instanciado na linha 094. A partir deste objeto, a
sessão do Hibernate é criada na linha 095. A transação é iniciada na linha 096 a
partir da sessão.
Entre as linhas 097 e 100 um objeto Message e um objeto User são criados e
inicializados. Na linha 101, o relacionamento entre o objeto Message e o objeto
User é configurado. Na linha 102 o objeto é salvo na sessão. Finalmente, a
transação é confirmada na linha 103 e a sessão é fechada na linha 104. Como o
atributo cascade do relacionamento é definido como save-update (linha 85 da
listagem 3.5), o objeto User associado à classe Message também é salvo. O trecho
de código entre as linhas 105 e 111 trata eventuais erros que podem ocorrer
durante a operação.
Para efetuar a atualização de objetos é necessário recuperar o objeto que
será atualizado, alterar seu estado e fechar a sessão. A Listagem 3.7 apresenta um
exemplo da operação de atualização com o Hibernate.
66
115:
116:
117:
118:
119:
try {
120:
121:
123:
124:
Message msg = (Message) sess.load(Message.class, new Long(1));
125:
msg.setText("Message text changed!");
126:
tx.commit();
127:
sess.close();
128:
129
try {
130:
tx.rollback();
131:
sess.close();
132:
133:
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.
67
138:
139:
140:
141:
142:
143:
try {
144:
145:
146:
147:
String queryStr = "from User where user.name like ?";
Query qry = sess.createQuery(queryStr);
qry.setString(0, "Mark%");
Collection usrs = qry.list();
148:
149:
150:
151:
152:
System.out.println(usrs.size() + " users selected.");
for (Iterator i = usrs.iterator(); i.hasNext(); {
User u = (User) i.next();
System.out.println(u.getName());
}
153:
sess.close();
154:
155:
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.
68
160:
161:
162:
163:
164:
try {
165:
166:
167:
168:
Message msg = (Message) sess.load(Message.class, new Long(1));
169:
sess.delete(msg);
170:
tx.commit();
171:
sess.close();
172:
173:
try {
174:
tx.rollback();
175:
sess.close();
176:
177:
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.
69
User
-username:String
-password:String
+setPassword(password:String):void
+getPassword():String
Administrator
Learner
- phone:String
-email:String
+setPhone(phone:String):void
+getPhone():String
+setEmaile(email:String):void
+getEmail():String
Figura 3.3 – Diagrama de Classes com Herança.
Ao aplicar o mapeamento usando uma tabela para cada classe concreta, são
geradas duas tabelas: a tabela ADMINISTRATOR, com as colunas USERNAME,
PASSWORD e PHONE além da tabela LEARNER, com as colunas
USERNAME, PASSWORD e EMAIL. Os principais problemas desta abordagem
são que ela não oferece suporte a consultas com polimorfismo e a dificuldade em
manter o esquema das tabelas no banco de dados, já que os atributos da
superclasse são replicados em cada tabela.
O mapeamento usando uma tabela por hierarquia de classes resulta em uma
tabela com todas as propriedades em todas as classes e um identificador que
determina o tipo da subclasse a qual a linha da tabela se refere. No exemplo da
Figura 3.3, uma tabela seria criada com as propriedades USERNAME,
PASSWORD, PHONE, EMAIL E USER_TYPE. A propriedade USER_TYPE é
usada para discriminar a qual subclasse cada linha pertence. Esta abordagem
possibilita o uso de consultas com polimorfismo e facilita a manutenção, contudo
há um problema: os atributos referentes às subclasses não podem ser declarados
como não nulos já que a mesma tabela armazena as instâncias das duas
subclasses.
O mapeamento usando uma tabela por subclasse resulta que cada classe,
abstrata ou concreta, seja mapeada em uma tabela. A ligação entre as superclasses
e as subclasses é feita através de relacionamentos de chave estrangeira. O
mapeamento do modelo descrito na Figura 3.3 resultaria em 3 tabelas: a tabela
70
USER, com as propriedades USER_ID, USERNAME e PASSWORD; a tabela
ADMINISTRATOR, com as propriedades PHONE e USER_ID, que é chave
estrangeira para a tabela USER; a tabela LEARNER, com as propriedades
EMAIL e USER_ID, também chave estrangeira. A principal vantagem desta
técnica é que ela resulta num modelo relacional normalizado ao mesmo tempo em
que possibilita o uso de consultas com polimorfismo. Contudo, é uma técnica
mais complexa do que as duas outras anteriormente citadas.
O Hibernate possibilita o uso das três técnicas, conforme a necessidade da
aplicação. A técnica “uma tabela para cada classe concreta” pode ser aplicada
naturalmente, sem que seja preciso qualquer configuração especial nos arquivos
de mapeamento do Hibernate. A técnica “uma tabela por hierarquia de classes” é
aplicada usando o elemento <subclass> no arquivo de mapeamento enquanto que
a técnica “uma tabela por subclasse” é aplicada usando elemento <joinedsubclass>.
3.4.1.3.
Hibernate e a Questão da Igualdade
Conforme visto na seção 3.3.1, há duas maneiras de representar igualdade
em Java: através do conceito de identidade e de equivalência enquanto que no
paradigma relacional a igualdade é determinada através de chaves primárias.
A identidade de objetos no Hibernate é determinada pelo valor do campo
identificador, representado pelo elemento <id> no arquivo de mapeamento,
mapeado para uma chave primária de uma tabela. Para checar se dois objetos
representam a mesma entidade, pode-se consultar o método de acesso do
identificador na classe de negócio (getId() no caso das classes Message e User do
exemplo da sessão 3.4.1.1.) ou utilizar o método Session.getIdentifier(Object o).
Os identificadores podem ser naturais, com algum significado para o
modelo de negócios, ou surrogates, sem significado para a lógica de negócios. O
Hibernate fornece várias estratégias usadas para gerar identificadores surrogates,
entre eles a estratégia sequence, que utiliza seqüências, incremente, que utiliza
campos auto incrementáveis e uuid.hex, que gera um identificador único, mesmo
quando ocorre processamento paralelo em várias máquinas.
71
3.4.1.4.
Hibernate e as Questões dos Relacionamentos
O Hibernate possibilita o uso de relacionamentos unidirecionais ou
bidirecionais, com cardinalidade um-para-um, um-para-muitos ou muito-paramuitos. Há várias formas de mapear relacionamentos com o Hibernate e descrever
todas seria excessivamente complexo e fugiria ao escopo desta dissertação.
Contudo, o exemplo da seção 3.4.1.1. exemplifica o uso de relacionamentos
direcionais um-para-um.
O Hibernate impõe uma limitação em classes com relacionamentos com
cardinalidade de muitos: a variável do relacionamento deve ser determinada em
função da interface da coleção em vez da classe concreta. Por exemplo, a interface
java.util.List deve ser usada em vez da classe java.util.LinkedList. O Hibernate
usa sua própria implementação de coleções, que oferece recursos como, por
exemplo, busca tardia, que é vista na próxima seção. Esta limitação, contudo não é
um problema já que programar para interfaces é uma conhecida boa prática de
programação (Bloch, 2002).
3.4.1.5.
Hibernate e a Questão do Grafo de Navegação
Uma das principais questões em ORM é fornecer acesso eficiente a uma
base de dados relacional através de um grafo de objetos (King & Bauer, 2005).
Conforme visto na seção 3.3.1., é importante determinar a porção do grafo de
objetos recuperada em cada consulta. Para lidar com esta questão, Hibernate
define quatro estratégias possíveis de busca que podem ser usadas em quaisquer
relacionamentos: busca imediata (immediate fetching), busca tardia (lazy
fetching), busca antecipada (eager fetching) e busca em lote (batch fetching).
Com a estratégia da busca imediata, logo que uma entidade é recuperada da
base de dados a entidade do relacionamento é recuperada através de uma consulta
à base de dados ou então ao cache de entidades. Esta estratégia não costuma ser
eficiente a não ser que as entidades relacionadas estejam quase sempre no cache.
A estratégia de busca tardia possibilita que a entidade relacionada seja
recuperada sob demanda, apenas quando for necessário consultá-la. A busca tardia
é um conceito fundamental para que uma performance adequada seja alcançada.
72
Com a estratégia de busca antecipada, as entidades relacionadas são
recuperadas em uma mesma consulta através do uso do comando SQL OUTER
JOIN. Otimizações em uma aplicação que usa Hibernate geralmente envolvem a
configuração de relacionamentos, escolhendo a estratégia de busca antecipada
para classes que quase sempre são usadas em conjunto.
A estratégia de busca em lote é uma técnica que pode aumentar a
performance de relacionamentos com a estratégia de busca tardia ou imediata.
Usualmente, ao recuperar um objeto da base de dados, uma consulta SQL é
realizada com uma cláusula WHERE, especificando o identificador do objeto
recuperado. Se a estratégia da busca em lote for usada, sempre que uma consulta
for realizada, o Hibernate procura por outros objetos na mesma unidade de
trabalho da sessão recuperáveis usando a mesma consulta, mas com valores
múltiplos para a cláusula WHERE. Quase sempre a estratégia de busca tardia é
mais eficiente que esta estratégia, porém a busca em lote é mais adequada para
usuários do Hibernate que não desejam ou não podem usar seu tempo para ajustar
a aplicação com uma combinação de busca tardia e antecipada.
Como visto nesta seção, o Hibernate fornece os meios para a resolução da
questão do grafo de navegação, porém cabe ao desenvolvedor configurar os
atributos dos relacionamentos na aplicação de forma a obter uma performance
satisfatória.
3.4.1.6.
Considerações Finais Sobre o Hibernate
Hibernate possibilita o uso de persistência de POJOs de uma forma similar
aos beans de entidades do EJB. Hibernate oferece vantagens sobre EJB. Hibernate
é uma solução de mapeamento completo enquanto que os beans de entidade de
EJB oferecem mapeamento médio (Fussel,1997). Por outro lado, EJB oferece
outros serviços de infra-estrutura como, por exemplo, transações gerenciadas pelo
container. Na seção 3.5 é visto como o Hibernate aliado ao Spring oferece
também estes serviços.
Há outros frameworks ORM além do Hibernate disponíveis no mercado.
Alguns gratuitos, outros comercias. A próxima seção apresenta um apanhado
73
destes frameworks, justificando a escolha do Hibernate para a arquitetura do
AulaNet 3.0.
3.4.2.
Outros Frameworks ORM
Segundo o artigo Object Relational tool comparision disponível em
http://c2.com/cgi/wiki?ObjectRelationalToolComparison
há
cerca
de
29
frameworks ORM disponíveis para Java atualmente, 14 deles são comerciais
enquanto que 15 são gratuitos. Como o AulaNet é distribuído gratuitamente, os
frameworks ORM comerciais são imediatamente descartados.
Dentre os 15 frameworks ORM gratuitos, 7 exigem que as classes
persistidas estendam alguma classe ou implemente alguma interface, resultando
em um forte acoplamento entre as classes do modelo e o framework, por isto
também são descartados. Entre os restantes, apenas o Hibernate (2005), iBATIS
(2005), Apache OJB (OJB, 2005) e JDOMax (2005), uma implementação da
especificação JDO (2005) são soluções de mapeamento completo.
Para confirmar a escolha do Hibernate em face destas outras opções é
realizada uma pesquisa, considerando aspectos não técnicos. Raible (2005) realiza
uma comparação entre web frameworks, apresentada no capítulo 4, onde são
considerados os seguintes itens: quantidade de documentação disponível,
disponibilidade de suporte, disponibilidade de ferramentas compatíveis, grau de
aceitação no mercado e disponibilidade de profissionais aptos a trabalhar com os
frameworks. Nesta seção é feita uma comparação similar, porém entre
frameworks ORM.
3.4.2.1.
Quantidade de Documentação Disponível
Há duas formas de contabilizar a disponibilidade de documentação acessível
sobre uma tecnologia: verificando o número de livros publicados sobre a
tecnologia ou verificando o número de tutoriais disponíveis na web. O gráfico da
Figura 3.4 mostra o número de livros publicados para cada framework ORM
segundo uma pesquisa realizada em novembro de 2005 no site da Amazon.
74
10
8
6
4
2
0
Apache OJB
Hibernate
iBATIS
JDO
Figura 3.4 – Livros Publicados Para Cada Framework ORM
Fonte: Amazon.com, Novembro de 2005
Para contabilizar o número de tutoriais disponíveis na web sobre cada
framework ORM, é feita uma consulta na ferramenta de busca Google. O
resultado da pesquisa realizada em março de 2006 é apresentado no gráfico da
Figura 3.5.
100000
80000
60000
40000
20000
0
Apache OJB
Hibernate
iBATIS
JDO
Figura 3.5 – Artigos e Tutoriais Para Cada Framework ORM
Fonte: Google.com, Março de 2006
Há uma quantidade significativamente maior de documentação disponível
para o Hibernate, tanto na forma de livros quanto na forma de tutoriais e artigos
com o JDO ocupando a segunda colocação.
75
3.4.2.2.
Disponibilidade de Suporte
É importante que o framework ORM escolhido disponha de suporte para
resolver questões não tratadas pela documentação disponível. Os frameworks
ORM Apache OJB e iBATIS possuem comunidades ativas que se comunicam
através de listas de discussão, trocando informações e provendo suporte gratuito.
Para mensurar a disponibilidade de suporte destes frameworks, realiza-se uma
pesquisa contabilizando o volume de mensagem trocado nestas listas de discussão
em determinado período de tempo.
O Hibernate também possui comunidade ativa, mas a troca de mensagem é
feita por fórum. Como o fórum não fornece nenhum mecanismo para selecionar as
mensagens enviadas em um determinado período de tempo, para mensurar o
volume de mensagens trocado foi realizada comunicação pessoal com os
administradores do fórum através de e-mail. Estes, que possuem mais privilégios
que os usuários comuns, forneceram o número de mensagens trocadas no período
especificado. O apêndice A apresenta uma transcrição dos e-mails trocados com
os administradores do fórum.
O framework JDOMax não possui nenhuma comunidade que ofereça
suporte a ele e a única maneira de obter qualquer tipo de auxílio é entrando em
contato diretamente com os desenvolvedores.
O gráfico da Figura 3.6 mostra o volume de mensagens trocadas nas listas
de discussão oficiais das comunidades do Apache OJB e iBATIs e no fórum do
Hibernate durante o mês de novembro de 2005.
5000
4000
3000
2000
1000
0
Apache OJB
Hibernate
iBATIS
76
A comunidade do Hibernate é a mais ativa. Vale ressaltar que o Hibernate é
desenvolvido pelo mesmo grupo responsável pelo desenvolvimento do servidor de
aplicações JBoss (2005), que também oferece suporte e treinamento comercial.
3.4.2.3.
Disponibilidade de Ferramentas Compatíveis
Ferramentas
compatíveis
com
um
framework
ORM
auxiliam
o
desenvolvimento. A ferramenta pode fornecer editores gráficos, automatizar
tarefas repetitivas, etc. Para contabilizar o número de ferramentas compatíveis
com cada framework ORM foi verificada a quantidade de plugins disponíveis para
as plataformas Eclipse e NetBeans, a compatibilidade com as IDEs Java mais
populares (IBM WSAD, Sun Java Studio Enterprise, Borland JBuilder, Oracle
JDeveloper, BEA Workshop e InteliJ IDEA), a compatibilidade com as
ferramentas de produtividade Middlegen e XDoclets além das ferramentas
disponíveis nos web sites dos próprios frameworks.
A Figura 3.7 mostra o número de ferramentas disponíveis compatíveis com
cada framework ORM, conforme pesquisa realizada em novembro de 2005.
15
10
5
0
Apache OJB
Hibernate
iBATIS
JDO
Figura 3.7 – Ferramentas Compatíveis com os Frameworks ORM em 11/2005
A pesquisa realizada em novembro de 2005 demonstra que o Hibernate é o
framework ORM que possui mais ferramentas compatíveis, com o JDO em
segundo lugar.
77
3.4.2.4.
Grau de Aceitação no Mercado
Ao selecionar um framework ORM é necessário realizar uma sondagem no
mercado para saber qual tem sido mais requisitado por empresas. Para obter um
indicativo do grau de aceitação no mercado para um framework, faz-se uma busca
em sites especializados por ofertas de emprego abertas que solicitem
desenvolvedores com habilidades em um determinado framework ORM. A Figura
3.8 mostra o resultado da pesquisa realizado no site Dice.com em dezembro de
2005.
600
500
400
300
200
100
0
Apache OJB
Hibernate
iBATIS
JDO
Figura 3.8 – Ofertas de Emprego Abertas para cada Framework ORM
Fonte: Dice.com, Dezembro de 2005
Segundo a pesquisa o Hibernate é o framework ORM mais solicitado em
ofertas de emprego com o JDO em segundo, com uma pequena vantagem sobre o
iBATIS em terceiro lugar. Este resultado reflete o estado do mercado norteamericano. Para tomar um indicativo do grau de aceitação dos frameworks ORM
no mercado brasileiro apresenta-se uma pesquisa realizada em dezembro de 2005
no
site
nacional
de
(http://www.manageronline.com.br/).
empregos
Manager
Online
78
20
15
10
5
0
Apache OJB
Hibernate
iBATIS
JDO
Figura 3.9 – Ofertas de Emprego Abertas para cada Framework ORM
Fonte: Manager Online, Dezembro de 2005
A pesquisa realizada em dezembro de 2005 revela que há pouco mais que
15 vagas abertas requisitando habilidade com o Hibernate e que não há vagas
abertas requisitando habilidade com OJB, iBATIS e JDO.
3.4.2.5.
Disponibilidade de Profissionais
É preciso considerar a disponibilidade de profissionais habilitados no
mercado para trabalhar com o framework ORM antes de efetuar uma escolha. A
escolha de um framework com poucos profissionais aptos disponíveis no mercado
implica em custos de treinamento mais elevados. Para verificar esta
disponibilidade faz-se uma consulta em sites que hospedam currículos. A Figura
3.10 mostra o resultado da pesquisa realizada em dezembro de 2005 no site
Jobs.net que reflete a realidade do mercado de trabalho norte-americano.
79
1500
1250
1000
750
500
250
0
Apache OJB
Hibernate
iBATIS
JDO
Figura 3.10 – Disponibilidade de Profissionais
Fonte: Jobs.net, Dezembro de 2005
O Hibernate é o framework ORM com mais profissionais aptos no mercado
norte-americano. A Figura 3.11 reflete a realidade do mercado brasileiro, obtido
através de uma busca no site brasileiro APInfo.com, realizada em dezembro de
2005.
300
250
200
150
100
50
0
Apache OJB
Hibernate
iBATIS
JDO
Figura 3.11 - Disponibilidade de Profissionais
Fonte: APInfo.com, Dezembro de 2005
O mercado nacional segue o mesmo padrão do mercado norte-americano
com o Hibernate sendo o framework ORM com mais profissionais habilitados
disponíveis, seguido do JDO.
80
3.4.2.6.
Resultado da Comparação entre Frameworks ORM
A análise mostra que o Hibernate é o framework ORM com mais
documentação disponível, incluindo livros publicados e tutoriais disponíveis na
web, com mais ferramentas compatíveis e com a comunidade mais ativa. Além
disso, a análise mostrou que o Hibernate é o framerwork ORM mais presente
tanto em ofertas de empregos quanto nos currículos de candidatos, nos mercados
norte-americano e brasileiro. Com isto em vista e dado que o Hibernate atende às
necessidades de persistência de dados do AulaNet, ele é incorporado à arquitetura
do AulaNet 3.0.
Enterprise JavaBeans não é incluído nesta análise por dois motivos: porque
ele não é uma solução de mapeamento completo (Fussel,1997) e porque os
critérios técnicos já o haviam descartado. Vale lembrar que o EJB também fornece
outros serviços de infra-estrutura como, por exemplo, segurança, transações
declarativas e exposição de serviços remotos. Na próxima seção é visto como o
Spring, incorporado à arquitetura do AulaNet 3.0, complementa o Hibernate
fornecendo estes serviços.
3.5.
O Framework de Infra-Estrutura Spring
Spring é um framework de infra-estrutura adotado na arquitetura do
AulaNet 3.0 para complementar o Hibernate. Este Spring oferece os serviços de
controle de transações, segurança e exposição de serviços remotos. O Spring
também simplifica o desenvolvimento com o Hibernate através do uso de métodos
template e contribui para um baixo acoplamento entre as classes da aplicação.
O Spring pode ser classificado como um framework de infra-estrutura, pois
provê serviços como gerencia de transações e de segurança além de se integrar
com frameworks ORM, que fornecem serviços de persistência. Spring também é
usualmente chamado de container leve ou “lightweight container” (Walls &
Breidenbach, 2005). O termo container é usado, pois Spring gerencia o ciclo de
vida dos objetos configurados nele, assim como o container EJB. Porém é
considerado um container leve, pois ao contrário do container EJB, ele não é
81
intrusivo e as classes da aplicação tipicamente não possuem dependências com o
Spring.
Spring é um framework dividido em vários módulos usados de acordo com
as necessidades da aplicação. Através do seu módulo de Dependency Injection
(Fowler, 2004), consegue-se um baixo grau de acoplamento entre as classes da
aplicação e através do módulo de programação orientada a aspectos (Aspect
Oriented Programming – AOP) (Jacobson & Ng, 2004), pode-se usar AOP sem
que seja necessário o aprendizado de uma nova linguagem ou a incorporação de
uma nova ferramenta ao projeto. Por fim, o módulo de integração ORM
possibilita a integração do Hibernate ao Spring.
A subseção a seguir descreve Dependency Injection, o principal conceito
por trás do Spring.
3.5.1.
Dependency Injection
O termo Dependency Injection (Fowler, 2004) é usado para classificar um
tipo específico de inversão de controle onde a responsabilidade de configurar
dependências entre classes é assumida por um terceiro objeto. Desta forma,
atinge-se um acoplamento mais fraco entre as classes e por conseqüência maior
reuso. A Figura 3.12 mostra um diagrama de classes com a classe
ConferenceFacade, representando o Façade (Gamma et al., 1995) dos serviços da
Conferência e a classe MessageDAOImpl e sua interface, que implementam o
DAO (Alur et al., 2001) responsável por efetuar as operações de persistência na
base de dados.
82
dao = new MessageDAOImpl();
<<Interface>>
MessageDAO
ConferenceFacade
messageDAO:MessageDAO
ConferenceFacade():void
postMessage(m:Message):void
listMessages():Message[]
createMessage(m:Message):void
updateMessage(m:Message):void
removeMessage(m:Message):void
MessageDAOImpl
<<create>>
Figura 3.12 – Dependências Configuradas sem Dependency Injection
Apesar da classe ConferenceFacade referenciar a interface MessageDAO,
ela é dependente da implementação da interface pois precisa instanciá-la para
poder usá-la. Através de Dependency Injection, um terceiro objeto denominado
Montador (Assembler) é inserido. Este objeto é responsável por instanciar e
configurar as dependências das classes relacionadas. A Figura 3.13 exemplifica o
mesmo modelo da Figura 3.12, mas desta vez usando Dependency Injection.
this.dao = dao;
<<Interface>>
MessageDAO
ConferenceFacade
dao:MessageDAO
ConferenceFacade():void
setDAO(dao:MessageDAO):void
<<create and set>>
MessageDAOImpl
Assembler
<<create>>
Figura 3.13 - Dependências Configuradas com Dependency Injection
83
Com a introdução do objeto Montador a classe ConferenceFacade passa a
depender apenas da interface MessageDAO. O montador é responsável por
instanciar a implementação adequada da interface e configurar a dependência da
classe ConferenceFacade.
Spring e frameworks similares exercem a função do montador no
Dependency Injection e como as classes relacionadas dependem apenas das
interfaces, o Spring pode passar Decorators ou Proxys (Gamma et al., 1995)
acrescentando funcionalidades de infra-estrutura.
3.5.2.
Dependency Injection com Spring
Para melhor compreensão do Spring esta seção apresenta um exemplo que
ilustra o funcionamento do seu módulo de Dependency Injection. Neste exemplo é
implementado o modelo de classes apresentado na Figura 3.14. Nas seções
seguintes, este exemplo será incrementado através da ilustração do uso de serviços
de infra-estrutura com o Spring.
84
Message
-id:Long
-text:String
-date:Date
+getId():Long
+getText():String
+setText(text:String):void
+getDate():Date
+setDate(date:Date):void
ConferenceFacade
<<Interface>>
MessageDAO
dao:MessageDAO
setDAO(dao:MessageDAO):void
MessageDAOImpl
Figura 3.14 – Modelo de Classes do Exemplo do Spring
O modelo da Figura 3.14 corresponde ao modelo da Figura 3.13, com o
Spring funcionando como o montador. A classe Message também é acrescentada
ao modelo para tornar o exemplo mais ilustrativo. O exemplo desta seção se limita
a mostrar o funcionamento básico do módulo de Dependency Injection do Spring.
Nas próximas seções este exemplo é incrementado para exemplificar as outras
funcionalidades de infra-estrutura que o Spring provê. A Listagem 3.1 apresenta a
implementação da classe Message.
85
02:
03:
04:
private Long id;
private String text;
private Date date;
05:
06:
07:
08:
public void setText(String newValue) { text = newValue; }
public String getText() { return text; }
09:
10:
public void setDate(Date newValue) { date = newValue; }
public Date getDate() { return date; }
11: }
Listagem 3.10 – Classe Message.
Como pode ser visto, a classe Message é implementada normalmente sem
nenhuma dependência com o Spring. As propriedades da classe são definidas
entre as linhas 02 e 04 e os métodos de acesso são definidos entre as linhas 05 e
10. A Listagem 3.11 apresenta o código fonte da interface MessageDAO.
12: public interface MessageDAO {
13:
14:
15:
16:
public void createMessage(Message m);
public void updateMessage(Message m);
public void removeMessage(Message m);
public Message[] listMessages();
17: }
Listagem 3.11 – Interface MessageDAO.
A interface MessageDAO também é construída se qualquer acoplamento
com o Spring. A implementação da classe MessageDAOImpl, que implementa a
interface MessageDAO, é apresentada na seção 3.5.4 onde é apresentada a
integração do Hibernate ao Spring. A listagem abaixo apresenta o código da classe
ConferenceFacade.
86
18: public class ConferenceFacade {
19:
private MessageDAO messageDao;
20:
public void setMessageDao(MessageDAO dao) { messageDao = dao; }
21:
22:
23:
public void postMessage(Message m) {
messageDao.createMessage(m);
}
24: public Message listMessages() {
25:
return messageDao.listMessages();
26: }
27: }
Listagem 3.12 – Classe ConferenceFacade.
A variável que armazena a dependência com a interface MessageDAO é
declarada na linha 19. A linha 20 explicita o método de acesso usado para
configurar a dependência. O método de envio de mensagens é declarado no trecho
entre a linha 21 e a linha 23 enquanto que o método que lista as mensagens da
conferência é declarado entre as linhas 24 e 26. Os métodos de negócio nos
Façades apenas delegam as chamadas recebidas para o DAO configurado. Um
exemplo mais realista envolveria várias chamadas de métodos para um ou mais
DAOs.
A dependência entre a classe ConferenceMessage e a interface
MessageDAO deve ser configurada no arquivo de configuração do Spring para
que este atue como o montador. A Listagem 3.13 apresenta este arquivo de
configuração do Spring, que por padrão tem o nome applicationContext.xml.
87
28: <?xml version="1.0" encoding="UTF-8"?>
29: <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
30:
"http://www.springframework.org/dtd/spring-beans.dtd">
31: <beans>
32:
33:
34:
<bean id="messageDAO"
class="MessageDAOImpl">
</bean>
35:
36:
37:
38:
39:
40:
<bean id="conferenceFacade"
class="ConferenceFacade">
<property name="messageDao">
<ref local="messageDAO"/>
</property>
</bean>
41: </beans>
Listagem 3.13 – Arquivo de Configuração do Spring
O trecho entre as linhas 32 e 34 define o bean messageDAO. O id, definido
na linha 32, identifica unicamente este bean no contexto da aplicação Spring. A
propriedade class, definida na linha 33, especifica a classe do bean.
O trecho entre as linhas 35 e 40 declaram o bean conferenceFacade. A
dependência com o bean messageDAO é configurada no trecho entre as linhas 37
e 39. Na linha 37 é descrito que a propriedade que armazena a dependência se
chama messageDao e na linha 38 é descrito que esta propriedade recebe o bean
messageDAO, definido anteriormente no mesmo arquivo.
Os beans definidos no arquivo de configuração do Spring ficam acessíveis
pela interface org.springframework.context.ApplicationContext. Há varias formas
de iniciar o contexto do Spring. A mais comum em aplicações web como o
AulaNet é através de um tratador de eventos executado automaticamente quando a
aplicação é iniciada no servidor de aplicações. Para configurar este tratador de
eventos, é preciso configurar o arquivo descritor da aplicação web.xml conforme
o exemplo da Listagem 3.14.
88
43: <!DOCTYPE web-app PUBLIC
44: "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
45: "http://java.sun.com/dtd/web-app_2_3.dtd">
46: <web-app>
47: <context-param>
48:
<param-name>contextConfigLocation</param-name>
49:
<param-value>/WEB-INF/applicationContext.xml</param-value>
50: </context-param>
51: <listener>
52:
<listener-class>
53:
org.springframework.web.context.ContextLoaderListener
54:
</listener-class>
55: </listener>
56: </web-app>
Listagem 3.14 – Descritor web.xml da Aplicação: Iniciando o Contexto Spring
Na linha 49 o nome do arquivo de configuração do Spring é configurado.
Neste exemplo optou-se pelo nome padrão, mas qualquer nome poderia ser usado
ou mesmo uma lista separada por vírgulas com vários arquivos de configuração. O
trecho entre as linhas 51 e 55 declara o tratador de eventos que inicia o contexto
Spring.
Além de promover o acoplamento fraco entre classes através do módulo de
Dependency Injection, o Spring também fornece serviços de infra-estrutura. A
próxima seção mostra como o Spring integrado ao Hibernate provê serviços
relacionados à persistência dos dados.
3.5.3.
Integração do Hibernate com o Spring
Ao integrar o Hibernate ao Spring, a configuração do Hibernate que antes
era feita separadamente passa a ser feita através do próprio Spring. Desta forma, a
manutenção do arquivo de configuração da aplicação é feita em um só arquivo
com uma sintaxe única. A Listagem 3.15 apresenta o arquivo de configuração do
Spring onde é configurada a integração com o Hibernate.
89
03:
04: <beans>
05: <bean id="dataSource"
06:
class="org.springframework.jndi.JndiObjectFactoryBean">
07:
<property name="jndiName">
08:
<value>java:/comp/env/jdbc/AulaNetDB</value>
09:
</property>
10: </bean>
11: <bean id="sessionFactory"
12:
class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
13:
<property name="dataSource" ref="dataSource"/>
14:
<property name="mappingResources">
15:
<list>
16:
<value>Message.hbm.xml</value>
17:
</list>
18:
</property>
19:
<property name="hibernateProperties">
20:
<props>
21:
<prop key="hibernate.dialect">
22:
net.sf.hibernate.dialect.MySQLDialect
23:
</prop>
24:
<prop key="hibernate.show_sql">false</prop>
25:
</props>
26:
</property>
27: </bean>
28: <bean id="messageDAO" class="MessageDAOImpl">
29:
<property name="sessionFactory" ref="sessionFactory">
30: </bean>
31: <bean id="conferenceFacade" class="ConferenceFacade">
32:
<property name="messageDao" ref="messageDAO"/>
33: </bean>
34: </beans>
Listagem 3.15 – Arquivo de Configuração do Spring: Integração com Hibernate.
O trecho entre as linhas 05 e 10 define a base de dados acessada pelo
Hibernate para persistir os dados. A fábrica de sessões do Hibernate é configurada
no trecho de código entre as linhas 11 e 27. Na linha 13 a fábrica é configurada
com a fonte de dados previamente configurada. Na linhas 16 a fábrica é
configurada para reconhecer os arquivos de mapeamento do Hibernate para a
classe Message. O dialeto é configurada na linha 22 e na linha 24 a opção de log
dos comandos SQL gerados é desabilitada. O bean messageDAO é configurado
no trecho entre as linhas 28 e 30. Na linha 29 ele é configurado com a fábrica de
sessões do Hibernate.
90
A classe org.springframework.orm.hibernate.support.HibernateDaoSupport
do Spring provê suporte para a implementação de DAOs usando Hibernate. Esta
classe gerencia o acesso do DAO à fábrica de sessões e possibilita a criação de
instâncias da classe org.springframework.orm.hibernate.HibernateTemplate, que
fornece vários templates que facilitam a execução das tarefas mais usuais com o
Hibernate. A Listagem 3.16 exibe a implementação da classe MessageDAOImpl.
35: public class MessageDAOImpl extends HibernateDaoSupport
36:
implements MessageDAO {
37:
38:
39:
public void createMessage(Message m) {
getHibernateTemplate().save(m);
}
40:
41:
42:
public void updateMessage(Message m) {
getHibernateTemplate().saveOrUpdateCopy(m);
}
43:
44:
45:
public void removeMessage(Message m) {
getHibernateTemplate().delete(category);
}
46: public Message[] listMessages() {
47:
List messages = getHibernateTemplate().find("from Message m");
48: }
49: }
Listagem 3.16 – Classe MessageDAOImpl.
Na linha 35 a classe é declarada estendendo a classe HibernateDaoSupport e
na linha 36 é declarado que a classe implementa a interface do MessageDAO. O
método getHibernateTemplate retorna instâncias da classe HibernateTemplate
sobre a qual as operações de criação (linha 38), atualização (linha 41), remoção
(linha 44) e busca (linha 47) são executadas.
O código resultante é consideravelmente menor do que o listado na seção
3.4.1.1., pois a classe HibernateTemplate do Spring se responsabiliza por abrir e
fechar sessões além de efetuar o tratamento de erros, convertendo possíveis
exceções em outras que não exigem tratamento. O código também não apresenta
marcação de transações, que são feitas declarativamente e são apresentadas na
próxima seção.
91
3.5.4.
Transações Declarativas com Spring
Spring possibilita o uso de transações declarativas que são descritas no
arquivo de configuração sem que seja preciso alterar o código fonte. O controle
das transações é realizado através de um gerenciador de transações. Há
implementações do gerenciador para a API JDBC, para os frameworks ORM
Hibernate, OJB, JDO, iBATIs e para a API JTA, que deve ser usada quando for
preciso controlar transações entre bancos de dados distintos.
Configurado o gerenciador de transações, é preciso especificar a política de
transação para os métodos das classes envolvidas. A política envolve um ou mais
dos seguintes atributos: escopo de propagação da transação, nível de isolamento,
dicas de somente leitura, tempo limite da transação e tolerância a erros.
O escopo de propagação da transação especifica o comportamento da
transação quando um método que participa de uma transação chama outro. Spring
possibilita que os seguintes valores sejam configurados para o escopo de
propagação da transação: PROPAGATION_MANDATORY, uma exceção é
lançada se um método marcado com este atributo é chamado fora de um contexto
de transação; PROPAGATION_NESTED, um método marcado com este atributo
deve
sempre
ser
executado
em
um
novo
contexto
de
transação;
PROPAGATION_NEVER, uma exceção é levantada se um método marcado com
este
atributo
é
chamado
em
um
contexto
de
transação;
PROPAGATION_NOT_SUPPORTED, indica que o método marcado com este
atributo
é
executado
fora
de
um
contexto
transacional
sempre;
PROPAGATION_REQUIRED, um método marcado com este atributo é sempre
executado dentro de uma transação, ou seja, se este método é chamado dentro de
uma transação, ele participa dela e no caso contrário é criada uma nova transação;
PROPAGATION_REQUIRES_NEW indica que o método sempre é executado
em seu próprio contexto de transação e PROPAGATION_SUPPORTS indica que
um método só roda em um contexto de transação se ele for chamado dentro de
um.
O nível de isolamento da transação especifica o comportamento entre
transações concorrentes que podem levar a problemas de “leituras sujas”, quando
uma transação lê um dado alterado por outra transação ainda não confirmada,
92
“leituras não repetitivas”, quando uma transação realiza uma mesma consulta duas
vezes e obtém resultados diferentes e “leituras fantasmas”, quando uma transação
realiza uma consulta uma vez, obtém um número determinado de linhas e
repetindo a consulta obtém um número diferente de linhas. Quanto maior o nível
de isolamento menor o desempenho da transação. Spring possibilita o uso de
cinco níveis de isolamento: ISOLATION_DEFAULT é usado o nível de
isolamento padrão da base de dados; ISOLATION_READ_UNCOMMITTED,
que
pode
resultar
em
leituras
ISOLATION_READ_COMMITTED
sujas,
que
não
repetíveis
evita
e
leituras
fantasmas.
sujas;
ISOLATION_REPEATEBLE_READ que evita leituras sujas e não repetíveis e
ISOLATION_SERIALIZABLE que evita todos os problemas de concorrência
listados anteriormente.
Dicas de somente leitura podem ser acrescentadas à política de transação
possibilitando um melhor desempenho em consultas que recuperam dados apenas
para leitura e o tempo limite da transação é usado para evitar que uma transação
espere infinitamente para ser concluída. A tolerância a erros pode ser configurada
de forma que a transação não seja abortada quando uma determinada exceção
ocorrer. A Listagem 3.17 apresenta o arquivo de configuração onde o gerenciador
de transação e os dados da política de transação são configurados.
93
03:
04: <beans>
05:
06:
07:
08:
09:
10:
11:
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">

</bean>
<bean id="sessionFactory"
class="org.springframework.orm.hibernate.LocalSessionFactoryBean">

</bean>
12:
13:
14:
15:
<bean id="txManager"
class="org.springframework.orm.hibernate.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
16:
17:
18:
19:
<bean id="messageDAOTarget"
<property name="sessionFactory" ref="sessionFactory">
</bean>
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
<bean id="messageDAO"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager" ref="txManager"/>
<property name="target" ref="messageDAOTarget"/>
<property name="proxyInterfaces">
<value>MessageDAO</value>
</property>
<property name="transactionAttributes">
<props>
<prop key="list*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
34: <bean id="conferenceFacade"
35:
class="ConferenceFacade">
36:
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
94
ConferenceFacade pode usar o Proxy da mesma forma que usaria a
implementação
concreta.
Na
linha
29
a
política
de
transação
PROPAGATION_REQUIRED com a dica de somente leitura para todos os
métodos começando com “list” e na linha 30 a política de transação
PROPAGATION_REQUIRED é especificada para os outros métodos.
O uso de transações declarativas resulta em um código mais limpo e com
um maior grau de reuso já que classes podem ter seu comportamento transacional
modificado sem que seja necessário mudar o código. Na próxima seção é
apresentado outro serviço de infra-estrutura provido pelo Spring: gerenciamento
de segurança.
3.5.5.
Gerenciamento de Segurança com Spring
O módulo de programação orientada a aspectos do Spring possibilita que o
desenvolvedor crie seus próprios aspectos, porém há vários aspectos que podem
ser usados em situações corriqueiras. Dentre eles, há o aspecto que possibilita o
uso de segurança declarativa onde se pode restringir o acesso aos métodos de uma
classe a determinados usuários.
Para que o Spring possa prover segurança declarativa é preciso que sejam
configurados um gerenciador de autenticação e um gerenciador de controle de
acesso. O gerenciador de autenticação é responsável por autenticar que o usuário é
quem diz ser. Tipicamente esta checagem é feita através de um par identificador –
senha. O gerenciador de controle de acesso é responsável pela autorização, ou
seja, ele decide se o usuário autenticado tem permissão para executar a operação.
O
gerenciador
de
autenticação
implementa
a
interface
org.acegisecurity.AuthenticationManager. O Spring possui uma implementação
desta interface chamada gerenciador de provedores (ProviderManager) cuja
função é realizar autenticação em diversos “provedores de autenticação”. Há
diversos tipos de provedores que podem ser usados para autenticar um usuário em
uma base de dados, usando um serviço remoto de autenticação, um servidor
LDAP, etc.
O gerenciador de controle de acesso é responsável por contabilizar os votos
dos org.acegisecurity.vote.AccessDecisionVoter e tomar a decisão se o acesso é
95
garantido ou negado. Um AccesDecisionVoter é uma classe que vota se o acesso a
um recurso é garantido, negado ou opcionalmente pode se abster da votação.
Exemplo: o RoleVoter vota para garantir acesso sempre que o usuário possuir um
papel com o qual ele está configurado. Há 3 implementações do gerenciador de
controle de acesso disponíveis no Spring: o AffirmativeBased, que garante acesso
se houver pelo menos um voto a favor, ConsensusBased que garante acesso
apenas se todos votarem a favor e UnanimousBased que garante acesso se não
houver votos contra.
A Listagem 3.18 mostra o arquivo de configuração do Spring modificado
para prover segurança declarativa para a classe MessageDAOImpl.
96
01: <beans>
02: 
03: <bean id="conferenceFacadeTarget" class="ConferenceFacade">
04:
05: </bean>
06: <bean id="messageDAOTarget"
07:
08:
<property name="sessionFactory" ref="sessionFactory"/>
09: </bean>
10: <bean id="messageDAO"
11:
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
12:
<property name="interceptorNames">
13:
<list><value>securityInterceptor</value></list>
14:
</property>
15:
<property name="beanNames">
16:
<list><value>messageDAOTarget</value></list>
17:
</property>
18: </bean>
19: <bean id='securityInterceptor'
20:
class='net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor'>
21:
<property name='authenticationManager' ref='authenticationManager'/>
22:
<property name='accessDecisionManager' ref='accessDecisionManager'/>
23:
<property name='objectDefinitionSource'>
24:
<value>
25:
MessageDAO.createMessage=ROLE_APPRENTICE,ROLE_MEDIATOR
26:
MessageDAO.updateMessage=ROLE_MEDIATOR
27:
MessageDAO.removeMessage=ROLE_MEDIATOR
28:
MessageDAO.list*=ROLE_APPRENTICE,ROLE_MEDIATOR
29:
</value>
30:
</property>
31: </bean>
32: <bean id='authenticationManager'
33:
class='net.sf.acegisecurity.providers.ProviderManager'>
34:
<property name='providers'>
35:
<list><ref bean='authenticationProvider'/></list>
36:
</property>
37: </bean>
38: <bean id='authenticationProvider'
39:
class='net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider'>
40:
<property name='authenticationDao' ref='memoryAuth'/>
41: </bean>
42: <bean id='authenticationDao'
43:
class='net.sf.acegisecurity.providers.dao.memory.InMemoryDaoImpl'>
44:
<property name='userMap'>
45:
<value>
46:
paulo=123456,ROLE_APPRENTICE
47:
mauro=abacate,ROLE_MEDIATOR
48:
</value>
49:
</property>
50: </bean>
51: <bean id='accessDecisionManager'
52:
class='net.sf.acegisecurity.vote.AffirmativeBased'>
53:
<property name='decisionVoters'>
54:
<list><ref bean='roleVoter'/></list>
55:
</property>
56: </bean>
57: <bean id='roleVoter' class='net.sf.acegisecurity.vote.RoleVoter'/>
58: </beans>
Listagem 3.18 - Arquivo de Configuração do Spring: Segurança Declarativa.
O trecho entre as linhas 10 e 18 define o proxy que acrescenta o aspecto
segurança a classe MessageDAOImpl sendo que o interceptador relativo a este
proxy é configurado na linha 13 e declarado no trecho entre as linhas 19 e 31. O
97
gerenciador de autenticação é configurado na linha 21 e o gerenciador de controle
de acesso na linha 22.
As linhas 25 e 28 indicam que os métodos de criação e listagem de
mensagens estão disponíveis tanto para aprendizes quanto para mediadores. Já as
linhas 26 e 27 indicam que apenas mediadores podem apagar ou atualizar
mensagens. O trecho entre as linhas 32 e 50 referem-se à configuração do
gerenciador de autenticação e o trecho entre as linhas 51 e 56 se referem à
configuração do gerenciador de controle de acesso.
O framework Spring possibilita um serviço de segurança declarativa para
POJOs, de forma similar ao dos EJBs. Este framework fornece ainda meios de
expor serviços remotamente, como é visto na próxima seção.
3.5.6.
Exposição de Serviços Remotos com Spring
Eventualmente é necessário expor as funcionalidades da camada de negócio
de uma aplicação remotamente para outras aplicações e para outros clientes,
inclusive clientes móveis. Spring possibilita a exposição de seus beans
remotamente de quatro formas diferentes: através do uso de RMI (RMI-IIOP.
2005), de Hessian/Burlap (Caucho, 2005), do HttpInvoker (Spring, 2005) e de
serviços web JAX-RPC (Singh et al., 2004).
RMI ou Remote Method Invocation é uma tecnologia que possibilita a
chamada a métodos de componentes remotos, também usada no Enterprise
JavaBeans. Sua principal vantagem é que ela é eficiente quando a comunicação é
feita entre duas plataformas Java. Modelos complexos de objetos podem ser
enviados através do mecanismo de serialização da plataforma Java. Sua principal
desvantagem é que ela usa portas arbitrárias para se comunicar, o que exige
esforço extra de configuração em firewalls, e não possibilita a comunicação de
Java com outras plataformas.
Hessian e Burlap são protocolos desenvolvidos pelo grupo Caucho (2005)
que possibilitam a comunicação remota entre serviços. Ao contrário do RMI,
Hessian e Burlap são construídos sobre o HTTP e, portanto não costumam
demandar configuração extra em firewall. Além disso, Hessian/Burlap possibilita
a comunicação entre as plataformas Java, PHP, Python, C++ e C#. Hessian utiliza
98
um protocolo binário, ideal quando a largura da banda é limitada e Burlap utiliza
um protocolo baseado em XML, ideal quando é preciso que as mensagens
trocadas sejam lidas por pessoas. Estes dois protocolos usam técnicas próprias
para enviar objetos pela rede que podem ser ineficientes quando se usa um modelo
complexo de classes.
O HttpInvoker é um protocolo desenvolvido exclusivamente para o Spring e
soluciona este problema. Assim como Hessian/Burlap ele usa HTTP e, portanto
não demanda configurações extras de firewall. Assim como o RMI, ele usa a
tecnologia de objetos serializáveis da plataforma Java, que é capaz de enviar
modelos complexos de objetos pela rede. HttpInvoker é a opção ideal quando é
preciso integrar duas aplicações que usam o framework Spring pela internet.
A tecnologia de serviços web possibilita a chamada de métodos remotos
através da troca de arquivos XML, a descoberta automática de serviços dentre
outras vantagens. Esta tecnologia é executada sobre o HTTP então firewalls não
costumam ser um empecilho e, como utiliza um padrão bem conhecido, é viável
realizar a comunicação entre diversas plataformas. Por outro lado, das quatro
tecnologias para exposição de serviços remotos, é a mais pesada e sua
performance pode não ser adequada em alguns cenários.
Spring possibilita que serviços sejam expostos sem que seja necessário
alterar o código fonte da aplicação. Para expor um serviço usando RMI, é preciso
configurar o Proxy adequado no arquivo de configuração. Para expor um serviço
com Hessian/Burlap ou HttpInvoker, além de configurar o Proxy no arquivo de
configuração é preciso declarar um servlet que trata as conexões HTTP. A
exposição de serviços como serviços web é mais trabalhosa, pois envolve também
a criação do arquivo descritor do serviço WSDL.
Para fins de demonstração, a Listagem 3.19 apresenta o arquivo de
configuração do Spring onde o serviço Conferência é exposto utilizando a
tecnologia RMI, a mesma usada pelo Enterprise JavaBeans.
99
01: <beans>
02: 
03:
04:
05:
<bean id="conferenceFacade" class="ConferenceFacadeImpl">
</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).
100
Além disso, o módulo de Dependency Injection promove o acoplamento
fraco entre componentes. Graças a este fraco acoplamento as classes são mais
fáceis de testar unitariamente. As dependências são explicitadas e podem ser
substituídas por mock objects (Mackinnon et al., 2000), objetos que imitam
objetos reais e os substituem em testes.
Finalmente, por ser um framework modular, apenas os módulos que
interessam à aplicação precisam ser selecionados. Desta forma, evita-se
complexidade desnecessária.
3.5.8.
Outros Frameworks Para Dependency Injection
Spring não é o único framework/container leve disponível no mercado. Há o
Avalon (2005), o HiveMind (2005), NanoContainer (2005) e o PicoContainer
(2005). Todos estes frameworks são gratuitos e, possíveis substitutos para o
Spring.
O projeto Avalon foi encerrado em 2004 e transformado no projeto
Excalibur (2005). O projeto PicoContainer provê apenas o suporte essencial para
um framework de Dependency Injection e tem suas funcionalidades estendidas
pelo NanoContainer. O HiveMind é o mais similar ao Spring, provendo também
um módulo de programação orientada a aspectos.
Spring aliado ao Hibernate oferece vários recursos de infra-estrutura. Para
reforçar a escolha do Spring é feita uma análise similar a que é feita com os
frameworks ORM: é verificado a quantidade de documentação disponível, a
disponibilidade de suporte, a disponibilidade de ferramentas compatíveis, o grau
de aceitação no mercado e a disponibilidade de profissionais com habilidades nos
frameworks comparados.
3.5.8.1.
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.
101
O gráfico apresentado na Figura 3.15 mostra o número de livros publicados
para cada um dos frameworks para Dependency Injection segundo uma pesquisa
realizada em dezembro de 2005 no site Amazon.
10
5
0
Excalibur
HiveMind
NanoContainer
PicoContainer
Spring
Figura 3.15 - Livros Publicados Para Cada Framework de Dependency Injection
Fonte: Amazon.com, Dezembro de 2005
Só há livros publicados sobre o Spring. O gráfico exibido na Figura 3.16
mostra o resultado de uma busca por tutorias na ferramenta de busca Google em
março de 2006.
60000
50000
40000
30000
20000
10000
0
Excalibur
HiveMind
NanoContainer PicoContainer
Spring
Figura 3.16 - Artigos e Tutoriais Para Cada Framework de Dependency Injection
Fonte: Google.com, Março de 2006
Há um número tão pequeno de tutoriais disponíveis sobre o NanoContainer,
que não é possível visualizar sua contribuição no gráfico. Os frameworks
102
Excalibur, HiveMid e PicoContainer também possuem um número pequeno de
tutoriais quando comparados com o Spring. Spring é claramente o framework para
Dependency Injection com mais documentação disponível, levando em
consideração os livros publicados e tutoriais disponíveis na web.
3.5.8.2.
É 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.
103
140
120
100
80
60
40
20
0
Excalibur
HiveMind
NanoContainer e
PicoContainer
Spring
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.
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.
104
7
6
5
4
3
2
1
0
Excalibur
HiveMind
NanoContainer
PicoContainer
Spring
Figura 3.18 – Ferramentas Compatíveis com os Frameworks para Dependency Injecton
em 12/2005
Constata-se
que
não
há
ferramentas
que
oferecem
suporte
ao
desenvolvimento com Excalibur, NanoContainer e PicoContainer. Há 1
ferramenta que oferece suporte ao desenvolvimento com HiveMind e 6 que dão
suporte ao desenvolvimento com o Spring.
3.5.8.4.
É 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.
105
400
300
200
100
0
Excalibur
HiveMind
NanoContainer
PicoContainer
Spring
Figura 3.19 – Ofertas de Emprego Abertas para cada Framework para
Dependency Injection. Fonte: Dice.com, Dezembro de 2005
Spring é o framework com mais vagas abertas no mercado de trabalho
norte-americano. Não há vagas abertas exigindo conhecimento com os
Frameworks NanoContainer e PicoContainer. O número de vagas abertas
demandando habilidades com Excalibur (2 vagas) e o HiveMind (1 vaga) e tão
pequeno que não pode ser notada nitidamente no gráfico.
O site Dice.com revela um retrato do mercado norte-americano, mas não
representa necessariamente a realidade do mercado brasileiro. Para verificar se a
realidade do mercado brasileiro é similar, realizou-se uma busca em dezembro de
2005 no site nacional Manager Online (http://www.manageronline.com.br/).
2
1
0
Excalibur
HiveMind
NanoContainer
PicoContainer
Spring
Figura 3.20 - Vagas Abertas para cada Framework de Dependency Injection
Fonte: Manager Online, Dezembro de 2005.
106
A pesquisa revela que só há 1 vaga aberta para o framework Spring segundo
a busca feita no site ManagerOnline. O número consideravelmente pequeno
dificulta qualquer comparação.
3.5.8.5.
Para diminuir gastos com treinamento é importante verificar a
disponibilidade de mão de obra no mercado de trabalho com aptidão a trabalhar
com os frameworks comparados. Para verificar esta disponibilidade faz-se uma
consulta em sites que hospedam currículos. A Figura 3.21 mostra o resultado da
busca realizada em dezembro de 2005 no site Jobs.net que reflete a realidade do
mercado de trabalho norte-americano.
200
150
100
50
0
Excalibur
HiveMind
NanoContainer
PicoContainer
Spring
Figura 3.21 - Disponibilidade de Profissionais em 12/2005
Fonte: Jobs.net.
Há pouco mais que 150 profissionais que se dizem aptos a trabalhar com o
framework Spring em seus currículos. Há um número consideravelmente pequeno
de profissionais aptos a trabalhar com o HiveMind e nenhum profissional apto a
para trabalhar com os outros frameworks. Para validar se a realidade do mercado
norte-americano é compatível com a realidade do mercado brasileiro realizou-se
uma busca no site nacional APInfo.com em dezembro de 2005.
107
40
30
20
10
0
Excalibur
HiveMind
NanoContainer
PicoContainer
Spring
Figura 3.22 - Disponibilidade de Profissionais
Fonte: APInfo.com, Dezembro de 2005.
Segundo a busca no site APInfo só o Spring possui profissionais que se
declaram aptos a trabalhar com o framework em seus currículos.
3.5.8.6.
Resultado da Comparação
Após comparar todos os critérios chega-se a conclusão que Spring é a opção
mais adequada para ser usada na arquitetura do AulaNet 3.0. Todos os outros
frameworks são carentes em vários aspectos. Spring possui farta documentação
disponível, suporte da comunidade e comercial e ferramentas compatíveis que
auxiliam o desenvolvimento. Além disso, Spring tem recebido uma boa aceitação
no mercado (principalmente no norte-americano) e há profissionais aptos a
trabalhar com ele disponíveis.
O EJB novamente não é incluído na análise, pois ele não é um framework
para Dependency Injection e porque ele é descartado na análise técnica ao
considerar suas desvantagens.
3.6.
Conclusão
O objetivo da camada de negócios é implementar a lógica da aplicação,
expondo esta lógica para a camada de apresentação ou para outras aplicações
clientes remotas, por exemplo, clientes móveis. Para cumprir este objetivo, podese optar por um framework de componentes, como o Enterprise JavaBeans ou
108
pode-se criar o próprio framework de componentes a partir de uma arquitetura
com POJOs (Plain Old Java Objects).
EJB traz vantagens relacionadas a aspectos de infra-estrutura tratados por
ele. Dentre estes aspectos os principais são: persistência automática dos beans de
entidade, componentes representando entidades de negócio. A persistência
automática livra o desenvolvedor de escrever código JDBC de baixo nível e
possibilita que a aplicação seja executada em bancos de dados diferentes; controle
de transações declarativo, a demarcação das transações é feita fora do código
fonte, tornando o código mais limpo e incentivando o reuso; gerenciamento de
segurança com demarcações declarativas que assim como a transação declarativa
incentiva o reuso já que componentes podem ter seu acesso controlado sem que
seja necessário alterar o código fonte e exposição de serviços remotos, que
possibilita que aplicações externas acessem o componente.
Contudo, EJB também traz desvantagens. Dentre elas, as principais são: a
grande quantidade de arquivos que precisam ser mantidos para definir um
componente; a dependência com servidores de aplicações compatíveis com EJB
que usualmente são mais caros e mais difíceis de configurar; elevado grau de
intrusão que dificulta a execução de testes unitários em componentes EJB e
restrições de programação impostas pela especificação que impossibilitam a
realização de atividades corriqueiras.
Ao invés de usar EJB, é possível criar um framework de componentes
próprio a partir de uma arquitetura com POJOs, agregando frameworks de infraestrutura que provêm as mesmas vantagens do EJB sem a maior parte das
desvantagens.
Para realizar a persistência de objetos, foi escolhido o Hibernate, um
framework ORM que trata a persistência de objetos em base de dados relacionais.
Ao contrário do EJB que é uma solução de mapeamento médio, Hibernate é uma
solução de mapeamento completo, isto é, possibilita o mapeamento de modelos
complexos envolvendo estruturas de herança de forma transparente, sem que as
classes persistidas precisem estender classes ou implementar interfaces do
framework. Hibernate trata também questões complexas relativas ao conflito de
paradigmas objeto/relacional. Outros frameworks ORM de mapeamento completo
gratuitos disponíveis são: Apache OJB, iBATIs e JDO. Contudo, Hibernate possui
mais documentação disponível, um maior número de ferramentas compatíveis,
109
maior disponibilidade de suporte, melhor aceitação no mercado de trabalho e
maior quantidade de mão de obra disponível.
Sozinho o Hibernate não oferece todos os serviços de infra-estrutura
presentes no EJB, por isto ele deve ser combinado com o framework Spring. Este
último integra-se ao Hibernate provendo também suporte a transações
declarativas, gerenciamento de segurança declarativa e exposição de serviços
remotos. Além disso, através de Dependency Injection, Spring promove o
acoplamento fraco entre classes, facilitando a criação de testes unitários e
incentivando o reuso. Há outros frameworks similares ao Spring, dentre eles o
Excalibur, HiveMind, PicoContainer e o NanoContainer. Porém estes são carentes
em quantidade de documentação disponível, ferramentas compatíveis, suporte da
comunidade ou comercial, grau de aceitação no mercado e quantidade de
profissionais disponíveis aptos a trabalhar com cada um.
O par Hibernate e Spring possibilita a incorporação de serviços de infraestrutura a arquitetura do AulaNet 3.0, possibilitando que o desenvolvedor de
componentes de groupware concentre-se em seu domínio ao invés de se preocupar
com serviços de baixo nível. Por se tratar de uma tecnologia aplicada a POJOs,
classes normais que não seguem nenhuma especificação rígida, pode também ser
aplicada a um framework de componentes desenvolvido para gerar componentes
de groupware. Este capítulo apresentou como um groupware se beneficia de
frameworks de infra-estrutura quando aplicados na camada de negócios. No
próximo capítulo é mostrado como a camada de apresentação também obtem
benefícios da incorporação destes frameworks.
4
A Camada de Apresentação
O objetivo da camada de apresentação em uma aplicação multicamadas é de
expor a lógica de negócios ao usuário e possibilitar a interação do usuário com a
aplicação. Em aplicações baseadas na internet como o AulaNet, esta camada
também costuma ser chamada de camada web.
Neste capítulo são apresentadas vantagens e desafios decorrentes do uso de
interfaces HTML. Logo depois são vistos os benefícios obtidos com a adoção do
padrão de arquitetura Model View Controller (MVC) (Fowler, 2002). São
apresentados e comparados frameworks de infra-estrutura que implementam o
MVC e fornecem recursos para contornar os desafios citados, concluindo a seção
com a escolha de um deles para o AulaNet 3.0.
4.1.
Vantagens e Desafios no Desenvolvimento de Interfaces HTML
HTML é a linguagem usada no desenvolvimento da interface com o usuário
da maior parte das aplicações baseadas em web atualmente. O uso de interfaces
HTML traz vantagens. Segundo Johnson (2002) e (2004) estas a seguir são as
principais:
V1. A aplicação é instalada no servidor. O usuário usa o navegador
instalado em seu computador que funciona como um cliente
universal;
V2. Desacopla o usuário da tecnologia usada no servidor;
V3. Geralmente firewalls são configurados para liberar o trafego de
rede na porta utilizada pelo servidor de páginas HTML, diminuindo
o esforço de configuração;
V4. Impõem restrições de configurações de hardware mais modestas às
máquinas dos usuários já que a maior parte do processamento ocorre
no servidor.
Capitulo 4. A Camada de Apresentação
111
Contudo, o desenvolvimento de aplicações baseadas na internet com
HTML/HTTP impõe uma série de desafios:
D1. A interface de aplicações web muda freqüentemente sem que
necessariamente a lógica de negócios seja alterada. É comum, por
exemplo, que um cliente solicite a EduWeb mudanças no visual do
AulaNet para que ele se identifique com sua marca;
D2. Uma interface HTML é limitada pelo modelo de requisição e
resposta, diferentemente de outras tecnologias de construção de
interface como o Swing (Topley, 1999), usada comumente em
aplicações Java Desktop, onde um componente de interface pode ser
atualizado automaticamente quando ocorre alguma mudança no
modelo;
D3. Interfaces web costumam apresentar marcações complexas como
tabelas aninhadas e extensos trechos de código JavaScript sendo que
apenas uma pequena parte desta marcação se destina a conteúdo
gerado dinamicamente. O código de marcação que constrói o layout
da interface deve ser separado do código que efetua as operações de
negócio de forma a possibilitar a separação em papéis:
desenvolvedor e web designer;
D4. Requisições HTTP carregam apenas parâmetros do tipo String, que
freqüentemente precisam ser convertidos para outros tipos;
D5. Interfaces HTML tornam a validação da entrada do usuário mais
importante, pois a aplicação tem controle limitado sobre o navegador
onde o usuário insere os dados;
D6. HTML oferece um conjunto limitado e não expansível de
componentes de interface;
D7. Garantir que uma aplicação tenha o mesmo visual em todos os
navegadores é custoso, devido as variações na aderência aos padrões
HTML, JavaScript e CSS;
D8. Questões de desempenho e concorrência devem ser consideradas,
pois é impossível prever o número de usuários acessando uma
aplicação web simultaneamente;
D9. Interfaces web são executadas no navegador, ao qual se tem
controle limitado. Por conseqüência, são difíceis de testar e depurar.
112
A divisão da aplicação em camadas, com uma delas destinada a
apresentação e interface com o usuário, contribui para a solução de alguns destes
desafios. Como uma camada só depende de outra imediatamente inferior, a
camada de apresentação pode ser alterada sem que a de negócios sofra alterações
(D1). Além disso, o web designer pode concentrar-se na camada de apresentação
enquanto o programador concentra-se na camada de negócios (D3). Finalmente, a
lógica de negócios não depende da camada web e cada camada pode ser testada,
depurada e otimizada isoladamente (D8 e D9).
Contudo, apenas a divisão em camadas não basta para solucionar estes
desafios. Para que isto ocorra é preciso também que a camada de apresentação
seja limpa, isto é, o fluxo de controle e a chamada dos métodos de negócios são
separados da visão, e magra, ou seja, não deve possuir mais código do que o
necessário para chamar a camada de negócios. Para garantir que seja limpa, usa-se
o padrão de arquitetura Model View Controller (MVC), discutido na próxima
seção. Para garantir que seja magra é importante disciplinar os desenvolvedores e
realizar auditorias periódicas no código.
4.2.
Model View Controller
O padrão de arquitetura Model View Controller (MVC) surgiu pela primeira
vez na década de 70 em um framework desenvolvido por Trygve Reenskaug para
a plataforma Smalltalk (Lalonde, 1994) e desde então tem influenciado a maior
parte dos frameworks voltados para interface com o usuário e a maneira de pensar
o design de interfaces (Fowler, 2002).
O MVC divide os elementos da camada de apresentação em três tipos: o
controlador (controller), encarregado de receber a entrada do usuário, acessar a
camada de negócios para manipular o modelo e selecionar a visão; o modelo
(model), um objeto representando uma parte do domínio e que provê os dados que
a visão vai exibir. É o contrato entre o controlador e a visão; a visão (view),
encarregada de exibir os dados do modelo para o usuário.
113
A Figura 4.1 mostra o fluxo do MVC clássico, usado em aplicações desktop.
Este modelo é adotado em aplicações web com poucas modificações, com é visto
mais adiante.
C
2
3
1
4
M
5
V
Figura 4.1 – MVC clássico (Ramachandran, 2002)
1) A visão notifica o controlador. Ocorre quando um formulário em
uma aplicação web é submetido ou quando um botão é clicado em
uma aplicação desktop, por exemplo.
2) O controlador acessa a lógica de negócios e atualiza o modelo.
Corresponde a chamada de um método do Façade na arquitetura do
AulaNet 3.0.
3) O controlador seleciona a visão mais adequada, passando para ela o
estado do modelo que ela deve exibir. O controlador pode, por
exemplo, selecionar uma visão caso a operação tenha sido bem
sucedida ou outra visão em caso de erro.
4) A visão consulta o estado do modelo e exibe as informações ao
usuário. Por exemplo, a visão exibe as mensagens postadas em uma
conferência.
5) O estado do modelo é alterado. O modelo dispara um evento e a
visão se atualiza. Por exemplo, quando um aprendiz envia uma
mensagem em um debate. Os outros aprendizes têm sua tela
atualizada sem que seja necessário solicitar atualizações ao servidor.
Em aplicações para a internet com interface HTML, como o AulaNet, o
modelo de requisição e resposta (Desafio 2) é um impedimento para que o modelo
atualize a visão. Neste caso, usa-se o MVC modificado que costuma ser chamado
de MVC Web ou de MVC pull, pois a visão “puxa” informações do modelo
114
enquanto que no MVC clássico, ou MVC push, o modelo “empurra” atualizações
para a visão. A Figura 4.2 exibe o fluxo no MVC pull.
C
2
3
1
4
M
V
Figura 4.2 – MVC pull (Johnson, 2002, 2004)
1) A visão notifica o controlador.
2) O controlador acessa a lógica de negócios e atualiza o modelo.
3) O controlador seleciona a visão mais adequada, passando a ela o
modelo que ela irá exibir.
4) A visão consulta o modelo e exibe as informações ao usuário.
A única diferença entre os MVC push e pull é que no segundo o modelo não
atualiza a visão.
Na plataforma J2EE, o modelo costuma ser implementado com JavaBeans,
a visão com páginas JSP e o controlador com servlets. Embora seja possível
implementar uma solução ad hoc que implante o MVC, há vários frameworks que
trazem uma estrutura MVC e tratam alguns dos desafios listados na seção anterior,
dentre eles, são analisados nas seções a seguir três destes frameworks: JavaServer
Faces (JSF, 2005), Struts (2005) e Spring MVC, o módulo MVC do framework
Spring (2005) apresentado no capítulo anterior. Estes frameworks, comumente
chamados de web frameworks, possuem diversas características em comum,
descritas a seguir.
4.3.
Características Comuns a Web Frameworks
Há cerca de 54 frameworks para o desenvolvimento web em plataforma
Java gratuitos disponíveis atualmente (Manageability, 2005). Este número é ainda
maior se contabilizados os frameworks comerciais. Boa parte destes frameworks
implementam o MVC de forma similar e têm características comuns que visam
115
solucionar alguns dos desafios descritos na seção 4.1. Estas características assim
como o comportamento destes frameworks são descritos a seguir.
O framework usualmente traz o controlador do MVC pronto. Este é
implementado através de um servlet que deve ser configurado ao instanciar o
framework. O controlador mapeia requisições em classes da instância que
realizam o padrão de projeto comando (Command) (Gamma et al., 1995). A visão
é programada pela instância, mas o framework fornece componentes que auxiliam
a sua construção. Já o modelo é implementado inteiramente pela instância e não
deve possuir nenhum tipo de dependência com o framework escolhido, já que ele
também é usado em outras camadas.
Ao receber uma requisição o controlador assume o controle da aplicação.
Cabe a ele extrair os parâmetros da requisição, que são do tipo String, convertêlos para tipos mais específicos da aplicação (desafio 4), que podem ser tipos
primitivos mais restritos como inteiros e boleanos ou objetos do modelo, e validálos (desafio 5). Em caso de erro de validação, o controlador exibe novamente a
visão que causou o erro. Componentes fornecidos pelo framework são usados na
visão, para repovoar os campos preenchidos e exibir mensagens sobre os erros
ocorridos.
Quando não ocorre erro de validação, o controlador chama o comando que
aciona a camada de negócios para modificar o modelo. Terminada a operação, o
comando sinaliza para o controlador, através do valor de retorno, por exemplo,
qual visão deve ser exibida e este finaliza a requisição mostrando esta visão.
Para que o controlador extraia os dados da requisição e transforme-os em
tipos específicos da instância, o framework fornece um mecanismo que mapeia os
campos de um formulário a propriedades destes tipos.
Este é o comportamento geral da maioria dos web frameworks disponíveis
atualmente. Cada um deles implementa estas características a sua maneira, além
de oferecer recursos extras.
4.4.
Comparação Técnica entre Web Frameworks
Com tantos web frameworks disponíveis no mercado, uma solução ad hoc
para a camada de apresentação foi descartada. Faz-se necessário escolher 1 dentre
116
os 54 web frameworks disponíveis. Para poder escolher um deles, é preciso
analisá-los e compará-los. Devido ao grande número de opções, sentiu-se a
necessidade de realizar uma comparação mais aprofundada do que as
comparações realizadas no capítulo 3. Contudo, analisar todos estes web
frameworks seria excessivamente custoso e fugiria do escopo deste trabalho. Em
vez disto, foram selecionados três: Struts, Spring MVC e JSF.
Struts foi escolhido para ser analisado, pois como será visto em mais
detalhes na seção 4.5, é o mais popular. Spring MVC foi escolhido porque o
Spring já é usado para a camada de negócios. Usá-lo também para a camada de
apresentação reduziria o esforço de aprendizado e possibilitaria uma melhor
integração entre as camadas de negócios e apresentação. Por fim, JSF foi
escolhido porque é um padrão da Sun Microsystems e define um modelo de
componentes. Estes três frameworks podem ser usados com o Spring e o
Hibernate, de forma que não há problemas decorrentes da integração. Nesta seção,
estes três web frameworks são apresentados seguidos de uma comparação técnica
entre eles.
4.4.1.
Struts
Por ter sido um dos primeiros web frameworks desenvolvidos, o Struts
(2005) também é um dos mais populares entre os desenvolvedores. Contudo, o
surgimento de tantos outros é um indicativo de que o Struts não satisfez
completamente as necessidades das aplicações. Nesta seção é visto como o Struts
implementa as funcionalidades comuns aos web frameworks.
Comandos no Struts são chamados de Ações (Actions), que devem estender
a classe org.apache.struts.action.Action ou uma de suas subclasses. Ações podem
vir acompanhadas de Action Forms que são objetos que representam os dados de
um formulário e que devem estender a classe org.apache.struts.action.ActionForm
ou uma de suas subclasses.
O mapeamento entre requisições e ações é feito através da URL da
requisição. A configuração da URL que chama o servlet controlador do Struts,
inserida no descritor web.xml da instância, deve conter uma parte fixa, que serve
117
para identificar o controlador do Struts, e uma parte variável, que identifica qual
ação será executada.
A Listagem 4.1 exibe um fragmento do descritor da aplicação que registra o
controlador do Struts. O mapeamento realizado na linha 10, “*.do” indica que a
parte fixa é “.do” e a parte variável é o que quer que venha antes.
01: <web-app>
02: <servlet>
03:
<servlet-name>Struts Controller</servlet-name>
04:
<servlet-class>
05:
org.apache.struts.action.ActionServlet
06:
</servlet-class>
07: </servlet>
08: <servlet-mapping>
09:
<servlet-name>Struts Controller</servlet-name>
10:
<url-pattern>*.do</url-pattern>
11: </servlet-mapping>
12: </web-app>
Listagem 4.1 – Declaração do Controlador do Struts na Instancia (web.xml)
Exemplo:
uma
requisição
para
http://aulanet.les.inf.puc-
rio.br/postMessage.do, “http://aulanet.les.inf.puc-rio.br/” identifica o servidor que
trata a requisição, “.do” identifica que o controlador do Struts será executado e
“postMessage” identifica a ação que o controlador irá executar.
Através do arquivo XML de configuração do Struts, que por padrão chamase struts-config.xml, a parte variável da URL é mapeada em ações. A Listagem
4.2 exibe um exemplo deste arquivo.
118
13: <struts-config>
14: <form-beans>
15:
<form-bean name="postMessageForm"
16:
type="br.puc-rio.inf.les.aulanet.PostMessageForm"/>
17: </form-beans>
18: <action-mappings>
19:
<action
20:
path="/postMessage"
21:
type="br.puc-rio.inf.les.aulanet.PostMessageAction"
22:
name="postMessageForm"
23:
scope="request" validate="true"
24:
input="/conference/postMessage.jsp">
25:
<forward
26:
name="success"
27:
path="/conference/postMessageSuccess.jsp"/>
28:
<forward
29:
name="failure"
30:
path="/conference/postMessageFailure.jsp"/>
31:
</action>
32: </action-mappings>
33: </struts-config>
Listagem 4.2 – Descritor struts-config.xml
Entre as linhas 19 e 31 encontra-se a definição de uma ação. Através do
atributo path na linha 20, é indicado ao controlador do Struts que ação deve ser
executada sempre que a parte variável da URL for “postMessage”. O atributo type
na linha 21 identifica a classe que implementa a ação e que é chamada pelo
controlador do Struts. A Listagem 4.3 mostra o exemplo de uma classe de ação.
119
34: public class PostMessageAction extends Action {
35:
36:
37:
public ActionForward execute(ActionMapping mapping,
ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws ServletException {
38:
PostMessageForm formBean = (PostMessageForm) form;
39:
40:
41:
42:
43:
try {
ConferenceFacade facade = new ConferenceFacadeImpl();
facade.postMessage(request.getRemoteUser(),
formBean.getParentId(), formBean.getConferenceId(),
formBean.getCategoryId(), formBean.getMessage());
44:
45:
return mapping.findForward("failure");
46:
}
47:
return mapping.findForward("success");
48: }
49: }
Listagem 4.3 – Ação postMessage
Na linha 38, a ação realiza uma conversão de tipo para o Action Form
especificado na linha 22 do arquivo struts-config.xml (Listagem 4.2). Na linha 41,
o Façade é instanciado. Na linha 41, a ação chama a camada de negócios para
atualizar o modelo. Na linha 47, o controlador é notificado para mostrar a vista de
sucesso ou, caso aconteça algum erro, a vista de fracasso na linha 45. O Action
Form para esta ação, descrito entre as linhas 15 e 16 do descritor strutsconfig.xml, é exibido na Listagem 4.4.
120
50: public class PostMessageForm extends ValidatorForm {
51:
52:
53:
54:
private String parentId;
private String conferenceId;
private String categoryId;
private Message message;
55:
56:
57:
58:
public void setParentId(String newValue) {
parentId = newValue;
}
public String getParentId() { return parentId; }
59:
60:
61:
62:
public void setConferenceId(String newValue) {
conferenceId = newValue;
}
public String getConferenceId() { return conferenceId; }
63:
64:
65:
66:
public void setCategoryId(String newValue) {
categoryId = newValue;
}
public String getCategory() { return categoryId; }
67: public void setMessage(Message newValue) {
68:
message = newValue;
69: }
70: public Message getMessage() { return message; }
71: }
Listagem 4.4 – Action Form da ação postMessage
O Action Form é uma classe que não precisa implementar nenhum método
especial além dos métodos gets e sets que definem propriedades JavaBeans
(2005). Na linha 50 é declarado que este Action Form estende a classe
ValidatorForm, uma subclasse de ActionForm que possibilita o uso de validações
declarativas no Struts.
Usando o esquema de validação do Struts, são executadas validações tanto
no lado do cliente quanto no lado do servidor através de regras declaradas em um
arquivo descritor chamado validation.xml. A validação no lado do cliente é feita
por JavaScript e evita que requisições desnecessárias sejam enviadas. Por outro
lado, o JavaScript do navegador do usuário pode ser desabilitado então esta deve
ser realizada também no lado do servidor, para garantir a integridade dos dados. A
Listagem 4.5 exibe um exemplo de arquivo validation.xml.
121
72: <form-validation>
73: <formset>
74:
<form name="postMessageForm">
75:
<field property="categoryId" depends="required">
76:
<msg name="required" key="postMessage.category.required"/>
77:
<arg0 key="postMessageForm.categoryId"/>
78:
</field>
79:
<field property="conferenceId" depends="required">
80:
<msg name="required" key="postMessage.conference.required"/>
81:
<arg0 key="postMessageForm.conferenceId"/>
82:
</field>
83:
<field property="message.subject" depends="required">
84:
<msg name="required" key="postMessage.message.subject.required"/>
85:
<arg0 key="postMessageForm.message.subject"/>
86:
</field>
87:
<field property="message.text" depends="required">
88:
<msg name="required" key="postMessage.message.text.required"/>
89:
<arg0 key="postMessageForm.message.text"/>
90:
</field>
91:
</form>
92: </form-set>
93: </form-validation>
Listagem 4.5 – Regras de Validação (validation.xml)
A linha 74 declara um conjunto de regras de validação para o Action Form
postMessageForm. Os trechos entre as linhas 75 e 78 definem que o campo
categoryId é requirido. Assim como os trechos entre as linhas 79 e 82, 83 e 86, 87
e 90 fazem o mesmo para os campos confereceId, message.subject e message.text.
Há outras regras de validações não usadas neste exemplo, como por exemplo,
validar a sintaxe de e-mails e URLs, validar se um número pertence a uma
determinar faixa, dentre outras.
O Struts também fornece um conjunto de bibliotecas de tags usadas nas
páginas JSP que compõem a visão. Estas bibliotecas contêm tags que possibilitam
o vínculo de campos de um formulário com atributos dos Action Forms e também
tags especializadas em mostrar erros de validação. A Listagem 4.6 mostra como a
página de envio de mensagens é construída, usando as tags do Struts.
122
094: <%@ taglib uri="http://jakarta.apache.org/struts/tags-html" prefix="html"%>
095: <%@ taglib uri="http://jakarta.apache.org/struts/tags-logic" prefix="logic"%>
096: <%@ taglib uri="http://jakarta.apache.org/struts/tags-bean" prefix="bean"%>
097: <html>
098: <head>
099:
<title>Envio de Mensagem</title>
100:
<html:javascript formName="PostMessageForm"/>
101: </head>
102: <body>
103:
<html:form action="/postMessage" method="POST"
104:
onsubmit="return validatePostMessageForm(this);">
105:
<html:hidden property="conferenceId" value="${param.conferenceId}"/>
106:
<html:hidden property="messageId" value="${param.messageId}"/>
107:
<logic:messagesPresent>
108:
<html:messages id="error">
109:
<bean:write name="error"/>
110:
</html:messages>
111:
</logic:messagesPresent>
112:
Categoria:
113:
<html:select property="categoryId">
114:
<html:option value="1">Questão</html:option>
115:
<html:option value="2">Seminário</html:option>
116:
<html:option value="3">Argumentação</html:option>
117:
</html:select><br>
118:
Assunto:
119:
<html:text property="message.subject" size="83" maxlength="100" /><br>
120:
Mensagem: <br>
121:
<html:textarea property="message.text" cols="65" rows="16" style="wrap" />
122:
</html:form>
123: </body>
124: </html>
Listagem 4.6 – Página de Envio de Mensagens
Entre as linhas 094 e 096 é feita a declaração das bibliotecas de tags do
Struts. Na linha 100 a tag html:javascript gera o código JavaScript responsável
pela validação no lado cliente. Já na linha 103 a tag html:form gera o formulário
que submete a requisição da ação postMessage. É importante notar que na linha
104,
a
propriedade
onsubmit
é
definida
com
o
valor
validatePostMessageForm(this). Se este atributo não for configurado desta forma,
o código de validação no lado cliente é gerado, mas nunca executado.
O trecho de código entre as linhas 107 e 111 geram a lista de erros de
validação. A tag logic:messagesPresent é usada para evitar que uma lista sem itens
seja exibida quando não há erros de validação. A tag html:messages é usada para
123
iterar sobre a lista de erros de validação. Finalmente a tag bean:write, é usada para
escrever a mensagem de erro na página.
Nota-se na listagem 4.6 que cada uma das tags de formulário HTML
(<form>, <input>, etc.) possui uma tag análoga na biblioteca de tags HTML do
Struts. Estas tags são responsáveis por criar o vinculo entre o campo do
formulário e a propriedade do Action Form.
4.4.2.
Spring MVC
O Spring (2005), apresentado no capítulo 3 e que foi escolhido para ser
usado na camada de negócios possui um módulo que implementa o MVC. Desta
forma, é um candidato natural a ser usado também na camada de apresentação.
Os comandos no Spring MVC recebem o mesmo nome do controlador do
Model
View
Controller
e
devem
implementar
a
interface
org.springframework.web.servlet.mvc.Controller. Geralmente não é necessário
implementar esta interface diretamente. O Spring MVC possui classes apropriadas
para situações específicas, como a submissão de um formulário web (classe
SimpleFormController) ou então um conjunto de telas no formato de Wizard
(classe AbstractWizardFormController). Ambas estão localizadas no pacote
org.springframework.web.servlet.mvc.
De forma similar ao Struts, os controladores do Spring MVC podem vir
acompanhados de classes que representam os dados submetidos em um
formulário. Estas classes recebem o nome de Comandos (Commands) no Spring
MVC. Este termo é inadequado, pois remete ao padrão de projeto Comando
(Gamma et al., 1995). Para preservar a clareza do texto, nesta dissertação os
comandos do Spring MVC serão chamados de beans de formulário.
O mapeamento entre requisições e controladores é feito de forma similar ao
Struts. O servlet controlador é associado a uma URL com uma parte fixa e outra
variável. A parte fixa serve para especificar que o servlet controlador do Spring
MVC deve ser executado. A parte variável serve para identificar qual controlador
deve ser executado. A Listagem 4.7 exibe o mapeamento do servlet controlador
no descritor da aplicação web.xml. Nota-se que o mapeamento realizado na linha
124
08, “*.spring”, indica que a parte fixa é “.spring” e a parte variável é o que quer
que venha antes.
01: <web-app>
02: <servlet>
03:
<servlet-name>SpringDispatcher</servlet-name>
04:
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
05: </servlet>
07:
<servlet-name>SpringDispatcher</servlet-name>
08:
<url-pattern>*.spring</url-pattern>
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.
125
11: <beans>
12: <bean id="postMessageController"
13:
class="br.pucrio.inf.les.aulanet.PostMessageController">
14:
<property name="conferenceFacade">
15:
<ref bean="conferenceFacade"/>
16:
</property>
17:
<property name="formView">
18:
<value>/protected/conference/postMessage.jsp</value>
19:
</property>
20:
<property name="successView">
21:
<value>/conference/postMessageSuccess.jsp</value>
22:
</property>
23:
<property name="failureView">
24:
<value>/conference/postMessageFailure.jsp</value>
25:
</property>
26:
<property name="validator">
27:
<bean class="br.pucrio.inf.les.aulanet.PostMessageValidator"/>
28:
</property>
29: </bean>
30: <bean id="urlMapping"
31:
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
32:
<property name="mappings">
33:
<props>
34:
<prop key="/postMessage.spring">postMessageController</prop>
35:
</props>
36:
</property>
37: </bean>
38: </beans>
Listagem 4.8 - Descritor SpringDispatcher-servlet.xml
Este arquivo por padrão chama-se <Nome da Servlet>-servlet.xml, onde
<Nome da Servlet> é o nome da servlet declarado na linha 03 da Listagem 4.7. Na
linha 34 da Listagem 4.8 a requisição “postMessage” é mapeada para o
controlador de nome “postMessageController”, declarado no mesmo arquivo entre
as linhas 12 e 29. Neste exemplo são configuradas cinco propriedades importantes
do controlador: entre as linhas 14 e 16 é configurado o Façade usado para
executar a lógica de negócios. Entre as linhas 17 e 19 é configurado a página de
entrada, ou seja, a tela que origina a requisição. Entre as linhas 20 e 22 é
configurada a página de sucesso, exibida quando a operação é executada
corretamente. Por fim, entre as linhas 23 e 25 é configurada a página de erros,
executada quando ocorre algum problema durante o acesso à camada de negócios.
Entre as linhas 26 e 28 o controlador é mapeado ao seu validador, que será
explicado mais adiante. Vale ressaltar que a sintaxe usada neste descritor é a
mesma dos descritores dos outros módulos do Spring usados na camada de
126
negócios. O controlador associado à requisição postMessage é mostrado na
Listagem 4.9.
39: public class PostMessageController extends SimpleFormController {
40:
41:
private ConferenceFacade confFacade;
private String failureView;
42:
43:
44:
public PostMessageController() {
setCommandClass(Message.class);
}
45:
46:
47:
48:
49:
50:
public void setConferenceFacade(ConferenceFacade newValue) {
confFacade = newValue;
}
public void setFailureView(String newValue) {
failureView = newValue;
}
51:
52:
53:
54:
protected ModelAndView onSubmit(HttpServletRequest request,
HttpServletResponse response, Object command, BindException errors)
throws Exception {
Message message = (Message) command;
55:
56:
57:
58:
59:
60:
61:
62:
63: }
64: }
try {
facade.postMessage(request.getRemoteUser(),
message.getParentId(), message.getConferenceId(),
message.getCategoryId(), message);
return new ModelAndView(failureView);
}
return new ModelAndView(getSuccessView());
Listagem 4.9 – Controlador Associado à Requisição postMessage
Na linha 39 da Listagem 4.9 a classe do controlador estende a classe
SimpleFormController, indicando que este controlador responde à submissão de
um formulário. As linhas 40 e 41 apresentam as propriedades para,
respectivamente, o Façade e a página exibida quando ocorre erro. Os métodos de
acesso para estas propriedades são definidos entre as linhas 45 e 50. Na linha 43, o
bean de formulário Message é associado a este controlador.
Entre as linhas 51 e 63 encontra-se o código do controle que é executado
quando o formulário é submetido. Primeiro, é realizada uma conversão de tipos na
127
linha 54. Depois, o Façade é chamado na linha 56. Diferentemente do Struts, o
Façade é configurado através de Dependency Injection ao invés de ser
instanciado, o que leva a um menor acoplamento entre a camada de apresentação
e a implementação da camada de negócios.
Se a operação for bem sucedida, é retornado um objeto ModelAndView que
encapsula o modelo e a visão apontando para a tela de sucesso (linha 62). Se
ocorrer algum erro durante a execução da lógica de negócios, a tela de erros é
exibida (linha 60).
Diferentemente do Struts, os beans de formulário no Spring MVC não
estendem uma classe do framework. Dessa forma, os beans de formulário não
possuem dependências com o Spring MVC, podendo inclusive ser reusadas
classes do modelo como beans de formulário sempre que for adequado. A
Listagem 4.10 mostra o bean de formulário usado pelo controlador postMessage.
66:
67:
68:
69:
70:
private String message;
private String subject;
71:
72:
public void setParentId(String newValue) { parentId = newValue; }
73:
74:
public void setConferenceId(String newValue) { conferenceId = newValue; }
75:
76:
public void setCategoryId(String newValue) { categoryId = newValue; }
public String getCategory() { return categoryId; }
77:
78:
public void setMessage(String newValue) { message = newValue; }
public String getMessage() { return message; }
79: public void setSubject(String newValue) { subject = newValue; }
80: public String getSubject() { return subject; }
81: }
Listagem 4.10 – Bean de Formulário Associado ao Controlador postMessage
Com relação a validação, quando este capítulo foi escrito em novembro de
2005, o esquema de validação do Spring MVC não se encontrava num estado de
maturidade tão elevado quanto o do Struts. Além de não oferecer validação no
128
lado do servidor, o esquema do Spring MVC não é baseado em regras descritivas,
ou seja, a validação precisa ser programada e associada à classe do controlador.
Atualmente há uma iniciativa para se criar um esquema de validação similar ao do
Struts para o Spring MVC, mas ainda não há previsão de quando haverá uma
versão estável. A Listagem 4.11 mostra a classe de validação para o controlador
postMessage.
82: public class SendMessageValidator implements Validator {
83:
84:
85:
public boolean supports(Class clazz) {
return clazz.equals(Message.class);
}
86:
87:
88:
89:
90:
91:
92:
93:
94:
public void validate(Object command, Errors errors) {
ValidationUtils.rejectIfEmptyOrWhitespace(errors, "categoryId",
"postMessage.categoryId.required", "Category empty.");
ValidationUtils.rejectIfEmptyOrWhitespace(errors, "conferenceId",
"postMessage.conference.required", "Conference empty.");
ValidationUtils.rejectIfEmptyOrWhitespace(errors, "message",
"postMessage.message.required", " Message empty.");
ValidationUtils.rejectIfEmptyOrWhitespace(errors, "subject",
"postMessage.subject.required", "Subject empty.");
95: }
96: }
Listagem 4.11 – Classe de Validação para o Controlador postMessage
Na linha 84 o validador especifica os tipos de beans de formulário que ele
valida, neste caso apenas o bean Message. Nas linhas 87 e 88 é validado se o
campo categoryId é vazio. O mesmo é feito nas linhas 89 e 90 para a propriedade
conferenceId, nas linhas 91 e 92 para a propriedade message e nas linhas 93 e 94
para a propriedade subject.
O Spring MVC também oferece um conjunto de tags usadas para exibir
mensagens de erro de validação na camada de apresentação, mas ao contrário do
Struts, possibilita que sejam usadas as tags do próprio HTML para gerar os
campos de entrada dos formulários. O vínculo entre as propriedades dos beans de
formulário e o formulário é feito com outras tags do Spring MVC. Esta
abordagem deixa as telas da camada de apresentação menos acopladas com o web
129
framework. A Listagem 4.12 exibe o código fonte da página de envio de
mensagens.
097: <%@ taglib uri="http://www.springframework.org/tags" prefix="spring" %>
098: <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
099: <html>
100: <head><title>Envio de Mensagem</title></head>
101: <body>
102:
<form action="sendMessage.spring" method="POST">
103:
<spring:bind path="command.conferenceId">
104:
<input type="hidden" name='<c:out value="${status.expression}"/>'
105:
value='${param.conferenceId}'/>
106:
</spring:bind>
107:
<spring:bind path="command.parentId">
108:
<input type=hidden name='<c:out value="${status.expression}"/>'
109:
value='${param.messageId}'/>
110:
</spring:bind>
111:
<spring:hasBindErrors name="command">
112:
<ul>
113:
<c:forEach items="${errors.allErrors}" var="error">
114:
<li><spring:message
115:
code="${error.code}"
116:
text="${error.defaultMessage}"
117:
arguments="${error.arguments}"/></li>
118:
</c:forEach>
119:
</ul>
120:
</spring:hasBindErrors>
121:
Categoria:
122:
<spring:bind path="command.categoryId">
123:
<select name='<c:out value="${status.expression}"/>'>
124:
<option value="1">Questão</option>
125:
<option value="2">Seminário</option>
126:
</select><br>
127:
</spring:bind>
128:
Assunto:
129:
<spring:bind path="command.subject">
130:
<input type="text" name='<c:out value="${status.expression}"/>'
131:
value='<c:out value="${status.value}"/>'
132:
size="83" maxlength="100"/>
133:
</spring:bind>
134:
Mensagem: <br>
135:
<spring:bind path="command.message">
136:
<textarea name='<c:out value="${status.expression}"/>' rows="15"
137:
cols="60" cols=65 rows=16 wrap>
138:
<c:out value="${status.value}"/>
139:
</textarea>
140:
</spring:bind>
141:
</form>
142:
</body>
143: </html>
Listagem 4.12 - Página de Envio de Mensagem
130
Nota-se o uso constante da tag spring:bind, que é usada para vincular as
propriedades do bean de formulário aos campos do formulário html. Outro ponto
que deve ser observado é o uso das tag spring:hasBindErrors e spring:message
usadas para listar os erros de validação quando estes houverem.
4.4.3.
JavaServer Faces
JavaServer Faces (JSF, 2005) é diferente dos web frameworks apresentados
até então pois além de ser um framework de infra-estrutura, também pode ser
classificado como um framework de componentes, pois define um modelo de
componentes para serem usados na camada de apresentação. Há três tipos
principais de componentes no JSF: componentes de interface, usado para compor
interfaces com o usuário, componentes de conversão de dados, usados para
converter os dados inseridos pelo usuário em tipos da aplicação e componentes de
validação de dados, usados para validar a entrada do usuário. JSF vem com um
conjunto padrão de componentes, que podem ser estendidos.
Os comandos no JSF recebem o nome de backing beans ou managed beans.
Estes não precisam implementar interfaces específicas ou estender classes,
bastando que o método do comando seja público, não receba parâmetros e tenha o
tipo de retorno String. Componentes de interface vinculam hyperlinks ou botões a
ações de comando. Os backing beans contém os dados dos formulários
relacionados de forma que não é necessário criar classes extras, como beans de
formulário ou Action Forms para isto.
O mapeamento entre requisições e controladores é feito através de campos
escondidos em formulários, inseridos automaticamente pelos componentes de
comando. Assim como no Spring MVC e no Struts, as URLs de requisição são
divididas em uma parte fixa e uma parte variável. A parte fixa serve para associar
a URL de requisição ao Servlet controlador do JSF e a parte variável da URL
serve para identificar qual página JSP que contém componentes JSF será
executada. A Listagem 4.13 exibe o mapeamento do servlet controlador no descritor
da aplicação web.xml. Nota-se que o mapeamento realizado na linha 08, “*.jsf”,
indica que a parte fixa é “.jsf” e a parte variável é o que quer que venha antes.
131
01: <web-app>
02: <servlet>
03:
<servlet-name>Faces Servlet</servlet-name>
04:
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
05: </servlet>
07:
<servlet-name>Faces Servlet</servlet-name>
08:
<url-pattern>*.jsf</url-pattern>
10: </web-app>
Listagem 4.13 - Declaração do Controlador do JSF na Instancia (web.xml)
Exemplo: em uma requisição enviada para http://aulanet.les.inf.pucrio.br/postMessage.jsf, “http://aulanet.les.inf.puc-rio.br/” identifica o servidor que
atende a requisição, “.jsf” identifica que o controlador do JSF será executado e
“postMessage” identifica a página JSP com componentes JSF associados
solicitada.
Através do arquivo XML de configuração do JSF são configurados casos de
navegação, backing beans, componentes de validação e de conversão de tipos. A
Listagem 4.14 exibe um exemplo deste arquivo, que tem como nome padrão
faces-config.xml.
132
11: <faces-config>
12: <navigation-rule>
13:
<from-view-id>/conference/postMessage.jsp</from-view-id>
14:
<navigation-case>
15:
<from-outcome>success</from-outcome>
16:
<to-view-id>/conference/postMessageSuccess.jsp</to-view-id>
17:
</navigation-case>
18:
<navigation-case>
19:
<from-outcome>failure</from-outcome>
20:
<to-view-id>/conference/postMessageFailure.jsp</to-view-id>
21:
</navigation-case>
22: </navigation-rule>
23: <managed-bean>
24:
<managed-bean-name>messageController</managed-bean-name>
25:
<managed-bean-class>MessageController</managed-bean-class>
26:
<managed-bean-scope>request</managed-bean-scope>
27:
<managed-property>
28:
<property-name>conferenceId</property-name>
29:
<value>#{param['conferenceId']}</value>
30:
</managed-property>
31:
<managed-property>
32:
<property-name>parentId</property-name>
33:
<value>#{param['parentId']}</value>
34:
</managed-property>
35: </managed-bean>
36: </faces-config>
Listagem 4.14 – Arquivo de Configuração faces-config.xml
Entre as linhas 12 e 22 são declarados dois casos de navegação a partir da
página /conference/postMessage.jsp. O caso entre as linhas 14 e 17 é executado
quando a operação é executada com sucesso enquanto que o caso entre as linhas
18 e 21 é executado quando ocorre algum erro durante a execução da operação.
O backing bean responsável pelo comando postMessage é declarado entre
as linhas 23 e 37. Na linha 24 o nome do backing bean é definido, enquanto que
na linha 25 é configurada a classe. Nota-se também que este bean tem duas
propriedades gerenciadas (managed properties) definidas entre as linhas 27 e 34.
O JSF se encarrega de configurar estas propriedades em tempo de execução, antes
de executar o método do backing bean. A Listagem 4.15 exibe o código fonte
deste backing bean.
133
37: public class MessageController {
38:
39:
40:
41:
private Message message;
42:
43:
44:
45:
46:
47:
48:
49:
public void setParentId(String newValue) { parentId = newValue; }
public void setConferenceId(String newValue) { conferenceId = newValue; }
public void setCategoryId(String newValue) { categoryId = newValue; }
public String getCategoryId() { return categoryId; }
public void setMessage(Message message) { message = newValue; }
public Message getMessage() { return message; }
50:
public String postMessage() {
51:
52:
53:
54:
55:
56:
57:
58:
59:
60: }
61: }
try {
ConferenceFacade facade = new ConferenceFacadeImpl();
FacesContext ctx = FacesContext.getCurrentInstance();
String author = ctx.getExternalContext().getRemoteUser();
facade.postMessage(author, parentId, conferenceId, categoryId, message);
return "failure";
}
return "success";
Listagem 4.15 – Backing Bean do Comando postMessage
Entre as linhas 38 e 41 são declaradas as propriedades parentId,
conferenceId, categoryId e message e entre as linhas 42 e 49 são declarados os
métodos de acesso a estas propriedades.
O método que executa o comando é declarado entre as linhas 50 e 60. Na
linha 52, a referência para o Façade que acessa a camada de negócios é obtida. Na
linha 54, é recuperado o nome de usuário logado a partir do contexto Faces
recuperado na linha 53. A lógica de negócios é executada na linha 55 e, caso haja
sucesso, o comando aciona o caso de navegação “success” (linha 59). Se houver
algum erro na execução da lógica de negócios, a tela de erro é acionada (linha 57).
Apesar de não precisar implementar interfaces especificas do JSF, o backing
bean não está totalmente desacoplado do framework. Na linha 53, o contexto
134
faces (FacesContext) é recuperado para posteriormente o nome do usuário logado
ser recuperado.
A declaração das regras de validação assim como o vínculo entre campos de
formulário e propriedades do backing bean, e entre os componentes de comando e
os métodos de comando nos backing beans são feitas no arquivo JSP. A Listagem
4.16 mostra a página JSP usada no comando postMessage.
62: <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
63: <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
64: <f:view>
65: <html>
66:
<head>
67:
<title>Envio de Mensagem</title>
68:
</head>
69:
<body>
70:
<h:form>
71:
<h:inputHidden id="conferenceId" value="#{param['conferenceId']}"/>
72:
<h:inputHidden id="parentId" value="#{param['parentId']}"/>
73:
<h:messages/><br>
74:
Categoria:
75:
<h:selectOneListbox value="#{messageController.categoryId}"
76:
required="true">
77:
<f:selectItem itemLabel="Questão" itemValue="1"/>
78:
<f:selectItem itemLabel="Seminário" itemValue="2"/>
79:
<f:selectItem itemLabel="Argumentação" itemValue="3"/>
80:
</h:selectOneListbox><br>
81:
Assunto:
82:
<h:inputText value="#{messageController.message.subject}"
83:
size="83" maxlength="100" required="true">
84:
<f:validateLength minimum="10"/>
85:
</h:inputText><br>
86:
Mensagem: <br>
87:
<h:inputTextarea value="#{messageController.message.text}"
rows="15" cols="60" cols="65" rows="16"
88:
required="true"/>
89:
</h:form>
90:
</body>
91: </html>
92: </f:view>
Listagem 4.16 – Página de Envio De Mensagens (JSF)
As bibliotecas de tags definidas nas linhas 62 e 63 possibilitam que JSF seja
usado em conjunto com JSP. A tag f:view (linha 64) serve para demarcar árvore
de componentes JSF. A tag h:form (linha 70) é usada para definir um formulário
135
de dados. As linhas 71 e 72 inserem campos escondidos, com as propriedades
conferenceId e parentId. Expressões delimitadas por “#{“ e “}” demarcam o uso
da linguagem de expressões do JSF e servem para criar vínculos. No caso destas
expressões, o uso de “#{param[’nome-do-parametro’]}” indica o vínculo do valor
dos componentes com as propriedade de requisição indicadas pelo nome “nomedo-parametro”.
O item entre as linhas 75 e 80 delimita um componente do tipo lista onde
apenas um item pode ser selecionado. O atributo value na linha 75 vincula o valor
do
item
selecionado
a
propriedade
categoryId
do
backing
bean
messageController. Ainda na linha 75, o atributo required=”true” demarca que o
atributo é requerido, gerando regras de validação automaticamente. JSF ainda não
gera regras de validação do lado do cliente, mas há como integrar o módulo de
validação no lado cliente do Struts ao JSF, conforme descrito em Geary &
Horstmann (2005). A linha 84 indica uma validação de tamanho mínimo,
indicando que o campo associado a esta só será válido se tiver um tamanho
mínimo de 10 caracteres.
JSF possibilita que novos componentes sejam criados caso os componentes
padrão não satisfaçam as necessidades da aplicação. Projetos como o MyFaces
(2005) e WebGalileo Faces (WebGalileo, 2005) disponibilizam componentes,
como por exemplo, um que possibilita que o usuário selecione uma data em um
calendário (Figura 4.3) ou um que apresenta um editor de textos HTML estilo
What You See Is What You Get (Figura 4.4), que já foi solicitado por diversos
usuários do AulaNet (Barreto et al., 2005).
Figura 4.3 - Calendário
Figura 4.4 - Editor HTML
Além disso, JSF foi desenvolvido visando à integração com ferramentas de
produtividade. Consequentemente há uma boa quantidade de ferramentas
136
compatíveis com JSF no mercado conforme descrito na seção 4.5.3, apesar deste
ser o mais novo dos 3 web frameworks analisados.
4.4.4.
Resultado da Análise Técnica
Após analisar tecnicamente os web frameworks Struts, Spring MVC e JSF
percebe-se que cada um tem suas vantagens e desvantagens.
Struts é o mais antigo dos três e, portanto, o mais maduro. Seu módulo de
validação baseado em regras capaz de validar dados tanto no lado do cliente
quanto no servidor é sua principal vantagem. Entretanto, o Struts força um grau
elevado de acoplamento entre a camada de apresentação e o web framework
usado ao impor que tanto Actions quanto Action Forms estendam classes próprias
do frameworks. Além disso, o Struts exige que sejam criadas classes específicas
para representar os dados inseridos em formulários, mesmo quando uma classe do
modelo é mais apropriada.
Spring MVC por outro lado apresenta um fraco grau de acoplamento. Os
beans de formulário não precisam estender classes ou implementar classes do
framework, podendo ser aproveitadas classes do modelo para esta função. Spring
MVC também fornece a melhor solução para integração entre os controladores na
camada de apresentação e os Façades na camada de negócios, através de
Dependency Injection (Fowler, 2004). Contudo, seu mecanismo de validação é
sua principal desvantagem, sendo o pior dos 3 analisados.
JSF se difere dos três por ser um framework de componentes. JSF não
possui um grau de acoplamento tão forte quanto o Struts e nem tão fraco quanto o
o Spring MVC. Seu módulo de validação é baseado em regras, como o do Struts,
mas não fornece validação do lado do cliente.
O que torna JSF a escolha técnica mais adequada ao AulaNet 3.0 é o fato
dele ser um framework de componentes. JSF possibilita que componentes de
interfaces sejam criados e aproveitados (desafio 6). Além disso, como foi visto em
seções anteriores, já há um mercado de componentes compostos por projetos
gratuitos (por exemplo, MyFaces (2005) e WebGalileo Faces (WebGalileo, 2005))
e comerciais (por exemplo, WebCharts (2005)) que complementam o conjunto
padrão de componentes JSF, diminuindo a necessidade de criar novos.
137
JSF apresenta um custo inicial de adoção superior aos dos outros web
frameworks analisados, pois exige que componentes sejam criados. Este custo é
inerente à abordagem de desenvolvimento baseado a componentes e é reduzido à
medida que o projeto evolui até atingir massa crítica, quando há componentes de
variedade suficiente e quando a necessidade de criar um novo componente
diminui (Szyperski, 1997). Como o AulaNet encontra-se em constante
desenvolvimento espera-se que após a massa crítica ser atingida o custo do
desenvolvimento com JSF seja menor do que com os outros web frameworks.
Apesar de não gerar validação no lado do cliente, principal vantagem do
Struts, há maneiras de usar este esquema de validação junto com o JSF caso seja
necessário (Geary & Horstmann, 2005). Quanto ao seu grau de acoplamento
superior ao do Spring MVC não é um motivo suficientemente forte para
abandoná-lo tendo em vista suas outras vantagens.
Somente a comparação técnica entre frameworks não é suficiente para tomar
a decisão sobre qual dos web frameworks é mais adequado às necessidades de um
projeto. No caso do AulaNet, como foi visto anteriormente, deve se levar em
conta que ele é desenvolvido por alunos de graduação, mestrado e doutorado no
Laboratório de Engenharia de Software da PUC-Rio e que EduWeb realiza
customizações para seus clientes. Na próxima seção são analisados os seguintes
fatores não-técnicos: como, por exemplo, a documentação disponível sobre cada
web framework e a quantidade de profissionais habilitados a trabalhar com este
web framework. Ao considerar estes fatores, evita-se a escolha de um web
framework com custo de adoção proibitivo para o LES ou para a EduWeb.
4.5.
Comparação Não-Técnica entre Web Frameworks
Além de analisar como os web frameworks funcionam tecnicamente, a
escolha do web framework mais adequado para um projeto deve levar em
considerações outros fatores, como: quantidade de documentação disponível,
disponibilidade de suporte (seja um suporte oficial ou da comunidade que usa o
framework), disponibilidade de ferramentas compatíveis, grau de aceitação de
mercado e disponibilidade de profissionais com habilidades nos frameworks.
Raible (2005) apresenta dados importantes que ajudarão esta análise, comparando
138
os frameworks que foram analisados tecnicamente na seção 4.4 e mais outros 3
web frameworks: Cocoon (2005), WebWork (2005) e Tapestry (2005).
Para uma análise mais precisa dos dados, foi necessário realizar
comunicação pessoal com o autor que gentilmente cedeu os dados de sua
pesquisa. Além disso, Matt Raible forneceu atualizações nos dados referentes à
disponibilidade de suporte. As transcrições dos e-mails trocados com Raible estão
disponíveis no apêndice A.
4.5.1.
Para medir a quantidade da documentação disponível faz-se uma pesquisa
na quantidade de livros publicados e de tutoriais escritos sobre cada web
framework. O resultado da pesquisa realizada por Raible (2005) no verão
(hemisfério norte) de 2005 é apresentado na Figura 4.5 e Figura 4.6.
35
30
25
20
15
10
5
0
Cocoon
Struts
Spring MVC WebWork
JSF
Tapestry
Figura 4.5 - Número de Livros Publicados
Fonte: Amazon.com (Raible, 2005), Verão de 2005 (hemisfério norte)
Há mais livros publicados sobre o Struts, com JSF vindo em segundo lugar
e Spring MVC em terceiro. A Figura 4.6 mostra o número de tutoriais disponíveis
na web para cada web framework segundo a pesquisa realizada no Google por
Raible (2005) no verão de 2005 (hemisfério norte).
139
7500
6000
4500
3000
1500
0
Cocoon
Struts
Spring
MVC
WebWork
JSF
Tapestry
Figura 4.6 - Número de Tutoriais escritos
Fonte: Google.com (Raible, 2005), Verão de 2005 (hemisfério norte)
Struts tem cerca de 7 mil artigos e tutoriais disponíveis na web, com o JSF
vindo em segundo lugar com cerca de 620 e seguido por Tapestry e Cocoon
praticamente empatados, com aproximadamente 570 artigos e tutoriais disponíveis
cada um.
Nota-se que há uma quantidade significantemente maior de documentação
disponível sobre o Struts, muito provavelmente devido a este ter sido um dos
primeiros web frameworks a serem criados, com o JSF vindo em segundo lugar.
4.5.2.
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.
140
2500
2000
1500
1000
500
0
Cocoon
Struts
WebWork
Tapestry
MyFaces
Figura 4.7 – Mensagens Trocadas em Listas de Discussão (Julho/2005)
(Raible, 2005)
A comunidade mais ativa é a do Struts com cerca de 2200 mensagens, sendo
seguida pela comunidade do Tapestry com cerca de 1400 mensagens e depois
pelas comunidades do MyFaces (implementação de JSF do grupo Jakarta) com
aproximadamente 1000 mensagens. Nota-se que Spring MVC não aparece entre
os listados. Isto porque o suporte do Spring MVC é feito através de um fórum,
que não fornece meios de amostrar a quantidade de mensagens trocadas em
determinado mês. Ainda que pudesse se amostrar o volume de e-mails trocados na
lista de discussão não oficial do Spring (como feito no capítulo 4) não haveria
como distinguir quantas mensagens dizem respeito ao módulo MVC do Spring e
quantas dizem respeito aos outros módulos. Todavia, além do suporte prestado no
fórum o Spring conta com suporte comercial prestado pela empresa Interface 21
(2005).
4.5.3.
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).
141
16
14
12
10
8
6
4
2
0
Cocoon
Struts
Spring MVC WebWork
Tapestry
JSF
Figura 4.8 – Ferramentas Compatíveis
(Raible, 2005), Verão de 2005 (hemisfério norte)
Percebe-se que há mais ferramentas compatíveis com JSF, o que não é
surpresa já que o JSF é um padrão aberto que foi desenvolvido objetivando
compatibilidade com ferramentas de produtividade. Logo em seguida vem o Struts
e em terceiro lugar o Spring MVC.
4.5.4.
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.
142
1750
1500
1250
Outubro de 2004
1000
Junho de 2005
750
Novembro de 2005
500
250
0
Cocoon
Struts
Spring
MVC
WebWork Tapestry
JSF
Figura 4.9 - Oferta de Empregos nos Meses 10/2004, 7/2005 e 11/2005
Fonte: Dice.com, 10/2004, 07/2005 (Raible, 2005) e 11/2005
Percebe-se claramente que o Struts é o framework mais mencionado em
ofertas de empregos no site Dice.com, mas que JSF foi o web framework cujo
número de ofertas de emprego mais cresceu ao longo do período analisado.
Estes dados representam à realidade do mercado norte-americano. Uma
busca feita em novembro de 2005 no site brasileiro Manager Online
(http://www.manageronline.com.br/) revela a realidade do mercado nacional
(figura 4.11).
60
50
40
30
20
10
0
Cocoon
Struts
Spring MVC WebWork
Figura 4.10 – Ofertas de Emprego
Fonte: Manager Online, Outubro de 2005
Tapestry
JSF
143
Novamente há uma discrepância entre o número de vagas disponíveis que
pedem conhecimentos em Struts e as que pedem conhecimento dos outros web
frameworks. Spring MVC encontra-se em segundo lugar com uma vantagem
pouco significativa sobre JSF.
4.5.5.
Antes de escolher um web framework é importante conhecer a
disponibilidades de mão de obra no mercado de trabalho que esteja preparada para
trabalhar com o framework. Escolher um web framework pouco conhecido
implicará em custos de treinamento de pessoal. Para avaliar a disponibilidade de
profissionais habilitados a lidar com estes frameworks foi feito uma pesquisa em
sites que hospedam currículos. A Figura 4.11 mostra uma pesquisa feita em junho
de 2005 por Raible (2005) no site Jobs.net que reflete a realidade do mercado
norte-americano.
700
600
500
400
300
200
100
0
Cocoon
Struts
Spring MVC WebWork
JSF
Tapestry
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.
144
700
600
500
400
300
200
100
0
Cocoon
Struts
Spring MVC WebWork
JSF
Tapestry
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
145
segundo lugar em todas as outras exceto na categoria de disponibilidade de
suporte, onde foi terceiro.
É importante ressaltar que o Struts é desenvolvido desde 2000 e já se
encontra num estado de maturidade elevado. Boa parte de seus bons resultados
podem ser atribuídos a este fato. Por outro lado, JSF teve sua primeira versão
lançada em 2004 e mesmo assim, assumiu uma boa colocação em todas as
análises, mostrando crescimento bastante acentuado no número de posições
disponíveis requerendo profissionais com habilidade neste web framework.
4.6.
Conclusão
O objetivo da camada de apresentação é de expor a lógica de negócios ao
usuário e possibilitar a interação do usuário com a aplicação. Esta camada também
costuma ser chamada de camada web no caso das aplicações baseadas na internet.
Atualmente, HTML é a linguagem mais usada na construções de interfaces de
aplicações disponíveis na web.
HTML oferece várias vantagens, dentre elas: HTML é executado em
navegadores padrões e, portanto, não necessita que novas aplicações sejam
instalados na máquina cliente; desacoplam o cliente da tecnologia usado no
servidor; costumam trafegar livremente por firewalls e impõem restrições de
configurações modestas já que a maior parte do processamento ocorre no lado do
servidor.
Contudo também são impostos uma série de desafios, dentre eles: a
interface com o usuário muda sem que a lógica de negócios necessariamente
mude (D1); o modelo de requisição e resposta impede que a camada de
apresentação seja notificada de mudanças no modelo (D2); é necessário separar o
código de layout estático do código gerado dinamicamente (D3); requisições
HTTP só carregam parâmetros do tipo String que precisam ser convertidos em
tipos mais específicos da aplicação (D4) e validados (D5); possui um conjunto
limitado de componentes (D6); difícil garantir que a aplicação terá o mesmo
visual em todos os navegadores (D7); questões de desempenho e concorrência
tornam-se mais críticas, pois a aplicação está sujeita a um maior número de
usuários (D8) e são difíceis de testar (D9).
146
A divisão em camadas, com uma camada de apresentação limpa e magra,
contribui para solução dos desafios D1, D3, D8 e D9. Para que a camada de
apresentação seja limpa, usa-se o padrão de arquitetura MVC. Para que seja
magra, é preciso disciplinar os desenvolvedores e realizar auditorias periódicas no
código.
O padrão de arquitetura MVC divide os elementos da camada de
apresentação em visão (View), que recebe a entrada do usuário e exibe o resultado
da operação, Controlador (Controller), que acessa a camada de negócios
manipulando o modelo e selecionando a visão apropriada, e o Modelo (Model),
objeto representando parte do domínio e que provê os dados para a visão. Apesar
de ser possível construir uma solução ad hoc, há vários frameworks, denominados
web frameworks, que se propõe a prover uma solução MVC e a resolver alguns
dos desafios decorrentes do uso de HTML.
Há cerca de 54 web frameworks gratuitos disponíveis para a plataforma
Java. Estes frameworks implementam o MVC e oferecem meios para superar os
desafios D4 e D5. Dentre estes. Foram escolhidos o Struts, por ser mais popular, o
Spring MVC, pois o Spring já foi selecionado para a camada de negócios, e o
JavaServer Faces, que fornece um padrão para desenvolvimento de componentes
de interface.
Ao analisar tecnicamente os web frameworks, conclui-se que o Struts
apresenta um elevado grau de intrusão, pois as ações e os Action Forms precisam
estender classes do framework e as páginas devem ser construídas utilizando tags
do Struts que emulam as tags do HTML. Este elevado grau de intrusão torna
difícil uma possível migração do Struts para outro web framework, caso seja
necessário. Por outro lado, seu esquema de validação é o melhor, possibilitando
que a validação dos dados de entrada seja executada no lado do cliente e do
servidor a partir de um conjunto de regras declarativas. Validações no lado do
cliente ajudam a reduzir o trafego entre o navegador e o servidor, mas podem ser
desabilitadas pelo usuário e, portanto, validações no lado do servidor também são
importantes.
Já o Spring MVC possui o pior módulo de validação entre os três
analisados, exigindo que as regras sejam programadas ao invés de declaradas.
Além disso, ocorre validação apenas no lado do servidor. Entretanto Spring MVC
é o menos intrusivo dos web frameworks analisados. Seus beans de formulários
147
não precisam estender nenhuma classe específica, seus controladores estendem
classes conforme o tipo de operação a ser realizada (submissão de formulário,
conjunto de telas estilo wizard, etc.) e não precisam instanciar diretamente o
Façade, pois eles são configurados através de Dependency Injection. As páginas
são compostas com as próprias tags HTML, diminuindo o acoplamento das
páginas com Spring MVC.
O JSF por outro lado é mais intrusivo que o Spring MVC, porém menos
intrusivo que o Struts. Seus backing beans não precisam estender classes
específicas, mas eventualmente precisam obter uma referência do contexto faces
(FacesContext) o que acopla o backing bean ao JSF. As visões são construídas
utilizando componentes de interface JSF. O principal diferencial é que o JSF
define um modelo de componentes reusáveis que pode ser estendido (desafio D6
da seção 4.1). Além disso, por ser um padrão aberto, a tendência é que surjam
componentes de terceiros que possam ser reaproveitados, tendência que já se
confirma com o surgimento de projetos como o MyFaces (2005) e WebGalileo
Faces (2005) gratuitos e WebCharts (2005) comercial.
A análise não-técnica indica que Struts é o web framework mais aceito pela
comunidade, mas o JSF também tem boa aceitação, sendo o web framework com
mais ferramentas compatíveis disponíveis no mercado e o web framework cujo
número de empregos mais cresceu no mercado norte-americano segundo as
pesquisas realizadas.
Após concluir a análise técnica e a não-técnica, julga-se que o JSF é o web
framework mais adequado para ser usado na camada de apresentação do AulaNet
3.0. O critério decisivo para a efetivação desta escolha é técnico: apenas o JSF
define um modelo de componentes. A criação de componentes de interfaces para
o AulaNet 3.0 auxiliará na padronização das interfaces e contribuirá para o
desenvolvimento rápido de interfaces. Além disso, podem ser aproveitados
componentes
desenvolvidos
por
terceiros,
sejam
estes
desenvolvidos
especificamente para o AulaNet ou não.
Ao considerar os desafios listados no início deste capítulo, constata-se que a
abordagem de divisão em camadas, com uma camada de apresentação limpa e
magra, contribuiu para a superação dos desafios D1, D3, D8 e D9. A utilização de
um web framework baseado em componentes, o JSF, contribuiu para a superação
dos desafios D4, D5 e D6. O desafio D2 não pode ser resolvido, pois é intrínseco
148
ao modelo de requisição e resposta utilizado nas aplicações web. Já o desafio D7
não é solucionado pelo AulaNet 3.0, pois o custo para obter uma interface
padronizada em todos os navegadores é muito alto e implica em muitos testes em
diferentes navegadores. Como o navegador Internet Explorer detém 85,31% de
participação
no
mercado,
segundo
pesquisa
realizada
em
janeiro
de
2006 (MarketShare, 2006), os testes e desenvolvimentos no AulaNet 3 serão
voltados em um primeiro momento para este navegador.
5
Arquitetura do AulaNet 3.0
Conforme apresentado no Capitulo 1, a arquitetura do AulaNet 3.0 pode ser
vista através de duas perspectivas: a da arquitetura de aplicação e a da arquitetura
técnica. A arquitetura de aplicação apresenta uma visão mais alto nível. A
estrutura lógica do sistema é descrita como uma coleção de componentes
relacionados e os tipos e operações obtidos na especificação são distribuídos
através dos componentes. Já a arquitetura técnica apresenta uma visão mais baixo
nível e inclui as partes do sistema independentes do domínio como a infraestrutura de comunicação de componentes (ex. CORBA ou Java/RMI), a
plataforma de hardware e a plataforma de software (D’Souza & Wills, 1998).
Este Capítulo retoma a especificação da arquitetura do AulaNet 3.0 descrita
no Capítulo 1, para em seguida incrementá-la através do acréscimo dos
frameworks de infra-estrutura analisados nos capítulos 3 e 4. É visto também
como a arquitetura é adaptada para possibilitar serviços a dispositivos móveis
como PDAs (Personal Digital Assistant) e, por fim, é visto como a arquitetura
possibilita a agregação de outros frameworks, tomando como exemplo o
framework de agentes de software Jade (2005) e uma prova de conceito
envolvendo um dispositivo móvel.
5.1.
Elementos Principais da Arquitetura do AulaNet 3.0
A arquitetura de aplicação do AulaNet 3.0 possui 2 níveis de
componentização: o de serviços e o de componentes de colaboração. Os serviços
podem ser plugados e desplugados de forma a montar um ambiente customizado
para cada grupo (Gerosa et al., 2005). O gerenciamento dos componentes é
realizado através de frameworks de componentes, conforme a Figura 5.1 mostra.
Capitulo 5. A Arquitetura do AulaNet 3.0
150
AulaNet
Groupware
Component
Component
Framework
Service
Component
Framework
Debate
Conferência
Collaboration
Component
Framework
.
.
Msg Manager
Msg Locator
Database
.
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.
Camada de
Apresentação
151
V
C
Camada de
Negócios
Façade
M
(DTO)
Data Access Object
Mail
Sender
Camada de
Recursos
Servidor de
E-Mails
SGBD
Figura 5.2 – Arquitetura Técnica do AulaNet 3.0
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).
152
Os serviços plugados no Service Component Framework são criados com
um único Façade, que expõe as operações deste serviço para a camada de
apresentação. Os componentes de colaboração plugados no Collaboration
Component Framework por sua vez, podem utilizar vários DTOs e DAOs,
dependendo da complexidade do componente. Estes componentes podem ainda
usar “código cola” (Szyperski et al., 1997) e adaptadores (D’Souza & Wills, 1998)
para possibilitar a integração com componentes e outros sistemas que não são
compatíveis por construção.
A camada de apresentação, que no caso de aplicações voltadas para a
internet também costuma ser chamada de camada web, expõe a lógica de negócios
ao usuário e possibilita a interação do usuário com a aplicação. Na arquitetura do
AulaNet 3.0, a camada web é composta pelo controlador, o C do MVC além de
páginas JSP, que correspondem ao V do MVC. O controlador chama os métodos
do Façade, acessando a camada de negócios. Os DTOs resultantes de operações
são passados a visão que exibe suas informações ao usuário.
Esta seção reviu a arquitetura definida para o AulaNet 3.0, do ponto de vista
da arquitetura técnica e de aplicação. Ao longo desta dissertação frameworks de
infra-estrutura foram acrescentados a esta arquitetura, provendo uma base de
serviços que tratam aspectos como persistência de dados, gerenciamento de
transações entre outros. Na próxima seção a arquitetura do AulaNet 3.0 é
reformulada através do acréscimo destes frameworks.
5.2.
A Arquitetura do AulaNet 3.0 e os Frameworks de Infra-Estrutura
Spring e Hibernate formam a base com os frameworks de infra-estrutura que
oferecem suporte ao desenvolvimento de componentes de negócios. Eles provêm
serviços de infra-estrutura, como por exemplo, persistência de dados e
gerenciamento de transações para os componentes desenvolvidos com o Service
Component Framework e o Collaboration Component Framework. A Figura 5.3
mostra o novo diagrama da arquitetura de aplicação do AulaNet 3.0 após a
incorporação dos frameworks de infra-estrutura.
153
Application
Groupware
Component
Framework
Component
Component
Framework
Debate
Conferência
.
Collaboration
Component
Framework
.
Msg Manager
Msg Locator
Spring
Hibernate
Database
.
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.
Camada de
Apresentação
Componente
JSF
Backing Bean
Camada de
Negócios
154
JSP
Servlet
JSF Controller
IFaçade
Proxy (Spring)
IFaçade
Façade
M
(DTO)
Mail
Sender
Spring/Hibernate
Data Access Object
XML
DTO.hbm.xml
Camada de
Recursos
Servidor de
E-Mails
SGBD
Figura 5.4 - Arquitetura Técnica do AulaNet 3.0 com Frameworks.
Na camada de apresentação, a visão é construída com páginas JSP
compostas por componentes JSF. Estes podem ser componentes de validação, de
conversão de dados e de interface com o usuário. O Servlet JSF Controller é usado
como controlador do MVC. Ao receber uma requisição, o controlador chama o
backing bean, que acessa a camada de negócios.
A entrada para a camada de apresentação é feita através do Proxy (Gamma
et al., 1995) do Spring. Como o Proxy implementa a mesma interface do Façade
(inteface IFaçade), o código cliente não precisa ser modificado para usar o Proxy
em vez da implementação direta do Façade. O Proxy do Spring acrescenta
serviços de controle de transações e gerenciamento de segurança. Para cada DTO
representando uma entidade de negócios, um arquivo de mapeamento do
Hibernate é gerado. Este arquivo possui os metadados de mapeamento
objeto/relacional que possibilitam que o Hibernate realize a ponte entre os
155
paradigmas objeto e relacional. Por fim, os DAOs são construídos usando tanto o
Hibernate, que possibilita o mapeamento de objetos em base de dados relacionais,
quanto o Spring, que gerencia a abertura e o fechamento de sessões do Hibernate e
oferece métodos template, simplificando o desenvolvimento e reduzindo a
ocorrência de erros. O Spring também atua na configuração das dependências dos
componentes da camada de negócio.
Como é mostrado nesta seção, a arquitetura de POJOs do AulaNet 3.0
possibilita o acréscimo de frameworks de infra-estrutura. Estes frameworks por
sua vez, possibilitam que o desenvolvedor de groupware concentre-se em seu
domínio, ou seja, groupware, deixando aspectos de infra-estrutura para outros
frameworks especialistas. A arquitetura do AulaNet 3.0 também provê suporte a
outros tipos de aplicações clientes, por exemplo, clientes móveis, como é visto a
seguir.
5.3.
Arquitetura Técnica e Mobilidade
Com o crescimento da utilização de equipamentos móveis e redes sem fio, o
potencial de uso de serviços tradicionais, como a navegação na web e e-mail
aumentou bem como serviços não tradicionais e específicos de aplicações móveis,
como aqueles que fazem uso da informação física do usuário. Através da adoção
destas tecnologias espera-se que seja possível comunicar-se e ter acesso a
informações e serviços em qualquer lugar e a qualquer instante. Neste contexto, a
educação deverá incluir soluções que façam uso destes recursos (Filippo et al.,
2005a).
Com o objetivo de investigar mecanismos para aumentar a colaboração na
aprendizagem
através
do
uso
de
equipamentos
móveis,
iniciou-se
o
desenvolvimento de uma extensão do ambiente AulaNet específica para este fim,
denominada AulaNetM (Filippo et al., 2005a). A versão atual do AulaNetM
integra-se ao AulaNet 2.1 no nível de dados. A arquitetura do AulaNet 3.0 foi
projetada para possibilitar integração no nível de serviços, aumentando assim a
reutilização entre os dois projetos. Há duas formas de possibilitar a integração da
arquitetura do AulaNet 3.0 no nível de serviços com o AulaNetM: através da
reposição da camada de apresentação e da exposição de serviços remotamente.
156
A técnica da reposição da camada de apresentação consiste em reaproveitar
todo o código da camada de negócios e combiná-lo com uma nova camada de
apresentação, desenvolvida especificamente para o dispositivo móvel. A aplicação
resultante é executada independentemente do AulaNet 3.0 e serve aplicações
clientes magras, ou seja, clientes que rodam em navegadores HTML no caso de
PDAs ou WML no caso de celulares. Esta aplicação pode ser instalada no mesmo
servidor do AulaNet (em um contexto diferente) ou em outro servidor.
Opcionalmente, são acrescentados serviços específicos para clientes
móveis, como serviços sensíveis a contexto ou a localização. Os projetistas da
aplicação móvel têm controle limitado sobre o navegador utilizado no dispositivo
e quase sempre não há suporte computacional para recuperar dados como a
localização do PDA e o nível de carga da bateria. Torna-se necessário então que a
aplicação questione o usuário sobre estas informações para poder prover estes
serviços. A Figura 5.5 exibe a arquitetura do AulaNetM integrada ao AulaNet 3.0,
usando esta técnica.
157
Camada de
Apresentação
AulaNetM
Camada de
Negócios
IFaçade
Serviços Móveis
Proxy (Spring)
IFaçade
Façade
M
(DTO)
Mail
Sender
Spring/Hibernate
Data Access Object
XML
DTO.hbm.xml
Camada de
Recursos
Servidor de
E-Mails
SGBD
Figura 5.5 – Arquitetura Técnica da Integração AulaNet 3.0 com AulaNetM
por Reposição da Camada de Apresentação
A não ser pela adição dos serviços móveis, que é opcional, a camada de
negócios é a mesma usada na arquitetura do AulaNet 3.0. A camada de
apresentação, assim como os serviços específicos de mobilidade, são
implementadas pelos projetistas do AulaNetM. O uso de MVC não é obrigatório,
mas é recomendado.
Esta forma de integração atua em nível de serviço, mas em instâncias
diferentes da camada de negócios, pois a camada de negócios precisa ser
implantada no servidor do AulaNet 3.0 e do AulaNetM. A principal vantagem
desta técnica é que as duas aplicações usam o mesmo código, da mesma forma
com a exceção dos serviços específicos relativos à mobilidade. Equipes
trabalhando em um projeto tendem a encontrar mais facilidade para mudar para
outro já que estão habituadas as mesmas interfaces da camada de negócios. A
158
principal desvantagem é que as informações do dispositivo como estado da
conexão, carga da bateria, localização, etc., não podem ser recuperadas de forma
transparente para o usuário. Além disso, é despendido um esforço extra para
manter os dois projetos sincronizados, já que quando ocorrerem mudanças na
camada de negócio, é preciso implantar a nova versão nos servidores do
AulaNetM e AulaNet 3.0.
A técnica da exposição de serviços remotos consiste em expor os serviços
do AulaNet 3.0 remotamente para outras aplicações clientes. Esta técnica pode ser
aplicada tanto para clientes magros quanto para clientes gordos, ou seja, clientes
escritos em J2ME (2005), SuperWaba (2005) ou qualquer outra tecnologia usada
para programar em dispositivos móveis.
O desenvolvedor tem total controle sobre clientes gordos, sendo assim, estes
tipos de clientes têm acesso a informações de contexto como localização, nível da
bateria do dispositivo e estado da conexão, desde que a tecnologia utilizada para o
desenvolvimento do cliente ofereça suporte a estas informações. Contudo, eles
precisam ser instalados diretamente no dispositivo. A Figura 5.6 exibe a
arquitetura do AulaNetM integrada ao AulaNet 3.0, usando a técnica de exposição
de serviços remotos.
159
Camada de Apresentação
+ Negócios
Cliente
Gordo
Camada de
Apresentação
Componente
JSF
JSP
Web Services
JSF
Controller
Backing Bean
Camada de
Negócios
IFaçade
Proxy Remoto (Spring)
Proxy (Spring)
IFaçade
Serviços Móveis
Façade
M
(DTO)
Mail
Sender
Spring/Hibernate
Data Access Object
XML
DTO.hbm.xml
Camada de
Recursos
Servidor de
E-Mails
SGBD
Figura 5.6 - Arquitetura Técnica da Integração AulaNet 3.0 com AulaNetM
por Exposição de Serviços Remotos
Um cliente gordo tem a sua camada de apresentação implementada com
tecnologias como o J2ME, mas também pode ter uma camada de negócios extra,
onde há serviços independentes do acesso ao AulaNet 3.0, como um serviço
despertador. Através de Serviços Web o cliente acessa a lógica de negócios do
AulaNet 3.0. No caso de clientes magros, não mostrados na figura acima, a
camada de apresentação é implementada utilizando HTML ou WML através das
tecnologias JSP e Servlets, que acessam a camada de negócios do AulaNet 3.0
através de Serviços Web.
160
Como é visto no capítulo 3, o Spring possibilita a exposição de serviços de
diversas formas. A forma escolhida para integração com AulaNetM a princípio é
por Serviços Web (Web Services), pois possibilitam a integração com aplicações
clientes escritos em várias linguagens de programação além do Java. O Spring
também possibilita que outros Proxys remotos sejam acrescentados, dando suporte
ao uso de outros protocolos, como o RMI (RMI-IIOP, 2005), o Hessian/Burlap
(Caucho, 2005) e o HttpInvoker (Spring, 2005). Vale lembrar que o uso de Proxys
no Spring é feito através de configurações no descritor da aplicação, sem que seja
necessário alterar o código dos componentes.
Os Proxys remotos recebem as chamadas remotas e as encaminham para os
métodos da camada de negócios ou para os componentes que provêm serviços
específicos de mobilidade. A arquitetura do AulaNet 3.0 não sofre alteração
substancial com o acréscimo dos serviços remotos.
A principal vantagem do uso da técnica de exposição de serviços remotos é
que ela dá suporte à construção de clientes gordos, que têm mais controle sobre o
dispositivo móvel. A principal desvantagem é que chamadas remotas de métodos
são mais caras que chamadas locais, tanto no que diz respeito ao desempenho
quanto à complexidade adicionada a programação. Esta técnica pode ser usada
tanto com clientes gordos quanto com clientes magros, mas em se tratando de
clientes magros, é mais vantajoso usar a técnica da reposição da camada de
apresentação que utilizam chamadas locais.
Apesar das promessas de ensino e aprendizagem em qualquer lugar e a
qualquer instante, a educação através de dispositivos móveis (m-learning) está
sujeita a alguns desafios: a conexão é intermitente e lenta; pouco poder de
processamento de dispositivos móveis; fontes de energias limitadas que de tempos
em tempos necessitam ser recarregadas; adaptação das aplicações a um
determinado aprendiz, ao contexto em que ele esta situado, à sua localização, etc.
Estes desafios são inerentes às características dos dispositivos móveis e podem ser
considerados também como desafios para outros tipos de groupware executados
em dispositivos móveis. Sistemas de agentes inteligentes têm um grande potencial
para solucionar estes desafios (Kinshuk & Lin, 2004).
161
5.4.
Arquitetura Técnica e Outros Frameworks: Jade
Apenas os frameworks Spring, Hibernate e JSF foram selecionados para
fazer parte da base de serviços de infra-estrutura da arquitetura do AulaNet 3.0,
contudo esta pode ser estendida para incorporar outros frameworks. Como estudo
de caso esta seção mostra como a arquitetura do AulaNet 3.0 foi estendida para
incorporar o framework de desenvolvimento de agentes Jade (Bellifemine et al.,
2003).
5.4.1.
Agentes de Software
O termo agente tem sido amplamente usado por pesquisadores em áreas
similares, o que torna difícil obter uma definição precisa e amplamente aceita.
Segundo Wooldridge & Jennings (1995) agentes pode ser definido seguindo uma
noção fraca ou forte.
Segundo a definição fraca, agente é definido como um sistema
computacional com as seguintes propriedades: autonomia, agentes operam sem a
intervenção de seres humanos e possuem controle sobre suas ações e estado
interno; habilidade social, agentes interagem com outros agentes e possivelmente
com seres humanos através de uma linguagem de comunicação de agentes (agentcommunication language - ACL); reatividade, agentes percebem seu ambiente
(que pode ser o ambiente físico, a internet, a interface gráfica com o usuário) e são
capazes de reagirem a mudanças neste ambiente; e pró-atividade, agentes tomam a
iniciativa de agem, sem receber ordem externa.
Já a noção forte, usada principalmente por pesquisadores na área de
inteligência artificial, acrescenta às propriedades descritas na noção fraca
características que geralmente são associadas a seres humanos. Por exemplo,
Shoham (1993) adiciona as noções de conhecimento, crenças, intenções e
obrigações aos agentes.
Para esta dissertação, a definição fraca de Wooldridge & Jennings (1995) é
adotada. É considerado também que agentes possuem a característica da
mobilidade, que possibilita que agentes se movam pela rede (White, 1994).
162
Pesquisas de sistemas multi-agentes (Multi Agent Systems - MAS) seguem
duas linhas (Torres & Lucena, 2001). A primeira considera agentes como
elementos de primeira ordem. Pesquisadores desta linha vêem MAS como o
elemento fundamental de uma nova engenharia de software para a qual devem ser
desenvolvidas novas linguagens, metodologias e técnicas de modelagem. Já
pesquisadores da segunda consideram agentes uma abstração que deve ser usada
para complementar o paradigma da orientação a objetos. Pretende-se seguir a
segunda linha de pesquisas ao acrescentar um framework de agentes ao AulaNet.
5.4.2.
Aplicações de Sistemas Multi-Agentes
Como é visto na seção 5.3, o m-learning está sujeito a alguns desafios: o
acesso ao conteúdo estudado é lento e intermitente, dispositivos móveis têm poder
de processamento modesto e fontes de energias limitadas, a aplicação móvel pode
se adaptar a um determinado contexto. Agentes aplicados em dispositivos móveis
lidam com muitos destes desafios impostos ao m-learning.
Agentes podem realizar download antecipado do conteúdo do estudo
baseado no histórico do aprendiz. A qualidade da conexão é usada por agentes
para tomar atitudes que diminuam o volume de dados trafegado como, por
exemplo, compactar os dados ou não baixar as imagens de uma página HTML.
Além disso, o usuário pode executar algumas operações off-line, como enviar uma
mensagem mesmo com a conexão indisponível, que serão completadas pelo
agente assim que ele tome conhecimento que a rede está novamente acessível.
Desta forma, os problemas causados pela intermitência e velocidade da rede são
amenizados.
A capacidade de mobilidade dos agentes pode evitar as limitações dos
dispositivos móveis. Os agentes móveis migram para um container de agentes em
um servidor na rede fixa, realizam um processamento complexo e retornam ao
dispositivo móvel com os resultados do processamento.
Agentes em execução dentro do PDA têm acesso a informações de contexto,
como localização e carga da bateria. Desta forma, agentes oferecem serviços
específicos que atendem às características de um ambiente com mobilidade e
modificam seu próprio comportamento com base nestas informações.
163
Além do m-learning, agentes inteligentes podem ser usados em uma grande
variedade de aplicações. Agentes são particularmente úteis em aplicações
distribuídas envolvendo comunicação ponto-a-ponto. Alguns exemplos de
domínios onde sistemas multi-agentes podem ser aplicados incluem aplicações de
comércio eletrônico (Ripper et al., 2000), assistentes pessoais para gerenciamento
de compromissos (Modi et al., 2004), simuladores (Drogoul & Ferber, 1992) entre
outros.
Além das aplicações de agentes no AulaNetM, também são vislumbradas
aplicações ou tópicos de pesquisa onde agentes podem ser usados no AulaNet 3.0.
Dentre elas, algumas são: o Agente Notificador, o Agente Moderador, o Agente
Mediador, o Agente Formador de Grupos e o Agente Tutor. O Agente Notificador
poderia ser configurado pelo aprendiz ou mediador para enviar notificações
sempre que ocorrer algum evento relacionado ao curso. Este agente poderia, por
exemplo, ser configurado para notificar o aprendiz sempre que uma mensagem
sua for respondida na conferência. O Agente Moderador seria usado para conduzir
a dinâmica de um debate. Um terceiro exemplo seria o do uso de um Agente
Mediador, que animaria discussões em conferências. Este agente, por exemplo,
enviaria mensagens polêmicas se percebesse um longo período de inatividade na
conferência. O Agente Formador de Grupos, baseado em critérios como
performance dos aprendizes, conhecimento e grau de afinidade, sugeriria a
formação de grupos de trabalho. Finalmente, o Agente Tutor poderia propor
conteúdos e cursos relacionados de acordo com o perfil do aprendiz.
Sistemas multi-agentes é um tópico de pesquisa “quente” na área de
sistemas de informação (Kinshuk & Lin, 2004) e que, como foi visto, pode trazer
vantagens tanto para o AulaNet quanto para o AulaNetM. Desta forma, é
desejável que a arquitetura do AulaNet 3.0 forneça suporte ao desenvolvimento de
sistemas multi-agentes. Para prover este suporte pode ser usado o framework Jade
(Bellifemine et al., 2003), como mostrado na seção a seguir.
5.4.3.
O Framework de Agentes Jade
Jade é um framework de aplicação orientada a objeto direcionado para o
desenvolvimento de sistemas multi-agentes em conformidade com a especificação
164
definida pela FIPA (Foundation for Intelligent Physical Agents) (FIPA, 2005),
uma organização reconhecida pelo IEEE que promove tecnologias baseada em
agentes e a interoperabilidade de suas especificações com outras tecnologias
(Bellifemine et al., 2005). Jade foi escolhido para mostrar que a arquitetura do
AulaNet 3.0 pode ser estendida com outros frameworks pois ele é um framework
de agentes que encontra-se em estado de relativa maturidade, é compatível com a
especificação da FIPA, é usado comercialmente em algumas empresas como a
Telecom Italia LAB, Whitestein Technologies AG e Acklin B.V. (Jade, 2005), é
escrito em Java e possibilita o uso de agentes tanto em dispositivos móveis quanto
servidores desktops através do pacote de extensão Leap.
Além do framework para desenvolvimento de agentes, o Jade inclui também
um ambiente de execução para os agentes, denominado container, e uma
ferramenta gráfica onde são realizadas as operações administrativas e o
monitoramento do estado dos agentes. Um conjunto de containeres Jade,
executando na mesma máquina ou em máquinas distintas, fazem parte de uma
plataforma. Agentes em uma mesma plataforma podem se comunicar,
opcionalmente usando ontologias. Agentes podem ainda migrar de um container
para outro ou clonar-se, gerando um novo agente idêntico (Caire, 2003).
Em uma plataforma, o primeiro container iniciado é denominado o container
principal (Main Container). Sempre que algum novo container for iniciado na
plataforma, ele deve registrar-se neste container. O container principal também é
responsável por hospedar os agentes AMS (Agent Management System) e DF
(Directory Facilitator). O primeiro é responsável pelo serviço de nomes que
garante que agentes terão nomes únicos em uma plataforma e possibilita a criação
e remoção de agentes em outros containeres. O segundo fornece um serviço de
páginas amarelas onde agentes podem procurar por outros atentes que prestam
serviços necessários para que seus objetivos sejam alcançados. A Figura 5.7
ilustra a execução de duas plataformas de agentes Jade.
165
Figura 5.7 – Plataformas de Agentes Jade (Caire, 2003).
A figura mostra duas plataformas. A primeira, denominada Plataform 1,
contém três containeres. Os agentes AMS (Agent Management System), DF
(Directory Facilitator) e o agente com o nome A1 se hospedam no container
principal. Os agentes A2 e A3 se hospedam no container 1 e o agente A4 se
hospeda no container 2. Tanto o container 1 quanto o container 2 se registram no
container principal, unindo-se à primeira plataforma. A segunda plataforma possui
apenas o container principal, onde se hospedam os agentes AMS, DF e um outro
agente chamado A5.
Agentes são construídos estendendo a classe jade.core.Agent. As ações que
um agente realiza são especificadas através de comportamentos, classes que
estendem jade.core.behaviours.Behaviour ou uma de suas subclasses. Há
subclasses específicas para comportamentos que devem ser executados
continuamente (CyclicBehaviour), que devem ser executados de tempos em
tempos
(TickerBehaviour),
que
são
executados
apenas
uma
vez
(OneShotBehaviour) e outras. Agentes são identificados pelo seu nome e pela sua
plataforma de execução através da classe jade.core.AID.
166
Com a adição do pacote de extensão Leap, o container Jade pode ser
executado em dispositivos móveis e em servidores Java. O pacote Leap substitui
partes do núcleo do Jade que passa a se chamar Jade-Leap e possibilita a
implantação de containeres Jade-Leap em ambientes J2SE, que é usado em
servidores, Personal Java/J2ME CDC, que é usado em PDAs e MIDP, que é usado
em telefones celulares (Caire, 2005).
Devido às limitações de hardware em dispositivos como PDAs e telefones
celulares, o Jade-Leap possui algumas limitações quando executado nestes
ambientes.
No ambiente PJAVA/J2ME CDC, a interface gráfica de administração não
pode ser usada, pois ela depende da biblioteca Swing apenas disponível em
servidores J2SE. Além disso, não é possível usar os agentes Sniffer e Introspector,
utilizados para depuração, em containeres executando no modo stand-alone. O
modo de execução stand-alone é explicado mais adiante. Finalmente, os serviços
de replicação do container principal, usado para adicionar tolerância à falhas, e de
entrega persistente de mensagens, que garante que mensagens são entregues
mesmo quando o agente não está disponível, não podem ser usados.
Já no ambiente J2ME MIDP, são impostas as mesmas limitações impostas
aos dispositivos PJAVA/J2ME CDC e mais algumas. Não há suporte à
mobilidade e à clonagem de agentes nestes ambientes. Comportamentos de
agentes que usem threads são proibidos. Por fim, o pacote jade.wrapper e os
métodos não estáticos da classe jade.core.Runtime não estão disponíveis e
algumas classes do pacote de ontologias não funcionam, pois dependem da API de
reflexão do Java que não esta disponível na plataforma MIDP.
Jade-Leap pode ser executado em dispositivos móveis de duas formas: no
modo split e no modo stand-alone. No modo stand-alone um container Jade-Leap
completo é executado no aparelho e no modo split, o container é dividido em dois
containeres, o back-end, executado em um servidor J2SE e o front-end, executado
no dispositivo móvel. O modo de execução split possui inicialização mais rápida e
diminui a quantidade de informação trafegada pela rede sem fio. Contudo, não é
oferecido suporte à mobilidade e à clonagem de agentes em containeres
executando no modo split. Desde a versão 3.3 do Jade-Leap o modo de execução
stand-alone não é mais mantido nem testado e seu uso é desencorajado pelos
projetistas do framework (Caire, 2005).
167
5.4.4.
Jade e a Arquitetura do AulaNet 3.0
Como visto no Capítulo 4, o Spring é o framework responsável por
configurar as dependências entre os componentes. Este é um dos principais
elementos da camada de negócios do AulaNet 3.0. Se um framework pode ser
integrado ao Spring, então este pode ser integrado com sucesso a arquitetura do
AulaNet 3.0.
Jade é um framework para a camada de negócios e, portanto, se integrado ao
Spring pode ser incorporado a camada de negócios do AulaNet 3.0. Como o
Spring não oferece suporte nativo à integração com o Jade, é desenvolvido um
adaptador que possibilita a integração de ambos. Este adaptador possibilita que o
container Jade seja iniciado dentro de uma aplicação que utiliza o Spring e
também que agentes criados com o Jade beneficiem-se dos recursos oferecidos
pelo Spring, como por exemplo, a configuração de dependências através de
Dependency Injection. O diagrama de classes do adaptador é mostrado na Figura
5.8.
168
org.springframework.beans.factory
<< interface >>
BeanFactoryAware
+setBeanFactory(beanFactory:BeanFactory)
<< interface >>
InitializingBean
<< interface >>
DisposableBean
+afterPropertiesSet()
+destroy()
<< interface >>
JadeLeapAdapter
JadeLeapAdapterImpl
-mainContainer:boolean
-containerName:String
-containerAddress:String
-containerPort:int
-autoInit:boolean
-mainContainerAddress:String
-mainContainerPort:int
+ isMainContainer():boolean
+setMainContainer(main:boolean)
+getContainerName():String
+setContainerName(name:String)
+getContainerAddress():String
+setContainerAddress(address:String)
+getContainerPort():int
+setContainerPort(port:int)
+ isAutoInit():boolean
+setAutoInit(autoInit:boolean)
+getMainContainerAddress():String
+setMainContainerAddress(address:String)
+getMainContainerPort():int
+setMainContainerPort(port:int)
+startContainer()
+stopContainer()
+isContainerRunning()
+getContainerController():ContainerController
+createAgent(def:AgentDefinitionByClassName):AgentController
+createAgent(def:AgentDefinitionByAgentInstance):AgentController
+killAgent(agentName:String)
+getAgentController(agentName:String):AgentController
AgentDefinition
0..* -name:String
+AgentDefinition()
+AgentDefinition(name:String)
+getName():String
+setName(name:String)
AgentDefinitionByClassName
AgentDefinitionByAgentInstance
-className:String
-arguments:Object[]
+getClassName():String
+setClassName(className:String)
+getArguments():Object[]
+setArguments(args:Object[])
+AgentDefinitionByAgentInstance()
+AgentDefinitionByAgentInstance(agent:Agent)
+AgentDefinitionByAgentInstance(agent:Agent, name:String)
jade.core
0..1
Agent
Figura 5.8 – Diagrama de Classes do Adaptador Jade-Leap para o Spring
A classe AgentDefinition e suas subclasses são usadas para definir um
agente. Estas definições são usadas pelo adaptador para criar agentes e adicionálos ao container Jade. A classe abstrata AgentDefinition utiliza apenas o nome do
agente para defini-lo, e não é suficiente para adicionar um agente a um container
Jade, logo uma de suas subclasses precisa ser utilizada. A subclasse
AgentDefinitionByClassName é usada para definir um agente com base no nome
da classe que implementa o agente e os argumentos que devem ser passados a ela.
A subclasse AgentDefinitionByAgentInstance define um agente através de uma
instância da classe jade.core.Agent.
169
A interface JadeLeapAdapter define os métodos do adaptador que realiza a
ponte de integração do Jade-Leap ao Spring. São definidos métodos para iniciar o
container
Jade
(método
startContainer()),
parar
o
container
(método
stopContainer()), verificar se o container está em execução (método
isContainerRunning())
e
recuperar
o
controle
do
container
(método
getContainerController()) com o qual operações mais complexas podem ser
realizadas sobre o container Jade. Além disso, há métodos para criar um agente,
segundo a descrição pelo nome da classe ou pela instância (métodos
createAgent()), destruir um agente (killAgent()) ou recuperar o controlador do
agente usado para executar operações como o acréscimo de comportamentos aos
agentes.
A classe concreta que implementa a interface JadeLeapAdapter é a
JadeLeapAdapterImpl. Além de implementar a interface JadeLeapAdapter, ela
implementa também as interfaces BeanFactoryAware, InitializingBean e
DisposableBean do Spring. A primeira define o método setBeanFactory(), que é
chamado pelo Spring para passar a fábrica de beans (BeanFactory) responsável
pela criação do adaptador. Através desta fábrica, outros beans definidos no Spring
podem ser recuperados pelos agentes criados a partir da definição baseada no
nome da classe (AgentDefinitionByClassName). Os agentes criados pela
definição baseada na instância do agente (AgentDefinitionByAgentInstance) não
necessitam da fábrica pois acessam os outros beans definidos no Spring pelo
mecanismo de Dependency Injection. A interface InitializingBean define o
método afterPropertiesSet() chamado quando o adaptador é inicializado e é usada
para iniciar o container Jade automaticamente. A interface DisposableBean define
o método destroy(), que é chamado pouco antes do adaptador ser destruído, usada
para encerrar o container Jade automaticamente.
Além disso, a classe JadeLeapAdapterImpl define propriedades que
possibilitam que o modo de execução do Jade seja configurado. A propriedade
mainContainer indica se o container a ser executado é um container principal. No
caso
desta
propriedade
ser
configurada
como
falsa,
as
propriedades
mainContainerAddress e mainContainerPort devem ser configuradas com o
endereço e a porta do container principal. As propriedades containerName,
containerAddress e containerPort são usadas para especificar, respectivamente, o
nome, endereço e porta do container iniciado pelo adaptador. O vetor
170
agentDefinitions é configurado com os agentes criados quando o container é
iniciado e a propriedade autoInit define se o container é iniciado automaticamente
quando o adaptador é criado.
Apesar de possibilitar a integração do Jade ao Spring, o adaptador
desenvolvido tem algumas limitações. Ao migrar para outra máquina, as
referências que um agente possui para serviços locais tornam-se inconsistentes. O
mesmo ocorre com agentes clonados em outras máquinas. Para superar esta
limitação, o agente com mobilidade ao retornar para o AulaNet deve comunicar-se
com um outro agente sem mobilidade, para que este possa lhe fornecer a
referência perdida. Além disso, agentes criados a partir da definição baseada no
nome da classe não podem fazer uso do módulo de Dependency Injection do
Spring, pois eles são instanciados pelo Jade e não pelo Spring. Para contornar este
problema o adaptador adiciona a fábrica de beans (BeanFactory) do Spring na
última posição do vetor de argumentos passados ao agente. Desta forma, o agente
recupera instâncias de beans definidos no Spring.
O adaptador deve ser configurado no arquivo de configuração do Spring,
como será visto na seção a seguir. Como nenhuma API específica do Jade ou do
JadeLeap é usada na construção do adaptador, este pode ser usado tanto em um
quanto no outro. O adaptador não foi desenvolvido para dar suporte ao modo de
execução split em dispositivos móveis, pois Spring foi desenvolvido para dar
suporte apenas aos ambientes J2SE e J2EE, e portanto não funciona em
dispositivos móveis. Contudo isto não é empecilho para que um agente em
execução em container em um ambiente J2SE ou J2EE com Spring se comunique
com outro agente em um dispositivo móvel MIDP ou PJAVA/J2ME CDC, como
é visto na próxima seção.
5.4.5.
Prova de Conceito com Agente Móvel
Para testar a integração entre o Jade e o Spring através do adaptador, bem
como a viabilidade do uso de agentes em dispositivos móveis se comunicando
com outros agentes em servidores, desenvolveu-se uma prova de conceito. Esta
prova é dividida em duas partes. Na primeira parte, é mostrado o sistema multiagentes “O Que Há de Novo na Conferência?” que tem pouca aplicação prática,
171
mas que é mostrado com mais detalhes por ser mais simples, e como
conseqüência mais didático. Na segunda parte é mostrado um sistema multiagentes “Assistente do Mediador” que tem mais aplicação prática, pois é
construído para superar alguns problemas reportados por usuários do AulaNetM.
Este não é mostrado com tantos detalhes devido a sua complexidade.
5.4.2.1.
MAS 1: O Que Há de Novo na Conferência?
Esta aplicação é usada para obter atualizações sobre uma determinada
conferência. A cada solicitação do usuário do PDA, a aplicação informa as
mensagens novas, que foram removidas, que tiveram suas categorias alteradas e
que foram avaliadas desde a última consulta do usuário.
Para implementar esta aplicação são utilizados dois agentes. O primeiro,
denominado Agente Móvel (MobileAgent), é hospedado por um container JadeLeap em execução em um PDA iPAQ 5555, utilizando a máquina virtual J2ME
CDC CrEme (2005). O modo de execução é o split e o container neste dispositivo
atua como front-end. O segundo agente, denominado Agente Conferência
(ConferenceAgent), é hospedado por um container Jade-Leap em execução no
servidor J2EE JBoss em conjunto com o protótipo do serviço Conferência
desenvolvido a partir da arquitetura definida para o AulaNet 3.0. Este container
funciona como o back-end. O container principal da plataforma é executado
separadamente, para facilitar a depuração do sistema. A Figura 5.9 ilustra a
interação entre os containeres.
172
AulaNet 3
Plataforma JADE
Split Container
JADE-LEAP
Back-End
JADE-LEAP
Front-End
Conference
Agent
Mobile
Agent
JSF
Conector
Spring
Hibernate
JADE-LEAP
Main Container
Figura 5.9 – Plataforma de Execução do MAS 1
O Agente Móvel, quando acionado pela aplicação, se comunica com o
Agente Conferência para buscar atualizações sobre uma determinada conferência.
O Agente Conferência então acessa a camada de negócios do AulaNet 3.0,
recuperando o estado dela e envia de volta ao Agente Móvel a lista das mensagens
novas, das mensagens que foram removidas, das mensagens que tiveram sua
categoria alterada e das mensagens que foram avaliadas desde a última consulta
do Agente móvel.
O Agente Conferência é implementado da mesma forma que qualquer outro
agente seria implementado na plataforma JadeLeap. A única diferença é que,
173
como ele é executado em conjunto com o Spring, obtém os benefícios
proporcionados por este framework. A Listagem 5.1 mostra o código do agente.
01: public class ConferenceAgent extends Agent {
02:
private ConferenceFacade facade;
03:
04:
05:
protected void setup() {
addBehaviour(new WhatIsNewInConferenceBehaviour());
}
06:
07:
08:
protected void takeDown() {
facade = null;
}
09:
10:
11:
public final ConferenceFacade getConferenceFacade() {
return conferenceFacade;
}
12: public final void setConferenceFacade(ConferenceFacade cf) {
13:
facade = cf;
14: }
15: }
Listagem 5.1 – Agente Conferência
Na linha 01, a classe do agente estende a classe jade.core.Agent. Todos os
agentes do Jade devem estender esta classe. Na linha 02 é declarada a variável
para o Façade da conferência. O método setup(), chamado pelo container Jade
para configurar o agente quando este é adicionado ao container, é declarado entre
as
linhas
03
e
05.
Na
linha
04
o
comportamento
WhatIsNewInConferenceBehaviour, que é descrito mais adiante, é acrescentado
ao agente. O método takeDown(), chamado quando o agente é removido do
container, é declarado no trecho entre as linhas 06 e 08. No trecho entre as linhas
09 e 14 são declarados os métodos de acesso para a propriedade facade. Esta
propriedade é configurada pelo Spring por Dependency Injection.
O comportamento WhatIsNewInConferenceBehaviour é responsável por
responder ao Agente Móvel o que há de novo na conferência. O código fonte
deste comportamento é listado a seguir.
174
16: public class WhatIsNewInConferenceBehaviour extends CyclicBehaviour {
17:
private final Map lastConference = new HashMap();
18:
19:
20:
21:
public void action() {
MessageTemplate mt = MessageTemplate.and(
MessageTemplate.MatchPerformative(ACLMessage.QUERY_IF),
MessageTemplate.MatchConversationId("conference-status"));
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
ACLMessage msg = myAgent.receive(mt);
if (msg != null) {
AID sender = msg.getSender();
Conference oldConference = (Conference) lastConference.get(sender);
String conferenceId = msg.getContent();
ConferenceFacade ca = (ConferenceAgent) myAgent;
ConferenceFacade facade = ca.getConferenceFacade();
Conference newConference = facade .findConferenceById(conferenceId);
List newMessages = getNewMessages(oldConference, newConference);
List deletedMessages = getDeletedMessages(oldConference, newConference);
List categorizedMessages = getCategorizedMessages(oldConference, newConference);
List evaluatedMessages = getEvalutatedMessages(oldConference, newConference);
String content = buildReplyContent(newMessages, deletedMessages,
categorizedMessages, evaluatedMessages);
36:
ACLMessage reply = msg.createReply();
37:
reply.setContent(content);
38:
myAgent.send(reply);
39:
lastConference.put(sender, newConference);
40:
} else {
41:
block();
42:
}
43: }
44: }
Listagem 5.2 – Comportamento WhatIsNewInConferenceBehaviour
Na linha 16 o comportamento é declarado como CyclicBehaviour, o que
significa que ele é executado indefinidamente. A variável lastConference é um
mapa que guarda um espelho das últimas consultas dos Agentes Móveis. No
trecho entre as linhas 18 e 21 é declarado um template de mensagem, que indica o
formato da mensagem que o agente espera receber. Na linha 22, uma mensagem
em conformidade com o template é solicitada. O remetente da mensagem é
recuperado na linha 24 e a partir dele é recuperada o status da conferência em sua
última consulta na linha 25. A partir do id da conferência recuperado na linha 26,
o estado atual da conferência é recuperado através do Façade na linha 29. Os
comandos no trecho entre as linhas 30 e 35 chamam métodos que calculam as
mensagens novas, as removidas, as que tiveram sua categoria modificada e as que
foram avaliadas e depois compõem a resposta que será enviada. Estes métodos
não são exibidos por motivos de clareza.
175
Na linha 36 a resposta é criada. O conteúdo dela é configurado na linha 37 e
ela é enviada na linha 38. Na linha 39 o mapa das conferências passadas é
atualizado.
Para que a dependência do agente com o Façade da conferência seja
satisfeita, é preciso que o arquivo de configuração do Spring seja configurado
apropriadamente. É também através do arquivo de configuração do Spring que o
adaptador do Jade-Leap é configurado. A Listagem 5.3 mostra o arquivo de
configuração do Spring.
45: <beans>
46: <bean id="jadeContainerConnector" class="JadeLeapConnectorImpl">
47:
<property name="mainContainer">
48:
<value>false</value>
49:
</property>
50:
<property name="autoInit">
51:
<value>true</value>
52:
</property>
53:
<property name="containerName">
54:
<value>SpringBackEnd</value>
55:
</property>
56:
<property name="containerPort">
57:
<value>2999</value>
58:
</property>
59:
<property name="mainContainerAddress">
60:
<value>127.0.0.1</value>
61:
</property>
62:
<property name="mainContainerPort">
63:
<value>1999</value>
64:
</property>
65:
<property name="agentDefinitions">
66:
<list>
67:
<bean class="AgentDefinitionByAgentInstance">
68:
<property name="name">
69:
<value>Conference-Agent</value>
70:
</property>
71:
<property name="agentInstance">
72:
<bean class="ConferenceAgent">
73:
<property name="facade">
74:
<ref bean="conferenceFacade"/>
75:
</property>
76:
</bean>
77:
</property>
78:
</bean>
79:
</list>
80:
</property>
81: </bean>
82: </beans>
Listagem 5.3 – Configuração no Spring do Adaptador Jade-Leap
176
O adaptador do Jade-Leap é configurado no trecho entre as linhas 45 e 81.
Por motivos de clareza o bean conferenceFacade não é exibido na listagem. No
trecho entre as linhas 47 e 49 a propriedade mainContainer é definida como false,
indicando que o container executado não é principal e entre as linhas 50 e 52 a
propriedade autoInit é configurada como true, o que indica que o container é
inicializado automaticamente. O nome do container é declarado como
SpringBackEnd no trecho entre as linhas 53 e 55 e a porta em que o container
executa é declara como 2999 no trecho entre as linhas 56 e 58. Entre as linhas 59
e 61 o endereço do container principal é configurado para 127.0.0.1 e entre as
linhas 62 e 64 a porta é configurada para 1999. No trecho entre as linhas 65 e 80,
a definição dos agentes é declarada. Neste exemplo, apenas o Agente Conferência
é configurado.
Na linha 67 é declarado que a definição de agentes usada é a definição por
instância de agente. Desta forma, é possível usar a funcionalidade de Dependency
Injection do Spring. O nome do agente, ConferenceAgente, é declarado na linha
69 e a instância do agente é declarada entre as linhas 72 e 76. A classe do agente é
definida na linha 72 e a dependência com o Façade da conferência é configurada
no trecho entre as linhas 73 e 75.
O Agente Móvel é implementado usando J2ME CDC e, portanto, não usa o
Spring e seu adaptador para o Jade-Leap. Seu código é exibido na Listagem 5.4. O
Código responsável pela criação da interface no PDA é omitido por questões de
clareza.
83: public class MobileAgent extends Agent {
84: protected void setup() {
85:
System.out.println("Agent created.\n");
86: }
87: }
Listagem 5.4 – Agente Móvel
O código do Agente Móvel é pequeno, mas é necessário, pois a classe Agent
é abstrata e não pode ser instanciada. Tudo que esta classe faz é imprimir uma
mensagem indicando que o agente foi criado. O comportamento do agente é
implementado
na
classe
ConferenceQueryBehaviour,
177
responsável
pela
comunicação com o Agente Conferência. Este comportamento, cujo código é
mostrado na Listagem 5.5, é adicionado ao agente dinamicamente quando um
usuário aciona o botão de atualização.
088: public class ConferenceQueryBehaviour extends Behaviour {
089:
090:
091:
092:
093:
private int step = SEND_QUERY;
private static final int SEND_QUERY = 1;
private static final int RECEIVE_RESPONSE = 2;
private static final int FINISH = 3;
094:
095:
096:
public ConferenceQueryBehaviour(String conferenceId) {
this.conferenceId = conferenceId;
}
097:
098:
099:
100:
101:
102:
103:
104:
105:
106:
public void action() {
switch (step) {
case SEND_QUERY:
AID receiver = new AID("Conference-Agent", AID.ISLOCALNAME);
ACLMessage query = new ACLMessage(ACLMessage.QUERY_IF);
query.addReceiver(receiver);
query.setConversationId("conference-status");
query.setContent(conferenceId);
query.setReplyWith("query" + System.currentTimeMillis());
myAgent.send(query);
107:
108:
109:
110:
111:
112:
113:
template = MessageTemplate.and(
MessageTemplate.MatchConversationId("conference-status"),
MessageTemplate.MatchInReplyTo(query.getReplyWith()));
step = RECEIVE_RESPONSE;
break;
case RECEIVE_RESPONSE:
ACLMessage reply = myAgent.receive(template);
114:
115:
116:
117:
118:
119:
120:
121:
122:
if (reply != null) {
System.out.println(reply.getContent());
step = FINISH;
} else {
block();
}
break;
}
}
123: public boolean done() {
124:
return step == FINISH;
125: }
126: }
Listagem 5.5 – Comportamento ConferenceQueryBehaviour
178
Como é visto na linha 088 a classe ConferenceQueryBehaviour, estende a
classe Behaviour que se encontra no topo da hierarquia das classes que oferecem
suporte à construção de comportamentos. Esta classe é útil para a construção de
comportamentos que funcionam como máquina de estados. O trecho entre as
linhas 097 e 122 declara o método action, executado toda vez que o
comportamento é chamado e o trecho entre as linhas 123 e 125 declara o método
done, que testa se o comportamento deve ser chamado novamente.
A variável que armazena o estado é declarada na linha 089. Constantes
representando os estados enviar pergunta (SEND_QUERY), receber resposta
(RECEIVE_RESPONSE) e final (FINISH) são declaradas entre as linhas 090 e
092. Na linha 093 é declarada a variável que armazena o id da conferência para a
qual serão obtidas as atualizações.
Um construtor que recebe o id da conferência como parâmetro é declarado
no trecho entre as linhas 094 e 096. O estado enviar pergunta é delimitado pelas
linhas 099 e 111. O endereço do destinatário é criado na linha 100 e a mensagem é
criada na linha 101. O destinatário é adicionado à mensagem na linha 102 e o
identificador da conversa é configurado na linha 103. O id da conferência para a
qual se deseja obter atualizações é adicionado como conteúdo da mensagem na
linha 104. Na linha 105, um número único é acrescentado a mensagem, para evitar
o tratamento de mensagens falsas. A mensagem é enviada na linha 106 e no trecho
entre as linhas 107 e 109 um template de mensagem com o formato da resposta
aguardada é criado. O estado enviar pergunta é delimitado pelas linhas 112 e 120.
A mensagem é recebida na linha 113 e seu conteúdo é exibido na tela (linha 115).
A interface gráfica desenvolvida para o PDA possui 6 botões divididos em
duas linhas. Na primeira linha encontram-se os botões para iniciar o container
Jade, parar o container e ativar o agente (acrescentar o comportamento
ConferenceQueryBehaviour a ele). Na segunda linha encontram-se os botões para
limpar a tela, configurar a aplicação e fechar o programa. A Figura 5.10 e a Figura
5.11 mostram o programa em execução.
179
Figura 5.10 – PDA Após a Inicialização Figura 5.11 – PDA Após a Primeira
do Jade-Leap
Consulta
A Figura 5.10 mostra a aplicação após o botão “Start Cont.” ser clicado,
resultando no início do container Jade. Já na Figura 5.11, é mostrado o estado da
aplicação após o botão “Activate Agent”, responsável pela ativação do agente, ser
acionado. Como é a primeira consulta realizada, todas as mensagens da
conferência são retornadas como mensagens novas. A Figura 5.12 mostra uma
nova ativação do agente.
180
Figura 5.12 - PDA Após a Segunda Consulta
Como a segunda ativação é realizada logo em seguida da primeira, sem que
haja mudança na conferência, o agente não detecta alterações. Este exemplo,
apesar de didático, possui pouca aplicação prática já que não apresenta nenhuma
evolução dos serviços já existentes no AulaNet e AulaNetM. Na próxima seção é
vista a segunda parte da prova de conceito, com uma aplicação baseada em um
problema real encontrado por mediadores do AulaNet.
5.4.2.2.
MAS 2: Alerta de Condições Indesejáveis
A aplicação desenvolvida nesta segunda parte tem como objetivo alertar o
mediador de um curso quando uma condição indesejável estiver ocorrendo no
serviço Conferências. São verificadas quatro condições que normalmente são
indesejáveis. A primeira refere-se ao seu nível de atividade, o que gera uma
notificação caso seja detectada a ausência de mensagens em um intervalo de
tempo maior do que um período previamente estabelecido. A segunda informação
verifica se uma questão está sendo pouco debatida ou se está polarizando a
conferência em detrimento das outras. Neste caso, o mediador é notificado caso
alguma mensagem categorizada como “Questão” possua uma quantidade de
181
respostas menor ou maior que um limite pré-configurado. Isto só é feito a partir
de 12 horas após o início da conferência, dando tempo para os aprendizes
iniciarem a discussão. A terceira informação refere-se ao nível de atividade dos
aprendizes: uma notificação é gerada quando um aprendiz apresentar uma
participação que possa ser considerada muito baixa segundo os critérios do curso.
A quarta e última informação disponibiliza uma medida para o mediador estimar o
nível de interatividade da conferência: por exemplo, uma notificação é gerada
toda vez que a porcentagem de folhas da estrutura da árvore da conferência for
maior que 50%, ou seja, quando mais da metade das mensagens não estiverem
sendo respondidas. Devido às diferentes características das turmas e dos
propósitos das conferências, os valores dos parâmetros para que as notificações
sejam acionadas devem ser configurados pelos mediadores para cada conferência
através de uma interface específica para este fim.
Ao receber estas notificações os mediadores podem tomar decisões que
mudem o rumo da conferência, contornando as situações indesejáveis. O
AulaNetM provê meios para a verificação destas situações através de informações
visuais (Figura 5.13) e estatísticas (Figura 5.14), porém, o processo de detecção
das condições indesejáveis não é automatizado, isto é, os Mediadores precisam
acessar diretamente o AulaNetM para obter a informação. Conseqüentemente, na
maior parte dos casos os mediadores tomam conhecimento da condição
tardiamente. Além disso, mediadores entrevistados reclamaram da dificuldade de
estabelecer conexão e de mantê-la uma vez estabelecida. Pesquisas revelaram
indícios de que os mediadores passavam mais tempo tentando conectar-se ou
reconectar-se do que analisando a conferência.
182
Figura 5.13 – Informações Visuais no Figura 5.14 – Informações Estatísticas
AulaNetM
no AulaNetM
Para contornar estes problemas uma MAS foi desenvolvido. Os mediadores
não precisam mais monitorar o estado da conferência, pois os agentes já fazem
isto e o mecanismo de tolerância a falhas presente no Jade possibilita que
mensagens não entregues devido a falhas na conexão sejam adiadas e entregues ao
retomar a conexão de forma transparente ao usuário. A aplicação consiste em um
sistema multi-agentes constituído por dois tipos de agentes diferentes: o
Conference Agent e o Mediator Assistant.
O Conference Agent é o mesmo descrito na seção anterior, mas a ele é
adicionado os comportamentos que permitem detectar as condições indesejáveis
na conferência. O Conference Agent é pró-ativo e reativo, e permanece
monitorando a Conferência do AulaNet na tentativa de detectar situações
indesejáveis. Como cada curso no AulaNet pode ter várias conferências, cada
nova conferência ganha um Conference Agent na sua ativação e, na sua
desativação, este agente é destruído.
O Mediator Assistant é executado dentro de um container Jade-Leap em
execução dentro de um PDA iPAQ 5555, o mesmo ambiente utilizado na
aplicação da seção anterior. Este agente permanece em execução no PDA
initerrupdamente, esperando por mensagens do Agente Conference Agent. Ao
receber uma mensagem, o agente Mediator Assistant emite um alerta,
comunicando ao seu usuário a situação indesejada ocorrida. Este agente é
183
autônomo, e pode optar por não mostrar um alerta em determinados casos, como a
desabilitação explícita de um determinado tipo de alerta pelo mediador ou a
excessiva repetição do alerta. As figuras Figura 5.15 e Figura 5.16 mostram o
Mediator Assistant em execução.
Figura 5.15 – Informações Visuais no Figura 5.16 – Informações Estatísticas
AulaNetM
no AulaNetM
A Figura 5.15 mostra a tela do agente Mediator Assistant e a Figura 5.16
mostra o agente após receber vários alertas. Esta aplicação é capaz de alertar os
mediadores tão logo a condição seja detectada e assim, estes são capazes de tomar
atitudes mais cedo para contornar a condição indesejável com mais rapidez.
5.5.
Conclusão
184
A arquitetura do AulaNet 3.0 pode ser vista através de duas perspectivas: a
da arquitetura de aplicação, que apresenta uma visão mais alto nível e a da
arquitetura técnica, que apresenta uma visão mais baixo nível.
Quando contemplada do ponto de vista da arquitetura de aplicação, a
arquitetura do AulaNet 3.0 apresenta dois níveis de componentização: o dos
serviços e o dos componentes de colaboração com os quais os serviços são
construídos. A arquitetura de aplicação apresenta dois frameworks de
componentes: o Service Component Framework, que provê os contratos que os
serviços de groupware devem implementar e o Collaboration Component
Framework, que fornece os contratos para criar componentes 3C com os quais os
serviços de groupware são construídos. Tanto os serviços quanto os componentes
3C são desenvolvidos segundo a arquitetura técnica.
A arquitetura técnica segue uma abordagem em três camadas e também o
padrão MVC (Fowler, 2002). A camada de recursos relaciona os recursos
necessários para à execução do AulaNet, por exemplo o banco de dados
relacional. A camada de negócios é onde a lógica da aplicação é implementada.
Nela encontram-se Data Transfer Objects (DTOs) (Fowler, 2005), classes do
modelo que representam entidades de negócio e são usadas para transportar dado
entre camadas (correspondem ao M do MVC), Data Access Objects (DAOs) (Alur
et al., 2001), classes que encapsulam o acesso ao banco de dados e Façades
(Gamma et al., 1995), classes que servem como ponto de entrada para a camada
de negócios. A camada de apresentação, que expõe a lógica de negócios ao
usuário, é composta pelo controlador, o C do MVC além de páginas JSP, que
correspondem ao V do MVC. Ao longo desta dissertação foram vistos como
vários frameworks podem ser acrescentados proporcionando uma base de serviços
de infra-estrutura. Após o acréscimo destes frameworks, a arquitetura é descrita
segundo a Figura 5.17.
Camada de
Apresentação
Componente
JSF
Backing Bean
Camada de
Negócios
185
JSP
JSF
Controller
IFaçade
Proxy (Spring)
IFaçade
Façade
M
(DTO)
Mail
Sender
Spring/Hibernate
Data Access Object
XML
DTO.hbm.xml
Camada de
Recursos
Servidor de
E-Mails
SGBD
Figura 5.17 – Arquitetura Técnica do AulaNet 3.0 com Frameworks
Com o crescimento do uso de dispositivos móveis e com o advento das
redes sem fio, espera-se que seja possível ter acesso a informações, comunicação
e serviços em qualquer lugar e a qualquer instante. Com o objetivo de investigar o
uso de equipamentos móveis na aprendizagem colaborativa, iniciou-se o
desenvolvimento de uma extensão do ambiente AulaNet para dispositivos móveis
denominada AulaNetM.
Atualmente o AulanetM integra-se ao AulaNet 2.1 no nível de dados. A
arquitetura do AulaNet 3.0 foi projetada para possibilitar a integração em nível de
serviços, proporcionando um maior reuso. A integração pode ser alcançada
através da técnica reposição da camada de apresentação ou da exposição de
serviços remotamente.
Pela técnica da reposição da camada de apresentação, a camada de negócios
de negócios é totalmente reaproveitada enquanto que a camada de apresentação é
186
substituída por uma outra mais adequada ao dispositivo móvel, utilizando HTML
ou WML. Esta técnica é adequada a clientes magros e sua principal vantagem é a
maior facilidade que equipes de um projeto tendem a encontrar ao participar de
outro, já que ambos usam as mesmas interfaces de negócios. A maior
desvantagem é que clientes magros não têm acesso direto a informações como a
localização do PDA, por exemplo, dificultando a implementação de serviços
específicos de mobilidade de forma transparente.
A técnica da exposição de serviços remotos é implementada através da
adição de Proxys do Spring que exportam os serviços remotamente. Clientes
magros ou gordos acessam os serviços do AulaNet através destes Proxys. A
principal vantagem desta técnica é que clientes gordos têm acesso às informações
do dispositivo, como por exemplo, a localização. Desta forma, podem dar suporte
a serviços específicos de mobilidade de forma transparente. A principal
desvantagem é que as chamadas remotas são mais complexas de serem feitas e
oferecem desempenho inferior. Apesar de prover suporte tanto para clientes
magros quanto gordos, esta técnica é mais adequada para os gordos.
Apesar das inegáveis vantagens do uso de dispositivos móveis, o
desenvolvimento de sistemas nestes ambientes oferece desafios devido à baixa
capacidade de processamento do aparelho, conexão intermitente e de baixa
qualidade, bateria que precisa ser recarregada, etc. Segundo Kinshuk & Lin
(2004), sistemas de agentes inteligentes têm um grande potencial para solucionar
estes desafios.
Além das aplicações de agentes para dispositivos móveis, há várias outras
possíveis para o AulaNet 3.0. Por isto, decidiu-se que a arquitetura do AulaNet
3.0 deveria possibilitar o uso de agentes. Para evidenciar que a arquitetura do
AulaNet 3.0 pode ser estendida com outros frameworks e que pode dar suporte ao
uso de agentes, decidiu-se investigar a integração do AulaNet ao framework de
agentes Jade.
Para que um framework seja integrado a arquitetura do AulaNet, é preciso
que este seja compatível com o Spring. Como o Spring não oferece suporte nativo
de integração com o Jade, foi necessário criar um adaptador. Através do
adaptador, podem ser realizadas operações sobre o container Jade e sobre agentes.
Como os agentes são instanciados pelo Spring, eles podem fazer uso das
187
funcionalidades proporcionadas por ele, incluindo Dependency Injection com
outras classes.
Para testar a integração do Jade com o Spring bem como a viabilidade do
uso de agentes em dispositivos móveis foi realizada uma prova de conceito em
duas etapas. Ambas envolveram agentes em ambientes móveis comunicando-se
com agentes no AulaNet.
O teste de conceito foi implementado com sucesso e com ele, constatou-se
que a arquitetura do AulaNet 3.0 pode ter outros frameworks não previstos
inicialmente incorporados, desde que eles sejam compatíveis com o Spring ou
possam ser adaptados através de um adaptador para uso com o Spring. Constatouse também que é possível desenvolver agentes em dispositivos móveis usando
Jade e que eles podem se comunicar com outros agentes localizados em
servidores.
6
Conclusão
Trabalhando colaborativamente, pelo menos potencialmente, pode-se
produzir melhores resultados do que se os membros do grupo atuassem
individualmente (Fuks et al., 2002). Groupware é um tipo de software que oferece
suporte à interação entre indivíduos possibilitando o trabalho colaborativo.
Learningware é um tipo de groupware usado no aprendizado colaborativo.
Um groupware envolve aspectos multidisciplinares em sua construção e é
difícil de aplicar e testar, sendo especialmente vulnerável a falhas (Gerosa et al.,
2004). Como cada grupo tem suas próprias necessidades que se modificam ao
longo do tempo, é importante que o groupware seja desenvolvido de forma
iterativa e que a experiência do seu uso seja usada para guiar seu
desenvolvimento, criando novos serviços ou melhorando as funcionalidades dos
serviços existentes. Através de uma arquitetura componentizada, o groupware
pode ser adaptado plugando e desplugando componentes, compondo uma
aplicação que melhor satisfaça um grupo de trabalho.
O AulaNet é um learningware desenvolvido pelo Laboratório de Engenharia
de Software (LES) da Pontifícia Universidade Católica do Rio de Janeiro (PUCRio) desde 1997 e desde o lançamento da versão 2.0 a sua arquitetura nunca
sofreu reengenharia. Alunos de graduação, mestrado e doutorado desenvolvem
suas monografias, dissertações e teses usando o AulaNet para realizar suas
pesquisas. O AulaNet é usado no curso Engenharia de Groupware, onde atua
como repositório de informações, e no curso Tecnologias de Informação Aplicada
A Educação (TIAE), onde é usado integralmente a distância. O AulaNet é
distribuído pela EduWeb, que também realiza customizações para atender as
demandas de seus clientes. Atualmente o AulaNet é usado em diversas
universidades e empresas no mundo inteiro. Com o passar do tempo o AulaNet
acumulou código legado que não segue as principais boas práticas e tecnologias
conhecidas atualmente. Como conseqüência, as equipes do LES e da EduWeb
vêm enfrentando dificuldades para desenvolver novos serviços e manter os
Capítulo 6. Conclusão
189
existentes, sendo apontadas causas como a baixa modularidade e o uso de um
paradigma funcional (Pimentel et al., 2005). Para solucionar estas questões,
iniciou-se o desenvolvimento de uma nova versão, o AulaNet 3.0.
Gerosa (2006) em sua pesquisa de doutorado na PUC-Rio concebeu uma
arquitetura baseada em componentes para o AulaNet 3.0. Esta arquitetura possui
dois níveis de componentização: o de serviços e o dos componentes 3C. Os
serviços, como a Conferência e o Debate são plugados e desplugados em um
framework de componentes, o Groupware Component Framework, compondo um
groupware especifico que atenda às necessidades de um grupo de trabalho. Os
serviços por sua vez são compostos por componentes 3C, que são reusados na
construção de diversos serviços.
Ao desenvolver componentes, o desenvolvedor se depara com inúmeros
desafios. Além de entender do seu domínio de conhecimento ele deve lidar com
questões como persistências de dados, controle de transações, segurança e muitas
outras. O desenvolvimento de groupware já é difícil por si só devido a seu caráter
multidisciplinar e a heterogeneidade dos diversos grupos de trabalho e não deveria
ser complicado por questões de baixo nível.
Frameworks de infra-estrutura de sistemas simplificam o desenvolvimento
de sistemas de infra-estrutura portáveis e eficientes (Fayad et al., 1999b). Estes
frameworks possibilitam uma visão mais alto nível destas questões. Nesta
dissertação, foi visto como estes frameworks oferecem serviços que simplificam o
desenvolvimento de groupwares. Tomando uma abordagem em camadas, foram
vistos frameworks usados na camada de negócios e frameworks usados na camada
de apresentação.
Ao buscar por frameworks para lidar com determinada questão de infraestrutura muitas vezes o arquiteto de software se depara com diversos frameworks
similares que se propõe a realizar a mesma coisa. A leitura da documentação do
fabricante pode ajudar na escolha, mas muitas vezes as informações fornecidas
pelo fabricante são subjetivas. Realizando uma análise técnica, possivelmente
implementando uma prova de conceito, o arquiteto obtém indícios sobre qual
framework atende melhor a suas necessidades. Entretanto nem sempre a
implementação da prova de conceito é possível devido à limitação natural de
tempo e recursos que todo projeto tem.
190
Além de identificar se o framework atende às necessidades técnicas do
projeto, há outros fatores importantes que devem ser considerados. É importante
saber se há documentação disponível, se há suporte disponível, se há ferramentas
compatíveis com o framework, se o framework está sendo usado por outras
instituições e se há profissionais aptos a trabalhar com o framework. Estas
questões não-técnicas usualmente são tão importantes quanto as questões técnicas,
principalmente no caso do AulaNet devido à rotatividade de desenvolvedores no
LES e a integração com a equipe da EduWeb. Esta dissertação apresentou uma
forma de comparar estes fatores.
Na camada de negócios, as principais questões de infra-estrutura resolvidas
por frameworks são: persistência de dados, gerenciamento de transações,
gerenciamento de segurança e exposição de serviços remotamente. Estas questões
são tratadas no framework de componentes Enterprise Java Beans (EJB) e, por
isso, ele foi avaliado como opção.
Após a análise técnica do EJB chegou-se a conclusão que ele apresentava
inúmeras desvantagens. É preciso manter uma grande quantidade de arquivos para
realizar manutenção em um componente EJB. Componentes EJB dependem de
servidores de aplicação que possuam containeres EJB que geralmente são mais
caros e complexos. Além disso, o modelo EJB resulta em componentes altamente
intrusivos e consequentemente mais difíceis de serem testados unitariamente. As
restrições de programação impostas pela especificação EJB 2.1 impossibilitam a
realização de atividades corriqueiras. A especificação EJB 3.0 vem se inspirado
em um modelo de POJOs e frameworks como o Hibernate para solucionar estas
questões mas, como seu futuro é incerto, optou-se por seguir uma arquitetura de
POJOs com frameworks.
Para tratar a persistência de dados e dos desafios decorrentes do conflito dos
paradigmas Objeto/Relacional, é usado o framework Object Relational Mapping
(ORM) Hibernate (2005). Antes de adotar o Hibernate foi realizada uma análise
técnica onde foram analisadas as características deste framework. Após a
implementação de uma prova de conceito, um protótipo do serviço Conferências
do AulaNet, percebeu-se que este framework supria as necessidades de
persistência do AulaNet.
Após a análise técnica foi realizada a análise não-técnica, que iniciou-se
pela seleção dos concorrentes. Os frameworks ORM iBATIS (2005), Apache OJB
191
(OJB, 2005) e JDOMax (2005), uma implementação da especificação JDO (2005)
são soluções de mapeamento completo (Fussel,1997) e gratuitos. A análise
determinou o Hibernate como o framework com mais documentação disponível,
com mais suporte disponível (é a comunidade mais ativa e possui suporte pago),
com mais ferramentas compatíveis, com mais empresas usando e com mais
profissionais aptos a trabalhar com ele disponíveis no mercado. Como os outros
não apresentavam nenhuma vantagem técnica significativa, a escolha do
Hibernate se manteve.
Para solucionar às questões de gerenciamento de transações, gerenciamento
de segurança e exposição de serviços remotamente, foi escolhido o framework
Spring (2005). A análise técnica mostrou que o Spring fornecia meios para lidar
com estas questões e, além disso, fornecia um módulo de Dependency Injection
que torna os componentes mais fracamente acoplados e mais fáceis de serem
testados unitariamente. Spring possui também um módulo de Programação
Orientada a Aspectos, possibilitando que pesquisas nesta área sejam realizadas
com o AulaNet. Spring também integra-se ao Hibernate, facilitando o seu uso.
O Spring também se manteve após a na análise não-técnica. Foram
encontrados 4 frameworks gratuitos com características similares ao Spring:
Avalon (2005), que se transformou no projeto Excalibur (2005), o HiveMind
(2005), NanoContainer (2005) e o PicoContainer (2005). A análise mostrou que o
Spring é superior em todas as categorias e, novamente, a escolha se manteve.
Na camada de apresentação, há uma família de frameworks denominada
web frameworks que oferecem uma implementação do padrão de projetos Model
View Controller (MVC) (Fowler, 2002), além de tratar também desafios
decorrentes do uso do HTML na construção de interfaces com o usuário. Estimase que há 54 web frameworks disponíveis gratuitamente na plataforma Java
(Manageability, 2005). Devido ao grande número de web frameworks disponíveis,
foi preciso adotar uma outra abordagem. Foram selecionados 3 para serem
analisados tecnicamente. O Struts (2005), por ser o mais popular, o Spring MVC,
módulo do framework Spring (2005), por ter sido escolhido para a camada de
apresentação, e o JavaServer Faces (JSF) (2005), por especificar um modelo de
componentes e ser um padrão da Sun.
A análise técnica indicou cada um com suas vantagens. O Spring MVC, o
menos intrusivo de todos, o Struts, com o melhor módulo de validação de entrada
192
de dados e o JSF sendo o único dos três a especificar um modelo de componentes.
Após a análise técnica, escolheu-se o JSF, pois ele aparenta ser um modelo de
componentes promissor e porque começa a se desenhar um mercado de
componentes JSF com o surgimento de projetos como MyFaces (2005) e
WebGalileo Faces (WebGalileo, 2005), que são gratuitos, e o WebCharts (2005),
que é comercial. Alguns destes componentes, como o editor HTML encontrado no
projeto MyFaces, atendem a demandas atuais de usuários do AulaNet.
Ao realizar a análise não-técnica notou-se que Struts liderou todas as
categorias exceto a categoria de ferramentas compatíveis. JSF, que liderou esta
categoria, ficou em segundo lugar em todas as outras exceto a categoria de
disponibilidade de suporte onde foi terceiro. JSF foi também o framework cujo
número de oportunidades requerendo habilidade no framework mais cresceu ao
longo das pesquisas. O bom desempenho do JSF na análise técnica foi crucial para
que ele se mantivesse como escolha para a camada de apresentação. Mesmo tendo
a sua primeira versão estável lançada em 2004, JSF ficou atrás apenas do Struts,
que parece ser o web framework mais aceito atualmente, mas que não define um
modelo de componentes e por isso não será usado.
Apesar da arquitetura do AulaNet 3.0 prever apenas estes 3 frameworks, é
possível incorporar outros frameworks, oferecendo infra-estrutura para tratar
questões não previstas. Nesta dissertação foi visto como incorporar o framework
de agentes Jade a arquitetura do AulaNet 3.0. Para integrar um novo framework
na camada de negócios da arquitetura do AulaNet 3.0 é preciso integrá-lo ao
Spring. Como o String não é intrusivo e é baseado em boas práticas, como a
programação para interfaces (Bloch, 2005) e encapsulamento através de
propriedades JavaBeans (2005), normalmente isto não é um problema. Como
visto nesta dissertação, o Jade pode ser integrado à arquitetura através de um
adaptador construído com poucas classes, possibilitando o uso de agentes de
software no AulaNet tanto para fins de pesquisa quanto para fins de mercado.
Além disso, através dos Proxys remotos do Spring é oferecido suporte a
aplicações móveis. Com a nova arquitetura, é possível integrar o AulaNet e o
AulaNetM, extensão do AulaNet para dispositivos móveis, no nível de serviços,
aumentando o reuso entre os dois projetos.
Desenvolver groupware é complexo e não deveria se tornar mais complexo
devido a aspectos de infra-estrutura de baixo nível como persistência de dados,
193
gerenciamento de transações, etc. Frameworks de infra-estrutura simplificam estes
aspectos ao tratarem os problemas em baixo nível e fornecerem interfaces em alto
nível. Estes frameworks são projetados e desenvolvidos por especialistas nesta
área enquanto que os componentes de groupware são projetados por especialistas
em groupware.
Esta pesquisa mostrou como uma arquitetura em três camadas pode se
beneficiar pelo uso de frameworks de infra-estrutura. Mostrou-se também uma
forma de avaliar frameworks que leva em conta tanto aspectos técnicos quanto
não-técnicos. Espera-se que esta pesquisa possa auxiliar arquitetos de groupware e
de software a construir aplicações, auxiliando na tomada de decisões sobre a
estruturação da arquitetura técnica e na escolha de frameworks de aplicação que
tratem de aspectos de infra-estrutura de baixo nível. Espera-se também que este
trabalho guie os desenvolvedores LES/EduWeb na construção do AulaNet 3.0,
para que este possa continuar rendendo mais uma década de pesquisas e
aprendizagem.
7
Referências Bibliográficas
Alur D., Crupi & J., Malks, D. (2001): Core J2EE Patterns: Best Practices and
Design Strategies. Publisher: Prentice Hall / Sun Microsystems Press, 2001.
Ambler, S. (2002): Mapping Objects to Relational Databases. AmbySoft Inc.
Artigo disponível em <www.ambysoft.com/mappingObjects.html>. Última visita
em 28/11/2005.
Avalon (2005): Página oficial do framework Avalon
<http://avalon.apache.org/>. Última visita em 11/12/2005.
disponível
em
Barreto, C. G., Fuks, H. & Lucena, C. J. P. (2005): Agregando Frameworks em
uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente
AulaNet. Anais do 5º Workshop de Desenvolvimento Baseado em Componentes WDBC 2005, 7-9 de novembro de 2005, Juiz de Fora, MG, ISBN 85-88279-47-9,
pp. 25-32.
Beck, K. (2004): Programação extrema explicada: acolha as mudanças. Porto
Alegre: Bookman.
Bellifemine, F., Caire, G., Poggi, A. & Rimassa, G. (2003): Jade – A White Paper.
EXP in search of innovation Volume 3 - n. 3 - September 2003– Special issue on
Jade.pp. 6-19.
Bellifemine, F., Caire, G., Trucco & T, Rimassa, G. (2005): Jade Programmer’s
guide, 2005.
Bloch, J. (2002): Effective Java Programming Language Guide. Addison Wesley,
2002.
Brown, S., Dalton, S., Jepp, D., Johnson, D., Li, S., Raible, M. (2005): Pro JSP,
Fourth Edition, Appress, 2005.
Buschmann, F., Meunier, R., Rohnert, H., Sommerland, P. & Stal, M (1996):
Pattern-Oriented Software Architectur A System of Patterns, John Wiley & Sons,
1996
Caire, C. (2003): Jade Tutorial - Jade Programming for Beginners, 2003.
Caire, C. (2005): Leap User Guide, 2005.
Caucho (2005): Página oficial do grupo Caucho
<http://www.caucho.com/>. Última visita em 11/12/2005.
disponível
em
Cheesman, J. e Daniels, J. (2001): UML Components. EUA: Addison-Wesley,
2001
Cocoon (2005): Página oficial do framework Cocoon disponível em
<http://cocoon.apache.org/>. Última visita em 2/11/2005.
Capítulo 7. Referências
195
CrEme (2005): Página oficial da máquina virtual J2ME/CDC/Personal Profile
CrEme dispónivel em <http://www.nsicom.com/Default.aspx?tabid=138>. Última
visita em 5/1/2006.
Drogoul, A. & Ferber, J. (1992): Multi-Agent Simulation as a Tool for Modeling
Societies: Application to Social Differentiation in Ant Colonies. In:
preproceedings MAAMAW92: 4th European Workshop on Modelling
Autonomous Agents in a Multi-Agent World, Italy.
D’Souza, D. F. & Wills, A. C. (1998): Objects, Components, and Frameworks
with UML : The Catalysis Approach. Addison Wesley, 1998.
EduWeb
(2005):
Site
da
empresa
EduWeb
disponível
em
<http://www.eduweb.com.br/portugues/home.asp>. Última visita: 18/03/2006.
EJB (2003): Sun Microsystems Enterprise JavaBeans Specification, Version 2.1,
Novembro de 2003.
EJB (2005): Enterprise JavaBeans. Site oficial disponível
<http://java.sun.com/products/ejb/index.jsp>. Última visita em 20/10/2005.
em
Excalibur (2005): Página oficial do framework Excalibur disponível em
<http://excalibur.apache.org/>. Última visita em 11/12/2005.
Fayad, M. E. & Schmidt, D. C. (1997): Object-oriented application frameworks,
Communications of the ACM, v.40 n.10, p.32-38, Oct. 1997
Fayad, M. E., Schimidt & D. C., Johnson, R. E. (1999a): Implementing
application frameworks: object-oriented frameworks at work. New York: J.
Wiley, c1999. 729 p. ISBN 0471252018.
Fayad, M. E., Schimidt & D. C., Johnson, R. E. (1999b): Building application
frameworks: object-oriented foundations of framework design. New York: J.
Wiley, c1999. 664 p. ISBN 0471248754.
Fayad, M. E. & Johnson, R. E. (2000): Domain-specific application frameworks:
frameworks experience by industry. New York: J. Wiley, c2000. 681 p. ISBN
0471332801.
Filippo,D., Fuks, H. & Lucena, C. J. P. (2005a): AulaNetM: Extension of the
AulaNet Environment to PDAs, CONTEXT 2005, 5th International and
Interdisciplinary Conference on Modeling and Using Context, Workshop 10:
Context and Groupware, CEUR Workshop Proceedings, ISSN 1613, vol 133,
Paris, France, 5-8 July, 2005.
Filippo., D., Fuks, H. & Lucena, C. J. .P. (2005b): AulaNetM: Extensão do
Serviço de Conferências do AulaNet destinada a usuários de PDAs, Anais do XVI
Simpósio Brasileiro de Informática na Educação – SBIE 2005, 07-11 de
Novembro, Juiz de Fora, MG, ISBN 85-88279-48-7, pp. 623-633.
FIPA (2005): Página oficial da organização
<http://www.fipa.org/>. Última visita em 5/1/2006.
FIPA
disponível
em
Fowler, M. (2002): Patterns of Enterprise Application Architecture. AddisonWesley, 2002
Fowler, M. (2004): Inversion of Control Containers and the Dependency Injection
pattern: Artigo disponível em <http://martinfowler.com/articles/injection.html>.
Última visita em: 2/11/2005.
196
Froehlich, G., Hoover, H. J., Liu, L. & Sorenson, P. (1997a): Hooking into
Object-Oriented Application Frameworks, To appear in the Proceedings of the
1997 International Conference on Software Engineering. Boston (May 1997).
Froehlich, G., Hoover, H. J., Liu, L. & Sorenson, P. (1997b): Reusing Application
Frameworks Through Hooks, Communications of the ACM special issue on
object-oriented frameworks, 1997.
Fuks, H., Gerosa, M. A. & Lucena, C. J. P. (2002): The Development and
Application of Distance Learning on the Internet, The Journal of Open and
Distance Learning, Vol. 17, N. 1, ISSN 0268-0513, Fevereiro 2002, pp. 23-38.
Fuks, H., Raposo, A. B., Gerosa, M.A. (2002): Engenharia de Groupware:
Desenvolvimento de Aplicações Colaborativas, XXI Jornada de Atualização em
Informática, Anais do XXII Congresso da Sociedade Brasileira de Computação,
V2, Cap. 3, ISBN 85-88442-24-8, pp 89-128, 2002.
Fuks, H., Gerosa, M. A., Pimentel, M. G., Raposo, A. B., Mitchell, L. H. R. G. &
Lucena, C. J. P. (2003): Evoluindo para uma Arquitetura de Groupware Baseada
em Componentes: o Estudo de Caso do Learningware AulaNet, WDBC 2003 - III
Workshop de Desenvolvimento Baseado em Componentes, Anais Eletrônicos,
São Carlos-SP, 10 a 12 de setembro de 2003.
Fuks, H., Raposo, A. B., Gerosa, M.A., Lucena, C. J. P. (2005) Applying the 3C
Model to Groupware Development, International Journal of Cooperative
Information Systems (IJCIS), v.14, n.2-3, Jun-Sep 2005, World Scientific, pp.
299-328.
Fussel, M. L. (1997): Foundations of Object Relational Mapping. ChiMu
Coorporation.
Artigo
disponível
em
<www.chimu.com/publications/objectRelational/>. Última visita em 28/11/2005.
Fussel, S. R., Kraut, R. E., Learch, F. J., Scherlis, W. L., Mcnally, M. M., Cadiz,
J. J. (1998): Coordination, overload and team performance: effects of team
communication strategies, Proceedings of CSCW '98, Seattle, USA, p. 275-284.
ISBN 1-58113-009-0.
Gamma, E., Helm, R., Johnson & R., Vlissides, J. (1995): Design patterns:
elements of reusable object-oriented software. Addison-Wesley, Reading, MA,
1995.
Geary, D. & Horstmann, C. (2005): Core JavaServer Faces, Sun Microsystems,
Inc, 2005.
Gerosa (2006): Desenvolvimento de Groupware Componentizado Baseado no
Modelo 3C de Colaboração. Tese de doutorado a ser defendida em 16/03/2006.
Gerosa, M. A., Barreto, C. G., Raposo, A. B., Fuks, H. & Lucena, C. J. P. (2004):
O Uso de uma Arquitetura Baseada em Componentes para Incrementar um
Serviço do Ambiente AulaNet. Anais do 4º Workshop de Desenvolvimento
Baseado em Componentes - WDBC 2004, 15-17 de Setembro, João Pessoa-PB,
ISBN 85-7669-001-2, pp. 55-60, 2004.
Gerosa, M. A., Pimentel, M., Filippo, D., Barreto, C. G., Raposo, A. B., Fuks, H.
& Lucena, C. J. P. (2005): Componentes Baseados no Modelo 3C para o
Desenvolvimento de Ferramentas Colaborativas. Anais do 5º Workshop de
197
Desenvolvimento Baseado em Componentes - WDBC 2005, 7-9 de novembro de
2005, Juiz de Fora, MG, ISBN 85-88279-47-9, pp. 109-112.
Gimenes, I. M. S (org.), & Huzita, E.H.M (org.) (2005): Desenvolvimento
Baseado em Componentes: Conceitos e Técnicas. Rio de Janeiro: Ciência
Moderna, 2005.
Hibernate (2005): Página oficial do framework Hibernate disponível em
<http://www.hibernate.org/>. Última visita em 20/10/2005.
HiveMind (2005): Página oficial do framework HiveMind disponível em
<http://jakarta.apache.org/hivemind/>. Última visita em 11/12/2005.
iBATIS (2005): Página oficial do framework Hibernate disponível em
<http://ibatis.apache.org/>. Última visita em 10/12/2005.
Ierusalimschy, R., Figueiredo, L.H. & Celes, W (1996). Lua – an extensible
extension language. Software: Practice & Experience, 26(6), 635-652.
Interface 21 (2005): Página oficial da empresa Interface 21 disponível em
<http://www.springframework.com/>. Última visita em 2/11/2005.
J2ME (2005): Página oficial da tecnologia J2ME disponível
<http://java.sun.com/j2me/index.jsp>. Última visita em 3/1/2006.
em
Jacobson, I. & Ng, P. (2004): Aspect-Oriented Software Development with Use
Cases. Addison-Wesley, 2004.
Jade (2005): Página official do framework Java Agent Development (Jade)
disponível em <http://jade.tilab.com/>. Última visita em 2/1/2006.
JavaBeans (2005): Especificação
<http://java.sun.com/beans>.
do
padrão
JavaBeans
disponível
em
JBoss (2005): Página oficial do servidor de aplicações JBoss disponível em
<http://www.jboss.com/developers/index>. Última visita em 20/11/2005.
JDBC (2005): Documentação da tecnologia JDBC disponível
<http://java.sun.com/products/jdbc/index.jsp>. Última visita em 28/11/2005.
em
JDO (2005): Documentação da tecnologia Java Data Objects (JDO) disponível em
< http://java.sun.com/products/jdo/index.jsp>. Última visita em 28/11/2005.
JDOMax (2005): Documentação do framework JDOMax disponível em
<http://www.jdomax.com/index.html>. Última visita em 10/12/2005.
JNDI (2005): Documentação da tecnologia
<http://java.sun.com/products/jndi/index.jsp >.
JNDI
disponível
em
Johnson, R. E & Foote, B. (1988): Designing Reusable Classes, Journal of
Object-Oriented Programming, June 1988.
Johnson, R. E. (1991): Reusing Object-Oriented Design, University of Illinois,
Technical Report UIUCDCS 91-1696, 1991.
Johnson, R. (2002): Expert One-on-One J2EE Design and Development. Reading:
Wiley Publishing Inc., 2002.
Johnson, R. (2004): Expert One-on-One J2EE Development without EJB. Wiley
Publishing Inc., 2004.
198
JSF (2005): JavaServer Faces. Implementação de referência da Sun disponível em
<http://java.sun.com/j2ee/javaserverfaces/>. Última visita em 8/10/2005.
JSR 220 (2005): JSR 220: Enterprise JavaBeansTM,Version 3.0 - Sun
Microsystems Enterprise JavaBeans Specification, Version 3.0, Junho de 2005.
JTA (2005): Documentação da tecnologia Java Transaction API (JTA) disponível
em <http://java.sun.com/products/jta/index.html>. Última visita em 10/12/2005.
Kinshuk & Lin T. (2004). Improving mobile learning environments by applying
mobile agents technology. Third Pan Commonwealth Forum on Open Learning,
4-8 July 2004, Dunedin, New Zealand.
King, G. & Bauer, C. (2005): Hibernate in Action. Manning Publishing Co., 2005.
Lalonde, W (1994): Discovering Smalltalk. The Benjamin/Cummings Publishing
Company, Inc, 1994.
Larman, C. (2004) Utilizando UML e Padrões: Uma introdução à análise e ao
projeto orientados a objetos e ao Processo Unificado, 2ª edição, Bookman, Porto
Alegre.
Lucena, C. J. P., Fuks, H. (2000) Professores e Aprendizes na Web: A Educação
na Era da Internet. Rio de Janeiro, Editora Clube do Futuro, 2000.
Lundberg, C. & Mattsson, M. (1996): On Using Legacy Software Components
with Object-Oriented Frameworks, Proceedings of Systemarkitekturer'96, Borås,
Sweden, 1996.
Mackinnon, T., Freeman & S., Craig, P. (2000): Endo-Testing: Unit Testing with
Mock Objects. Artigo publicado na conferência “eXtreme Programming and
Flexible Processes in Software Engineering - XP2000”.
Manageability (2005): Artigo “How Many Java Web Frameworks Can You
Name?” disponível em <http://www.manageability.org/blog/stuff/how-manyjava-web-frameworks/view>. Última visita em 9/10/2005.
MarketShare (2006): Market Share by Net Applications. Comparação de
participação de Mercado entre os navegadores. Artigo disponível em
<http://marketshare.hitslink.com/>. Última visita em 5/2/2006.
Mattsson, M. (1996): Object-oriented Frameworks - A survey of methodological
issues”, Licentiate Thesis, Department of Computer Science, Lund University,
CODEN: LUTEDX/(TECS-3066)/1-130/(1996), also as Technical Report, LUCS-TR: 96-167, Department of Computer Science, Lund University, 1996.
Mattsson. M. (2000): Evolution and Composition Object-Oriented Frameworks,
PhD Thesis, University of Karlskrona/Ronneby, Department of Software
Engineering and Computer Science, 2000.
Modi, P. J., Veloso, M., Smith, S. F. & Oh, J. (2004) CMRadar: A Personal
Assistant Agent for Calendar Management. In 6th International Workshop on
Agent-Oriented Information Systems (AOIS), pages 134-148, 2004.
MyFaces
(2005):
Página
oficial
do
MyFaces
<http://myfaces.apache.org/>. Última visita em: 25/10/2005.
disponível
em
NanoContainer (2005): Página oficial do framework NanoContainer disponível
em <http://nanocontainer.codehaus.org/>. Última visita em 11/12/2005.
199
Oberon (2005): Oberon Microsystems, Inc., BlackBox Developer and BlackBox
Component Framework, URL <http://www.oberon.ch/>. Última visita em
26/12/2005.
OJB (2005): Página oficial do framework Apache OJB disponível em
<http://db.apache.org/ojb/>. Última visita em 10/12/2005.
OpenDoc (2005): Documentação do framework de componentes OpenDoc
disponível
em
<http://developer.apple.com/documentation/macos8/Legacy/OpenDoc/opendoc.ht
ml>. Última visita em 26/12/2005.
Philippe, K. (2003): Introdução ao RUP – Rational Unified Process. Rio de
Janeiro: Ciência Moderna.
PicoContainer (2005): Página oficial do framework PicoContainer disponível em
<www.picocontainer.org/>. Última visita em 11/12/2005.
Pimentel (2006): RUP – 3C – Groupware: Processo de Desenvolvimento de
Groupware Baseado no Modelo 3C de Colaboração. Tese de doutorado a ser
defendida em 22/03/2006.
Pimentel, M., Gerosa, M. A., Filippo, D., Barreto, C. G., Raposo, A. B., Fuks, H.
& Lucena, C. J. P. (2005): AulaNet 3.0: desenvolvendo aplicações colaborativas
baseadas em componentes 3C. WCSCW 2005 - Workshop Brasileiro de
Tecnologias para Colaboração, 7 e 8 de Novembro 2005. Em Anais XVI
Simpósio Brasileiro de Informática na Educação, v. 2, ISBN 85-88279-48-7. Juiz
de Fora - MG: UFJF, 8 a 11 de Novembro 2005. p. 761-770.
Pinto, S. C. C. S. (2000): Composição em WebFrameworks, tese de doutorado,
Departamento de Informática PUC-Rio.
POJO (2005): Trecho do blog do Martin Fowler onde o termo Plain Old Java
Object
é
explicado
disponível
em
<http://www.martinfowler.com/bliki/POJO.html>. Última visita em 20/10/2005.
Pree, W. (1995): Design Patterns for Object-Oriented Software Development,
Addison-Wesley, 1995.
Raible, M. (2004): Spring Live. Sourcebeat, LLC, ISBN: 0974884375, 2004.
Raible, M. (2005): Java Web Frameworks,
<http://www.virtuas.com/osl-jwf-01.pdf>.
artigo
disponível
em
Ramachandran, V. (2002): Design Patterns for Building Flexible and
Maintainable
J2EE
Applications.
Artigo
disponível
em
<http://java.sun.com/developer/technicalArticles/J2EE/despat/index.html>.
Última visita em: 2/11/2005.
Raposo, A. B., Magalhães, L. P., Ricarte, I. L. M., Fuks, H. (2001): Coordination
of collaborative activities: A framework for the definition of tasks
interdependencies. 7th International Workshop on Groupware - CRIWG 2001,
170-179, 2001.
Rezende, J. L. (2003): Aplicando Técnicas de Comunicação para a Facilitação de
Debates no Ambiente AulaNet. Dissertação de Mestrado, Departamento de
Informática, Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio),
março 2003.
200
Ripper, P. S., Fontoura, M. F., Neto, A. M. & Lucena, C. J. P. (2000): V-Market:
A framework for agent e-commerce systems, World Wide Web, Volume 3, Issue
1, Mar 2000, Pages 43 - 52
RMI-IIOP (2005): Documentação da tecnologia RMI-IIOP disponível em
<http://java.sun.com/products/rmi-iiop/>. Última visita em 20/10/2005.
Santoro, F., Borges, M. & Santos, N. (1999): Computer-Supported Cooperative
Learning Environments: A Framework for Analysis. In Kommers, P., & Richards,
G. (Eds.), Proceedings of World Conference on Educational Multimedia,
Hypermedia and Telecommunications 1999 (pp. 62-67). Chesapeake, VA: AACE.
Sharp R., Fancellu, D. & Stephens M. (2002): EJB's 101 Damnations. Artigo
disponível em <http://www.softwarereality.com/programming/ejb/index.jsp>.
Última visita em 10/12/2005.
Sommerville, I. (2003): Engenharia de Software. 6 ed. São Paulo: Addison
Wesley, 2003.
Singh, I., Stearns, B., Brydon, S., Murray, G. & Ramachandran, V. (2004):
Designing Web Services with J2EE 1.4 Plataform. Pearson Education, 2004.
SJCC (2006): Sun Java Code Conventions (SJCC). Documento que especifica
convenções de código disponível em <http://java.sun.com/docs/codeconv/>.
Shoham, Y. (1993). Agent-oriented programming. Artificial Intelligence,
60(1):51-92.
Spring (2005): Página oficial do framework Spring disponível
<http://www.springframework.org/>. Última visita em 9/10/2005.
em
Struts (2005): Página oficial do framework Struts
<http://struts.apache.org/>. Última visita em 9/10/2005.
em
disponível
SuperWaba (2005): Página official da tecnologia SuperWaba disponível em
<http://www.superwaba.com.br/en/default.asp>. Última visita em 3/1/2006.
Szyperski, C., Bosch, J. & Weck, W. (1997): Sumary of the Second International
Workshop on Component-Oriented Programming. In: Second International
Workshop on Component-Oriented Programming (WCOP'97), 1997, Jyväskylä.
Szyperski, C. (1997): Component Software: Beyond
Programming, Addison-Wesley, ISBN 0-201-17888-5
Object-Oriented
Tapestry (2005): Página oficial do framework Tapestry disponível em
<http://jakarta.apache.org/tapestry/index.html>. Última visita em 2/11/2005.
Tate, B., Clark, M., Lee, B. & Linskey, B. (2003): Bitter EJB. Manning
Publications Co, 2003.
Tomcat (2005): Página oficial do servidor de aplicações Tomcat disponível em
<http://tomcat.apache.org/>. Última visita em 20/11/2005.
Topley, K. (1999): Core Swing: Advanced Programming. Pearson Education,
1999.
Torres, V. S. & Lucena, C. J. P. (2001): Um modelo orientado a objetos para
sistemas multi-agentes. 14 p. Port. PUC-RioInf.MCC30/01.
VirtuaS (2006): Página oficial da empresa VirtuaS
<http://www.virtuas.com/>. Última visita em 14/01/2006.
201
disponível
em
Walls, C. & Breidenbach, R. (2005): Spring in Action. Manning Publishing Co.,
2005.
WebCharts (2005): Biblioteca de Componentes Adicionais JSF WebCharts
disponível em <http://www.webcharts3d.com/>. Última visita em 22/11/06.
WebGalileo (2005): Biblioteca de Componentes Adicionais JSF WebGalileo
Faces disponível em <http://www.jscape.com/webgalileofaces/index.html>.
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
204
posted in foruns or mailing list in a given period of time.
I was able to collect the number of messages posted on all web frameworks and
dependency injection frameworks mailing lists but I couldn’t count the number of
messages posted in the Spring forum because the interface of the forum don't list
the messages in a given month.
Can you, or anyone working with Spring, or somebody you know working at
www.springframework.org web site, count the number of messages posted in
November/2005 at springframework.org forum, and the amount of messages
posted on the Web thread in July/2005 on the springframework.org forum? Or
maybe you can put me with contact with the administrators of the forum that
probably have access to some kind of administrator interface of the Forum or can
mak e a select statement direct on the database? It would add value for the
comparison and form my research.
Best regards,
Celso Gomes Barreto
No mesmo dia Rod Johnson respondeu com cópia para Colin Sampaleanu,
um de seus funcionários. O texto de sua resposta é transcrito a seguir.
Colin,
Is this info easy to get at?
Rgds
Rod
Colin Sampaleanu respondeu também no mesmo dia. O texto de sua
resposta é transcrito a seguir.
I don't think I can get it through the vBulletin management interface, on a month
by month basis, but I may be able to do it via a SQL Query. To some extent that
depends on the schema. I'll take a look this weekend...
Infelizmente não houve resposta desde então, o que leva a crer que Colin
Sampaleanu não conseguiu recuperar os dados.
205
A.3.
Comunicação com Matt Raible
Matt Raible é consultor J2EE para a empresa VirtuaS (2006), autor dos livro
Spring Live (Raible, 2004) e co-autor do livro Pro JSP (Brown et al., 2005).
Raible também possui um blog onde discute assuntos técnicos que recebe mais de
três milhões de visitas por mês, disponível em http://raibledesigns.com.
Raible escreveu o artigo Java Web Frameworks (Raible, 2005) onde vários
web frameworks são comparados. Este arquivo serviu como base para as
comparações demográficas realizadas ao longo desta dissertação. Como os
gráficos do artigo original eram coloridos e não seguiam o mesmo layout dos
outros gráficos usados na dissertação, foi preciso entrar em contato com Raible
para obter os dados originais da pesquisa. O e-mail enviado para M. Raible em
2/11/2005 com o assunto Java Web Frameworks é transcrito a seguir.
Dear Matt,
I read your article “Java Web Frameworks” and I found it very good, specially
the part where you compare the articles/books published, jobs counts, tools
available, traffic in mailing lists and resumes posted. In fact, I am willing to
quote your research in my master’s degree dissertation. My problem is that I
can’t just copy and paste your graphics because the have to be black and white
(dissertations are printed in black and white in my university) and they have to
follow the pattern of the other graphics I am using (I made a research similar you
had in resume/employees sites in my country). I would be very glad if you could
send me the raw data you used to build your graphics so that I can reproduce
them with precision.
I am a master degree student in the IT department of PUC-Rio
(http://www.inf.puc-rio.br), a highly prestigious university in Brazil. I am also
member
of
a
group
that
makes
studies
about
groupware
(http://groupware.les.inf.puc-rio.br/). My dissertation is about “Applying IntraInfrastructure Frameworks to Groupware Systems” with a study case on AulaNet,
a learningware environment we develop and use since 1997. In the chapter about
Web Frameworks I investigate a set of web frameworks and in the end of the
chapter I choose the one that best fits the AulaNet needs. Your research fits well
in this chapter because it gives me a non-technical way to compare the web
frameworks.
Yours faithfully,
Celso Gomes Barreto
206
Raible respondeu no mesmo dia, oferecendo o arquivo com seus gráficos
em dois formatos: Keynote ou PowerPoint, de onde os dados de sua pesquisa
poderiam ser extraídos. O texto de seu e-mail é transcrito a seguir.
Do you have a Mac with Keynote - or possible PowerPoint? If so, I can send you
a presentation with the graphs so you can see the raw data.
Matt
No dia 3/11/2005 respondi ao Matt, agradecendo a rápida resposta e
solicitando o arquivo em formato PowerPoint. O texto deste e-mail é transcrito a
seguir.
Hi Matt
Thanks for your quick answer.
I have access to a machine with PowerPoint installed so PowerPoint would be
fine.
Thanks a lot.
Yours faithfully,
Celso Gomes Barreto
Novamente Matt respondeu no mesmo dia, enviando o arquivo. Este
continha ainda atualizações referentes à disponibilidade de suporte. A transcrição
do último e-mail enviado por Matt, com o arquivo anexado, é transcrita a seguir.
Hopefully this comes through OK.
Apêndice B
Método Utilizado na Análise Não-Técnica
Nesta dissertação foi utilizado um método de comparação entre frameworks
que considera os seguintes aspectos de mercado: quantidade de documentação
disponível,
disponibilidade
de
suporte,
disponibilidade
de
ferramentas
compatíveis com os frameworks comparados, grau de aceitação no mercado e
disponibilidade de profissionais. O método utilizado nesta análise é baseado em
Raible (2005) é descrito neste apêndice.
B.1.
A categoria “Quantidade de Documentação Disponível” analisa a
quantidade de conteúdo disponível, em forma de livros e tutoriais disponíveis na
internet. Este método de análise não considera a qualidade da documentação.
Para a busca de livros, é realizada uma busca no site de livros
www.amazon.com. A chave de busca utilizada é o nome do próprio framework e
os resultados são analisados um a um, confirmando se o livro trata do assunto
buscado.
Para a busca de tutoriais, é realizada uma busca na ferramenta de buscas
www.google.com. É impossível validar se cada um dos sites retornados pela
busca é realmente um tutorial para o framework desejado, pois a pesquisa pode
retornar milhares de resultados. Por isto, a chave de busca foi elaborada de forma
a minizar o número de resultados falsos.
A chave de busca utilizada para a pesquisa por tutoriais para frameworks
ORM é: “orm framework tutorial nome_do_framework” (todas as páginas que
contenham todas estas palavras, sendo que nome_do_framework é o nome do
framework pesquisado). Já com os frameworks para Dependency Injection foi
utilizada a chave de busca “dependency injection framework tutorial
nome_do_framework”.
Os
dados
apresentandos
correspondem aos dados da pesquisa de Raible (2005).
para
Web
Frameworks
Apêndice B. Método Utilizado na Análise Não-Técnica
208
B.2.
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
209
lista os endereços das listas de discussões e Fóruns considerados na pesquisa dos
frameworks para Dependency Injection.
Framework
Veículo de Suporte
Endereço
Excalibur
Lista de Discussão
http://excalibur.apache.org/mail-lists.html
HiveMind
Lista de Discussão
http://mail-archives.apache.org/mod_mbox/jakarta-hivemind-user/
NanoContainer
Lista de Discussão
http://picocontainer.org/Mailing+lists
Fórum e Lista de
http://forum.springframework.org/
Discussão
e https://lists.sourceforge.net/lists/listinfo/springframework-user
e PicoContainer
Spring
Tabela B.2 – Veículos de Suporte dos Frameworks para Dependency Injection
Os frameworks Excalibur e HiveMind oferecem suporte através de listas de
discussão. Já o NanoContainer e o PicoContainer compartilham a mesma lista de
discussão onde o suporte é oferecido. Por fim, o Spring oferece um Fórum de
discussão oficial e uma lista de discussão não oficial onde o suporte é oferecido.
Para os Web Frameworks, são usados os dados coletados em Raible (2005).
B.3.
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).
210
B.4.
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.

Documento - Groupware@LES - PUC-Rio

Transcrição

Documentos relacionados

Instruções Instalação Software XCPPRO

Apresentação em PDF - Portal Software Livre

- Polis Educacional

framework de aplicações web para plataformas e - FACOM

FESTIVAL LIVRE CAPEZIO 2016 : Suzano TITULOS

Revista de Artigos de Conclusão de Curso Sistemas de

Mercado GIS - GeoNetwork opensource

LEI ORGANICA - Câmara Municipal Analandia

A Reforma Educacional de Nova York

Elementos de geographia e cosmographia

Talento: o desafio da excelência