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. Costa Instituto de Informática - UFG

Prof. Fábio M. Costa - Instituto de Informática / UFG
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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Por que usar uma IDL? PL PL PL PL 1 2 1 2 PL PL PL IDL PL 6 3 6 3 PL PL PL PL 5 4 5 4 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Mapeamentos para Linguagens de Programação em CORBA
Smalltalk C++ Ada-95 IDL Common Object Model C Java Cobol Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

example.idl // example.idl typedef string<80> NameStr; interface Player { readonly attribute NameStr name; }; interface PlayerFactory { Player createPlayer(in NameStr name); Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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); Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Arquivos Envolvidos, em C++
incluído em gerados example.hh ligado com escritos Player Server.hh Team Server.hh Player Server.cc Team Server.cc Client.cc exampleC.cc exampleS.cc Client Person Server Team Server Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Diagrama de Interações
main Team (Client Stub) ORB TeamDispatch (Server Skeleton) Team Server print request request print reply reply Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

example.idl: Implementação da Interface Player
typedef string<80> NameStr; interface Player { readonly attribute NameStr name; }; interface PlayerFactory { Player createPlayer(in NameStr name); Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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); Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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; Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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; } Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

example.idl: Implementação da 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); Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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); Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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; } Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 ... Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Client.cc (cont.) try { t=tf->createTeam("Germany"); } catch (const Exception &excpt) { cerr << "Unexpected exception " << excpt; exit(1); } cout<< "successfully created team "<< t->name(); goalkeeper=pf->createPlayer("Stefan Klos"); forward=pf->createPlayer("Andy Moeller"); cerr << "Unexpected exception " << excpt ; Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Client.cc (cont.) output=goalkeeper->name(); cout << "created player " << output << endl; output=forward->name(); try { t->add(goalkeeper,1); t->add(forward,10); output=t->print(); cout << output << endl; } catch (const Exception &excpt) { cerr << excpt << endl; exit(1); } Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Plataformas de Middleware Heterogêneas

Motivação Component Component Component Component Component Component Component Middleware Vendor A Middleware Vendor B Middleware Vendor C Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Integração de Plataformas de Middleware
Component Component Component Component Component Component Component OLE ORB ORB ORB RPC Bridge Bridge Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Pontes in-line Em nível de requisições Client ORB Core Obj. Imp. DSI DII Client ORB Core Obj. Imp. Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Interoperabilidade versus Inter-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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Protocolos de Interoperabilidade
Applications CORBA 2.0 GIOP ESIOP IIOP DOETalk DCE-CIOP Mandatory: provides "out of the box" interoperability Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Inter-Funcionamento COM-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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Arquitetura de Inter-Funcionamento
Sistema de Objetos A Sistema de Objetos B Ponte ref. de obj. em A ref. de obj. em B implementação de objeto em B visão em A do objeto alvo em B Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Instanciações Específicas
CORBA server COM client Bridge COM view of CORBA object Target CORBA object CORBA server Automation client Bridge Autom. view of CORBA object Target CORBA object CORBA client COM server CORBA objref Bridge CORBA view of COM object Target COM object CORBA client Automation server CORBA objref Bridge CORBA view of Autom. object Automation object Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Questões de Mapeamento em Inter-Funcionamento
Mapeamento de interfaces Mapeamento de composição de interfaces Mapeamento de identificadores (de objetos) Inversibilidade do mapeamento Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Representações de Dados Heterogê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 memory sign n+3 n+2 n+1 n little-endians memory sign n n+1 n+2 n+3 big-endians Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

O Problema (cont.) Diferentes esquemas de codificação de caracteres P r e u ß e n M ü n s t e r EBCDIC D7 99 85 A4 A2 A2 85 95 40 D4 A4 85 95 A2 A3 85 99 ASCII 50 72 65 75 73 73 65 6E 20 4D 75 76 6E 73 74 65 72 ISO 50 72 65 75 DF 65 6E 20 4D FC 6E 73 74 65 72 UCS 0050 0072 0065 0075 00DF 0065 006E 0020 004D 00FC 006E 0073 0074 0065 0072 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

O Problema (cont.) Diferentes linguagens de programação usam diferentes representações de dados Exemplo: cadeias de caracteres em Pascal e em C++: Pascal memória 3 a b c C++ memória a b c \0 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

O Problema (cont.) Representação little endian e big endian de uma seqüência: sequence<unsigned short>:[2,3] Big endian Little endian 2 2 2 2 3 3 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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) Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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

Exemplo: Alinhamento para Inteiros em CDR
Big Endian Little Endian Byte 12345 0x30 0x39 ( short) 0x39 0x30 1 0x07 0x15 0x5B 0xCD 1 ( long) 0xCD 0x5B 2 0x15 0x07 3 0x00 0xCB 0x00 0x04 1 0x01 0xFB 2 0x1F 0x71 3 ( long long) 0x71 0x1F 4 0xFB x01 5 0x04 0x00 6 0xCB 0x00 7 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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] Big endian Little endian 2 2 2 2 3 Original: Wolfgang Emmerich, 2000 3 Prof. Fábio M. Costa - Instituto de Informática / UFG

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) Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Number #CDATA #REQUIRED Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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=“ ” /> <Player name=“Marcel Desaily” role=“Defender” Number=“5” ... </Team> Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

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. Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG

Sistemas Distribuídos Resolvendo o Problema da Heterogeneidade

Apresentações semelhantes

Apresentação em tema: "Sistemas Distribuídos Resolvendo o Problema da Heterogeneidade"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Sistemas Distribuídos Resolvendo o Problema da Heterogeneidade

Apresentações semelhantes

Apresentação em tema: "Sistemas Distribuídos Resolvendo o Problema da Heterogeneidade"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback