HEROS

um

Sistema

de

Bancos

de

Dados

Heterog?neos

usando

CORBA

Elvira

Maria

Antunes

elvira@inf.puc-rio.br

S?rgio

lifschit@inf.puc-rio.br

Rubens

Nascimento

rubens@inf.puc-rio.br

PUC-RioInf

Novembro

Resumo

O

uso

de

padr?es

para

a

orienta

o

a

objetos

tem

sido

considerado

como

a

solu

o

para

coordenar

com

flexibilidade

e

integrar

os

recursos

de

processamento

de

informa

es

interligados

por

redes

de

comunica

o.

arquitetura

dos

sistemas

de

bancos

de

dados

heterog?neos

estes

padr?es

podem

ser

utilizados

para

a

integra

o

e

intera

o

dos

sistemas

heterog?neos

componentes

da

federa

o

aumentando

sua

flexibilidade

para

adaptar-se

a

novos

ambientes

e

sua

capacidade

de

expans?o

Este

trabalho

apresenta

os

principais

componentes

internos

da

arquitetura

do

HEROS

sistema

de

bancos

de

dados

heterog?neos

em

desenvolvimento

PUC-Rio

e

discute

sua

implementa

o

usando

o

padr?o

CORBA

para

a

interoperabilidade

destes

componentes

Palavras-Chave

SBDH

interoperabilidade

CORBA

HEROS

Abstract

Object

oriented

software

standards

have

been

considered

to

coordinate

with

the

desired

flexibility

and

integrate

the

information

processing

resources

within

a

given

network

With

respect

to

heterogeneous

database

systems

architectures

these

standards

can

be

used

for

the

integration

and

interaction

among

the

heterogeneous

components

which

may

increase

the

federation

adaptability

and

scalability

to

new

environments

This

work

gives

a

complete

presentation

of

HEROS

a

heterogeneous

object

oriented

database

system

and

discusses

its

implementation

using

CORBA

for

components

interoperability

Doutoranda

bolsista

CAPES

Parcialmente

apoiado

por

bolsa

de

produtividade

em

pesquisa

do

CNPq

Parcialmente

apoiado

por

projeto

integrado

de

pesquisa

do

CNPq

Introdu

o

Os

sistemas

de

banco

de

dados

surgiram

como

sendo

a

solu

o

para

o

problema

de

acesso

a

arquivos

heterog?neos

criados

por

m?ltiplas

aplica

es

aut?nomas

em

um

ambiente

centralizado

Estes

arquivos

eram

dif?ceis

de

serem

gerenciados

por

conterem

duplica

es

e

v?rios

tipos

de

heterogeneidade

como

diferen?as

de

nome

tipo

e

estruturas

de

arquivo

para

dados

similares

Para

resolver

estas

dificuldades

os

arquivos

aut?nomos

foram

substitu?dos

por

um

banco

de

dados

centralizado

sem

duplica

es

e

heterogeneidade

O

banco

de

dados

passou

a

ser

gerenciado

pelo

controle

centralizado

do

sistema

gerenciador

de

banco

de

dados

-LRB-

SGBD

-RRB-

que

dava

s

aplica

es

a

ilus?o

de

serem

as

nicas

usu?rias

do

dado

enquanto

mantinha

a

consist?ncia

privacidade

e

efici?ncia

A

coexist?ncia

de

muitos

e

diferentes

sistemas

de

banco

de

dados

apresenta-se

agora

como

natural

e

inevit?vel

no

contexto

das

grandes

organiza

es

em

um

mercado

livre

de

id?ias

e

produtos

em

constante

evolu

o.

Estes

m?ltiplos

sistemas

de

banco

de

dados

s?o

operados

e

administrados

sob

regras

locais

e

aut?nomas

podendo

estar

instalados

em

ambientes

computacionais

diferentes

com

modelos

de

dados

linguagens

e

representa

es

diversas

muitas

vezes

para

informa

es

similares

-LSB-

-RSB-

-LSB-

-RSB-

Surge

ent?o

a

necessidade

de

um

outro

n?vel

de

sistema

gerenciador

de

banco

de

dados

capaz

de

prover

o

acesso

a

dados

de

sistemas

de

banco

de

dados

j

existentes

que

diferem

entre

si

e

est?o

distribu?dos

ao

redor

de

redes

de

processamento

-LSB-

-RSB-

-LSB-

-RSB-

sem

exigir

mudan?as

nos

bancos

de

dados

e

sem

requerer

reprograma

o

dos

SGBDs

envolvidos

-LSB-

-RSB-

Os

sistemas

que

atendem

a

esses

requisitos

s?o

denominados

de

Sistemas

de

Bancos

de

Dados

Heterog?neos

A

an?lise

do

tipo

de

integra

o

existente

entre

os

componentes

dos

Sistemas

de

Bancos

de

Dados

Heterog?neos

permite

que

sejam

classificados

em

Sistemas

Federativos

com

Acoplamento

Forte

e

Sistemas

Federativos

com

Acoplamento

Fraco

-LSB-

-RSB-

-LSB-

-RSB-

Sistemas

de

Bancos

de

Dados

Heterog?neos

com

acoplamento

fraco

fornecem

uma

interface

para

a

negocia

o

direta

entre

os

m?ltiplos

Sistemas

Gerenciadores

de

Banco

de

Dados

componentes

A

cria

o

e

manuten

o

da

Federa

o

de

responsabilidade

do

usu?rio

e

n?o

existe

qualquer

controle

imposto

pelo

Sistema

Federado

Quando

o

usu?rio

da

Federa

o

deseja

acessar

um

dado

ele

deve

procur

lo

no

conjunto

dispon?vel

de

esquemas

de

exporta

o

e

definir

um

esquema

federado

para

importar

o

objeto

usando

uma

interface

de

usu?rio

um

programa

de

aplica

o

ou

um

linguagem

de

consulta

O

usu?rio

respons?vel

por

compreender

a

sem?ntica

do

objeto

do

esquema

de

exporta

o

e

resolver

as

heterogeneidades

sem?nticas

e

de

SGBDs

Sistema

de

Bancos

de

Dados

Heterog?neos

com

acoplamento

forte

composto

por

um

conjunto

de

Sistemas

de

Banco

de

Dados

componentes

heterog?neos

cooperativos

mas

aut?nomos

integrados

de

tal

forma

Federa

o

que

consultas

e

atualiza

es

podem

ser

realizadas

de

forma

transparente

localiza

o

dos

dados

e

aos

caminhos

de

acesso

Tal

transpar?ncia

obtida

pela

tradu

o

dos

diferentes

esquemas

dos

componentes

para

um

modelo

de

dados

comum

e

integrados

compondo

um

esquema

global

Todas

as

transa

es

que

envolvem

mais

de

um

Banco

de

Dados

s?o

definidas

em

termos

do

esquema

global

A

quest?o

da

interoperabilidade

entre

os

sistemas

isto

capacidade

dos

recursos

de

computa

o

interagirem

para

executarem

tarefas

conjuntamente

pode

variar

desde

estas

formas

avan?adas

como

Sistemas

de

Bancos

de

Dados

Heterog?neos

-LRB-

SBDHs

-RRB-

que

requerem

compreens?o

m?tua

n?o

somente

a

n?vel

de

sistemas

ou

programas

mas

tamb?m

a

n?vel

de

sem?ntica

dos

dados

at

formas

mais

simples

como

um

mecanismo

RPC

-LRB-

Remote

Procedure

Call

-RRB-

estendido

com

facilidades

para

tradu

o

de

dados

Para

prover

interoperabilidade

fatores

como

escala

heterogeneidade

gerenciamento

de

configura

o

e

monitoramento

de

redes

s?o

cr?ticos

A

tecnologia

de

objetos

facilita

o

gerenciamento

desta

complexidade

-LSB-

-RSB-

j

que

fi

fornece

um

meio

comum

onde

estruturas

de

dados

complexas

bem

como

especifica

es

de

comportamento

podem

ser

representadas

e

fi

acomoda

naturalmente

heterogeneidade

e

autonomia

heterogeneidade

porque

mensagens

enviadas

para

os

componentes

distribu?dos

dependem

apenas

das

interfaces

dos

componentes

indiferentes

a

suas

caracter?sticas

internas

e

autonomia

porque

componentes

podem

mudar

independentemente

e

transparentemente

desde

que

mantenham

suas

interfaces

inalteradas

Embora

a

orienta

o

para

objetos

apare?a

como

uma

solu

o

para

a

interoperabilidade

atualmente

ela

vem

contribuindo

para

o

problema

devido

diversidade

de

modelos

de

objetos

Esta

diversidade

justamente

uma

das

raz?es

que

levaram

v?rias

empresas

especialistas

em

sistemas

orientados

a

objetos

a

cooperar

no

sentido

de

definir

um

m?nimo

denominador

comum

a

ser

seguido

pelos

ambientes

orientados

a

objetos

dispon?veis

comercialmente

Esta

abordagem

de

m?nimo

denominador

comum

evidente

no

desenvolvimento

do

CORBA

Common

Object

Request

Broker

Architecture

que

aparece

hoje

com

uma

forte

tend?ncia

de

tornar-se

um

padr?o

de

fato

para

as

tecnologias

emergentes

de

objetos

distribu?dos

A

especifica

o

do

CORBA

um

produto

do

OMG

Object

Management

Group

-LSB-

-RSB-

Em

SBDHs

estes

padr?es

podem

ser

utilizados

para

a

integra

o

e

intera

o

dos

sistemas

heterog?neos

componentes

da

federa

o

aumentando

sua

flexibilidade

para

adaptar-se

a

novos

ambientes

e

sua

capacidade

de

expans?o

o

que

maximizado

pela

ado

o

de

tais

padr?es

para

a

interoperabilidade

dos

componentes

internos

da

pr?pria

arquitetura

do

SBDH

O

restante

deste

trabalho

est

organizado

da

seguinte

forma

se

o

apresentado

o

CORBA

padr?o

de

interoperabilidade

utilizado

no

projeto

HEROS

SBDH

em

desenvolvimento

PUC-Rio

se

o

s?o

descritos

o

projeto

HEROS

os

principais

componentes

internos

de

sua

arquitetura

e

a

motiva

o

para

o

uso

do

CORBA

se

o

e

s?o

mostradas

respectivamente

a

arquitetura

de

esquemas

do

HEROS

e

sua

ger?ncia

de

transa

o.

se

o

a

implementa

o

do

HEROS

usando

CORBA

comentada

E

se

o

s?o

apresentadas

algumas

considera

es

finais

Common

Object

Request

Broker

Architecture

CORBA

OMG

constitu?do

em

abril

de

um

cons?rcio

de

mais

de

empresas

cujo

principal

objetivo

desenvolver

uma

arquitetura

baseada

em

tecnologia

orientada

a

objetos

para

integra

o

de

aplica

es

distribu?das

O

OMG

n?o

cria

especifica

es

nem

produtos

Ao

inv?s

disso

o

OMG

envia

solicita

es

para

a

comunidade

de

desenvolvimento

de

software

pedindo

propostas

para

especifica

es

tecnol?gicas

Os

membros

dos

comit?s

apropriados

designados

pelo

OMG

avaliam

estas

propostas

e

finalmente

produzem

uma

especifica

o

que

o

resultado

de

um

acordo

comum

referente

as

caracter?sticas

desejadas

para

o

produto

definido

pela

especifica

o

-LSB-

-RSB-

A

arquitetura

especificada

publicada

e

mantida

pelo

OMG

denominada

Object

Management

Architecture

-LRB-

OMA

-RRB-

visa

garantir

reutiliza

o

de

componentes

interoperabilidade

e

portabilidade

padr?es

baseados

em

softwares

dispon?veis

comercialmente

base

dessa

arquitetura

est

o

CORBA

CORBA

uma

especifica

o

de

uma

arquitetura

e

interface

que

permite

que

aplica

es

fa?am

solicita

es

a

objetos

de

uma

forma

independente

e

transparente

indiferente

linguagem

sistema

operacional

ou

considera

es

de

localiza

o

-LSB-

-RSB-

CORBA

trata

ent?o

heterogeneidade

a

n?vel

de

plataforma

oferecendo

uma

infra-estrutura

para

implementar

SBDHs

que

passam

a

enfocar

apenas

o

tratamento

da

interoperabilidade

sem?ntica

A

especifica

o

CORBA

prop?e

uma

linguagem

comum

-LRB-

IDL

Interface

Definition

Language

-RRB-

para

defini

o

de

interfaces

entre

componentes

e

um

mecanismo

para

arbitrar

as

solicita

es

entre

os

componentes

isto

um

gerenciador

de

intera

es

entre

os

objetos

clientes

e

servidores

Esse

gerenciador

denominado

de

ORB

-LRB-

Object

Request

Broker

-RRB-

A

interface

do

ORB

com

os

objetos

feita

atrav?s

do

BOA

-LRB-

Basic

Object

Adapter

-RRB-

que

permite

a

gera

o

e

a

interpreta

o

de

refer?ncias

a

objetos

a

autentica

o

do

chamador

a

ativa

o/desativa

o

de

objetos

e

a

invoca

o

de

m?todos

A

implementa

o

do

BOA

dependente

de

linguagem

e

plataforma

Objetos

CORBA

podem

existir

em

qualquer

esta

o

rede

Clientes

remotos

podem

acessar

esses

objetos

atrav?s

de

seus

m?todos

p?blicos

-LRB-

definidos

em

IDL

-RRB-

A

linguagem

de

programa

o

utilizada

implementa

o

do

objeto

totalmente

transparente

aplica

o

cliente

que

pode

estar

escrita

em

outra

linguagem

Os

componentes

da

arquitetura

do

CORBA

s?o

-LRB-

-LSB-

-RSB-

-LSB-

-RSB-

e

-LSB-

-RSB-

-RRB-

fi

uma

linguagem

de

defini

o

de

interface

-LRB-

IDL

-RRB-

que

descreve

as

assinaturas

de

opera

es

e

atributos

associados

de

uma

interface

de

objeto

em

termos

que

o

resto

do

sistema

possa

entender

IDL

uma

linguagem

neutra

a

ser

mapeada

em

diferentes

linguagens

de

programa

o.

OMG

j

definiu

mapeamentos

para

C

C++

e

Smalltalk

fi

uma

completa

representa

o

din?mica

de

interfaces

dispon?veis

de

todos

os

objetos

em

um

reposit?rio

de

interface

-LRB-

IR

Interface

Repository

-RRB-

fi

uma

completa

extens?o

de

chamada

din?mica

permitindo

a

descoberta

em

tempo

de

execu

o

de

objetos

interfaces

dispon?veis

constru

o

de

mensagens

de

solicita

o

e

envio

destas

mensagens

fi

um

contexto

de

execu

o

que

permite

o

controle

da

execu

o

fi

um

adaptador

de

objeto

-LRB-

BOA

-RRB-

para

abstrair

detalhes

da

implementa

o

do

objeto

do

substrato

da

mensagem

O

segundo

componente

fundamental

da

OMA

o

conjunto

de

servi?os

comuns

-LRB-

Common

Object

Service

COSS

-RRB-

S?o

cerca

de

servi?os

dos

quais

se

destacam

Naming

Persistence

Security

Events

Transactions

O

OMA

inclui

os

Common

Horizontal

Facilities

que

especificam

frameworks

de

Compound

Documents

Object

Linking

Help

Facilities

Desktop

Management

e

os

Common

Vertical

Facilities

especificados

para

cada

segmento

de

ind?stria

-LRB-

sa?de

telecomunica

es

finan?as

manufatura

etc.

-RRB-

Existem

no

mercado

v?rios

ORBs

dispon?veis

comercialmente

por

empresas

como

IBM

IONA

HP

Digital

Visigenic

etc.

Alguns

dos

servi?os

especificados

arquitetura

OMA

j

est?o

dispon?veis

comercialmente

Outros

j

est?o

especificados

mas

n?o

dispon?veis

CORBA

tem

implementa

es

comerciais

-LRB-

produtos

-RRB-

abrangendo

desde

PC/Windows

at

MVS

mainframes

incluindo-se

plataformas

Unix

Windows

NT

Digital

e

Apple-Mac

Arquitetura

do

HEROS

rea

de

bancos

de

dados

SBDHs

t?m

sido

projetados

para

gerenciar

v?rios

bancos

de

dados

distribu?dos

aut?nomos

e

heterog?neos

O

grupo

de

banco

de

dados

da

PUC-Rio

est

desenvolvendo

sob

o

patroc?nio

do

CNPq

um

SBDH

com

acoplamento

forte

orientado

a

objetos

o

HEROS

Heterogeneous

Object

System

HEROS

suporta

opera

es

sobre

v?rios

SBDs

componentes

al?m

de

possuir

seu

pr?prio

banco

de

dados

Quanto

ao

seu

banco

de

dados

HEROS

gerencia

tanto

o

esquema

quanto

os

dados

associados

enquanto

que

no

que

se

refere

aos

bancos

de

dados

componentes

ele

apenas

fornece

acesso

sem

materializa

o

dos

dados

Os

SBDs

componentes

podem

diferir

quanto

ao

Sistema

Gerenciador

de

Banco

de

Dados

-LRB-

SGBD

-RRB-

modelo

de

dados

ambiente

computacional

e

localiza

o

f?sica

-LRB-

interligados

ent?o

por

sistemas

de

comunica

o

-RRB-

HEROS

proporciona

-LSB-

-RSB-

fi

uma

completa

transpar?ncia

de

localiza

o

e

replica

o

para

a

manipula

o

de

dados

como

se

o

usu?rio

estivesse

acessando

um

nico

banco

de

dados

centralizado

fi

transpar?ncia

do

modelo

de

dados

local

evitando

para

o

usu?rio

a

complexidade

de

conviver

ao

mesmo

tempo

com

v?rios

modelos

de

dados

diferentes

fi

interfer?ncia

m?nima

no

processamento

local

dos

SBDs

componentes

fi

uma

s?rie

de

abstra

es

de

dados

de

forma

a

permitir

uma

melhor

representa

o

das

sem?nticas

dos

SBDs

componentes

fi

consist?ncia

entre

dados

replicados

em

diferentes

SBDs

componentes

desde

que

tal

dado

esteja

mapeado

no

esquema

global

em

suas

v?rias

ocorr?ncias

fi

independ?ncia

f?sica

dos

dados

de

forma

que

mudan?as

nos

bancos

de

dados

locais

integrados

pelo

HEROS

como

altera

o

de

estrutura

de

armazenamento

localiza

o

rede

migra

o

entre

gerenciadores

distintos

n?o

impactam

as

aplica

es

definidas

sobre

o

esquema

global

requerendo

apenas

altera

es

nas

tradu

es

e

mapeamentos

correspondentes

pelos

administradores

de

banco

de

dados

locais

e

global

Um

SBDH

pode

oferecer

diferentes

tipos

de

funcionalidades

como

integra

o

de

esquemas

processamento

de

consultas

globais

ger?ncia

de

transa

es

globais

fun

es

administrativas

e

tratamento

de

diferentes

tipos

de

heterogeneidades

Integra

o

de

esquemas

est

associada

vis?o

l?gica

que

o

usu?rio

global

tem

dos

dados

distribu?dos

Ger?ncia

de

consulta

global

trata

a

an?lise

otimiza

o

e

execu

o

de

consultas

que

se

referem

a

dados

distribu?dos

Ger?ncia

de

transa

o

global

cuida

da

atomicidade

isolamento

e

durabilidade

de

transa

es

em

um

ambiente

distribu?do

Fun

es

administrativas

incluem

autentica

o

autoriza

o

defini

o

e

controle

de

restri

es

sem?nticas

sobre

os

dados

e

ger?ncia

de

dicion?rio

de

dados

e

diret?rios

Heterogeneidade

inclui

diferen?as

de

hardware

sistemas

operacionais

redes

de

comunica

o

fabricantes

de

SGBDs

e/ou

modelos

de

dados

No

HEROS

j

foram

definidos

modelo

de

dados

global

os

mecanismos

e

sistem?tica

para

integra

o

de

esquemas

o

modelo

e

ger?ncia

de

transa

o

global

e

tratamento

de

heterogeneidades

Em

uma

primeira

vers?o

embora

o

modelo

de

dados

fosse

orientado

a

objetos

sua

ger?ncia

de

transa

es

foi

desenvolvida

como

um

conjunto

de

m?dulos

funcionais

cuja

comunica

o

era

efetuada

por

um

mecanismo

de

RPC

Em

-LSB-

-RSB-

apresenta-se

um

resumo

desta

vers?o

e

analisa

se

as

vantagens

em

reestruturar

o

HEROS

para

uma

arquitetura

composta

por

classes

de

objetos

usando

uma

implementa

o

do

CORBA

para

efetuar

a

comunica

o

entre

os

componentes

remotos

Nesta

nova

vers?o

os

componentes

da

arquitetura

do

HEROS

s?o

representados

como

classes

de

objeto

onde

a

comunica

o

entre

os

objetos

remotos

efetuada

por

um

ORB

As

vantagens

desta

alternativa

s?o

a

representa

o

sob

a

forma

de

objetos

propicia

uma

melhor

visualiza

o

compreens?o

dos

componentes

e

suas

funcionalidades

a

propriedade

do

encapsulamento

facilita

o

refinamento/evolu

o

dos

componentes

do

HEROS

j

que

oculta

sua

implementa

o

que

pode

ser

alterada

sem

impactar

seus

usu?rios

desde

que

a

interface

seja

mantida

o

mecanismo

de

heran?a

permite

que

novos

gerentes

de

execu

o

espec?fica

para

um

sistema

componente

da

federa

o

sejam

criados

a

partir

de

uma

defini

o

gen?rica

de

gerente

de

execu

o

espec?fica

de

sistemas

componentes

enquanto

o

polimorfismo

faz

com

que

diferentes

objetos

da

classe

respondam

diferentemente

a

uma

mesma

invoca

o

de

m?todo

qualquer

aplica

o

em

qualquer

linguagem

de

programa

o

que

siga

os

padr?es

do

OMG

pode

usar

os

servi?os

do

HEROS

isto

executar

procedimentos

sobre

uma

federa

o

usufruindo

da

possibilidade

de

abstrair-se

de

quest?es

como

redund?ncias

conflitos

sem?nticos

ou

de

representa

o

e

localiza

o

dos

elementos

que

a

federa

o

integrar

enquanto

objetos

do

CORBA

os

componentes

do

HEROS

podem

residir

em

qualquer

local

f?sico

e

serem

substitu?dos

ficando

sob

a

responsabilidade

do

CORBA

administrar

esta

comunica

o

o

que

aumenta

a

extensibilidade

do

HEROS

isto

sua

capacidade

de

adaptar-se

a

novos

requisitos/estruturas

de

comunica

o

sem

a

necessidade

de

altera

es

internas

ss

a

aplica

o

e

o

componente

global

do

HEROS

podem

residir

em

qualquer

local

interligados

por

qualquer

forma

de

comunica

o

heterog?nea

ou

n?o

ficando

sob

a

responsabilidade

do

CORBA

administrar

esta

comunica

o

ae

a

Interface

de

Invoca

o

Din?mica

do

CORBA

permite

que

solicita

es

a

objetos

sejam

efetuadas

sem

conhecimento

anterior

das

assinaturas

das

opera

es

O

servidor

processa

em

tempo

de

execu

o

checagem

das

solicita

es

efetuadas

sem

necessidade

de

recompilar

o

c?digo

do

cliente

presen?a

de

novas

fun

es

dispon?veis

no

servidor

Os

principais

componentes

da

arquitetura

do

HEROS

s?o

apresentados

no

diagrama

a

seguir

e

detalhados

nas

pr?ximas

se

es

A

nota

o

utilizada

nos

Diagramas

de

Classes

apresentados

neste

trabalho

segue

a

proposta

de

-LSB-

RBP

-RSB-

Arquitetura

de

Esquemas

HEROS

possui

um

esquema

global

integrador

dos

diversos

esquemas

de

bancos

de

dados

componentes

-LSB-

-RSB-

O

modelo

de

dados

utilizado

globalmente

um

modelo

de

dados

orientado

a

objetos

especificado

em

-LSB-

-RSB-

A

Figura

apresenta

a

arquitetura

de

esquemas

do

HEROS

federa

o

endere?o

Commit

arvore

Gerar

Percorrer

Gerar

Percorrer

n

global

metros

componente

endere?o

nomepropriet?rio

Prepare

heros

BD-relacional

oracle

postgres

classe-exporta

o

o

n

local

indica

metros

tabela

nome

nome

BD-OO

comportamento

classe-global

pr

membros

o

comportamento

exp

execu

o

pr

requisito

pr

execu

o

compensat?ria

esquema

exporta

o

esquema

global

esquema

local

Figura

Diagrama

de

classes

de

objetos

dos

componentes

da

arquitetura

do

HEROS

Figura

Arquitetura

de

Esquemas

do

HEROS

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

expressos

usando

os

conceitos

do

modelo

de

dados

global

do

HEROS

O

esquema

global

cont?m

a

descri

o

integrada

dos

objetos

compartilhados

pelos

sistemas

componentes

Cada

esquema

externo

representa

uma

vis?o

de

aplica

o

do

esquema

global

Os

esquemas

correspondem

as

classes

assinaladas

Figura

Neste

diagrama

apresentamos

apenas

os

servi?os

relativos

ger?ncia

de

transa

o

global

omitindo

os

servi?os

relativos

integra

o

de

esquemas

A

integra

o

dos

sistemas

componentes

realizada

a

partir

da

defini

o

de

esquemas

de

exporta

o

-LSB-

-RSB-

Esquemas

de

exporta

o

s?o

gerados

automaticamente

por

ocasi?o

da

inclus?o

do

sistema

componente

federa

o

com

base

defini

o

do

ambiente

-LRB-

por

exemplo

a

classe

BD

Relacional

da

Figura

-RRB-

e

dos

pr?prios

SGBDs

componentes

-LRB-

por

exemplo

a

classe

Oracle

da

Figura

-RRB-

classes

estas

especializadas

da

classe

Componente

que

possui

informa

es

gen?ricas

a

todos

os

componentes

de

federa

o

e

defini

o

de

regras

de

tradu

o

-LRB-

mapeamento

-RRB-

das

propriedades

do

esquema

local

para

os

elementos

do

modelo

de

dados

do

HEROS

As

regras

de

mapeamento

est?o

associadas

classe

que

representa

o

ambiente

enquanto

que

a

classe

relativa

ao

SGBD

define

as

formas

de

acesso

espec?ficas

para

um

determinado

software

Esta

hierarquia

de

classes

usada

no

HEROS

para

representar

a

meta

informa

associada

a

cada

um

dos

sistemas

componentes

A

instancia

o

destas

classes

corresponde

s

informa

es

espec?ficas

sobre

as

estruturas

e

aplica

es

de

cada

sistema

a

ser

integrado

sendo

feita

automaticamente

atrav?s

de

regras

mediante

a

ocorr?ncia

do

evento

associado

execu

o

de

opera

es

Ao

se

solicitar

um

acesso

a

dado

ou

opera

o

de

sistemas

componentes

a

partir

do

esquema

global

HEROS

consulta

os

mapeamentos

armazenados

no

esquema

de

exporta

o

com

o

objetivo

de

descobrir

o

caminho

para

a

informa

o

e

ent?o

poder

recuper

la

para

altera

o/consulta

ou

execu

o

atrav?s

dos

procedimentos

de

acesso

a

dados

definidos

para

o

sistema

componente

No

momento

HEROS

realiza

a

tradu

o

entre

os

modelos

de

dados

e

deixa

a

crit?rio

do

administrador

de

banco

de

dados

da

federa

o

a

detec

o

de

poss?veis

heterogeneidades

sem?nticas

manualmente

Uma

vez

detectadas

HEROS

oferece

mecanismos

para

tratar

as

seguintes

heterogeneidades

sin?nimos

hom?nimos

replica

o

de

objetos

heterogeneidade

de

unidade

de

medida

e

generaliza

o.

Ger?ncia

de

Transa

es

A

ger?ncia

de

transa

es

em

um

sistema

gerenciador

de

bancos

de

dados

heterog?neos

tem

por

objetivo

a

obten

o

de

dados

consistentes

e

a

preserva

o

da

consist?ncia

global

presen?a

de

atualiza

es

globais

Nos

SGBDs

tradicionais

o

controle

da

execu

o

concorrente

de

transa

es

e

a

manuten

o

da

consist?ncia

dos

bancos

de

dados

em

caso

de

falhas

um

problema

bem

definido

e

com

diversas

solu

es

No

entanto

estas

solu

es

t?m

apresentado

restri

es

no

ambiente

de

SBDHs

visto

que

em

tais

ambientes

as

transa

es

tendem

a

ser

de

longa

dura

o

e

a

estrutura

de

controle

impl?cita

no

modelo

tradicional

de

transa

o

resultaria

manuten

o

das

restri

es

de

acesso

a

dados

por

per?odos

prolongados

reduzindo

o

n?vel

de

concorr?ncia

Informa

o

sobre

os

sistemas

de

banco

de

dados

componentes

necess?ria

para

permitir

o

acesso

e

interopera

o

entre

eles

Tal

informa

o

conhecida

por

meta

informa

o

inclui

nome

e

localiza

o

-LRB-

endere?o

rede

-RRB-

informa

es

sobre

o

modelo

de

dados

direitos

de

acesso

e

etc.

Modelo

de

Transa

o

Modelo

de

Transa

o

do

HEROS

utiliza

os

conceitos

de

transa

es

compens?veis

e

compensat?rias

presentes

no

modelo

de

Sagas

-LSB-

-RSB-

e

o

conceito

de

transa

o

vital

presente

no

modelo

de

transa

es

aninhadas

e

proposta

de

-LSB-

-RSB-

de

modelo

de

transa

o

para

sistemas

de

m?ltiplos

bancos

de

dados

Uma

transa

o

HEROS

uma

transa

o

com

aninhamento

aberto

O

modelo

permite

a

composi

o

modular

de

transa

es

possibilitando

que

resultados

parciais

sejam

observ?veis

por

outras

transa

es

e

evitando

que

em

transa

es

de

longa

dura

o

o

acesso

aos

dados

seja

bloqueado

por

longos

per?odos

favorecendo

o

uso

compartilhado

dos

dados

Uma

outra

vantagem

do

uso

de

subtransa

es

com

aceita

o

de

seus

resultados

a

maior

toler?ncia

a

falhas

j

que

se

reduz

o

n?mero

de

locais

participantes

em

um

determinado

instante

execu

o

de

uma

transa

o

global

A

utiliza

o

de

transa

es

compensat?rias

possibilita

a

manuten

o

da

consist?ncia

dos

bancos

de

dados

integrados

mesmo

no

caso

de

falha

durante

a

execu

o

de

um

protocolo

de

aceita

o

distribu?da

A

utiliza

o

do

conceito

de

transa

o

vital

possibilita

que

transa

es

planas

tradicionais

n?o

compens?veis

tamb?m

possam

ser

executadas

Uma

transa

o

R

do

HEROS

uma

hierarquia

em

dois

n?veis

de

-LRB-

sub

-RRB-

transa

es

com

aninhamento

aberto

O

n

de

mais

alto

n?vel

chamado

de

transa

o-raiz

e

os

demais

n?s

representam

transa

es-componentes

Transa

es

planas

s?o

vistas

como

casos

degenerados

das

transa

es

aninhadas

As

transa

es-componentes

de

uma

transa

o

HEROS

s?o

transa

es

pertencentes

a

um

dos

seguintes

tipos

fi

Compens?vel

uma

transa

o

deste

tipo

pode

ter

sua

execu

o

aceita

e

posteriormente

desfeita

atrav?s

da

execu

o

de

uma

transa

o

compensat?ria

fi

Compensat?ria

uma

transa

o

deste

tipo

n?o

pode

logicamente

falhar

A

transa

o

executada

para

desfazer

os

efeitos

de

uma

transa

o

compens?vel

cujos

resultados

tenham

sido

aceitos

fi

Vital

ou

Piv

uma

transa

o

deste

tipo

n?o

compens?vel

e

n?o

compensat?ria

e

uma

vez

aceita

n?o

pode

ter

seus

resultados

desfeitos

atrav?s

da

execu

o

de

uma

transa

o

compensat?ria

Uma

transa

o

pode

ter

um

n?mero

qualquer

de

transa

es

compens?veis

e

suas

correspondentes

transa

es

compensat?rias

e

sempre

uma

nica

transa

o

vital

ou

piv

-LRB-

Figura

-RRB-

Cada

transa

o

compens?vel

tem

o

resultado

da

sua

execu

o

aceito

t?o

logo

tenham

sido

completadas

as

suas

a

es

Caso

a

transa

o

a

que

pertence

venha

a

ser

cancelada

h

necessidade

de

se

mover

o

banco

de

dados

global

para

um

estado

consistente

com

a

retirada

dos

efeitos

das

a

es

executadas

e

aceitas

A

abordagem

utilizada

a

da

execu

o

de

transa

o

compensat?ria

que

desfa?a

semanticamente

esses

efeitos

A

transa

o

piv

deve

ser

sempre

executada

e

s

pode

ter

o

seu

resultado

aceito

ap?s

terem

sido

executadas

todas

as

transa

es

compens?veis

A

aceita

o

da

execu

o

da

transa

o

piv

implica

aceita

o

integral

da

transa

o

A

especifica

o

da

sem?ntica

operacional

do

Modelo

de

Transa

o

do

HEROS

foi

feita

com

o

uso

do

formalismo

ACTA

-LSB-

-RSB-

e

est

apresentada

em

detalhes

em

-LSB-

-RSB-

Execu

o

das

Transa

es

As

transa

es

HEROS

s?o

executadas

pela

classe

Federa

o

-LRB-

Figura

-RRB-

que

efetua

a

ger?ncia

global

de

transa

es

e

por

um

conjunto

de

classes

especializadas

da

classe

Componente

-LRB-

Figura

-RRB-

que

efetuam

a

ger?ncia

local

de

transa

es

h

uma

classe

deste

tipo

para

cada

local

participante

do

HEROS

As

opera

es

de

uma

transa

o

global

s?o

submetidas

para

execu

o

uma

a

uma

Uma

nova

opera

o

s

submetida

ap?s

a

classe

Federa

o

retornar

o

resultado

correspondente

execu

o

da

opera

o

que

a

precede

A

classe

Federa

o

respons?vel

pela

intera

o

do

HEROS

com

as

aplica

es

implementando

uma

interface

que

consiste

das

opera

es

b?sicas

-LCB-

Commit

Abort

EOT

-RCB-

Uma

transa

o

compensat?ria

derivada

pela

ger?ncia

de

transa

o

a

partir

das

opera

es

executadas

por

uma

transa

o

compens?vel

e

conclu?da

com

sucesso

A

transa

o

compensat?ria

executada

quando

torna-se

necess?rio

desfazer

semanticamente

os

efeitos

da

transa

o

compens?vel

original

sobre

o

banco

de

dados

global

As

classes

especializadas

da

classe

Componente

s?o

as

respons?veis

pela

intera

o

com

os

SGBDs

locais

Representam

em

cada

local

o

sistema

global

controlando

a

submiss?o

de

comandos

para

execu

o

pelo

SGBD

respectivo

e

representando

o

SGBD

no

processo

de

aceita

o

das

subtransa

es

globais

de

forma

semelhante

do

m?todo

de

agentes

-LSB-

-RSB-

Do

ponto

de

vista

da

execu

o

de

transa

o

para

se

integrar

um

novo

tipo

de

sistema

componente

federa

o

por

exemplo

o

SGBD

Sybase

basta

criar

uma

nova

classe

especializada

da

classe

Componente

e

implementar

para

ela

as

tr?s

opera

es

b?sicas

-LCB-

-RCB-

A

correspond?ncia

entre

conceitos

pertencentes

a

esquemas

dos

diferentes

n?veis

expressa

atrav?s

de

mapeamentos

representado

pela

classe

rvore

Global

da

Figura

Os

mapeamentos

s?o

utilizados

no

processo

de

tradu

o

de

opera

es

sobre

objetos

definidos

em

um

esquema

externo

em

opera

es

sobre

objetos

definidos

em

um

ou

mais

esquemas

locais

e

composi

o

dos

resultados

parciais

e

apresenta

o

do

resultado

correspondente

a

uma

opera

o

global

No

projeto

da

ger?ncia

de

transa

o

foram

consideradas

apenas

as

opera

es

sobre

objetos

definidos

no

esquema

global

Para

cada

opera

o

sobre

dados

recebida

para

execu

o

inicialmente

a

classe

Federa

o

utiliza

os

dados

sobre

mapeamentos

armazenados

no

esquema

global

e

gera

uma

rvore

de

opera

es

correspondente

Esta

rvore

cont?m

nos

Figura

Representa

o

gr?fica

da

estrutura

de

uma

transa

o

HEROS

seus

n?s

opera

es

sobre

os

sistemas

de

banco

de

dados

locais

expressos

com

conceitos

do

esquema

de

exporta

o

e

as

opera

es

de

composi

o

e

apresenta

o

da

resposta

opera

o

global

As

opera

es

desta

rvore

s?o

submetidas

as

respectivas

classes

especializadas

da

classe

Componente

que

representam

o

SGBD

local

A

classe

especializada

da

classe

Componente

ent?o

utiliza

os

dados

sobre

mapeamentos

armazenados

no

esquema

de

exporta

o

representado

pela

classe

rvore

Local

da

Figura

e

gera

uma

rvore

de

opera

es

correspondente

Esta

rvore

cont?m

nos

seus

n?s

opera

es

sobre

os

sistemas

de

banco

de

dados

locais

expressos

com

conceitos

do

esquema

local

e

as

opera

es

de

composi

o

e

apresenta

o

da

resposta

opera

o

submetida

pela

classe

Federa

o.

Como

os

mapeamentos

entre

esquema

global

e

esquemas

locais

s?o

transparentes

ao

usu?rio

global

poss?vel

haver

depend?ncias

de

dados

entre

duas

subtransa

es

locais

derivadas

pela

ger?ncia

de

transa

o.

Cada

opera

o

sobre

banco

de

dados

local

submetida

ao

SGBD

correspondente

como

componente

de

uma

subtransa

o

local

Para

cada

transa

o

global

existe

no

m?ximo

uma

nica

subtransa

o

por

local

As

subtransa

es

locais

s?o

executadas

pelos

SGBDs

correspondentes

da

mesma

forma

que

as

transa

es

locais

comuns

isto

um

SGBD

local

n?o

distingue

entre

subtransa

es

globais

e

transa

es

locais

especifica

o

da

ger?ncia

de

transa

o

assumiu-se

que

cada

SGBD

utiliza

o

protocolo

estrito

-LSB-

-RSB-

para

controle

de

concorr?ncia

garantindo

a

produ

o

de

hist?rias

serializ?veis

de

todas

as

transa

es

que

executa

No

caso

da

ocorr?ncia

de

falhas

o

SGBD

possui

a

capacidade

de

recuperar

um

estado

consistente

ocorr?ncia

do

cancelamento

de

uma

subtransa

o

pelo

SGBD

local

como

no

caso

de

solu

o

de

bloqueios

m?tuos

a

informa

o

sobre

o

cancelamento

fornecida

n?o

sendo

responsabilidade

do

SGBD

a

sua

ressubmiss?o

A

execu

o

de

um

comando

global

precedida

pela

aquisi

o

de

bloqueios

para

a

transa

o

em

andamento

A

possibilidade

de

conflitos

sem?nticos

entre

as

opera

es

verificada

atrav?s

do

exame

das

tabelas

de

compatibilidade

definidas

para

cada

classe

de

objetos

pelo

administrador

de

banco

de

dados

global

quando

da

cria

o

do

esquema

global

Estas

tabelas

s?o

criadas

com

a

aplica

o

do

princ?pio

da

comutatividade

entre

opera

es

isto

verificando

se

o

efeito

final

o

mesmo

independentemente

da

ordem

de

sua

execu

o.

Uma

opera

o

sobre

um

objeto

pode

resultar

execu

o

indireta

de

outras

opera

es

sobre

o

mesmo

ou

outros

objetos

As

descri

es

de

quais

classes

de

objeto

s?o

afetadas

e

quais

opera

es

s?o

indiretamente

executadas

fazem

parte

da

especifica

o

de

cada

m?todo

A

granularidade

das

restri

es

de

acessos

a

n?vel

global

a

da

classe

de

objeto

a

que

pertence

a

opera

o.

Quando

os

requisitos

de

acesso

da

opera

o

global

n?o

podem

ser

integralmente

atendidos

a

opera

o

entra

em

uma

lista

de

espera

aguardando

condi

es

para

sua

execu

o

A

descri

o

detalhada

dos

componentes

funcionais

da

ger?ncia

de

transa

o

e

a

especifica

o

formal

do

modelo

de

execu

o

das

transa

es

est?o

em

-LSB-

-RSB-

e

-LSB-

-RSB-

Implementa

o

do

HEROS

Nesta

vers?o

do

prot?tipo

do

HEROS

desenvolvido

em

ambiente

UNIX

utilizou-se

ORBeline

-LSB-

-RSB-

para

efetuar

a

comunica

o

entre

as

classes

componentes

da

arquitetura

do

HEROS

enquanto

que

a

implementa

o

dos

servi?os

das

classes

foi

realizada

linguagem

de

programa

o

C++

Os

SGBDs

componentes

utilizados

foram

o

Oracle

vs.

-LSB-

-RSB-

e

o

Postgres

vs.

-LSB-

-RSB-

localizados

em

m?quinas

diferentes

entre

si

e

da

aplica

o

tamb?m

implementada

em

C++

devido

a

restri

es

do

ORB

que

foi

disponibilizado

No

prot?tipo

foram

implementadas

em

C++

todas

as

classes

apresentadas

Figura

e

algumas

outras

-LRB-

anexo

-RRB-

utilizadas

para

a

ger?ncia

da

transa

o

global

As

intera

es

entre

as

classes

para

a

ger?ncia

da

transa

o

global

foram

projetadas

atrav?s

do

uso

de

Diagrama

de

Intera

o

proposto

por

Jacobson

-LSB-

-RSB-

e

constam

do

anexo

No

ORBeline

foram

declaradas

tr?s

classes

cujos

objetos

s?o

acessados

atrav?s

do

ORB

provendo

transpar?ncia

de

localiza

o

e

sistema

operacional

S?o

elas

-LRB-

Figura

-RRB-

Federa

o

Componente

e

F?brica

Estas

classes

foram

especificadas

em

IDL

e

em

suas

especifica

es

constam

apenas

os

servi?os

a

serem

invocados

atrav?s

do

ORB

A

classe

Federa

o

-LRB-

Figura

-RRB-

respons?vel

pela

intera

o

do

HEROS

com

as

aplica

es

implementando

uma

interface

que

consiste

das

opera

es

b?sicas

-LCB-

Commit

Abort

EOT

-RCB-

conforme

discutido

se

o

Sua

implementa

o

abrange

as

seguintes

classes

em

C++

Federa

o

Classe

Global

Procedimento

Global

rvore

Global

N

Global

Transa

o

Raiz

Subtransa

o

Comando

Compensat?rio

Processo

Compensat?rio

Garantia

de

Acesso

e

Log

Global

Para

aproveitar

parte

da

codifica

o

que

j

estava

pronta

relativa

a

primeira

vers?o

do

HEROS

e

manter

a

implementa

o

independente

do

mecanismo

de

comunica

o

foram

criados

mediadores

que

convertem

os

tipos

de

dados

gerados

pelo

ORBeline

para

os

tipos

de

dados

usados

nos

m?todos

idl

typedef

struct

-LCB-

string

string

string

sequence

<char>

-RCB-

typedef

struct

-LCB-

boolean

sequence

<char>

-RCB-

DEFINICAO

FEDERACAO

interface

federacao

-LCB-

boolean

-LRB-

in

long

-RRB-

boolean

-LRB-

-RRB-

boolean

-LRB-

-RRB-

boolean

-LRB-

-RRB-

-LRB-

in

comando

-RRB-

boolean

EOT

-LRB-

-RRB-

boolean

Commit

-LRB-

-RRB-

boolean

Abort

-LRB-

-RRB-

-RCB-

Figura

Especifica

o

em

IDL

da

classe

Federa

o

A

classe

Componente

-LRB-

Figura

-RRB-

respons?vel

pela

intera

o

da

classe

Federa

o

com

os

SGBDs

locais

implementando

uma

interface

que

consiste

das

opera

es

b?sicas

-LCB-

Prepare

-RCB-

conforme

discutido

se

o

Sua

implementa

o

abrange

as

seguintes

classes

em

C++

Componente

Classe

Exporta

o

Procedimento

Exporta

o

Esquema

Local

rvore

Local

N

Local

Processo

Local

e

Log

Local

Neste

prot?tipo

existem

tr?s

implementa

es

diferentes

para

a

classe

Componente

correspondendo

s

classes

Postgres

Oracle

e

Heros

apresentadas

Figura

As

implementa

es

abrangem

todas

as

classes

supra-citadas

diferindo

basicamente

idl

PARAMETROS

typedef

struct

-LCB-

string

sequence

<char>

conteudo

-RCB-

typedef

struct

-LCB-

long

string

string

sequence

sequence

-RCB-

typedef

struct

-LCB-

boolean

sequence

-RCB-

PREPARE

typedef

struct

-LCB-

long

-RCB-

typedef

struct

-LCB-

boolean

-RCB-

COMMIT

typedef

struct

-LCB-

long

-RCB-

typedef

struct

-LCB-

boolean

-RCB-

ABORT

typedef

struct

-LCB-

long

-RCB-

typedef

struct

-LCB-

boolean

-RCB-

DEFINICAO

DE

COMPONENTE

interface

componente

-LCB-

-LRB-

in

-RRB-

Prepare

-LRB-

in

-RRB-

-LRB-

in

-RRB-

-LRB-

in

-RRB-

boolean

-LRB-

-RRB-

boolean

-LRB-

-RRB-

boolean

-LRB-

-RRB-

-RCB-

Figura

Especifica

o

em

IDL

da

classe

Componente

quanto

codifica

o

dos

servi?os

-LCB-

-RCB-

respons?veis

pelo

acesso

ao

SGBD

Ao

se

criar

um

objeto

da

classe

Componente

no

ORBeline

tem

que

se

indicar

qual

o

execut?vel

que

dever

ser

utilizado

para

este

novo

objeto

A

classe

F?brica

-LRB-

Figura

-RRB-

surgiu

do

fato

de

que

para

se

invocar

servi?os

de

um

objeto

atrav?s

do

ORBeline

necess?rio

que

este

objeto

j

tenha

sido

criado

no

ORB

Foi

especificada

ent?o

uma

classe

que

respons?vel

pela

cria

o

de

todos

os

objetos

a

serem

acessados

atrav?s

do

ORB

bem

como

pela

listagem

dos

objetos

j

criados

O

exemplo

de

uma

aplica

o

escrita

em

C++

que

acessa

o

HEROS

apresentada

a

seguir

-LRB-

Figura

-RRB-

Nesta

aplica

o

interessante

se

observar

a

forma

como

a

aplica

o

ativa

um

objeto

do

ORB

atrav?s

da

fun

o

do

ORBeline

bind

A

partir

desta

chamada

de

fun

o

o

ORBeline

localiza

a

implementa

o

do

objeto

ativa-o

e

retorna

uma

refer?ncia

ao

objeto

para

a

aplica

o

que

a

partir

de

ent?o

usa-a

para

solicitar

servi?os

ao

respectivo

objeto

idl

DEFINICAO

FABRICA

interface

fabrica

-LCB-

boolean

-LRB-

-RRB-

boolean

-LRB-

-RRB-

boolean

-LRB-

-RRB-

boolean

-LRB-

-RRB-

boolean

-LRB-

-RRB-

boolean

-LRB-

-RRB-

boolean

-LRB-

-RRB-

-RCB-

Figura

Especifica

o

em

IDL

da

classe

F?brica

Federa

o

Aplica

o

Componente

F?brica

ORB

Figura

Classes

do

HEROS

no

CORBA

A

distribui

o

dos

componentes

do

HEROS

pode

ser

visualizada

graficamente

como

-LRB-

Figura

-RRB-

PROTOTIPOS

E

DEFINICOES

DE

TIPO

#include

#include

cabgeral.h

EXECUTAR

TRANSACAO

int

-LRB-

void

-RRB-

-LCB-

comando

comando

a

ser

executado

saida

resultado

do

comando

static

int

n

numero

da

transa

o

limpa

o

conteudo

de

comando

obtem

a

federacao

obtem

a

classe

obtem

o

metodo

obtem

os

parametros

de

entrada

ativa

objeto

federacao

no

CORBA

CORBA

Environment

env

CORBA

Exception

exp

CORBA

SystemException

federacao

federacao

bind

-LRB-

env

comando.nome

federacao

-RRB-

if

-LRB-

env.check

exception

-LRB-

-RRB-

-RRB-

-LCB-

exp

env.exception

value

-LRB-

-RRB-

CORBA

SystemException

cast

-LRB-

exp

-RRB-

if

-LRB-

-RRB-

-LCB-

cout

exp

id

-LRB-

-RRB-

ocorreu

endl

cout

com

codigo

minorFlag

-LRB-

-RRB-

endl

com

status

complementar

completed

-LRB-

-RRB-

endl

-RCB-

return

-RCB-

else

cout

Bound

to

componente

server

endl

executa

o

comando

n

-LRB-

n

-RRB-

-LRB-

-RRB-

saida

-LRB-

comando

-RRB-

printf

-LRB-

nResultado

t

t

t

t

s

n

n

saida.cont

-RRB-

printf

-LRB-

Commitando

n

n

-RRB-

Commit

-LRB-

-RRB-

-LRB-

-RRB-

saida

-LRB-

comando

-RRB-

printf

-LRB-

rResultado

t

t

t

t

s

n

n

saida.cont

-RRB-

printf

-LRB-

Commitando

n

-RRB-

Commit

-LRB-

-RRB-

EOT

-LRB-

-RRB-

-RCB-

Figura

Aplica

o

que

acessa

o

HEROS

As

decis?es

de

implementa

o

b?sicas

assumidas

neste

prot?tipo

foram

fi

Granularidade

de

Objeto

No

CORBA

objetos

podem

ser

definidos

em

diferentes

granularidades

No

caso

do

HEROS

os

objetos

correspondem

s

federa

es

administradas

pelo

HEROS

e

aos

sistemas

componentes

que

comp?em

estas

federa

es

j

que

enquanto

SGBDH

HEROS

apenas

fornece

acesso

aos

bancos

de

dados

componentes

sem

materializa

o

dos

dados

fi

Estilo

de

Invoca

o

CORBA

permite

que

o

cliente

invoque

interfaces

de

forma

est?tica

ou

din?mica

No

prot?tipo

foi

utilizada

apenas

a

invoca

o

est?tica

visto

que

nesta

vers?o

todos

os

objetos

s?o

conhecidos

e

a

interface

que

os

clientes

usam

n?o

tende

a

se

alterar

com

o

tempo

fi

Tipos

de

Objeto

ORBline

suporta

dois

tipos

de

objetos

ORB

objetos

persistentes

e

objetos

transientes

No

prot?tipo

utilizou-se

apenas

objetos

persistentes

j

que

os

objetos

gerenciados

pelo

ORBeline

precisam

ficar

registrados

para

poderem

ser

ativados

posteriormente

por

ocasi?o

do

uso

da

federa

o.

fi

Ciclo

de

Vida

do

Objeto

Objetos

do

ORB

precisam

ser

criados

ou

instalados

para

tornarem-se

dispon?veis

para

os

clientes

ORBline

oferece

tr?s

formas

para

cria

o/exclus

o

de

objetos

persistentes

usar

o

daemon

de

ativa

o

de

objeto

usar

os

servi?os

do

BOA

ou

instanciar/destruir

classes

em

C++

Optou-se

implementa

o

por

utilizar

os

daemons

chamados

pela

implementa

o

da

classe

F?brica

O

uso

de

tais

daemons

permite

que

o

servidor

ao

qual

se

refere

o

objeto

criado

desta

forma

possa

ser

automaticamente

ativado

quando

um

cliente

invoca

uma

solicita

o

ao

objeto

e

o

servidor

n?o

est

ativado

o

que

n?o

acontece

no

caso

de

instancia

o

em

classes

C++

quando

fica

a

crit?rio

da

implementa

o

dos

m?todos

da

classe

Os

servi?os

do

BOA

corresponderem

a

uma

interface

program?vel

para

os

daemons

mas

infelizmente

n?o

se

conseguiu

fazer

funcionar

n

vers?o

do

ORBeline

usado

para

a

implementa

o

deste

prot?tipo

implementa

o

do

F?brica

ORB

implementa

o

do

Heros

implementa

o

do

Oracle

aplica

o

ORB

implementa

o

do

Postgres

ORB

ORB

implementa

o

da

Federa

o

ORB

-LRB-

-LRB-

Figura

Distribui

o

dos

componentes

do

HEROS

fi

Identifica

o

de

objetos

Uma

aplica

o

cliente

precisa

de

uma

refer?ncia

de

objeto

para

fazer

uma

solicita

o.

No

CORBA

a

refer?ncia

de

objeto

pode

ser

obtida

em

uma

de

duas

formas

-LSB-

-RSB-

o

cliente

pode

obter

a

refer?ncia

do

objeto

de

uma

fonte

externa

A

fonte

externa

pode

ser

um

arquivo

ou

um

banco

de

dados

que

cont?m

refer?ncias

de

objeto

forma

de

cadeia

de

caracter

os

objetos

podem

ser

nomeados

e

tal

nome

ser

utilizado

para

a

solicita

o

de

servi?os

No

caso

do

ORBline

a

nica

forma

do

cliente

acessar

uma

inst?ncia

particular

de

determinada

classe

se

especificando

nome

de

objeto

para

ela

Conseq?entemente

no

HEROS

todos

os

objetos

s?o

nomeados

fi

Pol?tica

de

Ativa

o

Quando

se

registra

um

novo

objeto

no

CORBA

tem-se

que

especificar

uma

pol?tica

de

ativa

o

que

descreva

as

regras

que

determinada

implementa

o

deve

seguir

quando

m?ltiplos

objetos

ou

implementa

es

forem

ativadas

Existem

quatro

pol?ticas

de

ativa

o

no

CORBA

-LSB-

-RSB-

servidor

compartilhado

servidor

n?o

compartilhado

um

servidor

por

m?todo

e

servidor

persistente

Apenas

para

a

classe

F?brica

os

objetos

s?o

ativados

de

forma

compartilhada

isto

v?rios

objetos

ativos

de

uma

determinada

implementa

o

compartilham

o

mesmo

servidor

Todos

os

demais

objetos

s?o

ativados

de

forma

n?o

compartilhada

isto

somente

um

objeto

de

determinada

implementa

o

pode

estar

ativo

em

um

determinado

momento

em

um

servidor

Quando

se

trata

da

classe

Federa

o

o

servidor

n?o

compartilhado

permite

um

ambiente

multiusu?rio

isto

v?rios

clientes

solicitando

servi?os

de

federa

o

simultaneamente

J

para

a

classe

Componente

esta

pol?tica

permite

explorar

o

paralelismo

execu

o

local

de

procedimentos

globais

sem

que

um

local

tenha

que

ficar

esperando

pelo

outro

para

executar

fi

Mapeamento

entre

solicita

es

do

cliente

e

servidores

Para

associar

uma

solicita

o

do

cliente

a

um

m?todo

do

servidor

CORBA

oferece

as

seguintes

alternativas

uma

interface

para

uma

implementa

o

uma

interface

para

uma

entre

v?rias

implementa

es

e

uma

interface

para

v?rias

implementa

es

No

caso

da

classe

Federa

o

foi

utilizada

a

primeira

alternativa

ou

seja

para

cada

interface

existe

apenas

uma

implementa

o

j

que

n?o

se

prev

a

necessidade

de

diferentes

implementa

es

para

ela

Para

a

classe

Componente

o

mais

adequado

seria

a

terceira

alternativa

onde

pode-se

associar

v?rias

implementa

es

uma

mesma

interface

cada

uma

das

implementa

es

fornecendo

apenas

uma

parte

da

interface

Isto

permitiria

que

ao

se

incorporar

um

novo

tipo

de

componente

ao

HEROS

bastaria

implementar-se

apenas

os

servi?os

-LCB-

-RCB-

Como

a

vers?o

do

ORBeline

utilizada

n?o

tem

esta

op

o

escolheu-se

a

segunda

alternativa

onde

para

cada

interface

pode

se

ter

uma

implementa

o

diferente

embora

similar

Conclus?o

Visando

a

discuss?o

da

ado

o

do

CORBA

para

a

interoperabilidade

dos

componentes

internos

da

arquitetura

do

HEROS

este

trabalho

inicialmente

apresentou

uma

descri

o

sum?ria

dos

padr?es

de

interoperabilidade

do

OMG

e

dos

principais

componentes

internos

da

arquitetura

do

HEROS

Finalmente

o

trabalho

analisou

a

implementa

o

do

HEROS

usando

CORBA

CORBA

em

desenvolvimento

pelo

OMG

uma

especifica

o

e

uma

arquitetura

que

possibilita

que

objetos

em

sistemas

heterog?neos

possam

ser

acessados

de

forma

independente

de

sua

implementa

o.

No

CORBA

clientes

solicitam

a

execu

o

de

servi?os

e

servidores

executam

tais

servi?os

tudo

em

termo

de

tarefas

denominadas

opera

es

que

s?o

executadas

por

entidades

denominadas

objetos

Aplica

es

interagem

umas

com

as

outras

sem

saber

onde

as

outras

aplica

es

est?o

rede

ou

como

elas

executam

suas

tarefas

Usando

CORBA

poss?vel

encapsular

aplica

es

e

suas

respectivas

opera

es

como

conjuntos

de

objetos

distribu?dos

de

tal

forma

que

se

possa

plugar

e

desplugar

capacidades

de

clientes

e

servidores

medida

que

estes

necessitem

ser

adicionados

ou

substitu?dos

em

um

sistema

distribu?do

Logo

CORBA

trata

heterogeneidade

a

n?vel

de

plataforma

inclusive

heterogeneidade

a

n?vel

de

sistema

de

banco

de

dados

oferecendo

uma

infraestrutura

para

implementar

SBDH

deixando

no

entanto

a

n?vel

da

programa

o

do

SBDH

o

tratamento

da

interoperabilidade

sem?ntica

justamente

esta

linha

de

pesquisa

que

est

sendo

adotada

no

projeto

HEROS

SBDH

com

acoplamento

forte

em

desenvolvimento

PUC-Rio

que

usa

um

modelo

integrador

orientado

a

objetos

Os

objetos

que

comp?em

a

arquitetura

do

HEROS

foram

identificados

tanto

a

n?vel

de

integra

o

de

esquemas

quanto

da

execu

o

de

transa

o

global

a

serem

especificados

no

CORBA

e

foram

implementados

linguagem

de

programa

o

C++

Foi

utilizado

ORBeline

para

implementar

a

comunica

o

entre

tais

objetos

Este

prot?tipo

est

sendo

desenvolvido

em

ambiente

UNIX

utilizando

como

SGBDs

componentes

o

Oracle

vs.

e

o

Postgres

vs.

Refer?ncias

Bibliogr?ficas

-LSB-

-RSB-

Bernstein

P.

Hadizlacos

V.

Goodman

N.

Concurrency

Control

and

Recovery

in

Database

Systems

Addison-Wesley

USA

-LSB-

-RSB-

Cattell

R.G.G.

The

Object

Databases

Standard

Morgan

Kaufmann

Publishers

p.

-LSB-

-RSB-

Chung

C.

DATAPLEX

An

Access

to

Heterogeneous

Distributed

Databases

Communications

of

The

ACM

V.

N.

Jan.

-LSB-

-RSB-

Chrysanthis

P.K.

Ramamritham

K.

ACTA

The

Saga

Continues

In

Database

Transaction

Models

for

Advanced

Applications

editado

por

A.

K.

Elmagarmid

Morgan

Kaufmann

Pub.

USA

-LSB-

-RSB-

Helal

A.

Elmasri

R.

Standard

Developments

for

Database

and

System

Interoperability

In

Simp?sio

Brasileiro

de

Banco

de

Dados

X

Recife

Pernambuco

Recife

-LSB-

-RSB-

Jacobson

I.

Christerson

M

Jonsson

P.

vergaard

G.

Object

Oriented

Software

Engineering

A

Use

Case

Driven

Approach

Addison-Wesley

Publishing

Company

Inc.

-LSB-

-RSB-

Keuffel

W.

CORBA

Masterminds

Object

Management

DBMS

Tools

Strategies

for

is

Professionals

V.

N.

Mar

-LSB-

-RSB-

Litwin

W.

Mark

L.

Roussopoulos

N.

Interoperability

of

Multiple

Autonomous

Databases

ACM

Computing

Surveys

V.

N.

Set

-LSB-

-RSB-

Mehrotra

S.

Rastogi

R.

Korth

H.F.

Silberschatz

A.

A

Transaction

Model

for

Multidatabase

Systems

Technical

Report

Department

of

Computer

Sciences

University

of

Texas

at

Austin

Texas

USA

Mar.

-LSB-

-RSB-

Mowbray

T.J.

Zahavi

R.

The

Essential

CORBA

Systems

Integration

Using

Distributed

Objects

John

Wiley

Sons

Inc

-LSB-

-RSB-

Nicol

J.R.

Wilkes

C.T.

Manola

F.A.

Object

Orientation

in

Heterogeneous

Distributed

Computing

Systems

IEEE

Computer

V.

N.

Jun.

-LSB-

-RSB-

Orfali

R

Harkey

D.

Edwards

E.

The

Essential

Distributed

Objects

Survival

Guide

John

Wiley

Sons

Inc.

p.

-LSB-

-RSB-

ORACLE

Database

Administrator

's

Guide

Oracle

Corporation

Estados

Unidos

-LSB-

-RSB-

PostModern

Computing

ORBeline

User?s

Guide

PostModern

Computing

Technologies

Inc.

USA

-LSB-

-RSB-

Perrizo

W.

Rajkumar

J.

Ram

P.

HYDRO

A

Heterogeneous

Distributed

Database

System

In

International

Conference

on

Management

of

Data

Denver

Colorado

Anais

Colorado

-LSB-

ACM-SIGMOD

-RSB-

-LSB-

-RSB-

Pacitti

E.

Silva

S.D.

Duarte

C.H.

C.

Melo

R.N.

HEROS

Um

Sistema

de

Bancos

de

Dados

Heterog?neos

Orientado

a

Objetos

In

Simp?sio

Brasileiro

de

Banco

de

Dados

VIII

Campina

Grande

Para?ba

Anais

Campina

Grande

-LSB-

-RSB-

Ram

S.

Guest

Editor

's

Introduction

Heterogeneous

Distributed

Database

Systems

IEEE

Computer

V.

N.

Dez

-LSB-

-RSB-

Rhein

J.

e

Kemnitz

G.

The

Postgres

User

Manual

Electronics

Research

Laboratory

University

of

California

Berkeley

Fev

-LSB-

RBP

-RSB-

Rumbaugh

J.

Blaha

M.

Premerlani

W.

Eddy

F.

Lorensen

W.

Object-Oriented

Modeling

and

Design

Prentice-Hall

Inc.

p.

-LSB-

-RSB-

Silva

S.D.

Sistemas

de

Bancos

de

Dados

Heterog?neos

Modelo

de

Execu

o

da

Ger?ncia

de

Transa

es

Rio

de

Janeiro

Pontif?cia

Universidade

Cat?lica

do

Rio

de

Janeiro

p.

Tese

de

Doutorado

em

Inform?tica

Ci?ncia

da

Computa

o

Departamento

de

Inform?tica

da

PUC-Rio

-LSB-

-RSB-

Soley

R.M.

Kent

W.

The

OMG

Object

Model

In

Modern

Database

Systems

The

Object

Model

Interoperability

and

Beyond

W.

Kim

ed

Addison-Wesley

Publishing

Company

pp.

-LSB-

-RSB-

Sheth

A.P.

Larson

J.A.

Federated

Database

Systems

for

Managing

Distributed

Heterogeneous

and

Autonomous

Databases

ACM

Computing

Surveys

V.

N.

Set

-LSB-

-RSB-

Silva

S.D.

Melo

R.N.

Um

Modelo

de

Transa

o

para

Sistemas

de

Ger?ncia

de

Bancos

de

Dados

Heterog?neos

in

Simp?sio

Brasileiro

de

Banco

de

Dados

X

Recife

Pernambuco

Anais

Recife

-LSB-

-RSB-

Uch?a

E.M.A.

HEROS

Um

Sistema

de

Bancos

de

Dados

Heterog?neos

Integrando

Esquemas

Rio

de

Janeiro

Pontif?cia

Universidade

Cat?lica

do

Rio

de

Janeiro

p.

Disserta

o

de

Mestrado

em

Inform?tica

Ci?ncia

da

Computa

o.

Departamento

de

Inform?tica

da

PUC-Rio

-LSB-

-RSB-

Uch?a

E.M.A.

Melo

R.N

Lifschitz

S.

Interoperabilidade

de

Objetos

em

Sistemas

de

Bancos

de

Dados

Heterog?neos

Monografia

em

Ci?ncia

da

Computa

o

Pontif?cia

Universidade

Cat?lica

do

Rio

de

Janeiro

Departamento

de

Inform?tica

da

PUC-Rio

p.

Dez

-LSB-

-RSB-

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

Simp?sio

Brasileiro

de

Banco

de

Dados

IX

S?o

Carlos

S?o

Paulo

Anais

S?o

Carlos

-LSB-

-RSB-

Veijalainen

J.

Wolski

A.

Prepare

and

Commit

Certification

for

Decentralized

Transaction

Management

in

Rigorous

Heterogeneous

Database

Systems

In

Proceedings

of

the

International

Conference

on

Data

Engineering

ANEXO

DIAGRAMA

DE

CLASSES

DO

HEROS

ANEXO

DIAGRAMA

DE

INTERA

O

DE

CLASSES

DO

HEROS

corba
heros
heterogeneous database systems
interoperability