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

Transcrição

1 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

2 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

3 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

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

5 v O acaso é talvez, o pseudônimo que Deus usa quando não quer assinar suas obras. T. Gauther

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

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

8 viii SUMÁRIO 1 INTRODUÇÃO Motivação Objetivos Objetivo Geral Objetivos Específicos Metodologia Organização do Trabalho BANCO DE DADOS COMO SERVIÇO WEB Banco de Dados Banco de Dados Hierárquico Banco de Dados em Rede Banco de Dados Relacional Manipulação do Banco de Dados Sistemas Distribuídos Arquitetura de um sistema distribuído Serviços Web (Web Services) Software como um serviço Definição Objetivos WSDL XML Arquitetura e Protocolos de Comunicação Banco de dados como Serviço Web Por que Banco de dados com Serviço web? Desafios do DAAS Considerações Finais SOLUÇÕES EXISTENTES SimpleDB + AmazonS

9 Amazon S Funcionamento SimpleDB CouchDB Funcionamento Caso de Uso Considerações Finais VISUAL DAAS: UMA IDE PARA BANCO DE DADOS COMO SERVIÇO WEB Arquitetura da Visual DAAS Funcionamento da BigTable como Serviço Web Funcionalidades do Sistema Requisitos do Sistema Dicionário de Dados Arquitetura Orientada a Objetos Interface com o Usuário Considerações finais CONSIDERAÇÕES FINAIS Contribuições e Conclusões Publicação Trabalhos Futuros REFERÊNCIAS APÊNDICE A - Artigo publicado no XI Simpósio de Iniciação Científica e Tecnológica... 67

10 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 a l, 2004). 1.2 Objetivos A seguir serão apresentados os objetivos gerais e específicos deste trabalho.

11 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 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 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 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 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 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 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) 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 16 Figura 2.2: Modelo de Dados em redes e seus relacionamentos (Silberschatz, A. 2006) 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 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 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 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 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) 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 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) desta solução. A seguir a definição de Web Service, sua arquitetura, características e vantagens 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 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, Infra- Estrutura); 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) 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 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) 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 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 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) 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 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 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 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 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 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 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 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 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 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 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 31 Service, que pode ser utilizada para armazenar e retirar dados em qualquer quantidade, hora e lugar da web 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. única chave de acesso. Cada objeto é armazenado em bucket, repositório de dados, e recuperado, via uma 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 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 Para validar o conteúdo dos Xml

32 32 gerado pelo cliente ela disponibiliza um XSD no link 01/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. dado utilizando este espaço. Feito a criação de um local de armazenamento, o próximo passo é armazenar um

33 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 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 35 completo ao objeto. Se o objeto já existe, o controle de acesso anterior é substituído pelo novo 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 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 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 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 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 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 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) comando. Após instalar o CouchDB os primeiros passos vão ser executados via linha de 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 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 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 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: [ ]

41 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 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 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: b) A conta do Usuário c) O repositório Utilizado e uma subcategoria. d) O Nome do registro

43 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= 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 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 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 nota-se algumas deficiências: Analisando o atual cenário de servidores de banco de dados como serviço web 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 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 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 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 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 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 DAAS: A seguir serão apresentados os requisitos funcionais e não-funcionais da Visual 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 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 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 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 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 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 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 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 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()); } JSON public class AjaxService { function populatelist(data) } { DWEUtil.addOption( okoko,data); } } REQUISIÇÃO public String[] getoptions(){ return new String[] { 1, 2, 3 }; 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 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.