libgda"> ]> Michael Lausch

michael.lausch@1012surf.net

Rodrigo Moya

rodrigo@gnome-db.org

Vivien Malerba

malerba@linuxave.net

Cleber Rodrigues

cleberrrjr@bol.com.br

1999 February 1999-2000 The Free Software Foundation GNU Data Access (GDA) é um arquitetura cujo objetivo é prover acesso universal a diferentes tipos de fontes de dados. Desde os tradicionais bancos de dados relacionais, a qualquer fonte de dados imaginável, como por exemplo um servidor e-mail, um diretório LDAP... Esta universalidade é obtida através do uso de CORBA como mecanismo para comunicação entre os diferentes componentes da arquitetura. Este documente pode ser distribuido sob os termos e condições estabelecidas na Open Publication License, v1.0 or superior (a versão mais atual está sempre disponível em http://www.opencontent.org/openpub/ ) ODBC e SQL são padrões estabelecidos. O problema é que ODBC não especifica o protocolo de comunicação e não existem drivers para alguns bancos de dados. Você pode usar RPC, TCP/IP, ou memória compartilhada e 'signals' para fazer os pedidos ao cliente ao servidor. Então você tem que usar uma biblioteca ODBC específica a certo banco de cados. Esta biblioteca pode não estar disponível para a CPU ou sistema operacional na qual o cliente está rodando. SQL não é padronizado suficientemente, de maneira que compatibilidade de código não pode ser garantida para todos os servidores de banco de dados. E para alguns tipos de servidores, SQL não é nem mesmo cogitável (pense em LDAP). GDA tenta atavar o problema do ODBC e ajudá-lo com o problema do SQL. É um tipo de middleware (ou pode ser expadido para ser uma camada middleware) para acessar diferentes fontes de dados. GDA oferece uma visão bastante abstrata (high level) das fontes de dados e possui locais onde você pode encaixar componentes específicos a certa tarefa (low level) para acessar estes dados. GNU Data Access (GDA) é definido em um conjunto de interfaces CORBA IDL. O nível de abstração provido pelo GDA torna possível o acesso a qualquer tipo de fonte de dados, desde que um servidor CORBA que implemente estas interfaces IDL e acesse esta fonte de dados seja escrito. &Libgda; é uma implementação das interfaces CORBA GDA, usando ORBit como implementação CORBA. Isso significa que, em teoria, seria possível implementar &Libgda; para um outro CORBA ORB ou sistema operacional, desde que suporte a COBRA esteja presente nesse sistema. Este trás uma camada acima das rotinas internas CORBA, trazendo todo o poder nativo da arquitetura CORBA a programadores que não precisam ter conhecimento do mesmo. Este vem com diversas bibliotecas, para ambos clientes e servidores, implementadas em C. Este nível de abstração torna possível a posterior mudança do funcionamento interno sem a necessidade de alteração nas aplicações que utilizam estas bibliotecas, como também mas importantemente, manter desenvolvedores de aplicações longe das contínuas mudanças nas APIs relacionadas a CORBA em uso, como por exemplo OAF, GConf... Junto com estas bibliotecas (e 'header files' e 'language bindings' para desenvolvimento), &Libgda; traz várias ferramentas e utilitários para ajudá-lo na tarefa de desenvolver aplicações baseadas em &Libgda;, bem como automatizar algumas tarefas relacionadas ao banco de dados. &Libgda; é implementada para sistemas operacionais tipo Unix (incluindo Linux), e não depende de outras bibliotecas exceto por ORBit, GConf, OAF e Glib, o que o faz um sistema bastante leve, ideal para aplicações que rodarão em sistemas com recursos de hardware limitados. &Libgda; já foi parte do projeto GNOME-DB, na verdade ainda é, mas tem sido separado para que aplicações "não GNOMificadas" sejam desenvolvidas baseadas na mesma. &Libgda; é composta por três camadas independentes. A camada inferior é composta pelos provedores GDA, que são servidores CORBA cuja tarefa é mapear a API específica a determinada fonte de dados ao modelo GDA. Ou seja, eles são objetos CORBA que implementam a interface CORBA GDA. A camada do meio é a utilizada diretamente por aplicações desenvolvidas com &Libgda: um biblioteca que encapsula o código CORBA, escondendo toda a complexidade inerente ao CORBA da sua aplicação. Esta camada também inclui várias funções utilitárias para ajudá-lo no desenvolvimento de aplicações baseadas em GDA. Finalmente, em cima de tudo isso estão os programas distribuídos com o restante do pacote GDA, bem como qualquer aplicação que faz uso das bibliotecas GDA. &Libgda; é baseado em CORBA e utiliza ORBit como implementação CORBA. Basicamente o sistema fornece um arquivo IDL como a interface para o cliente. Para cada diferente fonte de dados (ODBC, Sybase, Informix, MySQL, LDAP, ...) um servidor deve ser escrito. Este servidor é preferencialmente um biblioteca compartilhada linkada a um pequeno programa (driver) para formar um servidor CORBA independente. Desta maneira é possivel usar o servidor como uma biblioteca para o cliente, aumentando a eficiência (nem sockets nem 'context switches' são necesários, uma vez o código está rodando na mesma máquina e no mesmo espaço de memória). A vantagem de se usar um servidor CORBA é que o servidor pode rodar em um outra máquina, balanceando a carga. Isto é possível porque ORBit é pequeno e rápido. Você pode usar o mesmo servidor de um linguagem de script que entenda CORBA e você pode fazer 'tracing' e controle de transações no servidor, sem necessidades de alterações no cliente. A desvantagem é que se tal provedor "der pau" todos os clientes são desconectados do banco de dados. Para superar este problema é possível que cada cliente requeira um nova cópia do provedor (entretanto, a API para o cliente ainda não tem esta opção). Os outros tipos de provedores são bibliotecas compartilhadas. Estes provedores são linkados ao cliente quando o cliente requer algo do provedor. A desvantagem é que o servidor e o cliente têem que estar na mesma máquina. Mas qualquer problema com o servidor afetara somente um cliente. O custo de inicialização é comparável ao do provedor executável. A grande vantagem deste tipo de provedor é que a depuração do código do provedor é mais simples, uma vez que você não pode anexar GDA a um provedor já rodando e você pode também apanhar error durante a inicialização do servidor. Por padrão cada provedor GDA é disponível como executável e como biblioteca compartilhada. O processo de compilação e as convenções usadas para implementar o provedor se asseguram que os executáveis e bibliotecas compartilhadas sejam compiladas e instaladas. Ou seja, provedores GDA são implementados em bibliotecas compartilhadas que são então linkadas a um pequeno programa que age exatamente como um driver para a biblioteca compartilhada. Você pode sempre encontrar em nosso web site, pacotes para RedHat e Debian, por isso você não deve ter nenhum problema instalando-os. Para uma instalação padrão, não há nada mais a ser feito; porém seria bom que você conhecesse sobre a parte de configuração CORBA e GDA, em caso que você venha a fazer um instalação fora do padrão, ou em casos de problemas durante a instalação. A instalação depende do formato que você resolveu fazer download. Se você tem um pacote como RPM ou DEB, procure na documentação do seu gerenciador de pacotes por como fazer para instalar novos pacotes. Se você optou pelo código fonte (em um tarball), você precisa compilar o software. Para fazê-lo, um vez que você tenha descompactado o tarball e re-criado toda a estrutra (diretórios, arquivos) do código fonte, entre com: ./configure make make install Este processo gerará os makefiles específicos para sua plataforma, compilará todo o código, e instalará os binários e a documentação no seu sistema. Se você não encontrar o arquivo configure, deve haver um outro chamado autogen.sh. Nessse caso, execute autogen.sh, que criará o arquivo configure e consequentemente o executará. Você pode especificar vários argumentos ao comando configure (ou ao comando autogen.sh). Os mais importantes seguem (você pode ver todos as opções de argumentos executando configure --help: --prefix=<diretório>: Prefixo onde programa será instalado --with-mysql=<diretório>: Diretório onde as bibliotecas MySQL estão instaladas --with-postgres=<diretório>: Diretório onde as bibliotecas PostgreSQL estão intaladas --with-sybase=<diretório>: Diretório onde as bibliotecas Sybase estão intaladas --with-ldap=<diretório>: Diretório onde as bibliotecas LDAP estão intaladas --with-oracle=<diretório>: Diretório onde as bibliotecas ORACLE estão intaladas --with-interbase=<diretório>: Diretório onde as bibliotecas Interbase estão intaladas --with-mdb=<diretório>: Diretório onde as bibliotecas MDB estão instaladas Normalmente provedores não são instalados, você dese adicionar estes argumentos quando executar configure. Se você encontrar algum problema durante a configuração, compilação ou instalação, não hesite em contactar a lista-de-discussão GNOME-DB (gnome-db-list@gnome.org, mas primeiro você precisa se inscrever na lista. Envie um e-mail para gnome-db-list-request@gnome.org com a palavra 'SUBSCRIBE' no campo 'Assunto', caso você ainda não tenha o feito). Dependendo do que você vai fazer com o &Libgda;, pode ser que você tenha que mergulhar no código, mas não tenha medo, ele foi teito com facilidade de uso em mente. Se você quer desenvolver aplicação usando &Libgda;, você deve instalar o pacote libgda-dev[el] se você está usando um sistema baseado em Debian ou RedHat. Se você mesmo compilou o programa, arquivos necessários para desenvolvimento já estão instalados no seu sistema. O único coisa você que você precisa fazer para ver se tudo está instalado, é verificar se as bibliotecas e programas do &Libgda; são vistas pelo sistema. Isto é, fazer com que o diretório bin/ do &Libgda; esteja na variável de ambiente PATH, tão bem como o diretório lib/ esteja em LD_LIBRARY_PATH (ou no arquivo /etc/ld.so.conf). Se você quer acessar uma fonte de dados através de um provedor GDA, você precisa primeniramente ter acesso a este provedor e, mais importante, este provedor deve ter acesso a fonte de dados específica. Tenha então, antes de tudo, seu banco de dados rodando. Para isso, você deve pesquisar como fazê-lo na documentação do seu banco de dados ou na seção específica a este provedor na documentação do &Libgda;. Uma vez que tenha seu provedor GDA instalado, seja ele localmente ou em outra máquina via rede, você precisa configurar seu sistema para ter acesso ao provedor. Se você está fazendo um instalação local, uma vez que vocêtenha instalado o provedor GDA (compilando ou instalando através de um pacote RPM ou Debia, por exemplo), o provedor já está vizível na sua máquina. Isto é porque o pacote com o provedor fornece um arquivo .oafinfo na qual ele especifíca o lugar onde este está instalado e outras informações sobre si mesmo. Se, pelo contrário, seu provedor está em uma outra máquina, você terá que criar um arquivo .oafinfo. Para isso, verifique a documentação de instalação do OAF. Então, o próximo passo é configurar as fontes de dados que você quer disponíveis no seu sistema. Para fazer isso, você deve, por enquanto, usar o GNOME-DB, que é um 'frontend' do &Libgda; do projeto GNOME. Seria um boa idéia acrescentar uma ferramento tipo linha-de-comando para controlar a configuração, como atualmente, usando GConf, não é uma questão simples como editar um arquivo de texto, como era antes, com a função gnome_config. A API para fazer isso já está disponível na biblioteca libgda-common, então isso seria muito fácil de ser feito. Voluntários? Ferramentas tipo linha-de-comando serão fornecidas com o &Libgda; para fazer uso do Libgda atualmente, você precisa saber quais informações são necessárias para se configurar um fonte de dados. Um dos problemas que GDA resolve é o processo de dar nomes as fontes de dados. Cada sistema de banco de dados tem a sua própria maneira de definir nomes para as fontes de dados. Por exemplo, MySQL usa o hostname, número da porta, e nome do banco de dados. Outros bancos de dados, como Solid, usam apenas o hostname e número da porta. Não há suporte há múltiplos bancos de dados por servidor. Já que o cliente não precisa de todos estes detalhes, a configuração do &Libgda; define todas as informações de tal fonte de dados, de maneira que o servidor (de banco de dados) correto possa ser contactado. Esta informação é obtida pela biblioteca cliente e enviada ao provedor, que então, examina a informação e decide qual banco de dados o cliente deve se conectar. A informação armazenada para cada fonte de dados é a seguinte: [vendas] Provider=gda-mysql DSN=DATABASE=teste;HOST=localhost;PORT=1111 Description=Banco de dados MySQL para testes em modo nativo Configurator=None O provedor para este banco de dados é o gda-mysql. O valor deste campo é usado como ID do objeto para ativação por parte do OAF. Este campo é o mais importante. O valor deste campor é a string enviada ao provedor para que ela saiba que fonte de dados acessar. Como este valor é interpretado por um determinado provedor é descrito na seção relacionada ao mesmo. Este campo é uma breve descrição da fonte de dados. Ele existe por pura conveniência e não tem nenhuma outra função. Esta seção traz informação específica a cada tipo de provedor disponível para &Libgda;. A biblioteca comum contêm um rico conjunto de funções de utilidade a ambos servidores e clientes GDA, e que pode facilmente ser utilizado em outras aplicações. Com objetivo de esconder todo código CORBA, o arquivo libgda-common inclui um conjunto de funções que oferecem acesso de baixo nível (low-level) a parte CORBA, em caso de você precisar fazer algo especial. A facilidade de logging provida pela pela biblioteca comum GDA usa um formato de arquivo especial que permite um fácil obtenção de todas as mensagens registradas. Desta maneira, você pode ver seus logs por data, hora, remover entradas, etc. &Libgda; oferece um formato de arquivo XML especial concebido para representar a estrutura completa de um banco de dados. Este formato de arquivo é usado para importar/exportar dados de/para um banco de dados. Este formato é usado também pelo (ainda não existente) provedor XML, que simula um sistema de banco de dados usando os dados armazenados nesses arquivos. A biblioteca gda-common inclui um classe, chamada GdaXmlDataabse, que oferece uma maneira de ler e modificar estes arquivos. A biblioteca cliente "embrulha" a interface CORBA. A biblioteca cuida de alocação e liberação de memória quando você não precisa mais dos resultados de uma consulta, ou quando você fecha a conexão com o banco de dados. Sua segunda função é fazer caching, de maneira que é possível navegar para frente e para trás dentro do resultado obtido com uma consulta, mesmo que o banco de dados não suporte um "cursor móvel" (scrolling cursos). É claro que as verificações de consistência e estratégias de locking não são mais suportadas, acreditamos, porém, que acharemos uma outra solução para isso. Há também suporte para controlar diferentes fontes de dados com diferentes servidores e características de conexões. Para atingir este ponto o sistema de configuração GConf é usado. Existe também funções utilitárias para ajudá-lo com as várias tarefas relacionadas com bancos de dados. Essas incluem execução de comandos em série (transações), acesso a provedores GDA, ... O conceito fundamental da biblioteca cliente é que o provedor deve permitir que você conecte-se a várias fontes de dados. Tal provedor é um servidor corba implementado com ORBit. Um provedor deve prover uma interface para construção de conexões (factory interface), que permite ao cliente solicitar ao servidor conexões não inicializadas. A ativação do provedor é feita através do sistema de ativação OAF. OAF cuida da identificação do 'name server' e da registração do servidor CORBA (o provedor GDA), uma vez que este está ativo. OAF também permite ao cliente escolher, se para cada nova conexão construída um novo servidor deve ser inicializado ou se um já em execução deve ser utilizado. Isto tráz implicações ao tempo necessário usado para iniciar a conexão e ao número de processos conectados ao servidor de bancos de dados (e por sua vez, o número de licenças em uso, no caso de um banco de dados não livre). Para se conectar a uma fonte de dados, o cliente geralmente deve passar alguma informação ao provedor. Primeiro o cliente deve passar uma string descrevendo a conexão para o provedor. O provedor usa esta informação de maneira específica para para completar as informações necessárias para estabelecer uma conexão com a fonte de dados. Essa informação pode ser o nome do computador (hostname) e número da porta, o nome da biblioteca a ser carregada, enfim, o que for necessário para a fonte de dados ser acessada. Adicionalmente o cliente deve passar o nome do usuário e um senha para ser autorizado a acessar o servidor da fonte de dados. O provedor não faz nenhuma verificação quanto a autenticação. Note também, que que a conexão entre o o cliente e o servidor não é encriptada, ou seja, esse dados são enviados como texto puro e simples. Isso não será mais verdade uma vez que ORBit suporte conexões encriptadas entre um servidor CORBA e seus clientes. Se esse procedimento não é aceitável, use o provedor em forma de biblioteca compartilhada. Depois que a conexão é aberta, o cliente pode solicitar a fonte de dados informação sobre o dicionário de dados. As semânticas dos dados retornados de tais consultas é altamente dependente do provedor e geralmente não é portável entre diferentes tipos de fontes de dados. Se os provedores pertecem a mesma classe (bancos de dados, por exemplo), essa informação será trocada entre ambos, mas não espere que o mesmo programa consultando um provedor LDAP e um provedor ODBC sem mudanças no código fonte. O cliente pode entrar criar objetos GdaCommanda que são usados para fazer as consultas aos provedores. Para provedores tipo SQL, a consulta é o comando SQL. É claro que o provedor é livre para alterar os estes comandos (conversão entre dialetos SQL) e alguns provedores tem sua própria linguagem de consulta (o provedor LDAP é um desses). É também possível chamar funções armazenadas no banco de dados (stored procedures). Essas funções devem ser implementadas no sistema de banco de dados ou implementadas pelo provedor. O resultado de uma consulta é acessado através de objetos de tipo GdaRecordset. Os dados resultados da consultados podem estar armazenados no cliente, no provedor ou no servidor de banco de dados. Isso depende de várias opções (flags) usadas quando o conjunto de registros (recordsets) é criado. Posições em um conjunto de registros são definidos através de marcadores (bookmark), que é um tipo de dado opaco. Um marcador pode ser usado para posicionar o ponteiro de acesso atual em um conjunto de registros. Uma vez que alguns sistemas de bancos de dados não permitem posicionamento arbitrário do ponteiro de acesso no resultado de uma consulta, o provedor armazena e guarda todas linhas obtidas. Se um conjunto de registros é configurado para armazenar os dados no cliente, então o marcador é um simples ponteiro para essas linhas. Você pode ler mais sobre armazenamento de linhas de dados, caching e transações na seção sobre conjunto de registros. A classe principal em GDA é a GdaConnection. Objetos desta classe estabelecem conexões com o servidor CORBA e são necessários para quase tudo que o cliente vai fazer. Cada objeto tem um pointeiro direto ou indireto a um desses objetos. Outra classe muito importante é a GdaCommand. Ela é usada para armazenar uma string com um comando e também para executar este comando no servidor CORBA. Esta classe mantém uma referência ao objeto de conexão. A execute retorna um objeto de classe GdaRecordset. Esta classe é responsável por buffering e caching e gerencimento de memória dos dados retornados pelo servidor. Um problema que GDA tenta esconder do usuária é a dirença nos tipos de dados que são armazenados nos bancos de dados e como eles são usados pela aplicação. Um exemplo bem característico é a representação de preços. Estes são números de ponto flutuante com dois dígitos depois do ponto decimal. A maioria dos bancos de dados lhe permite especificar um tipo de dado DECIMAL com um tamanho e precisão definidas. Em C não existe um tipo de dado equivalente. Você pode querer guardar esse valor em uma string, que é também conveniente para ser exibido, mas não é nada conveniente para calcular juros, por exemplo. Por isso GDA transforma o tipo de armazenamento do tipo da coluna para o tipo que o usuário quer. Isto é feito através do tipo (GDA_Type) de um valor. Se o banco de dados tiver a capacidade de converter diferentes tipos de dados ela é usada. Se não, a conversão é feita no cliente. Converter os dados no servidor pode levar a resultados imprevisíveis quando o servidor é uma máquina de 64bits e o cliente é uma máquina de 32 bits. Aqui está um lista dos tipo de dados GDA, e seus equivalentes em C e SQL, e as conversões permitidas. Todas fontes de dados devem prover funções que dêem acesso a suas meta-informações. Se a fonte de dados é um banco de dados, tal meta-informação é o nome das tableas, colunas, permissões dos usuários, etc. O resultado de uma consulta a meta-informação de uma fonte de dados é representada através do GdaRecordset. O problema é que na maioria das vezes o cliente está interessado em apenas parte dessa informação. O cliente quer consultar a fonte de dados sobre os índices de uma tabela, e não de todas as tabelas. Por isso é possível passar limitantes na consulta a meta-informações. Isso se complica mais ainda pelo fato de que cada consulta pode querer impor diferentes limitantes. A listagem a seguir mostra que tipos de consultas são implementadas e quais limitantes são válidos para cada consulta. Os limitantes são passados em pares de nome-valores. O nome é um enum e o valor é uma string. A função que implementa a consulta é uma função com números de argumentos variáveis e a lista de argumentos deve ser fechada com um enum de valor 0. A tabela a seguir mosta os limitantes mais usados e quando usá-los. Alguns esquemas podem requerer que você aplique um limitante. Limitantes Uso Observações GDA_Connection_OBJECT_CATALOG Usado para especificar-se o banco de dados GDA_Connection_OBJECT_SCHEMA Usado para especificar-se o dono GDA_Connection_OBJECT_NAME Usado para especificar-se o nome do objeto a consultar (tabela, ...) GDA_Connection_EXTRA_INFO Ative-o para obter informação detalhada do provedor Use uma string não nula (exemplo: "") A tabela que segue mostra os esquemas "padrões" que devem ser suportados por cada provedor GDA, entretanto um provedor específico pode não suportar alguns desses. Para testar se um esquema é suportado, veja a função gda_connection_supports(). Tipo de Objeto Identificador GDA Limitantes Suportados Campos Retornados Informação Extra Tabelas GDA_Connection_GDCN_SCHEMA_TABLES GDA_Connection_OBJECT_NAME, GDA_Connection_OBJECT_CATALOG, GDA_Connection_OBJECT_SCHEMA, GDA_Connection_EXTRA_INFO nome, comentários nome, dono, comentários, definição SQL Tabelas pais (para provedores que suportam parentesco) GDA_Connection_GDCN_SCHEMA_TAB_PARENTS GDA_Connection_OBJECT_NAME (required), GDA_Connection_OBJECT_CATALOG nome, ordem de parentesco Não Suportado Views GDA_Connection_GDCN_SCHEMA_VIEWS GDA_Connection_OBJECT_NAME, GDA_Connection_OBJECT_CATALOG, GDA_Connection_OBJECT_SCHEMA, GDA_Connection_EXTRA_INFO nome, comentários nome, dono, comentários, definição SQL Colunas de uma tabela (ou view) GDA_Connection_GDCN_SCHEMA_COLUMNS GDA_Connection_OBJECT_NAME (required), GDA_Connection_OBJECT_CATALOG, GDA_Connection_OBJECT_SCHEMA, GDA_Connection_COLUMN_NAME nome, tipo, tamanho, precisão, anulável (poder ser nulo), é chave, valor padrão, comentários Não suportado Sequências GDA_Connection_GDCN_SCHEMA_SEQUENCES GDA_Connection_OBJECT_NAME, GDA_Connection_OBJECT_CATALOG, GDA_Connection_OBJECT_SCHEMA, GDA_Connection_EXTRA_INFO nome, comentários nome, dono, comentários, definição SQL Procedimentos GDA_Connection_GDCN_SCHEMA_PROCS GDA_Connection_OBJECT_NAME, GDA_Connection_OBJECT_CATALOG, GDA_Connection_OBJECT_SCHEMA, GDA_Connection_EXTRA_INFO nome, Id do objeto, comentários nome, Id do objeto, dono, comentários, número de argumentos, definição SQL Parâmetros para procedimentos GDA_Connection_GDCN_SCHEMA_PROC_PARAMS GDA_Connection_OBJECT_NAME (necessário) Uso(entrada, saída or entrada/saída), tipo Não Suportado Agregados GDA_Connection_GDCN_SCHEMA_AGGREGATES GDA_Connection_OBJECT_NAME, GDA_Connection_OBJECT_CATALOG, GDA_Connection_OBJECT_SCHEMA, GDA_Connection_EXTRA_INFO nome, Id do objeto, tipo entrada, comentários nome, Id do objeto, tipo entrada, dono, comentários, definição SQL Tipos GDA_Connection_GDCN_SCHEMA_PROV_TYPES GDA_Connection_OBJECT_NAME, GDA_Connection_OBJECT_CATALOG, GDA_Connection_OBJECT_SCHEMA, GDA_Connection_EXTRA_INFO nome, dono, comentários, tipo Gda, tipo provedor nome, comentários Você deve prestar atenção especial para os limitantes usados (em aplicações clientes e em provedores GDA), porque é necessários que os limitantes retornem um erro se um limitante inválido for passado ao servidor. Isto é especialmente importante, uma vez que há esquemas que podem ter significados diferentes dependendo no conjunto de limitantes usado. Como você pode imaginar, isso pode levar a uma situação onde o cliente acaba recendo dados que ele não solicitou. A biblioteca cliente oferece um objeto muito interessante: GdaBatch, que é uma classe que permite que você trate uma série de objetos como um única entidade. Ela oferece este recurso com suporte real a transações (se o banco de dados sendo usado suportar). As alterações no banco de dados só são efetivadas se nenhum erro ocorrer, e consequentemente, caso um erro seja retornado pelo banco de dados, a execução do mesmo é cancelada. Este modelo lhe oferece suporte similar a transações em suas aplicações com apenas algumas linhas de código. Porém, o objeto GdaBatch é flexível bastante para ser usado como um simples conjunto de comandos, ignorando erros se é o que o você quer, e desabilitando o suporte a transações do seu banco de dados. Nesse caso, a melhor maneira de usar o objeto é conectá-lo á seus diferentes sinais, o que lhe permite saber a qualquer momento o status da execução de cada comando. Aplicações clientes GDA podem ser de dois tipos: Aplicações que fazem uso das biblioteca cliente &Libgda. Estes são os mais comuns, sendo de uso claro e fácil, uma vez que eles escondem todo a complexidade do CORBA com uma API fácil de usar. Clientes CORBA. Voce pode querer desenvolver um aplicação cliente CORBA em uma outra linguagem ou em uma outra plataforma com uma implementação CORBA ORB diferente. Nesse caso, você teria que gerar os stubs do cliente usando seu compilador de IDL para compilar os arquivos IDL que acompanham &Libgda;. Se você for fazer algo desse tipo, entre em contato com os desenvolvedores da &Libgda; para que possamos saber como o programa se portaria sob essas circunstâncias. Há um scipt chamado gda-buildclient que cuida de todas as bibliotecas necessárias para criar-se uma aplicação cliente GDA. Isso é que tudo que ele faz, então você achar que não vale apena usá-lo, mas ele é incluído por sua simplicidade. Uma invocação típica do script seria mais ou menos assim: gda-buildclient --o cliente --f <lista de arquivos .o > [--l <lista de bibliotecas adicionais>] [--L <lista de diretórios para procurar por bibliotecas>] Para mostrar como fazer isso, o compilador IDL JAVA será usado como exemplo. Como você já deve saber se você quer escrever um cliente CORBA, um arquivo IDL é usado para definir as interfaces oferecidas pelo servidor CORBA. Este arquivo IDL é usado por um programa chamado de "compilador IDL" para criar stubs para os clientes e skeletons para os servidores implementado a interface ORB particular. &Libgda; oferece um arquivo IDL que define todas as interfaces exportadas. Este arquivo é chamado gda.idl e pode ser encontrado junto na distribuição padrão do &Libgda;. O compilador IDL é o que você vai precisar para gerar, neste caso, os stubs para o cliente. Então, por exemplo, usando o compilador de IDL JAVA, você executaria o comando: java-idl gda.idl Isso resultaria em uma séria de arquivos .java. Estes são executáveis ou bibliotecas compartilhadas fazendo todo o trabalho de conversão. Eles mapeam as chamadas feitas as funções CORBA para a as funções específicas de uma fonte de dados. Estes podem usar ODCD, uma biblioteca nativa para o banco de dados, geradores e leitores de XML, LDAP, POP3, o que você possa imaginar. Há muito trabalho envolvido em provedores GDA, especialmente se a fonte de dados não é um banco de dados. Nesse caso, além de mapear a API para o modelo GDA, atenção especial tem que ser tomada para mapear a estrutura tipo banco de dados para uma estrutura diferente. Em ambos os casos, essa é a parte mais complexa da arquitetura GDA. Existe um conjunto de ferramentas oferecidos com &Libgda; para facilitar o processo de adicionar um novo servidor. Isso é feito principalmente através de um script chamado gda-buildserver, que pode ser usado para criar um estrutura básica para se criar um novo provedor, e também para compilá-lo. Se você escrever um novo provedor entre em contato com os desenvolvedores da &Libgda; para conversar sobre a sua inclusão no código oficial do &Libgda;. Outra maneira de criar-se um provedor GDA, seria usar os arquivos IDL para gerar a implementação de um servidor. Desta maneira você pode escrever o provedor na sua linguagem e implementação CORBA ORB preferida. Se você quer fazer algo desse tipo, por favor entre em contato com os desenvolvedores da &Libgda;. O objetivo da biblioteca gda-server é esconder do programador toda a complexidade CORBA para o desenvolvimento de provedores e elimina a duplicação de trabalho e leva a código muito mais fácil de ser depurado. A biblioteca fica no mesmo nível da biblioteca gda-server do ponto de vista CORBA. A biblioteca gda-server impõe uma certa estrutura na maneira que provedores devem ser implementados, mas também permitem customização. Todos objetos aqui são espécies de espelhos dos objetos da biblioteca gda-cliente, formando a parte servidor da estrutura CORBA da &Libgda;. o objeto GdaServerConnection: este é o objeto mais importante e cuida de toda a parte da conexão a fonte de dados (no caso de um banco de dados, o nome do banco de dados, usuário, senha, etc). Geralmente o cliente apenas usa um desse tipo de objeto. o objeto GdaServerCommand: este objeto é usado para preparar uma consulta para ser executada. o objeto GdaServerRecordset: cada vez que um comando é executado, um desses objetos é retornado, e podem ser examinados para ver-se os resultados do comando. Sob a &Libgda;, um conjunto de registros é examinado de maneira sequêncial, linha após linha (para alguns sistemas de banco de dados essa é a maneira que os resultados de uma consulta são manuseados, enquanto em outras, existe a possibilidade de acessar os resultados de maneira randômica). o objeto GdaServerField: para cada coluna, um desses objetos é usado. Ele descreve o nome da coluna, o tipo de dado, e seu conteúdo. Cada objeto GdaServerField é inicializado quando o conjunto de registros é criado, e seu valor será atualizado cada vez que uma nova linha é examinada. O gda-server usará estes objetos para enviar o conteúdo para o cliente CORBA. Isso é o que acontece do lado do servidor quando um cliente faz uma consulta: 1- um GdaServerConnection é criado 2- a conexão é aberta 3 - um GdaServerCommand é criado 4 - o comando é colocado no objeto GdaServerCommand 5- o comando é executado, e se nenhum erro ocorrer, um objeto GdaServerRecordset é criado e retornado 6 - o GdaServerCommand pode ser destruído sem problemas 7- a primeira linha do conjunto de registror pode ser examinada, então a segunda, terceira, etc 8- o GdaServerRecordset é destruído 9- a conexão é fechada, e o GdaServerConnection pode ser destruído. Todos os passos descritos acima são impostos pela estrutra &Libgda;. A implementação de um provedor para um tipo específico de banco de dados é, na verdade, a implementação de cada um dos passos descritos acima. Como a biblioteca C para um certo sistema de banco de dados usa estruturas específicas (para lidar com referências de conexões, etc) é possível anexar alguma informação aos objetos da biblioteca gda-server. Então geralmente o implementador do provedor define as seguintes estruturas (substitua DBMS, DataBase Management System, pelo nome do seu banco de dados, como por exemplo MYSQL ou POSTGRES): a estrutura de conexão é geralmente chamada de DBMS_Connection a estrutora de comando é geralmente chamada de DBMS_Command a estrutora de conjunto de registros é geralmente chamada de DBMS_Recordset Nessa seção estão algumas recomendações de como lidar com problemas específicos de cada sistema de banco de dados. &Libgda; tem alguns tipos de dados definidos, cobrindo todos os tipos de dados comuns (strings, números, datas, binários, etc). Entretando, porque cada sistema de banco de dados tem tipos específicos de dados (como, por exemplo, array, endereços IP), e as vezes é possivel criar tipos de dados personalizados, &Libgda; não pode ter conhecimento de todos tipos de dados. Então, para os tipos mais comuns onde um tipo de dado &Libgda; existe, este será usado, e de maneira contrária, o tipo GdaTypeUnknown será usado (o uso correto destes dados fica por conta do programador da aplicação). Sob a &Libgda;, a aplicação cliente não tem como saber a qual sistema de banco de dados ela está conectada, mas ela pode saber se tal sistema suporta certos recursos e quais são as tabelas, índices, etc, contidas no banco de dados. Uma das tarefas que mais consomem tempo é escrever funções que retornem respostas a todos essas solicitações do cliente. O trabalho básico a ser feito é implementar um conjunto de funções necessários para que a biblioteca gda-server manipule o provedor. Quanto um provedor quer iniciar, ele tem que dar ponteiros a estas funções em uma estrutura (veja o arquivo main-DBMS.c para isso). O outro conjunto de funções a implementar são relacionados com solicitações de esquemas. Entre as funções que você DEVE implementar está um função para solicitar esquemas. Esta função pode ser implementada da maneira que você quiser, mas uma prática comum (usado em todos provedores 'padrões' da &Libgda;) é fazer com que esta função, chame outras funções dependendo do tipo de esquema solicitado pela aplicação cliente. Geralmente um provedor tem apenas um header (gda-DBMS.h) que contém todas as definições de estruturas e declarações de funções. Este header precisa incluir o arquivo gda-server.h. O provedor também precisa os elementos comuns da biblioteca gda-common (para parte de XML, etc... quando estiver pronta). Geralmente há apenas um arquivo .c para a implementação das diferentes estruturas de um sistema de banco de dados, como mencionado acima, exceto pelo objeto GdaServerField que é totalmente controlado pela biblioteca gda-server, e um para o programa. Você pode dar uma olhada nos provedores distribuídos com &Libgda;, que fazem uso desta biblioteca. O provedor PostgreSQL é especialmente interessante, pois é um bom exemplo de customização de provedor. Este inclui funcionalidade extra não presente em outros provedores como os "buil-in recordsets", que são usados para obter-se dados diretamente, não sendo este um valor retornado pelo PostgreSQL.