Bd web dist
Upcoming SlideShare
Loading in...5
×
 

Bd web dist

on

  • 1,461 views

 

Statistics

Views

Total Views
1,461
Views on SlideShare
1,461
Embed Views
0

Actions

Likes
0
Downloads
24
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Bd web dist Bd web dist Document Transcript

  • Adriano Giacometti de Souza Lemes R.A. 0200330 8º Semestre BANCO DE DADOS DISTRIBUÍDOS EM APLICAÇÕES WEB Jaguariúna 2005
  • 2 Adriano Giacometti de Souza Lemes R.A. 0200330 8º Semestre BANCO DE DADOS DISTRIBUÍDOS EM APLICAÇÕES WEB Monografia apresentada à disciplina Trabalho de Conclusão de Curso, do curso de Ciência da Computação da Faculdade de Jaguariúna, sob a orientação do Prof. Ms. Leonardo Hartleben Reinehr, como exigência parcial para a conclusão do curso de graduação. Jaguariúna 2005
  • 3 LEMES, Adriano Giacometti de Souza. Banco de Dados Distribuídos em Aplicações Web. Monografia defendida e aprovada na FAJ e pela banca Examinadora constituída pelos professores: _____________________________________________________ Prof. Ms. Leonardo Hartleben Reinehr Professor Orientador _____________________________________________________ Prof. Ms. Oderson Dias de Mello Professor Convidado _____________________________________________________ Prof. Ms. Roberto Pacheco Professor Convidado
  • 4 AGRADECIMENTOS Antes de iniciar a minha lista de agradecimentos, primeiramente gostaria de pedir a benção de Deus, pois foi através dele que cheguei até esta etapa da minha vida. Com tudo gostaria de agradecer a todos os que me ajudaram durante esses quatros anos de sabedoria que obtive, e coisas que acabei aprendendo no caminho percorrido. Agradeço inicialmente a toda a minha família que me ajudou a chegar e a superar esse desafio de concluir uma faculdade, onde nos dias de hoje isso esta cada vez mais difícil. Gostaria de agradecer também a todo o corpo docente da faculdade que de alguma forma me ensinou pelo menos um pouco o que cada um sabia, e, além disso, demonstrando histórias de vida, um agradecimento especial vai ao meu orientador Leonardo no qual com muita paciência me ajudou a preparar esse trabalho feito com tanta dedicação e entusiasmo. Agradeço também a todos os colegas de sala, em especial o Emerson e o Luciano, que juntos superamos cada dia de estudo e trabalho trilhando um caminho de conquistas e derrotas, mas sempre com muito entusiasmo e perseverança. E por fim um agradecimento a uma pessoa muito especial, Gaciana, na qual me ajudou com muita paciência e tolerância, nos finais de semana no qual ficávamos o dia inteiro no computador finalizando cada etapa deste projeto, enfim agradeço a Deus e a todos, por tudo o que me ajudaram durante esses quatro anos de luta no qual todos nós percorremos, obrigado por tudo e que Deus proteja a todos nós em cada dia de novos desafios.
  • 5 "VOCÊ MESMO Lembre-se de que você mesmo é o melhor secretário de sua tarefa, o mais eficiente propagandista de seus ideais, a mais clara demonstração de seus princípios, o mais alto padrão do ensino superior que seu espírito abraça e a mensagem viva das elevadas noções que você transmite aos outros. Não se esqueça, igualmente, de que o maior inimigo de suas realizações mais nobres, a completa ou incompleta negação do idealismo sublime que você apregoa, a nota discordante da sinfonia do bem que pretende executar, o arquiteto de suas aflições e o destruidor de suas oportunidades de elevação - é você mesmo." -- Psicografada por Francisco Cândido Xavier
  • 6 LEMES, Adriano Giacometti de Souza. Banco de Dados Distribuído em Aplicações Web. Monografia (Bacharelado em Ciência da Computação) – Curso de Ciência da Computação da Faculdade de Jaguariúna, Jaguariúna. RESUMO Atualmente em muitos dos sites que visitamos, em especial os de comércio eletrônico, nos deparamos com a seguinte pergunta: como um site consegue armazenar uma quantidade tão grande de informações? A resposta é simples e direta: sempre, por traz de um grande site existe um banco de dados robusto e seguro armazenando dados confidenciais como, CPF, endereço. Quando falamos em banco de dados logo imaginamos um computador de grande porte armazenando centenas de milhares de informações ao mesmo tempo. Essa dedução é verdadeira, mas às vezes o que não sabemos é que quando efetuamos uma compra em um determinado site, não sabemos de onde vem aquele produto – por exemplo, em uma rede de lojas de conveniência as lojas estão espalhadas geograficamente. Nesse exemplo, como é o armazenamento de seus dados, como cliente, fornecedor, produto, entre outros? Para que se entenda como as informações dessas lojas referentes aos produtos são recuperadas usando as informações existentes nas diversas filiais, falaremos sobre bancos de dados distribuídos, que podem ser utilizados por sites de comércio eletrônico. Uma empresa que utiliza bancos de dados distribuídos mantém os dados de cada filial em um banco de dados separado, porém os bancos são capazes de se comunicar entre si. Assim, ao efetuarmos uma compra numa determinada filial - A, onde não sabemos se nela vai existir o que queremos comprar, por fim ao consultarmos o produto constatamos que o mesmo tem em estoque e que podemos comprar. Só que não sabemos se este produto esta na loja A, B, C ou na N-ésima loja, que está espalhada geograficamente. O objetivo deste trabalho visa demonstrar através de uma aplicação web a utilização de um banco de dados distribuído, onde existirá uma única aplicação demonstrando a diferença entre um SGBD-D e um SGBD. Com essa comparação será possível ampliar os conceitos técnicos de um banco de dados distribuído em relação ao tradicional, ou seja, o centralizado. Palavras-chave: banco de dados distribuído, aplicação web
  • 7 SUMÁRIO 1 INTRODUÇÃO..................................................................................................................... 10 2 REVISÃO BIBLIOGRÁFICA .............................................................................................. 12 2.1 Definições............................................................................................................................. 12 2.1.1 Visão geral......................................................................................................................... 13 2.1.2 Funcionamento .................................................................................................................. 15 2.1.2.1 Armazenamento distribuído ........................................................................................... 16 2.1.3 Arquitetura ........................................................................................................................ 16 2.1.3.1 Recursos de SQL............................................................................................................ 17 2.1.4 Autonomia local ................................................................................................................ 18 2.1.4.1 Independência de localização......................................................................................... 18 2.1.4.2 Independência de fragmentação ..................................................................................... 19 2.1.4.3 Independência de replicação .......................................................................................... 22 2.1.4.4 Gerenciamento de transações distribuídas ..................................................................... 24 2.1.5 Gerenciamento .................................................................................................................. 24 2.1.5.1 Tipos de falhas no sistema ............................................................................................. 25 2.1.5.2 Robustez ......................................................................................................................... 26 2.2 Aplicações web .................................................................................................................... 28 2.2.1 Conceitos e visão geral...................................................................................................... 28 2.2.2 Arquitetura ........................................................................................................................ 30 2.2.3 Segurança .......................................................................................................................... 32 2.2.3.1 Tipos de riscos de segurança.......................................................................................... 33 2.2.3.2 Risco técnico .................................................................................................................. 34 2.2.3.3 Estratégias de segurança................................................................................................. 36 2.2.3.4 Criptografia .................................................................................................................... 37 2.3 Banco de dados distribuídos e aplicações web..................................................................... 38 2.3.1 Aplicações distribuídas ..................................................................................................... 39 3 ESTUDO DE CASO ............................................................................................................. 42 3.1 Justificativas e necessidades................................................................................................. 42 3.2 Especificação do problema................................................................................................... 42 3.3 Modelo de dados .................................................................................................................. 43 3.4 Testes.................................................................................................................................... 45 4 PROTÓTIPO ......................................................................................................................... 46 4.1 Projeto .................................................................................................................................. 46 4.1.1 Arquitetura ........................................................................................................................ 46 4.1.2 Projeto do banco de dados................................................................................................. 47 4.2 Implementação ..................................................................................................................... 48 4.2.1 Sistema gerenciador de banco de dados distribuído.......................................................... 49 4.2.2 Linguagem de programação web ...................................................................................... 54 5 RESULTADOS ..................................................................................................................... 57 5.1 Vantagens ............................................................................................................................. 57 5.2 Desvantagens........................................................................................................................ 60 5.3 Comparações ........................................................................................................................ 61 6 CONCLUSÃO....................................................................................................................... 64
  • 8 LISTA DE SIGLAS API – Application Program Interface ASP – Active Server Pages BD – Banco de Dados BD-D – Banco de Dados Distribuído BR – Brasil CA – Certificado de autenticidade DHTML – Dinamic HiperText Markup Language DNS – Domain Name Server EJB – Enterprise Java Beans FTP – File Transfer Protocol HMTL – HyperText Markup Language HTTP – Hyper Text Transfer Protocol IP – Internet Protocol JDBC – Java DataBase Connectivity JP – Japão JSP – Java Server Pages LAN – Local Area Network MTS – Transaction Server Microsoft ODBC – Open DataBase Connectivity (Base de Dados aberta para conexão) OSI – Open Systems Interconnections SET – Secure Electronics Transaction SGBD - D – Sistema Gerenciador de Banco de Dados Distribuídos SGBD – Sistema Gerenciador de Banco de Dados SQL – Structure Query Language SSL – Secure Sockets TCP – Transmission Control Protocol URL – Uniform Resource Locator VPN – Virtual Private Network WAN – Wide Area Networks XML – eXtensible Markup Language
  • 9 LISTA DE FIGURAS Figura 2.1 – Comunicação entre banco de dados distribuídos geograficamente Figura 2.1.3 – Um sistema Web acessando um banco de dados Figura 2.1.4.2 – Um exemplo de fragmentação entre dados de BR e JP e a percepção do usuário Figura 2.1.4.3 – Um exemplo de replicação Figura 2.1.5.1 – Topologia de redes de computadores Figura 2.2.1 – Modelo simples de resposta e requisição entre cliente/servidor Figura 2.2.3.2 – Redes privativas virtuais Figura 2.2.3.3 – Posição do firewall Figura 2.3.1.1 – Representação de uma aplicação distribuída sem acesso à banco de dados Figura 2.3.1.2 – Representação de uma aplicação distribuída acessando um determinado banco de dados não-distribuído Figura 2.3.1.3 – Exemplo de acesso a uma aplicação web com vários bancos interligados. Figura 2.3.1.4 – Aplicação web acessando BD centralizado Figura 3.3.1 – Estrutura física do sistema de banco de dados distribuídos Figura 3.3.2 – Modelo Relacional do estudo de caso Figura 4.1 – Tela principal onde o usuário define a retirada e a devolução Figura 4.1.1 – Representação da arquitetura do protótipo do sistema Figura 4.1.2 – SGBD-D configurado Figura 4.2.2 – Estrutura de funcionamento de páginas com a tecnologia JSP
  • 10 1 INTRODUÇÃO Um sistema de banco de dados tradicional é dito centralizado, pois todos os dados estão armazenados em um único local. Todas as aplicações que necessitam acessar os dados o fazem por meio de um servidor. [SILBERSCHATZ]. Entretanto, com o crescente desenvolvimento das aplicações distribuídas, tornou-se necessário acessar os dados armazenados em um banco de dados a partir de diversos locais diferentes. As diversas filiais de uma empresa, por exemplo, podem armazenar individualmente os dados que controlam, mas eventualmente os gerentes das filiais necessitam consultar os dados de todas elas para recuperar algum relatório de toda a empresa. Além disso, diversos bancos de dados locais passaram a serem vistos como um grupo, cujo conjunto de informações está acessível como se estivesse armazenado em um único local. Tais necessidades levaram ao desenvolvimento dos bancos de dados distribuídos [SILBERSCHATZ]. Um Sistema de Gerenciamento de Banco de Dados Distribuído (SGBD-D) consiste de uma coleção de nós ou sites – pequenos computadores, estações de trabalho, mainframes ou sistemas de computadores de uso geral, onde cada nó pode participar na execução de transações que fazem acesso a dados de um ou diversos nós. Os nós que formam um SGBD-D podem se comunicar por diversos meios, tais como barramentos de alta velocidade e linhas telefônicas. Assim, a principal diferença entre sistemas de bancos de dados centralizados e distribuídos é que no primeiro os dados estão armazenados em um único local, enquanto no segundo os dados residem em diversos locais [SILBERSCHATZ]. Os bancos de dados distribuídos fornecem mecanismos para, a partir de dados situados em locais diferentes, processar consultas e atualizações de forma transparente, simulando a existência de um único banco de dados e um único esquema de dados. Isto facilita a visualização de um conjunto de banco de dados como um único [SILBERSCHATZ]. As aplicações Web podem especialmente se beneficiar da utilização de SGBD-Ds, já que a World Wide Web (WWW) é o maior sistema distribuído existente. Por isso, é importante avaliar o impacto da utilização de SGBD-Ds nesse tipo de aplicação. Para demonstrar a utilização de um SGBD-D, o projeto é dividido em quatro etapas, a primeira etapa demonstra todas as características de um gerenciador de banco de dados
  • 11 distribuído, definições, visão geral de um SGBD-D, funcionamento, entre outros. E na mesma etapa, demonstra desde o início de uma aplicação web, ou seja, como surgiu, como funciona, o que é uma aplicação web, e também a relação com um SGBD-D. Já a segunda parte foi dedicada ao estudo de caso, demonstrando as justificativas, especificações, modelo dos dados e os testes. A terceira parte foi desenvolvido o protótipo, sistema responsável pela execução dos testes, nesta etapa será identificado à arquitetura, projeto dos dados, implementação, qual SGBD escolhido e qual linguagem de programação utilizada. E já a quarta e última etapa dedicam-se aos resultados e conclusões, vantagens, desvantagens e o aspecto geral sobre banco de dados distribuído.
  • 12 2 REVISÃO BIBLIOGRÁFICA Esta seção apresenta os tópicos relacionados a este trabalho, os quais servem de base para o desenvolvimento do restante do mesmo. Para cada tópico são descritos os principais conceitos envolvidos, suas características, arquiteturas e outras informações importantes. 2.1 Definições Um sistema de banco de dados distribuído consiste em um conjunto de sites, ligados entre si através de algum tipo de rede de comunicações, em que: - Cada site é um site completo de sistema de banco de dados. - Porém, os sites atuam juntos, de modo que um usuário em qualquer site pode ter acesso a dados em qualquer lugar da rede, exatamente como se os dados estivessem armazenados no site do próprio usuário. Assim, um banco de dados distribuído é na verdade uma espécie de banco de dados virtual, no qual seus componentes estão fisicamente armazenados em vários bancos de dados reais distintos [DATE].
  • 13 Figura 2.1 - Comunicação entre banco de dados distribuídos geograficamente [DATE] Observe que cada site é ele próprio, do sistema de banco de dados por si mesmo, ou seja, o sistema de banco de dados distribuído pode, portanto, ser considerado como um tipo de parceria entre SGBDs individuais locais nos sites locais individuais; um novo componente de software em cada site - logicamente uma extensão do SGBD local - fornece as necessárias funções da parceria e é a combinação desse novo componente com o SGBD existente. A propósito, é comum deduzir que os sites estão fisicamente separados - talvez até geograficamente. Na verdade, o foco em sistemas distribuídos se deslocou nos últimos anos; enquanto a maior parte da pesquisa tendia a assumir a distribuição geográfica, a maior parte das primeiras instalações comerciais envolvia a distribuição local, com (por exemplo) vários sites, no mesmo edifício e interligados por meio de uma rede local (LAN). Porém, mais recentemente, a enorme proliferação de redes remotas (WAN) reativou o interesse na possibilidade de distribuição geográfica. [DATE] 2.1.1 Visão geral
  • 14 Um site pode participar da execução de uma transação global; transações essas que mantêm acesso em diversos sites. A execução de transações globais exige comunicação entre os sites [CONNALEM]. Há muitas razões para construir um banco de dados distribuído, incluindo o compartilhamento de dados, confiabilidade, disponibilidade e rapidez no processamento de consultas. Entretanto, essas vantagens são acompanhadas de muitas desvantagens, como o alto custo de desenvolvimento de software e o alto potencial de bugs. A principal desvantagem dos sistemas de bancos de dados distribuídos é a complexidade adicional para a garantir a coordenação adequada entre os sites. Um sistema distribuído pode sofrer os mesmos tipos de falhas que um sistema centralizado. Há, entretanto, tipos de falhas que precisam ser tratados em um ambiente distribuído, incluindo a falha de um site, a perda de mensagens e o particionamento da rede. Cada um desses problemas precisa ser considerado no projeto de um esquema de recuperação. Para um sistema ser robusto de fato, ele precisa detectar qualquer uma dessas falhas, reconfigurar-se de modo a manter o processamento e recuperar-se enquanto um processador ou uma ligação é recuperada [DATE]. O protocolo de efetivação em duas fases pode gerar obstrução, situação na qual o destino de uma transação não pode ser determinado até que um site que falhou (coordenador) tenha se recuperado. Os diversos esquemas de controle de concorrência que são usados em sistemas centralizados podem ser modificados para uso em ambientes distribuídos. Alguns exemplos de protocolos para o tratamento de dados replicados são o parcial e o de cópia primária. No caso dos esquemas de registro de tempo (timestamping) e validação, a única mudança necessária é o desenvolvimento de um mecanismo para a geração de registros de horários únicos globais. Isso pode ser feito ou pela concatenação do registro de tempo local com a identificação do site ou adiantando o relógio local sempre que uma mensagem chega com um registro de tempo maior [DATE]. O principal problema é decidir como manter os gráficos de espera. Os diferentes métodos para a organização desses gráficos trabalham com enfoques centralizados, hierárquicos e totalmente distribuídos. Alguns algoritmos distribuídos precisam de um coordenador. Se o coordenador falhar em virtude de uma falha do site no qual reside, somente após o reinício do coordenador em algum
  • 15 outro site o sistema poderá continuar processando. Isso pode ser feito por meio da manutenção de um backup do coordenador [SILBERSCHATZ] que estará pronto a assumir a função no caso de alguma falha. Outra opção é escolher um novo coordenador, os algoritmos que determinam onde a nova cópia do coordenador funcionará são chamados de algoritmos de eleição. Um sistema de banco de dados múltiplo proporciona um ambiente em que novas aplicações de banco de dados podem manter acesso a dados de diversos bancos de dados preexistentes, localizados em vários ambientes com hardware e software heterogêneos. Os sistemas de bancos de dados locais podem empregar modelos lógicos diferentes e linguagens de definição e manipulação de dados distintos, podem ainda diferir em relação aos mecanismos para controle de concorrência e gerenciamento de transações. Um sistema de banco de dados múltiplo cria a ilusão da integração lógica do banco de dados, sem impor uma integração física. [SILBERSCHATZ] 2.1.2 Funcionamento Podemos iniciar esse tópico com a seguinte pergunta: por que bancos de dados distribuídos são desejáveis? A resposta para essa pergunta é que normalmente as empresas já são distribuídas, pelo menos logicamente (em divisões, departamentos, grupos de trabalho, etc.) e com grande probabilidade também fisicamente (em fábricas, laboratórios, etc.) - e isso decorre que os dados também já estão normalmente distribuídos, porque cada unidade organizacional dentro da empresa necessariamente manterá dados que são relevantes para sua própria operação. O patrimônio total de informações da empresa é desse modo disseminado naquilo que às vezes se costuma chamar de ilhas de informações. Um sistema distribuído fornece as pontes necessárias para interligar essas linhas. Em outras palavras, ele permite que a estrutura do banco de dados reflita a estrutura da empresa - dados locais podem ser mantidos em instalações locais, às quais eles pertencem logicamente - enquanto ao mesmo tempo dados remotos estão disponíveis para acesso quando necessário [SILBERSCHATZ]. Um exemplo esclarecerá o que foi dito. Para simplificar, suponha que há apenas dois sites, São Paulo e Santa Catarina, e suponha que o sistema é um sistema bancário, com dados de contas para as contas de São Paulo armazenados São Paulo, e dados de contas para contas de Santa Catarina armazenados em Santa Catarina. Então, as vantagens são óbvias: o arranjo distribuído combina eficiência de processamento (os dados são mantidos próximos ao local em que são
  • 16 usados mais freqüentemente) com maior facilidade de acesso (é possível ter acesso a uma conta em São Paulo, a partir de Santa Catarina e vice-versa, através da rede de comunicações) [CONNALEM]. Fazer com que a estrutura do banco de dados reflita a estrutura da empresa é provavelmente (como acabamos de explicar) a principal vantagem de sistemas distribuídos. Contudo, devemos mencionar que também há algumas desvantagens, das quais a maior é o fato de sistemas distribuídos serem complexos, pelo menos do ponto de vista técnico. 2.1.2.1 Armazenamento distribuído Há diversos enfoques para o armazenamento de informações em um banco de dados distribuído: • Replicação: o sistema mantém replicas idênticas da relação. Cada replica é armazenada em diferentes sites, resultando na replicação dos dados. A alternativa para a replicação é armazenar somente uma cópia de uma determinada relação r. • Fragmentação: A relação é particionada em diversos fragmentos. Cada fragmento é armazenado em um site diferente. Podendo se dividir em horizontal, separam-se os registros (linhas) da tabela; e vertical, separa-se as colunas da tabela. • Replicação e fragmentação: A relação é particionada em vários segmentos. Os sistemas mantêm diversas réplicas de cada fragmento. [DATE] 2.1.3 Arquitetura Um sistema é um sistema distribuído em que: (a) alguns sites podem consultar diversos dados em lugares distintos, (b) o cliente não sabe em hipótese alguma em que sistema de dados ele está, (c) todas as aplicações são executadas no mesmo site [CONNALEM].
  • 17 Figura 2.1.3 - Um sistema Web acessando um banco de dados [SILBERSCHATZ] Lembramos ainda que são possíveis diversas variações sobre o tema básico: • Vários clientes poderiam compartilhar o mesmo SGBD-D. • Um único cliente poderia ser capaz de deter acesso a vastos SGBD-D. Esse caso por sua vez se subdivide em dois outros: A. O cliente está limitado a obter acesso a um único SGBD-D de cada vez, isto é, cada solicitação individual de banco de dados deve ser dirigida a um só SGBD-D; não é possível, dentro de uma única solicitação, combinar dados de dois ou mais SGBD-D. B. Para o cliente pode aparentar ser um único SGBD-D e o usuário não precisa saber qual SGBD-D armazena quais fragmentos de dados. 2.1.3.1 Recursos de SQL Atualmente, a SQL não fornece suporte para sistemas de bancos de dados distribuídos verdadeiros. É claro que nenhum suporte é exigido na área de manipulação de dados - toda a importância dos bancos de distribuídos (no que diz respeito ao usuário) está no fato de que os recursos de manipulação de dados devem permanecer inalterados. Porém, operações de definição
  • 18 de dados como FRAGMENT, REPLICATE, etc., são exigidas, mas não são fornecidas no momento [SILBERSCHATZ]. Por outro lado, a SQL admite certos recursos, incluindo em particular operações CONNECT e DISCONNECT para efetuar e desfazer conexões. Na verdade, uma aplicação de SQL deve executar uma operação CONNECT para se conectar ao servidor antes de poder emitir quaisquer solicitações de bancos de dados. Depois que a conexão é estabelecida, a aplicação - isto é, o cliente - pode emitir solicitações de SQL da maneira usual e o processamento de banco de dados necessário será executado pelo servidor. A SQL também permite que um cliente já conectado a um servidor se conecte a outro. O estabelecimento dessa segunda conexão faz a primeira se tornar adormecida; solicitações de SQL subseqüentes serão processadas pelo segundo servidor, até o momento em que o cliente (a) alterne para o servidor anterior por meio de outra operação nova, SET CONNECTION ou (b) se conecte a outro servidor, o que a segunda conexão se tornar adormecida também (e assim por diante). Em outras palavras, em qualquer instante determinado, um cliente poderá ter uma conexão ativa e qualquer número de conexões adormecidas, e todas as solicitações de banco de dados desse cliente serão direcionadas ao servidor [SILBERSCHATZ]. Finalmente, toda conexão estabelecida por um dado cliente (esteja ele ativo ou adormecido no momento) deve mais tarde ser fechada por meio de uma conexão DISCONNECT apropriada. 2.1.4 Autonomia local Os sites em um sistema distribuído devem ser autônomos, significando que todas as operações em um determinado site são controladas por esse site; nenhum site X deve depender de algum outro site Y para que sua operação seja bem-sucedida. A autonomia local também implica que dados locais são de propriedades e gerenciamentos locais, com contabilidade local, todos os dados “realmente” pertencem a algum banco de dados local, mesmo que sejam acessíveis a partir de outros sites remotos. Assim, questões como segurança, integridade e representação de armazenamento de dados locais permanecem sob controle [CONNALEM]. 2.1.4.1 Independência de localização
  • 19 A idéia básica da independência de localização (também chamada transparência de localização) é simples: os usuários não devem ser obrigados a saber onde estão fisicamente armazenados os dados, embora devam ser capazes de se comportar - pelo menos de um ponto de vista lógico - como se os dados estivessem todos armazenados em seu próprio site local. A independência de localização é desejável porque simplifica programas e atividades em terminal dos usuários. Em particular, permite que dados migrem de um site para outro sem invalidar qualquer desses programas ou atividades. Essa capacidade de migração desejável permite que dados sejam deslocados pela rede em resposta a alterações de exigências de desempenho [DATE]. 2.1.4.2 Independência de fragmentação Um sistema admite fragmentação de dados se uma dada variável de relação armazenada pode ser dividida em pedaços ou fragmentos para fins de armazenamento físico. A fragmentação é desejável por razões de desempenho: os dados podem ser armazenados no local em que são mais freqüentemente utilizados, de modo que a maior parte das operações seja apenas local, e o tráfego de rede seja reduzido. Por exemplo, considere a variável de relação de empregados EMP, com a amostra de valores apresentada na parte superior da Figura 2.1.4.2. Em um sistema que admitisse a fragmentação, poderíamos definir dois fragmentos [DATE]. FRAGMENT EMP AS N_EMP AT SITE ‘BR’ WHERE DEPTO# = ‘Dl’ OR DEPTO# = ‘D2’, L_ EMP AT SITE ‘JP’ WHERE DEPTO# = ‘D2’; Estamos supondo que (a) tuplas de empregados são mapeadas no armazenamento físico de modo bastante direto; (b) números de empregados e números de departamentos são apenas string de caracteres, e salários são apenas números; (c) D1 e D3 são departamentos da empresa no Brasil, e D2 é um departamento de da empresa no Japão. Em outras palavras, tuplas para empregados no Brasil serão armazenadas no site aqui no Brasil, e tuplas para empregados no Japão serão armazenadas no site lá no Japão. Observe os nomes dos fragmentos internos do sistema, N_EMP e L_EMP.
  • 20 Figura 2.1.4.2 - Um exemplo de fragmentação entre dados de BR e JP e a percepção do usuário [DATE] Existem basicamente duas espécies de fragmentação, horizontal e vertical (conforme mencionado no tópico 2.1.2.1), que correspondem às operações relacionais de restrição e projeção, respectivamente. De modo mais geral, um fragmento pode ser derivado por qualquer combinação arbitrária de restrições e projeções - ou melhor, arbitrária, mas tal que: • No caso da restrição, as restrições devem constituir uma decomposição ortogonal. • No caso da projeção, as projeções devem constituir uma decomposição sem perdas. O efeito prático dessas duas regras é que todos os fragmentos de uma determinada variável de relação serão independentes, no sentido de que nenhum deles poderá ser derivado dos outros ou ter uma restrição ou uma projeção que possa ser derivada dos outros. Se realmente quisermos armazenar o mesmo fragmento de informações em vários lugares diferentes, poderemos fazê-lo por meio do mecanismo de replicação do sistema. A reconstrução da variável de relação original a partir dos fragmentos é feita através de operações de junção e união convenientes (junção para fragmentos verticais, união para fragmentos horizontais). A propósito, no caso de união, observe que a eliminação de duplicatas não será necessária, graças à primeira das duas regras anteriores [DATE].
  • 21 Um sistema que suporta fragmentação de dados também deve admitir independência de fragmentação (também conhecida como transparência de fragmentação), isto é, os usuários devem ser capazes de se comportar, pelo menos de um ponto de vista lógico, como se os dados na verdade não estivessem fragmentados de modo algum. A independência de fragmentação (como a independência de localização) é desejável porque simplifica programas do usuário e atividades de terminal. Em particular, ela permite que os dados sejam refragmentados a qualquer momento (e os fragmentos sejam redistribuídos a qualquer momento) em resposta a mudanças nas exigências de desempenho, sem invalidar quaisquer desses programas ou atividades do usuário [DATE]. A independência de fragmentação implica que será apresentada aos usuários uma visão dos dados nas quais os fragmentos estão combinados logicamente por meio de junções e uniões adequadas. EMP WHERE SALÁRIO > 4000 AND DEPT0# = ‘D1’ Examinemos esse exemplo um pouco mais de perto. A variável de relação EMP, tal como é percebida pelo usuário, pode ser considerada (informalmente) uma visão dos fragmentos subjacentes N_EMP e L_EMP: VAR EMP VIEW N_EMP UNION L_EMP; Assim, o otimizador transforma a solicitação original do usuário na seguinte: (N_EMP UNION L_EMP ) WHERE SALÁRIO > 4000 AND DEPTO# = ‘Dl’ Essa expressão pode ainda ser transformada em: (N_ EMP WHERE SALÁRIO > 4000 AND DEPTO# = ‘Dl’) UNION (L_ EMP WHERE SALARIO > 4000 AND DEPTO# = ‘Dl’)
  • 22 A partir da definição do fragmento L_EMP no catálogo, o otimizador sabe que o segundo desses dois operandos de UNION é avaliado como uma relação vazia (a condição de restrição DEPTO# = ‘D1’AND DEPTO# = ‘D2’ nunca poderá ter o valor verdadeiro). Toda a expressão pode então ser simplificada para: N_EMP WHERE SALÁRIO > 4000 AND DEPTO# = ‘Dl’ Agora, o otimizador sabe que só precisa ter acesso ao site do Brasil. Considere o que significa para o otimizador lidar com a solicitação: EMP WHERE SALÁRIO > 4000 O problema de admitir operações sobre variáveis de relações fragmentadas tem certos pontos em comum como problema de admitir operações sobre visões de união e junção na verdade, os dois problemas é um só - ele simplesmente se manifestam em pontos diferentes na arquitetura geral do sistema. Em particular, o problema de atualizar variável de relações fragmentadas é idêntico ao problema de atualizar visões de junção e união [DATE]. 2.1.4.3 Independência de replicação Um sistema admite replicação de dados se uma dada variável de relação armazenada, ou geralmente, um dado fragmento de uma determinada variável de relação armazenada - pode ser representada por muitas cópias ou réplicas distintas, armazenadas em muitos sites distintos. Por exemplo: REPLICATE N EMP AS LN_ EMP AT SITE ‘Brasil’ REPLICATE L EMP AS NL_ EMP AT SITE “Japão”
  • 23 (consulte a Figura 2.1.4.3). Observe os nomes internos de réplicas do sistema, NL EMP e LN EMP. A replicação é desejável por pelo menos duas razões. Primeiro, pode significar melhor desempenho (aplicações podem operar sobre cópias locais, em vez de terem de se comunicar com sites remotos); segundo, também pode significar melhor disponibilidade (um dado objeto replicado permanece disponível para processamento - pelo menos para acesso - enquanto houver no mínimo uma cópia disponível). Naturalmente, a maior desvantagem da replicação é que, quando um determinado objeto replicado é atualizado, todas as cópias desse objeto precisam ser atualizadas; o problema da propagação de atualizações. Observamos de passagem que a replicação em um sistema distribuído representa uma aplicação específica da idéia de redundância controlada. Figura 2.1.4.3 - Um exemplo de replicação [DATE] Agora, a replicação, como a fragmentação, deve no caso ideal ser “transparente para o usuário”. Em outras palavras, um sistema que admita replicação de dados também deve admitir independência de replicação (também chamada transparência de replicação), isto é, os usuários devem ser capazes de se comportar, pelo menos de um ponto de vista lógico, como se os dados de fato não fossem replicados de modo algum.
  • 24 A independência de replicação implica que é de responsabilidade do otimizador do sistema determinar a quais réplicas é necessário ter acesso físico para satisfazer a qualquer solicitação de um determinado usuário [DATE]. 2.1.4.4 Gerenciamento de transações distribuídas Como sabemos, há dois aspectos principais do gerenciamento de transações, o controle de recuperação e o controle de concorrência, cada um deles exigindo um extenso tratamento no ambiente distribuído. Para explicar, é preciso antes introduzir um novo termo, agente. Em um sistema distribuído, uma única transação pode envolver a execução de código de vários sites; em particular, pode envolver atualizações em muitos sites. Dizemos então que cada transação consiste em vários agentes, onde um agente é o processo executado em razão de uma determinada transação em um site específico. E o sistema precisa saber quando dois agentes são ambos parte da mesma transação - por exemplo, dois agentes que fazem parte da mesma transação obviamente não podem estar em conflito. Passando agora especificamente ao controle de recuperação, para garantir que uma determinada transação é atômica (tudo ou nada) no ambiente distribuído, o sistema deve, portanto assegurar que o conjunto de agentes para essa transação tem todo ele um comprometimento ou um ROLLBACK. Quanto ao controle da concorrência: o controle da concorrência na maioria dos sistemas distribuídos se baseia em geral no bloqueio, exatamente como em sistemas não distribuídos. (Vários sistemas mais recentes começaram a implementar controles multiversão; porém, na prática, o bloqueio convencional ainda parece ser a técnica preferida para a maior parte dos sistemas) [DATE]. 2.1.5 Gerenciamento O acesso a diversos itens de dados em um sistema distribuído é normalmente acompanhado de transações que têm de preservar as propriedades. Há dois tipos de transações que devemos considerar. As transações locais, que são aquelas que mantêm acesso e atualizam somente a base de dados local; e as transações globais, que são aquelas que mantêm acesso e atualizam diversas bases de dados locais. Entretanto, no caso das
  • 25 transações globais, essa tarefa é bem mais complicada, já que diversos sites podem participar de sua execução. Uma falha em um desses sites ou uma falha de comunicação entre sites pode resultar em erros de processamento [DATE]. 2.1.5.1 Tipos de falhas no sistema Um sistema distribuído pode sofrer os mesmos tipos de falhas de um sistema centralizado (por exemplo, erros de software, erros de hardware ou erros em disco). Há, entretanto, tipos adicionais de falhas que precisam ser tratadas em um ambiente distribuído. Os tipos de falhas característicos são: • Falha em um site. • Perda de mensagens. • Falha de comunicação. • Problemas de particionamento da rede. A perda ou comprometimento das mensagens é sempre uma possibilidade nos sistemas distribuídos. O sistema usa protocolos de controle de transmissão, como TCP/IP, para o tratamento desses erros. Os sites de um sistema podem ser conectados fisicamente de diversas formas [CONNALEM]. Cada configuração apresenta vantagens e desvantagens. As configurações podem ser comparadas umas com as outras, com base nos seguintes critérios: • Custo de instalação. O custo da ligação física entre os sites do sistema. • Custo de comunicação. O custo de tempo e dinheiro para envio de uma mensagem do site A para o B. • Disponibilidade, relativo ao grau de acesso aos dados, a despeito de falhas de ligação entre ou nos sites. Um nó A para o B corresponde a uma comunicação direta entre dois sites. Em uma rede totalmente conectada, cada site está diretamente conectado a todos os outros sites. [CONNALEM].
  • 26 Em uma rede parcialmente conectada, há as ligações diretas entre alguns - mas não entre todos - os pares de sites. Então, o custo de instalação dessas configurações é menor que o das redes totalmente conectadas. Entretanto, se dois sites A e B não estão diretamente conectados, as mensagens entre eles precisam ser roteadas por uma seqüência de ligações. Essa necessidade resulta no crescimento dos custos de comunicação. Figura 2.1.5.1 - Topologia de redes de computadores [CONNALEM] Se uma ligação falha, as mensagens que poderiam ser transmitidas por meio dela deverão ser roteadas novamente. Em alguns casos, é possível encontrar outra rota por meio da rede, assim as mensagens poderão alcançar seus destinos. Em outros casos uma falha pode ocorrer onde não haja qualquer ligação entre o par de sites. Note que, sob essa definição, um subsistema pode ser considerado um único nó [CONNALEM]. Os diferentes tipos de redes parcialmente conectados, mostrados na Figura 2.1.5.1, têm características diferentes em relação aos tipos de falhas, instalações e custos de comunicação. 2.1.5.2 Robustez Para um sistema distribuído ser robusto ele precisa detectar falhas, reconfigurar o sistema para que ele possa continuar funcionando e recuperar a situação original durante o retomo de uma ligação ou de um processador.
  • 27 As falhas diferentes são tratadas de modos diferentes. Perda de mensagens são retransmitidas. Retransmissão repetida de uma mensagem, sem mensagem de reconhecimento é normalmente sintoma de perda de comunicação. Em geral, a rede tenta encontrar rotas alternativas para uma mensagem. Falhas nessas tentativas sugerem particionamento da rede. Entretanto, geralmente não é possível ter certeza se houve falha na comunicação entre sites ou se houve particionamento da rede. O sistema detecta a falha, mas não consegue identificar o tipo. Por exemplo, suponha que o site S1 não consiga se comunicar com o site S2. Pode ser que S2 esteja com problemas. Entretanto, pode ser que a ligação entre S1 e S2 não esteja funcionando. Suponha que o site S1 tenha identificado uma falha. Ele iniciará um procedimento para reconfiguração do sistema e, então, prosseguirá no modo de operação normal [SILBERSCHATZ]. • Se há dados replicados no site que não estão funcionando, o catálogo deverá ser atualizado para que as consultas não solicitem acesso à cópia desse site. • Se no site com problemas houver transações ativas no momento da falha, essas transações deverão ser abortadas. É preferível abortar essas transações rapidamente, já que elas poderão manter bloqueios em dados em sites ainda ativos. • Se o site que não está funcionando é um servidor de algum subsistema deverá ser feito uma eleição para determinar o novo servidor. Já que, em geral, não é possível distinguir entre falhas de rede e falhas nos sites, qualquer esquema de reconfiguração precisa ser projetado de modo a trabalhar corretamente caso haja o particionamento da rede. Em particular, a seguinte situação precisa ser evitada: • Dois ou mais servidores centrais são eleitos em partições distintas • Mais de uma partição atualiza e replica itens de dados. A reintegração de um site ou da comunicação entre pares dentro de um sistema também exige cuidados. Quando um site volta a integrar a rede, é preciso que um procedimento seja executado para atualização das tabelas do sistema, de modo a refletir as alterações sofridas enquanto ele esteve fora da rede. Se o site possui réplicas de itens de dados, é preciso que ele obtenha os valores atualizados desses itens e que se possa garantir que ele passe a receber todas as atualizações futuras [SILBERSCHATZ]. A reintegração de um site é mais complicada do que
  • 28 parece à primeira vista, já que os dados podem sofrer atualizações durante a reintegração do site em questão. Uma solução simples para esse problema seria a de manter o sistema temporariamente sem alterações enquanto o site é reintegrado. Na maioria das aplicações, entretanto, tal interrupção seria inaceitável. Quando a comunicação entre sites é restaurada, pode-se estar juntando partições da rede. Dado que o particionamento da rede limita os tipos de operações possíveis em um ou todos os sites [DATE]. 2.2 Aplicações web As aplicações web evoluíram de sites ou sistemas web. Os primeiros sites web formavam um sistema de hipermídia distribuído que permitia aos pesquisadores acessos a documentos e informações publicadas por outros pesquisadores da mesma área, diretamente de seus computadores [CONNALEM]. Os documentos eram visualizados e acessados através de um software denominado navegador (browser). Com um navegador, o usuário pode solicitar documentos de outros computadores na rede e apresentá-los na tela. Para visualizar um documento, o usuário deve iniciar o navegador e digitar o nome do computador host (hospedeiro) onde ele pode ser encontrado. O navegador envia uma solicitação do documento para o computador host. A solicitação é tratada por um software de aplicação denominada servidor web, a partir daí a resposta é enviada para o usuário que solicitou. Esta breve introdução visa mostrar de forma resumida os principais conceitos de aplicações web. 2.2.1 Conceitos e visão geral Uma aplicação web é desenvolvida e estendida a partir de um sistema web para adicionar funcionalidade de negócio. No seu termo mais simples, uma aplicação web é um sistema que permite a seus usuários executar as regras de negócio do sistema a partir de um navegador web. • Protocolo http: os navegadores e servidores web usam um protocolo conhecido como http (HyperText Transfer Protocol) que especifica como um navegador deve formatar e enviar uma solicitação para um servidor web. Esse protocolo é interpretado tanto pelo navegador (cliente) quanto pelo servidor, que devolve a resposta da solicitação [CONNALEM]. • Identificação do documento: o identificador completo para referência e obtenção do documento é o URL. Ele identifica o protocolo (http), o nome da máquina do host, o número de
  • 29 porta opcional e o nome/local do documento. Um URL pode ser usado para solicitar muitos tipos de objetos com diferentes protocolos. Alem do http, os protocolos comuns da internet incluem news, FTP, file entre outros. Cada protocolo é especifico para o tipo de informação ou recurso que ele apresenta [CONNALEM]. • Nomes de domínio: um nome de domínio é simplesmente um nome no formato texto usado para procurar um endereço de internet no formato numérico. O sistema de endereçamento da internet em uso hoje é o IP. Quando um cliente solicita um URL, a solicitação deve ser feita diretamente ao computador host. Isso significa que o computador host identificado no URL deve ser resolvido em um endereço IP numérico. Esse processo é feito com um servidor de nomes de domínio o DNS. Um DNS é um computador da rede que o cliente tem acesso e que está em um endereço IP conhecido [CONNALEM]. Um domínio é exclusivo, ou seja, só existe um registro pra ele, por exemplo, não existe um outro domínio como www.uol.com.br, pois o endereço IP desse já existe na tabela de DNS do servidor. • Tolerância a Falha: a meta de um design de sistemas web é que eles sejam robustos e tolerantes a falhas, esse desejo por um alto grau de tolerância a falha induziu em parte a decisão de usar um protocolo sem conexão, como o http. O http é executado sobre o TCP, mas poderá ser executado sobre qualquer serviço orientado para conexão. O TCP, normalmente combinado com o IP, é uma implementação de camadas no modelo OSI para comunicação de rede. O https (http with SSL) é relativo ao http, mas usa criptografia para ajudar na segurança da comunicação. O https é usado na internet para tratar dados confidenciais como informações pessoais e financeiras. [CONNALEM] • Html: os navegadores, além de estabelecer conexões com a rede, precisam apresentar o documento em uma tela, porém o TCP e o http não lidam com isso, portanto a apresentação do conteúdo é gerenciada pelo navegador, que é onde a HTML entra. A HTML é usada para expressar o conteúdo e a formatação visual de uma página. Um ponto importante a ser observado é que a HTML é uma linguagem que especifica como os documentos devem ser exibidos em uma tela de computador [CONNALEM]. Como seria a estrutura da HTML? Ela é definida por tags que pode ser usado para informar ao navegador como apresentar algo ou definir um link para outra página web. Todas as tags são envolvidas por sinais de maior e menor (< e >), normalmente elas são usadas em pares, por exemplo: <b>Teste</b> essa tags faz com que o texto “Teste” fique em negrito [CONNALEM].
  • 30 • Aplicações Web: As aplicações web usam as tecnologias de ativação para tornar seu conteúdo dinâmico e para permitir que os usuários do sistema afetem a regra do negócio no servidor. A diferença entre sites Web e aplicações Web é sutil e conta com a habilidade de um usuário para afetar o estado da regra no negócio no servidor. Portanto se no servidor não houver nenhuma regra de negócio, o sistema não deverá ser visto como uma aplicação web. Para aqueles sistemas nos quais o servidor Web - ou um servidor de aplicação que usa um servidor web para entrada do usuário - permite que uma regra do negócio seja afetada via navegador web, o sistema é considerado uma aplicação web. Em quase todas as aplicações web mais simples, o usuário precisa fornecer mais do que apenas informações de solicitação de navegação; normalmente, o usuário de uma aplicação Web insere uma gama variada de dados: texto simples, seleções de caixas de seleção ou, até mesmo, informações binárias ou de arquivos [CONNALEM]. Figura 2.2.1 - Modelo simples de resposta e requisição entre cliente/servidor [CONNALEM]. 2.2.2 Arquitetura Arquiteturas reais são criadas a partir de um ideal por parte do projetista. Elas sempre parecem se desenvolver de algo diferente ou são reunidas de mecanismos e padrões bem conhecidos. Quase todos os mecanismos e padrões arquitetônicos que podem ser aplicados a camadas do servidor de um sistema distribuído padrão também podem ser aplicados às arquiteturas de aplicações Web. A seguir, alguns padrões estruturais comuns que estão particularmente adaptados às arquiteturas de aplicações Web:
  • 31 • Fechada: A informação dinâmica em qualquer página Web dada pode ter que ser construída de uma coleção de objetos do negócio e controladores. As classes do padrão fachada unem páginas Web dinâmicas. Cada página Web possui uma classe do padrão fachada especificamente projetada que age para consolidar toda a organização do objeto do negócio e fornecer uma interface clara e de uso fácil para o desenvolvedor do script da página Web usar. • Composição de página: Cada página Web conceitual no sistema é reunida em tempo de execução a partir de um conjunto de fragmentos de páginas menores independentes, que são freqüentemente reutilizados através de páginas no sistema. Por exemplo, muitas aplicações de comércio eletrônico na Internet fornecem um modo rápido para digitar critérios de pesquisa de produtos em toda página Web conceitual. Esse padrão é uma maneira para fornecer a funcionalidade de quadros HTML sem usar os conjuntos de quadros. • Página modelada: Esse padrão define um modelo de uma página que todas as páginas Web enviadas analisam em seus caminhos para o cliente. Semelhante ao padrão composição de página, o padrão página modelada fornece estrutura adicional com modelos e telas formalmente definidos (páginas conceituais). O Java Pet Store fornece um exemplo de um uso desse padrão. É claro que, muitos outros padrões e mecanismos são comumente usados e associados a arquiteturas de aplicações Web. Os três padrões mais comuns da camada de apresentação são o cliente Web magro, o cliente Web gordo e a produção Web [CONNALEM]. • O cliente Web magro é usado principalmente para as aplicações baseadas na Internet, onde há pouco controle da configuração do cliente. O cliente requer apenas um navegador Web que dê suporte a formulários padrão. Toda a lógica do negócio é executada no servidor. • O cliente Web gordo padrão é usado onde uma quantidade significativa arquitetonicamente da lógica do negócio é executada na máquina do cliente. Normalmente, o cliente usa HTML, applets java ou controles ActiveX dinâmicos para executar a lógica do negócio. A comunicação com o servidor é feita ainda através do protocolo HTTP.
  • 32 • O padrão de produção Web é usado quando o navegador Web age principalmente como um dispositivo de produção e de contêiner para um sistema de objetos distribuídos. Além do protocolo HTTP para a comunicação do cliente e do servidor, outros protocolos, podem ser usados para dar suporte a um sistema de objetos distribuídos. É concebível aplicar vários padrões a qualquer arquitetura de sistema especifico. Por exemplo, um sistema de comércio eletrônico baseado na Internet pode usar o padrão de cliente Web magro para os casos de uso de vendas a seus consumidores e usar o cliente Web gordo ou o padrão de produção Web para os casos de uso de manutenção BackOffice. Isso é possível porque há um grau de controle da configuração do cliente quando você possui o cliente; torna-se mais complicado, no entanto, quando está solicitando negócios de usuários da Internet de todo o mundo. As aplicações Web mais realistas possuem a camada do meio adicional - o negócio - e a camada de dados. Arquitetonicamente, essas camadas back-end estão essencialmente inalteradas do modo que aparecem no sistema distribuído mais geral. É onde também a maioria dos componentes de processamento da lógica do negócio do sistema reside e a maioria do trabalho de alteração do estado do negócio acontece. A camada de lógica do negócio de aplicações Web é onde a maioria dos objetos do negócio faz seus trabalhos. Essa camada normalmente é uma camada transacional, onde os objetos podem executar alterações triviais no estado permanente. As duas implementações / especificações mais populares são o MTS e o EJB. As duas são essencialmente contêineres que gerenciam os ciclos de vida dos objetos transacionais e fornecem maneiras fáceis para executar transações de banco de dados. Esses dois contêineres dependem intensamente da camada de dados para fornecer as APIs básicas para dar suporte as transações [CONNALEM]. Os contêineres permitem que os objetos do negócio executem a lógica do negócio em um ambiente de transação segura, mesmo quando vários bancos de dados heterogêneos são usados. 2.2.3 Segurança Em uma aplicação para a Internet uma grande preocupação é com a segurança. Mesmo que a aplicação seja para uma intranet, protegida por um firewall da empresa, a segurança continuará sendo uma preocupação. Um sistema seguro é uma aplicação que funciona
  • 33 adequadamente e que faz apenas o que se propõe a fazer, sem comprometer a integridade dos nossos dados para aqueles que não estão autorizados a obter essas informações. Se nossos sistemas só fizessem o que se propõem a fazer, a segurança não seria um problema. Pessoas sem escrúpulos mesmo com acesso limitado ao seu sistema aproveitarão qualquer falha do sistema para obter acesso a informações potencialmente valiosas, como perfis de cliente e números de cartão de crédito, ou simplesmente derrubar o sistema para testar sua perícia e orgulho pessoal. A ameaça é muito real e com as aplicações Web assumindo papéis cada vez mais importantes nas empresas, a necessidade de entender e administrar os riscos de segurança se torna ainda mais crítica [CONNALEM]. A FAQ (Perguntas Mais Freqüentes) do grupo de notícias alt.security resume os problemas de segurança fazendo a seguinte pergunta comum: P: O que torna um sistema inseguro? R: Ligá-lo. O provérbio a seguir diz tudo: “O único sistema realmente seguro é aquele que está desligado e desconectado, guardado em um cofre reforçado com titânio, escondido em uma casamata de concreto e envolto por gás paralisante e por guardas armados muito bem remunerados. Mesmo assim, eu não arriscaria a minha vida por ele” [CONNALEM]. 2.2.3.1 Tipos de riscos de segurança Para entender as áreas de risco da nossa aplicação, precisamos entender primeiro onde nossos sistemas são vulneráveis. A arquitetura de sistemas Web básica, sendo uma variante de uma arquitetura distribuída, tem três elementos arquitetônicos principais: o cliente, o servidor e a rede. Cada um deles é vulnerável a ataques. • Nossos clientes correm os riscos de ataques de softwares que danificam o sistema do cliente ou comprometem os recursos do cliente particular, como informações pessoais e arquivos. • Nossos servidores correm o risco de acesso não-autorizado, o qual pode resultar na captura de informações confidenciais, na execução de programas prejudiciais no servidor ou, ainda, desativar temporariamente as funções do servidor. • Nossas redes podem ser monitoradas e as comunicações de dados entre o cliente e o servidor podem ser interceptadas.
  • 34 2.2.3.2 Risco técnico A natureza dos riscos nos nossos sistemas pode ser classificada em quatro áreas principais: • Sistemas configurados de modo inadequado • Software com bugs • Autenticação pobre ou requisitos de senha insuficientes • Falta de criptografia no tráfego da rede A principal razão para que qualquer parte de um sistema corra risco de segurança é um software configurado inadequadamente ou com bugs. Um sistema mal configurado ou um sistema com um bug abre um furo na segurança que pode ser explorado. Podemos citar um exemplo, onde um programa permitia que os usuários do sistema salvassem um arquivo em uma área particularmente importante do sistema de arquivos. Os arquivos nesse diretório eram executados automaticamente com privilégios de nível raiz e considerados partes do sistema operacional. Uma vez lá, o arquivo do hacker estava executando, dando ao intruso uma conta secreta e não monitorada no sistema, a qual ele usou para examinar o sistema anonimamente e obter informações importantes além de ser um ponto de partida para conquistar o próximo sistema [CONNALEM]. Em uma aplicação Web, a autenticação correta dos usuários de um sistema pode ocorrer em vários níveis. Em um nível, o próprio computador cliente pode ser autenticado para ser usado com o sistema. Uma aplicação Web pode ser criada para permitir apenas clientes com determinados endereços IP [CONNALEM]. A forma de autenticação mais comum é uma senha simples. Os usuários de um sistema recebem uma identificação (ID) de logon - uma identificação de usuário conhecida publicamente - e uma ID secreta (senha). Para obter acesso ao sistema, o usuário deve usar as duas. Após o primeiro acesso ao sistema, o usuário é normalmente solicitado a alterar a senha para algo que apenas o usuário conheça. As senhas são, em geral, a primeira linha de defesa de um sistema e ajudam a impedir ataques interativos no sistema. Esse tipo de autenticação tem muitos problemas. Do ponto de vista estritamente técnico, as ID de usuário e senha informam ao sistema apenas que um usuário que conhece aquela
  • 35 combinação está solicitando acesso ao sistema, não necessariamente que ela é a pessoa que supostamente tem esse conhecimento. O que um sistema está, na verdade, autenticando é um usuário com conhecimento de uma combinação de ID e senha de um usuário válido, não a identidade real da pessoa que está solicitando acesso ao sistema. Em muitas situações, o conhecimento de uma conta de logon específica não permitirá que um cracker acesse imediatamente todos os recursos do sistema. Normalmente, as contas de usuário são restritas para permitir acesso a apenas aqueles recursos necessários à execução das responsabilidades do usuário. O que mais interessa a um cracker são as senhas de administração, de raiz ou do administrador. Com esse nível de acesso, os recursos de todo o sistema estão abertos para exploração [CONNALEM]. Senhas simples podem ser quebradas com programas que adivinham senhas repetidamente a partir de um dicionário de palavras e combinações de números ou outros símbolos comuns. As melhores senhas são aquelas criadas a partir de uma base puramente pessoal e aleatória. Entretanto, o truque prático na utilização de senhas é usar senhas que possam ser lembradas. “Relatou-se uma vez em um ambiente no qual as senhas foram distribuídas pelo administrador de rede da empresa, que usou um software especial que ele acreditava produzir senhas aleatórias e muito difícil de adivinhar. Para aumentar a segurança - no seu modo de pensar - ele as alterava a cada três meses. Ele atribuiu senhas aos usuários do sistema, esperando que as memorizássemos rapidamente e destruíssemos as cópias escritas. As senhas eram codificadas e difíceis de lembrar. O resultado foi que metade dos usuários acabou escrevendo suas senhas em papéis adesivos e colando-as nos seus monitores” [CONNALEM]. O truque para o uso de senhas não é considerá-las a ferramenta de segurança final, mas simplesmente a primeira linha de defesa. Para serem eficientes, elas precisam ser tão aleatórias quanto a capacidade do usuário de se lembrar delas. A categoria geral final de risco de segurança é a falta de criptografia. Nesse tipo de risco, os invasores monitoram o tráfego da rede, coletando os diálogos de comunicação entre clientes e servidores. O protocolo de rede mais comum na Internet hoje é o TCP/IP. Quando projetado, a segurança não foi à preocupação principal; a internet, sendo a maior rede pública do mundo, não impede que usuários anônimos monitorem o tráfego geral que passa por seus sistemas. Os crackers podem usar “farejadores” para monitorar e analisar o tráfego da rede para um servidor ou cliente específico e, possivelmente, reconstruir informações importantes e úteis na obtenção de acesso adicional ao sistema ou simplesmente selecionar alguns números de cartão de crédito.
  • 36 Uma utilização importante da criptografia de rede está nas redes privativas virtuais (VPNs). Em uma VPN, uma rede pública, tal como a Internet, é usada como uma rede privativa. Todos os membros da rede privativa usam a criptografia para se comunicar entre si. As VPNs podem ter a vantagem distinta de permitir que pequenas empresas proporcionem acesso privativo de rede através da Internet pública a pessoas localizadas remotamente em vez de acessar por meio das linhas dedicadas que são muito mais caras. Algumas aplicações Web podem usar VPNs como parte de suas medidas de segurança. As VPNs podem ser implementadas com uma combinação de software e hardware ou apenas com software [CONNALEM]. Figura 2.2.3.2 - Redes privativas virtuais 2.2.3.3 Estratégias de segurança Em geral, tornamos nossos sistemas mais seguros: • Limitando o acesso ao sistema por meio de firewall, senhas e assim por diante. • Compreendendo os requisitos do sistema e de segurança • Mantendo atualizados sobre as mais recentes correções e alertas de segurança É claro que a maneira mais fácil de limitar o acesso a um sistema é desconectá-lo de qualquer rede pública, como a Internet, e proteger fisicamente todos os pontos nos quais a rede encontra o mundo real. Esse tipo de medida de segurança pode ser bom e apropriado para sistemas militares, mas para sistemas de comércio eletrônico na internet, não ajudaria muito nos negócios.
  • 37 Outra opção para limitar o acesso a aplicações baseadas em intranet é estabelecer um firewall entre a intranet e a Internet. A maioria das empresas mantém um firewall para isolar seus sistemas internos do mundo externo. O nome firewall tem origem na parede de aço existente entre o compartimento do motorista de um automóvel e o compartimento do motor. A idéia é que o fogo do motor tenha dificuldade de se espalhar para o restante do automóvel. Um firewall de rede é projetado para impedir que o tráfego indesejado entre e saia de uma rede interna. Normalmente, os fírewalls usam um servidor proxy para monitorar o tráfego de entrada e saída. O tráfego pode ser limitado de várias maneiras: por tipo - HTTP, FTP ou correio eletrônico - ou por endereço - www.umsite.com.br e assim por diante - assim como por outras [CONNALEM]. Figura 2.2.3.3 - Posição do firewall 2.2.3.4 Criptografia Os certificados e a assinatura de código contam com a criptografia. Essa mesma tecnologia pode ser usada para ajudar a proteger o tráfego de rede subjacente em uma aplicação Web. Como muitas aplicações Web usam a Internet pública para conectar clientes e servidores, os crackers podem monitorar e decodificar o tráfego da rede e, com algum esforço, determinar padrões de acesso e informações confidenciais, como senhas e números de cartões de crédito. Para tornar o tráfego de rede entre o cliente e o servidor mais seguro, ele pode ser criptografado. O impulso do comércio eletrônico tem exigido a emergência de vários esquemas para proteger informações confidenciais que transitam pela rede. Os dois esquemas mais promissores são o SSL e o SET.
  • 38 O SSL foi apresentado pela Netscape Communications Corporation e é um esquema de criptografia de nível baixo usado para criptografar protocolos de nível mais alto, como o HTTP e o FTP. O SSL exige que o servidor apresente um CA para verificar sua identidade e pode, opcionalmente, verificar também um certificado de cliente. O SSL está implementado na maioria dos navegadores de hoje e quase todas as aplicações comerciais o utilizam proporcionando uma medida de segurança para seus usuários [CONNALEM]. O SET é um conjunto de padrões e protocolos, para realizar transações financeira seguras, como as realizadas com cartão de crédito na Internet. Oferece um canal de comunicação seguro entre todos os envolvidos na transação. Garante autenticidade e privacidade entre as partes. 2.3 Banco de dados distribuídos e aplicações web Nos dias de hoje, praticamente todos os sites que permitem consulta a seus produtos, serviços ou qualquer outro tipo de informação trabalham com um Sistema de Banco de Dados, ou seja, os dados ficam armazenados em um banco de dados. Um exemplo desta característica é mostrado no exemplo a seguir: - Uma pessoa entra no site de uma determinada loja com a intenção de comprar algo. - A primeira coisa que essa pessoa vai verificar é se o produto possui estoque, uma coisa que ela não sabe é que essa loja pode ter N filiais, cada qual com um estoque diferente porém com uma mesma estrutura de dados. - O visitante ao consultar o(s) produto(s) não sabe se o mesmo se encontra no estoque da filial 1, 2, 3, 4 ou N-ésima, o que interessa para ele é que a loja possui o produto que ele escolheu. E a partir daí, ele transcorre com o devido processo para a finalização do pedido até a entrega do mesmo no endereço indicado. Neste trabalho estamos tratando de bancos de dados distribuídos, então surge a pergunta: qual a relação entre bancos de dados distribuídos e aplicações Web? Para responder essa pergunta, tomemos como base o visitante e o site da loja. O usuário, ao digitar www.aloja.com.br, não sabe qual das filiais da loja está acessando, ou mesmo se a loja possui filial. Porém, ao efetuar uma consulta de um produto, o usuário espera que o mesmo possua estoque, porém por trás de toda essa aplicação web pode existir, de acordo com a quantidade de filiais, os N bancos de dados em lugares diferentes, o que corresponde as filiais. A resposta se resume no seguinte: ao efetuar uma consulta, se aquele determinado produto não
  • 39 estiver no estoque da filial 1, ou filial 2, ou filial 3 ou filial 4 ou filial N-ésima, daí sim podemos afirmar que "o produto não pode ser comprado pois não tem em estoque". Agora, caso ele ache em alguma dessas ou mais filiais, o retorno esperado é que o produto está no estoque e portanto pode ser adquirido a qualquer momento. Portanto, um banco de dados distribuído pode facilitar a execução de uma aplicação web, pois esta não precisa se preocupar em qual banco deve fazer a pesquisa; o próprio BD-D se encarrega de distribuir a consulta e recuperar o dado requisitado 2.3.1 Aplicações distribuídas Uma aplicação é dita distribuída quando é executada em um ambiente distribuído, independente dela estar ou não acessando banco de dados distribuídos. Para exemplificar esta definição veja as ilustrações abaixo: Requisição HTTP Servidor Browser Web Resposta à requisição HTTP Figura 2.3.1.1 - Representação de uma aplicação distribuída sem acesso à banco de dados A ilustração abaixo trata de o acesso de uma aplicação Web a um SGBD-D. B ro w s e r W e b S e r v id o r W e b S e r v id o r B D Figura 2.3.1.2 - Representação de uma aplicação distribuída acessando um determinado banco de dados não-distribuído Para que fique mais claro qual a característica de um sistema de banco de dados distribuído, veja abaixo a figura que representa tal intenção.
  • 40 Figura 2.3.1.3 - Exemplo de acesso a uma aplicação web com vários bancos interligados A figura 2.3.1.4 ilustra justamente o contrário da figura 2.3.1.3, ou seja, para a arquitetura da figura 2.3.1.3 a aplicação web faz uma requisição ao BD e o próprio BD se encarrega de solucionar esta requisição, isto é, dado uma pesquisa não encontrada neste banco o mesmo assume a responsabilidade de realizar essa mesma pesquisa em outro banco de dados. Enquanto isso, na arquitetura da figura 2.3.1.4 a aplicação web faz várias requisições em vários bancos de dados distintos – a aplicação procura em um BD, depois em outro, e assim sucessivamente até encontrar os dados que deseja. Com isso conclui-se que em relação à performance e robustez o BD-Distribuido é mais vantajoso em comparação ao centralizado, agora em relação a custo um BD-Distribuido é muito superior a um centralizado, portanto a implantação de um banco de dados distribuído é muito cara, porém extremamente eficiente em relação ao centralizado.
  • 41 Figura 2.3.1.4 - Aplicação web acessando BD centralizado É possível descrever a situação ilustrada na figura 2.3.1.3 nas seguintes etapas: 1) O usuário acessa a aplicação web e executa uma consulta 2) Ao efetuar a consulta no banco SGBD-D B, o resultado não foi bem sucedido. 3) Devido as suas configurações de SGBD-D, a mesma consulta é executada no SGBD-D A, sem que o usuário saiba, e se ainda o resultado não foi bem sucedido a mesma consulta é executada no SGBD-D C 4) Caso ainda não retorne nada o usuário terá como resposta que o produto pesquisado não tem em estoque, por exemplo. 5) Conclusão: o usuário sem saber consultou o produto em todas as filiais da loja, não sendo bem sucedida porque o produto já estava esgotado em todas as lojas do grupo, mas caso estive na loja A (SGBD-D A), o usuário de forma alguma saberia que o produto estaria naquela ou em uma outra filial.
  • 42 3 ESTUDO DE CASO Para que seja possível exemplificar de uma maneira mais clara o funcionamento de um banco de dados distribuído, estaremos citando o caso de uma rede de locadoras de automóveis denominada Localiza Rent-Car. Esta locadora, localizada em Belo Horizonte, possui um total de 320 agências espalhadas pelo Brasil e pelo mundo, contando com uma frota de 30.000 automóveis de diversos tipos e marcas. 3.1 Justificativas e necessidades O grande objetivo da implementação de um estudo de caso é validar e demonstrar as idéias desenvolvidas em um projeto. Um estudo de caso bem feito é de grande importância para qualquer projeto, pois é ele que permite avaliar os resultados obtidos a partir da teoria do trabalho desenvolvido, para com isso se poder tirar conclusões. A Localiza Rent-Car foi escolhida como estudo de caso pelas razões enumeradas abaixo: - Cada filial deve armazenar os dados de seus veículos localmente, mas deve poder acessar os dados das demais filiais para atender pedidos específicos de clientes. - Os clientes devem poder fazer reservas on-line acessando somente um site (da empresa), sem precisar verificar o site de cada filial. - Não há necessidade do cliente saber em qual filial o carro está sendo reservado, importando apenas que o cliente vai retirar e entregar o automóvel no local por ele indicado. - Redução de custos/facilidade de controle, isto é, com as 320 agencias espalhadas pelo Brasil e pelo mundo o cliente consegue com muita comodidade locar um carro sem sair de casa. - Reduz o risco da utilização constante de dinheiro, ou seja, o cliente efetua o pagamento no momento da reserva. 3.2 Especificação do problema Quando se fala em locadora de veículos logo imaginamos uma empresa situada em uma cidade onde atende somente a população local, com isso certamente um único sistema de controle
  • 43 de frotas e reservas juntamente com um banco de dados centralizado já seria suficiente para tal gerenciamento. Mas o que se pode notar é que a empresa Localiza não é uma simples empresa na qual possui uma única agência, conforme visto a Localiza possui várias agências espalhadas pelo Brasil e pelo mundo, sendo assim estaremos demonstrando como seria extremamente vantajosa e importante a aplicação de um SGBD distribuído, levando em consideração a estrutura geográfica da empresa. Para que possamos estudar este caso tomamos como prioridade algumas regras de negócios, são elas: - A entrega e a retirada do carro são combinadas previamente no momento da reserva no site. - Cada locadora possui igualdades com relação a sua estrutura física, por exemplo, comercial, manutenção e gerência. Com isso cada uma possui uma meta a ser atingida seja ela em satisfação e financeira. 3.3 Modelo de dados Os dados de todas as locadoras estarão definidos de uma única forma, ou seja, as tabelas serão iguais com relação a sua estrutura, alterando somente o seu conteúdo. Por exemplo, em uma locadora pode não haver um determinado veículo enquanto na outra se encontra disponível com isso não perdendo a venda/aluguel. Por fim, como dito, as tabelas estarão organizadas igualmente com relação aos seus campos, tamanho, características e validações. A estrutura do banco e o relacionamento das tabelas estarão organizados da seguinte forma:
  • 44 Figura 3.3.1 - Estrutura física do sistema de banco de dados distribuídos
  • 45 Figura 3.3.2 - Modelo Relacional do estudo de caso 3.4 Testes Os testes executados serão os seguintes: Performance do banco e consultas: Será avaliado consultas e cadastros em execução simultânea para que seja possível avaliar a capacidade do banco. Segurança: Será avaliada a segurança de uma forma ampla, ou seja, integridade das informações ali contidas, bem como o sigilo dos dados. Comunicação entre os bancos: Esse é o ponto fundamental dos testes, é através dele que poderemos avaliar o funcionamento real de um SGBD-D quanto à troca de informações entre os mesmos.
  • 46 4 PROTÓTIPO Conforme mencionado nos capítulos anteriores, o protótipo implementa o estudo de caso escolhido para os testes de um sistema de banco de dados distribuídos: o caso da Localiza, uma empresa que trabalha na área de aluguel de veículos desde 1973. 4.1 Projeto O projeto de estudo de caso será baseado na área em que o cliente tem a possibilidade de efetuar reservas on-line. Veja ilustração referente ao momento, da reserva de um determinado veículo: Figura 4.1 - Tela principal onde o usuário define a retirada e a devolução 4.1.1 Arquitetura
  • 47 A arquitetura do sistema, mostrada na figura 4.1.1, está distribuída entre as locadoras da empresa da seguinte forma: - Localiza - A (sede do grupo - escritório central). Irá conter um banco de dados com as devidas tabelas, conforme citado na figura 3.3.1. Conseqüentemente este banco de dados estará configurado para se tornar um Sistema de Banco de Dados Distribuídos. - Localiza - B, Localiza - C e Localiza - D (possui uma unidade de negócio). Irá conter um banco de dados idêntico, em termos de estrutura, ao descrito no item anterior, contendo diferenças somente no conteúdo das tabelas. Figura 4.1.1 - Representação da arquitetura do protótipo do sistema 4.1.2 Projeto do banco de dados Esta seção mostra a estrutura do banco de dados distribuído definido para a solução, incluindo a criação das tabelas e seus devidos campos e também a configuração necessária no SGBD-D.
  • 48 Para que um sistema de banco de dados se torne distribuído é necessário verificar se o SGBD tem suporte a distribuição. Uma vez verificado o próximo passo é configurá-lo, para isso destacam-se os principais passos de configuração de um SGBD-D: - Primeiramente determina quem será o DISTRIBUIDOR, ou seja, o servidor no qual será responsável em distribuir os dados. - Em seguida é necessário definir o PUBLICADOR, ou seja, as bases de dados no qual cria-se um “tipo de compartilhamento” entre eles. - E por último cria-se os ASSINANTES, ou seja, esses serão adicionados nos publicadores de acordo com cada banco de dados. Um assinante do tipo PUSH é definido pela publicadora, ou seja, quem publicou os dados define quem vai recebê-los. Já o assinante do tipo PULL, ele escolhe que publicações assinar. Veja figura abaixo demonstrando um SGBD-D: Figura 4.1.2 - SGBD-D configurado 4.2 Implementação
  • 49 Esta seção detalha as principais características do banco de dados e a linguagem de programação usada no desenvolvimento do protótipo. 4.2.1 Sistema gerenciador de banco de dados distribuído O banco de dados escolhido foi o SQL Server 2000, da Microsoft. Para um banco de dados se tornar distribuído o mesmo sofre modificações como replicação e fragmentação, com isso poderemos mostrar a idéia de um SGBD-D [GUNDERLOY]. Principais características do SQL Server 2000: • Ferramentas gráficas para administração e desenvolvimento (Query Analyzer e Enterprise Manager) Replicação de Dados • Ferramenta para aferição de performance (Profiler) , que permite ao administrador capturar, armazenar e analizar eventos que responsáveis por gargalos no servidor • Views distribuídas (Distributed Partitioned Views) , que podem ser utilizadas para balanceamento e distribuição de carga entre servidores • Failover Clustering (fornece mecanismos para criar cópias on-line de sua base de dados à partir de um servidor virtual, responsável pelo manejo das requisições) As técnicas abaixo aplicadas são necessárias pois só assim o SGBD SQL Server 2000 se tornará distribuído. Antes de iniciar sobre as principais considerações, devemos levar em conta que as bases e as tabelas já estão devidamente criadas no SGBD [GUNDERLOY]. Veja as etapas: a) Definir qual servidor será o Distribuidor
  • 50 Tela inicial da definição do distribuidor Nesta opção escolhe-se quais bases serão publicadas b) Uma vez definido o distribuidor, nota-se que as bases de dados ficam com a seguinte aparência: Isso se dá ao fato de agora poder publicar todas essas bases, no qual é o próximo passo.
  • 51 c) Para que os bancos se tornem visíveis entre si, a próxima etapa é criar as publicações. Esta é a tela inicial na qual define-se qual base será publicado. Os passos a seguir são iguais para quantas bases de dados estiverem no Distribuidor. Nesta etapa define-se o tipo de publicação dos dados
  • 52 Nesta etapa há a possibilidade de definir quais tabelas/artigos farão parte da publicação d) A próxima e última etapa trata dos assinantes, ou seja, quais tabelas de quais bases poderão assinar as publicações das outras bases de dados. Para que tudo seja feito com êxito é extremamente importante seguir todas as etapas anteriores. Define-se qual banco será assinado por uma determinada publicação
  • 53 Tela na qual define-se em qual distribuidor serão assinados quais artigos/tabelas. Nesta opção escolhe-se qual publicação irá receber um determinado assinante/tabela
  • 54 Tela de conclusão da definição do assinante na publicação Para concluir devemos considerar alguns dados importantes para o desenvolvimento deste estudo de caso: - Existe 1 distribuidor local. - 4 bases de dados, na qual todas serão assinantes e publicadora. - Apenas uma, na qual conterá os dados da matriz, será a publicadora de todas as outras assinantes, ou seja, ela será a responsável por publicar os dados das outras filiais. 4.2.2 Linguagem de programação web Java Server Pages (JSP) (www.sun.com) é uma tecnologia de web-scripting para desenvolvimento de aplicações WEB semelhante ao Microsoft Active Server Pages (ASP) (www.microsoft.com), porém tem a vantagem da portabilidade de plataforma da linguagem Java. Operando na camada de apresentação, as páginas JSP utilizam a tecnologia Java do lado do servidor (servlets) para a criação de conteúdo dinâmico aliado com as tags HTML para manter o conteúdo estático [ANSELMO]. Com a tecnologia JSP é possível, entre outras coisas, produzir aplicações que permitam o acesso a banco de dados, o acesso a arquivos-texto, a captação de informações a partir de
  • 55 formulários, a captação de informações sobre o visitante e sobre o servidor e o uso de variáveis e loops entre outras coisas. O JSP não oferece nada que não possa ser criado com servlets puros. O JSP, entretanto, oferece a vantagem de ser facilmente codificado, facilitando assim a elaboração e manutenção de uma aplicação WEB. Além disso, a tecnologia JSP permite a separação da programação lógica (parte dinâmica) da programação visual (parte estática). Outra característica também é a possibilidade de produzir conteúdos dinâmicos que possam ser reutilizados. Pode-se considerar as principais características do JSP como sendo [ANSELMO]: Separação do conteúdo estático do dinâmico: em JSP, a lógica de geração de conteúdo dinâmico é mantido separada das tags HTML responsáveis pela interface para o usuário. A parte lógica é encapsulada em componentes JavaBeans externos, que são então utilizados pela página JSP através de tags especiais ou scriptlets. Diversos formatos: qualquer formato atual pode ser utilizado numa página JSP, além de HTML. Podem ser utilizadas linguagens XML, DHTML, entre outras. Integração com a API Servlet: JSP pode ser considerado uma abstração de alto nível dos servlets, considerado que as páginas JSP são compiladas para gerarem servlets. Dessa forma, praticamente qualquer coisa feita em servlets pode ser feita em JSP. Utilização de código Java: é possível utilizar os chamados scriplets, que são nada mais que trechos de código Java puro inseridos dentro da página JSP. A arquitetura geral das páginas JSP tem muito em comum com os servlets, tendo em vista que a especificação JSP é definida como uma extensão da API Servlet. Na maioria dos casos, as páginas JSP são submetidas a um processo de tradução e a uma fase de processamento de requisição. A primeira acontece apenas uma vez, a não ser que a página JSP em questão sofra alterações. Caso não ocorram erros de compilação, o resultado desta fase é uma classe que implementa a inteface Servlet. Fase de Compilação de uma página JSP: Quando uma página JSP é requisitada pelo cliente através de um browser, a classe equivalente a esta página é executada pelo servidor. A partir daí será gerada uma página HTML que será enviada de volta ao browser do cliente.
  • 56 Figura 4.2.2 - Estrutura de funcionamento de páginas com a tecnologia JSP [ANSELMO] A) Todo o processo começa quando um cliente faz uma solicitação, neste momento é enviado um request para o WebServer B) O WeServer localiza e envia a ação para a página JSP C) São verificadas mudanças nesta, se for a primeira vez é criado um programa Java Servlet D) O programa Java Servlet é compilado transformado em um bytecode (.class) E) Este .class pode ser auxiliado por pacotes .JAR que carregam Java Beans F) Durante a montagem da página HTML, podem também ocorrer solicitações a banco de dados G) A página HTML é gerada H) As chamadas Tags Personalizadas são transformadas neste momento em Tags comuns para a geração final I) A página final HTML é enviada de volta ao servidor J) É devolvida para o cliente que fez a solicitação A JSP usa linguagem Java como base para sua linguagem de scripts, utilizando todo o potencial desta, sendo por esse motivo que a JSP se apresenta muito mais flexível e muito mais robusta do que as outras linguagens [ANSELMO].
  • 57 5 RESULTADOS O estudo de caso apresentado possibilitou a coleta de resultados através de testes efetuados num mesmo sistema, no qual um utiliza um BD centralizado e o outro um BD-D. Os resultados foram concluídos com base em: - Duas aplicações web foram desenvolvidas conectadas em bases de dados configuradas de forma distinta, ou seja, a primeira aplicação foi desenvolvida com o objetivo de demonstrar a funcionalidade de um banco de dados centralizado; já a segunda utiliza um banco de dados distribuído devidamente preparado e configurado. - As aplicações realizam as mesmas operações de consulta, só que a primeira conecta várias vezes em bancos diferentes até que encontre o resultado da busca; já a aplicação com BDD conecta-se uma única vez ao banco principal retornando assim o resultado da SELECT efetuada. Esse exemplo está melhor identificado no tópico 5.2 no qual se faz comparações entre as duas conexões. - O grande resultado observado é quanto à velocidade de busca das consultas efetuadas pelos clientes. Enquanto uma aplicação com BD-Centralizado demora, dependendo do servidor, em torno de 6 segundos para retornar o resultado da SELECT, a aplicação com BD-Distribuido demora 2,5 segundos. Isso se dá ao fato do mesmo efetuar apenas uma conexão, portanto podemos concluir que podemos ter um ganho de aproximadamente 60%, lembrando que isso dependerá da conexão e do servidor. 5.1 Vantagens A principal vantagem da utilização de um banco de dados distribuído em uma aplicação web é a característica de partilhar e acessar dados de uma maneira confiável e eficiente, além do aumento de velocidade no processamento de consultas e do crescimento incremental, de possuir disponibilidade, confiabilidade e um controle distribuído, além da sua transparência e autonomia. Com relação ao estudo de caso apresentado podemos destacar uma necessidade muita interessante que só foi possível graças a utilização de um gerenciador de banco de dados distribuído, essa necessidade diz respeito ao compartilhamento dos dados entre as filiais, sendo
  • 58 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
  • 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
  • 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
  • 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:
  • 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){
  • 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.
  • 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.
  • 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.
  • 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.
  • 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