Integração de Sistemas de Bancos de Dados Heterogêneos Usando Frameworks

Integração de Sistemas de Bancos de Dados Heterogêneos Usando Frameworks Elvira Maria Antunes Uchôa e Rubens Nascimento Melo Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro, Brasil {elvira, rubens}@ inf.puc-rio.br

Resumo Este trabalho apresenta uma visão geral do framework HEROSfw, com ênfase em seus componentes e hot spots. Trata-se de um framework orientado a objetos para a construção de sistemas de gerência de bancos de dados heterogêneos. Uma discussão detalhada de sua implementação também é apresentada.

1. Introdução Um sistema de gerência de bancos de dados heterogêneos (SGBDH) precisa ter a capacidade de integrar novos tipos de sistemas, novas plataformas de hardware e software, novas formas de comunicação sem que seja necessário reestruturar seu projeto e implementação existentes. Sistemas de bancos de dados heterogêneos (SBDHs) têm sido apontados como uma das soluções mais viáveis para a integração de sistemas existentes, autônomos e diferentes, sem a necessidade de alterá-los. A técnica de framework oferece a infra-estrutura adequada para o atendimento de tal requisito, já que um framework é um (sub)sistema de software, de um domínio particular, que pode ser ajustado para aplicações individuais. Um framework consiste em uma grande estrutura que pode ser reutilizada, como um todo, para a construção de um novo sistema, o que representa, no contexto de sistemas de bancos de dados heterogêneos, cada nova federação. Este trabalho apresenta um framework para integração de sistemas de bancos de dados heterogêneos, com base na experiência de desenvolvimento [1], no Departamento de Informática - PUC-Rio, do HEROS - sistema de gerência de bancos de dados heterogêneos. O restante deste trabalho está organizado da seguinte forma. Na seção 2, a motivação para o desenvolvimento do framework HEROSfw é descrita. Nas seções 3, 4 e 5, o framework HEROSfw, seus principais componentes e hot spots, bem como sua implementação são detalhados. Na seção 6, alguns projetos correlatos a este são mencionados. Finalmente, na seção 7, o status corrente da pesquisa e alguns passos futuros são comentados. 2. Breve histórico do projeto HEROS - HEteRogeneous Object System é um SGBDH orientado a objetos, em desenvolvimento no Departamento de Informática da PUC-Rio que, em termos da classificação apresentada em [2], é caracterizado por um acoplamento forte [3]. Os sistemas de banco de dados (SBDs) componentes podem diferir quanto ao sistema de gerência de banco de dados (SGBD), modelo de dados, ambiente computacional e localização física

(interligados, então, por sistemas de comunicação). No HEROS, foram definidos seu modelo de dados integrador que é orientado a objetos [4], os mecanismos e sistemática para integração de esquemas [5], modelo e gerência de transação global [6] e tratamento de heterogeneidades [5]. Uma análise comparativa entre o HEROS e alguns projetos de SGBDHs é encontrada em [5], [6] e [7]. Em uma primeira versão, o sistema de gerência de transações do HEROS foi desenvolvido como um conjunto de módulos funcionais [6] e implementado como funções na linguagem de programação C, em ambiente UNIX, no laboratório do Departamento de Informática (Lab-DI) da PUC-Rio. A comunicação entre módulos remotos foi implementada como chamada de procedimentos remotos (RPC). Em [7], há um resumo da primeira versão do HEROS, são analisadas as vantagens de reestruturá-lo para uma arquitetura composta por classes de objetos, usando uma implementação do CORBA para efetuar a comunicação entre os componentes remotos, e é efetuada uma análise comparativa do HEROS, em relação a alguns projetos de SGBDH que também usam CORBA em sua arquitetura. Os detalhes de sua implementação estão disponíveis em http://www.inf.puc-rio.br/~tecbd/heros. Várias federações foram desenvolvidas, cada uma delas exigindo uma nova extensão da arquitetura do HEROS: a primeira [8] incorporou três tipos de SBD componente: Oracle (vs. 6.0), Postgres (vs. 4.0) e o banco de dados nativo do HEROS. A segunda [9] integrou o tipo de sistema componente Acervo de Internet/Intranet e Oracle (vs. 7.3.2); enquanto que a terceira federação [10] incorporou o tipo de SBD componente Legacy System. O desenvolvimento destas tantas aplicações, usando o HEROS, apontou uma série de limitações e desafios em sua arquitetura: ⇒ HEROS, por definição, pode ser estendido para integrar qualquer sistema componente mas a informação de que componentes de sua arquitetura devem ser estendidos/adaptados não é claramente assinalada na documentação do projeto, exigindo uma imersão na documentação para obtê-la; ⇒ Caso se deseje alterar o sistema de comunicação substituindo, por exemplo, CORBA por DCOM seria necessário reestruturar novamente todo o sistema, como aconteceu no caso da mudança de RPC para CORBA, o que não é coerente, já que o núcleo da arquitetura do HEROS continuaria o mesmo, só sofrendo alterações no sistema de comunicação; ⇒ A documentação do projeto HEROS está organizada a nível de classes de objetos, o que implica em um alto grau de detalhamento em seus modelos. Para a compreensão do funcionamento do HEROS e para sua instanciação em federações, não seria necessário o conhecimento do HEROS a este nível, bastando a visualização de seus componentes e a indicação de que pontos podem ser estendidos/adaptados/configurados para construir uma nova federação. Considera-se componente, neste contexto, a parte encapsulada de um sistema de software, que disponibiliza serviços, e que é utilizado como “building blocks” para a construção de sistemas, de forma transparente a como ele está implementado [11]. Enfim, o principal problema detectado é a necessidade de reutilizar a arquitetura do SGBDH HEROS (tanto código quanto projeto) para construir diferentes federações, permitindo, no entanto, a escolha ou redefinição de determinados componentes da arquitetura, para atender a particularidades de cada federação. A técnica de reuso orientada a objetos framework é proposta como solução para tal requisito. 3. O framework HEROSfw Bushmann et al. [11] definem framework como sendo um (sub)sistema de software (implementado em uma linguagem de programação), parcialmente completo, criado com o

objetivo de ser instanciado. Um framework define uma arquitetura para uma família de sistemas e fornece blocos básicos predefinidos para sua construção. Também define as partes que devem ser adaptadas para realizar uma funcionalidade específica. Em um ambiente orientado a objetos, um framework é composto de classes abstratas e concretas e sua instanciação consiste de composição e herança de classes. Normalmente, as classes concretas devem ser invisíveis para o usuário do framework. De acordo com [12], um framework consiste em frozen spots e hot spots. Frozen spots definem a arquitetura global de um sistema de software – seus componentes básicos e os relacionamentos entre eles. Eles permanecem imutáveis em qualquer instanciação do framework. Hot spots representam aquelas partes do framework que são específicas para cada sistema de software. Hot spots são projetados para serem genéricos – eles podem ser adaptados para as necessidades da aplicação em desenvolvimento. Quando se cria um sistema de software concreto, usando um framework, seus hot spots são preenchidos de acordo com as necessidades e requisitos específicos do sistema. O framework HEROSfw [13] tem por objetivo possibilitar a instanciação de softwares (SGBDHs) que permitam que um conjunto de sistemas de bancos de dados heterogêneos, cooperativos mas autônomos, sejam integrados de tal forma em uma federação, que consultas e atualizações possam ser realizadas, de forma transparente à localização dos dados, aos caminhos de acesso e a qualquer heterogeneidade ou redundância que exista. O framework HEROSfw é composto por seis frameworks, isto é, seus componentes são outros frameworks (Figura 1). O framework HEROSfw está dividido em duas partes: global e local. A parte global é única e corresponde ao segmento do HEROSfw que interage com os usuários globais da federação. A parte local corresponde ao segmento do HEROSfw que interage com os SBDs componentes, devendo existir um segmento destes para cada local onde haja um SBD componente. Federação HerosFed. HerosFed.lib HotCom. HotCom.lib

regraG. regraG.lib iuG. iuG.lib

esquemaG. esquemaG.lib

Interface usuário Usuário global

comunicG. comunicG.lib

Regra

Esquema

transG. transG.lib

Comunicação

Consulta

Transação

consultaG. consultaG.lib Sistema componente 1

Sistema componente n

HerosComp. HerosComp.lib HotTrans. HotTrans.lib HotEsq. HotEsq.lib Regra

HerosComp. HerosComp.lib HotTrans. HotTrans.lib HotEsq. HotEsq.lib Esquema

Regra Comunicação

... Interface usuário

Consulta

Transação

comunicL. comunicL.lib esquemaL. esquemaL.lib Esquema

regraL. regraL.lib

Interface usuário iuL. iuL.lib

Consulta consultaL. consultaL.lib

Sistema componente ABD local

Comunicação

Transação transL. transL.lib

Sistema componente ABD local

Figura 1: Componentes do framework HEROSfw.

O framework Interface usuário é responsável pela comunicação do HEROS com o usuário final. Esta comunicação tanto ocorre para a criação de novas federações como para seu uso. Uma federação HEROS pode ser usada, ou através de chamada direta de procedimentos pertencentes ao esquema (global ou externo), ou através de consultas globais, na linguagem de consulta do HEROS (SQL-like). As consultas globais são derivadas a partir do processo de interação com o usuário, pelo framework Interface usuário, que também retorna ao usuário final os dados e as mensagens resultantes do processamento efetuado. Este framework também realiza a análise sintática das solicitações, detectando erros de sintaxe ou referências inválidas a objetos do esquema (externo ou global). O framework Esquema é responsável por gerenciar os esquemas do HEROS. HEROS usa uma arquitetura de esquemas em quatro níveis [14]: esquemas local e de exportação – um para cada SBD componente, esquema global e esquema externo. Cada esquema local possui a descrição dos objetos locais que se deseja compartilhar com a federação, segundo os conceitos do modelo de dados utilizado pelo respectivo SGBD. O esquema de exportação de cada local contém a descrição dos objetos locais compartilhados, expressa usando os conceitos do modelo de dados global do HEROS. O esquema global contém a descrição integrada dos objetos compartilhados pelos sistemas de banco de dados componentes. Cada esquema externo representa uma visão de aplicação do esquema global. O framework Consulta é responsável por: ⇒ derivar, a partir da consulta global recebida e do esquema global, as subconsultas que devem ser submetidas aos diversos sistemas de banco de dados componentes. As subconsultas são parte de um plano de execução da consulta; ⇒ produzir um plano de execução alternativo otimizado, com base no plano de execução e em dados adicionais sobre os SBDs componentes do HEROS. O framework Transação [6] submete consultas ou solicitações de execução de procedimentos globais aos respectivos locais. Este framework implementa operações de banco de dados necessárias para composição dos resultados parciais e armazenamento temporário de resultados. O controle da atomicidade da transação e a detecção e o tratamento de deadlocks globais também são funções deste framework. Além disso, este framework é responsável pela submissão e controle da execução das subtransações locais, bem como a criação do estado de "preparado" necessário ao protocolo de sincronismo que implementa a atomicidade das transações globais. O framework Comunicação [13] é responsável pela realização física da comunicação entre a federação e os sistemas componentes, isto é, ele é responsável pela conexão com os servidores distribuídos que representam os sistemas componentes integrados, detectando e reportando ao framework Transação qualquer problema relacionado com o acesso de dados remotos. O framework Regra é responsável por prover o HEROS de um comportamento ativo, isto é, da capacidade de reagir automaticamente à ocorrência de determinados eventos. Esta característica é utilizada, no HEROS, sobretudo, para a tradução dos modelos de dados dos SBDs componentes para o modelo de dados do HEROS, gerando automaticamente os esquemas de exportação, por ocasião da inclusão do sistema componente e seu respectivo esquema local. O uso do comportamento ativo durante o processo de execução de transações, embora seja um tópico bastante interessante, está fora do contexto deste trabalho, por ser um tópico de pesquisa em aberto, apesar de previsto [5] no modelo de dados do HEROS. O aspecto dinâmico do framework HEROSfw [13] foi representado usando Modelo de

Caso de Uso e Diagrama de Interação de Jacobson [15], enquanto que seu aspecto estático foi representado usando Diagrama de Classes de Rumbaugh [16]. A modelagem foi realizada com o auxílio da ferramenta CASE Select Enterprise [17]. Para a implementação, usou-se a linguagem de programação C++. 4. Hot spots do framework HEROSfw O framework HEROSfw pode ser estendido quanto a três quesitos, que correspondem a seus hot spots: ⇒ Modelo de dados do sistema componente - com o intuito de que o esquema local do SBD componente possa ser automaticamente traduzido para o modelo de dados do HEROS (esquema exportação), através do disparo de regras de mapeamento; ⇒ Tipo de comunicação entre a federação e o SBD componente - o framework já oferece como opções as formas RPC, ORB e chamada direta, como resultado de experiências anteriores usando o HEROS, no entanto podem ser definidas outras modalidades de comunicação como DCOM da Microsoft; ⇒ Gerência de transação local - com o intuito de permitir que SBDs componentes relativos a diferentes tipos de SGBDs possam ser atualizados a partir da federação, conservando a integridade das operações globais, isto é, das operações que envolvem vários SBDs componentes. Cada um destes quesitos está detalhado a seguir. 4.1. Hot spot Modelo de dados Para integrar um novo tipo de modelo de dados à arquitetura do HEROS, é necessário se ajustar o framework Esquema da seguinte forma: 1. definir uma classe especializada da classe Esquema local, que defina as características [5] do modelo de dados a ser integrado (Figura 2). O esquema local dos SBDs componentes deste tipo corresponderão a objetos destas classes. Estrutura dados local 1+ Esquema local + Criar_esquema_local

1+ Procedimento local

Esq - modelo relacional

Esq - modelo ER

Esq - modelo OO

+ Criar_esquema_local

+ Criar_esquema_local

+ Criar_esquema_local

Figura 2: Diagrama de classes – Hot spot Modelo de dados local

2. criar um objeto na classe Tipo modelo dados, que represente o novo modelo de dados. A este objeto serão associadas as regras de mapeamento (framework Regra), que devem ser definidas para converter os conceitos do novo modelo de dados local para o modelo de dados do HEROS (Figura 3).

Framework Regra Regra 1+ regra mapeamento Framework Esquema

Tipo modelo dados componente

Tipo modelo dados - id_tipo_modelo_dados + Criar_tipo_modelo_dados

referência

1+

- id_tipo_modelo_dados - nome_componente - nome_federação + Criar_esquema_local + Criar_tipo_modelo_dados_componente - Obter_tipo_modelo_componente

possui

Esquema local + Criar_esquema_local Esquema exportação + Criar_esquema_exportação + Criar_árvore_local + Exec_proc_export

Sistema componente - nome_componente - nome_federação + Criar_esquema_exportação + Criar_esquema_local + Criar_sistema_componente + Criar_árvore_local + Exec_proc_export

Figura 3: Diagrama de classes – Tipo modelo dados

3. definir as regras (framework Regra) de mapeamento do novo modelo de dados para o modelo de dados orientado a objetos do HEROS (Figura 3). Ao se incluir o novo sistema componente como objeto da classe Sistema componente, deve-se associar a ele o tipo que corresponde a seu modelo de dados (classe Tipo modelo dados componente). Assim, quando se incluir seu esquema local, automaticamente as regras de mapeamento serão disparadas e o esquema de exportação será criado. 4.2. Hot spot Comunicação Para integrar um novo tipo de comunicação à arquitetura do HEROSfw (Figura 4), é necessário se ajustar o framework Comunicação da seguinte forma:

parte global

Tipo comunicação - id_tp_comunicação referência

1+

Comunicação cliente

Tipo comunicação componente - id_tp_comunicação - nome_componente - nome_federação + Criar_sistema_componente - Criar_tipo_comunicação_componente - Obter_tipo_comunicação + Solicitar_serviço_remoto

possui

associação

+ Criar_sistema_componente + Serviço_remoto {abstract} + Solicitar_serviço_remoto

Cc-rpc

Cc-orb

Cc-chamada direta

+ Serviço_remoto

+ Serviço_remoto

- nome_exec_servidor + Serviço_remoto

parte local Comunicação servidor + Gerência_local

Sistema componente - nome_componente - nome_federação Cs-rpc + Gerência_local

Cs-orb + Gerência_local

Framework Esquema

Cs-chamada direta + Gerência_local Framework Comunicação

Figura 4: Diagrama de classes – Hot spot Comunicação

1. definir uma classe especializada da classe Comunicação cliente para desempenhar o papel de cliente na comunicação da federação com o sistema componente. O método Serviço_remoto, invocado pela gerência global da federação, tem que ser redefinido, para estabelecer a comunicação com o componente remoto (servidor). 2. criar um objeto na classe Tipo comunicação, que represente o novo tipo de comunicação. 3. acrescentar, ao type_s_msg Tipo_comunicacao_componente::Solicitar_servico_remoto (type_e_msg par_entrada) método { Solicitar_serviç type_s_msg par_saida; int tp_com; o_remoto da classe Tipo Obter_tipo_comunicacao (par_entrada.local, &tp_com); comunicação switch (tp_com) { componente, a case 1: Cc_chamada_direta ocomcli_1; invocação do par_saida = ocomcli_1.Servico_remoto (par_entrada); procedimento break; case 2: Serviço_remoto Cc_orb ocomcli_2; para um objeto par_saida = ocomcli_2.Servico_remoto (par_entrada); da nova classe break; case 3: especializada da Cc_rpc ocomcli_3; classe par_saida = ocomcli_3.Servico_remoto (par_entrada); break; Comunicação } cliente (Figura return par_saida; } 5). A classe Figura 5: Implementação do serviço Solicitar_serviço_remoto Tipo

comunicação componente é responsável por identificar que especialização da classe Comunicação cliente deve ser usada para a comunicação com cada sistema componente. Ao se incluir o novo sistema componente como objeto da classe Sistema componente, deve-se associar a ele o tipo que corresponde a sua comunicação (classe Tipo comunicação componente), para que a classe adequada possa ser invocada, através do serviço Serviço_remoto. 4. definir uma classe especializada da classe Comunicação servidor para desempenhar o papel de servidor, na comunicação da federação com o sistema componente. O método Gerência_local, invocado pela classe Comunicação cliente, tem que ser redefinido. O método Gerência_local da classe especializada deve invocar o serviço Gerência_local da classe genérica Comunicação servidor, responsável por estabelecer a comunicação com os frozen spots locais. 4.3. Hot spot Transação Para integrar um novo tipo de gerência de transação local à arquitetura do HEROSfw (Figura 6), é necessário se ajustar o framework Transação da seguinte forma: Framework Esquema Sistema componente possui

- nome_componente - nome_federação

Framework Transação

Transação servidor

Tipo transação componente Transação cliente - id_aplic + Abort + Abort_R + Begin_trans_C + Begin_trans_P + Begin_trans_R + Begin_trans_T + Commit + Eliminar_comandos_compens + EOT + Exec_abort_sub + Exec_commit_sub + Exec_consulta_export + Exec_method + Exec_prepare + Exec_proc_compens + Exec_proc_export + Exec_query - Preparar_exec_oper_global - Preparar_exec_proc_export + Registrar_inicio_trans_compens

parte global

- id_tp_gerente_transação - nome_componente - nome_federação + Criar_tipo_transação_componente - Obter_tipo_transação + Solicitar_exec_abort + Solicitar_exec_commit + Solicitar_exec_oper 1+

referência

+ Abort_sub - Ativar_trans_local + Commit_sub + Criar_tipo_transação_componente - Desativar_trans_local + Exec_abort {abstract} + Exec_commit {abstract} + Exec_local_method + Exec_local_query + Exec_oper {abstract} + Exec_proc_local + Prepare - Re_submeter_comandos - Verificar_gerente_ativo

Tipo gerente transação - id_tp_gerente_transação

parte local

Ts-heros

Ts-oracle

Ts-postgres

+ Exec_abort + Exec_commit + Exec_oper

+ Exec_abort + Exec_commit + Exec_oper

+ Exec_abort + Exec_commit + Exec_oper

Figura 6: Diagrama de classes – Hot spot Transação

1. definir uma classe especializada da classe Transação servidor, redefinindo os procedimentos {Exec_oper, Exec_abort, Exec_commit} responsáveis por formatar as operações de submeter um comando (Exec_oper), aceitar (Exec_commit) e cancelar (Exec_abort) uma transação, de forma que sejam reconhecidas pelo SGBD local, submetendo os comandos derivados para execução e obtendo as respostas correspondentes. Caso exista diferença na forma de representação de dados pelo SGBD local e o HEROS, também devem ser efetuadas as respectivas conversões. 2. criar um objeto na classe Tipo gerente transação, que represente o novo tipo de gerência de transação local. 3. acrescentar aos métodos Solicitar_exec_oper, Solicitar_exec_commit e Solicitar_exec_abort (Figura 7) da classe Tipo transação componente, a invocação dos procedimentos Exec_oper, Exec_commit e Exec_abort, respectivamente, para um objeto

da nova classe especializada da classe Transação servidor. A classe Tipo transação componente é responsável por identificar que especialização da classe Transação servidor deve ser usada para acessar cada sistema componente. Ao se incluir o novo sistema componente como objeto da classe Sistema componente, deve-se associar a ele o tipo que corresponde a sua gerência de transação (classe Tipo transação componente), para que a classe adequada possa ser invocada, através dos serviços Exec_oper, Exec_commit e Exec_abort.

int Tipo_transacao_componente::Solicitar_exec_abort (type_local local) { int tp_trans; Obter_tipo_transacao (local, &tp_trans); switch (tp_trans) { case 1: Ts_heros otranserv_1; otranserv_1.Exec_abort () ; break; case 2: Ts_oracle otranserv_2; otranserv_2.Exec_abort (); break; case 3: Ts_postgres otranserv_3; otranserv_3.Exec_abort (); break; } return 1; }

Figura 7: Implementação do serviço Solicitar_exec_abort

4.4. Considerações finais Enfim, como visto nas seções anteriores, apenas as classes Tipo transação componente, Tipo modelo dados componente e Tipo comunicação componente precisam ter sua implementação ajustada/alterada no caso da extensão do framework, através de preenchimento de seus hot spots. Na verdade, cabe aos componentes cujo nome comece por Tipo..., descobrir para que classe especializada, escolhida por ocasião da instanciação da aplicação (criação da federação), as solicitações de serviço deverão ser enviadas e, logicamente, enviá-las. Todo o resto da implementação do framework HEROSfw mantém-se inalterável, por ocasião do desenvolvimento de uma nova aplicação (federação), sendo - o framework estendido apenas com a criação de classes especializadas, para os hot spots assinalados no projeto do framework que são: classes Comunicação cliente e Comunicação servidor - para o framework Comunicação; classe Transação servidor – para o framework Transação; e, classe Esquema local – para o framework Esquema. Caso se queira desenvolver uma aplicação, ou seja, criar uma federação HEROS, e os tipos de transação, modelo de dados e comunicação de seus sistemas componentes já tenham sido definidos para o framework HEROSfw, não há necessidade de qualquer ajuste/alteração no código do framework. Basta apenas, ao instanciar os sistemas componentes da nova federação, associá-los aos respectivos tipos, através da criação de objetos para as classes existentes. Neste caso, o framework HEROSfw funciona como um framework “caixa preta” [18]. 5. Implementação do framework HEROSfw O framework HEROSfw foi implementado na linguagem de programação C++. Os frameworks Consulta, Regra e Interface usuário não foram completamente implementados, no entanto foram incluídos como classes abstratas, afim de assinalar onde eles deverão ser incorporados, quando forem desenvolvidos. Detalhes desta implementação estão disponíveis em http://www.inf.puc-rio.br/~tecbd/heros. Na implementação do HEROSfw, foram criadas duas bibliotecas (Figura 1): ⇒ HerosFed.lib (Gerência global) - Esta biblioteca representa o componente global do framework HEROSfw, isto é, a visão da federação. Seu arquivo de cabeçalho é: Heros.h. Esta biblioteca deve ser usada na aplicação do usuário global, que deverá solicitar serviços

para a classe Heros. Caso seja desenvolvida uma interface gráfica para a submissão de consultas e criação de federações, esta também deverá usar tal biblioteca. Esta biblioteca abrange o segmento global dos frameworks Interface usuário, Esquema, Consulta e Regra, e o segmento cliente (ou global) dos frameworks Transação e Comunicação; cada um deles implementado como uma biblioteca à parte. A parte cliente (ou global) do framework Transação (biblioteca transG.lib) corresponde às classes {Transação cliente, Transação Raiz, Subtransação, Log global, Controle concorrência, Comando compensatório, Processo compensatório}. A parte cliente (ou global) do framework Comunicação (biblioteca comunicG.lib) abrange as classes: {Comunicação cliente, Ccchamada direta, Cc-orb, Cc-rpc}. A parte global do framework Esquema (biblioteca esquemaG.lib) abrange as classes: {Federação, Esquema externo, Esquema global, Classe global, Atributo global, Procedimento global, Árvore global, Dicionário dados}. Os frameworks Consulta (biblioteca consultaG.lib), Regra (biblioteca regraG.lib) e Interface usuário (biblioteca iuG.lib) não foram desenvolvidos, sendo apenas incluídos como classes abstratas, logo não é possível listar suas classes componentes. ⇒ HerosComp.lib (Gerência local) - Esta biblioteca representa o componente local do framework , isto é, o segmento do HEROSfw que deve existir em cada local onde houver um sistema componente a ser integrado à uma federação. Seu arquivo de cabeçalho é: Heros.h. Esta biblioteca deve ser usada pelo servidor de comunicação, que deverá solicitar serviços para a classe Comunicação servidor. Há necessidade de uma aplicação local, preferencialmente com interface gráfica, para a criação dos esquemas local e de exportação. Esta aplicação também deverá usar tal biblioteca, solicitando serviços para a classe Heros. Esta biblioteca abrange o segmento local dos frameworks Interface usuário, Esquema, Consulta e Regra, e o segmento servidor (ou local) dos frameworks Transação e Comunicação; cada um deles implementado como uma biblioteca à parte. A parte servidor (ou local) do framework Transação (biblioteca transL.lib) corresponde às classes: {Transação servidor, Ts-heros, Ts-oracle, Ts-postgres, Log local, Transação local}. A parte servidor (ou local) do framework Comunicação (biblioteca comunicL.lib) abrange as classes: {Comunicação servidor, Cs-chamada direta, Cs-orb, Cs-rpc}. A parte local do framework Esquema (biblioteca esquemaL.lib) corresponde às classes: {Sistema componente, Esquema exportação, Esquema local, Tipo modelo dados, Esq-modelo relacional, Esq-modelo oo, Esq-modelo relacional estendido, Classe exportação, Atributo exportação, Procedimento exportação, Árvore local, Estrutura dados local, Elemento dados local, Procedimento local}. Como os frameworks Consulta (biblioteca consultaL.lib), Regra (biblioteca regraL.lib) e Interface usuário (biblioteca iuL.lib), ainda não foram desenvolvidos, sendo apenas incluídos como classes abstratas, não é possível listar suas classes componentes. Além destas duas bibliotecas, existem três outras que foram criadas, só que estas são fornecidas juntamente com seu código fonte (em C++), e deverão ser alteradas a cada extensão do framework. São elas: ⇒ HotCom.lib (Hot spot Comunicação) – Esta biblioteca só precisa ser alterada quando se quiser usar um novo tipo de comunicação entre o componente global e local do framework HEROSfw. Ela é composta apenas pela classe {Tipo comunicação componente} que é responsável por invocar serviços da classe especializada da classe Comunicação cliente, encarregada de efetuar a comunicação com um determinado sistema componente. Esta biblioteca deve ser usada na aplicação do usuário global e na interface gráfica para a submissão de consultas e criação de federações. ⇒ HotTrans.lib (Hot spot Transação) – Esta biblioteca só precisa ser alterada quando se

quiser integrar, em uma federação, um sistema componente que use um novo tipo de gerência de transação. Ela é composta apenas pela classe {Tipo transação componente}, que é responsável por invocar serviços da classe especializada da classe Transação servidor, encarregada de submeter transações para um determinado tipo de sistema componente. Esta biblioteca deve ser usada pelo servidor de comunicação e pela aplicação encarregada da criação dos esquemas local. ⇒ HotEsq.lib (Hot spot Esquema) – Esta biblioteca só precisa ser alterada quando um novo tipo de modelo de dados for integrado ao framework HEROSfw. Ela é composta apenas pela classe {Tipo modelo dados componente}, que é responsável por invocar serviços da classe especializada da classe Esquema local, encarregada de representar o esquema local de um determinado tipo de sistema componente. Esta biblioteca deve ser usada pelo servidor de comunicação e pela aplicação encarregada da criação do esquema local. Na Figura 1, o framework Regra está sendo usado localmente para a tradução dos modelos de dados dos SBDs componentes para o modelo de dados do HEROS, gerando automaticamente os esquemas de exportação, por ocasião da inclusão do sistema componente e seu respectivo esquema local. A nível global, regra é usada pelo esquema global para gerenciar algumas heterogeneidades semânticas [5]. As setas que aparecem entrando no framework Esquema, a nível do módulo global, representam a criação da federação e, a nível do módulo local, representam a criação dos esquemas local. É justamente para este fim, que existe o framework Interface usuário no módulo local, e o porquê aparece, na Figura 1, o DBA local interagindo com o HEROSfw. 6. Trabalhos relacionados Na literatura, são encontrados uma grande quantidade de relatos de frameworks com os mais diferentes objetivos (interface com usuário – MVC [19]; sistema operacional - Choices [20]; sistema bancário - Gebos [21]; planejamento de transmissão de estação de TV (Bélgica) [22], dentre outros). No entanto, não foi encontrada qualquer descrição de um framework para integração de sistemas de bancos de dados heterogêneos. Quantos aos projetos de SGBDH relatados (Jupiter [23], VODAK [24], IRO-DB [25] e MIND [26], dentre outros), embora discutam a questão de extensibilidade, não utilizam a técnica de reuso framework em sua arquitetura. A vantagem de se utilizar esta técnica é que ela oferece toda um conjunto de conceitos que permite a clara identificação dos pontos de extensão/adaptação de uma arquitetura, tanto a nível de projeto quanto de código, além de suportar o preenchimento destes pontos, através da definição/escolha de componentes específicos para cada caso de instanciação do framework, isto é, de definição de federação, no contexto de SBDH. 7. Conclusão Na arquitetura dos SGBDHs, três características podem ser enfatizadas: interoperabilidade, já que os sistemas componentes de um SBDH tipicamente rodam em plataformas heterogêneas de hardware e software; distribuição, porque os sistemas componentes de um SBDH normalmente estão distribuídos fisicamente; e extensibilidade, já que um SGBDH deve poder integrar novos tipos de sistemas componentes, sem necessitar alterar o código que já estiver pronto. No Departamento de Informática da PUC-Rio, tem sido desenvolvido nos últimos anos um SGBDH – o HEROS. As questões de interoperabilidade e distribuição foram resolvidas, no projeto, com o uso de um padrão de interoperabilidade orientado a objetos. No entanto, a

questão de extensibilidade tem se apresentado como um dos grandes desafios no desenvolvimento do projeto, no que se refere à capacidade de criar novas federações, reaproveitando/reutilizando o projeto e implementação existentes. A solução considerada, neste trabalho, para esta questão foi a utilização da técnica de reuso framework. O framework HEROSfw foi utilizado no desenvolvimento de uma aplicação para uma holding de várias empresas que atuam nos ramos de transporte, armazenagem de containers de importadores (armazéns alfandegados) e guarda de móveis. Os SGBDs integrados foram Oracle vs. 7.3.2 e Informix, enquanto que o sistema de comunicação utilizado entre as partes global e locais do framework HEROSfw foi Visibroker, da Borland. No momento, as seguintes questões vêm sendo investigadas: desenvolvimento dos frameworks Interface usuário, Consulta e Regra; desenvolvimento do mecanismo de regras que provê a capacidade ativa do HEROS; integração de novos tipos de sistemas componentes, inclusive os que não sejam SBDs; desenvolvimento de design patterns para descrever a sistemática para instanciação do framework HEROSfw.

Referências Bibliográficas [1]

Uchôa, E.M.A.; Lifschitz, S. & Melo, R.N., “HEROS: a Heterogeneous Object Oriented Database System”, in Proc of the Ninth International Conference on Database and Expert Systems Applications (DEXA’98), Lecture Notes in Computer Science, n. 1460, pp. 223-230, Springer-Verlag, Vienna, Austria, Ago. 1998. [2] Sheth, A.P. & Larson, J.A., "Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases", in ACM Computing Surveys, vol. 22, n. 3, pp. 183-236, Set. 1990. [3] Duarte, C.H.C.; Pacitti, E.; Silva, S.D. & Melo, R.N., "HEROS: Um Sistema de Bancos de Dados Heterogêneos Orientado a Objetos", in Anais do VIII Simpósio Brasileiro de Banco de Dados, pp. 383-394, Campina Grande, Paraíba, 1993. [4] Uchôa, E.M.A.; Silva, S.D. & Melo, R.N., "Modelo de Dados do HEROS - Sistema de Bancos de Dados Heterogêneos Orientado a Objetos", in Anais do IX Simpósio Brasileiro de Banco de Dados, pp. 142-156, São Carlos, São Paulo, 1994. [5] Uchôa, E.M.A., "HEROS - Um Sistema de Bancos de Dados Heterogêneos: Integrando Esquemas", Dissertação de Mestrado, Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro, 203 p., Fev. 1994. [6] Silva, S.D., “Sistemas de Bancos de Dados Heterogêneos: Modelo de Execução da Gerência de Transações”, Tese de Doutorado, Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro, 150 p., Out. 1994. [7] Uchôa, E.M.A.; Melo, R.N & Lifschitz, S., “Interoperabilidade de Objetos em Sistemas de Bancos de Dados Heterogêneos”, Tech. Rep. MCC45/96, Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro, 31 p., Dez. 1996. [8] Oliveira, E.S., “HEROS: A Interoperabilidade de seus Componentes usando CORBA”, Dissertação de Mestrado, Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro, 129 p., 1997. [9] Piccinini, H.S., "Integrando Acervos da Internet/Intranet a Bancos de Dados Heterogêneos", Dissertação de Mestrado, Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro, 157 p., 1998. [10] Castro, C.E.P.S., “Integração de "Legacy Systems" a Sistemas de Bancos de Dados

[11]

[12]

[13]

[14] [15] [16] [17] [18] [19] [20] [21]

[22]

[23]

[24]

[25]

[26]

Heterogêneos", Dissertação de Mestrado, Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro, Jul. 1998. Bushmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P. & Stal, M., “Pattern-Oriented Software Architecture: A System of Patterns”, John Wiley & Sons, Chichester, West Sussex, England, 1996. Pree, W., “Meta-Patterns - A means for capturing the essentials of reusable objectoriented design”, in Proc of European Conference on Object-Oriented Programming (ECOOP’94), pp. 150-162, Bologna, Italy, Jul. 1994. Uchôa, E.M.A., "Framework para Integração de Sistemas de Bancos de Dados Heterogêneos", Tese de Doutorado, Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro, 1999. Özsu, M.T. & Valduriez, P., “Principles of Distributed Database Systems”, PrenticeHall, Inc., 562 p., 1991. Jacobson, I.; Christerson, M.; Jonsson, P. & Övergaard, G., “Object-Oriented Software Engineering - A Use Case Driven Approach”, Addison-Wesley, 528 p., 1992. Rumbaugh, J.; Blaha, M.; Premerlani, W.; Eddy, F. & Lorensen, W., “Object-Oriented Modeling and Design”, Prentice-Hall, Englewood Cliffs, NJ, 1991. Select Software Tools, Inc., Select Enterprise, http://www.selectst.com/products/, 0512-1998. Pree, W., “Framework Patterns”, SIGS Books & Multimedia, 104 p., 1996. LaLonde, W.R. & Pugh, J.R., “Inside Smalltalk, Volume II”, Prentice Hall, 1991. Russo, V.F., “An Object-Oriented Operating System”, Tese de doutorado, University of Illinois at Urbana-Champaign, Out. 1990. Bäumer, D.; Gryczan, G.; Knoll, R.; Lilienthal, C.; Riehle, D. & Züllighoven, H., “Framework Development for Large Systems”, in Communications of the ACM, vol. 40, n. 10, pp. 52-59, Out. 1997. Codenie, W.; Hondt, K.D.; Steyaert, P. & Vercammen, A., "From Custom Applications to Domain-Specific Frameworks", in Communications of the ACM, vol. 40, n. 10, pp. 71-77, Out. 1997. Murphy J. & Grimson J., “The Jupiter System: an Environment for Multidatabase Interoperability”, Tech. Rep. Dublin City University and Trinity College Dublin, Jan. 1994. Gesellschaft fuer Mathematik und Datenverarbeitung mbH, “VODAK V4.0 User Manual”, Arbeitspapiere der GMD - GMD Tech. Rep. no 910, German National Research Center for Information Technology, Darmstadt, Germany, Abr. 1995. Kapsammer E. & Wagner R.R., "The IRO-DB Approach Processing Queries in Federated Database Systems", in Proc of 8th Intl Workshop on Database and Expert Systems Applications DEXA'97, Toulouse, France, pp. 713-718, Set. 1997. Kilic E., Özhan G., Dengi C., Kesim N., Koksal P. & Dogac A., “Experiences in Using CORBA for a Multidatabase Implementation”, in Proc of the 6th Intl Workshop and Conference on Database and Expert Systems Applications DEXA’95, London, UK, pp. 223-230, Set. 1995.