Jrmi

PLATAFORMAS DISTRIBUÍDAS
Introdução aos
Eleri Cardozo
Sistemas Distribuídos
FEEC/UNICAMP
http://www.fee.unicamp.br/~eleri
Julho de 2002
(c) FEEC/UNICAMP 1 (c) FEEC/UNICAMP 2
Sistemas Distribuídos: Definição Sistemas Distribuídos: Motivação
Um sistema distribuído é um sistema computacional

com as seguintes propriedades: Evolução em microprocessadores: constante incremento
da capacidade de processamento com decréscimo de custo.
1. distribuição: um subconjunto de seus componentes
encontram-se geograficamente dispersos; Evolução em redes de comunicação: velocidades de
2. concorrência: um subconjunto de seus componentes Gigabits/s já disponíveis a custo atrativo.
executam concorrentemente (em paralelo);
3. ausência de estado global: é impossível determinar-se Portanto, a utilização de uma rede rápida de processadores
precisamente o estado global do sistema; poderosos é atrativa para abrigar sistemas complexos de
4. falhas parciais: qualquer componente do sistema software.
pode falhar independente dos demais;
5. assincronismo: as atividades do sistema não são
regidas por um relógio global.
Evolução em Microprocessadores Evolução em Redes
MIPS Mbits/s
100000
20 BIPS
10000 10000 10 Gbits/s
1000 1000
DEC Alpha ATM
Gigabit Ethernet
HP PA
100 100 T. Ring Fast Ethernet
Pentium FDDI
10 Mips 10 Ethernet
486
ISDN Frame Relay
386 X.25
1 286 1
1982 1987 1992 1997 2002 2007 1982 1987 1992 1997 2002 2007
Downsizing Downsizing: Benefícios
• liberdade de escolha (fornecedores, produtos, etc.);
$$$ • confiabilidade (múltiplos pontos de falha);
• processamento espacial da informação;
• aumento incremental da capacidade de processamento;
$$$ • atualização tecnológica constante.
Internet Sistemas Abertos
Sistemas Abertos são sistemas implementados

segundo padrões abertos.
Padrão aberto: documento estabelecido por

consenso e publicado por organismo de
padronização acreditado para uso comum e
repetitivo.
NOTA: esta definição exclui muitos padrões de-facto tais como

Java, Windows e MATLAB.
Sistemas Abertos: Uma Classificação Modelos de Referência
Um modelo de referência é uma descrição de todos

Podemos classificar Sistemas Abertos em quatro os possíveis componentes do sistema, bem como
categorias: suas funções, relações, e formas de interação [SEI].
Exemplos: OSI, RM-ODP, OMA.
1. Modelos de Referência;
2. Arquiteturas de Referência; Por não imporem restrições para a realização de
3. Arquiteturas Abertas; seus componentes, modelos de referência não
4. Implementações de Referência. garantem interoperabilidade entre diferentes
implementações. Entretanto, modelos de referência
são úteis para a concepção de arquiteturas para
sistemas abertos.
Arquiteturas de Referência Arquiteturas
Uma arquitetura de referência é similar a um modelo

de referência, mas prescreve interfaces entre seus Uma arquitetura é similar a um modelo ou arquitetura
componentes. de referência, mas prescreve protocolos de interopera-
Exemplos: TINA, CORBAservices. bilidade para todos os seus componentes.
Exemplos: CORBA, H.323, TCP/IP, ISDN.
Arquiteturas de referência possuem lacunas na
especificação que levam a diferentes interpretações Arquiteturas provêem interoperabilidade mínima entre
e possibilidades de extensões. Estas lacunas tendem suas implementações.
a comprometer a interoperabilidade entre diferentes
implementações da arquitetura.
Implementações de Referência Exemplo de Padrão Aberto: CORBA
CORBA CORBA
Objetos de
Facilities Facilities
Uma implementação de referência provê código Aplicação (vertical) (horizontal)
fonte aberto (não necessariamente gratuito) para
os componentes de uma arquitetura que são Object Request Broker (ORB)
fundamentais para a interoperabilidade entre
diferentes implementações desta arquitetura. O modelo de Serviços CORBA
Exemplos: FreeDCE, TMN API, HTTPd. referência OMA. (CORBAservices)
Implementações de referência garantem o maior CORBA especifica o Object Request Broker do modelo OMA.
nível possível de interoperabilidade para implemen- Interoperabilidade entre implementações CORBA é garantida
tações de sistemas abertos. pela linguagem IDL e pelo protocolo IIOP.
Sistemas Abertos: Conclusão

Exemplo de Padrão Aberto: CORBA
• IDL e IIOP garantem que duas implementações Sistemas abertos são fundamentais para:
CORBA sempre irão interoperar no tocante a
invocação remota de métodos. • tornar as implementações menos dependentes
de fornecedor individual;
• Serviços CORBA (CORBAservices) nem sempre
• incentivar a competição entre diferentes
interoperam pois apenas suas interfaces são
especificadas (faltam implementações de referência fornecedores por melhores produtos;
e/ou melhor especificação de comportamento). • desenvolver aplicações portáveis, confiáveis,
com alto grau de interoperabilidade e capazes
• Gerência, configuração e recursos avançados de de evoluir de forma ordenada;
diferentes implementações CORBA não interoperam.
• incentivar a inserção de novas tecnologias.

O Conceito de Middleware
Visão a Partir do Modelo OSI
OPA! Isto eu
conheço!!!
O Conceito de
Middleware APLICAÇÃO
APRESENTAÇÃO
SESSÃO
TRANSPORTE
REDE
ENLACE
FÍSICO
Conceito de Middleware e o Modelo OSI Conceito de Middleware e o Modelo OSI
Medicina
Telecomunicações
Finanças
Agente
Cliente Agente
} Gerenciamento de Rede
APLICAÇÃO
Ex: funções típicas de
telecomunicações } Domínio de aplicação
APLICAÇÃO
APRESENTAÇÃO
APRESENTAÇÃO
SESSÃO
SESSÃO
TRANSPORTE Um novo Modelo OSI: camada nível 8
TRANSPORTE contendo funções típicas dos vários
REDE domínios de aplicação:Medicina,
REDE Finanças, Telecomunicações, etc.
ENLACE
ENLACE
FÍSICO
FÍSICO
Conceito de Middleware e o Modelo OSI Conceito de Middleware e o Modelo OSI
Domínio da aplicação Domínio da aplicação
APLICAÇÃO Contexto da APLICAÇÃO
APRESENTAÇÃO Aplicação APRESENTAÇÃO

A Camada de Transporte SESSÃO
SESSÃO é um divisor entre o MIDDLEWARE
TRANSPORTE mundo das aplicações e o TRANSPORTE
mundo das comunicações
REDE Contexto das REDE
Comunicações ENLACE
ENLACE
FÍSICO FÍSICO

Conceito de Middleware e o Modelo OSI
Evolução em Middleware
Domínio da aplicação
agentes
APLICAÇÃO componentes
APRESENTAÇÃO objetos
Necessidade de distribuídos
chamada de
SESSÃO Padronização do procedimento
Middleware remoto (RPC)
troca de
mensagens
}
Sistema
Operacional Sistemas Heterogêneos!
+
Hardware 1977 1982 1987 1992 1997 2002 2007
Evolução do Conceito de Middleware

Troca de Mensagens (primitivas SEND/RECEIVE) Troca de Mensagens: Semântica
Aplicação Aplicação
tarefa 1 tarefa 2
Send Receive
API independente do send(M1)
TLI CPC-I Socket Named Pipes transporte send(M1)
tarefa 1 receive(M2) tarefa 2 receive(M1)

receive(M2)
SNA TCP/IP IPX/SPX NetBIOS Pilhas de Transporte
bloqueio
send(M2)
NDIS ODI Drivers de Rede
... Placas de Rede
Token-ring Ethernet ISDN

Troca de Mensagens: Implementação Chamada Remota de Procedimento (RPC)
Aplicação Aplicação
2- Call (…) 1- Register (…) 3- Call (…)
Remote Procedure Call (RPC)

espaço do usuário
TLI CPC-I Socket Named Pipes
espaço do núcleo port (endpoint)
API API
(socket) buffer (socket)
SNA TCP/IP IPX/SPX NetBIOS
sistema de sistema de
transporte transporte NDIS ODI
(TCP/IP) (TCP/IP)
LAN / WAN
Token-ring Ethernet
ISDN
RPC: Semântica RPC: Implementação
cliente servidor cliente servidor

R = call P2(a1,a2) P1 P2 P3
call P2(a1,a2) call P2(a1,a2)
cliente servidor 8 1 5
P2(a1,a2) 4
P1 bloqueio dispatcher
P2 executa empacota desempacota desempacota empacota

P2 parâmetros resultado parâmetros resultado
retorno bibliotecas
P3 RPC
retorno 2 7 3 6
a2 a1 P2
API API
(socket) (socket)
resultado

Objetos Distribuídos
Objetos: Constituição
• O conceito de objetos surgiu para atender os requisitos
relacionados ao aumento na complexidade do desenvolvimento estado: define um conjunto de variáveis
de software Reusabilidade internas que armazenam o estado
corrente do objeto
Objeto
interface: define, em termos de
protótipo, um conjunto de operações
(ou métodos)
implementação: código dos métodos

definidos tanto pelas interfaces quantos
Barramento de Software internos ao objeto
Interface Padrão
Objetos: Regras de Interação Objetos: Conceitos Básicos
• toda a interação com um objeto se dá através da invocação de Classificação: objetos são organizados em classes. Uma
seus métodos declarados como públicos; classe define o comportamento dos objetos dela derivados.
• métodos declarados como privados só podem ser invocados Relacionamento: classes podem apresentar relações de
pelos demais métodos definidos pelo objeto; interdependência, por exemplo
• herança (relação tipo é-um /é-uma);
• as variáveis de estado são manipuladas apenas pelos métodos • composição (relação tipo parte-de);
(públicos ou privados) definidos pelo objeto (isto é, são invisíveis • colaboração (relações tipo usa, delega, autoriza, etc).
externamente ao objeto).

Objetos: Conceitos Básicos
Objetos: Conceitos Básicos
classe classe
Instanciação: objetos são criados através de uma operação relação
(denominada de instanciação) sobre uma classe.
Encapsulamento: objetos “escondem” detalhes de sua encapsulamento instanciação herança (especialização)

implementação interna, expondo apenas suas interfaces para o
meio externo. estado
classe
Identidade: objetos possuem identidade única capaz de diferenciar métodos
um objeto dos demais. interface
M1 M3 invocação de métodos
Polimorfismo: métodos de mesmo nome podem apresentar identidade
diferentes comportamentos, dependendo do objeto que o M2
implementa. polimorfismo M2
Objetos Distribuídos Objetos Distribuídos: Vantagens
Deve-se notar que as tecnologias de middleware procuram Objetos distribuídos apresentam as seguintes vantagens
acompanhar as tecnologias de desenvolvimento de software: sobre troca de mensagens e RPC:
• troca de mensagens: estende o paradigma de programação • flexibilidade: qualquer entidade de software pode ser
não estruturada à programação de sistemas distribuídos transformada em um objeto distribuído;
(programação distribuída); • granularidade: objetos distribuídos podem apresentar
diferentes níveis de granularidade;
• RPC: estende o paradigma de programação estruturada à • confiabilidade: objetos distribuídos são entidades auto-
programação distribuída; contidas o que facilita a identificação, isolação e correção
de falhas;
• objetos distribuídos: estende o paradigma de programação • custo: o desenvolvimento de objetos distribuídos é mais
orientada a objetos à programação distribuída. econômico graças ao reuso de software propiciado pela
programação orientada a objetos.
Objetos Distribuídos: Interação Interfaces Remotas
Objetos distribuídos são capazes de interagir através de uma rede Objetos distribuídos devem definir pelo menos uma interface
de comunicação (LAN, Intranet, Internet) de forma semelhante à remota capaz de processar invocações através da rede. Em
interação entre objetos locais. Para tanto, padrões são necessários padrões neutros (independentes de linguagem de programação)
para prover: como CORBA e DCOM, uma linguagem de definição de interface
• definição de interfaces remotas; (IDL) é especificada. ORBs provêem compiladores IDL para cada
• identificação de objetos (referências); linguagem alvo.
• "nomeação" de objetos (naming);
• associação nome-referência (binding); RMI, por ser uma solução puramente Java, utiliza interfaces Java
• suporte à invocação remota de métodos (RPC). derivadas da interface Remote para definir interfaces remotas.
Estes padrões são oferecidos por uma infra-estrutura denominada Um servant (ou implementação) é um objeto que implementa
ORB (Object Request Broker). Por exemplo, RMI é o ORB nativo uma interface remota (i.e., supre código para os métodos da
da linguagem Java. interface). Um objeto distribuído é constituído por um ou mais
servants.
Referência de Objetos
Objetos Distribuídos: Implementação
Descrição da(s) ORB (biblioteca) Objetos distribuídos devem possuir uma identificação
Interface(s) (referência) capaz de localizá-lo na rede. Esta identificação
é dependente do ORB. Por exemplo, CORBA utiliza um
identificador denominado IOR (Interoperable Object
Compilador
Compilador de
Reference) que agrega o endereço de rede do objeto (host e
(C++, Java, ...)
Interfaces port do servidor), sua classe, seu identificador no servidor,
etc. IOR é armazenado em uma cadeia de bytes.
Implementação RMI utiliza as próprias instâncias das classes Java que

Stubs / Skeletons dos Servants implementam interfaces remotas para identificar objetos
(C++, Java, ...) distribuídos.
servant OBS: Uma referência pode ser persistente ou transiente.
Stubs e Skeletons Atribuição de Nomes
Para interagir com um objeto remoto, um objeto cliente deve obter

a referência do objeto remoto e converte-la em um objeto local
denomindo proxy ou stub. Stubs definem os mesmos métodos da ORBs convencionam esquemas de nomes para os objetos
interface remota do objeto. Ao invocar um método no stub, o stub distribuídos. Por exemplo, CORBA utiliza um espaço hierárquico
encaminha a requisição para o objeto remoto, recebe o retorno e o e arbitrário de nomes definido em um contexto.
devolve como resultado da interação. Skeletons fazem o papel
inverso do stub no lado do objeto remoto. RMI utiliza uma notação padrão URL:
interface rmi://ferrugem.dca.fee.unicamp.br:8088/Servers/AccountServer
cliente remota
//143.106.50.188/AccountServer
M1 Stub Rede Skeleton M1
M1 M1 objeto
M2 upcall M2 distribuído
invocação local M3 protocolo M3
de RPC
Binding Invocação Remota de Métodos
ORBs provêem serviços de nomes para armazenar e recuperar A invocação de métodos remotos exige protocolos de RPC
associações nome-referência de objeto. No caso do RMI, um (Remote Procedure Call). Tais protocolos especificam:
servidor de nomes denominado rmiregistry é fornecido com a • como parâmetros são codificados (número de parâmetros,
plataforma Java. tipos, valores e indireções);
• como invocações e retornos são estruturados;
servidor • que protocolo de transporte é utilizado (TCP ou UDP);
de nomes 1. bind/rebind • como exceções são propagadas de volta para o cliente.
2. lookup
CORBA especifica o protocolo IIOP (Internet Inter-ORB

Protocol), enquanto RMI especifica JRMP (Java Remote
3. invoke objeto Method Protocol). Opcionalmente, para fins de
cliente distribuído
interoperabilidade com CORBA, RMI pode utilizar IIOP.

Arquitetura de Distribuição Middleware: Padrões
DCOM EJB
servidor Indústria (Microsoft) (Sun)
RMI .NET
cliente objeto (SUN) (Microsoft)
servant
distribuído
DCE CORBA SOAP
Consórcios (OSF) (OMG) (W3C)
Stub Skeleton OSI ODP ISO/ITU-T

Object Request Broker
TCP/IP sockets RPC WWW Internet
Serviços Nomes Eventos Segurança 1977 1982 1987 1992 1997 2002
Plataforma Java 2
A Plataforma Java 2 consiste de uma linguagem (Java),

um ambiente de runtime (máquina virtual) e um conjunto
de serviços de middleware disponibilizados através de
Plataforma Java interfaces de programação (APIs).
Linguagem Java
Máquina Virtual
APIs
Plataforma Java 2: Arquitetura Plataformas Java 2

APIs
A SUN Microsystems fornece três tipos de plataformas Java 2:
Applets, Pacotes, Frameworks Suporte às
Aplicações • Java 2 Platform, Micro Edition (J2ME): plataforma de
desenvolvimento para dispositivos pequenos, tais como Palm Pilots,
Classes Java Classes Java Pagers, etc. Contém uma forma bem restrita da linguagem Java;
Estendidas Básicas
Plataforma
Java Básica • Java 2 Platform, Standard Edition (J2SE): contém serviços Java
bytecodes para Applets e Aplicações. Contém funcionalidades para entrada-
Máquina Virtual Java
saída, interfaces gráficas de usuários, entre outras;
Interface de
Portabilidade
Adaptador Adaptador • Java 2 Platform, Enterprise Edition (J2EE): plataforma de
S.O. Java
desenvolvimento completa para empresa fornecendo um ambiente
Browser seguro, multi-usuário, portável, neutro (Sistema Operacional e
S.O.
S.O. Hardware) para o desenvolvimento de aplicações distribuídas escritas
Java Chip
Hardware Hardware em Java (com ënfase no lado servidor).

Plataforma Java 2EE: Tecnologias Plataforma Java 2EE: Tecnologias
• Enterprise JavaBeans (EJB) • JNDI (Java Naming and Directory Interface)

Define uma API que facilita a criação, instalação e gerência de Provê acesso unificado a serviços de nomes e de diretório para as
aplicações baseadas em componentes. Utiliza RMI para aplicações Java.
comunicação cliente-servidor.
service providers
Servidor EJB
OMG COSNaming
JNDI SPI
JNDI API
Container EJB RMI Registry
EJB Home
Interface EJB Bean JNDI Naming
Cliente Manager
Cliente
EJB Remote Internet LDAP
Interface
Database
Novell NDS

• JTA (Java Transaction API) e JTS (Java
• JBDC (Java Database Connectivity)
Transaction Service)
Provê uma interface uniforme para acesso a bases de dados.
Definem APIs para um serviço de transação em
Java (baseados no Serviço de Transações do OMG
- CORBA OTS). JTA é utilizada no EJB.
JDBC
JDBC
Driver Database A Transaction
Driver A JTS API
JDBC API API Coordinator
JTA API
JDBC
Cliente JDBC Database B Transaction
Driver B JTS
Cliente Manager(s)
JDBC
Driver C Database C Resource
Datastores Manager(s)
• RMI-IIOP (Java Remote Method Invocation -

• Java IDL (Interface Definition Language)
CORBA Internet Inter-ORB Protocol)
Permite aplicações Java interoperarem com outras plataformas
CORBA (ex. Orbix). Prove compilador IDL e ORB simples que Permite clientes Java acessarem, via RMI, serviços disponibilizados
suporta IIOP. em CORBA (e vice-versa). RMI-IIOP utiliza JNDI.
Cliente Servidor Cliente

Applet Servidor Servidor Cliente Servidor
CORBA CORBA RMI
Java EJB RMI CORBA CORBA
(C++) (C++)
RMI-IIOP
IIOP API
Java 2 ORB Orbix RMI ORB CORBA ORB

IIOP

Plataforma Java 2EE: API Específicas,
Plataforma Java 2EE: Tecnologias Extensões, Pacotes e Produtos
• Outras Tecnologias: Java Media Framework (JMF): API para manipulação (local e
através da rede) de áudio e vídeo;
Java Server Pages (JPS) e Servlets: APIs que permitem estender Java TV API: API para serviços interativos em TV digital (ex:
as funcionalidades de um servidor WWW; vídeo sob demanda);
Java Phone API: API para serviços de telefonia (ex: click-to-dial);
Java Message Service (JMS): API para serviços de mensagens; Java Commerce Toolkit: pacote para desenvolvimento de
aplicações de comércio eletrönico;
JavaMail: API para serviços de E-mail; Java Cryptography Extension e Java Authentication and
Authorization Service: extensões de segurança;
J2EE Connector: arquitetura para conectar a plataforma Java 2 Java 2D, Java 3D, Java Advanced Imaging: APIs para
com outros serviços de informação da empresa.
computação gráfica;
Jini: serviços de suporte à redes com topologia variável;
.......... Dentre muitos outros !!!
Java Remote Method Invocation (RMI)

RMI: Visão Geral
Naming.lookup host
RMI é um ORB nativo da linguagem Java que provê uma rmi://host:port/Name rmiregistry
infra-estrutura para invocação de métodos remotos, um
compilador para geração de stubs e skeletons (rmic) e um Naming.bind
cliente RMI ObjRef rmi://host:port/Name
servidor de nomes (rmiregistry). RMI utiliza o mecanismo de
ObjRef
segurança nativo da linguagem Java através de security Naming
managers e class loaders. s.M1(...) servidor RMI
Naming
RMI tem como vantagens simplicidade e plena integração rmic Servant
com Java (segurança, carregamento dinâmico de classes, M1 M2 M3
M1 M2 M3
passagem de objetos por valor, etc.). Entretanto, é uma

JRMP
solução 100% Java (mas capaz de interoperar com outras stub skel.
TCP/IP
linguagens de programação através de CORBA). socket socket
IIOP
(c) FEEC/UNICAMP 63 TCP/IP

(c) FEEC/UNICAMP 64
Java RMI
RMI: Interfaces Remotas
Interfaces remotas em RMI são declaradas como interfaces Java

O ciclo de desenvolvimento de objetos distribuídos em
que estendem a interface Remote. Cada método da interface
RMI possui os seguintes passos: remota deve lançar uma exceção do tipo RemoteException (que
será propagada ao cliente).
1. definição da interface remota;
2. compilação da interface remota (javac); import java.rmi.Remote;
3. desenvolvimento do servant; import java.rmi.RemoteException;
4. geração de stubs e skeletons a partir do servant via public interface Account extends Remote {
compilador RMI (rmic); void deposit( long amount ) throws RemoteException;
5. desenvolvimento do servidor. void withdraw( long amount ) throws RemoteException;
long balance() throws RemoteException;
}
RMI: Passagem de Parâmetros em Métodos
de Interfaces Remotas RMI: Servants
import java.rmi.*;
Parâmetros e retornos em invocações remotas são sempre import java.rmi.server.*;
passados por valor (isto e, uma cópia é passada). Objetos
Java passado como parâmetros devem ser "serializáveis" public class AccountServant implements Account
(todos os tipos nativos são). {
long balance;
Referências de objetos remotos podem ser passados como long limit;
parâmetros ou retorno (no caso, uma cópia de seu stub é
passada). Tais objetos devem possuir apenas interfaces public AccountServant(long lim) throws RemoteException {
remotas. super();
balance = 0;
Caso a classe de um objeto passado ou retornado não se limit = lim;
encontra presente na JVM, a mesma pode ser carregada }
dinamicamente via HTTP (detalhes a seguir).
RMI: Servants (cont.) RMI: Classes
public void deposit( long amount ) throws RemoteException { <<interface>> AccountClient

Remote AccountServant_Stub
balance = balance + amount;
}
deposit()
public void withdraw( long amount ) throws RemoteException { AccountServant withdraw()
balance()
if((limit + balance - amount) < 0) extends
throw new RemoteException("Limit Exceeded"); deposit()
<<interface>> geradas por rmic
balance = balance - amount; withdraw()
} Account balance()
AccountServant_Skel
public long balance() throws RemoteException { deposit()
return balance; withdraw() implements deposit()
} balance() withdraw()
} balance()
RMI: rmic (Compilador RMI) RMI: Serviço de Nomes
A plataforma Java provê um compilador capaz de gerar

stubs e skeletons para suporte à distribuição de objetos A plataforma Java provê um serviço de nomes para registro de
com RMI. O compilador recebe como argumento a classe servants RMI. O serviço de nomes é suportado por um servidor
compilada do servant e gera dois arquivos compilados: um transiente, rmiregistry, que armazena as referências de objetos
contendo o stub (utilizado pelo cliente) e outro o skeleton localizados em seu próprio nó.
(utilizado pelo servidor). Exemplo:
C:\ dir *.class A referência de objeto no formato URL estipula o seu endereço
Account.class de host e, opcionalmente, port do servidor de nomes. Exemplo:
AccountServant.class seja um objeto registrado como:
C:\ rmic AccountServant rmi://ferrugem.dca.fee.unicamp.br/Servers/AccountServer
C:\ dir *.class O acesso à referência do objeto deve se dar no endereço de
Account.class host "ferrugem.dca.fee.unicamp.br" e port default do servidor
AccountServant.class de nomes (1099).
AccountServant_Stub.class
AccountServant_Skel.class
RMI: A Classe Naming RMI: Servidores
O servidor de nomes rmiregistry é acessível através da classe

Naming que provê os seguintes métodos estáticos: import java.rmi.*;
import java.rmi.server.*;
import java.net.*;
• void bind(String name, Remote ref): associa um nome a uma
referência de objeto; public class AccountServer {
• void rebind(String name, Remote ref): re-associa um nome a public static void main(String[] args)
uma referência de objeto; {
• Remote loopkup(String name): busca uma referência // if no security manager was set, set the RMI´s one
associada ao nome; if(System.getSecurityManager() == null) {
• void unbind(String name): desassocia a referência do nome; System.setSecurityManager(new RMISecurityManager());
• String[] list(String registry): lista todos os nomes mantidos }
por um servidor rmiregistry.
RMI: Servidores (cont.) RMI: Clientes
import java.rmi.*;
import java.net.*;
try {
String host = (InetAddress.getLocalHost()).getCanonicalHostName(); public class AccountClient {
String name = "rmi://" + host + "/Account"; public static void main(String args[]) {
Account objRef = new AccountServant((long)1000); if(args.length != 1) {
Naming.rebind(name, objRef); // bind System.out.println("I need the server's host name as argument");
System.out.println("AccountServant registered"); System.exit(0);}
} catch (Exception e) { // if no security manager was set, set the RMI´s one
System.err.println("AccountServant exception: " + if (System.getSecurityManager() == null) {
e.getMessage()); System.setSecurityManager(new RMISecurityManager());}
e.printStackTrace(); try { // get reference of the remote object
} String host =
} (InetAddress.getByName(args[0])).getCanonicalHostName();
String name = "rmi://" + host + "/Account";
Account accountRef = (Account) Naming.lookup(name);
RMI: Clientes (cont.) RMI: Aspectos de Segurança
No lado servidor, RMI exige que todas as permissões de socket

accountRef.deposit( 100 );
sejam habilitadas para os domínios onde os clientes se localizam.
accountRef.deposit( 300 );
accountRef.deposit( 100 ); Adicionalmente, permissão para conexão local ao port 1099
accountRef.withdraw( 240 ); (rmiregistry) deve ser habilitada. Por exemplo, o trecho do arquivo
accountRef.withdraw( 10 ); .java.policy abaixo libera interações com clientes localizados em
System.out.println("Balance is " + accountRef.balance()); qualquer host do domínio "dca.fee.unicamp.br"
accountRef.withdraw( 10000 );
} catch (Exception e) { grant {
System.err.println("AccountClient exception: " + permission java.net.SocketPermission "*.dca.fee.unicamp.br",
e.getMessage());
"listen,accept,connect";
}
permission java.net.SocketPermission "localhost:1099",
}
} "connect";
};

RMI Sobre HTTP RMI: Propriedades
Devido a presença de firewalls, uma requisição RMI pode ser

impedida de atingir o objeto remoto. Nestes casos, é possível O comportamento de clientes e servidores RMI pode ser
tunelar-se a requisição RMI sobre o protocolo HTTP. configurado através de propriedades da máquina virtual. As
mais comuns são:
cliente Serv. HTTP • java.rmi.server.codebase: localização (URL) das classes que

RMI devem ser carregadas dinamicamente (skeletons, parâmetros,
Firewall script CGI etc.);
servidor
HTTP POST (java-rmi.cgi) • java.rmi.server.logCalls: gera um log em System.err;
proxy RMI
Stub HTTP • java.rmi.activation.port: define um port de ativação para o
daemom RMI (default 1098);
Skeleton • java.rmi.server.disableHttp: desabilita tunelamento através
de HTTP.
sockets especiais
Como Distribuir um Objeto ?
• Os métodos públicos têm que ser definidos de forma

precisa através de uma sintaxe neutra. Para tal emprega-
se uma Linguagem de Descrição de Interfaces (IDL). ODP (Open Distributed
• Deve-se prover uma infra-estrutura que permita a Processing)
invocação remota (através da rede) de métodos. Esta
infra-estrutura é denominada Object Request Broker
(ORB).
• Deve-se conectar os métodos públicos ao ORB para

permitir sua invocação remota. Os componentes de
conexão, denominados stubs e skeletons, são gerados
integralmente por um Compilador IDL.
Modelo OSI Modelo OSI
O Modelo OSI possui algumas funcionalidades na

camada 7 para o desenvolvimento de sistemas Problemas no desenvolvimento de Sistemas Distribuídos
distribuídos: diretamente sobre o OSI:
• ROSE (Remote Operation Service Element); • baixa disponibilidade de implementações completas;

• CCR (Concurrency, Commitment, Recovery); • padrão “estacionado”;
• TP (Transaction Processing); • ausência de serviços importantes (segurança,
• DS (Directory Service); principalmente);
• MHS (Message Handling System). • ASN.1/BER pouco flexível;
• eficiência dos protocolos.

ODP: Open Distributed Processing ODP: Pontos de Vista
Empresa
Padrão OSI/ITU-T para processamento distribuído aberto
(ITU-T X.901,902,903,904).
É um modelo de referência apenas (protocolos não Informação Computação

são especificados) que vem influenciando outras especificação
SD
atividades de padronização (exemplo: CORBA). implementação
Seu desenvolvimento foi fortemente influenciado pelo

projeto ANSA (Universidade de Lancaster, UK).
Engenharia Tecnologia
ODP: Pontos de Vista ODP: Pontos de Vista
Pontos de vista não são hierarquizados, mas

especificação
sim diferentes visões de um mesmo sistema. Empresa
Informação SD Computação
SD
implementação
ponto de vista
ORB
Tecnologia
Engenharia
ODP: Ponto de Vista de Empresa ODP: Ponto de Vista de Empresa
O ponto de vista de empresa modela o sistema em termos de

grandezas relevantes para a organização onde o sistema será Grandezas relevantes para este ponto de vista:
empregado.
• requisitos (QoS, custos, ...);
Em linhas gerais, pode ser considerada um “resumo executivo” • objetivos (mercados, público-alvo, …);
do sistema, onde suas principais características são levantadas. • benefícios (lucro, produtividade, …);
Este ponto de vista estabelece as principais restrições impostas • políticas (segurança, acesso, taxação, ...);
ao projeto do sistema. • domínios administrativos/federações;
• restrições/privilégios de uso do sistema;
Não existe uma linguagem formal para descrever o sistema • pontos de referência (protocolos, acordos, ...);
neste ponto de vista. Textos, gráficos, diagramas, esquemas • funcionalidades (agentes, relações, contratos, ...).
podem ser livremente utilizados.

ODP: Ponto de Vista de Informação ODP: Ponto de Vista de Informação
O ponto de vista de informação tem por

Objetos de informação identificam as principais
objetivo modelar o sistema enfocando a
entidades do domínio, suas relações (especialização,
informação produzida e consumida pelo
decomposição, etc.) e principais variáveis e
sistema.
operações.
Neste ponto de vista são levantados os
Este ponto de vista pode ser descrito através de
principais componentes manipuladores
notação gráfica introduzidas por metodologias de
de informação, componentes estes
desenvolvimento orientado a objeto (UML, OMT, …).
denominados objetos de informação.
ODP: Ponto de Vista de Computação ODP: Ponto de Vista de Computação
O ponto de vista de computação modela o sistema No ODP, objetos computacionais básicos (BCO: basic
computacional object) possuem múltiplas interfaces
em termos de entidades de processamento de computacionais, cada uma associada a determinado tipo.
informação. Estas entidades, denominadas objetos O tipo define as características da interface.
computacionais, são os blocos fundamentais a
partir dos quais o sistema distribuído é contruido.
interface computacional
Este ponto de vista pode ser descrito através de BCO
notação gráfica introduzidas por metodologias de
desenvolvimento orientado a objeto (UML, OMT, …). T2
T1 tipo da interface
ODP: Interfaces Computacionais ODP: Ligação (Binding) Primitiva
Na ligação primitiva dois objetos computacionais básicos

iniciador sinal respondedor têm suas interfaces conectadas sem o auxílio de um
sinal artefato específico de interconexão. Exemplo: objetos
C++ num mesmo programa.
cliente evocação servidor
operação T T’
terminação
BCO BCO
produtor consumidor
fluxo T’: tipo complementar a T
stream

ODP: Ligação (Binding) Composta ODP: Ponto de Vista de Engenharia
Na ligação composta dois objetos computacionais O ponto de vista de engenharia fornece a visão
básicos têm suas interfaces conectadas com o auxílio “espacial” (distribuída) do sistema. Nesta visão os
de um artefato específico de interconexão. Na visão de objetos computacionais (BCO e BO) da visão de
computação este artefato é representado por um objeto computação são realizados através de objetos
de ligação (BO: binding object). básicos de engenharia (BEO: Basic Engineering
Object). Regras de estruturação que estabelecem
agrupamentos e ligações entre BEOs.
interface
de controle
Este ponto de vista pode ser descrito através de
diagramas de distribuição (deployment) da notação
BCO BO BCO UML.
T T’ T T’
ODP: Ponto de Vista de Engenharia ODP: Regras de Estruturação
Objetos Básicos de Cluster

Engenharia (BEO) checkpoint, recover, delete, ...
checkpoint, recover, delete, ...
Cluster é um agregado de BEOs
São as unidades de compartilhando um mesmo espaço
processamento no ponto interface de de endereçamento. Um BEO
gerenciamento
de vista de engenharia. especial no cluster (Gerente de GCL
Possuem uma interface de Cluster - GCL) provê uma interface
gerenciamento e uma ou de gerenciamento para o cluster. É
mais interfaces de serviço,
BEO BEO
a unidade de migração do ODP.
interfaces estas denomi-
nadas interfaces de
engenharia. interface de engenharia
CLUSTER
ODP: Regras de Estruturação ODP: Regras de Estruturação
checkpoint, recover, delete, ...

Nó
Cápsula
Um nó é composto de um conjunto
Cápsula é um agregado de de cápsulas e um núcleo. No ODP
GCP
clusters. Um BEO especial na o nó representa uma unidade de CÁPSULA
cápsula (Gerente de Cápsula) processamento, armazenamento e núcleo
GCL GCL
provê uma interface de geren- comunicação. Exemplo: estação
ciamento para a cápsula. É a UNIX.
unidade de alocação de CLUSTER CLUSTER
recursos do ODP (exemplo:
processo UNIX).
CÁPSULA
CÁPSULA NÓ

ODP: Regras de Estruturação ODP: Canal
Canal BEO1 BEO2

Stub
interface
de controle
Canal é a realização do Stub é responsável pelos serviços de
objeto de ligação na visão stub stub
apresentação (conversão/compactação de
de engenharia. É composto contr.
de três objetos básicos de de canal dados, criptografia, etc) do canal.
engenharia de cada lado: binders
stub, binder e protocol Apresenta uma interface de dados para o
adapter. Adicionalmente, objeto de engenharia no extremo do canal e
protocol adapters
um controlador de canal
canal uma interface de controle utilizada pelo
expõe uma interface única
de controle para o canal. controlador de canal.
rede
ODP: Canal ODP: Canal
Binder
Protocol Adapter
Binder é responsável pelo gerenciamento fim-a-
fim do canal. Funções típicas do binder: Protocol Adapter é responsável pela
monitoramento do fluxo de informação através comunicação fim-a-fim no canal. Funções
do canal, gerência de qualidade de serviço e típicas: estabelecimento e encerramento de
destruição de seu extremo do canal. conexões de transporte através da rede.
Possui interfaces de dados para o stub e Apresenta uma interface de dados para o
protocol adapter, além de uma interface de binder e uma interface de controle utilizada
controle utilizadada pelo controlador de canal. pelo controlador de canal.
ODP: Canal ODP: Mapeamento Computação/Engenharia
Controlador de Canal
BCO1 BEO1 BEO2
Controlador de canal apresenta uma interface única
de controle para o canal. Esta interface realiza na
visão de engenharia a interface computacional do stub stub
objeto de ligação (BO) presente na visão de contr.

de canal
BO
computação.
binders
Controlador de canal interage com os demais protocol adapters

BCO2
objetos do canal para realizar a ação de controle canal
solicitada em sua interface. transparência rede

ODP: Transparência ODP: Transparência
Tipos de transparência:
Transparência é um conceito chave que permite a
visão de engenharia (associada à implementação • acesso;
do sistema) se aproximar da visão de computação • localização;
(associada ao modelamento do sistema). • migração;
• concorrência (transação);
• relocação;
Transparência deve ser provida pelo núcleo, • falha;
canal e demais infra-estruturas de suporte à • replicação;
implementação (ORBs, repositórios, etc.). • persistência.
As transparências de acesso e localização são as mais

comumente encontradas nos sistemas distribuídos.
DCE: Distributed Computing Environment
Padrão da antiga Open Software Foundation (OSF),

hoje Open Group.
DCE (Distributed Computing
Environment) OSF é um consórcio sem fins lucrativos de empresas
(IBM, DEC, HP,…) destinado a padronização de
tecnologias de software para sistemas abertos.
Exemplo: OSF/1 (UNIX “não AT&T”)
OSF/Motif (similar ao X Window)
Diferentemente de organizações como a OMG

e ISO, a OSF supre os implementadores com um
código fonte base.
DCE: Objetivos DCE: Arquitetura

APLICAÇÕES DISTRIBUÍDAS
Oferecer um conjunto de serviços distribuídos
(RPC, sistema de arquivos, serviços de segurança, Sistema de Arquivos
diretório e relógio distribuído) independentes de
plataforma sobre os quais aplicações distribuídas Time Diretório Segurança
são construídas.
DCE Remote Procedure Call
Estes serviços são baseados em padrões já
DCE Threads
consagrados tais como X.500 (ISO/ITU-T), DNS
(IETF) e POSIX (IEEE).
SISTEMA OPERACIONAL REDE
HARDWARE
DCE: Threads DCE: Threads
espaço de en- espaço de endere-
OBJETIVO: uniformizar a programação multithreaded. dereçamento çamento comum
escalonamento
Utiliza o padrão POSIX 1003.4a (IEEE). T
H
T T T
Provê três esquemas de escalonamento de threads: R
H H
H
• FIFO (First In First Out) E
R R R
A
• RR (Round Robin) E E E
D tempo
• Default (RR com prioridades) A A A
D D D
processo
monothreaded processo multithreaded
DCE: Threads DCE: Threads
A programação multithreaded permite que servidores Formas de Escalonamento:

processem uma requisição enquanto outra estiver
pendente (bloqueada por I/O, por exemplo). FIFO A B C
cliente RR A B C A B C B C B B
req #1
servidor
multi-
DEF. A B C A B C C
threaded
cliente
req #2
Pb > Pa, Pc
DCE: Remote Procedure Call DCE: RPC
• Integrado com os serviços de thread, segurança SERVIÇO DE

e diretório; DIRETÓRIO
3. server ? 2. registra serviço
• Independente da pilha de protocolos de rede;
5. RPC
• Permite a passagem de argumentos de tamanho cliente servidor
ilimitado e de ponteiros;
4. endpoint ? RPC 1. registra endpoint
• Utiliza uma linguagem de definição de interfaces: daemon
IDL - Interface Definition Language (diferente da tabela de
IDL do CORBA !) endpoints

DCE: RPC DCE: RPC
stub do stub do
uuidgen gera ID único cliente cabeçalho
servidor
contém a definição
Editor arquivo IDL
da interface do serviço runtime lib código do código do runtime lib
(cliente) cliente servidor (servidor)
compilador IDL
Compilador C Compilador C
stub do stub do
cliente cabeçalho código C SERVIDOR
servidor CLIENTE
DCE: Serviço de Relógio Distribuído (DTS) DCE: DTS
fonte de tempo
Objetivo: garantir que os relógios das máquinas
(não requerida)
com DCE instalado:
• são consistentes (marcam o mesmo tempo); time time
• são corretos (seguem a mesma referência). server server
time ?
DTS é necessário para a ordenação de eventos rede
numa aplicação distribuída.
No DCE, tempo é armazenado num contador de

time time time
64 bits cujo valor zero corresponde a 00:00 Hs de clerk clerk clerk
15/10/1582 !
UTC
DCE: DTS DCE: Serviço de Diretório
Forma de operação:
Objetivo: manter a localização (host) de servidores.
UTC server #1
O serviço de diretório é estruturado em dois níveis:
UTC server #2 • Nível local (de célula): registra os recursos
locais (CDS: Cell Directory Service)
UTC server #3 • Nível Global: permite acesso a recursos remotos
UTC server #4 (GDS: Global Directory Service)
GDS é baseado nos padrões X.500 (ISO/ITU-T)

TIME CLERK
e DNS (Internet Domain Name System).

DCE: Serviço de Diretório DCE: Serviço de Segurança
Arquitetura: Objetivo: prover acesso seguro aos recursos.

outros servidores
No DCE, segurança compreende três atividades:
servidor DNS X.500 DA
• Autenticação: comprovação da identidade de
clientes e servidores;
célula
• Autorização: quem está autorizado a manipular

CDS GDA CDS GDA CDS GDA
determinado recurso;
CDS: Cell Directory Service • Proteção: garantir que a informação não se

GDA: Global Direcory Agent alterou em trânsito.
DCE: Serviço de Segurança DCE: Serviço de Segurança

AUTENTICAÇÃO AUTORIZAÇÃO
Utiliza a tecnologia Kerberos (MIT).
Utiliza listas de controle de acesso (ACL: Access Control
Um servidor de segurança (security server) gerencia a List). ACL é um padrão POSIX 1003.6.
distribuição de tickets (informação criptografada contendo
as identidade de pares cliente-servidor). Cada recurso possui uma ACL que discrimina os
privilégios para usuários e grupos de usuários.
Tickets são usados para o estabelecimento de Exemplos de privilégios: read, write, execute.
RPC Autenticada (segura).
ACLs são armazenadas num servidor (ACL server).
DCE: Serviço de Segurança DCE: Serviço de Segurança

PROTEÇÃO Visão Geral:
Utiliza checksum criptografado como proteção contra servidor de ferramentas de

alteração da informação em trânsito. autenticação chaves administração
criptográficas
obtém tickets
informação (ex: parâmetro RPC) checksum permissões
login RPC ACL

computado por criptografia cliente
(lib) servidor server
obtém
OBS: O DCE não provê mecanismos para permissão
criptografar a informação. recursos
DCE: Sistema de Arquivos DCE: DFS (cliente)
DCE provê um sistema de arquivos distribuído cliente

(DFS: Distributed File System) composto de: chamada de sistema
(open, read, write, …)
• Um subsistema de arquivo local similar ao
do UNIX denominado Episode (acesso chamadas locais chamadas DFS
compativel com o padrão POSIX 1003);
DFS cache
• Um conjunto de servidores para tornar
distribuído o subsistema de arquivos local. RPC para os
subsistema de servidores DFS
arquivo local
DCE: DFS (servidor) DCE: o conceito de CÉLULA
clientes
fileset replication BOS backup
server server server server
servidores DFS
chamadas locais chamadas DFS
File Exporter Token Manager
servidores de
segurança,
subsistema de
Episode arquivo local diretório e time
(+ extensões)
Object Management Group (OMG)
CORBA (Common Object O OMG foi fundado em 1989 por 11 empresas

(dentre elas 3Com, HP, Data General, Unisys,
Request Broker Sun e Philips) como uma empresa sem fins
lucrativos. Hoje possui 800 membros, dentre eles
Architecture) todos os “peso-pesados” das indústrias de
informática e de telecomunicações.

OMG: Missão OMG: Estrutura
O OMG é estruturado em três comitês:

A missão do OMG é prover a indústria com especifi-
cações detalhadas na área de gerência de objetos
distribuídos visando estabelecer uma base comum para 1. Platform Technology Committee (PTC);
o desenvolvimento de aplicações. Estas especificações 2. Domain Technology Committee (DTC);
incluem: uma arquitetura de referência (OMA) e sua
implementação (CORBA); uma linguagem de 3. Architecture Board.
especificação (IDL); protocolos de interoperabilidade
(GIOP, IIOP); aplicações específicas (TMN, IN, etc.).
Cada comitê é subdividido em Task Forces, Special
Interest Groups (SIGs) e Working Groups (WGs).
OMG: Processo de Padronização OMG: Padrões Alternativos

As principais tecnologias que competem com as
Membros do OMG possuem um dos três níveis de padronizadas pelo OMG são:
influência:
• voto no nível de Task Forces (universidades,
• Microsoft DCOM (Distributed Component Object Model).
Problema: uma empresa, uma tecnologia (Windows).
governos, pequenas empresas);
• voto no nível de Platform TC, Domain TC ou • Sun Java (linguagem, APIs, toolkits, frameworks, etc.).
ambos (grandes usuários de tecnologia); Problema: uma linguagem de programação.
• submissão de padrões para adoção nos TCs
(gigantes da informática e telecomunicações). • W3C (WWW Consortium): introdução de objetos na Web
(XML, HTTP, SOAP, etc.).
Problema: soluções centradas na Web.
A Arquitetura OMA OMA: Componentes
OMA (Object Management Architecture) é uma

arquitetura de referência para gerência de OMA possui um componente central, o Object Request Broker
(ORB), e 4 categorias de interfaces:
objetos distribuídos. A arquitetura identifica
componentes, interfaces e protocolos
• Serviços de Objetos (Object Services);
necessários para o desenvolvimento de
• Facilidades Comuns (Common Facilities);
sistemas de software interoperáveis entre os
• Interfaces Específicas do Domínio (Domain Interfaces);
principais sistemas de hardware, sistemas
• Interfaces Específicas da Aplicação (Application Interfaces).
operacionais e linguagens de programação.

OMA: Componentes OMA: Object Request Broker
O Object Request Broker (ORB) é um facilitador de

Application Domain Common comunicação entre objetos distribuídos. Funções típicas
Interfaces Interfaces Facilities desempenhadas pelo ORB:
• transparência de comunicação (localização, conversão de

Object Request Broker (ORB) dados, referência de objetos, etc.);
• gerência da execução de objetos servidores;
• manutenção de repositórios de servidores e suas interfaces;
Object • gerência de tipos específicos de dados (Any, NVList, etc.).
Services
OMA: Serviços de Objetos OMA: Facilidades Comuns
São arquiteturas e interfaces para serviços de propósito

geral tais como: São interfaces (denominadas horizontais) para serviços
orientados para aplicações-fim. Exemplos:
• nomes;
• eventos;
• propriedades; • agentes móveis;
• ciclo de vida; • data interchange;
• transações; • interfaceamento com o usuário;
• persistência;
• gerenciamento da informação;
• externalização/ internalização;
• segurança; • gerenciamento de sistemas;
• coleções. • gerenciamento de tarefas (workflow).
dentre muitos outros ...

OMA: Interfaces Específicas do Domínio OMA: Interfaces de Aplicação
São interfaces (denominadas verticais) para serviços São interfaces para os serviços específicos da
em domínios específicos. Exemplo: aplicação. Estes serviços em geral utilizam os
serviços de objetos, as facilidades comuns ou
• CORBA/TMN and CORBA/SNMP Interworking serviços específicos do domínio.
• CORBA/Intelligent Networks Interworking
• Notification Service Exemplo: uma aplicação de gerência de redes
• Control and Management of A/V Streams pode utilizar o serviço de eventos (serviço de
• Telecom Log Service objetos) e o Telecom Log Service (serviço
• Wireless Access & Control específico do domínio).

A Arquitetura CORBA CORBA: Características
• Estabelece uma arquitetura orientada a objetos;

A Arquitetura CORBA (Common Object Request Broker
Architecture) especifica um ORB para a Arquitetura de • Separa a interface do serviço de sua implementação;
Referência OMA.
• Prevê uma vasta gama se serviços e funcionalidades;
Os demais elementos da OMA, quando implementados
sobre CORBA são denominados CORBAservices • Permite a utilização de múltiplas linguagens de
(serviço de objetos) e CORBAfacilities (facilidades programação (C++, Java, Smalltalk, etc.);
comuns).
• Previsão de vir embutido nos sistemas operacionais e
linguagens de programação (Java 1.2).
CORBA: Arquitetura CORBA: Arquitetura
A Arquitetura CORBA é composta dos seguintes

componentes básicos: cliente servidor
• ORB (Object Request Broker);

IDL
• Compilador IDL (Interface Definition Language); ORB skeleton POA
• SII (Static Invocation Interface); IDL stub DII interface
• DII (Dynamic Invocation Interface);
• BOA/POA (Basic/Portable Object Adaptor); ORB
• Repositórios de Interfaces e de Implementação.
Repositório Repositório de
de Interfaces Implementação
CORBA: Object Request Broker (ORB) CORBA: ORB
É o componente básico de interconexão da

Arquitetura CORBA, sendo responsável pelo cliente (Java) servidor (C++)
encaminhamento de requisições de métodos
para objetos remotos.
Windows NT Solaris
O ORB provê independência de plataforma,

localização e linguagem de implementação dos
objetos comunicantes.
ORB
Usualmente é implementado como um daemon
que executa em todas as máquinas da rede.

CORBA: Interface Definition Language
CORBA: Internet Inter-ORB Protocol (IIOP) (OMG IDL)
Objetivo: Prover interoperabilidade entre ORBs de
diferentes fornecedores. Objetivo: especificar interfaces (métodos e
cliente atributos) de objetos.
OMG IDL não é linguagem de programação;

ORB (IONA)
A especificação CORBA provê mapeamentos de
servidor
IDL para linguagens orientadas e não orientadas
INTERNET
(TCP/IP) IIOP a objetos (C, C++, Java, etc.).
ORB (IBM)
OMG IDL: Compiladores IDL: Estrutura de uma Interface
Módulo
Compiladores IDL traduzem as interfaces IDL em Definições (tipos complexos, exceções)
construções de uma linguagem alvo (Java, C++,
etc.), bem como geram stubs e skeletons para Interface
clientes e servidores que utilizam e disponibilizam a Atributos
interface. Operações
Dependendo da linguagem alvo, compiladores IDL

podem gerar tambem código auxiliar para a Interface
manipulação de tipos e passagem de parâmetros. Atributos
Operações
IDL: Tipos Básicos IDL: Tipos Complexos

Enumerações:
• um conjunto de possíveis valores
Ponto Flutuante: Outros Tipos:
• float (IEEE 32 bits) • boolean: TRUE ou FALSE Exemplo:
• double (IEEE 32 bits) • char: 8 bits (usualmente ASCII) enum moeda {real, dolar, euro, peso};
• octet: 8 bits (opaco) moeda.real, moeda.dolar, moeda.iene
Inteiros: • any: armazena qualquer tipo IDL
• long: -231 ... +231 -1 Estruturas:
• unsigned long: 0 ... +232 -1 • um conjunto de tipos (básicos ou complexos) "empacotados".
• long long: -263 ... +263 -1
• unsigned long long: 0 ... +264 Exemplo:
• short: -215 ... +215 -1 struct cliente {
• unsigned short: 0 ... +216 -1 string nome;
long idade;
Nota: IDL não define inteiros ! };
IDL: Tipos Complexos (cont.) IDL: Tipos Complexos (cont.)
Uniões:
• contruções capazes de armazenar um tipo IDL dentre um
Strings:
conjunto de tipos declarados.
• armazenam uma sequência de caracteres ASCII com tamanho
máximo especificado (bounded) ou não (unbounded).
Exemplo:
enum formato {formatoString, formatoDigital};
Exemplos:
struct DataStruct {
string<30> cliente; // maximo 30 caracteres
short dia;
string cliente; // tamanho ilimitado
short mes;
short ano;
};
union Data switch (formato) {
case formatoString: string dataString;
case formatoDigital: long dataDigital;
default: DataStruct dataStruct;
};
Seqüências:
• armazenam uma seqüência de um mesmo tipo IDL
Arrays:
com tamanho máximo especificado (bounded) ou não
• armazenam um mesmo tipo IDL em uma estrutura multi-
(unbounded).
dimensional.
Exemplos:
Exemplos:
sequence<string, 10> nomes; // máximo 10 elementos
DataStruct vencimentos[16];
sequence<string> nomes;
float Z[50][50];
sequence<DataStruct> vencimentos;
Tipo Fixo: Constantes:

• permite representar um número em duas partes: valor e • permite associar valores a um identificador.
escala (posição do ponto decimal).
Exemplos:
Exemplos: const float pi = 3.1415926535;
fixed<6,2> preco; // (-/+)9999.99 const string palmeiras = "alviverde imponente";
fixed<4,3> taxaDolar; // (-/+)9.999

Tipo Any:
Typedefs: • permite armazenar um valor pertencente a qualquer tipo
• permitem definir nomes para tipos complexos. IDL (simples ou complexo), inclusive outro tipo any.
Exemplos: O mapeamento de IDL para linguagens alvo deve prover

typedef sequence<DataStruct> Datas; mecanismos para:
Datas vencimentos; • inserção de valores em tipos any;
typedef long integer; • extração de valores armazenados em tipos any;
integer dataDigital; • inspeção do tipo armazenado.
Nota: Tipos any são um remédio à imposibilidade de

sobregarregar operações (métodos) em IDL.
IDL: Exceções IDL: Interfaces

Interfaces são comumente definidas no escopo de um módulo
Operações nas interfaces IDL podem lançar exceções. (podem também estar desassociadas de um módulo). Interfaces
Exceções são declaradas em IDL da seguinte forma: são definidas em IDL da seguinte forma:
exception <nome> { interface <nome> {

parâmetros atributos
}; operações
};
Exemplos:
exception operationFailed { Exemplo:
string reason; interface Account {
short errorCode; void deposit (in long amount);
}; void withdraw(in long amount) raises {noFunds, operationFailed};
exception noFunds {}; long balance();
};
IDL: Atributos de Interfaces IDL: Operações
Atributos são variáveis associadas às interfaces (similares a

atributos públicos de classes em OO). Atributos podem ser Operações são definidas no escopo de uma interface IDL da seguinte
"readonly" ou "read-write", sendo definidos em IDL da seguinte forma:
forma:
<tipo> <nome> (<indireção> <tipo> parâmetro, ...) raises {E1, ... En};
<readonly> attribute <nome>;
Exemplos:
Exemplo: void withdraw(in long amount) raises {noFunds, operationFailed};
interface Account { long balance();
readonly attribute string customerName;
readonly attribute sequence<octet> number; Nota: IDL não permite a sobrecarga de operações (mesmo nome com
... diferentes assinaturas) ou operações com número de parâmetros variável.
};
Nota: o compilador IDL gera métodos get e set para operação com atributos.
IDL: Parâmetros de Operações IDL: Retorno de Operações
Parâmetros de operações podem assumir qualquer tipo (básico

ou complexo). A indireção do parâmetro é obrigatória e possui
três modos: Operações podem retornar o tipo void ou qualquer tipo IDL (básico
• in: o parâmetro é de entrada, isto é, passado do cliente para o ou complexo). Operações em CORBA são sempre síncronas
servidor. Seu valor permanece inalterado após o retorno da (mesmo retornando void).
operação.
• out: o parâmetro é de saída, isto é, passado do servidor para o Operações assíncronas podem ser definidas com a palavra-chave
cliente. Seu valor comumente se altera após o retorno da oneway. Neste caso, devem retornar void e não definir exceções.
operação. Exemplo:
• inout: o parâmetro é de entrada/saída, isto é, passado nos dois
sentidos. Seu valor comumente se altera após o retorno da oneway void deposit();
operação.
Nota: parâmetros com valor NULL são proibidos !

IDL: Interfaces e Tipos Complexos IDL: Definições Postergadas
Ao declarar uma interface em IDL, está-se declarando É comum referenciar uma interface antes da mesma ser definida. IDL
também um novo tipo complexo. Este tipo pode ser utilizado permite postergar a definição de interface declarando-se apenas o
em parâmetros e retornos de operações. Exemplo: seu nome. Exemplo:
interface Account { interface A;

...
}; interface B {
void op1 (in A p1, ...);
interface AccountFactory { ...
Account makeAccount(in string customerName, };
in sequence<octet> accountNumber);
}; interface A {
void op2 (in B p1, ...);
Nota: makeAccount retorna uma referência para um objeto ...
distribuído que implementa a interface Account. };
IDL: Herança de Interfaces Mapeamento IDL-Java
IDL permite herança simples e múltipla de interfaces. IDL Java

module package
interface D : A,B,C { boolean boolean
... char char
}; octet byte
string java.lang.String
Exemplo: short, unsigned short short
long, unsigned long int
interface SavingAccount : Account {
long long, unsigned long long long
readonly attribute float interestRate;
float float
float computeInterest();
double double
};
fixed java.math.BigDecimal

Mapeamento IDL-Java Parâmetros out e inout em Java
IDL Java Em linguagens que suportam ponteiros (como C++), parâmetros

enum, struct, union class out e inout são passados por referência quando mapeados para a
sequence, array array linguagem alvo. Em Java, todo parâmetro possui uma classe
interface interface, helper & holder classes Holder associada. O pacote org.omg.CORBA define as classes
constant (fora de uma interface) public interface holder para os tipos básicos, enquanto o compilador IDL gera as
constant (em uma interface) fields na interface Java classes holder para os tipos complexos. Portanto:
exception class • para um tipo qualquer X existe a classe XHolder;
any org.omg.CORBA.Any • a classes XHolder possui um atributo público do tipo X
typedef helper classes denominado value;
readonly attribute accessor method • este atributo contém o valor a ser passado para o servidor (inout),
readwrite attribute accessor and modifer methods bem como tem o seu valor alterado no retorno da operação.
operação método
Parâmetros out e inout em Java (cont.) Classes Helper
Tal como classes holder, cada tipo IDL X possui uma classe
Exemplo:
XHelper associada quando mapeado para Java. Classes helper
// IDL // Java oferecem três funcionalidades (via métodos estáticos):
interface Account { intHolder amt = new IntHolder(); • inserção do tipo em um tipo any:
... amt.value = 10000; void insert(org.omg.CORBA.Any a, X that);
void withdraw(inout long amount); acc.withdraw(amt);
}; System.out.println("Amount: " + • extração do tipo armazenado em um tipo any:
amt.value); X extract(org.omg.CORBA.Any a);
// Java
public interface AccountOperations {
...
• criação de stubs a partir da referência do objeto remoto:
void withdraw(intHolder amount); X narrow(org.omg.CORBA.Object obj);
};
Mapeamento IDL-Java: Exemplo Exemplo: Account.idl
Account.idl
interface Account {
Compilador IDL exception LimitExceeded{string reason;};
void deposit(
in long long arg0 );
Interface class class void withdraw(
AccountOperations AccountHolder _AccountStub in long long arg0 ) raises (LimitExceeded);
long long balance( );
Interface class class
Account AccountHelper AccountPOA };

Exemplo: AccountOpeations.java Exemplo: Account.java
public interface AccountOperations

{ public interface Account extends AccountOperations,
void deposit (long arg0); org.omg.CORBA.Object,
void withdraw (long arg0) throws AccountPackage.LimitExceeded; org.omg.CORBA.portable.IDLEntity
long balance (); {
} // interface AccountOperations }
Exemplo: AccountHolder.java Exemplo: AccountHelper.java
public final class AccountHolder implements abstract public class AccountHelper

org.omg.CORBA.portable.Streamable {
private static String _id = "IDL:Account:1.0"
{
public Account value = null; public static void insert (org.omg.CORBA.Any a, Account that)
{ ... }
public AccountHolder ()
{} public static Account extract (org.omg.CORBA.Any a)
{ ... }
public AccountHolder (Account initialValue)
{ public static Account narrow (org.omg.CORBA.Object obj)
value = initialValue; { .... }
}
public static String id ()
... { return _id;}
} }
Exemplo LimitExceeded.java IDL: Passagem de Objetos por Valor
package AccountPackage;
CORBA, por ser um padrão neutro, não suporta passagem de
public final class LimitExceeded extends org.omg.CORBA.UserException objetos nas invocações de métodos remotos. Recentemente, o
{
OMG introduziu o padrão denominado "Objeto por Valor"
public String reason = null;
(Object by Value - OBV).
public LimitExceeded ()
{ OBV permite:
super(LimitExceededHelper.id()); • definir um objeto em IDL (estado + métodos);
} // ctor • utilizar este objeto como parâmetro ou retorno de invocações,
passando-o por valor.
public LimitExceeded (String _reason)
{
super(LimitExceededHelper.id());
reason = _reason;
} // ctor
IDL: OBV IDL: OBV (cont.)
Mas: valuetype classes

• e se o cliente e servidor forem escritos em diferentes Helper,
linguagens de programação (que eventualmente não Holder
suportam o conceito de objeto, como C, Fortran, etc.) ? estado
métodos
• como objetos são serializados / de-serializados ?
construtor
Objeto
Resposta: Compilador IDL Java
O padrão OBV permite apenas transferir o estado do
objeto (similar a uma IDL struct) em uma invocação.
Os métodos devem ser implementados localmente,
tanto no lado cliente quanto no lado servidor, em suas Value Default Implementação
respectivas linguagens de programação. Factory Factory do Objeto
IDL: Valuetypes IDL: Uso de Valuetypes
// "objeto" a ser passado por valor

valuetype Empregado {
// definicao do estado // interface que utiliza o "objeto"

public string nome; interface RH
public string cargo; Empregado obtemEmpregado(in string nome);
public float idade; void adicionaEmpregado(in Empregado emp);
public long salario; void removeEmpregado(in Empregado emp);
};
// metodos - pode haver varios
long computaSalario();
// construtor
factory init(in string n, in string c, in float i);
};
IDL: Implementação de Valuetypes IDL: Implementação de Valuetypes (cont.)
import org.omg.CORBA.*; // construtor vazio tambem é necessario

public EmpregadoImpl()
public class EmpregadoImpl extends Empregado { {
this.nome = new String("");
// construtores this.cargo = new String("");
// conforme definido na IDL (facory init) this.idade = 0;
public EmpregadoImpl(String n, String c, float i) this.salario = 0;
{ }
this.nome = new String(n);
this.cargo = new String(c); public int computaSalario () {
this.idade = i; if(cargo.equals("gerente")) return(8000);
this.salario = computaSalario(); // <<< operacao local return(3000);
} }
}
IDL: Valuetypes - lado cliente IDL: Valutypes - lado servidor
import org.omg.CORBA.*;
// creia fabrica de Empregados (local) import java.util.*;
EmpregadoDefaultFactory fact = new EmpregadoDefaultFactory();
Empregado e = fact.init("Jose", "gerente", (float)43.0); public class RHServant extends RHPOA
implements RHOperations {
rh.adicionaEmpregado(e);
EmpregadoDefaultFactory the_factory = null;
Empregado e1 = rh.obtemEmpregado("Joao"); Hashtable empregados = null;
System.out.println("Empregado obtido: " + e1.nome + float massaSalarial = 0;
" - cargo: " + e1.cargo + " - idade: " + e1.idade);
public RHServant() {
// cria fabrica e hashtable
System.out.println("O salario de " + e1.nome + " e' " +
e1.computaSalario()); // <<< chamada local !! the_factory = new EmpregadoDefaultFactory();
empregados = new Hashtable();
}
IDL: Valutypes - lado servidor (cont.) CORBA: Basic Object Adapter (BOA)
public Empregado obtemEmpregado (String nome) {

Empregado e = (Empregado)empregados.get(nome);
Objetivo: instanciar (criar) servidores e controlar a
if(e == null) e = the_factory.init("", "", (float)0.0); execução de métodos.
return e;
}
O BOA identifica o código dos objetos servidores
public void adicionaEmpregado (Empregado emp) { interagindo com o Repositório de Implementação.
Empregado e = the_factory.init(emp.nome, emp.cargo, emp.idade);
massaSalarial += emp.computaSalario(); // <<< chamada local !
empregados.put(emp.nome, e);
Usualmente, o BOA provê três tipos de instanciação
} de servidores:
• compartilhada;
public void removeEmpregado (Empregado emp) {
if(empregados.remove(emp.nome) != null)
• não compartilhada;
massaSalarial -= emp.computaSalario(); // <<< chamada local ! • por método.
}
} (c) FEEC/UNICAMP 201 (c) FEEC/UNICAMP 202
CORBA: BOA CORBA: BOA
compartilhada não compartilhada por método A tendência é utilizar a instanciação por processo
e servidores multitheaded (para cada evocação
o servidor cria uma thread para processá-la).
M1 M1 M1 M1
M2 O BOA implementa também funções elementares
de segurança (Ex: verificação se um cliente possui
M3 M2 M2 M2 permissão para instanciar um servidor) via atributos
do sistema de arquivos.
método processo M3 M3 Pode-se implementar diferentes adaptadores de

objetos em prejuizo da portabilidade.

Adaptador de Objeto Portável (POA) POA: Stubs e Skeletons Portáveis
cliente servant
POA (Portable Object Adapter) é uma parte importante da value = gridRef.get(x,y) result = get(n, m)
arquitetura CORBA que trata do controle dos objetos que
implementam interfaces remotas (objetos servants). POA result = get(n, m)
vem eliminar muitas das deficiências do BOA (Basic Object
out skeleton in
Adapter), principalmente sua dependência de implemen-
tação. stub
in out
invoke
POA permite esquemas flexíveis de controle através da

combinação de políticas de controle do POA com diferentes in = invoke(out) out = invoke(”get”,in)
modos de ativação de objetos servants. get n m
invoke IIOP
result
ORB ORB
POA: Arquitetura POA: Arquitetura

Servidor CORBA
POA Manager
POA Raiz Servant Manager

POA Raiz é obtido através do método (default)
Servant Manager
resolve_initial_references("RootPOA")
disponibilizado pelo ORB.
(implementações)
Object ID código
Políticas
Definidas pelo suprido pelo

POA P1
Servants
POA P2 Um POA é sempre criado a partir de um
desenvolvedor Object ID desenvolvedor
Object ID
POA pai (exceto o Root POA) através
do método create_POA invocado no Object ID
POA pai.
Mapa de
POA P3 Objetos Ativos
POA: Operação Típica POA: Políticas

POA define 7 políticas:
1. Atribuição de OIDs: USER_ID; SYSTEM_ID (default)

POA servant
2. Retenção de Servants: RETAIN (servants são retidos no mapa
mapa objs.
ativos upcall M(...) de objetos ativos); NON_RETAIN (não existe mapa de objetos
ativos).
_invoke(M, ...)
skeleton
3. Processamento de Requisição:
USE_ACTIVE_OBJECT_MAP_ONLY (default);
USE_DEFAULT_SERVANT; USE_SERVANT_MANAGER.
OID parâmetros
4. Ativação Implícita: IMPLICIT_ACTIVATION (default) - atribui um
OID e o adiciona no mapa de objetos ativos quando necessário
_invoke (não ativa o servant !); NO_IMPLICIT_ACTIVATION.
POA: Políticas (cont.) POA: Políticas (cont.)
7. Política de Thread: ORB_CTRL_THREAD (default) - o

5. Unicidade de OIDs: UNIQUE_ID (default) - cada servant possui
POA mantém um pool de threads para atender as
um único ID; MULTIPLE_ID - um servant pode possui mais de
requisições; SINGLE_THREAD_MODEL - o pool possui
um ID.
apenas 1 thread; MAIN_THREAD_MODEL - não há
threads, exceto a thread "main".
6. Tempo de Vida: TRANSIENT (default) - referências atribuidas
por um POA se tornam inválidas quando o POA que as atribuiu
é desativado; PERSISTENT - referências sobrevivem à
desativação do POA (neste caso, a referência de objeto (IOR)
que abriga o OID deve "apontar" para o daemon de ativação do POA POA POA
ORB e não para o POA que a criou).
ORB ORB ORB

POA: Gerenciador de Servants POA: Gerenciador de POA
Existem dois tipos de gerenciador de servants (servant manager)

cuja utilização pelo POA se dá através da política
USE_SERVANT_MANAGER: O Gerenciador de POA (POA Manager) disponibiliza um conjunto
de métodos que permite colocar o POA um um dos quatro
• Ativador de Servants (Servant Activator): utilizado em conjunto com estados abaixo:
a política RETAIN, disponibiliza ao POA um método que retorna um
servant ativado dado um OID. O POA invoca esta operação quando • espera: suspende temporariamente o processamento das
o OID não está presente no mapa de objetos ativos; requisições, enfileirando-as;
• ativo: processa normalmente as requisições;
• Localizador de Servants (Servant Locator): utilizado em conjunto • descarte: descarta requisições;
com a política NON_RETAIN, disponibiliza ao POA um método que • inativo: estado pré-destruição (completa processamento das
retorna um servant ativado dado um OID. O POA invoca esta requisições pendentes e descarta novas requisições).
operação para cada requisição que recebe do ORB.
POA: Indentificadores de Objeto (OID) CORBA: Static Invocation Interface (SII)
OIDs podem ser atribuidos pelo POA (mais comum) ou

pela aplicação. OIDs é uma sequência de bytes presente SII é a forma mais simples do cliente invocar
no IOR que identifica o servant. IORs são criados pelo um método num servidor.
POA via métodos create_reference (POA atribui OID) ou
create_reference_with_id (aplicação atribui OID). SII requer que todas as interfaces de servidores
sejam conhecidas em tempo de compilação
Quando atribuído pela aplicação, em geral o OID é uma
chave de acesso para o estado do servant armazenado em (portanto, SII é type-safe).
uma base de dados. Isto permite a criação de servidores
persistentes.

CORBA: SII CORBA: Dynamic Invocation Interface (DII)
DII é um conjunto de serviços que permitem a clientes:

cliente servidor
• Verificar a existência de interfaces no Repositório de
Interfaces;
proxy
• Descobrir os parâmetros (tipos) e métodos (protótipos)
de determinada interface;
IDL stub
IDL skeleton POA
• Preparar passo-a-passo uma evocação para um
servidor que implementa esta interface.
ORB
CORBA: Repositórios de Interfaces e

CORBA: DSI Implementação
DSI (Dynamic Skeleton Interface) é equivalente Objetivo: armazenar de forma persistente as

ao DII para o lado servidor. DSI permite a um interfaces IDL e as implementações de servidores.
servidor inspecionar uma invocação antes de
seu processamento, obtendo o nome do método Estes repositórios podem ser implementados
e respectivos parâmetros. DSI permite também diretamente no sistema de arquivo nativo do
ao servidor retornar um valor para o cliente. sistema operacional ou através de uma base de
dados (relacional ou OO).
Nota: O uso de DII no lado cliente não implica
no uso de DSI no lado servidor e vice-versa. As implementações CORBA provêem aplicativos
para a manutenção destes repositórios.
CORBA: CORBAservices CORBAservices: Nomes
CORBAservices define arquiteturas e interfaces (não

O serviço de nomes especifica interfaces IDL para:
implementações !) para os seguintes serviços: • criar contextos para definições de nomes;
• associar (bind) um nome a um objeto (usualmente um servant);
• nomes (diretório); • pesquisar um nome (e obter o objeto associado);
• eventos; • navegar pelo diretório de nomes.
• ciclo de vida;
• segurança; interfaces IDL
• transações; do serviço
• time; servant
• persistência; CORBA
diretório de nomes
servidor de nomes (persistente ou transiente)
dentre muitos outros !
CORBAServices: Ciclo de Vida CORBAServices: Propriedades
O serviço de propriedades proporciona operações que O serviço de propriedades proporciona operações que
permitem criar, destruir, copiar objetos. permitem definir pares atributo-valor (propriedades) e
associa-los a qualquer entidade da aplicação.
find_factories servant
CORBA
create_propertyset
FactoryFinder create_initial_propertyset servant
encontra
create_constrained_propertyset CORBA
servant CORBA.Object obj =

PropertySetFactory
create_object CORBA GenericFactory.CreateObject(pars);
GenericFactory define_property
cria
get_property servant
copy delete_property CORBA
servant
move
CORBA ......
remove PropertySet
servidor de propriedades
LifeCycleObject
CORBAServices: Eventos CORBAServices: Object Transaction Service

O serviço de eventos prove um mecanismo de notificação OTS (Object Transaction Service) implementa um
segundo os modelos push e pull. serviço de transações aberto baseado no protocolo
2-phase commit.
obtain_push_consumer
obtain_push_supplier
connect_push_consumer
connect_push_supplier
interfaces IDL
disconnect_push_supplier do serviço
push
- begin
push - commit
evento - abort, ... servant base de dados
CORBA interface XA (Oracle, Sybase, etc.)
(X/Open)
push supplier servidor OTS
canal de eventos
push consumers permite a integração com
produtos que implementam
servidor de eventos esta interface
CORBAservices: Trader CORBA: Produtos
Trader, conceito introduzido no modelo ODP, foi padronizado pelo • ORBIX (IONA Technologies Ltd.)
OMG. Trader é um serviço de nomes mais sofisticado que permite • VisiBroker (Borland)
clientes encontrar servidores que melhor atendam suas necessidades.
Cenário típico de utilização do trader é dado abaixo. • ORBacus (Object Oriented Concepts / IONA)
• CORBAplus (Expersoft)
cliente
Trader
servidor • Nouveau (Rogue Wave)
CORBA CORBA
• vários outros ...
4 2 3 1
ORB Implementações robustas de domínio público:

Java IDL (parte da plataforma Java 2), MICO
1. exporta capacidades do servidor (desempenho, custo, etc.)
(C++), JacORB (Java), TAO (C++).
2. importa requisitos (desempenho mínimo, custo máximo, etc.)
3. retorna IOR do servidor
4. interage com o servidor (provavelmente via DII)

CORBA: Produtos CORBA: Produtos
Muitos produtos em diferentes domínios possuem

implementações CORBA embutidas para fins de Produtos CORBA tradicionais como ORBIX e
interoperabilidade com outros produtos compatível VisiBroker foram incorporados em Plataformas de
com CORBA. Exemplos: Desenvolvimento (Application Server Platforms).
Estas plataformas, além de permitirem
• Plataforma Jambala (Ericsson): utilizada em desenvolvimento em CORBA, suportam ainda
telefonia celular; desenvolvimento em J2EE/EJB, .NET, XML/SOAP,
• OpenView (HP): produto para gerência de redes e etc., bem como alguma interoperabilidade entre
TMN; estas tecnologias.
• Jaguar (Sybase): middleware para OLTP.
ORBIX ORBIX: Disponibilidade
Orbix possui versões para desenvolvimento em

C, C++, Java, COBOL, PL/1, VB para as
Orbix, da Iona Technologies, é uma família de seguintes plataformas:
produtos CORBA. Orbix possui compiladores IDL
para várias linguagens de programação, bem • Microsoft Windows NT/2000/XP;
como ORBs para uma grande variedade de • Sun Solaris;
• Linux;
plataformas. Por exemplo, é possível desenvolver • HP-UX
um servidor CORBA em COBOL e executá-lo em • Silicon Graphics IRIX;
mainframe IBM OS/390. • IBM AIX;
• IBM OS/390 Mainframe;
• Digital/Compaq OpenVMS.
ORBIX: Compilador IDL ORBIX: ORB
stubs, skeletons,
compilador IDL server template
No Orbix o Object Request Broker (ORB) consiste de dois
componentes:
parser gerador
IDL de código
árvore de
1. Uma interface de programação (API) que provê funções
arquivo IDL parsing relativas ao ORB para clientes e servidores tais como binding,
DII (cliente); iniciação de servidores, DSI (servidor);
2. Um daemon (orbixd) que executa em cada máquina da rede

utilitários e gerencia o repositório de implementação e ativação de
Code Generation Toolkit
servidores.
aplicação-exemplo
conversão IDL - HTML
etc.

ORBIX: ORB ORBIX: ORB
busca de servidor
ORBIX daemon
(orbixd) Rep. Orbix ORB possui as seguintes características básicas:
Impl.
instancia servidor • suporte para DII (Dynamic Invocation Interface);
• suporte para BOA e POA (Basic/Portable Object Adapter);
código da aplicação (cliente) código da aplicação (servidor) • suporte para DSI (Dynamic Skeleton Interface).
API API
Orbix ORB provê ainda uma interface para operações de
manipulação de typos (Any, NVList, ...), disponibilização de
código do stub código do skeleton
(gerado pelo ORB ORB (gerado pelo
servidores, busca de serviços disponíveis (nomes, eventos,
compilador IDL) (lib) requisição IIOP (lib) compilador IDL) ...), dentre muitas outras.
ORBIX: Repositórios ORBIX: Integração com MS-COM

ORBIX permite que servidores CORBA se apresentem a clientes
Orbix dispõe de repositórios de interface e de
como objetos COM (Component Object Model - padrão Microsoft).
implementação com a seguinte arquitetura:
cliente COM COM Bridge IIOP servidor

CORBA
repositório
registros putit
catit
utilitários de lstit
manutenção rmit provê mapeamento
e gerência bidirecional entre repositório repositório
...
MIDL e OMG IDL de tipos de interfaces
sistema de arquivos
(COM) (CORBA)
nativo da máquina
OBS: MIDL (Microsoft IDL) define tipos COM
ORBIX: Serviços CORBA VisiBroker
Orbix implementa os seguintes serviços CORBA:

VisiBroker tem sua origem no ORBeline, produto da
• serviço de nomes; PostModern que em 1996 fundiu-se com a Visigenic,
• serviço de transações; mudando o nome do produto para VisiBroker.
• serviço de trading; A Visigenic foi adquirida pela Borland que manteve o
• serviço de eventos; nome do produto, hoje na versão 4.
• serviço de notificação.
VisiBroker foi o primeiro ORB a ter uma versão total-
mente escrita em Java.
Atualmente, VisiBroker está incorporado no produto

Borland Enterprise Server.

VisiBroker: Disponibilidade VisiBroker: Características
VisiBroker possui versões para desenvolvimento em VisiBroker possui as seguintes características básicas:
C++ e Java para as seguintes plataformas:
• repositórios de interface e implementação;
• Microsoft Windows ; • suporte para DII (Dynamic Invocation Interface);
• Sun Solaris; • suporte para BOA e POA (Basic/Portable Object Adapter);
• Linux; • suporte para DSI (Dynamic Skeleton Interface);
• HP-UX; • suporte a multithreading (vários modelos de threading);
• IBM AIX; • suporte a Object-by-Value (OBV);
• Digital/Compaq UNIX; • Filtros (Interceptors).
• Silicon Graphics IRIX;
• IBM OS/390 Mainframe.
VisiBroker X Orbix VisiBroker: SmartAgent & OAD
VisiBroker é muito similar ao Orbix, sendo talvez o seu maior

concorrente. Algumas diferenças:
Serviço Distribuído de Nomes + Diretório
• possui dois daemons: SmartAgent e OAD (Object Activation SmartAgent SmartAgent

Daemon): SmartAgent
Algoritmos de
– SmartAgent: provê serviços de nome e diretório que 1. consulta Bal. de carga
Tol. a Falhas
permite localizar OADs. A localização pode levar em 2. encontra servidor
conta balanceamento de carga e tolerância a falhas; 3. retorna ref. OAD

– OAD: utilizado para instanciar servidores (similar ao
6. inst. servidor
orbixd). cliente OAD OAD
4. bind
5. acessa impl.
• serviço de nomes e eventos (OMG) incorporados.
Rep. Impl. Rep. Impl.
VisiBroker: Componentes Adicionais Java IDL
A Imprise oferece os seguintes componentes adicionais para o

VisiBroker: A plataforma Java dispõe de uma implementação CORBA
denominada Java IDL. Esta implementação, compatível com a
• VisiSecure: serviço de segurança do OMG; versão CORBA 2.3, vem sendo aprimorada desde a sua
• VisiTransact: serviço de transação do OMG; introdução na versão 1.2 e dispõe atualmente de:
• VisiNotify: serviço de notoficação do OMG.
• um compilador idl (idlj);
• adicionalmente, os seguintes CORBAservices são oferecidos • um conjunto de pacotes (org.omg.CORBA, ...);
pela Prism Technologies para o VisiBroker: Trading, Notification, • um daemon de ativação / servidor de nomes (orbd);
LifeCycle, Property, Collection, Concurrency, Relationship, e • um aplicativo para registro de servidores no repositório de
Time Services. implementação (servertool).

Java IDL CORBA x DCE
Java IDL suporta: A favor do DCE:
• Adaptador de Objeto Portável (POA); • Os padrão DCE está estacionado, enquanto

• servidores persistentes; CORBA está em constante evolução;
• passagem de objeto por valor (Object by Value);
• Intercerceptadores Portáveis (suporte parcial).
• Implementações DCE interoperam por princípio;
• DCE trata segurança em todos os níveis;
Java IDL não suporta: • DCE IDL suporta ponteiros e parâmetros de
tamanho arbitrário (pipes);
• segurança (IIOP/SSL, por exemplo); • DCE suporta o conceito de versão (de servidores).
• repositório de interfaces;
• passagem de contexto nas invocações (Current);
• outros serviços CORBA.
CORBA x DCE Desenvolvimento em CORBA
A favor do CORBA:
Onde utilizar CORBA ?
• CORBA é orientado a objeto (enquanto DCE é
orientado a procedimento); CORBA é uma arquitetura para sistemas distribuídos,
• OMG IDL permite herança e tipo any, além de mapear tipicamente utilizada em:
para várias linguagens de programação;
• CORBA permite late-binding via DII;
• novos desenvolvimentos;
• CORBA especifica uma vasta gama de serviços • integração de produtos e sistemas “legados”;
(poucos destes disponíveis atualmente !); • hooks e gateways de interoperabilidade.
• CORBA define repositórios de interfaces e implemenação;
• CORBA vem despertando mais interesse que o DCE.
Novos Desenvolvimentos em CORBA Integração via CORBA
A utilização de CORBA em novos desenvolvimentos se justifica CORBA é uma tecnologia adequada para a integração de
devido a: sistemas “legados” (exemplo: controle de estoques desen-
volvido em COBOL para IBM OS/390 utilizando DB2).
• ampla aceitação por parte da indústria;
• maturidade dos produtos CORBA disponíveis no mercado; Nestes casos, a interação com o sistema legado pode se dar
• neutralidade em termos de plataformas e linguagens de através de um wrapper dividido em duas partes:
programação; 1. parte responsável pela interação com um ORB, por exemplo,
• simplicidade de uso quando comparado a outras tecnologias através de stub gerado por compilador IDL;
(ex: DCOM e DCE); 2. parte responsável pela interação com o sistema legado
• integração natural com tecnologias relacionadas à Internet através de, por exemplo, interfaces de programação (APIs).
(applets, browsers, etc.).

Integração via CORBA Hooks CORBA de Interoperabilidade
Exemplo: Produto Hook CORBA de

Interoperabilidade IDL “exportada” Extensão
pelo produto ao Produto
Sistema Legado #1 Sistema Legado #2 Sistema Legado #3
(COBOL / OS/390) (C++ / UNIX) (V.Basic / Windows) IIOP
ORB interno
ORB Comercial
ao produto
wrapper #1 wrapper #2 wrapper #3
IDL > COBOL IDL > C++ COM-CORBA bridge
Hooks CORBA de interoperabilidade permitem adicionar

funcionalidades externas a produtos. Exemplos:
IIOP IIOP
ORB #1 ORB #2 ORB #3 • Plataforma Jambala para telefonia celular (Ericsson)
• Sistema de gerência de redes OpenView (HP)
Gateways de Interoperabilidade Microsoft DCOM

Gateways permitem sistemas baseados em CORBA DCOM (Distributed Component Object Model) é uma
interoperarem com sistemas baseados em outras generalização da tecnologia COM (ex-OLE) desenvolvida
arquiteturas e protocolos. Exemplo: pela Microsoft para o “mundo Windows”. Portanto,
OLE/COM/DCOM são soluções “fechadas”.
SNMP Gateway
Gerente COM permite a comunicação entre aplicativos executando
IDL - SNMP
CORBA no mesmo processador. Portanto, COM é um mecanismo
Agente
SNMP de comunicação inter-processos (IPC).
IIOP
ORB ORB Comercial DCOM estende COM permitindo a comunicação entre
IDL “exportada”
aplicativos executando em diferentes processadores.
Domínio de
Gerência pelo gateway Domínio de Portanto, DCOM é um middleware.
SNMP Gerência
CORBA
Atualmente, DCOM está integrado nas plataformas COM+ e
.NET.
Microsoft DCOM Microsoft DCOM
COM é neutro em termos de linguagem de programação. Por

servidor DCOM
exemplo, um cliente escrito em Visual Basic pode interagir com
servidor COM
um servidor escrito em C++. Para permitir esta neutralidade uma
linguagem de definição de interfaces foi definida pela Microsoft:
MIDL (Microsoft Interface Definition Language).
IPC
RPC rede
DCOM procura minimizar as diferenças em relação ao COM
cliente COM (transparência de distribuição), escondendo do desenvolvedor o
fato de clientes e servidores estarem em processadores distintos.
cliente DCOM
cliente e servidor em diferentes
(processos) mas no mesmo processador DCOM utiliza um mecanismo de RPC (derivado do DCE !) para
suporte à comunicação cliente/servidor.
cliente e servidor em
diferentes processadores

DCOM: Arquitetura DCOM: Objetos COM/DCOM
Objetos COM/DCOM derivam de uma

cliente DCOM proxy servidor DCOM stub classe classe base (coclass), definem uma
(coclass) interface com detrminado número de
cria instância instancia métodos, e podem ser agregados numa
(de servidor) interface biblioteca (lib).
SCM segurança DCE RPC SCM segurança DCE RPC classe O objeto, sua interface e a lib a qual
(coclass) pertence são individidual- e globalmente
protocolos de rede (TCP/IP) protocolos de rede (TCP/IP) identificados por um UUID (ou GUID)
interface (Universally/Globally Unique IDentifier),
uma sequência de 128 bits gerada por
hardware hardware
um aplicativo denominado guidgen.
classe
(coclass) guidgen leva em conta a data, hora,
SCM: Service Control Manager rede host ID, etc. para gerar um GUID.
(parte do Windows)
lib interface
DCOM: MIDL DCOM: Desenvolvimento

import "oaidl.idl";
import "ocidl.idl";
Desenvolver aplicações distribuídas em DCOM exige:
[object, uuid(3C6E0346-479C-11D4-96B9-0090272BDBDA), dual
helpstring("IAccountComObject Interface"), pointer_default(unique)]
interface IAccountComObject : IDispatch {
• experiência com o “mundo Windows”, principalmente com a
HRESULT deposit([in] unsigned long amount); tecnologia COM/COM+;
HRESULT withdraw([in] unsigned long amount);
HRESULT balance([out, retval] long *amount);};
• um ambiente de desenvolvimento que contenha gerador de
[uuid(3C6E0339-479C-11D4-96B9-0090272BDBDA), version(1.0), GUID (guidgen), compilador MIDL (midl), compilador da
helpstring("Account 1.0 Type Library")]
library ACCOUNTLib { linguagem alvo, etc. Os ambientes Microsoft Visual C++, Basic
importlib("stdole32.tlb"); e J++ contém estes aplicativos.
importlib("stdole2.tlb");
[uuid(3C6E0347-479C-11D4-96B9-0090272BDBDA), helpstring("AccountComObject Class")] Nos ambientes Microsoft, clientes e servidores COM/DCOM são
coclass AccountComObject {
[default] interface IAccountComObject; }; desenvolvidos a partir de um wizard (ATL COM AppWizard).
};
DCOM: Servidores CORBA x DCOM

A favor do CORBA:
Servidores DCOM podem ser instanciados de duas maneiras:
• CORBA é uma arquitetura aberta, independente de plataforma
• por demanda, quando uma requisição para um objeto for ou fornecedor;
gerada por um cliente; • CORBA é mais aceito por fornecedores de software;
• de forma persistente, como um serviço do sistema operacional • desenvolvimento em CORBA é mais simples que em DCOM;
(Windows-NT apenas); • CORBA se integra melhor com Java/Internet que DCOM;
• CORBA é um middleware mais completo que DCOM;
NOTA: o Register do Windows é empregado para mapear classes de objetos e
suas interfaces (através de seus GUIDs) em servidores (programas executáveis). • CORBA permite late-binding via DII;
Funciona, portanto, como o repositório de implementação do CORBA. • mercado de produtos CORBA bem superior ao mercado de
produtos DCOM;
NOTA: o SCM do Windows funciona para o DCOM como os daemons de • CORBA também opera em ambientes Windows.
ativação do CORBA (orbixd, OAD).

CORBA x DCOM
A favor do DCOM:
• força de mercado da Microsoft;

• perfeitamente integrado ao “mundo Windows”;
• estende COM, uma tecnologia bem conhecida pelos
desenvolvedores para Windows;
• integrado aos ambientes de desenvolvimento Microsoft
(Visual xxx);
• utiliza elementos já disponíveis no Windows (Register,
SCM, segurança, etc.).
(c) FEEC/UNICAMP 265

Jrmi

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Jrmi

Uploaded by

Copyright:

Available Formats

PLATAFORMAS DISTRIBUÍDAS

(c) FEEC/UNICAMP 1 (c) FEEC/UNICAMP 2

Sistemas Distribuídos: Definição Sistemas Distribuídos: Motivação

Um sistema distribuído é um sistema computacional

(c) FEEC/UNICAMP 3 (c) FEEC/UNICAMP 4

Evolução em Microprocessadores Evolução em Redes

• liberdade de escolha (fornecedores, produtos, etc.);

$$$ • confiabilidade (múltiplos pontos de falha);

• processamento espacial da informação;

• aumento incremental da capacidade de processamento;

$$$ • atualização tecnológica constante.

(c) FEEC/UNICAMP 7 (c) FEEC/UNICAMP 8

Internet Sistemas Abertos

Sistemas Abertos são sistemas implementados

Padrão aberto: documento estabelecido por

NOTA: esta definição exclui muitos padrões de-facto tais como

(c) FEEC/UNICAMP 9 (c) FEEC/UNICAMP 10

Sistemas Abertos: Uma Classificação Modelos de Referência

Um modelo de referência é uma descrição de todos

Uma arquitetura de referência é similar a um modelo

(c) FEEC/UNICAMP 13 (c) FEEC/UNICAMP 14

Implementações de Referência Exemplo de Padrão Aberto: CORBA

(c) FEEC/UNICAMP 15 (c) FEEC/UNICAMP 16

Sistemas Abertos: Conclusão

(c) FEEC/UNICAMP 17 (c) FEEC/UNICAMP 18

(c) FEEC/UNICAMP 19 (c) FEEC/UNICAMP 20

Conceito de Middleware e o Modelo OSI Conceito de Middleware e o Modelo OSI

Conceito de Middleware e o Modelo OSI Conceito de Middleware e o Modelo OSI

Domínio da aplicação Domínio da aplicação

APLICAÇÃO Contexto da APLICAÇÃO

APRESENTAÇÃO Aplicação APRESENTAÇÃO

(c) FEEC/UNICAMP 23 (c) FEEC/UNICAMP 24

Evolução do Conceito de Middleware

tarefa 1 receive(M2) tarefa 2 receive(M1)

... Placas de Rede

Token-ring Ethernet ISDN

(c) FEEC/UNICAMP 27 (c) FEEC/UNICAMP 28

Evolução do Conceito de Middleware

2- Call (…) 1- Register (…) 3- Call (…)

Remote Procedure Call (RPC)

cliente servidor cliente servidor

P2 executa empacota desempacota desempacota empacota

(c) FEEC/UNICAMP 31 (c) FEEC/UNICAMP 32

Evolução do Conceito de Middleware

implementação: código dos métodos

Objetos: Regras de Interação Objetos: Conceitos Básicos

(c) FEEC/UNICAMP 35 (c) FEEC/UNICAMP 36

Encapsulamento: objetos “escondem” detalhes de sua encapsulamento instanciação herança (especialização)

(c) FEEC/UNICAMP 37 (c) FEEC/UNICAMP 38

Objetos Distribuídos Objetos Distribuídos: Vantagens

(c) FEEC/UNICAMP 39 (c) FEEC/UNICAMP 40

Objetos Distribuídos: Interação Interfaces Remotas

Implementação RMI utiliza as próprias instâncias das classes Java que

servant OBS: Uma referência pode ser persistente ou transiente.

(c) FEEC/UNICAMP 43 (c) FEEC/UNICAMP 44

Stubs e Skeletons Atribuição de Nomes

Para interagir com um objeto remoto, um objeto cliente deve obter

(c) FEEC/UNICAMP 45 (c) FEEC/UNICAMP 46

Binding Invocação Remota de Métodos

CORBA especifica o protocolo IIOP (Internet Inter-ORB

(c) FEEC/UNICAMP 47 (c) FEEC/UNICAMP 48

Stub Skeleton OSI ODP ISO/ITU-T

(c) FEEC/UNICAMP 49 (c) FEEC/UNICAMP 50