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
– 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
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?
PL1
PL2
PL6
PL1
PL3
PL5
Original: Wolfgang Emmerich, 2000
PL4
PL6
PL2
IDL
PL5
PL3
PL4
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
Cobol
Original: Wolfgang Emmerich, 2000
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> 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
9
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
10
Arquivos Envolvidos, em C++
gerados
incluído em
ligado com
example.hh
escritos
Player
Team
Server.hh Server.hh
Client.cc exampleC.cc exampleS.cc
Client
Original: Wolfgang Emmerich, 2000
Player
Team
Server.cc 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
TeamDispatch
(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> 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
13
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
14
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
15
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
16
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
17
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
18
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
19
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
}
20
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
21
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
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
Motivação
Component
Component
Component
Component
Component
Middleware
Vendor A
Original: Wolfgang Emmerich, 2000
Component
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
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
27
Pontes
• in-line
Client
• Em nível de requisições
Obj. Imp.
Client
Obj. Imp.
DSI
Original: Wolfgang Emmerich, 2000
DII
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 InterFuncionamento
• 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
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
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
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
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-8859-1
50
72
65
75
6E
20
4D
73
74
65
72
UCS
DF
65
FC
6E
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
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
\0
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
0
0
2
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 (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
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
Type Alignment Type
Alignment Type
Alignment
char
1
long
4
double
4
octet
1
long long
8
boolean
1
short
2
float
4
enum
4
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)
0x30
0x39
0x39
0x30
0
1
123456789
(long)
0x07
0x5B
0xCD
0x15
0x15
0xCD
0x5B
0x07
0
1
2
3
1234567890123
(long long)
0x00
0x00
0x01
0x1F
0x71
0xFB
0x04
0xCB
0xCB
0x04
0xFB
0x71
0x1F
0x01
0x00
0x00
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
0
0
2
0
2
0
Little endian
2
0
0
0
2
0
3
Prof. Fábio M. Costa - Instituto de Informática / UFG
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|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
57
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”
/>
...
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