Вы находитесь на странице: 1из 45

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.

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

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
(c) FEEC/UNICAMP 5 (c) FEEC/UNICAMP 6
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.

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

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.

(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


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.
(c) FEEC/UNICAMP 11 (c) FEEC/UNICAMP 12
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.

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

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.

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

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.

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


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

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

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
(c) FEEC/UNICAMP 21 (c) FEEC/UNICAMP 22

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

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


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
(c) FEEC/UNICAMP 25 (c) FEEC/UNICAMP 26

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

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

Evolução do Conceito de Middleware


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
(c) FEEC/UNICAMP 29 (c) FEEC/UNICAMP 30
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

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

Evolução do Conceito de Middleware


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
(c) FEEC/UNICAMP 33 (c) FEEC/UNICAMP 34

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).

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


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

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

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.

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

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.
(c) FEEC/UNICAMP 41 (c) FEEC/UNICAMP 42
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.

(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


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

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

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.

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


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

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

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

(c) FEEC/UNICAMP 51 (c) FEEC/UNICAMP 52

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).

(c) FEEC/UNICAMP 53 (c) FEEC/UNICAMP 54


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

(c) FEEC/UNICAMP 55 (c) FEEC/UNICAMP 56

Plataforma Java 2EE: Tecnologias Plataforma Java 2EE: Tecnologias


• 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)

(c) FEEC/UNICAMP 57 (c) FEEC/UNICAMP 58

Plataforma Java 2EE: Tecnologias Plataforma Java 2EE: Tecnologias

• 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

(c) FEEC/UNICAMP 59 (c) FEEC/UNICAMP 60


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 !!!
(c) FEEC/UNICAMP 61 (c) FEEC/UNICAMP 62

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;
}
(c) FEEC/UNICAMP 65 (c) FEEC/UNICAMP 66
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).
(c) FEEC/UNICAMP 67 (c) FEEC/UNICAMP 68

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()
(c) FEEC/UNICAMP 69 (c) FEEC/UNICAMP 70

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
(c) FEEC/UNICAMP 71 (c) FEEC/UNICAMP 72
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.

(c) FEEC/UNICAMP 73 (c) FEEC/UNICAMP 74

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);
(c) FEEC/UNICAMP 75 (c) FEEC/UNICAMP 76

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";
};

(c) FEEC/UNICAMP 77 (c) FEEC/UNICAMP 78


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
(c) FEEC/UNICAMP 79 (c) FEEC/UNICAMP 80

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.

(c) FEEC/UNICAMP 81 (c) FEEC/UNICAMP 82

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.

(c) FEEC/UNICAMP 83 (c) FEEC/UNICAMP 84


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

(c) FEEC/UNICAMP 85 (c) FEEC/UNICAMP 86

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

(c) FEEC/UNICAMP 87 (c) FEEC/UNICAMP 88

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.

(c) FEEC/UNICAMP 89 (c) FEEC/UNICAMP 90


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.

(c) FEEC/UNICAMP 91 (c) FEEC/UNICAMP 92

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

(c) FEEC/UNICAMP 93 (c) FEEC/UNICAMP 94

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

(c) FEEC/UNICAMP 95 (c) FEEC/UNICAMP 96


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’

(c) FEEC/UNICAMP 97 (c) FEEC/UNICAMP 98

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

(c) FEEC/UNICAMP 99 (c) FEEC/UNICAMP 100

ODP: Regras de Estruturação ODP: Regras de Estruturação

checkpoint, recover, delete, ...



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Ó

(c) FEEC/UNICAMP 101 (c) FEEC/UNICAMP 102


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

(c) FEEC/UNICAMP 103 (c) FEEC/UNICAMP 104

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.

(c) FEEC/UNICAMP 105 (c) FEEC/UNICAMP 106

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

(c) FEEC/UNICAMP 107 (c) FEEC/UNICAMP 108


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.

(c) FEEC/UNICAMP 109 (c) FEEC/UNICAMP 110

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.
(c) FEEC/UNICAMP 111 (c) FEEC/UNICAMP 112

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
(c) FEEC/UNICAMP 113 (c) FEEC/UNICAMP 114
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

(c) FEEC/UNICAMP 115 (c) FEEC/UNICAMP 116

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

(c) FEEC/UNICAMP 117 (c) FEEC/UNICAMP 118

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

(c) FEEC/UNICAMP 119 (c) FEEC/UNICAMP 120


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
(c) FEEC/UNICAMP 121 (c) FEEC/UNICAMP 122

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
(c) FEEC/UNICAMP 123 (c) FEEC/UNICAMP 124

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).

(c) FEEC/UNICAMP 125 (c) FEEC/UNICAMP 126


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.
(c) FEEC/UNICAMP 127 (c) FEEC/UNICAMP 128

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).

(c) FEEC/UNICAMP 129 (c) FEEC/UNICAMP 130

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
(c) FEEC/UNICAMP 131 (c) FEEC/UNICAMP 132
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

(c) FEEC/UNICAMP 133 (c) FEEC/UNICAMP 134

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)
(c) FEEC/UNICAMP 135 (c) FEEC/UNICAMP 136

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.

(c) FEEC/UNICAMP 137 (c) FEEC/UNICAMP 138


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).

(c) FEEC/UNICAMP 139 (c) FEEC/UNICAMP 140

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.

(c) FEEC/UNICAMP 141 (c) FEEC/UNICAMP 142

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.

(c) FEEC/UNICAMP 143 (c) FEEC/UNICAMP 144


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

(c) FEEC/UNICAMP 145 (c) FEEC/UNICAMP 146

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 ...


(c) FEEC/UNICAMP 147 (c) FEEC/UNICAMP 148

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).

(c) FEEC/UNICAMP 149 (c) FEEC/UNICAMP 150


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).

(c) FEEC/UNICAMP 151 (c) FEEC/UNICAMP 152

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

(c) FEEC/UNICAMP 153 (c) FEEC/UNICAMP 154

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.

(c) FEEC/UNICAMP 155 (c) FEEC/UNICAMP 156


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)

(c) FEEC/UNICAMP 157 (c) FEEC/UNICAMP 158

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

(c) FEEC/UNICAMP 159 (c) FEEC/UNICAMP 160

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 ! };
(c) FEEC/UNICAMP 161 (c) FEEC/UNICAMP 162
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;
(c) FEEC/UNICAMP 163 (c) FEEC/UNICAMP 164
};

IDL: Tipos Complexos (cont.) IDL: Tipos Complexos (cont.)

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;

(c) FEEC/UNICAMP 165 (c) FEEC/UNICAMP 166

IDL: Tipos Complexos (cont.) IDL: Tipos Complexos (cont.)

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

(c) FEEC/UNICAMP 167 (c) FEEC/UNICAMP 168


IDL: Tipos Complexos (cont.) IDL: Tipos Complexos (cont.)

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.

(c) FEEC/UNICAMP 169 (c) FEEC/UNICAMP 170

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();
};
(c) FEEC/UNICAMP 171 (c) FEEC/UNICAMP 172

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.
(c) FEEC/UNICAMP 173 (c) FEEC/UNICAMP 174
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 !


(c) FEEC/UNICAMP 175 (c) FEEC/UNICAMP 176

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. };
(c) FEEC/UNICAMP 177 (c) FEEC/UNICAMP 178

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

(c) FEEC/UNICAMP 179 (c) FEEC/UNICAMP 180


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

(c) FEEC/UNICAMP 181 (c) FEEC/UNICAMP 182

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);
};

(c) FEEC/UNICAMP 183 (c) FEEC/UNICAMP 184

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 };

(c) FEEC/UNICAMP 185 (c) FEEC/UNICAMP 186


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 }

(c) FEEC/UNICAMP 187 (c) FEEC/UNICAMP 188

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;}
} }
(c) FEEC/UNICAMP 189 (c) FEEC/UNICAMP 190

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
(c) FEEC/UNICAMP 191 (c) FEEC/UNICAMP 192
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

(c) FEEC/UNICAMP 193 (c) FEEC/UNICAMP 194

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);
};

(c) FEEC/UNICAMP 195 (c) FEEC/UNICAMP 196

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);
} }
}
(c) FEEC/UNICAMP 197 (c) FEEC/UNICAMP 198
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();
}

(c) FEEC/UNICAMP 199 (c) FEEC/UNICAMP 200

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.

(c) FEEC/UNICAMP 203 (c) FEEC/UNICAMP 204


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
(c) FEEC/UNICAMP 205 (c) FEEC/UNICAMP 206

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

(c) FEEC/UNICAMP 207 (c) FEEC/UNICAMP 208

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.
(c) FEEC/UNICAMP 209 (c) FEEC/UNICAMP 210
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


(c) FEEC/UNICAMP 211 (c) FEEC/UNICAMP 212

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.

(c) FEEC/UNICAMP 213 (c) FEEC/UNICAMP 214

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.

(c) FEEC/UNICAMP 215 (c) FEEC/UNICAMP 216


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

(c) FEEC/UNICAMP 217 (c) FEEC/UNICAMP 218

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.

(c) FEEC/UNICAMP 219 (c) FEEC/UNICAMP 220

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 !
(c) FEEC/UNICAMP 221 (c) FEEC/UNICAMP 222
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
(c) FEEC/UNICAMP 223 (c) FEEC/UNICAMP 224

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

(c) FEEC/UNICAMP 225 (c) FEEC/UNICAMP 226

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)

(c) FEEC/UNICAMP 227 (c) FEEC/UNICAMP 228


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.

(c) FEEC/UNICAMP 229 (c) FEEC/UNICAMP 230

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.

(c) FEEC/UNICAMP 231 (c) FEEC/UNICAMP 232

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.

(c) FEEC/UNICAMP 233 (c) FEEC/UNICAMP 234


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.

(c) FEEC/UNICAMP 235 (c) FEEC/UNICAMP 236

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

(c) FEEC/UNICAMP 237 (c) FEEC/UNICAMP 238

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.

(c) FEEC/UNICAMP 239 (c) FEEC/UNICAMP 240


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.

(c) FEEC/UNICAMP 241 (c) FEEC/UNICAMP 242

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.

(c) FEEC/UNICAMP 243 (c) FEEC/UNICAMP 244

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).

(c) FEEC/UNICAMP 245 (c) FEEC/UNICAMP 246


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.

(c) FEEC/UNICAMP 247 (c) FEEC/UNICAMP 248

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.

(c) FEEC/UNICAMP 249 (c) FEEC/UNICAMP 250

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.).

(c) FEEC/UNICAMP 251 (c) FEEC/UNICAMP 252


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)

(c) FEEC/UNICAMP 253 (c) FEEC/UNICAMP 254

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.
(c) FEEC/UNICAMP 255 (c) FEEC/UNICAMP 256

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

(c) FEEC/UNICAMP 257 (c) FEEC/UNICAMP 258


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

(c) FEEC/UNICAMP 259 (c) FEEC/UNICAMP 260

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).
};

(c) FEEC/UNICAMP 261 (c) FEEC/UNICAMP 262

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).

(c) FEEC/UNICAMP 263 (c) FEEC/UNICAMP 264


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