FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS
EDUAN LENINE DOS SANTOS NEVES
VISUAL DAAS:
UMA IDE PARA BANCO DE DADOS COMO SERVIÇO WEB
SÃO JOSÉ DOS CAMPOS
2009
ii
EDUAN LENINE DOS SANTOS NEVES
VISUAL DAAS:
UMA IDE PARA BANCO DE DADOS COMO SERVIÇO WEB
Trabalho de graduação apresentado à Faculdade
de Tecnologia de São José dos Campos, como
parte dos requisitos necessários para a obtenção
do título de Tecnólogo em Informática
Orientador: Giuliano Araujo Bertoti, Msc
SÃO JOSÉ DOS CAMPOS
2009
iii
EDUAN LENINE DOS SANTOS NEVES
VISUAL DAAS:
UMA IDE PARA BANCO DE DADOS COMO SERVIÇO WEB
Trabalho de graduação apresentado à Faculdade
de Tecnologia de São José dos Campos, como
parte dos requisitos necessários para a obtenção
do título de Tecnólogo em Informática
_____________________________________________________________
ÉRICA FERREIRA DE SOUZA, Graduada
_____________________________________________________________
EDUARDO SAKAUE, Msc
_____________________________________________________________
GIULIANO ARAUJO BERTOTI, Msc
___/___/___
DATA DE APROVAÇÃO
iv
Dedico esta obra primeiramente a Deus,
que me iluminou em todos os momentos.
E aos meus amigos
David Ribeiro, José Teles e William Antônio,
que me serviram como fonte de inspiração.
v
“O acaso é talvez, o pseudônimo que Deus usa
quando não quer assinar suas obras.”
T. Gauther
vi
RESUMO
Este trabalho tem por objetivo o desenvolvimento de uma ferramenta visual para criação,
manipulação e administração de banco de dados como serviço web. Discute-se primeiro a
crescente demanda por armazenamento de dados e o surgimento das dificuldades de se
implementar uma base de dados que comporte tal necessidade. Apresentam-se em seguida os
conceitos de banco de dados como serviço web e as vantagens de se utilizar esta solução. E por
fim é desenvolvido um protótipo da aplicação Visual DAAS, uma IDE para banco de dados como
serviço web. Conclui-se que com esta ferramenta será possível aproveitar todas as vantagens e
possibilidades que o banco de dados como serviço web pode prover.
Palavras-Chave: Banco de Dados, Software como serviço Web, Ambiente de desenvolvimento
integrado.
vii
ABSTRACT
This work aims to create a visual tool for designing, manipulating and management
database as a service. Descute first to the growing demand for data storage and the emergence
of the difficulty of implementing a database comprising such a need. Apresent then the concepts
of database as a service and the advantages of using this solution. And finally it developed a
prototype of the Visual DAAS, an IDE for database as a service. Conclude that with this tool will
be possible to enjoy all the benefits and possibilities that the database as a service can provide.
Keywords: Database, Software as a Service, Integrated Development Environment.
viii
SUMÁRIO
1
INTRODUÇÃO ...................................................................................................... 10
1.1
Motivação ................................................................................................................. 10
1.2
Objetivos................................................................................................................... 10
1.2.1
Objetivo Geral .......................................................................................................... 11
1.2.2
Objetivos Específicos ............................................................................................... 11
1.3
Metodologia .............................................................................................................. 11
1.4
Organização do Trabalho.......................................................................................... 12
2
BANCO DE DADOS COMO SERVIÇO WEB ................................................... 13
2.1
Banco de Dados ........................................................................................................ 13
2.1.1
Banco de Dados Hierárquico .................................................................................... 14
2.1.2
Banco de Dados em Rede ......................................................................................... 15
2.1.3
Banco de Dados Relacional ...................................................................................... 16
2.2
Manipulação do Banco de Dados ............................................................................. 18
2.3
Sistemas Distribuídos ............................................................................................... 19
2.3.1
Arquitetura de um sistema distribuído ..................................................................... 19
2.4
Serviços Web (Web Services) ................................................................................... 20
2.4.1
Software como um serviço ....................................................................................... 20
2.4.2
Definição .................................................................................................................. 21
2.4.3
Objetivos................................................................................................................... 22
2.4.4
WSDL ....................................................................................................................... 22
2.4.5
XML ......................................................................................................................... 23
2.4.6
Arquitetura e Protocolos de Comunicação. .............................................................. 24
2.5
Banco de dados como Serviço Web ......................................................................... 27
2.5.1
Por que Banco de dados com Serviço web? ............................................................. 27
2.5.2
Desafios do DAAS ................................................................................................... 28
2.6
Considerações Finais ................................................................................................ 29
3
SOLUÇÕES EXISTENTES .................................................................................. 30
3.1
SimpleDB + AmazonS3 ........................................................................................... 30
9
3.1.1
Amazon S3 ............................................................................................................... 31
3.1.1.1
Funcionamento ......................................................................................................... 31
3.1.2
SimpleDB ................................................................................................................. 35
3.2
CouchDB .................................................................................................................. 37
3.2.1
Funcionamento ......................................................................................................... 39
3.3
Caso de Uso .............................................................................................................. 41
3.4
Considerações Finais ................................................................................................ 43
4
VISUAL DAAS: UMA IDE PARA BANCO DE DADOS COMO SERVIÇO
WEB
.................................................................................................................................. 45
4.1
Arquitetura da Visual DAAS.................................................................................... 45
4.2
Funcionamento da BigTable como Serviço Web ..................................................... 47
4.3
Funcionalidades do Sistema ..................................................................................... 48
4.4
Requisitos do Sistema............................................................................................... 49
4.5
Dicionário de Dados ................................................................................................. 50
4.6
Arquitetura Orientada a Objetos ............................................................................... 52
4.7
Interface com o Usuário ........................................................................................... 56
4.8
Considerações finais ................................................................................................. 60
5
CONSIDERAÇÕES FINAIS ................................................................................. 61
5.1
Contribuições e Conclusões...................................................................................... 61
5.1.1
Publicação ................................................................................................................. 62
5.2
Trabalhos Futuros ..................................................................................................... 62
REFERÊNCIAS ........................................................................................................................ 63
APÊNDICE A - Artigo publicado no XI Simpósio de Iniciação Científica e Tecnológica ...... 67
10
1
INTRODUÇÃO
1.1
Motivação
O aumento da demanda por recursos de armazenamentos de dados tornou-se
comum em qualquer ambiente profissional, acadêmico ou científico. O uso deste recurso requer
muito esforços e gastos na sua implementação, administração e manutenção (Hacigumus, 2009).
Com o advento da Internet, o paradigma “Software como serviço” (Software as a Service,
aplicações hospedadas em um servidor, que as disponibilizam via rede ou Internet) começaram a
surgir, substituindo alguns paradigmas da utilização de Software (O'Reilly, 2005). Do mesmo
modo o Banco de Dados como serviço Web (do inglês Database as a Service, DaaS) surgiu para
sanar as dificuldades na utilização deste recurso fundamental (Hacigumus, 2009).
Esta solução trás muitas vantagens em relação aos paradigmas de programação
anteriores. Por exemplo, as organizações que adotam este tipo de serviço deixam de se preocupar
com a compra de equipamentos para manter uma aplicação proprietária, economizam tempo no
desenvolvimento da sua solução, tem todas as vantagens que um provedor de software como
serviço web fornece como escalabilidade, segurança da informação, além de não ter de lidar com
manutenção e um grande número de treinamentos necessários para o desenvolvimento de um
software proprietário (Finch, 2006). Com isso, concentram-se esforços na solução do negócio,
pagando apenas pela demanda de uso da solução (Ravi et al, 2004).
1.2
Objetivos
A seguir serão apresentados os objetivos gerais e específicos deste trabalho.
11
1.2.1
Objetivo Geral
O objetivo deste trabalho é desenvolver uma IDE, Ambiente de Desenvolvimento
Integrado (do inglês Integrated Development Environment) para criação, manipulação e
administração de banco de dados como serviço web, aproveitando algumas tecnologias
existentes.
1.2.2
Objetivos Específicos
Os objetivos específicos deste trabalho são:
a) Definir uma arquitetura para um ambiente integrador de desenvolvimento para
banco de dados como serviço web.
b) Desenvolver uma engine para simplificar, administrar e controlar um
repositório de dados na web.
c) Desenvolver uma interface gráfica para simplificar o uso da ferramenta final.
1.3
Metodologia
A metodologia aplicada aqui consiste na pesquisa por formas de desenvolvimento
que se apliquem a um ambiente de desenvolvimento integrado e adapte-se as necessidades deste
novo paradigma. Esta ferramenta deverá sanar as falhas dos sistemas atuais e disponibilizar de
forma clara a tecnologia do banco de dados como serviço web, para desenvolvedores que não se
adaptaram ainda a este paradigma.
12
1.4
Organização do Trabalho
Os capítulos deste trabalho estão divididos da seguinte forma:
a) Capítulo 2 – Apresenta todos os fundamentos e conceitos que compõe a
tecnologia do banco de dados como serviço web.
b) Capítulo 3 – Apresenta as soluções de banco de dados como serviço web
disponibilizadas pela Apache e a Amazon, com exemplos de utilização.
c) Capítulo 4 – Apresenta o desenvolvimento do ambiente de desenvolvimento
integrado Visual DAAS.
d) Capítulo 5 – Apresenta as conclusões deste trabalho.
13
2
BANCO DE DADOS COMO SERVIÇO WEB
O objetivo deste capítulo é apresentar os conceitos de Banco de Dados, Serviços
Web e o conceito de Banco de Dados como Serviço Web.
As seções estão organizadas da seguinte forma: a seção 2.1 apresenta o que é
Banco de Dados, como funciona e quais os tipos de Bancos de Dados existentes e sua principal
linguagem de manipulação, a seção 2.2 explica o que é um Web Service e por último a seção 2.3
apresenta uma explicação dos conceitos de Banco de Dados como Serviço Web.
2.1
Banco de Dados
O conceito de banco de dados surgiu, junto com a idéia do armazenamento de
dados de forma organizada, para que os dados armazenados em uma base pudessem ser
recuperados e manipulados de forma fácil e ágil. Nada mais é do que uma coleção de dados
arranjados em uma estrutura lógica, na qual usa-se uma linguagem de pesquisa para se manipular
os dados. A partir disto o banco de dados tem revolucionado a maneira como temos acesso à
informação. A cada dia que passa nos tornamos cada vez mais dependentes desta tecnologia, que
está presente em todos os tipos de situações (Ravi et al, 2004).
É utilizado por aplicações ou por pessoas, que necessitam de um armazenamento
de informações e que as disponibilize para futuras consultas em sua base de dados. Geralmente
um banco de dados possui um gerenciador, o SGDB ( Sistema Gerenciador de Banco de Dados )
que auxilia na tarefa de administração deste recurso e seu conteúdo. Este software tem muitos
objetivos, desde controle de acesso à base de dados até a consistência dos dados mantidos nela
(Date, 2004).
14
A consistência dos dados mantidos em uma base é extremamente importante. Só
assim é que o objetivo principal de um banco de dados torna-se possível, logo é preciso que seu
gerenciador seja capaz de controlar os acessos dos usuários, que retiram e inserem dados, à base,
para que esta transação não gere conflitos e inutilize os registros do banco.
Para um melhor entendimento as próximas subseções irão abordar os tipos de
bancos de dados e suas características de funcionamento.
2.1.1
Banco de Dados Hierárquico
O modelo hierárquico utiliza-se da estrutura de dados Árvore para organizar seus
registros internos, onde cada dado só tem um registro pai, formando assim uma hierarquia,
podendo ter dentro dele várias hierarquias definindo os dados quem contém o banco. Este modelo
atualmente está em desuso, pois possui uma grande desvantagem em sua estrutura relacionada à
extração e inserção de dados. Em primeiro lugar ele é somente rápido quando se faz uma
pesquisa em somente uma hierarquia, para fazer uma pesquisa que relacione mais de uma
hierarquia ele deve percorrer a atual até o dado solicitado e voltar até a raiz e começar do zero na
outra hierarquia relacionada (Silberschatz, A. 2006).
Resumindo, apresenta problemas quando representa relacionamentos nãohierárquicos. Para ilustrar o banco e sua desvantagem vamos ao seguinte exemplo ilustrado na
Figura 2.1. Supõe-se a seguinte situação: o usuário faz uma consulta esperando obter o endereço
do SUPERVISOR de determinado DEPARTAMENTO. O sistema gerenciador do banco de
dados deverá percorrer o seguinte caminho, primeiro ele irá da raiz à entidade
DEPARTAMENTOS buscará pelo departamento solicitado, buscará na entidade abaixo
SUPERVISÃO armazenará o EMP_ID (identificação do empregado), voltará à raiz, irá à tabela
EMPREGADOS, buscará o empregado com o EMP_ID solicitado e irá, enfim, mais abaixo na
entidade endereço que está relacionado a aquele registro de empregado (Silberschatz, A. 2006).
15
Ainda que seja visível sua restrição, este modelo de banco de dado fora muito
utilizado nos primeiros sistemas de gestão de base de dados em mainframe.
Figura 2.1: Exemplo de um modelo de banco de dados hierárquico (Silberschatz, A. 2006).
2.1.2
Banco de Dados em Rede
No banco de dados em redes os registros são armazenados como uma coleção de
dados conectados uns ao outros por meio de um link e cada registro é uma coleção de atributos
com um valor único. Cada link liga somente dois registros. Isto significa que o modelo de dados
em rede somente fornece relacionamento binário entre os seus dados. Portanto o índice de
duplicação de dados, para suprir outros tipos de relacionamentos, neste modelo, é muito alto
(Silberschatz, A. 2006).
A Figura 2.2 mostra um modelo de banco de dados em rede.
16
Figura 2.2: Modelo de Dados em redes e seus relacionamentos (Silberschatz, A. 2006).
2.1.3
Banco de Dados Relacional
A estrutura do banco de dados relacional é atualmente o modelo mais utilizado de
banco de dados, seus dados são estruturados em tabelas simples, contendo linhas e colunas que
representam seus registros, essas tabelas devem satisfazer o conceito de integridade especificado
pelo criador do modelo Edgar F. Codd. A manipulação dessas tabelas é feita por operadores
originários de outras tabelas e dentro destes operadores são destacadas as três mais importantes
operações possíveis com eles:
a) Restrição: capaz de extrair linhas de uma tabela dado uma especificação;
b) Projeção: com a mesma função, mas em sentido diferente, esta operação
especifica uma coluna a ser extraída de uma tabela;
c) Junção: como o próprio nome indica esta operação une dois conteúdos de uma
tabela com base em valores comuns de uma coluna em ambas as tabelas.
17
A Figura 2.3 um exemplo de funcionamento destas operações:
Figura 2.3: Exemplo de tabelas de um modelo de banco de dados relacional (Date, C.J.
2004)
O modelo relacional é baseado na teoria de conjuntos e lógica de predicados em
matemática, assumindo assim algumas características destes conceitos. O termo relação é a
designação de uma tabela de um tipo específico em matemática, assim, seguindo o exemplo da
Figura 2.3, pode-se concluir que no banco de dados de produtos e tipos de produtos têm-se duas
relações (Date, 2004).
O modelo foi desenvolvido em 1969-70 com E. F. Codd, pela IBM em San Jose EUA. Desde a implantação do SGBDR (Sistema de Gerenciamento de Banco de Dados
Relacionais) até hoje o modelo tem sido melhorado (Date, 2004).
18
2.2
Manipulação do Banco de Dados
A manipulação de um Banco e de seus dados é feita por uma linguagem. As
requisições feitas por esta linguagem podem ser realizadas por um software intermediário ou
diretamente pelo usuário no SGDB. A mais comum é a SQL Linguagem de Consulta Estruturada
(do inglês Structured Query Language). Softwares intermediários possuem comandos em SQL
pré-programados, portanto o usuário final não tem conhecimento destes, mas se é um usuário que
deseja atingir diretamente a base necessita de um conhecimento da linguagem.
Uma linguagem de programação possui diversas características e uma delas é a
proximidade que ela tem com a linguagem humana, que é classificada de duas maneiras, de
Baixo Nível: Linguagem complexa muito próxima da linguagem de computador. Alto Nível
linguagem com uma grande semelhança à da escrita humana.
A Sql é classificada como de Alto nível, pois seus comandos são muitos parecidos
com a escrita humana e bem distante do que realmente as máquinas interpretam. Alguns
exemplos de comandos:
a) Select: operador de consulta, com ele pode-se iniciar uma pesquisa que retorne
n-colunas de n-tabelas;
b) From: indica onde a pesquisa será feita, quais tabelas serão usadas, seguido
dos nomes das tabelas;
c) Where: filtrar uma consulta, em número de linhas, aplica-se condições de
pesquisa com esta cláusula, seguida das condições a serem aplicadas;
Assim como o modelo relacional de banco de dados, a linguagem SQL foi
desenvolvida tendo como base de apoio a IBM Research no início da década de 70 e foi
19
implementado em um banco experimental chamado System R e posteriormente implementada em
muitos outros bancos.
Por ser muito utilizada esta linguagem sofreu atualizações e melhorias. Foi
padronizada pela ANSI (American National Standards Institute), portanto a forma de se
programar nela pode variar dependendo do padrão adotado pelo banco utilizado (Date, 2004).
2.3
Sistemas Distribuídos
Como o próprio nome indica é um sistema dividido em pequenos softwares que
juntos podem completar uma tarefa complexa. Esta opção de sistema é muito utilizada quando
uma parte da aplicação a ser desenvolvida já existe como um serviço web, assim pode-se utilizar
os recursos fornecidos por estes serviços e eliminar uma grande quantidade de tempo perdida
para desenvolver uma parte do sistema que já existia. (Tanenbaum, A, 2002)
Há um problema neste tipo de aplicação, como os sistemas não rodam em uma
mesma máquina e se comunicam pela Internet ou rede, significa que estará muito suscetível à
falhas e lentidão em seu funcionamento, dependendo muito do tipo de qualidade em que o
serviço é fornecido. (Tanenbaum, A, 2002)
2.3.1
Arquitetura de um sistema distribuído
Um sistema distribuído requer uma arquitetura que seja capaz de suprir essas
dificuldades que surgem ao implantar um sistema distribuído, como latência e desconfiança do
transporte das informações, a concorrência de acesso a recursos do sistema, a dificuldade de
atualização de sistemas por motivo de incompatibilidade entre os softwares distribuídos, entre
outros.
20
Para isso foi desenvolvido um paradigma arquitetural: SOA (Service Oriented
Architecture) Arquitetura orientada a serviço muito utilizada para aplicações distribuídas por dar
suporte a algumas dessas dificuldades encontradas ao se aplicar um sistema distribuído.
Esta arquitetura padroniza a forma como um sistema distribuído deve funcionar,
dividindo esta interação em basicamente em três processos, o da busca pelos recursos
disponibilizados, a consolidação e confirmação do recurso requisitado, e por fim a execução do
recurso disponibilizado por um Web Service (Erl, T 2005)
2.4
Serviços Web (Web Services)
A seguir a definição de Web Service, sua arquitetura, características e vantagens
desta solução.
2.4.1
Software como um serviço
Software como um serviço (Software as a Service – SaaS), é um novo paradigma
na utilização de software. Nesta solução em alguns casos você paga pelo o que usa e não pela
propriedade, em outros casos este modelo é utilizado internamente em grandes corporações onde
há uma diversidade de softwares desenvolvidos em linguagens diferentes, mas necessitam de um
mesmo recurso.
É um modelo de distribuição de software, o qual as aplicações ficam hospedadas
em um servidor e são disponibilizadas pela rede.
Esta tecnologia de serviço tem muitas vantagens, algumas delas são:
a) Escalabilidade, capacidade de atender a todos os requisitantes;
21
b) Evita gastos com personalização e implementação;
c) Economia de tempo;
d) Dispensa a compra de equipamentos para manter a aplicação (Hardware, InfraEstrutura);
e) Não ter de lidar com manutenção;
f) Diminuir o número de treinamentos, necessários para o desenvolvimento de
um software proprietário.
Sendo necessário apenas a personalizar o serviço fornecido de acordo com a
necessidade do contratante e ter o treinamento básico para lidar com a aplicação (Miller, 2009).
2.4.2
Definição
Um Web Service (ou Serviço Web) é um software, hospedado em um servidor, que
provê alguma funcionalidade útil para algum outro software, independente de em que linguagem
fora desenvolvido este outro software e o próprio Web Service (En. W3C 2009).
A comunicação entre o Web Service e softwares que o utilizam é feita através de
uma rede, na maioria das vezes a Internet. Para que haja a capacidade de comunicação, necessitase de um conhecimento em comum entre estes dois softwares, no caso um protocolo de
comunicação é admitido e padronizado para que isso seja possível.
Um arquivo WSDL (Web Service Definition Language) define exatamente as
funcionalidades de dado Web Service. Normalmente este arquivo é escrito em XML (Extensible
Markup Language), um padrão de linguagem escolhido pela W3C (World Wide Web
22
Consortium, comunidade internacional, a qual suas organizações membros são dedicadas ao
desenvolvimento de normas e padrões Web) para realizar esta interpretação universal (W3C,
2001).
2.4.3
Objetivos
O objetivo desta tecnologia é possibilitar a interoperabilidade entre sistema de
base programática diferente. Um software feito com uma linguagem que tenha suporte às
tecnologias utilizadas por Web Service pode facilmente passar a utilizar os recursos de um ou até
mesmo passar a prover Web Services.
Com exemplo uma empresa que faz suas vendas via comércio eletrônico, pode
facilmente solicitar um serviço web completo, que suporte este tipo de aplicação, sendo
necessário apenas ter os conhecimentos de como utilizar esta tecnologia e usufruir dos seus
benefícios. Evitando assim gastos com desenvolvimento de aplicações próprias refazendo aquilo
que já está feito com qualidade, segurança, agilidade e competência, que são umas das
características de empresas que fornecem este tipo de serviço, pois afinal de contas o negócio
principal desses fornecedores de serviços web são os negócios de seus próprios clientes .
2.4.4
WSDL
Linguagem de descrição de um Serviço Web (do inglês Web Services Description
Language) é um documento que descreve onde e como suas funcionalidades estão definidas. Este
recurso é necessário para que um Web Service seja entendido tanto pela máquina, quanto pelo
homem que necessita para programar um agente requisitante.
É dividido de dois conceitos o abstrato e o concreto: Abstrato descreve o padrão
em que as mensagens trocadas no Web Service devem estar. Este padrão de mensagens é descrito
23
em um documento, o mais usado para esta funcionalidade é o XML Schema (no formato de
arquivo .xsd). No Concreto o WSDL descreve como será feita a transação destas mensagens, que
meio e que endereço estão localizados certos componentes de um Web Service (W3C).
2.4.5
XML
Esta é uma das razões da existência de Web Services e Sistemas Distribuídos, pois
facilita a comunicação entre sistemas e sem ela essa interoperabilidade seria muito difícil e cara
de ser implementada.
XML (Extensible Markup Language) é a linguagem de marcação utilizada para
troca de mensagens. Seu conteúdo é todo definido dentro de tags pré-definidas pelo autor do
documento, a sintaxe desta linguagem é bem simples e a estrutura interna de um documento
XML é baseada no conceito de árvore, a qual um elemento pode ter vários filhos e um filho
possui somente um pai. É recomendado pela W3C. Um exemplo de Arquivo na Figura 2.5:
Figura 2.4: Aparência de um documento XML (W3School)
O arquivo xml utilizado em um Web Service pode conter a descrição, o
armazenamento e o formato da transmissão utilizada na troca de dados (W3Schools).
O Web Service é dividido em duas partes funcionais:
24
a) Agentes: parte concreta de um Web Service, que enquanto está funcionando, os
agentes tem a tarefa básica de enviar e receber mensagens, que são trocadas na
interação entre os softwares requisitantes e o Web Service;
b) Serviços: é um recurso abstrato de um Web Service, pode-se resumir que um
serviço é uma das funções que um Web Service provê (W3C).
Para que um Web Service seja útil e faça algum sentido é necessário alguém que
pratique alguma ação dentro e fora deste sistema e para isso tem-se dois atores: o Requisitante e o
Provedor.
a) Requisitante: este ator ou entidade é responsável por solicitar o serviço de um
Provedor, geralmente é o requisitante que inicia a troca de mensagens que
contém as solicitações e respostas;
b) Provedor: é o agente que contém o serviço a ser disponibilizado, caracteriza-se
por receber uma solicitação e enviar uma resposta ao requisitante (W3C).
Um Web Service deve possuir uma semântica na descrição de suas
funcionalidades. Para se obter uma semântica desejável utiliza-se uma linguagem de marcação
que torne as funcionalidades de um Web Service legível por outra máquina, tornando possível
assim a comunicação entre os requisitantes e provedores do serviço.
2.4.6
Arquitetura e Protocolos de Comunicação.
Para que troca de mensagens, no contexto do Web Services seja possível, existe
um padrão de comunicação o SOAP (Simple Object Access Protocol) (W3C, 2007).
25
Na prática um Web Service possui diversos métodos disponíveis para uma dada
aplicação, para se utilizar estes recurso tem-se o auxílio deste protocolo. A invocação remota de
um método é armazenada em um arquivo XML, que contém o endereço do Web Service, o nome
do método a se utilizar e os argumentos necessários, caso a resposta deste método seja baseada
nos parâmetros passados. Este arquivo é enviado via HTTP para o servidor do Web Service
HTTP (Hypertext Transfer Protocol), outro protocolo padrão para quem utiliza a
Internet, pois através dele as páginas de web são requisitadas e transportadas (W3C).
Na Figura 2.5, uma breve descrição do funcionamento de um Web Service SOAP.
Figura 2.5: Ciclo básico de funcionamento de um Web Service SOAP.
Voltando ao SOAP, esta tecnologia não define nenhuma semântica, quer seja a
aplicação em que se aplica ou modelo de programação. Esta característica torna-o uma
ferramenta que pode ser utilizada em qualquer tipo de aplicação desenvolvida. Devida esta
flexibilidade tornou-se uma das principais normas para troca de mensagens em Web Services.
Além desta vantagem o SOAP é um protocolo de RPC (Remote Procedure Calls) que funciona
sobre HTTP (ou SMTP, ou outro) isto significa que suas mensagens serão transportadas
independentes de normas de seguranças impostas por firewalls que normalmente são utilizadas
em sistemas de RPC.
26
Funciona da seguinte maneira, ao invés do protocolo HTTP requisitar uma página
para ser visualizada em um navegador, o SOAP envia seus arquivos e recebe uma resposta, caso
haja, através do mesmo caminho em que foi enviada solicitação (W3C).
Outra alternativa é a utilização da arquitetura REST, Transferência de Estado
Representacional (do inglês Representational State Transfer), esta técnica segue o mesmo
princípio utilizado pelo SOAP, o qual há um requisitante e é esperado uma resposta, neste caso as
solicitações são efetuadas através de url e é também por onde os parâmetros são enviados. A
resposta pode retornar um arquivo contendo o resultado do processamento. Na Figura 2.6, o ciclo
de funcionamento de um Web Service REST.
Figura 2.6: Ciclo de um Web Service REST
REST aproveita de forma simples a utilização dos métodos nativos do protocolo
HTTP, são eles POST, GET, PUT ou DELETE, cada um com uma funcionalidade específica,
sendo que GET é o mais comum ser utilizado pelo REST.
27
2.5
Banco de dados como Serviço Web
Após a definição de Banco de dados e Software como serviço web, pode-se definir
Banco de dados como Serviço Web (do inglês Database as a service, DaaS), resume-se na
disponibilização de um banco de dados e todas suas funcionalidades por meio de um Web
Service, assumindo as características de um sistema distribuido, o qual o banco de dados, que
antes era parte integrada do sistema, passa a se caracterizar por um nó deste, independente do
resto da aplicação.
A comunicação com a base que antes era feita diretamente por comandos
executados pela aplicação sobre o banco, passa a ser encapsulada em uma mensagem, que
enviada através de um protocolo de comunicação, de um cliente à um web service, tendo como
resposta outra mensagem encapsulada e enviada por este mesmo protoloco. Porém agora não é
necessário lidar com a melhora do desempenho do banco, para atender uma grande demanda,
pois uma das característica básica de um sistema como serviço web é prover as funcionalidades
com a capacidade de atender qualquer demanda solicitada (Escalabilidade). Nem tampouco lidar
com problemas que poderiam surgir caso a base de dados sofresse alguma atualização no seu
software, pois a interface da aplicação com a base de dados será a mesma independente da versão
do software que prove os serviço.
2.5.1
Por que Banco de dados com Serviço web?
Como foi abordada na seção 1.1 a implementação de modelos de banco de dados
tradicionais trás custos operacionais indesejáveis pelas organizações, os gastos vão de compra de
equipamentos a contratação de profissionais do ramo destinado a realizar tarefas simples, mas de
grande valia.
28
Mesmo com todo este aparato ainda surgem alguns problemas com este antigo
paradigma, seria muito difícil com alguns profissionais manter a escalabilidade de um sistema de
banco de dados e na atualização de um banco para uma versão mais atual poderiam surgir
diversos problemas de incompatibilidade.
Um serviço web de banco de dados costuma ter suporte a todas estas necessidades
e serem capazes de solucionar estes problemas que encontramos ao nos depararmos com estes
modelos antigos. Com um custo muito menor e podendo até ser de graça, caso grandes
organizações como a Google adaptem suas ferramentas para uso público.
2.5.2
Desafios do DAAS
O que todos se perguntam Após compreender o conceito de DAAS é “E a
privacidade dos dados?”. Realmente é necessário segurança sobre os dados armazenados e
durante uma transação de informações.
Para solucionar estes problemas provedores de DAAS estão preparados com regras
de segurança, como a encriptação de todos os dados sob seu controle e torna isso uma das
questões mais importantes de seus sistemas, pois os dados de seus clientes são de extrema
importância e valiosos. Os níveis de encriptação podem variar de um grupo de dados a um único
registro de uma dada estrutura de dados.
E esta encriptação pode ser realizada no software que disponibiliza a aplicação
Web Service ou no hardware que a mantém.
Na camada software a encriptação pode ficar a cargo de algoritmos de confiança
como RSA e BlowFish, que foram testados por um banco de dados como serviço web da IBM, o
NetDB2, para a aplicação o algoritmo BlowFish saiu-se melhor nestes testes levando em conta a
sua velocidade, simplicidade e sua eficiência.
29
Para a utilização desta ferramenta é disponibilizada uma função de encriptação e é
fornecida ao usuário uma chave para desencriptar seus dados. Esta função e chave podem ser
usadas diretamente nas operações feitas pelo usuário em suas consultas (do inglês querys) (H.
Hacigumus 2002, IBM).
2.6
Considerações Finais
Neste capítulo introduzimos os conceitos base para o entendimento de uma
aplicação Database as a Service. Foram abordados os conceitos de banco de dados, aplicação
distribuídas, Web Services e finalmente a teoria de banco de dados como serviço web.
No próximo capítulo serão apresentadas soluções existentes e suas características
em comuns e as diferenças entre elas e um caso de uso de um banco de dados como serviço web
utilizado pelo site de fotografias Twitpic.
30
3
SOLUÇÕES EXISTENTES
Os DAAS são disponibilizados pela Internet. Como não existe muito Web Services
deste tipo, a maioria dos que existem são pagos. Para utilizar um DAAS deve-se recordar toda
base que foi explicada anteriormente mais uma linguagem de programação que fará todo o papel
de cliente requisitante.
As seções estão organizadas na seguinte forma: seção 3.1 Apresenta a solução
proposta pela Amazon que soma as
vantagens
de dois
Web Services
robustos,
SimpleDB+AmazonS3, para uma aplicação completa de banco de dados como serviço, a seção 3.2
que mostra uma opção gratuita desenvolvida pela Apache CouchDB e por ultimo 3.3 seção
destinada a um caso de uso que utiliza uma solução existente, Twitpic.
3.1
SimpleDB + AmazonS3
A Amazon.com, corporação tradicional de e-commerce, viu na tecnologia
“Software as a Service” um grande mercado e começou a investir fortemente no desenvolvimento
deste tipo de aplicação. (Amazon.com, 2006)
SimpleDB é um exemplo de Web Service, desenvolvido pela Amazon, que
interage com o Amazon S3 e através de suas funções de indexação e consulta formam um
provedor de DAAS.
O Amazon S3 (Amazon Simple Storage Service) possui funções para
armazenamento enquanto o SimpleDB lida com a manipulação dos dados. Este conjunto de
ferramentas tem como foco a excelência em escalabilidade. Provê uma simples interface Web
31
Service, que pode ser utilizada para armazenar e retirar dados em qualquer quantidade, hora e
lugar da web.
3.1.1
Amazon S3
Desenvolvido para escrever, ler e apagar objetos de um a 5 gigabytes cada. E o
número de objetos que se pode armazenar é ilimitado.
Cada objeto é armazenado em bucket, repositório de dados, e recuperado, via uma
única chave de acesso.
Um bucket pode estar alocado nos Estados Unidos ou na Europa. Todos os dados
serão armazenados nesses bucket’s, mas poderão ser acessados de qualquer lugar.
O mecanismo de autenticação garante a segurança dos dados de acessos não
autorizados. Mas se desejar que o acesso a algum objeto seja público, basta especificar o objeto
com modificadores de acesso.
3.1.1.1
Funcionamento
Neste exemplo será abordada a API SOAP para utilizar alguns recursos do
Amazon S3 como a criação de um bucket e a Inserção de um dado dentro dele.
Para utilizar as funcionalidades do produto Amazon ele disponibiliza um arquivo
Wsdl
que
as
descreve,
para
uma
máquina
interpretar,
acessível
no
endereço
http://doc.s3.amazonaws.com/2006-03-01/AmazonS3.wsdl. Para validar o conteúdo dos Xml
32
gerado pelo cliente ela disponibiliza um XSD no link http://doc.s3.amazonaws.com/2006-0301/AmazonS3.xsd.
Existem dados comuns que serão trafegados em todas as transações, estes são:
a) AWSAccessKeyId: A Chave de Acesso para uma requisição AWS;
b) Timestamp: Tempo atual do Sistema;
c) Signature: Assinatura para Requisição.
Na Figura 3.1, segue um exemplo de solicitação:
Figura 3.1: Exemplo de solicitação para criação de um Bucket
Este exemplo é uma requisição para a criação de um bucket com os dados
completos, nome do bucket 'repositorio', note que na terceira chave, 'Acl', do contexto o conteúdo
'private' especifica o acesso ao recurso sendo privado para acesso somente a quem o criador deste
permitir acessar. Ao enviar esta requisição, é esperada a resposta ilustrada na Figura 3.2.
Feito a criação de um local de armazenamento, o próximo passo é armazenar um
dado utilizando este espaço.
33
Figura 3.2: Exemplo de solicitação para criação de um Bucket
PutObjectInline - Esta operação adiciona um objeto em um dado bucket. Os dados
deste objeto devem estar contidos no corpo de uma mensagem SOAP. Caso ocorra de o objeto já
existir, o novo objeto irá sobrescrever o objeto antigo, isso porque o Amazon S3 armazena a
ultima requisição de escrita. Como já visto, Amazon S3 é um sistema distribuído. Se receber
muitas requisições ao mesmo tempo, para um mesmo objeto, irá escrever todos simultaneamente,
todos serão armazenados, mas somente um ficará no final. Amazon S3 não prove lock por objeto;
se você precisar deve desenvolver uma camada de aplicação para isto.
Para ter certeza de que o objeto não foi corrompido em toda sua viajem, você pode
calcular o MD5 (Message-Digest algorithm 5, algoritmo utilizados na verificação de arquivos)
deste objeto, depositar o resultado no Amazon S3 e comparar com o MD5 do objeto a ser
conferido armazenado no repositório.
Este método é limitado a trabalhar com objetos de no máximo 1mb, se utilizá-lo
para maiores fins, receberá uma resposta indicando o seguinte erro: InlineDataTooLargeError
indicando que passou do limite proposto, para armazenar objetos maiores a API do Amazon S3
disponibiliza o método não-linear PutObject.
No exemplo da Figura 3.3, tem-se a inserção de um texto e um meta-dado
inserindo objeto 'Teste' dentro do bucket 'repositorio', dado um usuário e FULL_CONTROL
(controle completo) para acesso ao objeto por requisições anônimas:
a) Bucket: local onde será inserido o objeto;
34
b) Key: a chave da assinatura do objeto;
c) Metadata: Podem-se atribuir valores que identificam o objeto no sistema para
a fácil identificação daquele objeto futuramente;
d) Data: Dado codificado na Base64;
Figura 3.3: Exemplo de documento xml para inserção de um objeto em um Bucket
e) ContentLength: Tamanho do dado em bytes;
f) AccessControlList: Uma lista de controle de acesso para o recurso. É opcional
se for omitido o valor associado ao controle será de FULL_CONTROL, acesso
35
completo ao objeto. Se o objeto já existe, o controle de acesso anterior é
substituído pelo novo.
3.1.2
SimpleDB
A utilização do Amazon S3 crua não traz muitos benefícios para o usuário, além
da escalabilidade, pois os dados não são nada mais além do que armazenados e retirados de forma
bruta para isso desenvolveram o SimpleDB, que contém diversas funcionalidades para manipular
esses dados armazenados como indexação e consultas. Estes serviços em conjunto com o
Amazon S3 possibilitam a escalabilidade web com mais custo benefício aos desenvolvedores.
Diferente do modelo tradicional banco de dados relacional, que necessitavam de
gastos consideráveis em relação à clusterização, desenvolvimento da base e posteriormente
requeria um DBA para administrar e dar manutenção ao sistema. Amazon SimpleDB é muito
simples não requer esquema, automaticamente indexa seus dados e provê uma API simples para o
acesso armazenamento dos dados.
Esta aplicação diminui gastos administrativos com modelagem, manutenção de
index e melhora do desempenho.
SimpleDB é um Web Service simples que provê as funcionalidades de criação de
data sets, consulta a seus dados e retorno dos resultados
Organizam-se os dados em estruturas dentro de domínios e podem-se executar
consultas através de toda estrutura de dados armazenada em um domínio particular. Domínios
são preenchidos por itens, e itens são descritos por valores e atributos. Para entender estes
elementos, considere-os uma variação de uma tabela. Um domínio é como uma planilha, itens são
como linhas de dados, atributos são como colunas e os valores são os dados inseridos em cada
célula.
36
Mas diferente de uma tabela, vários valores podem ser associados a cada célula.
Por exemplo, para um item “calça” pode conter ambos os valores “azul” e “branca” para o
atributo cor. Resumindo cada item pode ter sua própria configuração de atributos, como no
exemplo da Figura 3.4.
Tabela 3.1: Exemplo de um domínio
Criar um domínio para guardar sua estrutura de configuração única de dados.
Métodos GET, PUT ou DELETE são utilizados para manipulação dos itens nos domínios criados,
associando cada item a seus atributos e valores. Cada item pode ter até 256 atributos diferentes e
para cada atributos valores de 1 a 1024 bytes.
Para consulta aos dados usa-se as Apis Select e Query e simples operadores de
condição : =, !=, <, > <=, >=, STARTS-WITH, AND, OR, NOT, INTERSECTION e UNION
entre outros operadores de funções aleatórias como de organização.
Um exemplo de consulta que se pode ser feita é a seguinte:
select * from meuDominio where atribuo = 'valor'
Nesta solução você só paga por aquilo que utiliza (Amazon SimpleDB).
37
3.2
CouchDB
É um banco dados como serviço que foi desenvolvido pela Apache, orientado a
documentos, suas funcionalidades são acessíveis via protocolos RESTful Http/JSON API. É
caracterizado por ser um banco robusto, através de uma interface orientada à documentos pode-se
fazer consultas e indexar seu conteúdo. Esta interface tem sua engine desenvolvida em JavaScript
(linguagem de script, interpretada por navegadores, criada em 1995, para adicionar dinamicidade
às páginas na web) que facilita diversas operações comuns a um banco de dados (CouchDB,
2009).
Características do sistema:
a) Software Gratuito;
b) Código fonte aberto;
c) Interface amigável com o Usuário;
d) Somente disponível para Sistema Operacional Linux (Implementação).
Na Figura 3.4 é apresentada a arquitetura do sistema. Sua base foi escrita em
Erlang, linguagem desenvolvida pela Ericsson caracterizada por possibilitar a modificação de um
software, feito nela, em Runtime, assim nunca uma aplicação desenvolvida em Erlang precisa ser
parada para efetuar suas atualizações. Esta linguagem dá suporte à comunicação HTTP, portanto
suas funcionalidades podem ser fornecidas com muita facilidade possibilitando a criação de um
Database as a Service completo (Armstrong, 2003).
38
Figura 3.4 – Arquitetura do Sistema CouchDB
Documentos consistem em um objeto com campos nomeados e com valores
atribuídos a esses campos, podendo ser estes valores, textos (Strings), numéricos, datas e outros.
Um exemplo de documento poderia ser um post de um blog, na Figura 3.5:
Figura 3.5 Estrutura de um documento
Percebe-se que cada campo possui um valor característico, Assunto assim como
Corpo são Strings simples, já Tag é um campo que possui uma lista de valores.
CouchDB nada mais é do que uma coleção destes documentos que são
identificados unicamente por um ID.
39
Diferentemente do Sql, o CouchDB foi desenvolvido para armazenar e
disponibilizar uma grande quantidade de semi-estruturas, dados orientados a documentos.
CouchDB facilita o desenvolvimento de aplicações orientadas a documentos.
Com o CouchDB, não é necessário a criação de um esquema, então novos tipos de
documentos podem ser adicionados juntamente com os antigos. A ferramenta de visualização,
usando JavaScript, é desenhada para manusear facilmente estes novos tipos de documentos.
3.2.1
Funcionamento
Atualmente o CouchDB é disponibilizado apenas para plataformas Linux e Mac, é
distribuído como pacote de instalação e código fonte para ser compilado e usado, as duas versões
de instalações são disponibilizadas gratuitamente no site http://couchdb.apache.org/. Há uma
sessão no site dedicado a notificações de bugs, que usuários encontram no decorrer das
operações. Podendo ser corrigidos pelos próprios usuários e sua correção pode ser disponibilizada
na próxima versão oficial do software (CouchDB, 2009)
Após instalar o CouchDB os primeiros passos vão ser executados via linha de
comando.
Assim como a maioria dos bancos de dados como serviço, o CouchDB
disponibiliza três métodos (REST) principais para manipulação dos seus dados, estes são:
a) GET - Método utilizado para capturar algum dado do banco;
b) PUT - Tem a função de inserir dados no banco;
c) DELETE - Utilizado para apagar um dado específico do banco.
40
Para acessar os métodos utiliza-se comando curl no terminal do sistema Linux
seguido a URL precedida do prefixo -X juntamente com o método a ser utilizado
Como no exemplo:
( 1 ) curl -X GET http://127.0.0.1:5984/_all_dbs
Neste exemplo capturamos uma lista dos bancos de dados existentes no sistema.
Se for seu primeiro acesso não deverá existir nenhum banco então a resposta que teria seria "[]"
que indica a não existência de conteúdo no registro procurado. Mas se antes o método PUT fosse
acionado para criar um banco de dados como no exemplo abaixo:
( 2 ) curl -X PUT http://127.0.0.1:5984/novobanco
Ele retornaria a seguinte resposta:
{"ok":true}
Em forma de um simples documento, contendo apenas a confirmação da criação.
Se fosse solicitado novamente o código ( 1 ) uma lista semelhante a esta iria
aparecer no visualizador do CouchDB:
["novobanco"]
Todas estas funcionalidades são disponibilizadas também pelo Futon, a interface
gráfica administrativa do CouchDB, Figura 3.6, para acessar esta ferramenta é necessário
executá-la via um navegador web através do endereço:
[ http://127.0.0.1:5984/_utils/ ]
41
Figura 3.6: Visualização da Ferramenta Futon
3.3
Caso de Uso
Atualmente há algumas aplicações que optaram por esta tecnologia, sistemas em
que o uso do armazenamento é extremo, tanto para leitura quanto para escrita. Esses sistemas
adotaram fornecedores de Banco de Dados como Serviço Web pagos, o qual hoje é a melhor
opção a se adotar.
Twitpic é um serviço muito simples para publicação de fotos e divulgação através
da sua conta Twitter microblogging e serviço de relacionamentos. Acesso pela url
http://twitpic.com, seu serviço pode ser também utilizado independentemente do Twitter, similar
ao mais popular site de compartilhamento fotos. (Twitpic.com, 2009)
Os serviços do Twitpic são disponibilizados via REST e suas fotos São
armazenadas no serviço de armazenamento Amazon S3 disponibilizados pela Amazon citada
anteriormente. Abaixo, na Figura 3.7, a home page do Twitpic.
42
Figura 3.7 Página principal do TwitPic
Ao cadastrar-se no sistema você tem a possibilidade de fazer uploads de fotos
ilimitados de para o seu perfil.
Na Figura 3.8, um exemplo de foto hospedada nos serviços da Amazon, note que a
url de acesso a imagem é extensa, isso porque nela estão contidas as seguintes informações:
a) O endereço do Web Service da Amazon:
http://s3.amazonaws.com
b) A conta do Usuário
http://s3.amazonaws.com/twitpic
c) O repositório Utilizado e uma subcategoria.
http://s3.amazonaws.com/twitpic/photos/large
d) O Nome do registro
http://s3.amazonaws.com/twitpic/photos/large/31196922.jpg
43
Figura 3.8 Exemplo de imagem armazenada em um Banco de dados como serviço Web
e) E mais três parâmetros provenientes da AmazonS3:
Chave de Acesso público ao Registro
AWSAccessKeyId=0ZRYP5X5F6FSMBCCSE82
Tempo de validade do Registro
Expires=1257022857
Autenticação do Usuário
Signature=waVZT9AF1aC91B1U29PxqUzBPio%3D
3.4
Considerações Finais
Dados os sistemas anteriores nota-se que há diferenças entre o modo de se fazer,
mas o conceito base da criação de um repositório e a inclusão de registros neles é idêntico.
44
Nota-se que há realmente a necessidade do uso da tecnologia, porém ainda não há
o suporte para a parte de manipulação visual, o que daria maior controle da situação em que se
encontram seus registros no banco de dados atual.
No próximo capítulo serão apresentadas as desvantagens destes produtos e o
desenvolvimento de uma nova aplicação que supra estas falhas e traga as vantagens do Database
as a Service para usuários iniciantes.
45
4
VISUAL DAAS: UMA IDE PARA BANCO DE DADOS COMO SERVIÇO WEB
Este capítulo apresenta a Visual DaaS, uma IDE para banco de dados como
serviço web. Será apresentada sua arquitetura, funcionamento, dicionário de dados, arquitetura
orientada a objetos, e interface gráfica com o usuário.
As seções estão organizadas da seguinte forma: a seção 4.1 desenvolvimento da
arquitetura do projeto Visual DAAS, a seção 4.2 mostra o funcionamento da BigTable e como
são estruturados seus registros, na seção 4.3 é apresentado um breve resumo do funcionamento
do sistema Visual DAAS, a seção 4.4 explica o funcionamento da engine que age entre a
interface gráfica e o repositório BigTable, a seção 4.5 apresenta o dicionário de dados que
definirá a estrutura dos dados armazenados na BigTable e finalmente na seção 4.6 é apresentado
a interface gráfica do usuário.
4.1
Arquitetura da Visual DAAS
Analisando o atual cenário de servidores de banco de dados como serviço web
nota-se algumas deficiências:
a) SimpleDB & AmazomS3: possui uma API completa e bem documentada,
porém seus serviços são pagos e não possui uma interface gráfica com o
usuário;
b) Usabilidade: os bancos de dados como serviços atuais são voltados para a
comunidade de desenvolvedores avançados, isso requer que o usuário tenha
além do conhecimento de programação, entenda também de banco de dados
orientado a documentos;
46
c) Soluções gratuitas como CouchDB, são para implementação e não fornece o
serviço completo, qual incluiria a infra-estrutura.
O modelo que será desenvolvido vai atender a essas dificuldades encontradas nos
projetos atuais de DAAS, trazendo de forma mais simples as vantagens do banco de dados como
serviço para os usuários iniciantes.
A BigTable é uma base de dados distribuída, extensa e escalável criada pela
Google. Ela é usada em muitas de suas aplicações populares e está somente disponível
internamente para funcionários da Google. Embora a BigTable não seja um DaaS, o
desenvolvedor Andrew Hitchcock, disponibiliza-a como Web Service, para testes. Seu uso é
limitado, está disponível no link http://bigtable.appspot.com, o limite de uso é cerca de 500mb de
capacidade são disponibilizados, por usuário. Este Web Service disponibiliza somente os métodos
de acesso e manipulação GET, PUT e DELETE, arquitetura RESTful (Hitchcock, 2009).
O objetivo da arquitetura é aproveitar este recurso e desenvolver sobre ele uma
interface amigável ao usuário, para que ele possa desenvolver aplicações que utilizem essa
ferramenta como banco de dados. Aproveitar os benefícios que uma ferramenta da Google pode
oferecer como escalabidade e o funcionamento ininterrupto da base.
Ao criar seu banco pela Visual DAAS, automaticamente será criado um Web
Service deste banco para ser utilizado em outras aplicações caso o usuários esteja desenvolvendo.
A arquitetura da Visual DAAS é apresentada na Figura 4.1.
A arquitetura está definida da seguinte forma:
a) BigTable: localiza-se na primeira camada da aplicação, que funciona como um
repositório de dados, sendo manipulada diretamente pela engine da IDE.
b) Engine: um nível acima está localizado o núcleo da aplicação, que concentra a
maior parte do processamento, agindo como intermediário entre a interface
47
gráfica com o usuário e a BigTable. Nesta etapa encontra-se, também, o
gerenciamento dos Web Services criados pelos usuários da IDE.
Figura 4.1. Arquitetura da Visual DAAS
c) Interface Gráfica: ultima camada da aplicação, qual o usuário tem o acesso
direto e controle total sobre a aplicação.
4.2
Funcionamento da BigTable como Serviço Web
O repositório BigTable trabalha com armazenamento de dados codificados em
Base64 como no exemplo da Figura 4.2. O sistema de codificação Base64 para transferência de
dados pela Internet, é constituído por 64 caracteres que variam de 0 a 9, de A a Z e inclui os
símbolos “/”, “+” e “=”. (Josefsson, S., 2009)
48
FIGURA 4.2 Exemplo de um dado codificado na Base64
Cada registro é estruturado no formato JSON (JavaScript Object Notation Notação de Objetos JavaScript), é um padrão de troca de mensagens entre sistemas, os dados são
organizados em listas e seu conteúdo é legível pelo homem (Json.org, 1999). Cada registro é
considerado uma célula e cada célula possui os seguintes atributos, apresentados na Figura 4.3:
FIGURA 4.3 Atributos de uma Célula contida na BigTable
O método GET de captura de dados permite somente a captura de uma célula por
vez, portanto será necessário o desenvolvimento de meta-dados para facilitar a manipulação dos
dados na BigTable e definir algumas constantes em relação à estrutura das tabelas criadas por
este modelo.
4.3
Funcionalidades do Sistema
O Visual DAAS, assim como nos banco de dados convencionais, deverá prover
funcionalidades simples, como criação e manipulação de tabelas, e mais complexas, como
indexação e backup dos dados gravados na base.
49
Haverá também um sistema de consultas que serão feitas por meio de comandos
SQL ou por um sistema de associação visual, no qual o usuário acrescentará os filtros da busca
até montar o resultado desejado passando assim por um sistema de consulta da Engine Java e
retornará ao usuário os resultados em uma tabela. Esta consulta também poderá ser feita através
do Web Service do sistema e o resultado será disponibilizado em JSON.
Este tipo de resultado facilitará a associação com outros aplicativos que usufruem
de Web Services como complementos para suas aplicações.
4.4
Requisitos do Sistema
A seguir serão apresentados os requisitos funcionais e não-funcionais da Visual
DAAS:
a) Requisitos Funcionais – A engine deve prover as funcionalidades relacionadas
ao processamento de dados do sistema, incluído nisso estaria o sistema de
gerenciamento da base de dados BigTable, o controle de acesso para os
usuários, um gerenciador de consultas e indexação do banco, e por fim um
gerenciador de Web Services tanto dos gerados como os dos consumidos no
caso da BigTable;
b) Requisitos não funcionais - Uma característica indispensável em um sistema
Web é a usabilidade, pois assim suas funcionalidades podem ser assimiladas
sem ao menos que o usuário tenha a necessidade de ler um manual ou tutorial
de como manipular o aplicativo em questão. Outro requisito é a Escalabilidade,
além da provida pela Web Service da BigTable, o Visual DAAS também
deverá atender a este requisito, que leva em conta tanto software como o
hardware, utilizado no servidor que hospeda a aplicações, que passa a ter papel
fundamental neste padrão de qualidade.
50
4.5
Dicionário de Dados
Em um banco de dados convencional os arquivos de configurações definem a
estrutura de um banco de dados, armazenam elementos que o compõe e os dados que estão
contidos neles em datafiles. Como a BigTable não disponibiliza nenhum recurso similar, é
necessário esquematizar esta base para que seja possível implementar o modelo.
Baseado em um banco de dados relacional, os dados serão armazenados em
tabelas e estas conterão linhas e colunas.
Assim como as células também deve-se definir atributos para uma tabela, esses
atributos serão armazenados em uma célula seu conteúdo estará estruturado no formato JSON,
como no exemplo da Figura 4.4.
Figura 4.4 Estrutura de uma tabela em JSON
Todas as tabelas serão descritas pelos atributos, apresentados na Figura 4.5.
51
Figura 4.5 Atributos de uma tabela do sistema Visual DAAS
A meta-célula da Figura 4.5, precisa ser armazenada em uma tabela, linha e coluna
específica, com um padrão para ser seguido caso outra tabela seja criada.
Primeiramente é necessário assim como os bancos convencionais criar tabelas de
que armazenarão os objetos criados no sistema e seus usuários, essas tabelas também deverão
seguir o padrão especificado anteriormente, exemplo na Figura 4.6:
FIGURA 4.6 A Tabela de objetos armazenará as tabelas criadas pelos usuários do sistema
Note que o primeiro registro da tabela de objetos refere-se a ela mesma, indicando
a existência de um objeto no sistema.
52
Feito isso, é necessário armazenarmos os usuários do sistema, que terão poder
sobre os objetos criados. Então se cria uma tabela para este fim, apresentada na Figura 4.7.
Esta tabela também será referenciada nos registros de objeto e assim será com
todos os outros criados. Ao criar-se uma tabela ou objeto, uma rotina do sistema criará
automaticamente um registro na tabela de objetos relacionando diretamente ao usuário que a
criou.
FIGURA 4.7 Tabela de Usuários do sistema.
Primeiramente será necessária a criação de um cadastro de usuário, para
identificação do autor das futuras tabelas. Este dado inicial será gravado na tabela de usuários
criada nas configurações do dicionário de dados. Ao entrar no sistema, após o login, o usuário
terá acesso ao Menu de aplicações e visualização da área de trabalho do sistema.
4.6
Arquitetura Orientada a Objetos
A Engine da IDE será desenvolvida em Java, linguagem que dá suporte a todos os
requisitos levantados anteriormente (Sun Microsystem, 2005).
53
Abaixo as funcionalidades providas pelo sistema:
a) Visualizador de Objetos: Menu principal do programa onde será possível
visualizar os objetos criados pelo usuário;
b) Criar Tabela: Disponibilizará um painel contendo os campos necessários para
criação de uma tabela: nome da tabela, nº de colunas e seus nomes;
c) Visualizar Tabela: Ao clicar aparecerá uma janela para digitar o nome da
tabela e um botão para confirmação, caso exista o sistema exibe a tabela na
área de tarefas;
d) Editar Tabela: Também com o campo de entrada do nome da tabela esta opção
retorna uma tabela de objetos com colunas referenciando aos atributos das
tabelas como nome de colunas e tipo;
e) Fazer Consulta: Com esta opção pode-se executar uma consulta através de uma
string SQL e o resultado caso haja será uma tabela com os dados na área de
trabalho do sistema;
f) Gerar Web Service de uma Tabela: Esta opção gera uma Url para que uma
tabela possa ser acessada via RESTful.
Analisando estas informações e atendendo os requisitos funcionais é possível
desenvolver o diagrama de classes do projeto, apresentado na Figura 4.8:
54
FIGURA 4.8 Diagrama de classes do sistema.
Este diagrama ilustra o funcionamento do sistema, mas análise é necessária para o
entendimento por completo. Primeiramente a classe Célula seria a base do sistema com suas
simples características valor do tipo Object, podendo receber variados tipos de conteúdo, e a
especificação do conteúdo no atributo tipo, classificado pelos atributos pertencentes ao Enum
TipoDados podendo variar entre DATA, MOEDA, NUMERO e TEXTO.
Acima encontra-se a classe Linha que é composta por Células, possui os atributos
tabela, que recebe como valor o nome da tabela que está contida, o atributo número, que
corresponde ao número da linha na tabela, o atributo colunas que é uma lista correspondente ao
formato da linha e por fim o atributo célula, que é uma lista das células contidas naquela linha.
55
A classe Coluna possui os atributos tabela, qual ela pertence, nome da coluna e
tipo define o dado que pode ser inserido no seu conteúdo. A classe está associada diretamente
com uma Linha e juntas compõe a classe Tabela que além dessas características ainda possui os
atributos:
a) nome: nome dado à tabela;
b) usuário: criador da tabela;
c) dataCriacao: data da criação da tabela;
d) colunas: lista de colunas que formam a tabela;
e) linhas: lista das linhas com conteúdo que preenchem a tabela.
Esta tabela já possui alguns métodos bem definidos, além de seus “getters” e
“setters” como addLinha e addColuna, que adicionam respectivamente uma linha e uma coluna à
tabela.
TabelaToJSON e JSONToTable são responsáveis pela manipulação da tabela de
acordo com a camada em que a tabela estiver sendo utilizada, para gravar a tabela na BigTable o
método tabelaToJSON faz a tradução do um objeto Tabela para um arquivo JSON. Já para o
caminho oposto utiliza-se o método JSONToTable. Para a camada Visual será desenvolvido um
modelo de dados similar em JavaScript, que receberia como fonte de dados os objetos
codificados em JSON, processo ilustrado na Figura 4.9.
Para a utilização da BigTable foram adicionados recursos para se adaptar ao
projeto ao arquivo BigTable.jar disponibilizado por este site http://bigtable.appspot.com, foi
criada uma classe BigTableMelhorada para suprir com esta necessidade. Foram criados métodos
para inserir, deletar, atualizar e selecionar uma tabela na BigTable de acordo com os padrões
especificados pelo projeto.
56
A classe Configurações será a primeira a ser executada na implementação do
projeto, pois é responsável pela configuração inicial do dicionário de dados e da manipulação do
seu conteúdo.
Web Browser
Web Server
HTML / JAVASCRIPT
JAVA
function eventManager()
{
AjaxService.getOptions(populateList());
}
public class AjaxService
{
JSONreturn new String[] {“1”,”2”,”3”};
function populateList(data)
{
DWEUtil.addOption(“okoko”,data);
}
public String[] getOptions(){
}
}
REQUISIÇÃO
Figura 4.9 Ilustração do processo de transição dos dados pelas camadas da aplicação.
E por fim a classe Consulta que tratara das consultas em SQL feias pelo usuário,
retornando o resultado, se existir, uma outra tabela no formato JSON. Este método também será
acessível via Web Service, podendo ser acessado via RESTful.
4.7
Interface com o Usuário
Foi utilizado como base para a construção da interface o conceito de aplicações
RIA Aplicações de Internet Rica (da sigla em inglês RIA - Rich Internet Application), possuem
57
os aspectos visuais semelhantes a aplicativos desktop, adequando-se aos quesitos de usabilidade e
maior aproveitamento da aplicação (Duhl, J, 2003).
Uma das características das aplicações RIA é a de que todo o processamento
destinado a interface fica a cargo do navegador e a maior parte dos dados ficam em um servidor
de aplicações.
Esta interface será desenvolvida em JavaScript com auxílio da biblioteca JQuery,
que suporta vários plugins, para facilitar a criação de aplicações RIA .
A seguir, na Figura 4.6, o design da aplicação Visual BigTable.
Figura 4.6: Modelo de como seria a visualização do sistema.
58
Abaixo, Figura 4.7 a Tela de login do sistema com o botão para cadastro do
usuário caso ainda não esteja cadastrado e um botão “OK” para confirmação do Login.
Figura 4.7 a Tela de Login do sistema
Abaixo, Figura 4.8, o Visualizador de Tabelas, caracteriza-se por uma tela simples,
com um campo de texto para inclusão do nome da tabela desejada e um botão de “OK” para
confirmação da busca.
59
Figura 4.8 Visualizador de Tabelas.
Abaixo, Figura 4.9, o Editor de Tabelas, tela de edição tem o leiaute similar ao de
uma tabela, contém colunas que representam os atributos da tabela como Nome, Tipo, Tamanho e
Data da Criação, e suas linhas que representam os campos da tabela em edição.
Figura 4.9 Editor de Tabelas.
Abaixo, Figura 4.10, a Tela para consultas em SQL. Dado um comando SQL, o
resultado será uma nova tela com a tabela resultante.
60
Figura 4.10 Tela de Consultas.
4.8
Considerações finais
Este capítulo apresentou a Visual DAAS. Foi descrito a arquitetura do sistema,
funcionamento, dicionário de dados, arquitetura orientada a objetos e interface gráfica. No
próximo capítulo serão apresentadas as considerações finais deste Trabalho.
61
5
CONSIDERAÇÕES FINAIS
Este trabalho apresentou a Visual DAAS, uma IDE para criação, administração e
manipulação de Banco de Dados como Serviço Web.
Este Capítulo está organizado como segue: a Seção 5.1 apresenta as contribuições
e conclusões, enquanto a Seção 5.2 apresenta possíveis trabalhos futuros.
5.1
Contribuições e Conclusões
As contribuições deste trabalho são:
a) Definição de uma arquitetura de IDE’s para o desenvolvimento de Banco de
Dados como Serviço Web
b) Definição e implementação de uma engine Java para a administração e
manipulação dos dados criados e dos Web Services disponibilizados pela
aplicação.
c) Definição e implementação de uma interface gráfica, utilizando tecnologias
RIA.
A partir destas contribuições pode-se concluir que:
a) É possível facilitar a utilização de um banco de dados como serviço web, sem
ao menos o usuário digitar uma linha de código para criação do banco.
62
b) Por ser um sistema bem encapsulado, pois a camada de visualização está
desacoplada da engine da aplicação, é possível o uso posterior desta ferramenta
que podem ser acoplada a diversas outras aplicações.
5.1.1
Publicação
Artigo Publicado:
“Visual DAAS: uma IDE para banco de dados como serviço web” artigo completo
publicado no XI Simpósio de Iniciação Científica e Tecnológica (SICT 2009), promovido pela
Faculdade de Tecnologia de São Paulo. Conforme apêndice A.
5.2
Trabalhos Futuros
As contribuições alcançadas com este trabalho não encerram as pesquisas
relacionadas ao sistema Visual DAAS, mas abrem oportunidades para alguns trabalhos futuros:
a) Desenvolver um sistema Visual que se adapte a qualquer base de dados como
serviço web, pois a Visual DAAS é destinada apenas a BigTable.
b) Aprimorar os quesitos de segurança da informação, como criptografia e
controle de concorrência.
c) Aplicar testes com usuários finais, a fim de analisar os quesitos funcionais e
não funcionais do sistema.
63
REFERÊNCIAS
AMAZON – Simple Storage Service Disponível em: < http://aws.amazon.com/s3/>.
Acesso 09 de junho 2009
AMAZON – SimpleDB Disponível em: <http://aws.amazon.com/simpledb/>. Acesso 20
de março 2009
AMAZON – What is AWS? Disponível em: <http://aws.amazon.com/what-is-aws/>.
Acesso 08 de junho 2009
ARMSTRONG, J - Making reliable distributed systems in the presence of software
errors.
Disponível
<http://ftp.sunet.se/pub/lang/erlang/download/armstrong_thesis_2003.pdf>
em:
Acesso
12
agosto de 2009.
BENNETT, K- Service-based software: the future for flexible software, 2000 –
Disponível em: <http://www.bds.ie/Pdf/ServiceOriented1.pdf>. Acesso 06 de abril de
2009.
CHANG, F., DEAN, J., GHEMAWAT, S., WILSON, H., WALLACH, D., BURROWS,
M., CHANDRA, T., FIKES, A., GRUBER, R. - Bigtable: A Distributed Storage System
for Structured Data <http://labs.google.com/papers/bigtable.html>. Acesso 05 de março
de 2009.
COUCHDB - The CouchDB Project. Disponível em: <http://CouchDB.apache.org/>.
Acesso 10 de abril de 2009
DATE, C. J. Introdução a Sistemas de Banco de Dados – Editora Campus – 2004
64
Duhl, J. - Rich
Internet
Applications, novembro de 2003. Disponível em:
<http://www.adobe.com/platform/whitepapers/idc_impact_of_rias.pdf>. Acesso em 18
outubro de 2009
ERL, T., Service-Oriented Architecture: Concepts, Technology, and Design, Prentice
Hall, 2005, ISBN 0-13-185858-0.
FIELDING, DR - REST - Representational State Transfer. 2000, Disponível em
<http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm>. Acesso 17 de
agosto de 2009.
FINCH, C. - The Benefits of the Software-as-a-Service Model, 2006 - Disponível em:
<http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleI
d=107276>. Acesso 06 de abril de 2009.
HACIGUMUS, H., IYER, B., E MEHROTRA, S. Providing database as a service. Data
Engineering, 2002. Proceedings. 18ª Conferencia Iternacional de (2002)
IBM. - Working with jQuery, Part 3: Rich Internet applications with jQuery and Ajax :
JQuery: Building tomorrow's Web apps today, 28 outubro 2008. Disponível em:
<http://www.ibm.com/developerworks/web/library/wa-jquery3/>. Acesso em 21 outubro
de 2009
JAVA – The Java Language Specification, Third Edition – Disponível em:
<http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html>. Acesso em 05 de
junho de 2009.
JOSEFSSON, S., The Base16, Base32, and Base64 Data Encodings - Ed. Network
Working Group – Disponível em: < http://tools.ietf.org/pdf/rfc3548.pdf >. Acesso em 3
de agosto de 2009.
65
JSON - JavaScript Object Notation. Disponível em: <www.json.org>. Acesso 21 de
agosto de 2009.
Miller, M - Cloud Computing Pros and Cons for End Users Disponível em:
<http://www.informit.com/articles/article.aspx?p=1324280>. Acesso em 15 de setembro
2009.
RAVI JAMMALAMADAKA ,JEHAN WICKRAMASURYA, MAHESH DATT
YEMMANURU ,YONGHUA WU - Database As Service - Disponível em: <http://wwwdb.ics.uci.edu/pages/research/das>. Acesso em: 01 de abril de 2009.
SILBERSCHATZ, A, HENRY F. KORTH, S. SUDARSHAN Sistema de Banco de
Dados - Editora Campos – 2006
TANENBAUM, A, STEEN V, Distributed Systems: Principles and Paradigms,
Prentice Hall, 2002, ISBN 0-13-088893-1.
TIM O'REILLY - What Is Web 2.0. Publicado em 30/09/2005 - Disponível em
<http://oreilly.com/web2/archive/what-is-web-20.html>. Acesso em 15 de abril de 2009.
W3C
-
Hypertext
Transfer
Protocol
-
HTTP/1.1
Disponível
em:
<http://www.w3.org/Protocols/rfc2616/rfc2616.html>. Acesso 04 de abril de 2009.
W3C - SOAP Version 1.2 Part 0: Primer (Second Edition) Recommendation 27 Abril de
2007 Diponível em:<http://www.w3.org/TR/2007/REC-soap12-part0-20070427>. Acesso
em 03 de abril de 2009
W3C - Web Services Activity Disponível em: < http://www.w3.org/2002/ws/ >. Acesso
em: 3 de abril de 2009.
W3C - Web Services Architecture Disponível em: < http://www.w3.org/TR/ws-arch/>.
Acesso em: 3 de abril de 2009.
66
W3C - Web Services Architecture Working Group Note 11 Fevereiro de 2004 Disponível
em: <http://www.w3.org/TR/ws-arch/>. Acesso em: 20 de março de 2009.
W3SCHOLLS
–
Xml
what
is
this?
Disponível
<http://www.w3schools.com/XML/xml_whatis.asp>. Acesso em 04 de abril 2009
em:
67
APÊNDICE A - Artigo publicado no XI Simpósio de Iniciação Científica e Tecnológica
VISUAL DAAS: UMA IDE PARA BANCO DE DADOS COMO
SERVIÇO WEB
Eduan Lenine dos Santos Neves¹, Giuliano Bertoti¹
¹Facudade de Tecnologia do Estado de São Paulo(FATEC), São José dos Campos, Brasil
[email protected], [email protected]
1.
Introdução
A utilização do banco de dados como recurso de
armazenamento estruturado tornou-se muito comum na
área acadêmica, científica e profissional[1].
A dificuldade de se implementar, manter e
administrar um banco de dados é comum em todas essas
situações. É necessária a contratação de mão de obra
especializada e nem sempre é possível prover o recurso
com a mesma escalabilidade de um serviço com grande
demanda.
Soluções de aplicações disponibilizadas pela web
tornam-se mais comum com o aumento da utilização da
internet banda larga, tendência que deu nome a uma
nova fase da computação, Computação nas Nuvens
(Clouding Computing)[2]. Algumas soluções que
passaram para este plano e estão se destacando uma das
outras, nisso se encaixa o Banco de Dados como
Serviço Web, que é fornecer toda a infra-estrutura
necessária para implementação e o banco de dados em
si pela web.
Esta solução trás muitas vantagens em relação aos
paradigmas de programação anteriores. Por exemplo, as
organizações que adotam este tipo de serviço deixam de
se preocupar com a compra de equipamentos para
manter uma aplicação proprietária, economizam tempo
no desenvolvimento da sua solução, tem todas as
vantagens que um provedor de serviços fornece como
escalabilidade, segurança da informação, além de não
ter de lidar com manutenção e um grande número de
treinamentos, necessários para o desenvolvimento de
um software proprietário. Concentrando seus esforços
na solução do negócio.
Este artigo tem como objetivo mostrar como é
possível no cenário atual a implementação de uma IDE
(Ambiente de Desenvolvimento Integrado) para Banco
de dados como Serviço Web, utilizando recursos
existentes e disponibilizando suas funcionalidades de
forma simples e eficiente.
2.
Bigtable: Armazenamento como
serviço.
Para a construção de uma aplicação desse tipo, é
necessária uma grande capacidade de armazenamento.
Esse tipo de necessidade também é sanado por serviços
disponibilizados pela Internet, podendo ser aproveitado
por diversos tipos de aplicações.
Uma opção é a “Bigtable as a Service”, solução
desenvolvida pela Google utilizada em diversas outras
aplicações
como
ferramenta
eficiente
de
armazenamento [3], será utilizada aqui como principal
fonte e base de dados.
3.
A IDE: Visual Daas
A forma mais simples de se manipular uma
ferramenta é quando esta possui uma interface gráfica,
simples e usual. Para isso foi desenvolvido um protótipo
do que seria possível visualizar no sistema desenvolvido
para manipulação de um Daas (Database as a service),
na Figura 1.
Figura 1 - Interface gráfica da aplicação
A IDE deve prover funcionalidades básicas
existentes nos atuais sistemas de banco de dados e
avançadas que seriam a disponibilização de suas
funcionalidades e bases criadas pelos usuários, através
de Web Services.
4.
Conclusão
Este artigo apresentou os conceitos deste novo
paradigma na utilização de banco de dados e descreveu
a possibilidade de se desenvolver uma IDE para
manipulação e melhor aproveitamentos das vantagens
oferecidas por esta nova tecnologia.
5.
Referências
[1] Database as a Service, Disponível em:
<http://www-db.ics.uci.edu/pages/research/das>.
[2]
Wikipedia
En,
Disponível
em
<http://en.wikipedia.org/wiki/Cloud_computing>
[3] Bigtable: A Distributed Storage System for
Structured Data , Disponível em:
<http://labs.google.com/papers/bigtable.html>