SlideShare uma empresa Scribd logo
Um Sistema de Banco de Dados Replicado Gerenciado
através de Applets Distribuídas
André Luis Castro de Freitas1
1
Departamento de Matemática – Fundação Universidade Federal do Rio Grande
(FURG)
Caixa Postal 474 – 96201.900 – Rio Grande – RS – Brazil
dmtalcf@super.furg.br
Abstract. A distributed and replied database it is characterized as a collection
of several similar databases, logically connected through a computers net.
This work has as proposal the definition, administration and implementation
of a distributed and replied database that uses several databases in different
servers. Therefore, the distributed transactions, width concurrency control,
are executed through the same software in the different nodes, characterizing
a distributed database system. The software proposes the use of interfaces
through navigation web browse, applets in the programming language Java,
where the structures customers and the several servers that manipulate the
databases built using the RMI.
Resumo. Uma base de dados distribuída e replicada caracteriza-se como uma
coleção de diversas bases de dados, semelhantes, interligadas logicamente
através de uma rede de computadores. Este trabalho tem como proposta a
definição, gerenciamento e implementação de um banco de dados distribuído
replicado que utilize várias bases de dados relacionais em diferentes
servidores. Portanto, as transações distribuídas, com o controle da
concorrência, são executadas através do mesmo software nos diferentes nós.
O software propõe a utilização de interfaces via navegador web, applets na
linguagem de programação Java e as estruturas clientes e servidores que
manipulam as bases de dados construídas utilizando o serviço RMI.
1. Introdução
Os sistemas de banco de dados têm sido criados de forma independente, sem a
preocupação quanto a possíveis integrações. Assim, cada base de dados pertencente a
um sistema é administrada sob regras locais e autônomas. A evolução tecnológica das
redes de computadores e de banco de dados propõe a modificação na maneira como os
dados são processados [Lima, 1997].
A existência de diferentes SGBDs apresenta-se como natural e inevitável no contexto
das grandes organizações, e cria a necessidade de um outro nível de sistema de gerência
de banco de dados, capaz de prover o acesso a dados já existentes e distribuídos em
redes de computadores [Chung, 1990]. Este acesso deve ser feito sem exigir mudanças
locais nos banco de dados não requerendo reprogramação dos SGBDs envolvidos
[RAM, 1991].
Sistemas que atendem a esses requisitos não possuem uma denominação única, e são
chamados de sistemas de banco de dados federados, de sistemas multidatabase ou,
ainda, de sistemas de banco de dados distribuídos heterogêneos [Breitbar, 1992].
Um sistema de banco de dados distribuído heterogêneo representa a combinação de
diferentes tecnologias de bases de dados com um sistema em questão, ou seja, consiste
de uma coleção de nós cada qual podendo participar na execução de transações que
fazem acesso a dados em um ou diversos nós de maneira transparente [Özsu, 1999].
Atualmente existem alguns bancos de dados distribuídos comerciais que apresentam
características de processamento distribuído. Entre eles pode-se citar o Oracle 9i, o qual
apresenta fragmentação horizontal primária de tabelas e índices. Essa versão demonstra
total transparência na manipulação dos dados. Um segundo exemplo é o SQL Server
2000 cuja redução de fragmentos horizontais ainda é limitada. Por fim o IBM Informix
Dynamic Server que utiliza também fragmentação primária através de um servidor cuja
responsabilidade é estender a distribuição. Mas todos esses bancos de dados são
softwares proprietários e apresentam grande complexidade de desenvolvimento e alto
custo de manutenção. O grande problema destes sistemas é a não conexão a outras
tecnologias de bancos de dados existentes, não permitindo a heterogeneidade.
O objetivo deste trabalho é, portanto, gerenciar e coordenar as transações de um
sistema de banco de dados distribuído e replicado que manipule diferentes bancos em
cada um dos nós envolvidos.
Com o objetivo de atenuar a complexidade de desenvolvimento do sistema proposto
optou-se pela utilização de réplicas, considerando os nós disponíveis, não levando em
consideração a possibilidade de fragmentação. Acredita-se que a utilização de réplicas,
apesar de resultar na duplicação de informações, contribua positivamente com o
paralelismo, quando a exigência maior do sistema for para leituras e com a
disponibilidade das informações, pois o sistema pode continuar o processamento apesar
da identificação de falhas em alguns nós.
Conforme a figura 1, cada nó contém uma cópia do banco de dados (de diferentes
fornecedores) que permanece conectado ao serviço de gerenciamento. O cliente acessa o
serviço e estabelece a conexão com um dos nós, em caso de consultas, ou com todos os
nós, em caso de atualizações.
Fig. 1. Sistema de Banco de Dados Distribuído Replicado / RMI-Java
Considerando a afirmação anterior, verifica-se a necessidade de gerenciar a execução
de transações que fazem acesso aos dados armazenados em um nó local. É importante
ressaltar que cada transação pode ser tanto uma transação local como parte de uma
transação global. Partindo deste pressuposto criou-se um serviço, disponível em cada
nó, implementado a partir da linguagem Java, utilizando o mecanismo RMI – Remote
Method Invocation.
RMI disponibiliza uma família de objetos colaborativos localizados em qualquer
lugar permitindo a comunicação através de protocolos padrão através da rede. O método
permite a comunicação entre máquinas virtuais Java executadas em computadores
distintos [Horstmann, 2001].
Este trabalho está organizado nas seções 2 e 3. A seção 2 define e caracteriza o
modelo e o ambiente da estrutura proposta. Na seção 3 é demonstrada a arquitetura do
sistema, onde são verificados os lados do servidor e do cliente identificando as
estruturas de conexão e controle. Após procede-se a conclusão e trabalhos futuros.
2. Modelo e Ambiente
A proposta para o modelo é a utilização de servidores Web distribuídos. Esta abordagem
espalha a carga de pedidos entre os vários computadores conectados. A conexão do
usuário ao sistema é feita pela execução de uma applet Java cuja cópia está disponível
em cada um dos servidores. Portanto o cliente pode optar em qual nodo fará a execução,
pois cada um dos componentes possui uma réplica do conteúdo a ser oferecido por esse
servidor Web.
A applet Java comunica-se com um serviço disponível localmente o qual fará a
conexão aos outros servidores para acesso ao serviço de banco de dados. Estas conexões
são todas gerenciadas através do mecanismo RMI.
O mecanismo RMI permite o acesso a um objeto em uma máquina diferente o qual é
chamado de objeto remoto. Quando o cliente quer executar um método remoto ele
simplesmente invoca um método normal da linguagem Java que será encapsulado em
um objeto substituto chamado stub.
O stub empacota, como um bloco de bytes, os parâmetros utilizados no método
remoto. O stub, então, envia estas informações para o servidor. No lado do servidor, um
objeto receptor separa os parâmetros, localiza o objeto chamado, invoca o método e, por
fim, envia um pacote composto dos dados de retorno para o cliente. O stub cliente
separa o valor de retorno [Horstmann, 2001].
A conexão local entre o banco de dados e o serviço RMI é feita através da API Java
DataBase Connectivity (JDBC). Utilizando JDBC é possível fazer acesso a um banco de
dados independentemente do verdadeiro mecanismo de banco de dados que está sendo
utilizado para armazenamento das informações [Reese, 2000], promovendo a
heterogeneidade.
O conjunto de classes que implementam as interfaces JDBC para um determinado
mecanismo de banco de dados é chamado driver JDBC. A figura 2, demonstra o modelo
caracterizando, justamente, a existência de uma estrutura RMI para cada nó que
disponibiliza o serviço de acesso ao banco de dados. Cada serviço conecta-se,
localmente, a cada cópia do banco via um driver JDBC.
O cliente, por sua vez, executa uma applet a qual dispõe de um serviço RMI para
acesso a objetos remotos. Conseqüentemente, a applet via RMI faz conexão com o
serviço gerenciador local que se conecta aos os nós para consulta e/ou atualização das
informações. A utilização do serviço local intermediário ocorre devido à limitação de
conexão das applets com outros servidores que não o de onde fora carregada a applet.
Portanto, é executada uma solicitação inicial de conexão RMI applet → serviço local
bem com n (dependendo do número de nodos) conexões RMI serviço local → serviços
local e remotos de banco de dados.
Fig. 2. Modelo Interno do Sistema de Banco de Dados Distribuído Replicado
Com relação ao ambiente estão sendo efetuados testes sobre dois bancos de dados:
MySQL e PostgreSQL, utilizando plataformas Windows e Linux. O objetivo é que cada
nó possua uma configuração diferenciada, ou seja, o nó 1, por exemplo, contenha
plataforma Windows com MySQL, o nó 2 plataforma Windows com PostgreSQL, o nó
3 plataforma Linux com MySQL e assim sucessivamente. Tem-se por meta avaliar,
futuramente, a performance, velocidade e segurança destes nós, em se tratando de que
estes apresentam características bem diferenciadas.
3. Arquitetura
A arquitetura de uma aplicação focaliza o processamento do sistema de
particionamento, ou seja, a arquitetura decide em que máquina e em que espaço de
processo um determinado código deve executar [Özsu, 1999]. Qualquer aplicação de
banco de dados é uma aplicação cliente/servidor se ela manipular armazenamento e
recuperação de dados no processo de banco de dados e manipulação e apresentação de
dados em qualquer outro lugar. O objetivo desta proposta é utilizar uma arquitetura de
três camadas (arquitetura que utiliza um servidor de aplicação entre cliente e banco de
dados) com vários servidores conectados a bancos de dados idênticos (replicados). Para
que esta estrutura funcione corretamente a seguir serão demonstradas algumas
características estabelecidas no lado do cliente e do servidor.
3.1. Cliente-Applet
A camada de apresentação, a qual caracteriza o cliente, deve fornecer uma interface de
usuário para utilização do sistema. O cliente, na verdade, acessa uma máquina servidora,
onde está instalado o serviço Web, por meio do software Apache. O serviço
disponibiliza o acesso a Applet de gerenciamento. A Applet disponibiliza a interface
onde são solicitadas as transações. Assim é feita a localização do serviço através da
mensagem lookup identificando um serviço RMI de nome AppletDBService. Caso a
conexão for bem sucedida é enviada a mensagem retornaInformacao passando como
parâmetro o comando SQL requerido.
Fig. 3. Conexão Applet – Serviço Local
3.2. Serviço Local
Conforme as informações solicitadas pela Applet responsável pela aplicação, o sistema
irá ativar várias linhas de execução (threads), no objetivo de consultar ou atualizar os
diversos servidores. Através do envio da mensagem start a aplicação ativa cada thread
para uma lista de servidores disponíveis em arquivo.
ipRemoto1=200.132.78.158
ipRemoto2=200.132.78.146
ipRemoto3=200.132.78.147
ipRemoto4=end
soRemoto1=windows
soRemoto2=linux
soRemoto3=windows
soRemoto4=end
Cada linha é colocada em execução através do método run cuja primeira solicitação é
a execução do comando PING. O comando PING tem por função verificar se o servidor
solicitado encontra-se ativo ou não. Caso o servidor solicitado encontre-se ativo é feita à
tentativa para conexão com o serviço remoto. O primeiro passo é a localização do
serviço através da mensagem lookup identificando um serviço RMI de nome DataBase.
Por fim, se a conexão for bem sucedida é enviada a mensagem executaComando
passando como parâmetro o comando SQL requerido. Neste momento o controle
operacional está de posse do servidor. É importante salientar que a ativação das threads
é feita para todos os servidores disponíveis.
Fig. 4. Conexão Serviço Local – Serviço Distribuído
No caso de um comando SQL do tipo SELECT a primeira thread que atender a
requisição do usuário tem por objetivo prover o cancelamento das outras que ainda estão
tentando localizar a informação. No caso de comandos de atualização como INSERT,
UPDATE ou DELETE cada thread deve terminar naturalmente.
Para os comandos de atualização são verificados quais os serviços que não estão
disponíveis. Para cada serviço ativo será enviado o comando SQL a ser executado e o
número IP da máquina que não oferece, temporariamente, o serviço. Estas informações
são armazenadas no arquivo de log de cada servidor ativo.
A ativação das linhas de execução para envio das informações de falha ocorre de
maneira semelhante às consultas. A única diferença no diagrama da figura 3 é a
modificação do método executaComando(solicita) pelo método atualizaLog(numIPLog,
solicita). Através do envio da mensagem start a aplicação, agora, ativa cada thread para
uma lista de servidores que estão ativos no momento. Cada servidor recebe, portanto, a
mensagem atualizaLog a qual é responsável pelo armazenamento destas informações no
lado do servidor. Estas informações são armazenadas até o momento em que a máquina
de número IP determinada voltar as suas atividades normais e permitir a atualização de
sua base de dados.
3.3. Servidor
O lado servidor tem por responsabilidade gerenciar, fornecer e manipular as
informações junto ao banco de dados. Os métodos remotos são definidos no lado do
servidor sendo que o cliente só dispõe das interfaces dos mesmos. Portanto, os métodos
executaComando e atualizaLog citados anteriormente são implementados no lado do
servidor. Para cada solicitação de comando SQL recebida pelo servidor este precisa
acessar a base local disponível. O acesso é feito via API JDBC que promove a conexão
de uma aplicação Java a uma base de dados.
A figura 5, a seguir, mostra a seqüência do envio de mensagens para o método
executaComando. Para cada acesso realizado ao serviço a aplicação faz uma nova
conexão à base de dados. O método getConnection tem por objetivo atualizar as
informações a respeito da base de dados que será utilizada. É feita a leitura de um
arquivo texto o qual possui informações a respeito do driver, url, username e password.
Esta facilidade foi inserida no intuito de propor ao usuário a utilização de qualquer
tecnologia de base de dados no lado servidor desde que este possua os drivers de
gerenciamento para tal.
jdbc.driver=org.gjt.mm.mysql.Driver
jdbc.url=jdbc:mysql://localhost/bancodadosexemplo
jdbc.username=PUBLIC
jdbc.password=
Após a identificação das informações, quando uma classe Driver, reconhece sua
URL, ela cria uma conexão de banco de dados utilizando as propriedades especificadas.
Ela fornece a classe DriverManager uma implementação java.sql.Connection
representando esta conexão de banco de dados. DriverManager retorna este objeto
Connection para a implementação.
Fig. 5. Conexão Servidor
A partir do objeto Connection é criado um conjunto de procedimentos através de
createStatement para que se possa fazer o direcionamento do comando SQL desejado.
Por fim, o método executeQuery é responsável pela execução do comando desejado. É
importante observar que para comandos do tipo SELECT o método retornará
informações que serão encaminhadas ao lado cliente via serviço RMI. Para comandos de
atualização que não geram informações de retorno para visualização, faz-se o retorno do
status para gerenciamento das atividades.
O lado servidor comporta-se como uma aplicação com uma base de dados local. Caso
a base de dados não esteja disponível no momento, pelo fato do banco de dados não
estar ativo, o serviço RMI deste servidor mantém um arquivo de log com as operações
de atualização. Toda vez que for proposta alguma verificação ou atualização de
informações no banco e existirem informações no arquivo de log este é
automaticamente atualizado.
Uma outra característica do lado servidor é que quando este ativado é feita uma
procura nos logs disponíveis nos outros servidores se não existem atualizações a serem
executadas para tanto é armazenado em arquivo as informações a respeito dos outros
servidores.
dbc.ip=200.132.78.158
jdbc.so=windows
jdbc.ipRemoto1=200.132.78.146
jdbc.ipRemoto2=200.132.78.147
jdbc.ipRemoto3=end
jdbc.soRemoto1=linux
jdbc.soRemoto2=windows
jdbc.soRemoto3=end
3.4. Falha de Serviço
O grande problema a ser administrado pelo sistema é quando um determinado serviço
não está disponível e comandos SQL de atualização são solicitados. Conforme
mencionado na seção 3.2 o serviço local responsabiliza-se em detectar quais serviços
não estão disponíveis enviando para os servidores ativos informações sobre os IPs com
problemas bem como informando, também, os respectivos comandos SQL. Esta parte já
está implementada e atende as necessidades previstas para o perfeito funcionamento do
sistema.
Também implementada está a atualização das informações quando um determinado
serviço retorna ao perfeito funcionamento. É importante salientar que um servidor não
pode prover informações até que venha a ser totalmente atualizado. A idéia é que o
serviço ao retornar a funcionar envie solicitações aos outros servidores verificando se
estes outros detém comandos em seus arquivos de logs. O pior caso é quando todos os
outros servidores não fornecem o serviço. Neste caso o sistema deve interromper as suas
atividades de atualização, fornecendo, apenas, informações sobre consultas,
apresentando ao usuário que está atualizado até uma determinada data. Caso contrário
cada servidor disponível retornará as informações que detém para atualizar a base em
questão.
Uma outra questão que pode a acontecer é a existência de duplicidades de
informações nos arquivos de logs disponíveis. O gerenciamento desta etapa propõe o
armazenamento no lado do servidor dos comandos já atualizados, com respectivas datas
e horários de solicitação. Caso um servidor forneça as informações e outro esteja fora de
serviço, e também contenha as informações, em uma próxima atualização estes
comandos já estarão atualizados e serão descartados.
Conclusões
Os mecanismos de suporte ao serviço RMI permitem a conexão entre diversas
aplicações Java em equipamentos diferentes exceto para aplicações Applets executadas
dentro de um navegador. Levando em consideração tal restrição implementou-se um
serviço local que propicia a comunicação com outros equipamentos. As implementações
propostas até o momento demonstram a eficácia e aplicabilidade da distribuição dos
serviços remotos. Unindo, portanto, os serviços remotos aos serviços disponíveis para
bancos de dados foram demonstrados, neste trabalho, o gerenciamento distribuído das
atividades de consulta e atualização a bases de dados.
Preliminarmente, percebe-se que o estado atual do sistema atende aos requisitos no
que se refere a consultas e atualizações. Com relação às atualizações, em caso de falha
nos servidores, a implementação mantém atualizadas todas as bases disponíveis.
Acredita-se que a validação da consistência lógica apresentada pelo sistema proposto
será aumentada gradualmente com novos testes, portanto mais estudos de caso,
envolvendo aplicações reais, estão sendo preparados para certificar o modelo.
Trabalhos Futuros
O objetivo deste trabalho foi demonstrar as características básicas de uma proposta para
implementação de um sistema de banco de dados distribuído e replicado utilizando
serviço RMI-Java, atualizado através de Applets Java. Alguns problemas ainda devem
ser estudados. Com relação ao crescimento da rede são raros os estudos de desempenho
de um SGBD distribuído. Faz-se importante detalhar a rede de comunicação observando
o comportamento de protocolos de comunicação e de algoritmos à medida que os
sistemas crescem.
Referências
Breitbar, Y; Silberschatz, A. ”Overview of Multidatabase Transaction Management”, The
VLDB Journal, vol. 1, n. 2, pp. 181-239, 1992.
Chung, C; Dataplex, C. “An Accesss to Heterogeneous Distributed Databases”, Comunications
of the ACM, vol. 33, n. 1, pp. 70-80, Jan. 1990.
Elmasri, R; Navathe, S. Fundamentals of Database Systems, Benjamin/Cummings, 2a. edição,
1994.
Horstmann, C; Cornell G. Core Java 2: Volume II, Advanced Features. [S.l.]: Prentice Hall,
2001.
Korth, H; Silberschatz, A, Sistema de Banco de Dados. Makron Books, São Paulo, 1995.
Lima, J.C; Ribeiro C. Oliveira, “Acesso Integrado a Banco de Dados Distribuídos Heterogêneos
utilizando CORBA” in Proc.
1997 XII Simpósio Brasileiro de Banco de Dados,
Fortaleza, Brasil, pp.333-348.
Niemeyer, P; Peck, J. Exploring Java, [S.l.]: O'Reilly & Associates, 1997.
Özsu, M.T; Valduriez, P. Principles of Distributed Database Systems, Prentice Hall, 2a. edição,
1999.
Ram, S. “Heterogeneous Distributed Database Systems”. Computer, v.24 , n.1, p.7-9, Dec.
1991.
Reese, G. Programação para Banco de Dados. JDBC e Java, Ed. Bercley, São Paulo, 2000.

Mais conteúdo relacionado

Mais procurados

Arquitetura peer to-peer (p2p)
Arquitetura peer to-peer (p2p)Arquitetura peer to-peer (p2p)
Arquitetura peer to-peer (p2p)
Nilton Rodrigues Pereira
 
Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02
Arthur Emanuel
 
S.o aula 1920
S.o aula 1920S.o aula 1920
S.o aula 1920
Armando Rivarola
 
Dia 12 04_2010
Dia 12 04_2010Dia 12 04_2010
Dia 12 04_2010
scorpio3
 
Apresentação1
Apresentação1Apresentação1
Apresentação1
Ruihardy Hardy
 
Redes de Computadores
Redes de ComputadoresRedes de Computadores
Redes de Computadores
deisiweg
 
Sistemas Distribuídos - Aula 03
Sistemas Distribuídos - Aula 03Sistemas Distribuídos - Aula 03
Sistemas Distribuídos - Aula 03
Arthur Emanuel
 
Internet
InternetInternet
Internet
redesinforma
 
Memória Compartilhada Distribuída Conceitos e Algoritmos
Memória Compartilhada Distribuída Conceitos e AlgoritmosMemória Compartilhada Distribuída Conceitos e Algoritmos
Memória Compartilhada Distribuída Conceitos e Algoritmos
Augusto Luengo Pereira Nunes, PhD
 
Proposta lucas simon-rodrigues-magalhaes
Proposta lucas simon-rodrigues-magalhaesProposta lucas simon-rodrigues-magalhaes
Proposta lucas simon-rodrigues-magalhaes
lucassrod
 
Modelo osi e seus serviços
Modelo osi e seus serviçosModelo osi e seus serviços
Modelo osi e seus serviços
Luciano Rodrigues da Silva
 
GlossáRio De Internet
GlossáRio De InternetGlossáRio De Internet
GlossáRio De Internet
FredericoSilva
 
Modelo OSI - Camada 6
Modelo OSI - Camada 6Modelo OSI - Camada 6
Modelo OSI - Camada 6
Kiidz
 
WebServices
WebServicesWebServices
WebServices
Frederico Madeira
 
Modelo osi
Modelo osiModelo osi
Modelo osi
Ana Santos
 
Peer-to-peer
Peer-to-peerPeer-to-peer
Peer-to-peer
Leo-Sotto
 
Icc: primeiro trabalho do modelo OSI
Icc: primeiro trabalho do modelo OSIIcc: primeiro trabalho do modelo OSI
Icc: primeiro trabalho do modelo OSI
nogueirinha
 
Apostilaredes
ApostilaredesApostilaredes
Apostilaredes
Alexandre Unterstell
 
SI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de CódigoSI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de Código
Frederico Madeira
 
SI - SAD - Sistemas de Arquivos Distribuídos
SI - SAD  - Sistemas de Arquivos DistribuídosSI - SAD  - Sistemas de Arquivos Distribuídos
SI - SAD - Sistemas de Arquivos Distribuídos
Frederico Madeira
 

Mais procurados (20)

Arquitetura peer to-peer (p2p)
Arquitetura peer to-peer (p2p)Arquitetura peer to-peer (p2p)
Arquitetura peer to-peer (p2p)
 
Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02
 
S.o aula 1920
S.o aula 1920S.o aula 1920
S.o aula 1920
 
Dia 12 04_2010
Dia 12 04_2010Dia 12 04_2010
Dia 12 04_2010
 
Apresentação1
Apresentação1Apresentação1
Apresentação1
 
Redes de Computadores
Redes de ComputadoresRedes de Computadores
Redes de Computadores
 
Sistemas Distribuídos - Aula 03
Sistemas Distribuídos - Aula 03Sistemas Distribuídos - Aula 03
Sistemas Distribuídos - Aula 03
 
Internet
InternetInternet
Internet
 
Memória Compartilhada Distribuída Conceitos e Algoritmos
Memória Compartilhada Distribuída Conceitos e AlgoritmosMemória Compartilhada Distribuída Conceitos e Algoritmos
Memória Compartilhada Distribuída Conceitos e Algoritmos
 
Proposta lucas simon-rodrigues-magalhaes
Proposta lucas simon-rodrigues-magalhaesProposta lucas simon-rodrigues-magalhaes
Proposta lucas simon-rodrigues-magalhaes
 
Modelo osi e seus serviços
Modelo osi e seus serviçosModelo osi e seus serviços
Modelo osi e seus serviços
 
GlossáRio De Internet
GlossáRio De InternetGlossáRio De Internet
GlossáRio De Internet
 
Modelo OSI - Camada 6
Modelo OSI - Camada 6Modelo OSI - Camada 6
Modelo OSI - Camada 6
 
WebServices
WebServicesWebServices
WebServices
 
Modelo osi
Modelo osiModelo osi
Modelo osi
 
Peer-to-peer
Peer-to-peerPeer-to-peer
Peer-to-peer
 
Icc: primeiro trabalho do modelo OSI
Icc: primeiro trabalho do modelo OSIIcc: primeiro trabalho do modelo OSI
Icc: primeiro trabalho do modelo OSI
 
Apostilaredes
ApostilaredesApostilaredes
Apostilaredes
 
SI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de CódigoSI - Processos, Threads, Virtualização e Migração de Código
SI - Processos, Threads, Virtualização e Migração de Código
 
SI - SAD - Sistemas de Arquivos Distribuídos
SI - SAD  - Sistemas de Arquivos DistribuídosSI - SAD  - Sistemas de Arquivos Distribuídos
SI - SAD - Sistemas de Arquivos Distribuídos
 

Destaque

Nicke 06.03
Nicke 06.03Nicke 06.03
Nicke 06.03
Meio & Mensagem
 
Mtv 11.04
Mtv 11.04Mtv 11.04
Mtv 11.04
Meio & Mensagem
 
QOs
QOsQOs
QOs
VNG
 
Cara login ke dasbor wodrpress
Cara login ke dasbor wodrpressCara login ke dasbor wodrpress
Cara login ke dasbor wodrpress
Sutardjo ( Mang Ojo )
 
3ºano
3ºano3ºano
Pizarra02
Pizarra02Pizarra02
Pizarra02
rodrigoeducamos
 
Φίλτρο νερού Aqua Vie
Φίλτρο νερού Aqua VieΦίλτρο νερού Aqua Vie
Φίλτρο νερού Aqua Vie
Camelot International Health Organization
 
Thực hiện cuộc gọi vo ip đơn giản
Thực hiện cuộc gọi vo ip đơn giảnThực hiện cuộc gọi vo ip đơn giản
Thực hiện cuộc gọi vo ip đơn giản
VNG
 
ประกาศรับย้าย/รับโอน/บุคลากรทางการศึกษาอื่่นตามมาตรา 38 ค(2) สพป.ลย1
ประกาศรับย้าย/รับโอน/บุคลากรทางการศึกษาอื่่นตามมาตรา 38 ค(2) สพป.ลย1ประกาศรับย้าย/รับโอน/บุคลากรทางการศึกษาอื่่นตามมาตรา 38 ค(2) สพป.ลย1
ประกาศรับย้าย/รับโอน/บุคลากรทางการศึกษาอื่่นตามมาตรา 38 ค(2) สพป.ลย1
itecloei1
 
Aparell locomotor
Aparell locomotorAparell locomotor
Aparell locomotor
Marta Baró Sancho
 
Tierra De Dinosaurios Grupo5
Tierra De Dinosaurios Grupo5Tierra De Dinosaurios Grupo5
Tierra De Dinosaurios Grupo5
salaazul
 
test upload
test uploadtest upload
test upload
dearlyraindear
 
Appreciation letter to Mr. Abudullah
Appreciation letter to Mr. AbudullahAppreciation letter to Mr. Abudullah
Appreciation letter to Mr. AbudullahAbdulla Nasseer
 
Ymaps
YmapsYmaps
Bidang pembelajaran-4-1
Bidang pembelajaran-4-1Bidang pembelajaran-4-1
Bidang pembelajaran-4-1
Bazlin Ahmad
 
Πλυντήριο καθαρισμού τροφίμων Imperial Tech
Πλυντήριο καθαρισμού τροφίμων Imperial TechΠλυντήριο καθαρισμού τροφίμων Imperial Tech
Πλυντήριο καθαρισμού τροφίμων Imperial Tech
Camelot International Health Organization
 
Bê á-ba do bebê 10.06
Bê á-ba do bebê 10.06Bê á-ba do bebê 10.06
Bê á-ba do bebê 10.06
Meio & Mensagem
 

Destaque (20)

Nicke 06.03
Nicke 06.03Nicke 06.03
Nicke 06.03
 
Mtv 11.04
Mtv 11.04Mtv 11.04
Mtv 11.04
 
QOs
QOsQOs
QOs
 
Cara login ke dasbor wodrpress
Cara login ke dasbor wodrpressCara login ke dasbor wodrpress
Cara login ke dasbor wodrpress
 
IMG_1416
IMG_1416IMG_1416
IMG_1416
 
Vstrech vipusk
Vstrech vipuskVstrech vipusk
Vstrech vipusk
 
3ºano
3ºano3ºano
3ºano
 
Pizarra02
Pizarra02Pizarra02
Pizarra02
 
Φίλτρο νερού Aqua Vie
Φίλτρο νερού Aqua VieΦίλτρο νερού Aqua Vie
Φίλτρο νερού Aqua Vie
 
CertIV_T&A_Certificate
CertIV_T&A_CertificateCertIV_T&A_Certificate
CertIV_T&A_Certificate
 
Thực hiện cuộc gọi vo ip đơn giản
Thực hiện cuộc gọi vo ip đơn giảnThực hiện cuộc gọi vo ip đơn giản
Thực hiện cuộc gọi vo ip đơn giản
 
ประกาศรับย้าย/รับโอน/บุคลากรทางการศึกษาอื่่นตามมาตรา 38 ค(2) สพป.ลย1
ประกาศรับย้าย/รับโอน/บุคลากรทางการศึกษาอื่่นตามมาตรา 38 ค(2) สพป.ลย1ประกาศรับย้าย/รับโอน/บุคลากรทางการศึกษาอื่่นตามมาตรา 38 ค(2) สพป.ลย1
ประกาศรับย้าย/รับโอน/บุคลากรทางการศึกษาอื่่นตามมาตรา 38 ค(2) สพป.ลย1
 
Aparell locomotor
Aparell locomotorAparell locomotor
Aparell locomotor
 
Tierra De Dinosaurios Grupo5
Tierra De Dinosaurios Grupo5Tierra De Dinosaurios Grupo5
Tierra De Dinosaurios Grupo5
 
test upload
test uploadtest upload
test upload
 
Appreciation letter to Mr. Abudullah
Appreciation letter to Mr. AbudullahAppreciation letter to Mr. Abudullah
Appreciation letter to Mr. Abudullah
 
Ymaps
YmapsYmaps
Ymaps
 
Bidang pembelajaran-4-1
Bidang pembelajaran-4-1Bidang pembelajaran-4-1
Bidang pembelajaran-4-1
 
Πλυντήριο καθαρισμού τροφίμων Imperial Tech
Πλυντήριο καθαρισμού τροφίμων Imperial TechΠλυντήριο καθαρισμού τροφίμων Imperial Tech
Πλυντήριο καθαρισμού τροφίμων Imperial Tech
 
Bê á-ba do bebê 10.06
Bê á-ba do bebê 10.06Bê á-ba do bebê 10.06
Bê á-ba do bebê 10.06
 

Semelhante a Poster08

Protocolos logicos de_comunicacao
Protocolos logicos de_comunicacaoProtocolos logicos de_comunicacao
Protocolos logicos de_comunicacao
Portal_do_Estudante_Redes
 
Apostila Oracle 10g
Apostila Oracle 10gApostila Oracle 10g
Apostila Oracle 10g
Andre Nascimento
 
BDD
BDDBDD
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptxAula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
ChadidoDiogo1
 
121 redes
121 redes121 redes
121 redes
ARILSON OLIVEIRA
 
Banco de dados distribuidos
Banco de dados distribuidosBanco de dados distribuidos
Banco de dados distribuidos
Deroci Nonato Júnior
 
Arquitetura e Integração de sistemas
Arquitetura e Integração de sistemasArquitetura e Integração de sistemas
Arquitetura e Integração de sistemas
Jether Rodrigues
 
Modelo de Referência OSI
Modelo de Referência OSIModelo de Referência OSI
Modelo de Referência OSI
Alberto Felipe Friderichs Barros
 
Sistemas Distribuidos, Middleware e RPC
Sistemas Distribuidos, Middleware e RPCSistemas Distribuidos, Middleware e RPC
Sistemas Distribuidos, Middleware e RPC
limabezerra
 
Sistemas Distribuidos, Middleware e RPC
Sistemas Distribuidos, Middleware e RPCSistemas Distribuidos, Middleware e RPC
Sistemas Distribuidos, Middleware e RPC
limabezerra
 
Redes de computadores
Redes de computadoresRedes de computadores
Banco de Dados Distribuidos
Banco de Dados DistribuidosBanco de Dados Distribuidos
Banco de Dados Distribuidos
André Fachin
 
Web Sphere Application Server
Web Sphere Application ServerWeb Sphere Application Server
Web Sphere Application Server
Fabricio Carvalho
 
Web Services
Web ServicesWeb Services
Web Services
Paulo Neto
 
Net framework
 Net framework Net framework
Net framework
Waldir Calazans
 
Odi tutorial glossário e termos técnicos
Odi tutorial   glossário e termos técnicosOdi tutorial   glossário e termos técnicos
Odi tutorial glossário e termos técnicos
Caio Lima
 
Apontamentos psi m18
Apontamentos psi m18Apontamentos psi m18
Apontamentos psi m18
tomascarol2
 
GlossáRio De Internet
GlossáRio De InternetGlossáRio De Internet
GlossáRio De Internet
CatarinaTavares
 
Cliente e servidor
Cliente e servidorCliente e servidor
Cliente e servidor
Davi Silva
 
Sistema Computacao Revisao 1
Sistema Computacao Revisao 1Sistema Computacao Revisao 1
Sistema Computacao Revisao 1
Duílio Andrade
 

Semelhante a Poster08 (20)

Protocolos logicos de_comunicacao
Protocolos logicos de_comunicacaoProtocolos logicos de_comunicacao
Protocolos logicos de_comunicacao
 
Apostila Oracle 10g
Apostila Oracle 10gApostila Oracle 10g
Apostila Oracle 10g
 
BDD
BDDBDD
BDD
 
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptxAula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
 
121 redes
121 redes121 redes
121 redes
 
Banco de dados distribuidos
Banco de dados distribuidosBanco de dados distribuidos
Banco de dados distribuidos
 
Arquitetura e Integração de sistemas
Arquitetura e Integração de sistemasArquitetura e Integração de sistemas
Arquitetura e Integração de sistemas
 
Modelo de Referência OSI
Modelo de Referência OSIModelo de Referência OSI
Modelo de Referência OSI
 
Sistemas Distribuidos, Middleware e RPC
Sistemas Distribuidos, Middleware e RPCSistemas Distribuidos, Middleware e RPC
Sistemas Distribuidos, Middleware e RPC
 
Sistemas Distribuidos, Middleware e RPC
Sistemas Distribuidos, Middleware e RPCSistemas Distribuidos, Middleware e RPC
Sistemas Distribuidos, Middleware e RPC
 
Redes de computadores
Redes de computadoresRedes de computadores
Redes de computadores
 
Banco de Dados Distribuidos
Banco de Dados DistribuidosBanco de Dados Distribuidos
Banco de Dados Distribuidos
 
Web Sphere Application Server
Web Sphere Application ServerWeb Sphere Application Server
Web Sphere Application Server
 
Web Services
Web ServicesWeb Services
Web Services
 
Net framework
 Net framework Net framework
Net framework
 
Odi tutorial glossário e termos técnicos
Odi tutorial   glossário e termos técnicosOdi tutorial   glossário e termos técnicos
Odi tutorial glossário e termos técnicos
 
Apontamentos psi m18
Apontamentos psi m18Apontamentos psi m18
Apontamentos psi m18
 
GlossáRio De Internet
GlossáRio De InternetGlossáRio De Internet
GlossáRio De Internet
 
Cliente e servidor
Cliente e servidorCliente e servidor
Cliente e servidor
 
Sistema Computacao Revisao 1
Sistema Computacao Revisao 1Sistema Computacao Revisao 1
Sistema Computacao Revisao 1
 

Mais de Simba Samuel

Manual cctv v3.1
Manual cctv v3.1 Manual cctv v3.1
Manual cctv v3.1
Simba Samuel
 
Manual do curso de cftv
Manual do curso de cftvManual do curso de cftv
Manual do curso de cftv
Simba Samuel
 
012 computacao forense
012   computacao forense012   computacao forense
012 computacao forense
Simba Samuel
 
Ubuntu guia do_iniciante-2-0
Ubuntu guia do_iniciante-2-0Ubuntu guia do_iniciante-2-0
Ubuntu guia do_iniciante-2-0
Simba Samuel
 
Curriculum vitae
Curriculum vitaeCurriculum vitae
Curriculum vitae
Simba Samuel
 
Angola2
Angola2Angola2
Angola2
Simba Samuel
 
Motivação
MotivaçãoMotivação
Motivação
Simba Samuel
 
Html
HtmlHtml
Capítulo 3 funcionalidades e protocolos da camada de aplicação
Capítulo 3   funcionalidades e protocolos da camada de aplicaçãoCapítulo 3   funcionalidades e protocolos da camada de aplicação
Capítulo 3 funcionalidades e protocolos da camada de aplicação
Simba Samuel
 
Linguagem de-programacao-html 2
Linguagem de-programacao-html 2Linguagem de-programacao-html 2
Linguagem de-programacao-html 2
Simba Samuel
 
Segurança de informação1
Segurança de informação1Segurança de informação1
Segurança de informação1
Simba Samuel
 
Android in action 2nd edition 2011
Android in action 2nd edition 2011Android in action 2nd edition 2011
Android in action 2nd edition 2011
Simba Samuel
 
Projecto de Programação de Aluno(Samuel)
Projecto de Programação de Aluno(Samuel)Projecto de Programação de Aluno(Samuel)
Projecto de Programação de Aluno(Samuel)
Simba Samuel
 
Mgp sisp --plano_de_gerenciamento_do_projeto
Mgp sisp --plano_de_gerenciamento_do_projetoMgp sisp --plano_de_gerenciamento_do_projeto
Mgp sisp --plano_de_gerenciamento_do_projeto
Simba Samuel
 
Exercicios
ExerciciosExercicios
Exercicios
Simba Samuel
 

Mais de Simba Samuel (15)

Manual cctv v3.1
Manual cctv v3.1 Manual cctv v3.1
Manual cctv v3.1
 
Manual do curso de cftv
Manual do curso de cftvManual do curso de cftv
Manual do curso de cftv
 
012 computacao forense
012   computacao forense012   computacao forense
012 computacao forense
 
Ubuntu guia do_iniciante-2-0
Ubuntu guia do_iniciante-2-0Ubuntu guia do_iniciante-2-0
Ubuntu guia do_iniciante-2-0
 
Curriculum vitae
Curriculum vitaeCurriculum vitae
Curriculum vitae
 
Angola2
Angola2Angola2
Angola2
 
Motivação
MotivaçãoMotivação
Motivação
 
Html
HtmlHtml
Html
 
Capítulo 3 funcionalidades e protocolos da camada de aplicação
Capítulo 3   funcionalidades e protocolos da camada de aplicaçãoCapítulo 3   funcionalidades e protocolos da camada de aplicação
Capítulo 3 funcionalidades e protocolos da camada de aplicação
 
Linguagem de-programacao-html 2
Linguagem de-programacao-html 2Linguagem de-programacao-html 2
Linguagem de-programacao-html 2
 
Segurança de informação1
Segurança de informação1Segurança de informação1
Segurança de informação1
 
Android in action 2nd edition 2011
Android in action 2nd edition 2011Android in action 2nd edition 2011
Android in action 2nd edition 2011
 
Projecto de Programação de Aluno(Samuel)
Projecto de Programação de Aluno(Samuel)Projecto de Programação de Aluno(Samuel)
Projecto de Programação de Aluno(Samuel)
 
Mgp sisp --plano_de_gerenciamento_do_projeto
Mgp sisp --plano_de_gerenciamento_do_projetoMgp sisp --plano_de_gerenciamento_do_projeto
Mgp sisp --plano_de_gerenciamento_do_projeto
 
Exercicios
ExerciciosExercicios
Exercicios
 

Poster08

  • 1. Um Sistema de Banco de Dados Replicado Gerenciado através de Applets Distribuídas André Luis Castro de Freitas1 1 Departamento de Matemática – Fundação Universidade Federal do Rio Grande (FURG) Caixa Postal 474 – 96201.900 – Rio Grande – RS – Brazil dmtalcf@super.furg.br Abstract. A distributed and replied database it is characterized as a collection of several similar databases, logically connected through a computers net. This work has as proposal the definition, administration and implementation of a distributed and replied database that uses several databases in different servers. Therefore, the distributed transactions, width concurrency control, are executed through the same software in the different nodes, characterizing a distributed database system. The software proposes the use of interfaces through navigation web browse, applets in the programming language Java, where the structures customers and the several servers that manipulate the databases built using the RMI. Resumo. Uma base de dados distribuída e replicada caracteriza-se como uma coleção de diversas bases de dados, semelhantes, interligadas logicamente através de uma rede de computadores. Este trabalho tem como proposta a definição, gerenciamento e implementação de um banco de dados distribuído replicado que utilize várias bases de dados relacionais em diferentes servidores. Portanto, as transações distribuídas, com o controle da concorrência, são executadas através do mesmo software nos diferentes nós. O software propõe a utilização de interfaces via navegador web, applets na linguagem de programação Java e as estruturas clientes e servidores que manipulam as bases de dados construídas utilizando o serviço RMI. 1. Introdução Os sistemas de banco de dados têm sido criados de forma independente, sem a preocupação quanto a possíveis integrações. Assim, cada base de dados pertencente a um sistema é administrada sob regras locais e autônomas. A evolução tecnológica das redes de computadores e de banco de dados propõe a modificação na maneira como os dados são processados [Lima, 1997]. A existência de diferentes SGBDs apresenta-se como natural e inevitável no contexto das grandes organizações, e cria a necessidade de um outro nível de sistema de gerência de banco de dados, capaz de prover o acesso a dados já existentes e distribuídos em redes de computadores [Chung, 1990]. Este acesso deve ser feito sem exigir mudanças locais nos banco de dados não requerendo reprogramação dos SGBDs envolvidos [RAM, 1991]. Sistemas que atendem a esses requisitos não possuem uma denominação única, e são
  • 2. chamados de sistemas de banco de dados federados, de sistemas multidatabase ou, ainda, de sistemas de banco de dados distribuídos heterogêneos [Breitbar, 1992]. Um sistema de banco de dados distribuído heterogêneo representa a combinação de diferentes tecnologias de bases de dados com um sistema em questão, ou seja, consiste de uma coleção de nós cada qual podendo participar na execução de transações que fazem acesso a dados em um ou diversos nós de maneira transparente [Özsu, 1999]. Atualmente existem alguns bancos de dados distribuídos comerciais que apresentam características de processamento distribuído. Entre eles pode-se citar o Oracle 9i, o qual apresenta fragmentação horizontal primária de tabelas e índices. Essa versão demonstra total transparência na manipulação dos dados. Um segundo exemplo é o SQL Server 2000 cuja redução de fragmentos horizontais ainda é limitada. Por fim o IBM Informix Dynamic Server que utiliza também fragmentação primária através de um servidor cuja responsabilidade é estender a distribuição. Mas todos esses bancos de dados são softwares proprietários e apresentam grande complexidade de desenvolvimento e alto custo de manutenção. O grande problema destes sistemas é a não conexão a outras tecnologias de bancos de dados existentes, não permitindo a heterogeneidade. O objetivo deste trabalho é, portanto, gerenciar e coordenar as transações de um sistema de banco de dados distribuído e replicado que manipule diferentes bancos em cada um dos nós envolvidos. Com o objetivo de atenuar a complexidade de desenvolvimento do sistema proposto optou-se pela utilização de réplicas, considerando os nós disponíveis, não levando em consideração a possibilidade de fragmentação. Acredita-se que a utilização de réplicas, apesar de resultar na duplicação de informações, contribua positivamente com o paralelismo, quando a exigência maior do sistema for para leituras e com a disponibilidade das informações, pois o sistema pode continuar o processamento apesar da identificação de falhas em alguns nós. Conforme a figura 1, cada nó contém uma cópia do banco de dados (de diferentes fornecedores) que permanece conectado ao serviço de gerenciamento. O cliente acessa o serviço e estabelece a conexão com um dos nós, em caso de consultas, ou com todos os nós, em caso de atualizações. Fig. 1. Sistema de Banco de Dados Distribuído Replicado / RMI-Java Considerando a afirmação anterior, verifica-se a necessidade de gerenciar a execução de transações que fazem acesso aos dados armazenados em um nó local. É importante ressaltar que cada transação pode ser tanto uma transação local como parte de uma transação global. Partindo deste pressuposto criou-se um serviço, disponível em cada nó, implementado a partir da linguagem Java, utilizando o mecanismo RMI – Remote Method Invocation.
  • 3. RMI disponibiliza uma família de objetos colaborativos localizados em qualquer lugar permitindo a comunicação através de protocolos padrão através da rede. O método permite a comunicação entre máquinas virtuais Java executadas em computadores distintos [Horstmann, 2001]. Este trabalho está organizado nas seções 2 e 3. A seção 2 define e caracteriza o modelo e o ambiente da estrutura proposta. Na seção 3 é demonstrada a arquitetura do sistema, onde são verificados os lados do servidor e do cliente identificando as estruturas de conexão e controle. Após procede-se a conclusão e trabalhos futuros. 2. Modelo e Ambiente A proposta para o modelo é a utilização de servidores Web distribuídos. Esta abordagem espalha a carga de pedidos entre os vários computadores conectados. A conexão do usuário ao sistema é feita pela execução de uma applet Java cuja cópia está disponível em cada um dos servidores. Portanto o cliente pode optar em qual nodo fará a execução, pois cada um dos componentes possui uma réplica do conteúdo a ser oferecido por esse servidor Web. A applet Java comunica-se com um serviço disponível localmente o qual fará a conexão aos outros servidores para acesso ao serviço de banco de dados. Estas conexões são todas gerenciadas através do mecanismo RMI. O mecanismo RMI permite o acesso a um objeto em uma máquina diferente o qual é chamado de objeto remoto. Quando o cliente quer executar um método remoto ele simplesmente invoca um método normal da linguagem Java que será encapsulado em um objeto substituto chamado stub. O stub empacota, como um bloco de bytes, os parâmetros utilizados no método remoto. O stub, então, envia estas informações para o servidor. No lado do servidor, um objeto receptor separa os parâmetros, localiza o objeto chamado, invoca o método e, por fim, envia um pacote composto dos dados de retorno para o cliente. O stub cliente separa o valor de retorno [Horstmann, 2001]. A conexão local entre o banco de dados e o serviço RMI é feita através da API Java DataBase Connectivity (JDBC). Utilizando JDBC é possível fazer acesso a um banco de dados independentemente do verdadeiro mecanismo de banco de dados que está sendo utilizado para armazenamento das informações [Reese, 2000], promovendo a heterogeneidade. O conjunto de classes que implementam as interfaces JDBC para um determinado mecanismo de banco de dados é chamado driver JDBC. A figura 2, demonstra o modelo caracterizando, justamente, a existência de uma estrutura RMI para cada nó que disponibiliza o serviço de acesso ao banco de dados. Cada serviço conecta-se, localmente, a cada cópia do banco via um driver JDBC. O cliente, por sua vez, executa uma applet a qual dispõe de um serviço RMI para acesso a objetos remotos. Conseqüentemente, a applet via RMI faz conexão com o serviço gerenciador local que se conecta aos os nós para consulta e/ou atualização das informações. A utilização do serviço local intermediário ocorre devido à limitação de conexão das applets com outros servidores que não o de onde fora carregada a applet. Portanto, é executada uma solicitação inicial de conexão RMI applet → serviço local bem com n (dependendo do número de nodos) conexões RMI serviço local → serviços
  • 4. local e remotos de banco de dados. Fig. 2. Modelo Interno do Sistema de Banco de Dados Distribuído Replicado Com relação ao ambiente estão sendo efetuados testes sobre dois bancos de dados: MySQL e PostgreSQL, utilizando plataformas Windows e Linux. O objetivo é que cada nó possua uma configuração diferenciada, ou seja, o nó 1, por exemplo, contenha plataforma Windows com MySQL, o nó 2 plataforma Windows com PostgreSQL, o nó 3 plataforma Linux com MySQL e assim sucessivamente. Tem-se por meta avaliar, futuramente, a performance, velocidade e segurança destes nós, em se tratando de que estes apresentam características bem diferenciadas. 3. Arquitetura A arquitetura de uma aplicação focaliza o processamento do sistema de particionamento, ou seja, a arquitetura decide em que máquina e em que espaço de processo um determinado código deve executar [Özsu, 1999]. Qualquer aplicação de banco de dados é uma aplicação cliente/servidor se ela manipular armazenamento e recuperação de dados no processo de banco de dados e manipulação e apresentação de dados em qualquer outro lugar. O objetivo desta proposta é utilizar uma arquitetura de três camadas (arquitetura que utiliza um servidor de aplicação entre cliente e banco de dados) com vários servidores conectados a bancos de dados idênticos (replicados). Para que esta estrutura funcione corretamente a seguir serão demonstradas algumas características estabelecidas no lado do cliente e do servidor. 3.1. Cliente-Applet A camada de apresentação, a qual caracteriza o cliente, deve fornecer uma interface de usuário para utilização do sistema. O cliente, na verdade, acessa uma máquina servidora, onde está instalado o serviço Web, por meio do software Apache. O serviço disponibiliza o acesso a Applet de gerenciamento. A Applet disponibiliza a interface onde são solicitadas as transações. Assim é feita a localização do serviço através da mensagem lookup identificando um serviço RMI de nome AppletDBService. Caso a conexão for bem sucedida é enviada a mensagem retornaInformacao passando como parâmetro o comando SQL requerido.
  • 5. Fig. 3. Conexão Applet – Serviço Local 3.2. Serviço Local Conforme as informações solicitadas pela Applet responsável pela aplicação, o sistema irá ativar várias linhas de execução (threads), no objetivo de consultar ou atualizar os diversos servidores. Através do envio da mensagem start a aplicação ativa cada thread para uma lista de servidores disponíveis em arquivo. ipRemoto1=200.132.78.158 ipRemoto2=200.132.78.146 ipRemoto3=200.132.78.147 ipRemoto4=end soRemoto1=windows soRemoto2=linux soRemoto3=windows soRemoto4=end Cada linha é colocada em execução através do método run cuja primeira solicitação é a execução do comando PING. O comando PING tem por função verificar se o servidor solicitado encontra-se ativo ou não. Caso o servidor solicitado encontre-se ativo é feita à tentativa para conexão com o serviço remoto. O primeiro passo é a localização do serviço através da mensagem lookup identificando um serviço RMI de nome DataBase. Por fim, se a conexão for bem sucedida é enviada a mensagem executaComando passando como parâmetro o comando SQL requerido. Neste momento o controle operacional está de posse do servidor. É importante salientar que a ativação das threads é feita para todos os servidores disponíveis. Fig. 4. Conexão Serviço Local – Serviço Distribuído No caso de um comando SQL do tipo SELECT a primeira thread que atender a requisição do usuário tem por objetivo prover o cancelamento das outras que ainda estão tentando localizar a informação. No caso de comandos de atualização como INSERT, UPDATE ou DELETE cada thread deve terminar naturalmente. Para os comandos de atualização são verificados quais os serviços que não estão disponíveis. Para cada serviço ativo será enviado o comando SQL a ser executado e o número IP da máquina que não oferece, temporariamente, o serviço. Estas informações são armazenadas no arquivo de log de cada servidor ativo. A ativação das linhas de execução para envio das informações de falha ocorre de
  • 6. maneira semelhante às consultas. A única diferença no diagrama da figura 3 é a modificação do método executaComando(solicita) pelo método atualizaLog(numIPLog, solicita). Através do envio da mensagem start a aplicação, agora, ativa cada thread para uma lista de servidores que estão ativos no momento. Cada servidor recebe, portanto, a mensagem atualizaLog a qual é responsável pelo armazenamento destas informações no lado do servidor. Estas informações são armazenadas até o momento em que a máquina de número IP determinada voltar as suas atividades normais e permitir a atualização de sua base de dados. 3.3. Servidor O lado servidor tem por responsabilidade gerenciar, fornecer e manipular as informações junto ao banco de dados. Os métodos remotos são definidos no lado do servidor sendo que o cliente só dispõe das interfaces dos mesmos. Portanto, os métodos executaComando e atualizaLog citados anteriormente são implementados no lado do servidor. Para cada solicitação de comando SQL recebida pelo servidor este precisa acessar a base local disponível. O acesso é feito via API JDBC que promove a conexão de uma aplicação Java a uma base de dados. A figura 5, a seguir, mostra a seqüência do envio de mensagens para o método executaComando. Para cada acesso realizado ao serviço a aplicação faz uma nova conexão à base de dados. O método getConnection tem por objetivo atualizar as informações a respeito da base de dados que será utilizada. É feita a leitura de um arquivo texto o qual possui informações a respeito do driver, url, username e password. Esta facilidade foi inserida no intuito de propor ao usuário a utilização de qualquer tecnologia de base de dados no lado servidor desde que este possua os drivers de gerenciamento para tal. jdbc.driver=org.gjt.mm.mysql.Driver jdbc.url=jdbc:mysql://localhost/bancodadosexemplo jdbc.username=PUBLIC jdbc.password= Após a identificação das informações, quando uma classe Driver, reconhece sua URL, ela cria uma conexão de banco de dados utilizando as propriedades especificadas. Ela fornece a classe DriverManager uma implementação java.sql.Connection representando esta conexão de banco de dados. DriverManager retorna este objeto Connection para a implementação. Fig. 5. Conexão Servidor
  • 7. A partir do objeto Connection é criado um conjunto de procedimentos através de createStatement para que se possa fazer o direcionamento do comando SQL desejado. Por fim, o método executeQuery é responsável pela execução do comando desejado. É importante observar que para comandos do tipo SELECT o método retornará informações que serão encaminhadas ao lado cliente via serviço RMI. Para comandos de atualização que não geram informações de retorno para visualização, faz-se o retorno do status para gerenciamento das atividades. O lado servidor comporta-se como uma aplicação com uma base de dados local. Caso a base de dados não esteja disponível no momento, pelo fato do banco de dados não estar ativo, o serviço RMI deste servidor mantém um arquivo de log com as operações de atualização. Toda vez que for proposta alguma verificação ou atualização de informações no banco e existirem informações no arquivo de log este é automaticamente atualizado. Uma outra característica do lado servidor é que quando este ativado é feita uma procura nos logs disponíveis nos outros servidores se não existem atualizações a serem executadas para tanto é armazenado em arquivo as informações a respeito dos outros servidores. dbc.ip=200.132.78.158 jdbc.so=windows jdbc.ipRemoto1=200.132.78.146 jdbc.ipRemoto2=200.132.78.147 jdbc.ipRemoto3=end jdbc.soRemoto1=linux jdbc.soRemoto2=windows jdbc.soRemoto3=end 3.4. Falha de Serviço O grande problema a ser administrado pelo sistema é quando um determinado serviço não está disponível e comandos SQL de atualização são solicitados. Conforme mencionado na seção 3.2 o serviço local responsabiliza-se em detectar quais serviços não estão disponíveis enviando para os servidores ativos informações sobre os IPs com problemas bem como informando, também, os respectivos comandos SQL. Esta parte já está implementada e atende as necessidades previstas para o perfeito funcionamento do sistema. Também implementada está a atualização das informações quando um determinado serviço retorna ao perfeito funcionamento. É importante salientar que um servidor não pode prover informações até que venha a ser totalmente atualizado. A idéia é que o serviço ao retornar a funcionar envie solicitações aos outros servidores verificando se estes outros detém comandos em seus arquivos de logs. O pior caso é quando todos os outros servidores não fornecem o serviço. Neste caso o sistema deve interromper as suas atividades de atualização, fornecendo, apenas, informações sobre consultas, apresentando ao usuário que está atualizado até uma determinada data. Caso contrário cada servidor disponível retornará as informações que detém para atualizar a base em questão. Uma outra questão que pode a acontecer é a existência de duplicidades de informações nos arquivos de logs disponíveis. O gerenciamento desta etapa propõe o armazenamento no lado do servidor dos comandos já atualizados, com respectivas datas e horários de solicitação. Caso um servidor forneça as informações e outro esteja fora de
  • 8. serviço, e também contenha as informações, em uma próxima atualização estes comandos já estarão atualizados e serão descartados. Conclusões Os mecanismos de suporte ao serviço RMI permitem a conexão entre diversas aplicações Java em equipamentos diferentes exceto para aplicações Applets executadas dentro de um navegador. Levando em consideração tal restrição implementou-se um serviço local que propicia a comunicação com outros equipamentos. As implementações propostas até o momento demonstram a eficácia e aplicabilidade da distribuição dos serviços remotos. Unindo, portanto, os serviços remotos aos serviços disponíveis para bancos de dados foram demonstrados, neste trabalho, o gerenciamento distribuído das atividades de consulta e atualização a bases de dados. Preliminarmente, percebe-se que o estado atual do sistema atende aos requisitos no que se refere a consultas e atualizações. Com relação às atualizações, em caso de falha nos servidores, a implementação mantém atualizadas todas as bases disponíveis. Acredita-se que a validação da consistência lógica apresentada pelo sistema proposto será aumentada gradualmente com novos testes, portanto mais estudos de caso, envolvendo aplicações reais, estão sendo preparados para certificar o modelo. Trabalhos Futuros O objetivo deste trabalho foi demonstrar as características básicas de uma proposta para implementação de um sistema de banco de dados distribuído e replicado utilizando serviço RMI-Java, atualizado através de Applets Java. Alguns problemas ainda devem ser estudados. Com relação ao crescimento da rede são raros os estudos de desempenho de um SGBD distribuído. Faz-se importante detalhar a rede de comunicação observando o comportamento de protocolos de comunicação e de algoritmos à medida que os sistemas crescem. Referências Breitbar, Y; Silberschatz, A. ”Overview of Multidatabase Transaction Management”, The VLDB Journal, vol. 1, n. 2, pp. 181-239, 1992. Chung, C; Dataplex, C. “An Accesss to Heterogeneous Distributed Databases”, Comunications of the ACM, vol. 33, n. 1, pp. 70-80, Jan. 1990. Elmasri, R; Navathe, S. Fundamentals of Database Systems, Benjamin/Cummings, 2a. edição, 1994. Horstmann, C; Cornell G. Core Java 2: Volume II, Advanced Features. [S.l.]: Prentice Hall, 2001. Korth, H; Silberschatz, A, Sistema de Banco de Dados. Makron Books, São Paulo, 1995. Lima, J.C; Ribeiro C. Oliveira, “Acesso Integrado a Banco de Dados Distribuídos Heterogêneos utilizando CORBA” in Proc. 1997 XII Simpósio Brasileiro de Banco de Dados, Fortaleza, Brasil, pp.333-348. Niemeyer, P; Peck, J. Exploring Java, [S.l.]: O'Reilly & Associates, 1997. Özsu, M.T; Valduriez, P. Principles of Distributed Database Systems, Prentice Hall, 2a. edição, 1999. Ram, S. “Heterogeneous Distributed Database Systems”. Computer, v.24 , n.1, p.7-9, Dec. 1991. Reese, G. Programação para Banco de Dados. JDBC e Java, Ed. Bercley, São Paulo, 2000.