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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 5
Por que usar uma IDL?
PLPL66
PLPL22
PLPL55
PLPL11
PLPL44
PLPL33 PLPL66
PLPL22
PLPL55
PLPL11
PLPL44
PLPL33IDLIDL
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 6
Mapeamentos para Linguagens de Programação em CORBA
IDLIDL
CommonObjectModel
CommonObjectModel
SmalltalkSmalltalk
CobolCobol
JavaJava
Ada-95Ada-95C++C++
CC
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 9
example.idl
// example.idltypedef 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 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);};
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 11
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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 12
Diagrama de Interações
printprint requestrequest requestrequestprintprint
replyreply
mainmain
replyreply
TeamServerTeamServer
TeamDispatch(Server Skeleton)
TeamDispatch(Server Skeleton)ORBORBTeam
(Client Stub)Team
(Client Stub)
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 13
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);};
Original: Wolfgang Emmerich, 2000 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);};
Original: Wolfgang Emmerich, 2000 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;};
Original: Wolfgang Emmerich, 2000 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;
}
}
Original: Wolfgang Emmerich, 2000 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);};
Original: Wolfgang Emmerich, 2000 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);};
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 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; }}
Original: Wolfgang Emmerich, 2000 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
...
Original: Wolfgang Emmerich, 2000 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);
Original: Wolfgang Emmerich, 2000 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); }}
Plataformas de Middleware Heterogêneas
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 25
Motivação
Component
Component
Component
MiddlewareVendor A
Component
MiddlewareVendor B
Component
Component
Component
MiddlewareVendor C
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 27
Integração de Plataformas de Middleware
ORBORB
OLE
RPC
BridgeBridge
ORB
ComponentComponentComponentComponent
ComponentComponent
ComponentComponent
ComponentComponent
ComponentComponent
ComponentComponent
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 28
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
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 32
Protocolos de Interoperabilidade
CORBA 2.0CORBA 2.0
ApplicationsApplications
GIOPGIOP ESIOPESIOP
IIOPIIOP DOETalkDOETalk ................ DCE-CIOPDCE-CIOP ................
Mandatory: provides "out of the box" interoperability
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 38
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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 39
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
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 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
Representações de DadosHeterogêneas
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 43
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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 44
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
Original: Wolfgang Emmerich, 2000 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++:
PascalPascal
C++C++
3memóriamemória a b c
amemóriamemória b c \0
Original: Wolfgang Emmerich, 2000 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]
2020
Big endianBig endian Little endianLittle endian
3
000
02030
002
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 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)
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 51
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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 52
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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 53
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
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 54
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 55
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 56
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 57
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>
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 58
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>
Original: Wolfgang Emmerich, 2000 Prof. Fábio M. Costa - Instituto de Informática / UFG 59
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 60
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 61
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 62
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.
Top Related