Sistemas Distribudos Resolvendo o Problema da Heterogeneidade Especializao
Sistemas Distribuídos Resolvendo o Problema da Heterogeneidade Especialização em Redes de Computadores Prof. Fábio M. Costa Instituto de Informática - UFG Original: Wolfgang Emmerich, 2000 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 2
Linguagens de Programação Heterogêneas Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG
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 4
Por que usar uma IDL? PL 1 PL 2 PL 6 PL 1 PL 3 PL 5 Original: Wolfgang Emmerich, 2000 PL 4 PL 6 PL 2 IDL PL 5 PL 3 PL 4 Prof. Fábio M. Costa - Instituto de Informática / UFG 5
Mapeamentos para Linguagens de Programação em CORBA Smalltalk C++ Ada-95 IDL Common Object Model Java C Original: Wolfgang Emmerich, 2000 Cobol Prof. Fábio M. Costa - Instituto de Informática / UFG 6
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 7
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 8
example. idl // example. idl typedef string<80> Name. Str; interface Player { readonly attribute Name. Str name; }; interface Player. Factory { Player create. Player(in Name. Str name); }; Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 9
example. idl (cont. ) interface Team { readonly attribute Name. Str name; exception Invalid. Number{}; exception Number. Occupied{}; exception No. Player. At. Number{}; void add(in Player a. Player, in short number) raises (Invalid. Number, Number. Occupied); void remove(in short number) raises (Invalid. Number, No. Player. At. Number); string print(); }; interface Team. Factory { Team create. Team(in Name. Str teamname); }; Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 10
Arquivos Envolvidos, em C++ gerados incluído em ligado com example. hh escritos Player Team Server. hh Client. cc example. C. cc example. S. cc Client Original: Wolfgang Emmerich, 2000 Player Team Server. cc Person Server Team Server Prof. Fábio M. Costa - Instituto de Informática / UFG 11
Diagrama de Interações main Team (Client Stub) print ORB request reply Original: Wolfgang Emmerich, 2000 Team. Dispatch (Server Skeleton) request Team Server print reply Prof. Fábio M. Costa - Instituto de Informática / UFG 12
example. idl: Implementação da Interface Player // example. idl typedef string<80> Name. Str; interface Player { readonly attribute Name. Str name; }; interface Player. Factory { Player create. Player(in Name. Str name); }; Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 13
Player. Server. hh #include "example. hh" class Player. Server: public virtual Player. BOAImpl{ private: char * the_player_name; public: Player. Server(); virtual Name. Str name(); virtual void set_name(char *); }; class Player. Factory. Server : public virtual Player. Factory. BOAImpl { virtual Player * create. Player(Name. Str); }; Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 14
Player. Server. cc #include "Player. Server. hh" Name. Str Player. Server: : name(){ char * ret; ret = new char[strlen(the_player_name)+1]; strcpy(ret, the_player_name); return(ret); }; Player * Player. Factory. Server: : create. Player( Name. Str name) { Player. Server * a. Player = new Player. Server; a. Player->set_name(name); a. Player->_duplicate(); return a. Player; }; Wolfgang Emmerich, 2000 Original: Prof. Fábio M. Costa - Instituto de Informática / UFG 15
Player. Server. cc (cont. ) int main(int argc, char* argv[]) { Player. Factory. Server myplayergenerator; try { CORBA: : BOA. impl_is_ready("Player. Factory"); } 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 16
example. idl: Implementação da Interface Team interface Team { readonly attribute Name. Str name; exception Invalid. Number{}; exception Number. Occupied{}; exception No. Player. At. Number{}; void add(in Player a. Player, in short number) raises (Invalid. Number, Number. Occupied); void remove(in short number) raises (Invalid. Number, No. Player. At. Number); string print(); }; interface Team. Factory { Team create. Team(in Name. Str teamname); }; Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 17
Team. Server. hh #include "example. hh" class Team. Server : public virtual Team. BOAImpl { private: Player * the_team[MAXPLAYERS+1]; char * the_team_name; public: virtual void set_name(char *); virtual Name. Str name(); virtual void add(Player *, short); virtual void remove(short); virtual char * print(); }; class Team. Factory. Server : public virtual Team. Factory. BOAImpl { virtual Team * create. Team(Name. Str); }; Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 18
Team. Server. cc #include "Team. Server. hh" void Team. Server: : add(Player *a. Player, short num){ if (num<1 || num > MAXPLAYERS) { throw(Invalid. Number); } else if ((the_team[num]!=NULL)) { throw(Number. Occupied); } else { a. Player->_duplicate(); the_team[num]=a. Player; } Demais métodos: remove, print }; Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 19
Team. Server. cc (cont. ) Team* Team. Factory. Server: : create. Team( Name. Str name) { Team. Server * a. Team = new Team. Server; a. Team->set_name(name); a. Team->_duplicate(); return(a. Team); }; int main(int argc, char* argv[]) { Team. Factory. Server myteamgenerator; try { CORBA: : BOA. impl_is_ready("Team. Factory"); } catch (const Exception &excpt) { cerr << excpt; } Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG } 20
Client. cc #include "example. hh" int main(int argc, char* argv[]) { Player. Factory * pf; Team. Factory * 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 21
Client. cc (cont. ) try { t=tf->create. Team("Germany"); } catch (const Exception &excpt) { cerr << "Unexpected exception " << excpt; exit(1); } cout<< "successfully created team "<< t->name(); try { goalkeeper=pf->create. Player("Stefan Klos"); forward=pf->create. Player("Andy Moeller"); } catch (const Exception &excpt) { cerr << "Unexpected exception " << excpt ; exit(1); Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 22
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); } } Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 23
Plataformas de Middleware Heterogêneas Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG
Motivação Component Component Middleware Vendor A Original: Wolfgang Emmerich, 2000 Component Middleware Vendor B Middleware Vendor C Prof. Fábio M. Costa - Instituto de Informática / UFG 25
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 26
Integração de Plataformas de Middleware Component Component OLE ORB ORB Bridge Original: Wolfgang Emmerich, 2000 RPC Bridge Prof. Fábio M. Costa - Instituto de Informática / UFG 27
Pontes • in-line Client • Em nível de requisições Obj. Imp. Client Obj. Imp. DSI B OR e Cor Original: Wolfgang Emmerich, 2000 OR B e Cor B OR e Cor DII ore O C RB Prof. Fábio M. Costa - Instituto de Informática / UFG 28
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 29
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 30
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 31
Protocolos de Interoperabilidade Applications CORBA 2. 0 ESIOP GIOP 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 32
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 Original: Wolfgang Emmerich, 2000 ØÉ um protocolo abstrato: implementação de acordo com a tecnologia disponível Prof. Fábio M. Costa - Instituto de Informática / UFG 33
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 34
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 35
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 36
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 interfuncionamento 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 37
Arquitetura de Inter-Funcionamento Sistema de Objetos A ref. de obj. em A Sistema de Objetos B Ponte ref. de obj. em B visão em A do objeto alvo em B Original: Wolfgang Emmerich, 2000 implementação de objeto em B Prof. Fábio M. Costa - Instituto de Informática / UFG 38
Instanciações Específicas Bridge Target CORBA object COM view of CORBA object CORBA server COM client CORBA objref Target CORBA object CORBA server CORBA objref Bridge CORBA view of COM object Target COM object CORBA view of Autom. object CORBA client COM server CORBA client Original: Wolfgang Emmerich, 2000 Autom. view of CORBA object Automation client Bridge Automation object Automation server Prof. Fábio M. Costa - Instituto de Informática / UFG 39
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 40
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 41
Representações de Dados Heterogêneas Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG
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 n+3 little-endians n+2 n+1 n+2 n+3 memory sign n big-endians memory sign Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 43
O Problema (cont. ) • Diferentes esquemas de codificação de caracteres P r e u ß e n M ü n s t e r EBCDIC D 7 99 85 A 4 A 2 85 95 40 D 4 A 4 85 95 A 2 A 3 85 99 ASCII 50 72 65 75 73 73 65 6 E 20 4 D 75 76 6 E 73 74 65 72 ISO-8859 -1 50 72 65 75 6 E 20 4 D 73 74 65 72 UCS DF 65 FC 6 E 0050 0072 0065 0075 00 DF 0065 006 E 0020 004 D 00 FC 006 E 0073 0074 0065 0072 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 44
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 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 45
O Problema (cont. ) • Representação little endian e big endian de uma seqüência: sequence<unsigned short>: [2, 3] Big endian Original: Wolfgang Emmerich, 2000 0 2 0 3 Little endian 2 0 0 0 2 0 3 0 Prof. Fábio M. Costa - Instituto de Informática / UFG 46
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 47
Abordagens • Camada de apresentação: Representação de Dados Padronizada – XDR da Sun (e. Xternal 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 48
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 viceversa • 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 49
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 50
Alinhamento de Dados em CDR Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 51
Exemplo: Alinhamento para Inteiros em CDR Big Endian Little Endian Byte 12345 (short) 0 x 30 0 x 39 0 x 30 0 1 123456789 (long) 0 x 07 0 x 5 B 0 x. CD 0 x 15 0 x. CD 0 x 5 B 0 x 07 0 1 2 3 1234567890123 (long) 0 x 00 0 x 01 0 x 1 F 0 x 71 0 x. FB 0 x 04 0 x. CB 0 x 04 0 x. FB 0 x 71 0 x 1 F 0 x 01 0 x 00 0 1 2 3 4 5 6 7 Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 52
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 Original: Wolfgang Emmerich, 2000 0 2 0 3 2 0 0 0 2 0 3 Prof. Fábio M. Costa - Instituto de Informática / UFG 0 Little endian 53
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 54
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 55
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 56
Exemplo: DTD XML para Times de Futebol <!ELEMENT Team ((Player|Player. Trainer)*)> <!ATTLIST Team name #CDATA #REQUIRED> <!ELEMENT Player. Trainer EMPTY> <!ATTLIST Player. Trainer 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 Original: > Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 57
Exemplo: DTD XML para Times de Futebol (cont. ) <!DOCTYPE Team SYSTEM “Soccer. dtd”> <Team name=“Chelsea FC”> <Player. Trainer name=“Gianluca Vialli” role=“Forward” Number = “ 10” Salary=“ 10000000” /> <Player name=“Marcel Desaily” role=“Defender” Number=“ 5” />. . . Original: Wolfgang Emmerich, 2000 </Team> Prof. Fábio M. Costa - Instituto de Informática / UFG 58
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 59
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 60
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 61
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 62
- Slides: 62