1 / 62

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. Visão Geral. Linguagens de Programação Heterogêneas Modelo de objetos comum Linguagem de definição de interfaces comum

arva
Télécharger la présentation

Sistemas Distribuídos Resolvendo o Problema da Heterogeneidade

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sistemas DistribuídosResolvendo o Problema da Heterogeneidade Especialização em Redes de Computadores 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  3. Linguagens de Programação Heterogêneas

  4. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  5. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

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

  7. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  8. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

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

  10. 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); }; Prof. Fábio M. Costa - Instituto de Informática / UFG

  11. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

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

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

  14. 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); }; Prof. Fábio M. Costa - Instituto de Informática / UFG

  15. 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; }; Prof. Fábio M. Costa - Instituto de Informática / UFG

  16. 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; } } Prof. Fábio M. Costa - Instituto de Informática / UFG

  17. 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); }; Prof. Fábio M. Costa - Instituto de Informática / UFG

  18. 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); }; Prof. Fábio M. Costa - Instituto de Informática / UFG

  19. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  20. 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; } } Prof. Fábio M. Costa - Instituto de Informática / UFG

  21. 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 ... Prof. Fábio M. Costa - Instituto de Informática / UFG

  22. 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); Prof. Fábio M. Costa - Instituto de Informática / UFG

  23. 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); } } Prof. Fábio M. Costa - Instituto de Informática / UFG

  24. Plataformas de Middleware Heterogêneas

  25. Motivação Component Component Component Component Component Component Component Middleware Vendor A Middleware Vendor B Middleware Vendor C Prof. Fábio M. Costa - Instituto de Informática / UFG

  26. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  27. Integração de Plataformas de Middleware Component Component Component Component Component Component Component OLE ORB ORB ORB RPC Bridge Bridge Prof. Fábio M. Costa - Instituto de Informática / UFG

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

  29. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  30. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  31. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

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

  33. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  34. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  35. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  36. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  37. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  38. Arquitetura deInter-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 Prof. Fábio M. Costa - Instituto de Informática / UFG

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

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

  41. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  42. Representações de DadosHeterogêneas

  43. n+3 n+2 n+1 n memory sign n n+1 n+2 n+3 memory sign 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-endians big-endians Prof. Fábio M. Costa - Instituto de Informática / UFG

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

  45. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

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

  47. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  48. 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) Prof. Fábio M. Costa - Instituto de Informática / UFG

  49. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

  50. 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 Prof. Fábio M. Costa - Instituto de Informática / UFG

More Related