T. D. S. I. PARA WEB
Prof. Emmanuel Nolêto
[email protected]
IDL - Corba
Introdução
• Multicast IP
• Otimização do uso do link eliminando
redundância;
• Múltiplas notificações divididas por grupos.
• Facilidade de desenvolvimento;
• Permite que a aplicação cresça.
Componentes

IDL (Interface Definition Language)



A arquitectura que materializa o sistema.
GIOP (General Inter-ORB Protocol)


A linguagem em que se especificam os
objectos distribuídos
O protocolo de comunicação utilizado nas
invocações
IIOP (Internet Inter-Orb Protocol)

Implementação do GIOP sobre TCP/IP.
Origem



Norma definida pelo OMG (Object Management
Group), uma organização independente
formada em 1989.
O objectivo principal reside em permitir a
implementação de objectos distribuídos em
qualquer linguagem e garantir a
interoperabilidade, mesmo perante cenários de
grande heterogeneidade.
Faz parte de um conjunto de especificações
introduzidas de forma escalonada: 1992, 1995,
..., 2000
Origem
• CORBA (“Common Object Request Broker
Architecture”)
• Especificação da OMG (“Object Management
Group”) para sistemas distribuídos multiplataforma, independente de fornecedor;
• Outra especificação bastante conhecida: UML
• Possui muitas implementações, para várias
linguagem e arquiteturas;
• Inclusive para sistemas embarcados e sistemas
em tempo real (CORBART);
Meta-Modelo de Objectos

“Objecto CORBA” é sinónimo de objecto remoto

Corresponde ao servidor no paradigma C/S



Os clientes não precisam de ser objectos
Os objectos CORBA são independentes de qualquer
linguagem



Aceita invocações (pedidos) e envia respostas
Podem-se traduzir para várias linguagens, mesmo que
não sejam OO
Há mappings standard para: C, C++, Java, COBOL,
Smalltalk, Ada, Lisp, Python, and IDLscript.
Comporta a noção de herança (múltipla).
Meta-Modelo de Objetos

Os objectos CORBA são caracterizados
por uma interface, um identificador único
e são acessíveis através de referências



As referências para os objectos remotos são
opacas
Pode haver múltiplas referências para o
mesmo objecto CORBA
A localização dos objectos remotos está
contida na próprias referências, mas é
completamente
transparente para os
clientes
CORBA
IDL

A linguagem IDL serve para:



Especificar a interface dos objectos remotos
Definir agrupamentos de objectos em
módulos
Estabelecer as relações hierárquicas entre
tipos de objectos
IDL - Módulos
Module A {
… };
Module B {
… Module C {
… };
};
São opcionais e permitem limitar a
visibilidade (escopo) de conjuntos de
definições.
Interfases IDL
module M {
interface I {
… };
};

O tipo dos objectos CORBA é definido
através de um nome único assinalado
com a palavra chave: INTERFASE
 Podem incluir a definição de operações,
tipos, atributos e excepções...
Operações IDL
module M {
interface I {
string op1( in long arg1, out short arg2, inout boolean arg3 ) ;
oneway void shutdown( ... ) ;
};
};
• As operações podem ter (ou não) um resultado e
parâmetros de entrada, saída ou entrada e saída.
• Podem ser assíncronas e lançar exceções ...
Excepções IDL
module M {
exception E1 {
long errorCode;
};
...
Interface I {
void op(...) raises (E1, E2, ...) ;
...
};
};
• Cada operação pode lançar vários tipos de
excepções e estas podem conter variáveis...
Atributos IDL
module M {
interface I {
attribute <type> A1;
readonly attribute <type> A2;
...
};
};



Um objecto CORBA pode ter um ou mais atributos
Os atributos podem ser marcados como sendo só de leitura.
Cada atributo define implicitamente até duas operações
(para fazer a consulta e a atualização dos valores se
permitido).
Tipos básicos do IDL
• Os tipos primitivos usuais, com diversas precisões,
estão presentes em CORBA IDL.
•
•
•
•
•
•
•
Short
unsigned short
long
unsigned long
long long
unsigned long long
float
Tipos básicos do IDL
•
•
•
•
•
•
double
long double
boolean
char
wchar
string
• Estes tipos podem ser usados para construir novos
tipos mais complexos
Tipos complexos do
IDL
module M {
struct { long l;
....}
T1 ;
typedef sequence< T1> T2;
typedef sequence< T2,, 20> T3;
typedef T3 T4[10][20]; };
enum E { e1, e2, e3, ..., en};
• A definição de novos tipos é feita através da palavra chave
typedef. Pode-se definir novos tipos à custa de estruturas,
sequências, arrays, enumerações e unions.
Unions IDL
module M {
enum E { e1, e2, e3, ..., en};
typedef union U switch( E ) {
case e1: string s;
case e2: long l ;
...
default: float f;
} T1 ;
... };
• As unions podem ter a validade dos campos ditada por um
atributo de controlo, ao estilo dos registos com variante da
linguagem Pascal.
Herança IDL
module MyServer {
interface Service {
readonly attribute string name ;
oneway void shutdown() ;
};
interface MyService : Service {
void ping( inout string msg) ;
}; };
• Um objecto CORBA pode derivar de um ou mais
objectos, desde que não haja colisões de nomes
NameService
• O espaço dos nomes dos objectos CORBA é
hierárquico e relativo a uma dada raiz.
• Qualquer caráter pode ser usado na designação de
um objecto
•
Não havendo um separador (“/”), não é (sempre) possível
designar o nome completo por uma string.
•
O código de acesso ao NameService é relativamente complexo.
• O nome é sempre relativo à raiz associada a cada
ORB.
• É possível organizar os NameServices em
federações, para particionar o espaço de nomes, por
exemplo.
Name Services
• São oferecidas as operações usuais de
interacção com um repositório (registry):
• bind(...), unbind(...), rebind(...), resolve(...) e
list(...)
• A operação de listagem devolve um
iterador e evita transferir de uma só vez o
conteúdo do repositório...
Serialização em Java
•
Classes
•
•
•
•
•
•
•
•
•
•
•
Tipos primitivos ( Sim )
Tipos básicos que implementam Serializable ( Sim )
Conteiners caso os objetos sejam serializáveis ( Sim )
Classes que herdam tipos serializáveis (Integer herda Number) ( Sim )
Exceções e erros ( Sim )
Conteiners, componentes e eventos AWT e Swing ( Sim )
Classes matemáticas (java.math) ( Sim )
Classes de reflexão (java.lang.reflect) ( Sim )
Adapter, filters e classes filhas ( Não )
Streams, readers, writers e outras classes de I/O ( Não )
Serialização permitida ( Não )
RMI
Problemas
• Apesar da normalização verificam-se problemas de
interoperabilidade entre ORBs distintos.
•
A melhor maneira de garantir a inter-operabilidade entre
clientes e servidores heterogéneos (linguagens
diferentes) é usar um ORB e ferramentas da mesma
proveniência...
• O servidor precisa de uma interface para expor seus
métodos para JVMs remotas;
• O cliente precisa pensar que está acessando objetos
locais;
• A passagem de objetos e variáveis por valor e por
referência precisa ser resolvida por meio de
serialização.