Este documento descreve um trabalho de conclusão de curso sobre bancos de dados distribuídos em aplicações web. O trabalho apresenta: 1. Uma revisão bibliográfica sobre bancos de dados distribuídos e aplicações web, incluindo definições, arquitetura, funcionamento e segurança. 2. Um estudo de caso para demonstrar a utilização de um banco de dados distribuído em uma aplicação web. 3. Um protótipo desenvolvido para testar o estudo de caso, utilizando um sistema gerenciador de banco de

1. Adriano Giacometti de Souza Lemes
R.A. 0200330 8º Semestre
BANCO DE DADOS DISTRIBUÍDOS EM APLICAÇÕES WEB
Jaguariúna
2005

2. 2
Adriano Giacometti de Souza Lemes
R.A. 0200330 8º Semestre
BANCO DE DADOS DISTRIBUÍDOS EM APLICAÇÕES WEB
Monografia apresentada à disciplina Trabalho
de Conclusão de Curso, do curso de Ciência da
Computação da Faculdade de Jaguariúna, sob
a orientação do Prof. Ms. Leonardo Hartleben
Reinehr, como exigência parcial para a
conclusão do curso de graduação.
Jaguariúna
2005

3. 3
LEMES, Adriano Giacometti de Souza. Banco de Dados Distribuídos em Aplicações Web.
Monografia defendida e aprovada na FAJ e pela banca Examinadora constituída pelos
professores:
_____________________________________________________
Prof. Ms. Leonardo Hartleben Reinehr
Professor Orientador
_____________________________________________________
Prof. Ms. Oderson Dias de Mello
Professor Convidado
_____________________________________________________
Prof. Ms. Roberto Pacheco
Professor Convidado

4. 4
AGRADECIMENTOS
Antes de iniciar a minha lista de agradecimentos, primeiramente gostaria de pedir a
benção de Deus, pois foi através dele que cheguei até esta etapa da minha vida.
Com tudo gostaria de agradecer a todos os que me ajudaram durante esses quatros anos de
sabedoria que obtive, e coisas que acabei aprendendo no caminho percorrido. Agradeço
inicialmente a toda a minha família que me ajudou a chegar e a superar esse desafio de concluir
uma faculdade, onde nos dias de hoje isso esta cada vez mais difícil.
Gostaria de agradecer também a todo o corpo docente da faculdade que de alguma forma
me ensinou pelo menos um pouco o que cada um sabia, e, além disso, demonstrando histórias de
vida, um agradecimento especial vai ao meu orientador Leonardo no qual com muita paciência
me ajudou a preparar esse trabalho feito com tanta dedicação e entusiasmo.
Agradeço também a todos os colegas de sala, em especial o Emerson e o Luciano, que
juntos superamos cada dia de estudo e trabalho trilhando um caminho de conquistas e derrotas,
mas sempre com muito entusiasmo e perseverança.
E por fim um agradecimento a uma pessoa muito especial, Gaciana, na qual me ajudou
com muita paciência e tolerância, nos finais de semana no qual ficávamos o dia inteiro no
computador finalizando cada etapa deste projeto, enfim agradeço a Deus e a todos, por tudo o que
me ajudaram durante esses quatro anos de luta no qual todos nós percorremos, obrigado por tudo
e que Deus proteja a todos nós em cada dia de novos desafios.

5. 5
"VOCÊ MESMO
Lembre-se de que você mesmo é o melhor secretário de
sua tarefa, o mais eficiente propagandista de seus
ideais, a mais clara demonstração de seus princípios, o
mais alto padrão do ensino superior que seu espírito
abraça e a mensagem viva das elevadas noções que
você transmite aos outros. Não se esqueça, igualmente,
de que o maior inimigo de suas realizações mais nobres,
a completa ou incompleta negação do idealismo sublime
que você apregoa, a nota discordante da sinfonia do
bem que pretende executar, o arquiteto de suas aflições
e o destruidor de suas oportunidades de elevação - é
você mesmo."
-- Psicografada por Francisco Cândido Xavier

6. 6
LEMES, Adriano Giacometti de Souza. Banco de Dados Distribuído em Aplicações Web.
Monografia (Bacharelado em Ciência da Computação) – Curso de Ciência da Computação da
Faculdade de Jaguariúna, Jaguariúna.
RESUMO
Atualmente em muitos dos sites que visitamos, em especial os de comércio eletrônico, nos
deparamos com a seguinte pergunta: como um site consegue armazenar uma quantidade tão
grande de informações? A resposta é simples e direta: sempre, por traz de um grande site existe
um banco de dados robusto e seguro armazenando dados confidenciais como, CPF, endereço.
Quando falamos em banco de dados logo imaginamos um computador de grande porte
armazenando centenas de milhares de informações ao mesmo tempo. Essa dedução é verdadeira,
mas às vezes o que não sabemos é que quando efetuamos uma compra em um determinado site,
não sabemos de onde vem aquele produto – por exemplo, em uma rede de lojas de conveniência
as lojas estão espalhadas geograficamente. Nesse exemplo, como é o armazenamento de seus
dados, como cliente, fornecedor, produto, entre outros?
Para que se entenda como as informações dessas lojas referentes aos produtos são recuperadas
usando as informações existentes nas diversas filiais, falaremos sobre bancos de dados
distribuídos, que podem ser utilizados por sites de comércio eletrônico. Uma empresa que utiliza
bancos de dados distribuídos mantém os dados de cada filial em um banco de dados separado,
porém os bancos são capazes de se comunicar entre si. Assim, ao efetuarmos uma compra numa
determinada filial - A, onde não sabemos se nela vai existir o que queremos comprar, por fim ao
consultarmos o produto constatamos que o mesmo tem em estoque e que podemos comprar. Só
que não sabemos se este produto esta na loja A, B, C ou na N-ésima loja, que está espalhada
geograficamente.
O objetivo deste trabalho visa demonstrar através de uma aplicação web a utilização de um banco
de dados distribuído, onde existirá uma única aplicação demonstrando a diferença entre um
SGBD-D e um SGBD. Com essa comparação será possível ampliar os conceitos técnicos de um
banco de dados distribuído em relação ao tradicional, ou seja, o centralizado.
Palavras-chave: banco de dados distribuído, aplicação web

7. 7
SUMÁRIO
1 INTRODUÇÃO..................................................................................................................... 10
2 REVISÃO BIBLIOGRÁFICA .............................................................................................. 12
2.1 Definições............................................................................................................................. 12
2.1.1 Visão geral......................................................................................................................... 13
2.1.2 Funcionamento .................................................................................................................. 15
2.1.2.1 Armazenamento distribuído ........................................................................................... 16
2.1.3 Arquitetura ........................................................................................................................ 16
2.1.3.1 Recursos de SQL............................................................................................................ 17
2.1.4 Autonomia local ................................................................................................................ 18
2.1.4.1 Independência de localização......................................................................................... 18
2.1.4.2 Independência de fragmentação ..................................................................................... 19
2.1.4.3 Independência de replicação .......................................................................................... 22
2.1.4.4 Gerenciamento de transações distribuídas ..................................................................... 24
2.1.5 Gerenciamento .................................................................................................................. 24
2.1.5.1 Tipos de falhas no sistema ............................................................................................. 25
2.1.5.2 Robustez ......................................................................................................................... 26
2.2 Aplicações web .................................................................................................................... 28
2.2.1 Conceitos e visão geral...................................................................................................... 28
2.2.2 Arquitetura ........................................................................................................................ 30
2.2.3 Segurança .......................................................................................................................... 32
2.2.3.1 Tipos de riscos de segurança.......................................................................................... 33
2.2.3.2 Risco técnico .................................................................................................................. 34
2.2.3.3 Estratégias de segurança................................................................................................. 36
2.2.3.4 Criptografia .................................................................................................................... 37
2.3 Banco de dados distribuídos e aplicações web..................................................................... 38
2.3.1 Aplicações distribuídas ..................................................................................................... 39
3 ESTUDO DE CASO ............................................................................................................. 42
3.1 Justificativas e necessidades................................................................................................. 42
3.2 Especificação do problema................................................................................................... 42
3.3 Modelo de dados .................................................................................................................. 43
3.4 Testes.................................................................................................................................... 45
4 PROTÓTIPO ......................................................................................................................... 46
4.1 Projeto .................................................................................................................................. 46
4.1.1 Arquitetura ........................................................................................................................ 46
4.1.2 Projeto do banco de dados................................................................................................. 47
4.2 Implementação ..................................................................................................................... 48
4.2.1 Sistema gerenciador de banco de dados distribuído.......................................................... 49
4.2.2 Linguagem de programação web ...................................................................................... 54
5 RESULTADOS ..................................................................................................................... 57
5.1 Vantagens ............................................................................................................................. 57
5.2 Desvantagens........................................................................................................................ 60
5.3 Comparações ........................................................................................................................ 61
6 CONCLUSÃO....................................................................................................................... 64

8. 8
LISTA DE SIGLAS
API – Application Program Interface
ASP – Active Server Pages
BD – Banco de Dados
BD-D – Banco de Dados Distribuído
BR – Brasil
CA – Certificado de autenticidade
DHTML – Dinamic HiperText Markup Language
DNS – Domain Name Server
EJB – Enterprise Java Beans
FTP – File Transfer Protocol
HMTL – HyperText Markup Language
HTTP – Hyper Text Transfer Protocol
IP – Internet Protocol
JDBC – Java DataBase Connectivity
JP – Japão
JSP – Java Server Pages
LAN – Local Area Network
MTS – Transaction Server Microsoft
ODBC – Open DataBase Connectivity (Base de Dados aberta para conexão)
OSI – Open Systems Interconnections
SET – Secure Electronics Transaction
SGBD - D – Sistema Gerenciador de Banco de Dados Distribuídos
SGBD – Sistema Gerenciador de Banco de Dados
SQL – Structure Query Language
SSL – Secure Sockets
TCP – Transmission Control Protocol
URL – Uniform Resource Locator
VPN – Virtual Private Network
WAN – Wide Area Networks
XML – eXtensible Markup Language

9. 9
LISTA DE FIGURAS
Figura 2.1 – Comunicação entre banco de dados distribuídos geograficamente
Figura 2.1.3 – Um sistema Web acessando um banco de dados
Figura 2.1.4.2 – Um exemplo de fragmentação entre dados de BR e JP e a percepção do usuário
Figura 2.1.4.3 – Um exemplo de replicação
Figura 2.1.5.1 – Topologia de redes de computadores
Figura 2.2.1 – Modelo simples de resposta e requisição entre cliente/servidor
Figura 2.2.3.2 – Redes privativas virtuais
Figura 2.2.3.3 – Posição do firewall
Figura 2.3.1.1 – Representação de uma aplicação distribuída sem acesso à banco de dados
Figura 2.3.1.2 – Representação de uma aplicação distribuída acessando um determinado banco de
dados não-distribuído
Figura 2.3.1.3 – Exemplo de acesso a uma aplicação web com vários bancos interligados.
Figura 2.3.1.4 – Aplicação web acessando BD centralizado
Figura 3.3.1 – Estrutura física do sistema de banco de dados distribuídos
Figura 3.3.2 – Modelo Relacional do estudo de caso
Figura 4.1 – Tela principal onde o usuário define a retirada e a devolução
Figura 4.1.1 – Representação da arquitetura do protótipo do sistema
Figura 4.1.2 – SGBD-D configurado
Figura 4.2.2 – Estrutura de funcionamento de páginas com a tecnologia JSP

10. 10
1 INTRODUÇÃO
Um sistema de banco de dados tradicional é dito centralizado, pois todos os dados estão
armazenados em um único local. Todas as aplicações que necessitam acessar os dados o fazem
por meio de um servidor. [SILBERSCHATZ].
Entretanto, com o crescente desenvolvimento das aplicações distribuídas, tornou-se
necessário acessar os dados armazenados em um banco de dados a partir de diversos locais
diferentes. As diversas filiais de uma empresa, por exemplo, podem armazenar individualmente
os dados que controlam, mas eventualmente os gerentes das filiais necessitam consultar os dados
de todas elas para recuperar algum relatório de toda a empresa. Além disso, diversos bancos de
dados locais passaram a serem vistos como um grupo, cujo conjunto de informações está
acessível como se estivesse armazenado em um único local. Tais necessidades levaram ao
desenvolvimento dos bancos de dados distribuídos [SILBERSCHATZ].
Um Sistema de Gerenciamento de Banco de Dados Distribuído (SGBD-D) consiste de
uma coleção de nós ou sites – pequenos computadores, estações de trabalho, mainframes ou
sistemas de computadores de uso geral, onde cada nó pode participar na execução de transações
que fazem acesso a dados de um ou diversos nós. Os nós que formam um SGBD-D podem se
comunicar por diversos meios, tais como barramentos de alta velocidade e linhas telefônicas.
Assim, a principal diferença entre sistemas de bancos de dados centralizados e distribuídos é que
no primeiro os dados estão armazenados em um único local, enquanto no segundo os dados
residem em diversos locais [SILBERSCHATZ].
Os bancos de dados distribuídos fornecem mecanismos para, a partir de dados situados
em locais diferentes, processar consultas e atualizações de forma transparente, simulando a
existência de um único banco de dados e um único esquema de dados. Isto facilita a visualização
de um conjunto de banco de dados como um único [SILBERSCHATZ].
As aplicações Web podem especialmente se beneficiar da utilização de SGBD-Ds, já que a
World Wide Web (WWW) é o maior sistema distribuído existente. Por isso, é importante avaliar o
impacto da utilização de SGBD-Ds nesse tipo de aplicação.
Para demonstrar a utilização de um SGBD-D, o projeto é dividido em quatro etapas, a
primeira etapa demonstra todas as características de um gerenciador de banco de dados

11. 11
distribuído, definições, visão geral de um SGBD-D, funcionamento, entre outros. E na mesma
etapa, demonstra desde o início de uma aplicação web, ou seja, como surgiu, como funciona, o
que é uma aplicação web, e também a relação com um SGBD-D. Já a segunda parte foi dedicada
ao estudo de caso, demonstrando as justificativas, especificações, modelo dos dados e os testes. A
terceira parte foi desenvolvido o protótipo, sistema responsável pela execução dos testes, nesta
etapa será identificado à arquitetura, projeto dos dados, implementação, qual SGBD escolhido e
qual linguagem de programação utilizada. E já a quarta e última etapa dedicam-se aos resultados
e conclusões, vantagens, desvantagens e o aspecto geral sobre banco de dados distribuído.

12. 12
2 REVISÃO BIBLIOGRÁFICA
Esta seção apresenta os tópicos relacionados a este trabalho, os quais servem de base para
o desenvolvimento do restante do mesmo. Para cada tópico são descritos os principais conceitos
envolvidos, suas características, arquiteturas e outras informações importantes.
2.1 Definições
Um sistema de banco de dados distribuído consiste em um conjunto de sites, ligados entre
si através de algum tipo de rede de comunicações, em que:
- Cada site é um site completo de sistema de banco de dados.
- Porém, os sites atuam juntos, de modo que um usuário em qualquer site pode ter acesso
a dados em qualquer lugar da rede, exatamente como se os dados estivessem armazenados no site
do próprio usuário.
Assim, um banco de dados distribuído é na verdade uma espécie de banco de dados
virtual, no qual seus componentes estão fisicamente armazenados em vários bancos de dados
reais distintos [DATE].

13. 13
Figura 2.1 - Comunicação entre banco de dados distribuídos geograficamente [DATE]
Observe que cada site é ele próprio, do sistema de banco de dados por si mesmo, ou seja,
o sistema de banco de dados distribuído pode, portanto, ser considerado como um tipo de parceria
entre SGBDs individuais locais nos sites locais individuais; um novo componente de software em
cada site - logicamente uma extensão do SGBD local - fornece as necessárias funções da parceria
e é a combinação desse novo componente com o SGBD existente.
A propósito, é comum deduzir que os sites estão fisicamente separados - talvez até
geograficamente. Na verdade, o foco em sistemas distribuídos se deslocou nos últimos anos;
enquanto a maior parte da pesquisa tendia a assumir a distribuição geográfica, a maior parte das
primeiras instalações comerciais envolvia a distribuição local, com (por exemplo) vários sites, no
mesmo edifício e interligados por meio de uma rede local (LAN). Porém, mais recentemente, a
enorme proliferação de redes remotas (WAN) reativou o interesse na possibilidade de
distribuição geográfica. [DATE]
2.1.1 Visão geral

14. 14
Um site pode participar da execução de uma transação global; transações essas que
mantêm acesso em diversos sites. A execução de transações globais exige comunicação entre os
sites [CONNALEM].
Há muitas razões para construir um banco de dados distribuído, incluindo o
compartilhamento de dados, confiabilidade, disponibilidade e rapidez no processamento de
consultas. Entretanto, essas vantagens são acompanhadas de muitas desvantagens, como o alto
custo de desenvolvimento de software e o alto potencial de bugs. A principal desvantagem dos
sistemas de bancos de dados distribuídos é a complexidade adicional para a garantir a
coordenação adequada entre os sites.
Um sistema distribuído pode sofrer os mesmos tipos de falhas que um sistema
centralizado. Há, entretanto, tipos de falhas que precisam ser tratados em um ambiente
distribuído, incluindo a falha de um site, a perda de mensagens e o particionamento da rede. Cada
um desses problemas precisa ser considerado no projeto de um esquema de recuperação. Para um
sistema ser robusto de fato, ele precisa detectar qualquer uma dessas falhas, reconfigurar-se de
modo a manter o processamento e recuperar-se enquanto um processador ou uma ligação é
recuperada [DATE].
O protocolo de efetivação em duas fases pode gerar obstrução, situação na qual o destino
de uma transação não pode ser determinado até que um site que falhou (coordenador) tenha se
recuperado.
Os diversos esquemas de controle de concorrência que são usados em sistemas
centralizados podem ser modificados para uso em ambientes distribuídos. Alguns exemplos de
protocolos para o tratamento de dados replicados são o parcial e o de cópia primária. No caso dos
esquemas de registro de tempo (timestamping) e validação, a única mudança necessária é o
desenvolvimento de um mecanismo para a geração de registros de horários únicos globais. Isso
pode ser feito ou pela concatenação do registro de tempo local com a identificação do site ou
adiantando o relógio local sempre que uma mensagem chega com um registro de tempo maior
[DATE].
O principal problema é decidir como manter os gráficos de espera. Os diferentes métodos
para a organização desses gráficos trabalham com enfoques centralizados, hierárquicos e
totalmente distribuídos.
Alguns algoritmos distribuídos precisam de um coordenador. Se o coordenador falhar em
virtude de uma falha do site no qual reside, somente após o reinício do coordenador em algum

15. 15
outro site o sistema poderá continuar processando. Isso pode ser feito por meio da manutenção de
um backup do coordenador [SILBERSCHATZ] que estará pronto a assumir a função no caso de
alguma falha. Outra opção é escolher um novo coordenador, os algoritmos que determinam onde
a nova cópia do coordenador funcionará são chamados de algoritmos de eleição.
Um sistema de banco de dados múltiplo proporciona um ambiente em que novas
aplicações de banco de dados podem manter acesso a dados de diversos bancos de dados
preexistentes, localizados em vários ambientes com hardware e software heterogêneos. Os
sistemas de bancos de dados locais podem empregar modelos lógicos diferentes e linguagens de
definição e manipulação de dados distintos, podem ainda diferir em relação aos mecanismos para
controle de concorrência e gerenciamento de transações. Um sistema de banco de dados múltiplo
cria a ilusão da integração lógica do banco de dados, sem impor uma integração física.
[SILBERSCHATZ]
2.1.2 Funcionamento
Podemos iniciar esse tópico com a seguinte pergunta: por que bancos de dados
distribuídos são desejáveis? A resposta para essa pergunta é que normalmente as empresas já são
distribuídas, pelo menos logicamente (em divisões, departamentos, grupos de trabalho, etc.) e
com grande probabilidade também fisicamente (em fábricas, laboratórios, etc.) - e isso decorre
que os dados também já estão normalmente distribuídos, porque cada unidade organizacional
dentro da empresa necessariamente manterá dados que são relevantes para sua própria operação.
O patrimônio total de informações da empresa é desse modo disseminado naquilo que às vezes se
costuma chamar de ilhas de informações. Um sistema distribuído fornece as pontes necessárias
para interligar essas linhas. Em outras palavras, ele permite que a estrutura do banco de dados
reflita a estrutura da empresa - dados locais podem ser mantidos em instalações locais, às quais
eles pertencem logicamente - enquanto ao mesmo tempo dados remotos estão disponíveis para
acesso quando necessário [SILBERSCHATZ].
Um exemplo esclarecerá o que foi dito. Para simplificar, suponha que há apenas dois sites,
São Paulo e Santa Catarina, e suponha que o sistema é um sistema bancário, com dados de contas
para as contas de São Paulo armazenados São Paulo, e dados de contas para contas de Santa
Catarina armazenados em Santa Catarina. Então, as vantagens são óbvias: o arranjo distribuído
combina eficiência de processamento (os dados são mantidos próximos ao local em que são

16. 16
usados mais freqüentemente) com maior facilidade de acesso (é possível ter acesso a uma conta
em São Paulo, a partir de Santa Catarina e vice-versa, através da rede de comunicações)
[CONNALEM].
Fazer com que a estrutura do banco de dados reflita a estrutura da empresa é
provavelmente (como acabamos de explicar) a principal vantagem de sistemas distribuídos.
Contudo, devemos mencionar que também há algumas desvantagens, das quais a maior é o fato
de sistemas distribuídos serem complexos, pelo menos do ponto de vista técnico.
2.1.2.1 Armazenamento distribuído
Há diversos enfoques para o armazenamento de informações em um banco de dados
distribuído:
• Replicação: o sistema mantém replicas idênticas da relação. Cada replica é armazenada
em diferentes sites, resultando na replicação dos dados. A alternativa para a replicação é
armazenar somente uma cópia de uma determinada relação r.
• Fragmentação: A relação é particionada em diversos fragmentos. Cada fragmento é
armazenado em um site diferente. Podendo se dividir em horizontal, separam-se os registros
(linhas) da tabela; e vertical, separa-se as colunas da tabela.
• Replicação e fragmentação: A relação é particionada em vários segmentos. Os sistemas
mantêm diversas réplicas de cada fragmento. [DATE]
2.1.3 Arquitetura
Um sistema é um sistema distribuído em que: (a) alguns sites podem consultar diversos
dados em lugares distintos, (b) o cliente não sabe em hipótese alguma em que sistema de dados
ele está, (c) todas as aplicações são executadas no mesmo site [CONNALEM].

17. 17
Figura 2.1.3 - Um sistema Web acessando um banco de dados [SILBERSCHATZ]
Lembramos ainda que são possíveis diversas variações sobre o tema básico:
• Vários clientes poderiam compartilhar o mesmo SGBD-D.
• Um único cliente poderia ser capaz de deter acesso a vastos SGBD-D. Esse caso por sua
vez se subdivide em dois outros:
A. O cliente está limitado a obter acesso a um único SGBD-D de cada vez, isto é, cada
solicitação individual de banco de dados deve ser dirigida a um só SGBD-D; não é possível,
dentro de uma única solicitação, combinar dados de dois ou mais SGBD-D.
B. Para o cliente pode aparentar ser um único SGBD-D e o usuário não precisa saber qual
SGBD-D armazena quais fragmentos de dados.
2.1.3.1 Recursos de SQL
Atualmente, a SQL não fornece suporte para sistemas de bancos de dados distribuídos
verdadeiros. É claro que nenhum suporte é exigido na área de manipulação de dados - toda a
importância dos bancos de distribuídos (no que diz respeito ao usuário) está no fato de que os
recursos de manipulação de dados devem permanecer inalterados. Porém, operações de definição

18. 18
de dados como FRAGMENT, REPLICATE, etc., são exigidas, mas não são fornecidas no
momento [SILBERSCHATZ].
Por outro lado, a SQL admite certos recursos, incluindo em particular operações
CONNECT e DISCONNECT para efetuar e desfazer conexões. Na verdade, uma aplicação de
SQL deve executar uma operação CONNECT para se conectar ao servidor antes de poder emitir
quaisquer solicitações de bancos de dados. Depois que a conexão é estabelecida, a aplicação - isto
é, o cliente - pode emitir solicitações de SQL da maneira usual e o processamento de banco de
dados necessário será executado pelo servidor.
A SQL também permite que um cliente já conectado a um servidor se conecte a outro. O
estabelecimento dessa segunda conexão faz a primeira se tornar adormecida; solicitações de SQL
subseqüentes serão processadas pelo segundo servidor, até o momento em que o cliente (a)
alterne para o servidor anterior por meio de outra operação nova, SET CONNECTION ou (b) se
conecte a outro servidor, o que a segunda conexão se tornar adormecida também (e assim por
diante). Em outras palavras, em qualquer instante determinado, um cliente poderá ter uma
conexão ativa e qualquer número de conexões adormecidas, e todas as solicitações de banco de
dados desse cliente serão direcionadas ao servidor [SILBERSCHATZ].
Finalmente, toda conexão estabelecida por um dado cliente (esteja ele ativo ou
adormecido no momento) deve mais tarde ser fechada por meio de uma conexão DISCONNECT
apropriada.
2.1.4 Autonomia local
Os sites em um sistema distribuído devem ser autônomos, significando que todas as
operações em um determinado site são controladas por esse site; nenhum site X deve depender de
algum outro site Y para que sua operação seja bem-sucedida. A autonomia local também implica
que dados locais são de propriedades e gerenciamentos locais, com contabilidade local, todos os
dados “realmente” pertencem a algum banco de dados local, mesmo que sejam acessíveis a partir
de outros sites remotos. Assim, questões como segurança, integridade e representação de
armazenamento de dados locais permanecem sob controle [CONNALEM].
2.1.4.1 Independência de localização

19. 19
A idéia básica da independência de localização (também chamada transparência de
localização) é simples: os usuários não devem ser obrigados a saber onde estão fisicamente
armazenados os dados, embora devam ser capazes de se comportar - pelo menos de um ponto de
vista lógico - como se os dados estivessem todos armazenados em seu próprio site local. A
independência de localização é desejável porque simplifica programas e atividades em terminal
dos usuários. Em particular, permite que dados migrem de um site para outro sem invalidar
qualquer desses programas ou atividades. Essa capacidade de migração desejável permite que
dados sejam deslocados pela rede em resposta a alterações de exigências de desempenho
[DATE].
2.1.4.2 Independência de fragmentação
Um sistema admite fragmentação de dados se uma dada variável de relação armazenada
pode ser dividida em pedaços ou fragmentos para fins de armazenamento físico. A fragmentação
é desejável por razões de desempenho: os dados podem ser armazenados no local em que são
mais freqüentemente utilizados, de modo que a maior parte das operações seja apenas local, e o
tráfego de rede seja reduzido. Por exemplo, considere a variável de relação de empregados EMP,
com a amostra de valores apresentada na parte superior da Figura 2.1.4.2. Em um sistema que
admitisse a fragmentação, poderíamos definir dois fragmentos [DATE].
FRAGMENT EMP AS N_EMP AT SITE ‘BR’
WHERE DEPTO# = ‘Dl’ OR DEPTO# = ‘D2’,
L_ EMP AT SITE ‘JP’
WHERE DEPTO# = ‘D2’;
Estamos supondo que (a) tuplas de empregados são mapeadas no armazenamento físico de
modo bastante direto; (b) números de empregados e números de departamentos são apenas string
de caracteres, e salários são apenas números; (c) D1 e D3 são departamentos da empresa no
Brasil, e D2 é um departamento de da empresa no Japão. Em outras palavras, tuplas para
empregados no Brasil serão armazenadas no site aqui no Brasil, e tuplas para empregados no
Japão serão armazenadas no site lá no Japão. Observe os nomes dos fragmentos internos do
sistema, N_EMP e L_EMP.

20. 20
Figura 2.1.4.2 - Um exemplo de fragmentação entre dados de BR e JP e a percepção do
usuário [DATE]
Existem basicamente duas espécies de fragmentação, horizontal e vertical (conforme
mencionado no tópico 2.1.2.1), que correspondem às operações relacionais de restrição e
projeção, respectivamente. De modo mais geral, um fragmento pode ser derivado por qualquer
combinação arbitrária de restrições e projeções - ou melhor, arbitrária, mas tal que:
• No caso da restrição, as restrições devem constituir uma decomposição ortogonal.
• No caso da projeção, as projeções devem constituir uma decomposição sem perdas.
O efeito prático dessas duas regras é que todos os fragmentos de uma determinada
variável de relação serão independentes, no sentido de que nenhum deles poderá ser derivado dos
outros ou ter uma restrição ou uma projeção que possa ser derivada dos outros. Se realmente
quisermos armazenar o mesmo fragmento de informações em vários lugares diferentes,
poderemos fazê-lo por meio do mecanismo de replicação do sistema.
A reconstrução da variável de relação original a partir dos fragmentos é feita através de
operações de junção e união convenientes (junção para fragmentos verticais, união para
fragmentos horizontais). A propósito, no caso de união, observe que a eliminação de duplicatas
não será necessária, graças à primeira das duas regras anteriores [DATE].

21. 21
Um sistema que suporta fragmentação de dados também deve admitir independência de
fragmentação (também conhecida como transparência de fragmentação), isto é, os usuários
devem ser capazes de se comportar, pelo menos de um ponto de vista lógico, como se os dados
na verdade não estivessem fragmentados de modo algum. A independência de fragmentação
(como a independência de localização) é desejável porque simplifica programas do usuário e
atividades de terminal. Em particular, ela permite que os dados sejam refragmentados a qualquer
momento (e os fragmentos sejam redistribuídos a qualquer momento) em resposta a mudanças
nas exigências de desempenho, sem invalidar quaisquer desses programas ou atividades do
usuário [DATE].
A independência de fragmentação implica que será apresentada aos usuários uma visão
dos dados nas quais os fragmentos estão combinados logicamente por meio de junções e uniões
adequadas.
EMP WHERE SALÁRIO > 4000 AND DEPT0# = ‘D1’
Examinemos esse exemplo um pouco mais de perto. A variável de relação EMP, tal como
é percebida pelo usuário, pode ser considerada (informalmente) uma visão dos fragmentos
subjacentes N_EMP e L_EMP:
VAR EMP VIEW
N_EMP UNION L_EMP;
Assim, o otimizador transforma a solicitação original do usuário na seguinte:
(N_EMP UNION L_EMP ) WHERE SALÁRIO > 4000 AND DEPTO# = ‘Dl’
Essa expressão pode ainda ser transformada em:
(N_ EMP WHERE SALÁRIO > 4000 AND DEPTO# = ‘Dl’)
UNION
(L_ EMP WHERE SALARIO > 4000 AND DEPTO# = ‘Dl’)

22. 22
A partir da definição do fragmento L_EMP no catálogo, o otimizador sabe que o segundo
desses dois operandos de UNION é avaliado como uma relação vazia (a condição de restrição
DEPTO# = ‘D1’AND DEPTO# = ‘D2’ nunca poderá ter o valor verdadeiro). Toda a expressão
pode então ser simplificada para:
N_EMP WHERE SALÁRIO > 4000 AND DEPTO# = ‘Dl’
Agora, o otimizador sabe que só precisa ter acesso ao site do Brasil. Considere o que
significa para o otimizador lidar com a solicitação:
EMP WHERE SALÁRIO > 4000
O problema de admitir operações sobre variáveis de relações fragmentadas tem certos
pontos em comum como problema de admitir operações sobre visões de união e junção na
verdade, os dois problemas é um só - ele simplesmente se manifestam em pontos diferentes na
arquitetura geral do sistema. Em particular, o problema de atualizar variável de relações
fragmentadas é idêntico ao problema de atualizar visões de junção e união [DATE].
2.1.4.3 Independência de replicação
Um sistema admite replicação de dados se uma dada variável de relação armazenada, ou
geralmente, um dado fragmento de uma determinada variável de relação armazenada - pode ser
representada por muitas cópias ou réplicas distintas, armazenadas em muitos sites distintos. Por
exemplo:
REPLICATE N EMP AS
LN_ EMP AT SITE ‘Brasil’
REPLICATE L EMP AS
NL_ EMP AT SITE “Japão”

23. 23
(consulte a Figura 2.1.4.3). Observe os nomes internos de réplicas do sistema, NL EMP e LN
EMP.
A replicação é desejável por pelo menos duas razões. Primeiro, pode significar melhor
desempenho (aplicações podem operar sobre cópias locais, em vez de terem de se comunicar com
sites remotos); segundo, também pode significar melhor disponibilidade (um dado objeto
replicado permanece disponível para processamento - pelo menos para acesso - enquanto houver
no mínimo uma cópia disponível). Naturalmente, a maior desvantagem da replicação é que,
quando um determinado objeto replicado é atualizado, todas as cópias desse objeto precisam ser
atualizadas; o problema da propagação de atualizações.
Observamos de passagem que a replicação em um sistema distribuído representa uma
aplicação específica da idéia de redundância controlada.
Figura 2.1.4.3 - Um exemplo de replicação [DATE]
Agora, a replicação, como a fragmentação, deve no caso ideal ser “transparente para o
usuário”. Em outras palavras, um sistema que admita replicação de dados também deve admitir
independência de replicação (também chamada transparência de replicação), isto é, os usuários
devem ser capazes de se comportar, pelo menos de um ponto de vista lógico, como se os dados
de fato não fossem replicados de modo algum.

24. 24
A independência de replicação implica que é de responsabilidade do otimizador do
sistema determinar a quais réplicas é necessário ter acesso físico para satisfazer a qualquer
solicitação de um determinado usuário [DATE].
2.1.4.4 Gerenciamento de transações distribuídas
Como sabemos, há dois aspectos principais do gerenciamento de transações, o controle de
recuperação e o controle de concorrência, cada um deles exigindo um extenso tratamento no
ambiente distribuído. Para explicar, é preciso antes introduzir um novo termo, agente. Em um
sistema distribuído, uma única transação pode envolver a execução de código de vários sites; em
particular, pode envolver atualizações em muitos sites. Dizemos então que cada transação
consiste em vários agentes, onde um agente é o processo executado em razão de uma
determinada transação em um site específico. E o sistema precisa saber quando dois agentes são
ambos parte da mesma transação - por exemplo, dois agentes que fazem parte da mesma
transação obviamente não podem estar em conflito.
Passando agora especificamente ao controle de recuperação, para garantir que uma
determinada transação é atômica (tudo ou nada) no ambiente distribuído, o sistema deve, portanto
assegurar que o conjunto de agentes para essa transação tem todo ele um comprometimento ou
um ROLLBACK.
Quanto ao controle da concorrência: o controle da concorrência na maioria dos sistemas
distribuídos se baseia em geral no bloqueio, exatamente como em sistemas não distribuídos.
(Vários sistemas mais recentes começaram a implementar controles multiversão; porém, na
prática, o bloqueio convencional ainda parece ser a técnica preferida para a maior parte dos
sistemas) [DATE].
2.1.5 Gerenciamento
O acesso a diversos itens de dados em um sistema distribuído é normalmente
acompanhado de transações que têm de preservar as propriedades.
Há dois tipos de transações que devemos considerar. As transações locais, que são aquelas
que mantêm acesso e atualizam somente a base de dados local; e as transações globais, que são
aquelas que mantêm acesso e atualizam diversas bases de dados locais. Entretanto, no caso das

25. 25
transações globais, essa tarefa é bem mais complicada, já que diversos sites podem participar de
sua execução. Uma falha em um desses sites ou uma falha de comunicação entre sites pode
resultar em erros de processamento [DATE].
2.1.5.1 Tipos de falhas no sistema
Um sistema distribuído pode sofrer os mesmos tipos de falhas de um sistema centralizado
(por exemplo, erros de software, erros de hardware ou erros em disco). Há, entretanto, tipos
adicionais de falhas que precisam ser tratadas em um ambiente distribuído. Os tipos de falhas
característicos são:
• Falha em um site.
• Perda de mensagens.
• Falha de comunicação.
• Problemas de particionamento da rede.
A perda ou comprometimento das mensagens é sempre uma possibilidade nos sistemas
distribuídos. O sistema usa protocolos de controle de transmissão, como TCP/IP, para o
tratamento desses erros. Os sites de um sistema podem ser conectados fisicamente de diversas
formas [CONNALEM].
Cada configuração apresenta vantagens e desvantagens. As configurações podem ser
comparadas umas com as outras, com base nos seguintes critérios:
• Custo de instalação. O custo da ligação física entre os sites do sistema.
• Custo de comunicação. O custo de tempo e dinheiro para envio de uma mensagem do
site A para o B.
• Disponibilidade, relativo ao grau de acesso aos dados, a despeito de falhas de ligação
entre ou nos sites.
Um nó A para o B corresponde a uma comunicação direta entre dois sites. Em uma rede
totalmente conectada, cada site está diretamente conectado a todos os outros sites.
[CONNALEM].

26. 26
Em uma rede parcialmente conectada, há as ligações diretas entre alguns - mas não entre
todos - os pares de sites. Então, o custo de instalação dessas configurações é menor que o das
redes totalmente conectadas. Entretanto, se dois sites A e B não estão diretamente conectados, as
mensagens entre eles precisam ser roteadas por uma seqüência de ligações.
Essa necessidade resulta no crescimento dos custos de comunicação.
Figura 2.1.5.1 - Topologia de redes de computadores [CONNALEM]
Se uma ligação falha, as mensagens que poderiam ser transmitidas por meio dela deverão
ser roteadas novamente. Em alguns casos, é possível encontrar outra rota por meio da rede, assim
as mensagens poderão alcançar seus destinos. Em outros casos uma falha pode ocorrer onde não
haja qualquer ligação entre o par de sites. Note que, sob essa definição, um subsistema pode ser
considerado um único nó [CONNALEM].
Os diferentes tipos de redes parcialmente conectados, mostrados na Figura 2.1.5.1, têm
características diferentes em relação aos tipos de falhas, instalações e custos de comunicação.
2.1.5.2 Robustez
Para um sistema distribuído ser robusto ele precisa detectar falhas, reconfigurar o sistema
para que ele possa continuar funcionando e recuperar a situação original durante o retomo de uma
ligação ou de um processador.

27. 27
As falhas diferentes são tratadas de modos diferentes. Perda de mensagens são
retransmitidas. Retransmissão repetida de uma mensagem, sem mensagem de reconhecimento é
normalmente sintoma de perda de comunicação. Em geral, a rede tenta encontrar rotas
alternativas para uma mensagem. Falhas nessas tentativas sugerem particionamento da rede.
Entretanto, geralmente não é possível ter certeza se houve falha na comunicação entre
sites ou se houve particionamento da rede. O sistema detecta a falha, mas não consegue
identificar o tipo. Por exemplo, suponha que o site S1 não consiga se comunicar com o site S2.
Pode ser que S2 esteja com problemas. Entretanto, pode ser que a ligação entre S1 e S2 não esteja
funcionando. Suponha que o site S1 tenha identificado uma falha. Ele iniciará um procedimento
para reconfiguração do sistema e, então, prosseguirá no modo de operação normal
[SILBERSCHATZ].
• Se há dados replicados no site que não estão funcionando, o catálogo deverá ser
atualizado para que as consultas não solicitem acesso à cópia desse site.
• Se no site com problemas houver transações ativas no momento da falha, essas
transações deverão ser abortadas. É preferível abortar essas transações rapidamente, já que elas
poderão manter bloqueios em dados em sites ainda ativos.
• Se o site que não está funcionando é um servidor de algum subsistema deverá ser feito
uma eleição para determinar o novo servidor.
Já que, em geral, não é possível distinguir entre falhas de rede e falhas nos sites, qualquer
esquema de reconfiguração precisa ser projetado de modo a trabalhar corretamente caso haja o
particionamento da rede. Em particular, a seguinte situação precisa ser evitada:
• Dois ou mais servidores centrais são eleitos em partições distintas
• Mais de uma partição atualiza e replica itens de dados.
A reintegração de um site ou da comunicação entre pares dentro de um sistema também
exige cuidados. Quando um site volta a integrar a rede, é preciso que um procedimento seja
executado para atualização das tabelas do sistema, de modo a refletir as alterações sofridas
enquanto ele esteve fora da rede. Se o site possui réplicas de itens de dados, é preciso que ele
obtenha os valores atualizados desses itens e que se possa garantir que ele passe a receber todas
as atualizações futuras [SILBERSCHATZ]. A reintegração de um site é mais complicada do que

28. 28
parece à primeira vista, já que os dados podem sofrer atualizações durante a reintegração do site
em questão. Uma solução simples para esse problema seria a de manter o sistema
temporariamente sem alterações enquanto o site é reintegrado. Na maioria das aplicações,
entretanto, tal interrupção seria inaceitável. Quando a comunicação entre sites é restaurada,
pode-se estar juntando partições da rede. Dado que o particionamento da rede limita os tipos de
operações possíveis em um ou todos os sites [DATE].
2.2 Aplicações web
As aplicações web evoluíram de sites ou sistemas web. Os primeiros sites web formavam
um sistema de hipermídia distribuído que permitia aos pesquisadores acessos a documentos e
informações publicadas por outros pesquisadores da mesma área, diretamente de seus
computadores [CONNALEM]. Os documentos eram visualizados e acessados através de um
software denominado navegador (browser). Com um navegador, o usuário pode solicitar
documentos de outros computadores na rede e apresentá-los na tela. Para visualizar um
documento, o usuário deve iniciar o navegador e digitar o nome do computador host (hospedeiro)
onde ele pode ser encontrado. O navegador envia uma solicitação do documento para o
computador host. A solicitação é tratada por um software de aplicação denominada servidor web,
a partir daí a resposta é enviada para o usuário que solicitou. Esta breve introdução visa mostrar
de forma resumida os principais conceitos de aplicações web.
2.2.1 Conceitos e visão geral
Uma aplicação web é desenvolvida e estendida a partir de um sistema web para adicionar
funcionalidade de negócio. No seu termo mais simples, uma aplicação web é um sistema que
permite a seus usuários executar as regras de negócio do sistema a partir de um navegador web.
• Protocolo http: os navegadores e servidores web usam um protocolo conhecido como
http (HyperText Transfer Protocol) que especifica como um navegador deve formatar e enviar
uma solicitação para um servidor web. Esse protocolo é interpretado tanto pelo navegador
(cliente) quanto pelo servidor, que devolve a resposta da solicitação [CONNALEM].
• Identificação do documento: o identificador completo para referência e obtenção do
documento é o URL. Ele identifica o protocolo (http), o nome da máquina do host, o número de

29. 29
porta opcional e o nome/local do documento. Um URL pode ser usado para solicitar muitos tipos
de objetos com diferentes protocolos. Alem do http, os protocolos comuns da internet incluem
news, FTP, file entre outros. Cada protocolo é especifico para o tipo de informação ou recurso
que ele apresenta [CONNALEM].
• Nomes de domínio: um nome de domínio é simplesmente um nome no formato texto
usado para procurar um endereço de internet no formato numérico. O sistema de endereçamento
da internet em uso hoje é o IP. Quando um cliente solicita um URL, a solicitação deve ser feita
diretamente ao computador host. Isso significa que o computador host identificado no URL deve
ser resolvido em um endereço IP numérico. Esse processo é feito com um servidor de nomes de
domínio o DNS. Um DNS é um computador da rede que o cliente tem acesso e que está em um
endereço IP conhecido [CONNALEM]. Um domínio é exclusivo, ou seja, só existe um registro
pra ele, por exemplo, não existe um outro domínio como www.uol.com.br, pois o endereço IP
desse já existe na tabela de DNS do servidor.
• Tolerância a Falha: a meta de um design de sistemas web é que eles sejam robustos e
tolerantes a falhas, esse desejo por um alto grau de tolerância a falha induziu em parte a decisão
de usar um protocolo sem conexão, como o http.
O http é executado sobre o TCP, mas poderá ser executado sobre qualquer serviço
orientado para conexão. O TCP, normalmente combinado com o IP, é uma implementação de
camadas no modelo OSI para comunicação de rede. O https (http with SSL) é relativo ao http,
mas usa criptografia para ajudar na segurança da comunicação. O https é usado na internet para
tratar dados confidenciais como informações pessoais e financeiras. [CONNALEM]
• Html: os navegadores, além de estabelecer conexões com a rede, precisam apresentar o
documento em uma tela, porém o TCP e o http não lidam com isso, portanto a apresentação do
conteúdo é gerenciada pelo navegador, que é onde a HTML entra. A HTML é usada para
expressar o conteúdo e a formatação visual de uma página. Um ponto importante a ser observado
é que a HTML é uma linguagem que especifica como os documentos devem ser exibidos em uma
tela de computador [CONNALEM].
Como seria a estrutura da HTML? Ela é definida por tags que pode ser usado para
informar ao navegador como apresentar algo ou definir um link para outra página web. Todas as
tags são envolvidas por sinais de maior e menor (< e >), normalmente elas são usadas em pares,
por exemplo: <b>Teste</b> essa tags faz com que o texto “Teste” fique em negrito
[CONNALEM].

30. 30
• Aplicações Web: As aplicações web usam as tecnologias de ativação para tornar seu
conteúdo dinâmico e para permitir que os usuários do sistema afetem a regra do negócio no
servidor. A diferença entre sites Web e aplicações Web é sutil e conta com a habilidade de um
usuário para afetar o estado da regra no negócio no servidor. Portanto se no servidor não houver
nenhuma regra de negócio, o sistema não deverá ser visto como uma aplicação web. Para aqueles
sistemas nos quais o servidor Web - ou um servidor de aplicação que usa um servidor web para
entrada do usuário - permite que uma regra do negócio seja afetada via navegador web, o sistema
é considerado uma aplicação web. Em quase todas as aplicações web mais simples, o usuário
precisa fornecer mais do que apenas informações de solicitação de navegação; normalmente, o
usuário de uma aplicação Web insere uma gama variada de dados: texto simples, seleções de
caixas de seleção ou, até mesmo, informações binárias ou de arquivos [CONNALEM].
Figura 2.2.1 - Modelo simples de resposta e requisição entre cliente/servidor
[CONNALEM].
2.2.2 Arquitetura
Arquiteturas reais são criadas a partir de um ideal por parte do projetista. Elas sempre
parecem se desenvolver de algo diferente ou são reunidas de mecanismos e padrões bem
conhecidos. Quase todos os mecanismos e padrões arquitetônicos que podem ser aplicados a
camadas do servidor de um sistema distribuído padrão também podem ser aplicados às
arquiteturas de aplicações Web. A seguir, alguns padrões estruturais comuns que estão
particularmente adaptados às arquiteturas de aplicações Web:

31. 31
• Fechada: A informação dinâmica em qualquer página Web dada pode ter que ser
construída de uma coleção de objetos do negócio e controladores. As classes do padrão fachada
unem páginas Web dinâmicas. Cada página Web possui uma classe do padrão fachada
especificamente projetada que age para consolidar toda a organização do objeto do negócio e
fornecer uma interface clara e de uso fácil para o desenvolvedor do script da página Web usar.
• Composição de página: Cada página Web conceitual no sistema é reunida em tempo de
execução a partir de um conjunto de fragmentos de páginas menores independentes, que são
freqüentemente reutilizados através de páginas no sistema. Por exemplo, muitas aplicações de
comércio eletrônico na Internet fornecem um modo rápido para digitar critérios de pesquisa de
produtos em toda página Web conceitual. Esse padrão é uma maneira para fornecer a
funcionalidade de quadros HTML sem usar os conjuntos de quadros.
• Página modelada: Esse padrão define um modelo de uma página que todas as páginas
Web enviadas analisam em seus caminhos para o cliente. Semelhante ao padrão composição de
página, o padrão página modelada fornece estrutura adicional com modelos e telas formalmente
definidos (páginas conceituais). O Java Pet Store fornece um exemplo de um uso desse padrão. É
claro que, muitos outros padrões e mecanismos são comumente usados e associados a
arquiteturas de aplicações Web.
Os três padrões mais comuns da camada de apresentação são o cliente Web magro, o
cliente Web gordo e a produção Web [CONNALEM].
• O cliente Web magro é usado principalmente para as aplicações baseadas na Internet,
onde há pouco controle da configuração do cliente. O cliente requer apenas um navegador Web
que dê suporte a formulários padrão. Toda a lógica do negócio é executada no servidor.
• O cliente Web gordo padrão é usado onde uma quantidade significativa
arquitetonicamente da lógica do negócio é executada na máquina do cliente. Normalmente, o
cliente usa HTML, applets java ou controles ActiveX dinâmicos para executar a lógica do
negócio. A comunicação com o servidor é feita ainda através do protocolo HTTP.

32. 32
• O padrão de produção Web é usado quando o navegador Web age principalmente como
um dispositivo de produção e de contêiner para um sistema de objetos distribuídos. Além do
protocolo HTTP para a comunicação do cliente e do servidor, outros protocolos, podem ser
usados para dar suporte a um sistema de objetos distribuídos.
É concebível aplicar vários padrões a qualquer arquitetura de sistema especifico. Por
exemplo, um sistema de comércio eletrônico baseado na Internet pode usar o padrão de cliente
Web magro para os casos de uso de vendas a seus consumidores e usar o cliente Web gordo ou o
padrão de produção Web para os casos de uso de manutenção BackOffice. Isso é possível porque
há um grau de controle da configuração do cliente quando você possui o cliente; torna-se mais
complicado, no entanto, quando está solicitando negócios de usuários da Internet de todo o
mundo.
As aplicações Web mais realistas possuem a camada do meio adicional - o negócio - e a
camada de dados. Arquitetonicamente, essas camadas back-end estão essencialmente inalteradas
do modo que aparecem no sistema distribuído mais geral. É onde também a maioria dos
componentes de processamento da lógica do negócio do sistema reside e a maioria do trabalho de
alteração do estado do negócio acontece. A camada de lógica do negócio de aplicações Web é
onde a maioria dos objetos do negócio faz seus trabalhos. Essa camada normalmente é uma
camada transacional, onde os objetos podem executar alterações triviais no estado permanente.
As duas implementações / especificações mais populares são o MTS e o EJB. As duas são
essencialmente contêineres que gerenciam os ciclos de vida dos objetos transacionais e fornecem
maneiras fáceis para executar transações de banco de dados. Esses dois contêineres dependem
intensamente da camada de dados para fornecer as APIs básicas para dar suporte as transações
[CONNALEM].
Os contêineres permitem que os objetos do negócio executem a lógica do negócio em um
ambiente de transação segura, mesmo quando vários bancos de dados heterogêneos são usados.
2.2.3 Segurança
Em uma aplicação para a Internet uma grande preocupação é com a segurança. Mesmo
que a aplicação seja para uma intranet, protegida por um firewall da empresa, a segurança
continuará sendo uma preocupação. Um sistema seguro é uma aplicação que funciona

33. 33
adequadamente e que faz apenas o que se propõe a fazer, sem comprometer a integridade dos
nossos dados para aqueles que não estão autorizados a obter essas informações.
Se nossos sistemas só fizessem o que se propõem a fazer, a segurança não seria um
problema. Pessoas sem escrúpulos mesmo com acesso limitado ao seu sistema aproveitarão
qualquer falha do sistema para obter acesso a informações potencialmente valiosas, como perfis
de cliente e números de cartão de crédito, ou simplesmente derrubar o sistema para testar sua
perícia e orgulho pessoal. A ameaça é muito real e com as aplicações Web assumindo papéis cada
vez mais importantes nas empresas, a necessidade de entender e administrar os riscos de
segurança se torna ainda mais crítica [CONNALEM].
A FAQ (Perguntas Mais Freqüentes) do grupo de notícias alt.security resume os
problemas de segurança fazendo a seguinte pergunta comum:
P: O que torna um sistema inseguro?
R: Ligá-lo. O provérbio a seguir diz tudo: “O único sistema realmente seguro é aquele que
está desligado e desconectado, guardado em um cofre reforçado com titânio, escondido em uma
casamata de concreto e envolto por gás paralisante e por guardas armados muito bem
remunerados. Mesmo assim, eu não arriscaria a minha vida por ele” [CONNALEM].
2.2.3.1 Tipos de riscos de segurança
Para entender as áreas de risco da nossa aplicação, precisamos entender primeiro onde
nossos sistemas são vulneráveis. A arquitetura de sistemas Web básica, sendo uma variante de
uma arquitetura distribuída, tem três elementos arquitetônicos principais: o cliente, o servidor e a
rede. Cada um deles é vulnerável a ataques.
• Nossos clientes correm os riscos de ataques de softwares que danificam o sistema do
cliente ou comprometem os recursos do cliente particular, como informações pessoais e arquivos.
• Nossos servidores correm o risco de acesso não-autorizado, o qual pode resultar na
captura de informações confidenciais, na execução de programas prejudiciais no servidor ou,
ainda, desativar temporariamente as funções do servidor.
• Nossas redes podem ser monitoradas e as comunicações de dados entre o cliente e o
servidor podem ser interceptadas.

34. 34
2.2.3.2 Risco técnico
A natureza dos riscos nos nossos sistemas pode ser classificada em quatro áreas
principais:
• Sistemas configurados de modo inadequado
• Software com bugs
• Autenticação pobre ou requisitos de senha insuficientes
• Falta de criptografia no tráfego da rede
A principal razão para que qualquer parte de um sistema corra risco de segurança é um
software configurado inadequadamente ou com bugs. Um sistema mal configurado ou um
sistema com um bug abre um furo na segurança que pode ser explorado. Podemos citar um
exemplo, onde um programa permitia que os usuários do sistema salvassem um arquivo em uma
área particularmente importante do sistema de arquivos. Os arquivos nesse diretório eram
executados automaticamente com privilégios de nível raiz e considerados partes do sistema
operacional. Uma vez lá, o arquivo do hacker estava executando, dando ao intruso uma conta
secreta e não monitorada no sistema, a qual ele usou para examinar o sistema anonimamente e
obter informações importantes além de ser um ponto de partida para conquistar o próximo
sistema [CONNALEM].
Em uma aplicação Web, a autenticação correta dos usuários de um sistema pode ocorrer
em vários níveis. Em um nível, o próprio computador cliente pode ser autenticado para ser usado
com o sistema. Uma aplicação Web pode ser criada para permitir apenas clientes com
determinados endereços IP [CONNALEM].
A forma de autenticação mais comum é uma senha simples. Os usuários de um sistema
recebem uma identificação (ID) de logon - uma identificação de usuário conhecida publicamente
- e uma ID secreta (senha). Para obter acesso ao sistema, o usuário deve usar as duas. Após o
primeiro acesso ao sistema, o usuário é normalmente solicitado a alterar a senha para algo que
apenas o usuário conheça. As senhas são, em geral, a primeira linha de defesa de um sistema e
ajudam a impedir ataques interativos no sistema.
Esse tipo de autenticação tem muitos problemas. Do ponto de vista estritamente técnico,
as ID de usuário e senha informam ao sistema apenas que um usuário que conhece aquela

35. 35
combinação está solicitando acesso ao sistema, não necessariamente que ela é a pessoa que
supostamente tem esse conhecimento. O que um sistema está, na verdade, autenticando é um
usuário com conhecimento de uma combinação de ID e senha de um usuário válido, não a
identidade real da pessoa que está solicitando acesso ao sistema.
Em muitas situações, o conhecimento de uma conta de logon específica não permitirá que
um cracker acesse imediatamente todos os recursos do sistema. Normalmente, as contas de
usuário são restritas para permitir acesso a apenas aqueles recursos necessários à execução das
responsabilidades do usuário. O que mais interessa a um cracker são as senhas de administração,
de raiz ou do administrador. Com esse nível de acesso, os recursos de todo o sistema estão
abertos para exploração [CONNALEM].
Senhas simples podem ser quebradas com programas que adivinham senhas repetidamente
a partir de um dicionário de palavras e combinações de números ou outros símbolos comuns. As
melhores senhas são aquelas criadas a partir de uma base puramente pessoal e aleatória.
Entretanto, o truque prático na utilização de senhas é usar senhas que possam ser lembradas.
“Relatou-se uma vez em um ambiente no qual as senhas foram distribuídas pelo administrador de
rede da empresa, que usou um software especial que ele acreditava produzir senhas aleatórias e
muito difícil de adivinhar. Para aumentar a segurança - no seu modo de pensar - ele as alterava a
cada três meses. Ele atribuiu senhas aos usuários do sistema, esperando que as memorizássemos
rapidamente e destruíssemos as cópias escritas. As senhas eram codificadas e difíceis de lembrar.
O resultado foi que metade dos usuários acabou escrevendo suas senhas em papéis adesivos e
colando-as nos seus monitores” [CONNALEM].
O truque para o uso de senhas não é considerá-las a ferramenta de segurança final, mas
simplesmente a primeira linha de defesa. Para serem eficientes, elas precisam ser tão aleatórias
quanto a capacidade do usuário de se lembrar delas.
A categoria geral final de risco de segurança é a falta de criptografia. Nesse tipo de risco,
os invasores monitoram o tráfego da rede, coletando os diálogos de comunicação entre clientes e
servidores. O protocolo de rede mais comum na Internet hoje é o TCP/IP. Quando projetado, a
segurança não foi à preocupação principal; a internet, sendo a maior rede pública do mundo, não
impede que usuários anônimos monitorem o tráfego geral que passa por seus sistemas. Os
crackers podem usar “farejadores” para monitorar e analisar o tráfego da rede para um servidor
ou cliente específico e, possivelmente, reconstruir informações importantes e úteis na obtenção
de acesso adicional ao sistema ou simplesmente selecionar alguns números de cartão de crédito.

36. 36
Uma utilização importante da criptografia de rede está nas redes privativas virtuais
(VPNs). Em uma VPN, uma rede pública, tal como a Internet, é usada como uma rede privativa.
Todos os membros da rede privativa usam a criptografia para se comunicar entre si. As VPNs
podem ter a vantagem distinta de permitir que pequenas empresas proporcionem acesso privativo
de rede através da Internet pública a pessoas localizadas remotamente em vez de acessar por meio
das linhas dedicadas que são muito mais caras. Algumas aplicações Web podem usar VPNs como
parte de suas medidas de segurança. As VPNs podem ser implementadas com uma combinação
de software e hardware ou apenas com software [CONNALEM].
Figura 2.2.3.2 - Redes privativas virtuais
2.2.3.3 Estratégias de segurança
Em geral, tornamos nossos sistemas mais seguros:
• Limitando o acesso ao sistema por meio de firewall, senhas e assim por diante.
• Compreendendo os requisitos do sistema e de segurança
• Mantendo atualizados sobre as mais recentes correções e alertas de segurança
É claro que a maneira mais fácil de limitar o acesso a um sistema é desconectá-lo de
qualquer rede pública, como a Internet, e proteger fisicamente todos os pontos nos quais a rede
encontra o mundo real. Esse tipo de medida de segurança pode ser bom e apropriado para
sistemas militares, mas para sistemas de comércio eletrônico na internet, não ajudaria muito nos
negócios.

37. 37
Outra opção para limitar o acesso a aplicações baseadas em intranet é estabelecer um
firewall entre a intranet e a Internet. A maioria das empresas mantém um firewall para isolar seus
sistemas internos do mundo externo.
O nome firewall tem origem na parede de aço existente entre o compartimento do
motorista de um automóvel e o compartimento do motor. A idéia é que o fogo do motor tenha
dificuldade de se espalhar para o restante do automóvel. Um firewall de rede é projetado para
impedir que o tráfego indesejado entre e saia de uma rede interna. Normalmente, os fírewalls
usam um servidor proxy para monitorar o tráfego de entrada e saída. O tráfego pode ser limitado
de várias maneiras: por tipo - HTTP, FTP ou correio eletrônico - ou por endereço -
www.umsite.com.br e assim por diante - assim como por outras [CONNALEM].
Figura 2.2.3.3 - Posição do firewall
2.2.3.4 Criptografia
Os certificados e a assinatura de código contam com a criptografia. Essa mesma
tecnologia pode ser usada para ajudar a proteger o tráfego de rede subjacente em uma aplicação
Web. Como muitas aplicações Web usam a Internet pública para conectar clientes e servidores,
os crackers podem monitorar e decodificar o tráfego da rede e, com algum esforço, determinar
padrões de acesso e informações confidenciais, como senhas e números de cartões de crédito.
Para tornar o tráfego de rede entre o cliente e o servidor mais seguro, ele pode ser
criptografado. O impulso do comércio eletrônico tem exigido a emergência de vários esquemas
para proteger informações confidenciais que transitam pela rede. Os dois esquemas mais
promissores são o SSL e o SET.

38. 38
O SSL foi apresentado pela Netscape Communications Corporation e é um esquema de
criptografia de nível baixo usado para criptografar protocolos de nível mais alto, como o HTTP e
o FTP. O SSL exige que o servidor apresente um CA para verificar sua identidade e pode,
opcionalmente, verificar também um certificado de cliente. O SSL está implementado na maioria
dos navegadores de hoje e quase todas as aplicações comerciais o utilizam proporcionando uma
medida de segurança para seus usuários [CONNALEM].
O SET é um conjunto de padrões e protocolos, para realizar transações financeira seguras,
como as realizadas com cartão de crédito na Internet. Oferece um canal de comunicação seguro
entre todos os envolvidos na transação. Garante autenticidade e privacidade entre as partes.
2.3 Banco de dados distribuídos e aplicações web
Nos dias de hoje, praticamente todos os sites que permitem consulta a seus produtos,
serviços ou qualquer outro tipo de informação trabalham com um Sistema de Banco de Dados, ou
seja, os dados ficam armazenados em um banco de dados.
Um exemplo desta característica é mostrado no exemplo a seguir:
- Uma pessoa entra no site de uma determinada loja com a intenção de comprar algo.
- A primeira coisa que essa pessoa vai verificar é se o produto possui estoque, uma coisa
que ela não sabe é que essa loja pode ter N filiais, cada qual com um estoque diferente porém
com uma mesma estrutura de dados.
- O visitante ao consultar o(s) produto(s) não sabe se o mesmo se encontra no estoque da
filial 1, 2, 3, 4 ou N-ésima, o que interessa para ele é que a loja possui o produto que ele
escolheu. E a partir daí, ele transcorre com o devido processo para a finalização do pedido até a
entrega do mesmo no endereço indicado.
Neste trabalho estamos tratando de bancos de dados distribuídos, então surge a pergunta:
qual a relação entre bancos de dados distribuídos e aplicações Web?
Para responder essa pergunta, tomemos como base o visitante e o site da loja. O usuário,
ao digitar www.aloja.com.br, não sabe qual das filiais da loja está acessando, ou mesmo se a loja
possui filial. Porém, ao efetuar uma consulta de um produto, o usuário espera que o mesmo
possua estoque, porém por trás de toda essa aplicação web pode existir, de acordo com a
quantidade de filiais, os N bancos de dados em lugares diferentes, o que corresponde as filiais. A
resposta se resume no seguinte: ao efetuar uma consulta, se aquele determinado produto não

39. 39
estiver no estoque da filial 1, ou filial 2, ou filial 3 ou filial 4 ou filial N-ésima, daí sim podemos
afirmar que "o produto não pode ser comprado pois não tem em estoque". Agora, caso ele ache
em alguma dessas ou mais filiais, o retorno esperado é que o produto está no estoque e portanto
pode ser adquirido a qualquer momento.
Portanto, um banco de dados distribuído pode facilitar a execução de uma aplicação web,
pois esta não precisa se preocupar em qual banco deve fazer a pesquisa; o próprio BD-D se
encarrega de distribuir a consulta e recuperar o dado requisitado
2.3.1 Aplicações distribuídas
Uma aplicação é dita distribuída quando é executada em um ambiente distribuído,
independente dela estar ou não acessando banco de dados distribuídos. Para exemplificar esta
definição veja as ilustrações abaixo:
Requisição HTTP
Servidor
Browser Web
Resposta à requisição
HTTP
Figura 2.3.1.1 - Representação de uma aplicação distribuída sem acesso à banco de dados
A ilustração abaixo trata de o acesso de uma aplicação Web a um SGBD-D.
B ro w s e r W e b S e r v id o r W e b S e r v id o r B D
Figura 2.3.1.2 - Representação de uma aplicação distribuída acessando um determinado
banco de dados não-distribuído
Para que fique mais claro qual a característica de um sistema de banco de dados
distribuído, veja abaixo a figura que representa tal intenção.

40. 40
Figura 2.3.1.3 - Exemplo de acesso a uma aplicação web com vários bancos interligados
A figura 2.3.1.4 ilustra justamente o contrário da figura 2.3.1.3, ou seja, para a arquitetura
da figura 2.3.1.3 a aplicação web faz uma requisição ao BD e o próprio BD se encarrega de
solucionar esta requisição, isto é, dado uma pesquisa não encontrada neste banco o mesmo
assume a responsabilidade de realizar essa mesma pesquisa em outro banco de dados. Enquanto
isso, na arquitetura da figura 2.3.1.4 a aplicação web faz várias requisições em vários bancos de
dados distintos – a aplicação procura em um BD, depois em outro, e assim sucessivamente até
encontrar os dados que deseja. Com isso conclui-se que em relação à performance e robustez o
BD-Distribuido é mais vantajoso em comparação ao centralizado, agora em relação a custo um
BD-Distribuido é muito superior a um centralizado, portanto a implantação de um banco de
dados distribuído é muito cara, porém extremamente eficiente em relação ao centralizado.

41. 41
Figura 2.3.1.4 - Aplicação web acessando BD centralizado
É possível descrever a situação ilustrada na figura 2.3.1.3 nas seguintes etapas:
1) O usuário acessa a aplicação web e executa uma consulta
2) Ao efetuar a consulta no banco SGBD-D B, o resultado não foi bem sucedido.
3) Devido as suas configurações de SGBD-D, a mesma consulta é executada no
SGBD-D A, sem que o usuário saiba, e se ainda o resultado não foi bem sucedido a mesma
consulta é executada no SGBD-D C
4) Caso ainda não retorne nada o usuário terá como resposta que o produto
pesquisado não tem em estoque, por exemplo.
5) Conclusão: o usuário sem saber consultou o produto em todas as filiais da loja,
não sendo bem sucedida porque o produto já estava esgotado em todas as lojas do grupo, mas
caso estive na loja A (SGBD-D A), o usuário de forma alguma saberia que o produto estaria
naquela ou em uma outra filial.

42. 42
3 ESTUDO DE CASO
Para que seja possível exemplificar de uma maneira mais clara o funcionamento de um
banco de dados distribuído, estaremos citando o caso de uma rede de locadoras de automóveis
denominada Localiza Rent-Car. Esta locadora, localizada em Belo Horizonte, possui um total de
320 agências espalhadas pelo Brasil e pelo mundo, contando com uma frota de 30.000
automóveis de diversos tipos e marcas.
3.1 Justificativas e necessidades
O grande objetivo da implementação de um estudo de caso é validar e demonstrar as
idéias desenvolvidas em um projeto. Um estudo de caso bem feito é de grande importância para
qualquer projeto, pois é ele que permite avaliar os resultados obtidos a partir da teoria do trabalho
desenvolvido, para com isso se poder tirar conclusões.
A Localiza Rent-Car foi escolhida como estudo de caso pelas razões enumeradas abaixo:
- Cada filial deve armazenar os dados de seus veículos localmente, mas deve poder
acessar os dados das demais filiais para atender pedidos específicos de clientes.
- Os clientes devem poder fazer reservas on-line acessando somente um site (da empresa),
sem precisar verificar o site de cada filial.
- Não há necessidade do cliente saber em qual filial o carro está sendo reservado,
importando apenas que o cliente vai retirar e entregar o automóvel no local por ele indicado.
- Redução de custos/facilidade de controle, isto é, com as 320 agencias espalhadas pelo
Brasil e pelo mundo o cliente consegue com muita comodidade locar um carro sem sair de casa.
- Reduz o risco da utilização constante de dinheiro, ou seja, o cliente efetua o pagamento
no momento da reserva.
3.2 Especificação do problema
Quando se fala em locadora de veículos logo imaginamos uma empresa situada em uma
cidade onde atende somente a população local, com isso certamente um único sistema de controle

43. 43
de frotas e reservas juntamente com um banco de dados centralizado já seria suficiente para tal
gerenciamento.
Mas o que se pode notar é que a empresa Localiza não é uma simples empresa na qual
possui uma única agência, conforme visto a Localiza possui várias agências espalhadas pelo
Brasil e pelo mundo, sendo assim estaremos demonstrando como seria extremamente vantajosa e
importante a aplicação de um SGBD distribuído, levando em consideração a estrutura geográfica
da empresa.
Para que possamos estudar este caso tomamos como prioridade algumas regras de
negócios, são elas:
- A entrega e a retirada do carro são combinadas previamente no momento da reserva no
site.
- Cada locadora possui igualdades com relação a sua estrutura física, por exemplo,
comercial, manutenção e gerência. Com isso cada uma possui uma meta a ser atingida seja ela em
satisfação e financeira.
3.3 Modelo de dados
Os dados de todas as locadoras estarão definidos de uma única forma, ou seja, as tabelas
serão iguais com relação a sua estrutura, alterando somente o seu conteúdo. Por exemplo, em
uma locadora pode não haver um determinado veículo enquanto na outra se encontra disponível
com isso não perdendo a venda/aluguel. Por fim, como dito, as tabelas estarão organizadas
igualmente com relação aos seus campos, tamanho, características e validações. A estrutura do
banco e o relacionamento das tabelas estarão organizados da seguinte forma:

44. 44
Figura 3.3.1 - Estrutura física do sistema de banco de dados distribuídos

45. 45
Figura 3.3.2 - Modelo Relacional do estudo de caso
3.4 Testes
Os testes executados serão os seguintes:
Performance do banco e consultas: Será avaliado consultas e cadastros em execução
simultânea para que seja possível avaliar a capacidade do banco.
Segurança: Será avaliada a segurança de uma forma ampla, ou seja, integridade das
informações ali contidas, bem como o sigilo dos dados.
Comunicação entre os bancos: Esse é o ponto fundamental dos testes, é através dele que
poderemos avaliar o funcionamento real de um SGBD-D quanto à troca de informações entre os
mesmos.

46. 46
4 PROTÓTIPO
Conforme mencionado nos capítulos anteriores, o protótipo implementa o estudo de caso
escolhido para os testes de um sistema de banco de dados distribuídos: o caso da Localiza, uma
empresa que trabalha na área de aluguel de veículos desde 1973.
4.1 Projeto
O projeto de estudo de caso será baseado na área em que o cliente tem a possibilidade de
efetuar reservas on-line. Veja ilustração referente ao momento, da reserva de um determinado
veículo:
Figura 4.1 - Tela principal onde o usuário define a retirada e a devolução
4.1.1 Arquitetura

47. 47
A arquitetura do sistema, mostrada na figura 4.1.1, está distribuída entre as locadoras da
empresa da seguinte forma:
- Localiza - A (sede do grupo - escritório central). Irá conter um banco de dados com as
devidas tabelas, conforme citado na figura 3.3.1. Conseqüentemente este banco de dados estará
configurado para se tornar um Sistema de Banco de Dados Distribuídos.
- Localiza - B, Localiza - C e Localiza - D (possui uma unidade de negócio). Irá conter um
banco de dados idêntico, em termos de estrutura, ao descrito no item anterior, contendo
diferenças somente no conteúdo das tabelas.
Figura 4.1.1 - Representação da arquitetura do protótipo do sistema
4.1.2 Projeto do banco de dados
Esta seção mostra a estrutura do banco de dados distribuído definido para a solução,
incluindo a criação das tabelas e seus devidos campos e também a configuração necessária no
SGBD-D.

48. 48
Para que um sistema de banco de dados se torne distribuído é necessário verificar se o
SGBD tem suporte a distribuição. Uma vez verificado o próximo passo é configurá-lo, para isso
destacam-se os principais passos de configuração de um SGBD-D:
- Primeiramente determina quem será o DISTRIBUIDOR, ou seja, o servidor no qual será
responsável em distribuir os dados.
- Em seguida é necessário definir o PUBLICADOR, ou seja, as bases de dados no qual
cria-se um “tipo de compartilhamento” entre eles.
- E por último cria-se os ASSINANTES, ou seja, esses serão adicionados nos
publicadores de acordo com cada banco de dados. Um assinante do tipo PUSH é definido pela
publicadora, ou seja, quem publicou os dados define quem vai recebê-los. Já o assinante do tipo
PULL, ele escolhe que publicações assinar. Veja figura abaixo demonstrando um SGBD-D:
Figura 4.1.2 - SGBD-D configurado
4.2 Implementação

49. 49
Esta seção detalha as principais características do banco de dados e a linguagem de
programação usada no desenvolvimento do protótipo.
4.2.1 Sistema gerenciador de banco de dados distribuído
O banco de dados escolhido foi o SQL Server 2000, da Microsoft. Para um banco de
dados se tornar distribuído o mesmo sofre modificações como replicação e fragmentação, com
isso poderemos mostrar a idéia de um SGBD-D [GUNDERLOY].
Principais características do SQL Server 2000:
• Ferramentas gráficas para administração e desenvolvimento (Query Analyzer e
Enterprise Manager) Replicação de Dados
• Ferramenta para aferição de performance (Profiler) , que permite ao administrador
capturar, armazenar e analizar eventos que responsáveis por gargalos no servidor
• Views distribuídas (Distributed Partitioned Views) , que podem ser utilizadas para
balanceamento e distribuição de carga entre servidores
• Failover Clustering (fornece mecanismos para criar cópias on-line de sua base de
dados à partir de um servidor virtual, responsável pelo manejo das requisições)
As técnicas abaixo aplicadas são necessárias pois só assim o SGBD SQL Server 2000 se
tornará distribuído. Antes de iniciar sobre as principais considerações, devemos levar em conta
que as bases e as tabelas já estão devidamente criadas no SGBD [GUNDERLOY]. Veja as
etapas:
a) Definir qual servidor será o Distribuidor

50. 50
Tela inicial da definição do distribuidor
Nesta opção escolhe-se quais bases serão publicadas
b) Uma vez definido o distribuidor, nota-se que as bases de dados ficam com a seguinte
aparência:
Isso se dá ao fato de agora poder publicar todas essas bases, no qual é o próximo passo.

51. 51
c) Para que os bancos se tornem visíveis entre si, a próxima etapa é criar as publicações.
Esta é a tela inicial na qual define-se qual base será publicado. Os passos a seguir são iguais para
quantas bases de dados estiverem no Distribuidor.
Nesta etapa define-se o tipo de publicação dos dados

52. 52
Nesta etapa há a possibilidade de definir quais tabelas/artigos farão parte da publicação
d) A próxima e última etapa trata dos assinantes, ou seja, quais tabelas de quais bases
poderão assinar as publicações das outras bases de dados. Para que tudo seja feito com êxito é
extremamente importante seguir todas as etapas anteriores.
Define-se qual banco será assinado por uma determinada publicação

53. 53
Tela na qual define-se em qual distribuidor serão assinados quais artigos/tabelas.
Nesta opção escolhe-se qual publicação irá receber um determinado assinante/tabela

54. 54
Tela de conclusão da definição do assinante na publicação
Para concluir devemos considerar alguns dados importantes para o desenvolvimento deste
estudo de caso:
- Existe 1 distribuidor local.
- 4 bases de dados, na qual todas serão assinantes e publicadora.
- Apenas uma, na qual conterá os dados da matriz, será a publicadora de todas as outras
assinantes, ou seja, ela será a responsável por publicar os dados das outras filiais.
4.2.2 Linguagem de programação web
Java Server Pages (JSP) (www.sun.com) é uma tecnologia de web-scripting para
desenvolvimento de aplicações WEB semelhante ao Microsoft Active Server Pages (ASP)
(www.microsoft.com), porém tem a vantagem da portabilidade de plataforma da linguagem Java.
Operando na camada de apresentação, as páginas JSP utilizam a tecnologia Java do lado do
servidor (servlets) para a criação de conteúdo dinâmico aliado com as tags HTML para manter o
conteúdo estático [ANSELMO].
Com a tecnologia JSP é possível, entre outras coisas, produzir aplicações que permitam o
acesso a banco de dados, o acesso a arquivos-texto, a captação de informações a partir de

55. 55
formulários, a captação de informações sobre o visitante e sobre o servidor e o uso de variáveis e
loops entre outras coisas.
O JSP não oferece nada que não possa ser criado com servlets puros. O JSP, entretanto,
oferece a vantagem de ser facilmente codificado, facilitando assim a elaboração e manutenção de
uma aplicação WEB. Além disso, a tecnologia JSP permite a separação da programação lógica
(parte dinâmica) da programação visual (parte estática). Outra característica também é a
possibilidade de produzir conteúdos dinâmicos que possam ser reutilizados. Pode-se considerar
as principais características do JSP como sendo [ANSELMO]:
Separação do conteúdo estático do dinâmico: em JSP, a lógica de geração de conteúdo
dinâmico é mantido separada das tags HTML responsáveis pela interface para o usuário. A parte
lógica é encapsulada em componentes JavaBeans externos, que são então utilizados pela página
JSP através de tags especiais ou scriptlets.
Diversos formatos: qualquer formato atual pode ser utilizado numa página JSP, além de
HTML. Podem ser utilizadas linguagens XML, DHTML, entre outras.
Integração com a API Servlet: JSP pode ser considerado uma abstração de alto nível
dos servlets, considerado que as páginas JSP são compiladas para gerarem servlets. Dessa forma,
praticamente qualquer coisa feita em servlets pode ser feita em JSP.
Utilização de código Java: é possível utilizar os chamados scriplets, que são nada mais
que trechos de código Java puro inseridos dentro da página JSP.
A arquitetura geral das páginas JSP tem muito em comum com os servlets, tendo em vista
que a especificação JSP é definida como uma extensão da API Servlet.
Na maioria dos casos, as páginas JSP são submetidas a um processo de tradução e a uma
fase de processamento de requisição. A primeira acontece apenas uma vez, a não ser que a página
JSP em questão sofra alterações. Caso não ocorram erros de compilação, o resultado desta fase é
uma classe que implementa a inteface Servlet.
Fase de Compilação de uma página JSP: Quando uma página JSP é requisitada pelo
cliente através de um browser, a classe equivalente a esta página é executada pelo servidor. A
partir daí será gerada uma página HTML que será enviada de volta ao browser do cliente.

56. 56
Figura 4.2.2 - Estrutura de funcionamento de páginas com a tecnologia JSP [ANSELMO]
A) Todo o processo começa quando um cliente faz uma solicitação, neste
momento é enviado um request para o WebServer
B) O WeServer localiza e envia a ação para a página JSP
C) São verificadas mudanças nesta, se for a primeira vez é criado um
programa Java Servlet
D) O programa Java Servlet é compilado transformado em um bytecode
(.class)
E) Este .class pode ser auxiliado por pacotes .JAR que carregam Java Beans
F) Durante a montagem da página HTML, podem também ocorrer
solicitações a banco de dados
G) A página HTML é gerada
H) As chamadas Tags Personalizadas são transformadas neste momento em
Tags comuns para a geração final
I) A página final HTML é enviada de volta ao servidor
J) É devolvida para o cliente que fez a solicitação
A JSP usa linguagem Java como base para sua linguagem de scripts, utilizando todo o
potencial desta, sendo por esse motivo que a JSP se apresenta muito mais flexível e muito
mais robusta do que as outras linguagens [ANSELMO].

57. 57
5 RESULTADOS
O estudo de caso apresentado possibilitou a coleta de resultados através de testes
efetuados num mesmo sistema, no qual um utiliza um BD centralizado e o outro um BD-D.
Os resultados foram concluídos com base em:
- Duas aplicações web foram desenvolvidas conectadas em bases de dados configuradas
de forma distinta, ou seja, a primeira aplicação foi desenvolvida com o objetivo de demonstrar a
funcionalidade de um banco de dados centralizado; já a segunda utiliza um banco de dados
distribuído devidamente preparado e configurado.
- As aplicações realizam as mesmas operações de consulta, só que a primeira conecta
várias vezes em bancos diferentes até que encontre o resultado da busca; já a aplicação com BDD
conecta-se uma única vez ao banco principal retornando assim o resultado da SELECT efetuada.
Esse exemplo está melhor identificado no tópico 5.2 no qual se faz comparações entre as duas
conexões.
- O grande resultado observado é quanto à velocidade de busca das consultas efetuadas
pelos clientes. Enquanto uma aplicação com BD-Centralizado demora, dependendo do servidor,
em torno de 6 segundos para retornar o resultado da SELECT, a aplicação com BD-Distribuido
demora 2,5 segundos. Isso se dá ao fato do mesmo efetuar apenas uma conexão, portanto
podemos concluir que podemos ter um ganho de aproximadamente 60%, lembrando que isso
dependerá da conexão e do servidor.
5.1 Vantagens
A principal vantagem da utilização de um banco de dados distribuído em uma aplicação
web é a característica de partilhar e acessar dados de uma maneira confiável e eficiente, além do
aumento de velocidade no processamento de consultas e do crescimento incremental, de possuir
disponibilidade, confiabilidade e um controle distribuído, além da sua transparência e autonomia.
Com relação ao estudo de caso apresentado podemos destacar uma necessidade muita
interessante que só foi possível graças a utilização de um gerenciador de banco de dados
distribuído, essa necessidade diz respeito ao compartilhamento dos dados entre as filiais, sendo

58. 58
que cada compartilhamento possui um controle de distribuição, caracterizando assim
confiabilidade e disponibilidade.
Além disso, outras relações importantes são: rapidez no processamento das consultas e a
transparência para o usuário, ou seja, em momento algum o usuário sabe em qual local tal
consulta esta sendo executada.
5.1.1 Compartilhamento de Dados e Controle de Distribuição
A principal vantagem de partilhar informações pela distribuição de dados é que cada nó é
capaz de reter um grau de controle sobre os dados armazenados localmente. Em sistemas
distribuídos, existe um administrador global do banco de dados que é responsável pelo sistema
como um todo. Uma parte dessas responsabilidades é delegada ao administrador do banco de
dados local para cada nó. Dependendo do projeto do banco de dados distribuído, cada
administrador pode ter um grau diferente de autonomia local. A possibilidade de autonomia local
é freqüentemente uma grande vantagem de banco de dados distribuídos, especialmente no
contexto de aplicações web, onde a instabilidade da rede pode ocasionar falhas na comunicação
com um determinado site.
5.1.2 Confiabilidade e Disponibilidade
Confiabilidade significa que um sistema funciona conforme foi projetado.
Disponibilidade quer dizer que o sistema realiza suas funções sempre que é requerido.
Ambas são necessárias: um sistema confiável que não esteja sempre disponível é
impraticável; um sistema disponível que não seja confiável também. Se um nó falhar em um
sistema distribuído, os nós remanescentes podem ser capazes de continuar operando. A falha de
um nó pode ser detectada pelo sistema e uma ação apropriada pode ser necessária para recuperar
a falha. Quando o nó que falha se recupera ou é reparado, deve haver mecanismos disponíveis
para integrar habilmente o nó de volta ao sistema.
Embora a recuperação de falhas seja mais complexa em sistemas distribuídos, a
habilidade da maioria dos sistemas para continuar a operar apesar da falha de um nó resulta no