bd web dist

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

Upload: pauloerica

Post on 18-Nov-2014

1.579 views

Category:

Documents


0 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Bd web dist

Adriano Giacometti de Souza Lemes

R.A. 0200330 8º Semestre

BANCO DE DADOS DISTRIBUÍDOS EM APLICAÇÕES WEB

Jaguariúna

2005

Page 2: Bd web dist

2

Adriano Giacometti de Souza Lemes

R.A. 0200330 8º Semestre

BANCO DE DADOS DISTRIBUÍDOS EM APLICAÇÕES WEB

Jaguariúna

2005

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.

Page 3: Bd web dist

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

Page 4: Bd web dist

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.

Page 5: Bd web dist

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

Page 6: Bd web dist

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

Page 7: Bd web dist

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

Page 8: Bd web dist

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

Page 9: Bd web dist

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

Page 10: Bd web dist

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

Page 11: Bd web dist

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.

Page 12: Bd web dist

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

Page 13: Bd web dist

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

Page 14: Bd web dist

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

Page 15: Bd web dist

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

Page 16: Bd web dist

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

Page 17: Bd web dist

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

Page 18: Bd web dist

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

Page 19: Bd web dist

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.

Page 20: Bd web dist

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

Page 21: Bd web dist

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

Page 22: Bd web dist

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”

Page 23: Bd web dist

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.

Page 24: Bd web dist

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

Page 25: Bd web dist

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

Page 26: Bd web dist

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.

Page 27: Bd web dist

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

Page 28: Bd web dist

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

Page 29: Bd web dist

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

Page 30: Bd web dist

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:

Page 31: Bd web dist

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.

Page 32: Bd web dist

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

Page 33: Bd web dist

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.

Page 34: Bd web dist

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

Page 35: Bd web dist

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.

Page 36: Bd web dist

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.

Page 37: Bd web dist

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.

Page 38: Bd web dist

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

Page 39: Bd web dist

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

Resposta à requisiçãoHTTP

BrowserServidor

Web

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.

S e r v id o r W e b S e r v id o r B DB r o 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 DB r o w s e r W e b

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.

Page 40: Bd web dist

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.

Page 41: Bd web dist

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.

Page 42: Bd web dist

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

Page 43: Bd web dist

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:

Page 44: Bd web dist

44

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

Page 45: Bd web dist

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.

Page 46: Bd web dist

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

Page 47: Bd web dist

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.

Page 48: Bd web dist

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

Page 49: Bd web dist

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

Page 50: Bd web dist

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.

Page 51: Bd web dist

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

Page 52: Bd web dist

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

Page 53: Bd web dist

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

Page 54: Bd web dist

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

Page 55: Bd web dist

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.

Page 56: Bd web dist

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

Page 57: Bd web dist

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

Page 58: Bd web dist

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

Page 59: Bd web dist

59

aumento da disponibilidade, que, por exemplo, é crucial em sistemas de banco de dados

utilizados em aplicações de tempo real.

5.1.3. Aceleração no Processo de Consultas

Se uma consulta envolve dados em diversos nós, é possível dividi-la em sub-consultas

que podem ser executadas em paralelo. Entretanto, em um sistema distribuído, não há o

compartilhamento da memória principal, assim sendo, nem todas as estratégias para

processadores paralelos podem ser aplicados diretamente a sistemas distribuídos. Nesses casos,

em que os dados são duplicados, as consultas podem ser direcionadas pelo sistema para os nós

com menos carga.

5.1.4. Transparência e Autonomia

A transparência de rede é o grau em que os usuários do sistema podem estar

despreocupados com os detalhes do projeto do sistema distribuído, ou seja, é a separação entre a

semântica de alto nível de um sistema e seus detalhes de implementação. A questão fundamental

é prover independência de dados no ambiente distribuído.

Os usuários do banco de dados visualizariam uma única imagem da base de dados

logicamente integrada, embora ela estivesse fisicamente distribuída. A autonomia local é o grau

em que um projetista ou administrador de um nó pode ser independente do restante do sistema

distribuído.

Considerando as questões de transparência e autonomia, pode-se ter:

Autonomia de Nomeação e de Local: Em banco de dados distribuídos, cuidados precisam ser

tomados para garantir que dois nós não usem o mesmo nome para itens de dados distintos. Uma

solução para este problema é requerer que todos os nomes sejam registrados em um servidor de

nome central. Para o aumento de autonomia local é requerer que cada nó prefixe seu próprio

identificador para qualquer nome que ele gerar. Isto assegura que dois nós não gerem o mesmo

nome (uma vez que cada nó tem um único identificador).

Transparência de Reprodução e Fragmentação: Quando um item de dado é requisitado, a

réplica específica não precisa ser nomeada. Em vez disso, uma tabela de catálogo é usada pelo

Page 60: Bd web dist

60

sistema para determinar todas as réplicas para o item de dado. Da mesma forma, um usuário não

deve ser solicitado a saber como um item é fragmentado.

Transparência de Localização: A transparência de localização é obtida criando-se um conjunto

de nomes alternativos ou aliases para cada usuário. Um usuário pode então se referir aos itens de

dados por meio de nomes simples, os quais são traduzidos pelo sistema para nomes completos.

Com aliases1, o usuário pode despreocupar-se em relação à localização física de itens de dado.

Ele não é afetado se o administrador do banco de dados decidir remover um item de um nó para

outro.

Transparência e Atualização: O problema principal é assegurar que todas as réplicas de um

item de dado e todos os fragmentos afetados sejam atualizados. O problema de atualização para

dados reproduzidos e fragmentados está relacionado ao problema de atualização de visões.

5.2 Desvantagens

Todo sistema, apesar de eficiente, também têm suas desvantagens e algumas delas estão

relacionadas aos custos e à complexidade, podendo gerar uma degradação do desempenho e um

aumento do número de “bugs”.

5.2.1. Custos

O custo em nível de software é bem mais alto em BD-D do que em um banco de dados

centralizado. Os fatores que determinam o aumento do custo são:

- Desenvolvimento de algoritmos eficientes e rápidos para controlar a fragmentação, replicação

de dados e processamento de consultas;

- Prevenção de falhas em nós da rede. Quando houver falha o sistema tem que continuar

funcionando. Para isto, deve-se desenvolver algoritmos contendo um número de replicação dos

dados satisfatória para suprir esta necessidade;

1 Habilidade de usar diferentes nomes para comandos cujo entendimento seja difícil

Page 61: Bd web dist

61

- Os softwares desenvolvidos devem ser portáveis para serem executados em qualquer hardware

e sistema operacional, ou o sistema de um ambiente para outro deve sofrer pequenas alterações;

- Os algoritmos de consulta devem ser rápidos e eficientes para satisfazer a expectativa de tempo

x resposta que o usuário tem em relação ao sistema;

- Os algoritmos de backup devem ser capazes de guardar as últimas atualizações do sistema, além

de especificar se os mesmos devem ser feitos à noite, ao meio-dia ou se devem parar todo

sistema.

O mais importante é que o SGBD-D e os programas devem garantir, acima de tudo, dados

consistentes em todas as atualizações e consultas feitas.

5.2.2. Complexidade

A complexidade adicional requerida para assegurar a própria coordenação entre os nós é a

principal desvantagem de um SGBD-D. Através dela são gerados um maior potencial de erros;

uma vez que os nós que formam o sistema distribuído operam em paralelo, sendo mais difícil

assegurar a correção dos algoritmos, há uma degradação do desempenho de processamento, uma

vez que a mudança de mensagens e a computação adicional requerida para realizar a coordenação

interna não surgem em sistemas centralizados, gerando assim esse baixo desempenho.

Dependendo de como a consulta foi desenvolvida (algoritmo) pode tornar-se muito

complexa e levar muito tempo para ser executada.

5.3 Comparações

Os testes apresentados a seguir foram executados de duas formas:

1º - Foi feita uma customização na aplicação web onde a mesma acessa um BD-D, para

isso veja a forma de conexão entre a base de dados distribuída:

Page 62: Bd web dist

62

1 - try {

2 - Class.forName("net.sourceforge.jtds.jdbc.Driver");

3 - } catch (java.lang.ClassNotFoundException e) {

4 - System.err.print("ClassNotFoundException: ");

5 - System.err.println(e.getMessage());

6 - }

7 - try {

8 - String base = "TCC_A";

9 - String server = "AGSL:1433";

10 - String url = "jdbc:jtds:sqlserver://"+server+"/"+base;

11 - conn = DriverManager.getConnection(url, " ", " ");

12 - stmt = conn.createStatement();

13 - } catch (SQLException e) {

14 - out.println(e);

15 - }

2º - Já na segunda aplicação foi feito uma conexão similar ao apresentado acima, só que

de uma tal forma conectando a um BD centralizado, veja:

1 - nBd = 1;

2 - bd = “A”;

3 - while (nBd < = 4) {

4 - try {

5 - Class.forName("net.sourceforge.jtds.jdbc.Driver");

6 - } catch (java.lang.ClassNotFoundException e) {

7 - System.err.print("ClassNotFoundException: ");

8 - System.err.println(e.getMessage());

9 - } try {

10 - String base = "TCC_"+bd;

11 - String server = "AGSL:1433";

12 - String url = "jdbc:jtds:sqlserver://"+server+"/"+base;

13 - conn = DriverManager.getConnection(url, " ", " ");

14 - stmt = conn.createStatement();

15 - } catch(SQLException e) {

16 - out.println(e);

17 - }

18 - nBd++;

19 - if(nBd == 2){

Page 63: Bd web dist

63

20 - bd=B;

21 - }

22 - if(nBd == 3){

23 - bd=C;

24 - }

25 - if(nBd == 4){

26 - bd=D;

27 - }

28 - }

Concluindo o que foi apresentado nas comparações, vantagens/desvantagens e de uma

forma geral, podemos destacar o seguinte:

A primeira aplicação efetua somente uma conexão com o banco TCC_A (veja linha 8),

onde a mesma possui “assinaturas” das outras tabelas que conseqüentemente são de outros

bancos;

Já a segunda aplicação necessita de uma variável na qual armazena sempre uma próxima

conexão, ou seja, ao rodar a aplicação serão efetuadas 4 conexões caso a busca não obtenha

sucesso nas três primeiras, isso para este estudo de caso.

Veja, uma aplicação pode conter “n” conexões com os bancos de dados, por exemplo,

uma aplicação com 10 bancos (10 filiais diferentes), conseqüentemente serão efetuadas 10

conexões, caso as nove primeiras não tragam o resultado esperado, isso resulta em uma demora

ainda maior nas consultas às tabelas.

Page 64: Bd web dist

64

6 CONCLUSÃO

A tecnologia de Banco de Dados Distribuídos está em crescente expansão, visto que as

limitações nas transmissões de dados têm diminuído com a evolução das redes de computadores.

A possibilidade de poder ter as informações mais próximas de onde serão utilizadas,

podendo cada nó ter um grau de controle sobre os dados locais - autonomia local, é a maior

vantagem da distribuição de dados, sem levar em consideração a transparência. No entanto, deve-

se levar em conta à complexidade adicionada à coordenação entre os nós, que pode ser

considerada a principal desvantagem na utilização de sistemas de banco de dados distribuídos.

Devido também ao seu alto custo, muitas empresas preferem utilizar tecnologias que

usem conceitos de Sistemas Distribuídos à usar diretamente Banco de Dados Distribuídos.

Sabe-se que muitas empresas desejam possuir um Banco de Dados Distribuído, porém sua

Complexidade e, principalmente seu alto custo tornam esse desejo, muitas vezes, inviável.

Para se utilizar um Sistema de Banco de Dados Distribuído são necessários altos

investimentos em estruturas de redes, hubs, switches, routers, hardware, software, além de um

grande e capacitado treinamento de pessoal.

Contudo, em se tratando de software, as empresas aplicaram as suas bases de dados

utilizando conceitos de BDD, graças ao surgimento SQL Server, uma das mais completas e

viáveis ferramentas do mundo, ou seja, as instituições podem possuir um Banco de Dados

completo com características Distribuídas. Para empresas nacionais e internacionais (como Redes

Hospitalares, Bancos, etc.) consideradas de grande porte é necessário ter um Banco Distribuído;

no entanto para empresas de pequeno e médio porte, é importante ter um Banco Distribuído,

porém não sendo necessário devido ao volume de informações. Se o Custo e a Complexidade são

grandes, a melhor solução é adotar uma ferramenta que possua tais características e solucione os

problemas.

O SQL Server no futuro promete-nos muitas ferramentas de software ainda mais

vantajosas, relacionadas a todas as áreas especificadamente, prova disto, é o lançamento da nova

versão, quem sem dúvida estará ainda mais voltado especificamente para atender necessidades

distribuídas.

Page 65: Bd web dist

65

Os conceitos de Banco de Dados Distribuídos começam a se firmar mais no mercado e,

com isso, pretendem alcançar um grande domínio entre as empresas. Contudo, estuda-se a

probabilidade de sua distribuição ficar menos complexa e menos custosa, para que assim, possa

atender a todo o mercado, sem restrições. A utilização do SQL Server como uma ferramenta de

BDD abre um vasto horizonte de aplicações, pois pode-se realizar estudos específicos em grandes

empresas, para ver o quanto seus BD são utilizados e com que finalidades, se são centralizados e

como podem se tornar distribuídos; enfim, para ter-se uma noção das necessidades apresentadas

pelas mesmas, e buscar soluções em tipos específicos de BD e de softwares.

Com visto existe diversas vantagens para a utilização de um SGBD-D, sendo que as

principais, podem destacar a confiabilidade, transparência para o usuário e sem dúvida a

facilidade de implementação, isto é, o trabalho de implementação quando se usa um SGBD-D é

menos complexa, como visto no tópico 5.3. Conseqüentemente a performance cresce melhorando

assim todas as transações com o banco de dados, em contra partida um SGBD centralizado fica

inviável devido sua complexidade de desenvolvimento, ou seja, implementação do sistema.

O que se pode notar neste trabalho apresentado e no estudo de caso realizado é que um

SGBD centralizado, claro que dependendo da estrutura geográfica da empresa, é extremamente

inviável, portanto referente ao estudo de caso feito, ficou comprovado que um SGBD-D é de

suma importância devido as diversas filiais espalhadas pelo Brasil e pelo mundo, sendo que os

dados estão sendo compartilhados e disponibilizados de forma transparente e segura para todos os

usuários, e sem esquecer que a aplicação que esta rodando, possibilitando a interface com o

usuário é uma só, ou seja, independente da quantidade de banco de dados existentes existe um

único sistema realizando todas as operações feitas pelo usuário.

Page 66: Bd web dist

66

REFERÊNCIAS BIBLIOGRÁFICAS

ANSELMO, Fernando. Tudo o que você queria saber sobre o JSP quando utiliza o servidor

TomCat com o banco MySQL. Visual Books, 2002

CONNALEM, Jim. Desenvolvendo aplicações web com UML. Tradução da 2a Edição, Editora

Campus, 1999.

DATE, C. J. Introdução a Sistemas de Bancos de Dados. 7a Edição, Ed. Campus, 2000.

GUNDERLOY, Mike; JORDEN, Joseph L. Dominando SQL Server 2000 “A Biblia”. Makron

Books, 2001

SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistema de Banco de Dados. 3a Edição,

Makron Books, 1999.

Page 67: Bd web dist

67

BIBLIOGRÁFIA ADICIONAL ALVES, William Pereira. Fundamentos de Bancos de Dados. 1ª Edição, Editora Érica, 2003

DEITEL, Harvey M.; DEITEL, Paul J. Java: Como Programar. 4ª Edição. Bookman, 2002.

DISTRIBUÍDO, Banco de Dados. Disponível via url em: http://atlas.ucpel.tche.br

/~lichtnow/bd2.htm#notas. Acesso em 28 de outubro de 2005

DISTRIBUÍDO, Banco de Dados. Disponível via url em: http://pt.wikipedia.org

/wiki/Banco_de_dados_distribu%C3%ADdos. Acesso em 28 de outubro de 2005

DISTRIBUÍDO, Banco de Dados. Disponível via url em: http://www.lasid.ufba.br

/eventos/wola99/resumos/fernando.html. Acesso em 28 de outubro de 2005

ELMASRI; NAVATHE. Sistemas de Banco de Bados. 4ª Edição, Makron Books

KURNIAWAN, Budi. Java para a Web com Servlets, JSP e EJB. Editora Ciência Moderna,

2002

MACHADO, Felipe Nery Rodrigues. Banco de Dados - Projeto e Implementação. 1ª Edição,

Editora Érica, 2003