Sistemas Distribuídos Resolvendo o Problema da Heterogeneidade

Sistemas Distribuídos

Resolvendo o Problema da Heterogeneidade

Especialização em Redes de Computadores

Prof. Fábio M. CostaInstituto de Informática - UFG

Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 2

Visão Geral• Linguagens de Programação Heterogêneas

– Modelo de objetos comum

– Linguagem de definição de interfaces comum

– Mapeamentos para linguagens de programação

• Plataformas de Middleware Heterogêneas– Interoperabilidade

– Inter-funcionamento

• Representações de Dados Heterogêneas– Representação de dados padrão

– Protocolo de transporte em nível de aplicação

– Máquinas virtuais

Linguagens de Programação Heterogêneas


Motivação

• Os componentes de sistemas distribuídos são escritos em diferentes linguagens de programação

• Estas linguagens de programação podem ou não impor seus próprios modelos de objetos

• Modelos de objetos variam bastante

• Estas diferenças precisam ser contornadas para facilitar a integração


Por que usar uma IDL?

PLPL66

PLPL22

PLPL55

PLPL11

PLPL44

PLPL33 PLPL66

PLPL22

PLPL55

PLPL11

PLPL44

PLPL33IDLIDL


Mapeamentos para Linguagens de Programação em CORBA

IDLIDL

CommonObjectModel

CommonObjectModel

SmalltalkSmalltalk

CobolCobol

JavaJava

Ada-95Ada-95C++C++

CC


Finalidade de um Modelo de Objetos Comum

• Meta-modelo para o sistema de tipos da plataforma de middleware

• Define o significado de:– Tipos de objetos– Operações– Atributos– Requisições– Exceções– Sub-tipagem

• Definido de maneira genérica o suficiente para permitir mapeamentos para a maioria das linguagens de programação


Linguagem de Definição de Interfaces

• Uma linguagem para se expressar todos os conceitos do modelo de objetos da plataforma de middleware

• Independente de linguagem de programação

• Mapeamentos para diferentes linguagens de programação são necessários

• Exemplo: OMG/IDL– Permite expressar os conceitos do modelo de

objetos de CORBA


example.idl

// example.idltypedef string<80> NameStr;

interface Player { readonly attribute NameStr name;};

interface PlayerFactory { Player createPlayer(in NameStr name);};


example.idl (cont.)

interface Team { readonly attribute NameStr name; exception InvalidNumber{}; exception NumberOccupied{}; exception NoPlayerAtNumber{}; void add(in Player aPlayer, in short number) raises (InvalidNumber,NumberOccupied); void remove(in short number) raises (InvalidNumber,NoPlayerAtNumber); string print();};interface TeamFactory { Team createTeam(in NameStr teamname);};


Arquivos Envolvidos, em C++example.hhexample.hh

exampleC.ccexampleC.cc exampleS.ccexampleS.cc

PlayerServer.hh

PlayerServer.hh

TeamServer.hh

TeamServer.hh

PlayerServer.cc

PlayerServer.cc

TeamServer.cc

TeamServer.ccClient.ccClient.cc

ClientClient PersonServerPersonServer

TeamServerTeamServer

incluído emincluído emligado comligado com

escritosescritos

geradosgerados


Diagrama de Interações

printprint requestrequest requestrequestprintprint

replyreply

mainmain

replyreply

TeamServerTeamServer

TeamDispatch(Server Skeleton)

TeamDispatch(Server Skeleton)ORBORBTeam

(Client Stub)Team

(Client Stub)


example.idl: Implementação da Interface Player

// example.idltypedef string<80> NameStr;

interface Player { readonly attribute NameStr name;};

interface PlayerFactory { Player createPlayer(in NameStr name);};


PlayerServer.hh#include "example.hh"class PlayerServer:public virtual PlayerBOAImpl{ private: char * the_player_name; public: PlayerServer(); virtual NameStr name(); virtual void set_name(char *);};class PlayerFactoryServer : public virtual PlayerFactoryBOAImpl { virtual Player * createPlayer(NameStr);};


PlayerServer.cc#include "PlayerServer.hh"NameStr PlayerServer::name(){ char * ret; ret = new char[strlen(the_player_name)+1]; strcpy(ret,the_player_name); return(ret);};Player * PlayerFactoryServer::createPlayer( NameStr name) { PlayerServer * aPlayer = new PlayerServer; aPlayer->set_name(name); aPlayer->_duplicate(); return aPlayer;};


PlayerServer.cc (cont.)

int main(int argc, char* argv[]) {

PlayerFactoryServer myplayergenerator;

try {

CORBA::BOA.impl_is_ready("PlayerFactory");

} catch (const Exception &excpt) {

// an error occured calling impl_is_ready()

cerr << excpt;

}

}


example.idl: Implementação da Interface Team

interface Team { readonly attribute NameStr name; exception InvalidNumber{}; exception NumberOccupied{}; exception NoPlayerAtNumber{}; void add(in Player aPlayer, in short number) raises (InvalidNumber,NumberOccupied); void remove(in short number) raises (InvalidNumber,NoPlayerAtNumber); string print();};interface TeamFactory { Team createTeam(in NameStr teamname);};


TeamServer.hh#include "example.hh"class TeamServer : public virtual TeamBOAImpl { private: Player * the_team[MAXPLAYERS+1]; char * the_team_name; public: virtual void set_name(char *); virtual NameStr name(); virtual void add(Player *, short); virtual void remove(short); virtual char * print();};class TeamFactoryServer : public virtual TeamFactoryBOAImpl { virtual Team * createTeam(NameStr);};


TeamServer.cc

#include "TeamServer.hh"

void TeamServer::add(Player *aPlayer,short num){

if (num<1 || num > MAXPLAYERS) {

throw(InvalidNumber);

} else if ((the_team[num]!=NULL)) {

throw(NumberOccupied);

} else {

aPlayer->_duplicate();

the_team[num]=aPlayer;

}

}; Demais métodos: remove, print


TeamServer.cc (cont.)

Team* TeamFactoryServer::createTeam( NameStr name) { TeamServer * aTeam = new TeamServer; aTeam->set_name(name); aTeam->_duplicate(); return(aTeam);};

int main(int argc, char* argv[]) { TeamFactoryServer myteamgenerator; try { CORBA::BOA.impl_is_ready("TeamFactory"); } catch (const Exception &excpt) { cerr << excpt; }}


Client.cc

#include "example.hh"int main(int argc, char* argv[]) { PlayerFactory * pf; TeamFactory * tf; Team * t; Player *goalkeeper, *forward; char * output; //obtain references for player and team factory

...


Client.cc (cont.) try { t=tf->createTeam("Germany"); } catch (const Exception &excpt) { cerr << "Unexpected exception " << excpt; exit(1); } cout<< "successfully created team "<< t->name(); try { goalkeeper=pf->createPlayer("Stefan Klos"); forward=pf->createPlayer("Andy Moeller"); } catch (const Exception &excpt) { cerr << "Unexpected exception " << excpt ; exit(1);


Client.cc (cont.) output=goalkeeper->name(); cout << "created player " << output << endl; output=forward->name(); cout << "created player " << output << endl; try { t->add(goalkeeper,1); t->add(forward,10); output=t->print(); cout << output << endl; } catch (const Exception &excpt) { cerr << excpt << endl; exit(1); }}

Plataformas de Middleware Heterogêneas


Motivação

Component

Component

Component

MiddlewareVendor A

Component

MiddlewareVendor B

Component

Component

Component

MiddlewareVendor C


Quando é Necessário Ter Diferentes Plataformas de Middleware

• Implementações de plataformas de middleware se diferenciam em vários critérios:– Mapeamentos de linguagens de programação

disponíveis– Serviços e facilidades disponíveis– Plataformas de hardware suportadas– Plataformas de sistemas operacionais suportadas

• Separação de domínios de segurança

• Sistemas distribuídos em larga escala


Integração de Plataformas de Middleware

ORBORB

OLE

RPC

BridgeBridge

ORB

ComponentComponentComponentComponent

ComponentComponent

ComponentComponent

ComponentComponent

ComponentComponent

ComponentComponent


Pontes

Client

ORB CoreORB Core

Obj. Imp.Client

ORB CoreORB Core

Obj. Imp.

DSI DII

• in-line• in-line • Em nível de requisições• Em nível de requisições


Integração de Middleware

• Interoperabilidade: habilidade de diferentes implementações do mesmo padrão de middleware operarem em conjunto– Requer a definição de protocolos de interação

• Inter-funcionamento: integração de diferentes padrões de middleware– Requer

• Mapeamento entre modelos de objetos

• Definição de protocolos de interação


Interoperabilidade versusInter-funcionamento

• Interoperabilidade entre diferentes implementações do mesmo padrão– Ex.: entre diferentes produtos CORBA

• Inter-funcionamento entre diferentes padrões– CORBA ↔ DCE– CORBA ↔ COM/DCOM/OLE

• Fazem parte do padrão da OMG:– Interoperabilidade em CORBA– Inter-funcionamento entre COM e CORBA


Referências de Objeto Interoperáveis (IORs)

• Referências de objetos são “opacas” para os clientes

• Fabricantes de ORBs têm liberdade para definir implementação das referências

• IORs são usadas para apresentar referências de objetos no formato nativo de cada ORB– Formato padrão (IOR) traduzido para o formato

nativo de cada ORB


Protocolos de Interoperabilidade

CORBA 2.0CORBA 2.0

ApplicationsApplications

GIOPGIOP ESIOPESIOP

IIOPIIOP DOETalkDOETalk ................ DCE-CIOPDCE-CIOP ................

Mandatory: provides "out of the box" interoperability


General Inter-ORB Protocol (GIOP)

• Define sete tipos de mensagens padrão trocados entre ORBs distintos– Request – Reply– Locate Request– Locate Reply– Cancel request– Close Connection– Message Error

É um protocolo abstrato: implementação de acordo com a tecnologia disponível


Internet Inter-ORB Protocol (IIOP)

• Mapeia GIOP para TCP/IP

• Provê operações para abrir e fechar conexões TCP/IP

• É requisito necessário para conformidade com o padrão CORBA

• Suportado por todos os ORBs CORBA existentes no mercado– Ex.: ORB embutido no Netscape Communicator


Representação de Dados Comum

• Definida como parte do GIOP• Implementação da camada de apresentação

para suporte à heterogeneidade• Mapeamento de tipos de dados IDL para

fluxos de bytes segundo o protocolo de transporte

• Define codificação para:– Tipos primitivos– Tipos estruturados– IORs


Motivação para Inter-Funcionamento

• COM e OLE/Automation são amplamente utilizados para a integração de aplicações em desktops– Documentos compostos– Interfaces com o usuário (VB, VC++)

• OMG ainda não oferece suporte para documentos compostos e interfaces com o usuário

• COM e OLE não suportam distribuição– embora DCOM, introduzido posteriormente, o faça

• CORBA foi projetada para suportar distribuição


Inter-FuncionamentoCOM-CORBA

• Objetivo: prover um mapeamento bi-direcional e transparente entre COM/OLE e CORBA

• A especificação adotada foi submetida em conjunto por 11 fabricantes de ORBs– A maioria deles já tinha esta habilidade de inter-

funcionamento implementada em seus ORBs

– Adotada em março de 1996

• A Microsoft decidiu não se envolver neste esforço– Ao invés disto, procurou definir seu próprio ambiente

distribuído: DCOM


Arquitetura deInter-Funcionamento

Sistema deObjetos ASistema deObjetos A

Sistema deObjetos BSistema deObjetos B

ref. de obj.em A

ref. de obj.em A

PontePonte

ref. de obj.em B

ref. de obj.em B

visão em A doobjeto alvo em Bvisão em A doobjeto alvo em B

implementaçãode objeto em Bimplementaçãode objeto em B


Instanciações Específicas

CORBA client COM server

CORBAobjref

Bridge

CORBA viewof COM object

Target COMobject

CORBA client Automation server

CORBAobjref

Bridge

CORBA view ofAutom. object

Automationobject

CORBA server COM client

Bridge

COM view ofCORBA object

Target CORBAobject

CORBA server Automation client

Bridge

Autom. view ofCORBA object

Target CORBAobject


Questões de Mapeamento em Inter-Funcionamento

• Mapeamento de interfaces

• Mapeamento de composição de interfaces

• Mapeamento de identificadores (de objetos)

• Inversibilidade do mapeamento


CORBA COM

• Habilita clientes COM a fazerem acesso a objetos CORBA

• Mapeamento razoavelmente óbvio:– Tipos atômicos de IDL são semelhantes aos tipos

primitivos de COM– Tipos estruturados: idem– Referências de objeto CORBA mapeiam para ponteiros

de interface COM– Herança de interfaces em CORBA pode ser

representada por meio de objetos COM com múltiplas interfaces

– Atributos CORBA são mapeados para operações get e set em COM

Representações de DadosHeterogêneas


O Problema

• Os computadores onde residem cliente e servidor podem usar diferentes formatos de representação de dados– Servidores RISC/Unix: big-endian– Estações NT e PCs/Unix: little endian

little-endianslittle-endians

big-endiansbig-endians

memorymemorysignsign

n+3n+3 n+2n+2 n+1n+1 nn

memorymemorysignsign

nn n+1n+1 n+2n+2 n+3n+3


O Problema (cont.)

• Diferentes esquemas de codificação de caracteres

EBCDIC

ASCII

ISO-8859-1

UCS 0050 0072 0065 0075 00DF 0065 006E 0020 004D 00FC 006E 0073 0074 0065 0072

50 72 65 75 DF 65 6E 20 4D FC 6E 73 74 65 72

50 72 65 75 73 73 65 6E 20 4D 75 76 6E 73 74 65 72

D7 99 85 A4 A2 A2 85 95 40 D4 A4 85 95 A2 A3 85 99

P r e u ß e n M ü n s t e r


O Problema (cont.)

• Diferentes linguagens de programação usam diferentes representações de dados

• Exemplo: cadeias de caracteres em Pascal e em C++:

PascalPascal

C++C++

3memóriamemória a b c

amemóriamemória b c \0


O Problema (cont.)

• Representação little endian e big endian de uma seqüência:

sequence<unsigned short>:[2,3]

2020

Big endianBig endian Little endianLittle endian

3

000

02030

002


Motivação

• Representações de dados precisam ser convertidas entre objetos clientes e servidores heterogêneos

• Esta conversão deve ser transparente para o desenvolvedor de aplicações

• A conversão pode ser feita:– na implementação da camada de apresentação– na implementação da camada de aplicação– na implementação da plataforma


Abordagens

• Camada de apresentação: Representação de Dados Padronizada– XDR da Sun (eXternal Data Representation)– CDR da OMG (Common Data Representation)

• Camada de aplicação: uso de uma notação de sintaxe abstrata– ASN.1– XML & SGML

• Plataforma: Máquina Virtual (ex.: Java)


Common Data Representation da OMG

• CDR define como ORBs de diferentes fabricantes trocam dados entre si

• Define como tipos definidos em IDL são mapeados para fluxos de octetos (bytes) e vice-versa

• Lida com o mapeamento de:– tipos atômicos (primitivos)

– tipos estruturados

– pseudo-tipos (ex.: exceções)

– referências de objeto


Mapeamento CDR para Tipos Atômicos

• Inclui ambas as codificações little e big endian– Mensagens explicitam a codificação escolhida– Receptor é responsável pela conversão, se

necessária– Reduz o overhead para transferência de dados

entre máquinas com a mesma representação

• Determina tamanhos padrão (e alinhamentos) para todos os tipos atômicos


Alinhamento de Dados em CDR

Type Alignment Type Alignment Type Alignmentchar 1 long 4 double 4octet 1 long long 8 boolean 1short 2 float 4 enum 4


Exemplo: Alinhamento para Inteiros em CDR

Big Big EndianEndian Little Little EndianEndian ByteByte

1234512345 0x300x30 0x390x39 00((short)short) 0x390x39 0x300x30 11

0x070x07 0x150x15 00123456789123456789 0x5B0x5B 0xCD0xCD 11((long)long) 0xCD0xCD 0x5B0x5B 22

0x150x15 0x070x07 33

0x000x00 0xCB0xCB 000x000x00 0x040x04 110x010x01 0xFB0xFB 22

12345678901231234567890123 0x1F0x1F 0x710x71 33((long long long)long) 0x710x71 0x1F0x1F 44

0xFB0xFB 00x01x01 550x040x04 0x000x00 660xCB0xCB 0x000x00 77


Mapeamento CDR para Tipos Estruturados

• Número de elementos (em uma dada codificação)

• Elementos como resultado do mapeamento de tipos aninhados (atômicos ou estruturados)

• Exemplo: sequence<unsigned short>:[2,3]

2020

Big endianBig endian Little endianLittle endian

3

000

02030

002


Mapeamento CDR para Referências de Objeto

• Informação necessária para representar uma referência de objeto:– se é NULL (não será usada para requisições)– Tipo do objeto referenciado– Protocolos suportados– Serviços do ORB envolvidos no acesso ao

objeto através da referência

• Estas informações são fornecidas nas Referências de Objeto Interoperáveis (IORs)


Resolução na Camada de Aplicação

• A plataforma de middleware somente pode resolver a heterogeneidade se ela sabe como os dados estão estruturados

• Algumas vezes não é apropriado revelar as estruturas de dados para o middleware:– A plataforma não precisa realizar qualquer processamento das

estruturas de dados– Definições de interface se tornariam desnecessariamente

complexas– Transformações de dados durante marshalling e

unmarshalling não podem ser toleradas– Os dados estão estruturados segundo uma abordagem

específica do domínio da aplicação


Abordagens para Domínios Específicos

• ASN.1– Abstract Syntax Notation, definida pela

International Telecommunication Union (ITU)

• SGML– Usada na área de automação de escritórios

• XML– Intercâmbio de dados estruturados na Web


Exemplo: DTD XML para Times de Futebol

<!ELEMENT Team ((Player|PlayerTrainer)*)><!ATTLIST Team name #CDATA #REQUIRED><!ELEMENT PlayerTrainer EMPTY><!ATTLIST PlayerTrainer name #CDATA #REQUIRED role (Defender|Midfield|Forward) #REQUIRED Number #CDATA #REQUIRED Salary #CDATA #REQUIRED

><!ELEMENT Player EMPTY><!ATTLIST Player name #CDATA #REQUIRED role (Defender|Midfield|Forward) #REQUIRED Number #CDATA #REQUIRED>


Exemplo: DTD XML para Times de Futebol (cont.)

<!DOCTYPE Team SYSTEM “Soccer.dtd”><Team name=“Chelsea FC”> <PlayerTrainer name=“Gianluca Vialli” role=“Forward” Number = “10” Salary=“10000000” /> <Player name=“Marcel Desaily” role=“Defender” Number=“5” /> ...</Team>


Resolvendo a Heterogeneidade no Nível da Plataforma

• Máquina Virtual– Uma plataforma acima do sistema operacional– Por definição, impõe uma representação de

dados comum


Exemplo: Máquina Virtual Java• Define os seguintes tipos atômicos:

– boolean: representado como um int– byte: inteiro de 8 bits sinalizado, em complemento de dois– short: inteiro de 16 bits sinalizado, em compl. de dois– int: inteiro de 32 bits sinalizado, em compl. de dois– long: inteiro de 64 bits sinalizado, compl. de dois– char: caracter UCS de 16 bits– float: número de ponto flutuante de 32 bits, segundo o

padrão IEEE 754– double: número de ponto flutuante de 64 bits, segundo o

padrão IEEE 754


Pontos-Chave

• Heterogeneidade pode ocorrer em vários níveis:– Linguagem de Programação– Middleware– Representação de Dados

• CORBA e COM resolvem a heterogeneidade de linguagem de programação através de uma IDL com mapeamentos para várias linguagens

• Heterogeneidade de middleware é resolvida através de especificações de interoperabilidade e inter-funcionamento


Pontos-Chave

• Heterogeneidade de dados pode ser resolvida através de:– Representações de dados padronizadas

• CDR, NDR, XDR

– Estruturação dos dados no nível das aplicações• XML, SGML, ASN.1

– Máquinas Virtuais• JVM, Python VM, etc.

Sistemas Distribuídos Resolvendo o Problema da Heterogeneidade

Documents

Transcript of Sistemas Distribuídos Resolvendo o Problema da Heterogeneidade