(c) FEEC/UNICAMP1 PLATAFORMAS DISTRIBUÍDAS Eleri Cardozo FEEC/UNICAMP eleri Julho de 2002.
Transcript of (c) FEEC/UNICAMP1 PLATAFORMAS DISTRIBUÍDAS Eleri Cardozo FEEC/UNICAMP eleri Julho de 2002.
(c) FEEC/UNICAMP 1
PLATAFORMAS DISTRIBUÍDAS
Eleri CardozoFEEC/UNICAMP
http://www.fee.unicamp.br/~eleri
Julho de 2002
(c) FEEC/UNICAMP 2
Introdução aos Sistemas Distribuídos
(c) FEEC/UNICAMP 3
Sistemas Distribuídos: Definição
Um sistema distribuído é um sistema computacionalcom as seguintes propriedades:
1. distribuição: um subconjunto de seus componentes encontram-se geograficamente dispersos;2. concorrência: um subconjunto de seus componentes executam concorrentemente (em paralelo);3. ausência de estado global: é impossível determinar-se precisamente o estado global do sistema;4. falhas parciais: qualquer componente do sistema pode falhar independente dos demais;5. assincronismo: as atividades do sistema não são regidas por um relógio global.
(c) FEEC/UNICAMP 4
Sistemas Distribuídos: Motivação
Evolução em microprocessadores: constante incremento da capacidade de processamento com decréscimo de custo.
Evolução em redes de comunicação: velocidades de Gigabits/s já disponíveis a custo atrativo.
Portanto, a utilização de uma rede rápida de processadores poderosos é atrativa para abrigar sistemas complexos de software.
(c) FEEC/UNICAMP 5
Evolução em Microprocessadores
MIPS
1987 1992 1997 20021982 2007
1
10
1000
100
10000
100000
20 BIPS
Pentium
486Mips
286
DEC Alpha
HP PA
386
(c) FEEC/UNICAMP 6
Evolução em Redes
Mbits/s
1987 1992 1997 20021982 2007
1
10
1000
100
10000 10 Gbits/s
Fast Ethernet
ISDNEthernet
FDDIT. Ring
X.25 Frame Relay
ATM Gigabit Ethernet
(c) FEEC/UNICAMP 7
Downsizing
$$$
$$$
(c) FEEC/UNICAMP 8
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 9
Internet
(c) FEEC/UNICAMP 10
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 11
Sistemas Abertos: Uma Classificação
Podemos classificar Sistemas Abertos em quatro categorias:
1. Modelos de Referência;2. Arquiteturas de Referência;3. Arquiteturas Abertas;4. Implementações de Referência.
(c) FEEC/UNICAMP 12
Modelos de Referência
Um modelo de referência é uma descrição de todos os possíveis componentes do sistema, bem como suas funções, relações, e formas de interação [SEI]. Exemplos: OSI, RM-ODP, OMA.
Por não imporem restrições para a realização de seus componentes, modelos de referência não 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 13
Arquiteturas de Referência
Uma arquitetura de referência é similar a um modelo de referência, mas prescreve interfaces entre seus componentes.Exemplos: TINA, CORBAservices.
Arquiteturas de referência possuem lacunas na especificação que levam a diferentes interpretações e possibilidades de extensões. Estas lacunas tendem a comprometer a interoperabilidade entre diferentes implementações da arquitetura.
(c) FEEC/UNICAMP 14
Arquiteturas
Uma arquitetura é similar a um modelo ou arquitetura de referência, mas prescreve protocolos de interopera-bilidade para todos os seus componentes. Exemplos: CORBA, H.323, TCP/IP, ISDN.
Arquiteturas provêem interoperabilidade mínima entre suas implementações.
(c) FEEC/UNICAMP 15
Implementações de Referência
Uma implementação de referência provê código fonte aberto (não necessariamente gratuito) para os componentes de uma arquitetura que são fundamentais para a interoperabilidade entre diferentes implementações desta arquitetura.Exemplos: FreeDCE, TMN API, HTTPd.
Implementações de referência garantem o maior nível possível de interoperabilidade para implemen-tações de sistemas abertos.
(c) FEEC/UNICAMP 16
Exemplo de Padrão Aberto: CORBA
CORBA especifica o Object Request Broker do modelo OMA. Interoperabilidade entre implementações CORBA é garantida pela linguagem IDL e pelo protocolo IIOP.
O modelo de referência OMA.
Object Request Broker (ORB)
Objetos deAplicação
CORBAFacilities(vertical)
CORBAFacilities
(horizontal)
Serviços CORBA(CORBAservices)
(c) FEEC/UNICAMP 17
Exemplo de Padrão Aberto: CORBA
• IDL e IIOP garantem que duas implementações CORBA sempre irão interoperar no tocante a invocação remota de métodos.
• Serviços CORBA (CORBAservices) nem sempre interoperam pois apenas suas interfaces são especificadas (faltam implementações de referência e/ou melhor especificação de comportamento).
• Gerência, configuração e recursos avançados de diferentes implementações CORBA não interoperam.
(c) FEEC/UNICAMP 18
Sistemas Abertos: Conclusão
Sistemas abertos são fundamentais para: • tornar as implementações menos dependentes de fornecedor individual;• incentivar a competição entre diferentes fornecedores por melhores produtos;• desenvolver aplicações portáveis, confiáveis, com alto grau de interoperabilidade e capazes de evoluir de forma ordenada;• incentivar a inserção de novas tecnologias.
(c) FEEC/UNICAMP 19
O Conceito deMiddleware
(c) FEEC/UNICAMP 20
O Conceito de MiddlewareVisão a Partir do Modelo OSI
APLICAÇÃO
APRESENTAÇÃO
SESSÃO
TRANSPORTE
REDE
ENLACE
FÍSICO
OPA! Isto eu conheço!!!
(c) FEEC/UNICAMP 21
Conceito de Middleware e o Modelo OSI
APLICAÇÃO
APRESENTAÇÃO
SESSÃO
TRANSPORTE
REDE
ENLACE
FÍSICO
Medicina
TelecomunicaçõesFinanças
(c) FEEC/UNICAMP 22
Conceito de Middleware e o Modelo OSI
APLICAÇÃO
APRESENTAÇÃO
SESSÃO
TRANSPORTE
REDE
ENLACE
FÍSICO
Ex: funções típicas detelecomunicações } Domínio de aplicação
Agente AgenteCliente } Gerenciamento de Rede
Um novo Modelo OSI: camada nível 8 contendo funções típicas dos váriosdomínios de aplicação:Medicina, Finanças, Telecomunicações, etc.
(c) FEEC/UNICAMP 23
Conceito de Middleware e o Modelo OSI
APLICAÇÃO
APRESENTAÇÃO
SESSÃO
TRANSPORTE
REDE
ENLACE
FÍSICO
Domínio da aplicação
Contexto daAplicação
Contexto dasComunicações
A Camada de Transporteé um divisor entre o mundo das aplicações e o mundo das comunicações
(c) FEEC/UNICAMP 24
Conceito de Middleware e o Modelo OSI
APLICAÇÃO
APRESENTAÇÃO
SESSÃO
TRANSPORTE
REDE
ENLACE
FÍSICO
Domínio da aplicação
MIDDLEWARE
(c) FEEC/UNICAMP 25
Conceito de Middleware e o Modelo OSI
APLICAÇÃO
APRESENTAÇÃO
SESSÃO
Domínio da aplicação
Sistema Operacional
+Hardware
} Sistemas Heterogêneos!
Necessidade dePadronização do
Middleware
(c) FEEC/UNICAMP 26
Evolução em Middleware
1987 1992 1997 2002 200719821977
troca demensagens
chamada deprocedimentoremoto (RPC)
objetosdistribuídos
agentes
componentes
(c) FEEC/UNICAMP 27
Evolução do Conceito de Middleware Troca de Mensagens (primitivas SEND/RECEIVE)
Receive
Aplicação Aplicação
TLI CPC-I Socket Named Pipes
SNA TCP/IP NetBIOSIPX/SPX
NDIS ODI
Token-ring Ethernet ISDN
API independente do transporte
Pilhas de Transporte
Drivers de Rede
Placas de Rede...
Send
(c) FEEC/UNICAMP 28
Troca de Mensagens: Semântica
tarefa 1 tarefa 2
send(M1)
receive(M2)
tarefa 1 tarefa 2
bloqueio
send(M1)
receive(M2)
send(M2)
receive(M1)
(c) FEEC/UNICAMP 29
Troca de Mensagens: Implementação
sistema detransporte(TCP/IP)
API(socket)
sistema detransporte(TCP/IP)
API(socket)
port (endpoint)
buffer
espaço do usuário
espaço do núcleo
LAN / WAN
(c) FEEC/UNICAMP 30
Evolução do Conceito de MiddlewareChamada Remota de Procedimento (RPC)
TLI CPC-I Socket Named Pipes
SNA TCP/IP NetBIOSIPX/SPX
NDIS ODI
Token-ring Ethernet
Aplicação Aplicação
ISDN
Remote Procedure Call (RPC)
2- Call (…) 1- Register (…) 3- Call (…)
(c) FEEC/UNICAMP 31
RPC: Semântica
cliente servidorcall P2(a1,a2)
retorno
cliente servidor
bloqueio
call P2(a1,a2)
P2 executa
P1
P2
P3
retorno
(c) FEEC/UNICAMP 32
RPC: Implementação
API(socket)
empacotaparâmetros
desempacotaresultado
cliente
R = call P2(a1,a2)
desempacotaparâmetros
empacotaresultado
servidor
dispatcher
P1 P2 P3
API(socket)
P2(a1,a2)1
2 3
45
67
8
bibliotecasRPC
P2a1a2
resultado
(c) FEEC/UNICAMP 33
Evolução do Conceito de MiddlewareObjetos Distribuídos
• O conceito de objetos surgiu para atender os requisitos relacionados ao aumento na complexidade do desenvolvimento de software Reusabilidade
Objeto
Barramento de Software
Interface Padrão
(c) FEEC/UNICAMP 34
Objetos: Constituição
interface: define, em termos deprotótipo, um conjunto de operações (ou métodos)
estado: define um conjunto de variáveis internas que armazenam o estado corrente do objeto
implementação: código dos métodos definidos tanto pelas interfaces quantos internos ao objeto
(c) FEEC/UNICAMP 35
Objetos: Regras de Interação
• toda a interação com um objeto se dá através da invocação de seus métodos declarados como públicos;
• métodos declarados como privados só podem ser invocados pelos demais métodos definidos pelo objeto;
• as variáveis de estado são manipuladas apenas pelos métodos (públicos ou privados) definidos pelo objeto (isto é, são invisíveis externamente ao objeto).
(c) FEEC/UNICAMP 36
Objetos: Conceitos Básicos
Classificação: objetos são organizados em classes. Uma classe define o comportamento dos objetos dela derivados.
Relacionamento: classes podem apresentar relações de interdependência, por exemplo• herança (relação tipo é-um/é-uma);• composição (relação tipo parte-de);• colaboração (relações tipo usa, delega, autoriza, etc).
(c) FEEC/UNICAMP 37
Objetos: Conceitos Básicos
Instanciação: objetos são criados através de uma operação (denominada de instanciação) sobre uma classe.
Encapsulamento: objetos “escondem” detalhes de sua implementação interna, expondo apenas suas interfaces para o meio externo.
Identidade: objetos possuem identidade única capaz de diferenciar um objeto dos demais.
Polimorfismo: métodos de mesmo nome podem apresentar diferentes comportamentos, dependendo do objeto que o implementa.
(c) FEEC/UNICAMP 38
Objetos: Conceitos Básicos
identidade
instanciação
classe
classe
herança (especialização)
classerelação
interfaceinvocação de métodosM1 M3
M2
estado
métodos
polimorfismo
encapsulamento
M2
(c) FEEC/UNICAMP 39
Objetos Distribuídos
Deve-se notar que as tecnologias de middleware procuram acompanhar as tecnologias de desenvolvimento de software:
• troca de mensagens: estende o paradigma de programação não estruturada à programação de sistemas distribuídos (programação distribuída);
• RPC: estende o paradigma de programação estruturada à programação distribuída;
• objetos distribuídos: estende o paradigma de programação orientada a objetos à programação distribuída.
(c) FEEC/UNICAMP 40
Objetos Distribuídos: Vantagens
Objetos distribuídos apresentam as seguintes vantagens sobre troca de mensagens e RPC:
• flexibilidade: qualquer entidade de software pode ser transformada em um objeto distribuído;• granularidade: objetos distribuídos podem apresentar diferentes níveis de granularidade;• confiabilidade: objetos distribuídos são entidades auto-contidas o que facilita a identificação, isolação e correção de falhas;• custo: o desenvolvimento de objetos distribuídos é mais econômico graças ao reuso de software propiciado pela programação orientada a objetos.
(c) FEEC/UNICAMP 41
Objetos Distribuídos: Interação
Objetos distribuídos são capazes de interagir através de uma rede de comunicação (LAN, Intranet, Internet) de forma semelhante à interação entre objetos locais. Para tanto, padrões são necessários para prover:• definição de interfaces remotas;• identificação de objetos (referências);• "nomeação" de objetos (naming);• associação nome-referência (binding);• suporte à invocação remota de métodos (RPC).
Estes padrões são oferecidos por uma infra-estrutura denominada ORB (Object Request Broker). Por exemplo, RMI é o ORB nativo da linguagem Java.
(c) FEEC/UNICAMP 42
Interfaces Remotas
Objetos distribuídos devem definir pelo menos uma interface remota capaz de processar invocações através da rede. Em padrões neutros (independentes de linguagem de programação) como CORBA e DCOM, uma linguagem de definição de interface (IDL) é especificada. ORBs provêem compiladores IDL para cada linguagem alvo.
RMI, por ser uma solução puramente Java, utiliza interfaces Java derivadas da interface Remote para definir interfaces remotas.
Um servant (ou implementação) é um objeto que implementa uma interface remota (i.e., supre código para os métodos da interface). Um objeto distribuído é constituído por um ou mais servants.
(c) FEEC/UNICAMP 43
Objetos Distribuídos: Implementação
ORB (biblioteca)Descrição da(s)Interface(s)
Compilador deInterfaces
Stubs / SkeletonsImplementaçãodos Servants
(C++, Java, ...)
Compilador(C++, Java, ...)
servant
(c) FEEC/UNICAMP 44
Referência de Objetos
Objetos distribuídos devem possuir uma identificação (referência) capaz de localizá-lo na rede. Esta identificação é dependente do ORB. Por exemplo, CORBA utiliza um identificador denominado IOR (Interoperable Object Reference) que agrega o endereço de rede do objeto (host e port do servidor), sua classe, seu identificador no servidor, etc. IOR é armazenado em uma cadeia de bytes.
RMI utiliza as próprias instâncias das classes Java que implementam interfaces remotas para identificar objetos distribuídos.
OBS: Uma referência pode ser persistente ou transiente.
(c) FEEC/UNICAMP 45
Stubs e Skeletons
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 interface remota do objeto. Ao invocar um método no stub, o stub encaminha a requisição para o objeto remoto, recebe o retorno e o devolve como resultado da interação. Skeletons fazem o papel inverso do stub no lado do objeto remoto.
invocação local
Stub Rede Skeleton
interfaceremota
objetodistribuídoupcall
M1M2M3
M1
M1M2M3
M1
protocolode RPC
cliente
(c) FEEC/UNICAMP 46
Atribuição de Nomes
ORBs convencionam esquemas de nomes para os objetos distribuídos. Por exemplo, CORBA utiliza um espaço hierárquico e arbitrário de nomes definido em um contexto.
RMI utiliza uma notação padrão URL:rmi://ferrugem.dca.fee.unicamp.br:8088/Servers/AccountServer//143.106.50.188/AccountServer
(c) FEEC/UNICAMP 47
Binding
ORBs provêem serviços de nomes para armazenar e recuperar associações nome-referência de objeto. No caso do RMI, um servidor de nomes denominado rmiregistry é fornecido com a plataforma Java.
servidor de nomes
servidor de nomes
clienteobjeto
distribuído
2. lookup 1. bind/rebind
3. invoke
(c) FEEC/UNICAMP 48
Invocação Remota de Métodos
A invocação de métodos remotos exige protocolos de RPC (Remote Procedure Call). Tais protocolos especificam:• como parâmetros são codificados (número de parâmetros, tipos, valores e indireções);• como invocações e retornos são estruturados;• que protocolo de transporte é utilizado (TCP ou UDP);• como exceções são propagadas de volta para o cliente.
CORBA especifica o protocolo IIOP (Internet Inter-ORB Protocol), enquanto RMI especifica JRMP (Java Remote Method Protocol). Opcionalmente, para fins de interoperabilidade com CORBA, RMI pode utilizar IIOP.
(c) FEEC/UNICAMP 49
Arquitetura de Distribuição
SkeletonStub
Object Request Broker
servant objetodistribuído
Nomes Eventos SegurançaServiços
servidor
cliente
(c) FEEC/UNICAMP 50
Middleware: Padrões
1987 1992 1997 200219821977
TCP/IP sockets RPC WWW
OSI ODP
DCE(OSF)
CORBA(OMG)
Consórcios
ISO/ITU-T
Internet
SOAP (W3C)
Indústria
DCOM(Microsoft)
RMI(SUN)
EJB(Sun)
.NET(Microsoft)
(c) FEEC/UNICAMP 51
Plataforma Java
(c) FEEC/UNICAMP 52
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 interfaces de programação (APIs).
Linguagem Java
Máquina Virtual
APIs
(c) FEEC/UNICAMP 53
Plataforma Java 2: Arquitetura
Adaptador
Browser
S.O.
Hardware
Adaptador
S.O.
Hardware
S.O. Java
Java Chip
Interface dePortabilidade
Máquina Virtual Java bytecodes
Classes Java Básicas
Classes Java Estendidas
PlataformaJava Básica
Applets, Pacotes, Frameworks Suporte àsAplicações
APIs
(c) FEEC/UNICAMP 54
Plataformas Java 2
A SUN Microsystems fornece três tipos de plataformas Java 2:
• Java 2 Platform, Micro Edition (J2ME): plataforma de desenvolvimento para dispositivos pequenos, tais como Palm Pilots, Pagers, etc. Contém uma forma bem restrita da linguagem Java;
• Java 2 Platform, Standard Edition (J2SE): contém serviços Java para Applets e Aplicações. Contém funcionalidades para entrada-saída, interfaces gráficas de usuários, entre outras;
• Java 2 Platform, Enterprise Edition (J2EE): plataforma de desenvolvimento completa para empresa fornecendo um ambiente seguro, multi-usuário, portável, neutro (Sistema Operacional e Hardware) para o desenvolvimento de aplicações distribuídas escritas em Java (com ënfase no lado servidor).
(c) FEEC/UNICAMP 55
Plataforma Java 2EE: Tecnologias
• Enterprise JavaBeans (EJB)
Cliente
Servidor EJB
Container EJB
EJB BeanEJB HomeInterface
EJB RemoteInterface Database
Define uma API que facilita a criação, instalação e gerência de aplicações baseadas em componentes. Utiliza RMI para comunicação cliente-servidor.
(c) FEEC/UNICAMP 56
Plataforma Java 2EE: Tecnologias
• JNDI (Java Naming and Directory Interface)
Cliente
JNDI API
JNDI NamingManager
OMG COSNaming
RMI Registry
Internet LDAP
Novell NDS
JNDI SPI
service providers
Provê acesso unificado a serviços de nomes e de diretório para as aplicações Java.
(c) FEEC/UNICAMP 57
Plataforma Java 2EE: Tecnologias
• JBDC (Java Database Connectivity)
Provê uma interface uniforme para acesso a bases de dados.
Cliente JDBC
JDBC API
JDBC Driver
API
JDBC Driver A
JDBC Driver B
JDBC Driver C
Database A
Database B
Database C
(c) FEEC/UNICAMP 58
Plataforma Java 2EE: Tecnologias
• JTA (Java Transaction API) e JTS (Java Transaction Service)
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.
Cliente JTS
JTA APIJTS API
TransactionCoordinator
TransactionManager(s)
ResourceManager(s)Datastores
(c) FEEC/UNICAMP 59
Plataforma Java 2EE: Tecnologias
• Java IDL (Interface Definition Language)
Permite aplicações Java interoperarem com outras plataformas CORBA (ex. Orbix). Prove compilador IDL e ORB simples que suporta IIOP.
Java 2 ORB Orbix
AppletJava
ServidorEJB
ClienteCORBA(C++)
ServidorCORBA(C++)
IIOP
(c) FEEC/UNICAMP 60
Plataforma Java 2EE: Tecnologias
• RMI-IIOP (Java Remote Method Invocation - CORBA Internet Inter-ORB Protocol)
Permite clientes Java acessarem, via RMI, serviços disponibilizados
em CORBA (e vice-versa). RMI-IIOP utiliza JNDI.
IIOP
RMI ORB CORBA ORB
ClienteRMI
ServidorRMI
ClienteCORBA
ServidorCORBA
RMI-IIOPAPI
(c) FEEC/UNICAMP 61
Plataforma Java 2EE: Tecnologias
• Outras Tecnologias:
� Java Server Pages (JPS) e Servlets: APIs que permitem estender as funcionalidades de um servidor WWW;
� Java Message Service (JMS): API para serviços de mensagens;
� JavaMail: API para serviços de E-mail;
� J2EE Connector: arquitetura para conectar a plataforma Java 2 com outros serviços de informação da empresa.
(c) FEEC/UNICAMP 62
Plataforma Java 2EE: API Específicas, Extensões, Pacotes e Produtos
� Java Media Framework (JMF): API para manipulação (local e através da rede) de áudio e vídeo;� Java TV API: API para serviços interativos em TV digital (ex: vídeo sob demanda);� Java Phone API: API para serviços de telefonia (ex: click-to-dial);� Java Commerce Toolkit: pacote para desenvolvimento de aplicações de comércio eletrönico;� Java Cryptography Extension e Java Authentication and Authorization Service: extensões de segurança;� Java 2D, Java 3D, Java Advanced Imaging: APIs para computação gráfica;� Jini: serviços de suporte à redes com topologia variável; � .......... Dentre muitos outros !!!
(c) FEEC/UNICAMP 63
Java Remote Method Invocation (RMI)
RMI é um ORB nativo da linguagem Java que provê uma infra-estrutura para invocação de métodos remotos, um compilador para geração de stubs e skeletons (rmic) e um servidor de nomes (rmiregistry). RMI utiliza o mecanismo de segurança nativo da linguagem Java através de security managers e class loaders.
RMI tem como vantagens simplicidade e plena integração com Java (segurança, carregamento dinâmico de classes, passagem de objetos por valor, etc.). Entretanto, é uma solução 100% Java (mas capaz de interoperar com outras linguagens de programação através de CORBA).
(c) FEEC/UNICAMP 64
RMI: Visão Geral
Naming.bindrmi://host:port/NameObjRef
stub
socket
Naming.lookuprmi://host:port/Name rmiregistry
host
skel.
socket
servidor RMI
cliente RMI
TCP/IP
JRMP
TCP/IP
IIOP
Servant
M2M1 M3
s.M1(...)
ObjRef
M2M1 M3
rmicNaming
Naming
(c) FEEC/UNICAMP 65
Java RMI
O ciclo de desenvolvimento de objetos distribuídos em RMI possui os seguintes passos:
1. definição da interface remota;2. compilação da interface remota (javac); 3. desenvolvimento do servant;4. geração de stubs e skeletons a partir do servant via compilador RMI (rmic);5. desenvolvimento do servidor.
(c) FEEC/UNICAMP 66
RMI: Interfaces Remotas
Interfaces remotas em RMI são declaradas como interfaces Java que estendem a interface Remote. Cada método da interface remota deve lançar uma exceção do tipo RemoteException (que será propagada ao cliente).
import java.rmi.Remote; import java.rmi.RemoteException;
public interface Account extends Remote { void deposit( long amount ) throws RemoteException; void withdraw( long amount ) throws RemoteException; long balance() throws RemoteException; }
(c) FEEC/UNICAMP 67
RMI: Passagem de Parâmetros em Métodos de Interfaces Remotas
Parâmetros e retornos em invocações remotas são sempre passados por valor (isto e, uma cópia é passada). Objetos Java passado como parâmetros devem ser "serializáveis" (todos os tipos nativos são).
Referências de objetos remotos podem ser passados como parâmetros ou retorno (no caso, uma cópia de seu stub é passada). Tais objetos devem possuir apenas interfaces remotas.
Caso a classe de um objeto passado ou retornado não se encontra presente na JVM, a mesma pode ser carregada dinamicamente via HTTP (detalhes a seguir).
(c) FEEC/UNICAMP 68
RMI: Servants
import java.rmi.*;import java.rmi.server.*;
public class AccountServant implements Account { long balance; long limit;
public AccountServant(long lim) throws RemoteException { super(); balance = 0; limit = lim; }
(c) FEEC/UNICAMP 69
RMI: Servants (cont.)
public void deposit( long amount ) throws RemoteException { balance = balance + amount; }
public void withdraw( long amount ) throws RemoteException { if((limit + balance - amount) < 0) throw new RemoteException("Limit Exceeded"); balance = balance - amount; } public long balance() throws RemoteException { return balance; } }
(c) FEEC/UNICAMP 70
RMI: Classes
<<interface>>Account
deposit()withdraw() balance()
AccountServant
deposit()withdraw() balance()
<<interface>>Remote
extends
implements
AccountServant_Stub
deposit()withdraw() balance()
AccountServant_Skel
deposit()withdraw() balance()
geradas por rmic
AccountClient
(c) FEEC/UNICAMP 71
RMI: rmic (Compilador RMI)
A plataforma Java provê um compilador capaz de gerar stubs e skeletons para suporte à distribuição de objetos com RMI. O compilador recebe como argumento a classe compilada do servant e gera dois arquivos compilados: um contendo o stub (utilizado pelo cliente) e outro o skeleton (utilizado pelo servidor). Exemplo:C:\ dir *.classAccount.classAccountServant.classC:\ rmic AccountServantC:\ dir *.classAccount.classAccountServant.classAccountServant_Stub.classAccountServant_Skel.class
(c) FEEC/UNICAMP 72
RMI: Serviço de Nomes
A plataforma Java provê um serviço de nomes para registro de servants RMI. O serviço de nomes é suportado por um servidor transiente, rmiregistry, que armazena as referências de objetos localizados em seu próprio nó.
A referência de objeto no formato URL estipula o seu endereço de host e, opcionalmente, port do servidor de nomes. Exemplo: seja um objeto registrado como:rmi://ferrugem.dca.fee.unicamp.br/Servers/AccountServerO acesso à referência do objeto deve se dar no endereço de host "ferrugem.dca.fee.unicamp.br" e port default do servidor de nomes (1099).
(c) FEEC/UNICAMP 73
RMI: A Classe Naming
O servidor de nomes rmiregistry é acessível através da classe Naming que provê os seguintes métodos estáticos:
• void bind(String name, Remote ref): associa um nome a uma referência de objeto;• void rebind(String name, Remote ref): re-associa um nome a uma referência de objeto;• Remote loopkup(String name): busca uma referência associada ao nome;• void unbind(String name): desassocia a referência do nome;• String[] list(String registry): lista todos os nomes mantidos por um servidor rmiregistry.
(c) FEEC/UNICAMP 74
RMI: Servidores
import java.rmi.*;import java.rmi.server.*;import java.net.*;
public class AccountServer {public static void main(String[] args) { // if no security manager was set, set the RMI´s one if(System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); }
(c) FEEC/UNICAMP 75
RMI: Servidores (cont.)
try { String host = (InetAddress.getLocalHost()).getCanonicalHostName(); String name = "rmi://" + host + "/Account"; Account objRef = new AccountServant((long)1000); Naming.rebind(name, objRef); // bind System.out.println("AccountServant registered"); } catch (Exception e) { System.err.println("AccountServant exception: " + e.getMessage()); e.printStackTrace(); } }
(c) FEEC/UNICAMP 76
RMI: Clientes
import java.rmi.*;import java.net.*;
public class AccountClient { public static void main(String args[]) { if(args.length != 1) { System.out.println("I need the server's host name as argument"); System.exit(0);} // if no security manager was set, set the RMI´s one if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager());} 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 77
RMI: Clientes (cont.)
accountRef.deposit( 100 ); accountRef.deposit( 300 ); accountRef.deposit( 100 ); accountRef.withdraw( 240 ); accountRef.withdraw( 10 ); System.out.println("Balance is " + accountRef.balance()); accountRef.withdraw( 10000 ); } catch (Exception e) { System.err.println("AccountClient exception: " + e.getMessage()); } } }
(c) FEEC/UNICAMP 78
RMI: Aspectos de Segurança
No lado servidor, RMI exige que todas as permissões de socket sejam habilitadas para os domínios onde os clientes se localizam. Adicionalmente, permissão para conexão local ao port 1099 (rmiregistry) deve ser habilitada. Por exemplo, o trecho do arquivo .java.policy abaixo libera interações com clientes localizados em qualquer host do domínio "dca.fee.unicamp.br"
grant { permission java.net.SocketPermission "*.dca.fee.unicamp.br", "listen,accept,connect"; permission java.net.SocketPermission "localhost:1099", "connect";};
(c) FEEC/UNICAMP 79
RMI Sobre HTTP
Devido a presença de firewalls, uma requisição RMI pode ser impedida de atingir o objeto remoto. Nestes casos, é possível tunelar-se a requisição RMI sobre o protocolo HTTP.
clienteRMI
StubproxyHTTP
servidorRMI
Firewall script CGI(java-rmi.cgi)
sockets especiais
Skeleton
HTTP POST
Serv. HTTP
(c) FEEC/UNICAMP 80
RMI: Propriedades
O comportamento de clientes e servidores RMI pode ser configurado através de propriedades da máquina virtual. As mais comuns são:
• java.rmi.server.codebase: localização (URL) das classes que devem ser carregadas dinamicamente (skeletons, parâmetros, etc.);• java.rmi.server.logCalls: gera um log em System.err;• java.rmi.activation.port: define um port de ativação para o daemom RMI (default 1098);• java.rmi.server.disableHttp: desabilita tunelamento através de HTTP.
(c) FEEC/UNICAMP 81
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).
• Deve-se prover uma infra-estrutura que permita a 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 82
ODP (Open DistributedProcessing)
(c) FEEC/UNICAMP 83
Modelo OSI
O Modelo OSI possui algumas funcionalidades nacamada 7 para o desenvolvimento de sistemas distribuídos:
• ROSE (Remote Operation Service Element);• CCR (Concurrency, Commitment, Recovery);• TP (Transaction Processing);• DS (Directory Service);• MHS (Message Handling System).
(c) FEEC/UNICAMP 84
Modelo OSI
Problemas no desenvolvimento de Sistemas Distribuídosdiretamente sobre o OSI:
• baixa disponibilidade de implementações completas;• padrão “estacionado”;• ausência de serviços importantes (segurança, principalmente);• ASN.1/BER pouco flexível;• eficiência dos protocolos.
(c) FEEC/UNICAMP 85
ODP: Open Distributed Processing
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ãosão especificados) que vem influenciando outrasatividades de padronização (exemplo: CORBA).
Seu desenvolvimento foi fortemente influenciado peloprojeto ANSA (Universidade de Lancaster, UK).
(c) FEEC/UNICAMP 86
ODP: Pontos de Vista
Empresa
Informação Computação
Engenharia Tecnologia
SDespecificação
implementação
(c) FEEC/UNICAMP 87
ODP: Pontos de Vista
Pontos de vista não são hierarquizados, mas sim diferentes visões de um mesmo sistema.
SD
ponto de vista
(c) FEEC/UNICAMP 88
ODP: Pontos de Vista
Empresa
Informação Computação
Engenharia
SD
espe
cific
ação
impl
emen
taçã
o
TecnologiaORB
(c) FEEC/UNICAMP 89
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á empregado.
Em linhas gerais, pode ser considerada um “resumo executivo” do sistema, onde suas principais características são levantadas.
Este ponto de vista estabelece as principais restrições impostas ao projeto do sistema.
Não existe uma linguagem formal para descrever o sistema neste ponto de vista. Textos, gráficos, diagramas, esquemas podem ser livremente utilizados.
(c) FEEC/UNICAMP 90
ODP: Ponto de Vista de Empresa
Grandezas relevantes para este ponto de vista:
• requisitos (QoS, custos, ...);• objetivos (mercados, público-alvo, …);• benefícios (lucro, produtividade, …);• políticas (segurança, acesso, taxação, ...);• domínios administrativos/federações;• restrições/privilégios de uso do sistema;• pontos de referência (protocolos, acordos, ...);• funcionalidades (agentes, relações, contratos, ...).
(c) FEEC/UNICAMP 91
ODP: Ponto de Vista de Informação
O ponto de vista de informação tem por objetivo modelar o sistema enfocando a informação produzida e consumida pelo sistema.
Neste ponto de vista são levantados os principais componentes manipuladores de informação, componentes estes denominados objetos de informação.
(c) FEEC/UNICAMP 92
ODP: Ponto de Vista de Informação
Objetos de informação identificam as principais entidades do domínio, suas relações (especialização, decomposição, etc.) e principais variáveis e operações.
Este ponto de vista pode ser descrito através de notação gráfica introduzidas por metodologias de desenvolvimento orientado a objeto (UML, OMT, …).
(c) FEEC/UNICAMP 93
ODP: Ponto de Vista de Computação
O ponto de vista de computação modela o sistema em termos de entidades de processamento de informação. Estas entidades, denominadas objetos computacionais, são os blocos fundamentais a partir dos quais o sistema distribuído é contruido.
Este ponto de vista pode ser descrito através de notação gráfica introduzidas por metodologias de desenvolvimento orientado a objeto (UML, OMT, …).
(c) FEEC/UNICAMP 94
ODP: Ponto de Vista de Computação
No ODP, objetos computacionais básicos (BCO: basic computacional object) possuem múltiplas interfaces computacionais, cada uma associada a determinado tipo. O tipo define as características da interface.
T1 T2
BCOinterface computacional
tipo da interface
(c) FEEC/UNICAMP 95
ODP: Interfaces Computacionais
stream
sinal
produtor consumidor
sinal
evocação
terminação
operação
fluxo
cliente servidor
iniciador respondedor
(c) FEEC/UNICAMP 96
ODP: Ligação (Binding) Primitiva
BCOT’T
BCO
Na ligação primitiva dois objetos computacionais básicos têm suas interfaces conectadas sem o auxílio de um artefato específico de interconexão. Exemplo: objetos C++ num mesmo programa.
T’: tipo complementar a T
(c) FEEC/UNICAMP 97
ODP: Ligação (Binding) Composta
Na ligação composta dois objetos computacionais básicos têm suas interfaces conectadas com o auxílio de um artefato específico de interconexão. Na visão de computação este artefato é representado por um objeto de ligação (BO: binding object).
BO
interfacede controle
T T’ T’TBCO BCO
(c) FEEC/UNICAMP 98
ODP: Ponto de Vista de Engenharia
O ponto de vista de engenharia fornece a visão “espacial” (distribuída) do sistema. Nesta visão os objetos computacionais (BCO e BO) da visão de computação são realizados através de objetos básicos de engenharia (BEO: Basic Engineering Object). Regras de estruturação que estabelecem agrupamentos e ligações entre BEOs.
Este ponto de vista pode ser descrito através de diagramas de distribuição (deployment) da notação UML.
(c) FEEC/UNICAMP 99
ODP: Ponto de Vista de Engenharia
Objetos Básicos de Engenharia (BEO)
São as unidades de processamento no ponto de vista de engenharia. Possuem uma interface de gerenciamento e uma ou mais interfaces de serviço, interfaces estas denomi-nadas interfaces de engenharia.
checkpoint, recover, delete, ...
interface de engenharia
BEO
interface degerenciamento
(c) FEEC/UNICAMP 100
ODP: Regras de Estruturação
Cluster
Cluster é um agregado de BEOs compartilhando um mesmo espaço de endereçamento. Um BEO especial no cluster (Gerente de Cluster - GCL) provê uma interface de gerenciamento para o cluster. É a unidade de migração do ODP.
GCL
CLUSTER
BEO
checkpoint, recover, delete, ...
(c) FEEC/UNICAMP 101
ODP: Regras de Estruturação
Cápsula
Cápsula é um agregado de
clusters. Um BEO especial na cápsula (Gerente de Cápsula) provê uma interface de geren-ciamento para a cápsula. É a unidade de alocação de recursos do ODP (exemplo: processo UNIX).
checkpoint, recover, delete, ...
GCP
CÁPSULA
GCL
CLUSTER
GCL
CLUSTER
(c) FEEC/UNICAMP 102
ODP: Regras de Estruturação
Nó
Um nó é composto de um conjunto de cápsulas e um núcleo. No ODP o nó representa uma unidade de processamento, armazenamento e comunicação. Exemplo: estação UNIX.
CÁPSULA
CÁPSULA
núcleo
NÓ
(c) FEEC/UNICAMP 103
ODP: Regras de Estruturação
Canal
Canal é a realização do objeto de ligação na visão de engenharia. É composto de três objetos básicos de engenharia de cada lado: stub, binder e protocol adapter. Adicionalmente, um controlador de canal expõe uma interface única de controle para o canal.
canal
stub
rede
protocol adapters
stub
contr.de canal
binders
BEO1 BEO2interface
de controle
(c) FEEC/UNICAMP 104
ODP: Canal
Stub
Stub é responsável pelos serviços de apresentação (conversão/compactação de dados, criptografia, etc) do canal.
Apresenta uma interface de dados para o objeto de engenharia no extremo do canal e uma interface de controle utilizada pelo controlador de canal.
(c) FEEC/UNICAMP 105
ODP: Canal
Binder
Binder é responsável pelo gerenciamento fim-a-fim do canal. Funções típicas do binder: monitoramento do fluxo de informação através do canal, gerência de qualidade de serviço e destruição de seu extremo do canal.
Possui interfaces de dados para o stub e protocol adapter, além de uma interface de controle utilizadada pelo controlador de canal.
(c) FEEC/UNICAMP 106
ODP: Canal
Protocol Adapter
Protocol Adapter é responsável pela comunicação fim-a-fim no canal. Funções típicas: estabelecimento e encerramento de conexões de transporte através da rede.
Apresenta uma interface de dados para o binder e uma interface de controle utilizada pelo controlador de canal.
(c) FEEC/UNICAMP 107
ODP: Canal
Controlador de Canal
Controlador de canal apresenta uma interface única de controle para o canal. Esta interface realiza na visão de engenharia a interface computacional do objeto de ligação (BO) presente na visão de computação.
Controlador de canal interage com os demais objetos do canal para realizar a ação de controle solicitada em sua interface.
(c) FEEC/UNICAMP 108
ODP: Mapeamento Computação/Engenharia
canal
stub
rede
protocol adapters
stub
contr.de canal
binders
BEO2BEO1 BCO1
BO
BCO2
transparência
(c) FEEC/UNICAMP 109
ODP: Transparência
Transparência é um conceito chave que permite a visão de engenharia (associada à implementação do sistema) se aproximar da visão de computação (associada ao modelamento do sistema).
Transparência deve ser provida pelo núcleo, canal e demais infra-estruturas de suporte à implementação (ORBs, repositórios, etc.).
(c) FEEC/UNICAMP 110
ODP: Transparência
Tipos de transparência:
• acesso;• localização;• migração;• concorrência (transação);• relocação;• falha;• replicação;• persistência.
As transparências de acesso e localização são as mais comumente encontradas nos sistemas distribuídos.
(c) FEEC/UNICAMP 111
DCE (Distributed ComputingEnvironment)
(c) FEEC/UNICAMP 112
DCE: Distributed Computing Environment
Padrão da antiga Open Software Foundation (OSF), hoje Open Group.
OSF é um consórcio sem fins lucrativos de empresas (IBM, DEC, HP,…) destinado a padronização detecnologias 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 OMGe ISO, a OSF supre os implementadores com um código fonte base.
(c) FEEC/UNICAMP 113
DCE: Objetivos
Oferecer um conjunto de serviços distribuídos(RPC, sistema de arquivos, serviços de segurança,diretório e relógio distribuído) independentes deplataforma sobre os quais aplicações distribuídassão construídas.
Estes serviços são baseados em padrões já consagrados tais como X.500 (ISO/ITU-T), DNS(IETF) e POSIX (IEEE).
(c) FEEC/UNICAMP 114
DCE: Arquitetura
HARDWARE
SISTEMA OPERACIONAL REDE
DCE Threads
DCE Remote Procedure Call
SegurançaTime Diretório
Sistema de Arquivos
APLICAÇÕES DISTRIBUÍDAS
(c) FEEC/UNICAMP 115
DCE: Threads
OBJETIVO: uniformizar a programação multithreaded.
Utiliza o padrão POSIX 1003.4a (IEEE).
Provê três esquemas de escalonamento de threads:• FIFO (First In First Out)• RR (Round Robin)• Default (RR com prioridades)
(c) FEEC/UNICAMP 116
DCE: Threads
espaço de endere-çamento comum
THREAD
THREAD
THREAD
THREAD
espaço de en-dereçamento
processomonothreaded processo multithreaded
escalonamento
tempo
(c) FEEC/UNICAMP 117
DCE: Threads
A programação multithreaded permite que servidoresprocessem uma requisição enquanto outra estiverpendente (bloqueada por I/O, por exemplo).
servidor multi-threaded
cliente
cliente
req #1
req #2
(c) FEEC/UNICAMP 118
DCE: Threads
Formas de Escalonamento:
Pb > Pa, Pc
A B C
CC ABA C
AA CCC BB
FIFO
RR
DEF.
BBB B
(c) FEEC/UNICAMP 119
DCE: Remote Procedure Call
• Integrado com os serviços de thread, segurança e diretório;
• Independente da pilha de protocolos de rede;
• Permite a passagem de argumentos de tamanho ilimitado e de ponteiros;
• Utiliza uma linguagem de definição de interfaces: IDL - Interface Definition Language (diferente da IDL do CORBA !)
(c) FEEC/UNICAMP 120
DCE: RPC
SERVIÇO DEDIRETÓRIO
servidor
2. registra serviço
RPCdaemon
tabela de endpoints
1. registra endpoint
cliente5. RPC
3. server ?
4. endpoint ?
(c) FEEC/UNICAMP 121
DCE: RPC
uuidgen
Editor
compilador IDL
arquivo IDL
gera ID único
contém a definiçãoda interface do serviço
stub docliente cabeçalho
stub doservidor código C
(c) FEEC/UNICAMP 122
DCE: RPC
stub docliente cabeçalho
stub doservidor
Compilador C
CLIENTE SERVIDOR
Compilador C
código docliente
código doservidor
runtime lib(cliente)
runtime lib(servidor)
(c) FEEC/UNICAMP 123
DCE: Serviço de Relógio Distribuído (DTS)
Objetivo: garantir que os relógios das máquinascom DCE instalado:
• são consistentes (marcam o mesmo tempo);• são corretos (seguem a mesma referência).
DTS é necessário para a ordenação de eventosnuma aplicação distribuída.
No DCE, tempo é armazenado num contador de64 bits cujo valor zero corresponde a 00:00 Hs de15/10/1582 !
(c) FEEC/UNICAMP 124
DCE: DTS
UTC
timeserver
timeserver
timeclerk
timeclerk
timeclerk
redetime ?
fonte de tempo(não requerida)
(c) FEEC/UNICAMP 125
DCE: DTS
Forma de operação:
UTC server #1
UTC server #2
UTC server #3
UTC server #4
TIME CLERK
(c) FEEC/UNICAMP 126
DCE: Serviço de Diretório
Objetivo: manter a localização (host) de servidores.
O serviço de diretório é estruturado em dois níveis:• Nível local (de célula): registra os recursos locais (CDS: Cell Directory Service)• Nível Global: permite acesso a recursos remotos (GDS: Global Directory Service)
GDS é baseado nos padrões X.500 (ISO/ITU-T) e DNS (Internet Domain Name System).
(c) FEEC/UNICAMP 127
DCE: Serviço de Diretório
Arquitetura:
servidor DNS X.500 DA
CDS GDA CDS GDA CDS GDA
CDS: Cell Directory AgentGDA: Global Direcory Agent
célula
outros servidores
(c) FEEC/UNICAMP 128
DCE: Serviço de Segurança
Objetivo: prover acesso seguro aos recursos.
No DCE, segurança compreende três atividades:
• Autenticação: comprovação da identidade de clientes e servidores;
• Autorização: quem está autorizado a manipular determinado recurso;
• Proteção: garantir que a informação não se alterou em trânsito.
(c) FEEC/UNICAMP 129
DCE: Serviço de Segurança
AUTENTICAÇÃO
Utiliza a tecnologia Kerberos (MIT).
Um servidor de segurança (security server) gerencia adistribuição de tickets (informação criptografada contendoas identidade de pares cliente-servidor).
Tickets são usados para o estabelecimento deRPC Autenticada (segura).
(c) FEEC/UNICAMP 130
DCE: Serviço de Segurança
AUTORIZAÇÃO
Utiliza listas de controle de acesso (ACL: Access ControlList). ACL é um padrão POSIX 1003.6.
Cada recurso possui uma ACL que discrimina osprivilégios para usuários e grupos de usuários.Exemplos de privilégios: read, write, execute.
ACLs são armazenadas num servidor (ACL server).
(c) FEEC/UNICAMP 131
DCE: Serviço de Segurança
PROTEÇÃO
Utiliza checksum criptografado como proteção contraalteração da informação em trânsito.
checksuminformação (ex: parâmetro RPC)
computado por criptografia
OBS: O DCE não provê mecanismos paracriptografar a informação.
(c) FEEC/UNICAMP 132
DCE: Serviço de Segurança
Visão Geral:
servidor deautenticação
obtém tickets
ferramentas deadministraçãochaves
criptográficas
permissões
login(lib)
clienteACL
server
RPC
recursos
servidorobtémpermissão
(c) FEEC/UNICAMP 133
DCE: Sistema de Arquivos
DCE provê um sistema de arquivos distribuído (DFS: Distributed File System) composto de:
• Um subsistema de arquivo local similar ao do UNIX denominado Episode (acesso compativel com o padrão POSIX 1003);
• Um conjunto de servidores para tornar distribuído o subsistema de arquivos local.
(c) FEEC/UNICAMP 134
DCE: DFS (cliente)
subsistema dearquivo local
clientechamada de sistema(open, read, write, …)
chamadas locais chamadas DFS
DFS cache
RPC para osservidores DFS
(c) FEEC/UNICAMP 135
DCE: DFS (servidor)
chamadas locais chamadas DFS
Token Manager
Episodesubsistema dearquivo local(+ extensões)
File Exporter
filesetserver
replicationserver
BOSserver
backupserver
(c) FEEC/UNICAMP 136
DCE: o conceito de CÉLULA
servidores DFS
servidores desegurança,diretório e time
clientes
(c) FEEC/UNICAMP 137
CORBA (Common ObjectRequest Broker
Architecture)
(c) FEEC/UNICAMP 138
Object Management Group (OMG)
O OMG foi fundado em 1989 por 11 empresas (dentre elas 3Com, HP, Data General, Unisys, Sun e Philips) como uma empresa sem fins lucrativos. Hoje possui 800 membros, dentre eles todos os “peso-pesados” das indústrias de informática e de telecomunicações.
(c) FEEC/UNICAMP 139
OMG: Missão
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 o desenvolvimento de aplicações. Estas especificações incluem: uma arquitetura de referência (OMA) e sua implementação (CORBA); uma linguagem de especificação (IDL); protocolos de interoperabilidade (GIOP, IIOP); aplicações específicas (TMN, IN, etc.).
(c) FEEC/UNICAMP 140
OMG: Estrutura
O OMG é estruturado em três comitês:
1. Platform Technology Committee (PTC);
2. Domain Technology Committee (DTC);
3. Architecture Board.
Cada comitê é subdividido em Task Forces, Special Interest Groups (SIGs) e Working Groups (WGs).
(c) FEEC/UNICAMP 141
OMG: Processo de Padronização
Membros do OMG possuem um dos três níveis de influência: voto no nível de Task Forces (universidades, governos, pequenas empresas); voto no nível de Platform TC, Domain TC ou ambos (grandes usuários de tecnologia); submissão de padrões para adoção nos TCs (gigantes da informática e telecomunicações).
(c) FEEC/UNICAMP 142
OMG: Padrões Alternativos
As principais tecnologias que competem com as padronizadas pelo OMG são:
• Microsoft DCOM (Distributed Component Object Model). Problema: uma empresa, uma tecnologia (Windows).
• Sun Java (linguagem, APIs, toolkits, frameworks, etc.).
Problema: uma linguagem de programação.
• W3C (WWW Consortium): introdução de objetos na Web (XML, HTTP, SOAP, etc.).
Problema: soluções centradas na Web.
(c) FEEC/UNICAMP 143
A Arquitetura OMA
OMA (Object Management Architecture) é uma arquitetura de referência para gerência de objetos distribuídos. A arquitetura identifica componentes, interfaces e protocolos necessários para o desenvolvimento de sistemas de software interoperáveis entre os principais sistemas de hardware, sistemas operacionais e linguagens de programação.
(c) FEEC/UNICAMP 144
OMA: Componentes
OMA possui um componente central, o Object Request Broker (ORB), e 4 categorias de interfaces:
Serviços de Objetos (Object Services); Facilidades Comuns (Common Facilities); Interfaces Específicas do Domínio (Domain Interfaces); Interfaces Específicas da Aplicação (Application Interfaces).
(c) FEEC/UNICAMP 145
OMA: Componentes
ApplicationInterfaces
Domain Interfaces
CommonFacilities
Object Request Broker (ORB)
ObjectServices
(c) FEEC/UNICAMP 146
OMA: Object Request Broker
O Object Request Broker (ORB) é um facilitador de comunicação entre objetos distribuídos. Funções típicas desempenhadas pelo ORB:
transparência de comunicação (localização, conversão de dados, referência de objetos, etc.); gerência da execução de objetos servidores; manutenção de repositórios de servidores e suas interfaces; gerência de tipos específicos de dados (Any, NVList, etc.).
(c) FEEC/UNICAMP 147
OMA: Serviços de Objetos
São arquiteturas e interfaces para serviços de propósito geral tais como:
• nomes;• eventos;• propriedades;• ciclo de vida;• transações;• persistência;• externalização/ internalização;• segurança;• coleções.
dentre muitos outros ...
(c) FEEC/UNICAMP 148
OMA: Facilidades Comuns
São interfaces (denominadas horizontais) para serviços orientados para aplicações-fim. Exemplos:
• agentes móveis;• data interchange;• interfaceamento com o usuário;• gerenciamento da informação;• gerenciamento de sistemas;• gerenciamento de tarefas (workflow).
(c) FEEC/UNICAMP 149
OMA: Interfaces Específicas do Domínio
São interfaces (denominadas verticais) para serviços em domínios específicos. Exemplo:
• CORBA/TMN and CORBA/SNMP Interworking• CORBA/Intelligent Networks Interworking• Notification Service • Control and Management of A/V Streams• Telecom Log Service• Wireless Access & Control
(c) FEEC/UNICAMP 150
OMA: Interfaces de Aplicação
São interfaces para os serviços específicos da aplicação. Estes serviços em geral utilizam os serviços de objetos, as facilidades comuns ou serviços específicos do domínio. Exemplo: uma aplicação de gerência de redes pode utilizar o serviço de eventos (serviço de objetos) e o Telecom Log Service (serviço específico do domínio).
(c) FEEC/UNICAMP 151
A Arquitetura CORBA
A Arquitetura CORBA (Common Object Request Broker Architecture) especifica um ORB para a Arquitetura de Referência OMA.
Os demais elementos da OMA, quando implementados sobre CORBA são denominados CORBAservices (serviço de objetos) e CORBAfacilities (facilidades comuns).
(c) FEEC/UNICAMP 152
CORBA: Características
• Estabelece uma arquitetura orientada a objetos;
• Separa a interface do serviço de sua implementação;
• Prevê uma vasta gama se serviços e funcionalidades;
• Permite a utilização de múltiplas linguagens de programação (C++, Java, Smalltalk, etc.);
• Previsão de vir embutido nos sistemas operacionais e linguagens de programação (Java 1.2).
(c) FEEC/UNICAMP 153
CORBA: Arquitetura
A Arquitetura CORBA é composta dos seguintescomponentes básicos:
• ORB (Object Request Broker);• Compilador IDL (Interface Definition Language);• SII (Static Invocation Interface);• DII (Dynamic Invocation Interface);• BOA/POA (Basic/Portable Object Adaptor);• Repositórios de Interfaces e de Implementação.
(c) FEEC/UNICAMP 154
CORBA: Arquitetura
cliente
ORB
POAIDL
skeletonIDL stub DII
servidor
ORBinterface
Repositóriode Interfaces
Repositório deImplementação
(c) FEEC/UNICAMP 155
CORBA: Object Request Broker (ORB)
É o componente básico de interconexão daArquitetura CORBA, sendo responsável peloencaminhamento de requisições de métodospara objetos remotos.
O ORB provê independência de plataforma,localização e linguagem de implementação dosobjetos comunicantes.
Usualmente é implementado como um daemonque executa em todas as máquinas da rede.
(c) FEEC/UNICAMP 156
CORBA: ORB
cliente (Java) servidor (C++)
Windows NT Solaris
ORB
(c) FEEC/UNICAMP 157
CORBA: Internet Inter-ORB Protocol (IIOP)
Objetivo: Prover interoperabilidade entre ORBs dediferentes fornecedores.
ORB (IBM)
INTERNET(TCP/IP)
cliente
ORB (IONA)
IIOPservidor
(c) FEEC/UNICAMP 158
CORBA: Interface Definition Language (OMG IDL)
Objetivo: especificar interfaces (métodos e atributos) de objetos.
OMG IDL não é linguagem de programação;
A especificação CORBA provê mapeamentos deIDL para linguagens orientadas e não orientadasa objetos (C, C++, Java, etc.).
(c) FEEC/UNICAMP 159
OMG IDL: Compiladores
Compiladores IDL traduzem as interfaces IDL em construções de uma linguagem alvo (Java, C++, etc.), bem como geram stubs e skeletons para clientes e servidores que utilizam e disponibilizam a interface.
Dependendo da linguagem alvo, compiladores IDL podem gerar tambem código auxiliar para a manipulação de tipos e passagem de parâmetros.
(c) FEEC/UNICAMP 160
IDL: Estrutura de uma Interface
Módulo
Definições (tipos complexos, exceções)
Operações
Atributos
Interface
Operações
Atributos
Interface
(c) FEEC/UNICAMP 161
IDL: Tipos Básicos
Ponto Flutuante: • float (IEEE 32 bits)• double (IEEE 32 bits)
Inteiros:• long: -231 ... +231 -1• unsigned long: 0 ... +232 -1• long long: -263 ... +263 -1• unsigned long long: 0 ... +264
• short: -215 ... +215 -1• unsigned short: 0 ... +216 -1
Nota: IDL não define inteiros !
Outros Tipos:• boolean: TRUE ou FALSE• char: 8 bits (usualmente ASCII)• octet: 8 bits (opaco)• any: armazena qualquer tipo IDL
(c) FEEC/UNICAMP 162
IDL: Tipos Complexos
Enumerações:• um conjunto de possíveis valores
Exemplo:enum moeda {real, dolar, euro, peso};moeda.real, moeda.dolar, moeda.iene
Estruturas:• um conjunto de tipos (básicos ou complexos) "empacotados".
Exemplo:struct cliente { string nome; long idade;};
(c) FEEC/UNICAMP 163
IDL: Tipos Complexos (cont.)
Uniões:• contruções capazes de armazenar um tipo IDL dentre um conjunto de tipos declarados.
Exemplo:enum formato {formatoString, formatoDigital};struct DataStruct { short dia; short mes; short ano; }; union Data switch (formato) { case formatoString: string dataString; case formatoDigital: long dataDigital; default: DataStruct dataStruct; };
(c) FEEC/UNICAMP 164
IDL: Tipos Complexos (cont.)
Strings:• armazenam uma sequência de caracteres ASCII com tamanho máximo especificado (bounded) ou não (unbounded).
Exemplos:string<30> cliente; // maximo 30 caracteresstring cliente; // tamanho ilimitado
(c) FEEC/UNICAMP 165
IDL: Tipos Complexos (cont.)
Seqüências:• armazenam uma seqüência de um mesmo tipo IDL com tamanho máximo especificado (bounded) ou não (unbounded).
Exemplos:sequence<string, 10> nomes; // máximo 10 elementossequence<string> nomes;sequence<DataStruct> vencimentos;
(c) FEEC/UNICAMP 166
IDL: Tipos Complexos (cont.)
Arrays:• armazenam um mesmo tipo IDL em uma estrutura multi-dimensional.
Exemplos:DataStruct vencimentos[16];float Z[50][50];
(c) FEEC/UNICAMP 167
IDL: Tipos Complexos (cont.)
Tipo Fixo:• permite representar um número em duas partes: valor e escala (posição do ponto decimal).
Exemplos:fixed<6,2> preco; // (-/+)9999.99 fixed<4,3> taxaDolar; // (-/+)9.999
(c) FEEC/UNICAMP 168
IDL: Tipos Complexos (cont.)
Constantes:• permite associar valores a um identificador.
Exemplos:const float pi = 3.1415926535;const string palmeiras = "alviverde imponente";
(c) FEEC/UNICAMP 169
IDL: Tipos Complexos (cont.)
Typedefs:• permitem definir nomes para tipos complexos.
Exemplos:typedef sequence<DataStruct> Datas;Datas vencimentos;typedef long integer;integer dataDigital;
(c) FEEC/UNICAMP 170
IDL: Tipos Complexos (cont.)
Tipo Any:• permite armazenar um valor pertencente a qualquer tipo IDL (simples ou complexo), inclusive outro tipo any.
O mapeamento de IDL para linguagens alvo deve prover mecanismos para:• inserção de valores em tipos any;• extração de valores armazenados em tipos any;• 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 171
IDL: Exceções
Operações nas interfaces IDL podem lançar exceções. Exceções são declaradas em IDL da seguinte forma:
exception <nome> { parâmetros};
Exemplos:exception operationFailed { string reason; short errorCode; }; exception noFunds {};
(c) FEEC/UNICAMP 172
IDL: Interfaces
Interfaces são comumente definidas no escopo de um módulo (podem também estar desassociadas de um módulo). Interfaces são definidas em IDL da seguinte forma:
interface <nome> { atributos operações};
Exemplo:interface Account { void deposit (in long amount); void withdraw(in long amount) raises {noFunds, operationFailed}; long balance();};
(c) FEEC/UNICAMP 173
IDL: Atributos de Interfaces
Atributos são variáveis associadas às interfaces (similares a atributos públicos de classes em OO). Atributos podem ser "readonly" ou "read-write", sendo definidos em IDL da seguinte forma:
<readonly> attribute <nome>;
Exemplo:interface Account { readonly attribute string customerName; readonly attribute sequence<octet> number; ...};
Nota: o compilador IDL gera métodos get e set para operação com atributos.
(c) FEEC/UNICAMP 174
IDL: Operações
Operações são definidas no escopo de uma interface IDL da seguinte forma:
<tipo> <nome> (<indireção> <tipo> parâmetro, ...) raises {E1, ... En};
Exemplos:void withdraw(in long amount) raises {noFunds, operationFailed};long balance();
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.
(c) FEEC/UNICAMP 175
IDL: Parâmetros 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:• in: o parâmetro é de entrada, isto é, passado do cliente para o servidor. Seu valor permanece inalterado após o retorno da operação.• out: o parâmetro é de saída, isto é, passado do servidor para o cliente. Seu valor comumente se altera após o retorno da operação.• inout: o parâmetro é de entrada/saída, isto é, passado nos dois sentidos. Seu valor comumente se altera após o retorno da operação.
Nota: parâmetros com valor NULL são proibidos !
(c) FEEC/UNICAMP 176
IDL: Retorno de Operações
Operações podem retornar o tipo void ou qualquer tipo IDL (básico ou complexo). Operações em CORBA são sempre síncronas (mesmo retornando void).
Operações assíncronas podem ser definidas com a palavra-chave oneway. Neste caso, devem retornar void e não definir exceções. Exemplo:
oneway void deposit();
(c) FEEC/UNICAMP 177
IDL: Interfaces e Tipos Complexos
Ao declarar uma interface em IDL, está-se declarando também um novo tipo complexo. Este tipo pode ser utilizado em parâmetros e retornos de operações. Exemplo:
interface Account { ...};
interface AccountFactory { Account makeAccount(in string customerName, in sequence<octet> accountNumber);};
Nota: makeAccount retorna uma referência para um objeto distribuído que implementa a interface Account.
(c) FEEC/UNICAMP 178
IDL: Definições Postergadas
É comum referenciar uma interface antes da mesma ser definida. IDL permite postergar a definição de interface declarando-se apenas o seu nome. Exemplo:
interface A;
interface B { void op1 (in A p1, ...); ...};
interface A { void op2 (in B p1, ...); ...};
(c) FEEC/UNICAMP 179
IDL: Herança de Interfaces
IDL permite herança simples e múltipla de interfaces.
interface D : A,B,C {...};
Exemplo:
interface SavingAccount : Account { readonly attribute float interestRate; float computeInterest();};
(c) FEEC/UNICAMP 180
Mapeamento IDL-Java
IDL Javamodule package boolean boolean char char octet byte string java.lang.String short, unsigned short short long, unsigned long int long long, unsigned long long long float float double double fixed java.math.BigDecimal
(c) FEEC/UNICAMP 181
Mapeamento IDL-Java
IDL Javaenum, struct, union class sequence, array array interface interface, helper & holder classes constant (fora de uma interface) public interface constant (em uma interface) fields na interface Java exception class any org.omg.CORBA.Any typedef helper classes readonly attribute accessor method readwrite attribute accessor and modifer methods operação método
(c) FEEC/UNICAMP 182
Parâmetros out e inout em Java
Em linguagens que suportam ponteiros (como C++), parâmetros out e inout são passados por referência quando mapeados para a linguagem alvo. Em Java, todo parâmetro possui uma classe Holder associada. O pacote org.omg.CORBA define as classes holder para os tipos básicos, enquanto o compilador IDL gera as classes holder para os tipos complexos. Portanto:• para um tipo qualquer X existe a classe XHolder;• a classes XHolder possui um atributo público do tipo X denominado value;• este atributo contém o valor a ser passado para o servidor (inout), bem como tem o seu valor alterado no retorno da operação.
(c) FEEC/UNICAMP 183
Parâmetros out e inout em Java (cont.)
Exemplo:
// IDLinterface Account { ... void withdraw(inout long amount);};
// Java public interface AccountOperations { ... void withdraw(intHolder amount);};
// JavaintHolder amt = new IntHolder();amt.value = 10000;acc.withdraw(amt);System.out.println("Amount: " + amt.value);
(c) FEEC/UNICAMP 184
Classes Helper
Tal como classes holder, cada tipo IDL X possui uma classe XHelper associada quando mapeado para Java. Classes helper oferecem três funcionalidades (via métodos estáticos): • inserção do tipo em um tipo any: void insert(org.omg.CORBA.Any a, X that);
• extração do tipo armazenado em um tipo any: X extract(org.omg.CORBA.Any a);
• criação de stubs a partir da referência do objeto remoto: X narrow(org.omg.CORBA.Object obj);
(c) FEEC/UNICAMP 185
Mapeamento IDL-Java: Exemplo
Account.idl
Compilador IDL
InterfaceAccount
InterfaceAccountOperations
classAccountHolder
classAccountHelper
class_AccountStub
classAccountPOA
(c) FEEC/UNICAMP 186
Exemplo: Account.idl
interface Account { exception LimitExceeded{string reason;};
void deposit( in long long arg0 ); void withdraw( in long long arg0 ) raises (LimitExceeded); long long balance( ); };
(c) FEEC/UNICAMP 187
Exemplo: AccountOpeations.java
public interface AccountOperations { void deposit (long arg0); void withdraw (long arg0) throws AccountPackage.LimitExceeded; long balance ();} // interface AccountOperations
(c) FEEC/UNICAMP 188
Exemplo: Account.java
public interface Account extends AccountOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity {}
(c) FEEC/UNICAMP 189
Exemplo: AccountHolder.java
public final class AccountHolder implements org.omg.CORBA.portable.Streamable{ public Account value = null;
public AccountHolder () {}
public AccountHolder (Account initialValue) { value = initialValue; }...}
(c) FEEC/UNICAMP 190
Exemplo: AccountHelper.java
abstract public class AccountHelper{private static String _id = "IDL:Account:1.0"
public static void insert (org.omg.CORBA.Any a, Account that) { ... }
public static Account extract (org.omg.CORBA.Any a) { ... }
public static Account narrow (org.omg.CORBA.Object obj) { .... }
public static String id () { return _id;}}
(c) FEEC/UNICAMP 191
Exemplo LimitExceeded.java
package AccountPackage;
public final class LimitExceeded extends org.omg.CORBA.UserException{ public String reason = null;
public LimitExceeded () { super(LimitExceededHelper.id()); } // ctor
public LimitExceeded (String _reason) { super(LimitExceededHelper.id()); reason = _reason; } // ctor
(c) FEEC/UNICAMP 192
IDL: Passagem de Objetos por Valor
CORBA, por ser um padrão neutro, não suporta passagem de objetos nas invocações de métodos remotos. Recentemente, o OMG introduziu o padrão denominado "Objeto por Valor" (Object by Value - OBV).
OBV permite:• definir um objeto em IDL (estado + métodos);• utilizar este objeto como parâmetro ou retorno de invocações, passando-o por valor.
(c) FEEC/UNICAMP 193
IDL: OBV
Mas:• e se o cliente e servidor forem escritos em diferentes linguagens de programação (que eventualmente não suportam o conceito de objeto, como C, Fortran, etc.) ?• como objetos são serializados / de-serializados ?
Resposta: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 respectivas linguagens de programação.
(c) FEEC/UNICAMP 194
IDL: OBV (cont.)
Compilador IDL
classesHelper,Holder
ObjetoJava
Implementaçãodo Objeto
DefaultFactory
ValueFactory
estadométodos
construtor
valuetype
(c) FEEC/UNICAMP 195
IDL: Valuetypes
// "objeto" a ser passado por valorvaluetype Empregado {
// definicao do estado public string nome; public string cargo; public float idade; public long salario;
// metodos - pode haver varios long computaSalario();
// construtor factory init(in string n, in string c, in float i);};
(c) FEEC/UNICAMP 196
IDL: Uso de Valuetypes
// interface que utiliza o "objeto"interface RH Empregado obtemEmpregado(in string nome); void adicionaEmpregado(in Empregado emp); void removeEmpregado(in Empregado emp);};
(c) FEEC/UNICAMP 197
IDL: Implementação de Valuetypes
import org.omg.CORBA.*;
public class EmpregadoImpl extends Empregado {
// construtores // conforme definido na IDL (facory init) public EmpregadoImpl(String n, String c, float i) {
this.nome = new String(n);this.cargo = new String(c);this.idade = i;this.salario = computaSalario(); // <<< operacao local
}
(c) FEEC/UNICAMP 198
IDL: Implementação de Valuetypes (cont.)
// construtor vazio tambem é necessario public EmpregadoImpl() {
this.nome = new String("");this.cargo = new String("");this.idade = 0;this.salario = 0;
}
public int computaSalario () {if(cargo.equals("gerente")) return(8000);return(3000);
}}
(c) FEEC/UNICAMP 199
IDL: Valuetypes - lado cliente
// creia fabrica de Empregados (local) EmpregadoDefaultFactory fact = new EmpregadoDefaultFactory(); Empregado e = fact.init("Jose", "gerente", (float)43.0);
rh.adicionaEmpregado(e);
Empregado e1 = rh.obtemEmpregado("Joao"); System.out.println("Empregado obtido: " + e1.nome +
" - cargo: " + e1.cargo + " - idade: " + e1.idade);
System.out.println("O salario de " + e1.nome + " e' " + e1.computaSalario()); // <<< chamada local !!
(c) FEEC/UNICAMP 200
IDL: Valutypes - lado servidor
import org.omg.CORBA.*;import java.util.*;
public class RHServant extends RHPOA implements RHOperations {
EmpregadoDefaultFactory the_factory = null; Hashtable empregados = null; float massaSalarial = 0;
public RHServant() {// cria fabrica e hashtablethe_factory = new EmpregadoDefaultFactory();empregados = new Hashtable();
}
(c) FEEC/UNICAMP 201
IDL: Valutypes - lado servidor (cont.)
public Empregado obtemEmpregado (String nome) { Empregado e = (Empregado)empregados.get(nome); if(e == null) e = the_factory.init("", "", (float)0.0); return e; }
public void adicionaEmpregado (Empregado emp) { Empregado e = the_factory.init(emp.nome, emp.cargo, emp.idade); massaSalarial += emp.computaSalario(); // <<< chamada local ! empregados.put(emp.nome, e); }
public void removeEmpregado (Empregado emp) { if(empregados.remove(emp.nome) != null) massaSalarial -= emp.computaSalario(); // <<< chamada local ! }}
(c) FEEC/UNICAMP 202
CORBA: Basic Object Adapter (BOA)
Objetivo: instanciar (criar) servidores e controlar aexecução de métodos.
O BOA identifica o código dos objetos servidoresinteragindo com o Repositório de Implementação.
Usualmente, o BOA provê três tipos de instanciaçãode servidores:
• compartilhada;• não compartilhada;• por método.
(c) FEEC/UNICAMP 203
CORBA: BOA
compartilhada não compartilhada por método
método processo
M1
M2
M3
M1
M2
M1
M2
M3
M1
M2
M3
(c) FEEC/UNICAMP 204
CORBA: BOA
A tendência é utilizar a instanciação por processoe servidores multitheaded (para cada evocaçãoo servidor cria uma thread para processá-la).
O BOA implementa também funções elementaresde segurança (Ex: verificação se um cliente possuipermissão para instanciar um servidor) via atributos do sistema de arquivos.
Pode-se implementar diferentes adaptadores de objetos em prejuizo da portabilidade.
(c) FEEC/UNICAMP 205
Adaptador de Objeto Portável (POA)
POA (Portable Object Adapter) é uma parte importante da arquitetura CORBA que trata do controle dos objetos que implementam interfaces remotas (objetos servants). POA vem eliminar muitas das deficiências do BOA (Basic Object Adapter), principalmente sua dependência de implemen-tação.
POA permite esquemas flexíveis de controle através da combinação de políticas de controle do POA com diferentes modos de ativação de objetos servants.
(c) FEEC/UNICAMP 206
POA: Stubs e Skeletons Portáveis
stuboutin
IIOP
get n m
result = get(n, m)
ORB ORB
skeletonout in
result
in = invoke(out)
invoke
out = invoke(”get”,in)
invoke
cliente servant
result = get(n, m)value = gridRef.get(x,y)
(_ImplBase)
(_Stub)
(c) FEEC/UNICAMP 207
POA: Arquitetura
Um POA é sempre criado a partir de um POA pai (exceto o Root POA) através do método create_POA invocado no POA pai.
POA Raiz é obtido através do método resolve_initial_references("RootPOA") disponibilizado pelo ORB.
POA Raiz
POA P1 POA P2
POA P3
(c) FEEC/UNICAMP 208
POA: Arquitetura
Mapa de Objetos Ativos
Object ID
Object ID
Object ID
Object ID
Servant Manager
Ser
van
ts(i
mp
lem
enta
ções
)
Servant Manager(default)
Po
lític
as
POA ManagerServidor CORBA
códigosuprido pelodesenvolvedor
Definidas pelodesenvolvedor
(c) FEEC/UNICAMP 209
POA: Operação Típica
_invoke
OID
skeleton
parâmetros
_invoke(M, ...)
servant
upcall
POA
M(...)mapa objs.ativos
_invoke
OID
skeleton
parâmetros
_invoke(M, ...)
servant
upcall
POA
M(...)mapa objs.ativos
(c) FEEC/UNICAMP 210
POA: Políticas
POA define 7 políticas:
1. Atribuição de OIDs: USER_ID; SYSTEM_ID (default)
2. Retenção de Servants: RETAIN (servants são retidos no mapa de objetos ativos); NON_RETAIN (não existe mapa de objetos ativos).
3. Processamento de Requisição: USE_ACTIVE_OBJECT_MAP_ONLY (default); USE_DEFAULT_SERVANT; USE_SERVANT_MANAGER.
4. Ativação Implícita: IMPLICIT_ACTIVATION (default) - atribui um OID e o adiciona no mapa de objetos ativos quando necessário (não ativa o servant !); NO_IMPLICIT_ACTIVATION.
(c) FEEC/UNICAMP 211
POA: Políticas (cont.)
5. Unicidade de OIDs: UNIQUE_ID (default) - cada servant possui um único ID; MULTIPLE_ID - um servant pode possui mais de um ID.
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 ORB e não para o POA que a criou).
(c) FEEC/UNICAMP 212
POA: Políticas (cont.)
7. Política de Thread: ORB_CTRL_THREAD (default) - o POA mantém um pool de threads para atender as requisições; SINGLE_THREAD_MODEL - o pool possui apenas 1 thread; MAIN_THREAD_MODEL - não há threads, exceto a thread "main".
POA
ORB
POA
ORB
POA
ORB
POA
ORBORB
POA
ORBORB
POA
ORBORB
(c) FEEC/UNICAMP 213
POA: Gerenciador de Servants
Existem dois tipos de gerenciador de servants (servant manager) cuja utilização pelo POA se dá através da política USE_SERVANT_MANAGER:
• Ativador de Servants (Servant Activator): utilizado em conjunto com 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 o OID não está presente no mapa de objetos ativos;
• Localizador de Servants (Servant Locator): utilizado em conjunto com a política NON_RETAIN, disponibiliza ao POA um método que retorna um servant ativado dado um OID. O POA invoca esta operação para cada requisição que recebe do ORB.
(c) FEEC/UNICAMP 214
POA: Gerenciador de POA
O Gerenciador de POA (POA Manager) disponibiliza um conjunto de métodos que permite colocar o POA um um dos quatro estados abaixo:
• espera: suspende temporariamente o processamento das requisições, enfileirando-as;• ativo: processa normalmente as requisições;• descarte: descarta requisições;• inativo: estado pré-destruição (completa processamento das requisições pendentes e descarta novas requisições).
(c) FEEC/UNICAMP 215
POA: Indentificadores de Objeto (OID)
OIDs podem ser atribuidos pelo POA (mais comum) ou pela aplicação. OIDs é uma sequência de bytes presente no IOR que identifica o servant. IORs são criados pelo POA via métodos create_reference (POA atribui OID) ou create_reference_with_id (aplicação atribui OID).
Quando atribuído pela aplicação, em geral o OID é uma chave de acesso para o estado do servant armazenado em uma base de dados. Isto permite a criação de servidores persistentes.
(c) FEEC/UNICAMP 216
CORBA: Static Invocation Interface (SII)
SII é a forma mais simples do cliente invocarum método num servidor.
SII requer que todas as interfaces de servidoressejam conhecidas em tempo de compilação(portanto, SII é type-safe).
(c) FEEC/UNICAMP 217
CORBA: SII
cliente
ORB
POAIDL skeletonIDL stub
servidor
proxy
(c) FEEC/UNICAMP 218
CORBA: Dynamic Invocation Interface (DII)
DII é um conjunto de serviços que permitem a clientes:
• Verificar a existência de interfaces no Repositório de Interfaces;
• Descobrir os parâmetros (tipos) e métodos (protótipos) de determinada interface;
• Preparar passo-a-passo uma evocação para um servidor que implementa esta interface.
(c) FEEC/UNICAMP 219
CORBA: DSI
DSI (Dynamic Skeleton Interface) é equivalente ao DII para o lado servidor. DSI permite a um servidor inspecionar uma invocação antes de seu processamento, obtendo o nome do método e respectivos parâmetros. DSI permite também ao servidor retornar um valor para o cliente.
Nota: O uso de DII no lado cliente não implica no uso de DSI no lado servidor e vice-versa.
(c) FEEC/UNICAMP 220
CORBA: Repositórios de Interfaces e Implementação
Objetivo: armazenar de forma persistente as interfaces IDL e as implementações de servidores.
Estes repositórios podem ser implementados diretamente no sistema de arquivo nativo do sistema operacional ou através de uma base de dados (relacional ou OO).
As implementações CORBA provêem aplicativos para a manutenção destes repositórios.
(c) FEEC/UNICAMP 221
CORBA: CORBAservices
CORBAservices define arquiteturas e interfaces (não implementações !) para os seguintes serviços:
• nomes (diretório);• eventos;• ciclo de vida;• segurança;• transações;• time;• persistência;
dentre muitos outros !
(c) FEEC/UNICAMP 222
CORBAservices: Nomes
O serviço de nomes especifica interfaces IDL para:• criar contextos para definições de nomes;• associar (bind) um nome a um objeto (usualmente um servant);• pesquisar um nome (e obter o objeto associado);• navegar pelo diretório de nomes.
servantCORBA
interfaces IDLdo serviço
servidor de nomesdiretório de nomes(persistente ou transiente)
(c) FEEC/UNICAMP 223
CORBAServices: Ciclo de Vida
O serviço de propriedades proporciona operações que permitem criar, destruir, copiar objetos.
GenericFactory
FactoryFinder
find_factories
create_object
servantCORBA
servantCORBA
servantCORBA
copymove
remove
LifeCycleObject
CORBA.Object obj = GenericFactory.CreateObject(pars);
encontra
cria
(c) FEEC/UNICAMP 224
CORBAServices: Propriedades
O serviço de propriedades proporciona operações que permitem definir pares atributo-valor (propriedades) e
associa-los a qualquer entidade da aplicação.
PropertySet
PropertySetFactory
create_propertysetcreate_initial_propertyset
create_constrained_propertyset
define_propertyget_property
delete_property
......
servantCORBA
servantCORBA
servidor de propriedades
(c) FEEC/UNICAMP 225
CORBAServices: Eventos
O serviço de eventos prove um mecanismo de notificação segundo os modelos push e pull.
obtain_push_consumerobtain_push_supplier
connect_push_consumerconnect_push_supplier
canal de eventos
push
push supplier
push consumersservidor de eventos
pushevento
disconnect_push_supplier
(c) FEEC/UNICAMP 226
CORBAServices: Object Transaction Service
OTS (Object Transaction Service) implementa um serviço de transações aberto baseado no protocolo 2-phase commit.
servantCORBA
interfaces IDLdo serviço- begin - commit - abort, ...
servidor OTS
base de dados(Oracle, Sybase, etc.)interface XA
(X/Open)
permite a integração comprodutos que implementamesta interface
(c) FEEC/UNICAMP 227
CORBAservices: Trader
Trader, conceito introduzido no modelo ODP, foi padronizado pelo OMG. Trader é um serviço de nomes mais sofisticado que permite clientes encontrar servidores que melhor atendam suas necessidades. Cenário típico de utilização do trader é dado abaixo.
1. exporta capacidades do servidor (desempenho, custo, etc.)2. importa requisitos (desempenho mínimo, custo máximo, etc.)3. retorna IOR do servidor4. interage com o servidor (provavelmente via DII)
ORB
Trader servidorCORBA
clienteCORBA
2 34 1
(c) FEEC/UNICAMP 228
CORBA: Produtos
• ORBIX (IONA Technologies Ltd.)• VisiBroker (Borland)• ORBacus (Object Oriented Concepts / IONA)• CORBAplus (Expersoft)• Nouveau (Rogue Wave)• vários outros ...
Implementações robustas de domínio público:Java IDL (parte da plataforma Java 2), MICO (C++), JacORB (Java), TAO (C++).
(c) FEEC/UNICAMP 229
CORBA: Produtos
Muitos produtos em diferentes domínios possuem implementações CORBA embutidas para fins de interoperabilidade com outros produtos compatível com CORBA. Exemplos:
• Plataforma Jambala (Ericsson): utilizada em telefonia celular;• OpenView (HP): produto para gerência de redes e TMN;• Jaguar (Sybase): middleware para OLTP.
(c) FEEC/UNICAMP 230
CORBA: Produtos
Produtos CORBA tradicionais como ORBIX e VisiBroker foram incorporados em Plataformas de Desenvolvimento (Application Server Platforms). Estas plataformas, além de permitirem desenvolvimento em CORBA, suportam ainda desenvolvimento em J2EE/EJB, .NET, XML/SOAP, etc., bem como alguma interoperabilidade entre estas tecnologias.
(c) FEEC/UNICAMP 231
ORBIX
Orbix, da Iona Technologies, é uma família de produtos CORBA. Orbix possui compiladores IDL para várias linguagens de programação, bem como ORBs para uma grande variedade de plataformas. Por exemplo, é possível desenvolver um servidor CORBA em COBOL e executá-lo em mainframe IBM OS/390.
(c) FEEC/UNICAMP 232
ORBIX: Disponibilidade
Orbix possui versões para desenvolvimento em C, C++, Java, COBOL, PL/1, VB para as seguintes plataformas:
• Microsoft Windows NT/2000/XP; • Sun Solaris;• Linux;• HP-UX• Silicon Graphics IRIX;• IBM AIX;• IBM OS/390 Mainframe;• Digital/Compaq OpenVMS.
(c) FEEC/UNICAMP 233
geradorde código
ORBIX: Compilador IDL
utilitários
parserIDL
árvore deparsingarquivo IDL
stubs, skeletons,server templatecompilador IDL
aplicação-exemploconversão IDL - HTMLetc.
Code Generation Toolkit
(c) FEEC/UNICAMP 234
ORBIX: ORB
No Orbix o Object Request Broker (ORB) consiste de dois componentes:
1. Uma interface de programação (API) que provê funções 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 e gerencia o repositório de implementação e ativação de servidores.
(c) FEEC/UNICAMP 235
ORBIX: ORB
código da aplicação (cliente)
código do stub(gerado pelo
compilador IDL)
código da aplicação (servidor)
código do skeleton(gerado pelo
compilador IDL)requisição IIOP
API API
ORBIX daemon(orbixd)
ORB (lib)
ORB (lib)
instancia servidor
Rep.Impl.
busca de servidor
(c) FEEC/UNICAMP 236
ORBIX: ORB
Orbix ORB possui as seguintes características básicas:
• suporte para DII (Dynamic Invocation Interface);• suporte para BOA e POA (Basic/Portable Object Adapter);• suporte para DSI (Dynamic Skeleton Interface). Orbix ORB provê ainda uma interface para operações de manipulação de typos (Any, NVList, ...), disponibilização de servidores, busca de serviços disponíveis (nomes, eventos, ...), dentre muitas outras.
(c) FEEC/UNICAMP 237
ORBIX: Repositórios
Orbix dispõe de repositórios de interface e de
implementação com a seguinte arquitetura:
sistema de arquivosnativo da máquina
utilitários demanutenção
e gerência
registros
repositório
putitcatitlstitrmit...
(c) FEEC/UNICAMP 238
ORBIX: Integração com MS-COM
ORBIX permite que servidores CORBA se apresentem a clientes
como objetos COM (Component Object Model - padrão Microsoft).
OBS: MIDL (Microsoft IDL) define tipos COM
cliente COM COM IIOP servidorCORBA
Bridge
provê mapeamentobidirecional entreMIDL e OMG IDL
repositóriode tipos(COM)
repositóriode interfaces
(CORBA)
(c) FEEC/UNICAMP 239
ORBIX: Serviços CORBA
Orbix implementa os seguintes serviços CORBA:
• serviço de nomes;• serviço de transações;• serviço de trading;• serviço de eventos;• serviço de notificação.
(c) FEEC/UNICAMP 240
VisiBroker
VisiBroker tem sua origem no ORBeline, produto da PostModern que em 1996 fundiu-se com a Visigenic, mudando o nome do produto para VisiBroker.
A Visigenic foi adquirida pela Borland que manteve o nome do produto, hoje na versão 4.
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 241
VisiBroker: Disponibilidade
VisiBroker possui versões para desenvolvimento em C++ e Java para as seguintes plataformas:
• Microsoft Windows ; • Sun Solaris;• Linux;• HP-UX;• IBM AIX;• Digital/Compaq UNIX;• Silicon Graphics IRIX;• IBM OS/390 Mainframe.
(c) FEEC/UNICAMP 242
VisiBroker: Características
VisiBroker possui as seguintes características básicas:
• repositórios de interface e implementação;• suporte para DII (Dynamic Invocation Interface);• suporte para BOA e POA (Basic/Portable Object Adapter);• suporte para DSI (Dynamic Skeleton Interface);• suporte a multithreading (vários modelos de threading);• suporte a Object-by-Value (OBV);• Filtros (Interceptors).
(c) FEEC/UNICAMP 243
VisiBroker X Orbix
VisiBroker é muito similar ao Orbix, sendo talvez o seu maior concorrente. Algumas diferenças:
• possui dois daemons: SmartAgent e OAD (Object Activation Daemon):
– SmartAgent: provê serviços de nome e diretório que permite localizar OADs. A localização pode levar em conta balanceamento de carga e tolerância a falhas;– OAD: utilizado para instanciar servidores (similar ao orbixd).
• serviço de nomes e eventos (OMG) incorporados.
(c) FEEC/UNICAMP 244
VisiBroker: SmartAgent & OAD
SmartAgent
SmartAgent
SmartAgent
Serviço Distribuído de Nomes + Diretório
Algoritmos deBal. de cargaTol. a Falhas
OAD
Rep. Impl.
OAD
Rep. Impl.
cliente
1. consulta2. encontra servidor
3. retorna ref. OAD
4. bind5. acessa impl.
6. inst. servidor
(c) FEEC/UNICAMP 245
VisiBroker: Componentes Adicionais
A Imprise oferece os seguintes componentes adicionais para o VisiBroker:
• VisiSecure: serviço de segurança do OMG;• VisiTransact: serviço de transação do OMG;• VisiNotify: serviço de notoficação do OMG.
• adicionalmente, os seguintes CORBAservices são oferecidos pela Prism Technologies para o VisiBroker: Trading, Notification, LifeCycle, Property, Collection, Concurrency, Relationship, e Time Services.
(c) FEEC/UNICAMP 246
Java IDL
A plataforma Java dispõe de uma implementação CORBA denominada Java IDL. Esta implementação, compatível com a versão CORBA 2.3, vem sendo aprimorada desde a sua introdução na versão 1.2 e dispõe atualmente de:
• um compilador idl (idlj);• um conjunto de pacotes (org.omg.CORBA, ...);• um daemon de ativação / servidor de nomes (orbd);• um aplicativo para registro de servidores no repositório de implementação (servertool).
(c) FEEC/UNICAMP 247
Java IDL
Java IDL suporta:
• Adaptador de Objeto Portável (POA);• servidores persistentes;• passagem de objeto por valor (Object by Value);• Intercerceptadores Portáveis (suporte parcial).
Java IDL não suporta:
• segurança (IIOP/SSL, por exemplo);• repositório de interfaces;• passagem de contexto nas invocações (Current);• outros serviços CORBA.
(c) FEEC/UNICAMP 248
CORBA x DCE
A favor do DCE:
• Os padrão DCE está estacionado, enquanto CORBA está em constante evolução;• Implementações DCE interoperam por princípio;• DCE trata segurança em todos os níveis;• DCE IDL suporta ponteiros e parâmetros de tamanho arbitrário (pipes);• DCE suporta o conceito de versão (de servidores).
(c) FEEC/UNICAMP 249
CORBA x DCE
A favor do CORBA:
• CORBA é orientado a objeto (enquanto DCE é orientado a procedimento);• OMG IDL permite herança e tipo any, além de mapear para várias linguagens de programação;• CORBA permite late-binding via DII;• CORBA especifica uma vasta gama de serviços (poucos destes disponíveis atualmente !);• CORBA define repositórios de interfaces e implemenação;• CORBA vem despertando mais interesse que o DCE.
(c) FEEC/UNICAMP 250
Desenvolvimento em CORBA
Onde utilizar CORBA ?
CORBA é uma arquitetura para sistemas distribuídos, tipicamente utilizada em:
• novos desenvolvimentos;• integração de produtos e sistemas “legados”;• hooks e gateways de interoperabilidade.
(c) FEEC/UNICAMP 251
Novos Desenvolvimentos em CORBA
A utilização de CORBA em novos desenvolvimentos se justifica devido a:
• ampla aceitação por parte da indústria;• maturidade dos produtos CORBA disponíveis no mercado;• neutralidade em termos de plataformas e linguagens de programação;• simplicidade de uso quando comparado a outras tecnologias (ex: DCOM e DCE);• integração natural com tecnologias relacionadas à Internet (applets, browsers, etc.).
(c) FEEC/UNICAMP 252
Integração via CORBA
CORBA é uma tecnologia adequada para a integração de sistemas “legados” (exemplo: controle de estoques desen-
volvido em COBOL para IBM OS/390 utilizando DB2).
Nestes casos, a interação com o sistema legado pode se dar através de um wrapper dividido em duas partes:1. parte responsável pela interação com um ORB, por exemplo, através de stub gerado por compilador IDL;2. parte responsável pela interação com o sistema legado através de, por exemplo, interfaces de programação (APIs).
(c) FEEC/UNICAMP 253
Integração via CORBA
Exemplo:
Sistema Legado #1(COBOL / OS/390)
Sistema Legado #2(C++ / UNIX)
Sistema Legado #3(V.Basic / Windows)
wrapper #1 wrapper #2 wrapper #3
IDL > COBOL IDL > C++ COM-CORBA bridge
ORB #2 ORB #3ORB #1IIOP IIOP
(c) FEEC/UNICAMP 254
Hooks CORBA de Interoperabilidade
Hooks CORBA de interoperabilidade permitem adicionar funcionalidades externas a produtos. Exemplos:• Plataforma Jambala para telefonia celular (Ericsson)• Sistema de gerência de redes OpenView (HP)
ORB internoao produto
Produto Extensãoao Produto
IDL “exportada”pelo produto
IIOPORB Comercial
Hook CORBA deInteroperabilidade
(c) FEEC/UNICAMP 255
Gateways de Interoperabilidade
Gateways permitem sistemas baseados em CORBA interoperarem com sistemas baseados em outras arquiteturas e protocolos. Exemplo:
GerenteCORBA
IDL “exportada”pelo gateway
IIOPORB Comercial
AgenteSNMP
Domínio deGerência SNMP
Domínio deGerência
CORBA
ORB
GatewayIDL - SNMP
SNMP
(c) FEEC/UNICAMP 256
Microsoft DCOM
DCOM (Distributed Component Object Model) é uma generalização da tecnologia COM (ex-OLE) desenvolvida pela Microsoft para o “mundo Windows”. Portanto, OLE/COM/DCOM são soluções “fechadas”.
COM permite a comunicação entre aplicativos executando no mesmo processador. Portanto, COM é um mecanismo de comunicação inter-processos (IPC).
DCOM estende COM permitindo a comunicação entre aplicativos executando em diferentes processadores. Portanto, DCOM é um middleware.
Atualmente, DCOM está integrado nas plataformas COM+ e .NET.
(c) FEEC/UNICAMP 257
Microsoft DCOM
servidor COM
cliente COM
servidor DCOM
cliente DCOM
rede
cliente e servidor em diferentes (processos) mas no mesmo processador
cliente e servidor emdiferentes processadores
RPCIPC
(c) FEEC/UNICAMP 258
Microsoft DCOM
COM é neutro em termos de linguagem de programação. Por exemplo, um cliente escrito em Visual Basic pode interagir 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).
DCOM procura minimizar as diferenças em relação ao COM (transparência de distribuição), escondendo do desenvolvedor o fato de clientes e servidores estarem em processadores distintos.
DCOM utiliza um mecanismo de RPC (derivado do DCE !) para suporte à comunicação cliente/servidor.
(c) FEEC/UNICAMP 259
DCOM: Arquitetura
SCM segurança DCE RPC
protocolos de rede (TCP/IP)
hardware
SCM segurança DCE RPC
protocolos de rede (TCP/IP)
hardware
rede
instancia
proxy stubcliente DCOM servidor DCOM
cria instância(de servidor)
SCM: Service Control Manager (parte do Windows)
(c) FEEC/UNICAMP 260
DCOM: Objetos COM/DCOM
Objetos COM/DCOM derivam de uma classe base (coclass), definem uma interface com detrminado número de métodos, e podem ser agregados numa biblioteca (lib).
O objeto, sua interface e a lib a qual pertence são individidual- e globalmente identificados por um UUID (ou GUID) (Universally/Globally Unique IDentifier), uma sequência de 128 bits gerada por um aplicativo denominado guidgen.
guidgen leva em conta a data, hora, host ID, etc. para gerar um GUID.
classe(coclass)
interface
classe(coclass)
interface
classe(coclass)
interfacelib
(c) FEEC/UNICAMP 261
DCOM: MIDLimport "oaidl.idl";import "ocidl.idl";
[object, uuid(3C6E0346-479C-11D4-96B9-0090272BDBDA), dual helpstring("IAccountComObject Interface"), pointer_default(unique)]interface IAccountComObject : IDispatch { HRESULT deposit([in] unsigned long amount); HRESULT withdraw([in] unsigned long amount); HRESULT balance([out, retval] long *amount);};
[uuid(3C6E0339-479C-11D4-96B9-0090272BDBDA), version(1.0), helpstring("Account 1.0 Type Library")]library ACCOUNTLib { importlib("stdole32.tlb"); importlib("stdole2.tlb"); [uuid(3C6E0347-479C-11D4-96B9-0090272BDBDA), helpstring("AccountComObject Class")]coclass AccountComObject { [default] interface IAccountComObject; };};
(c) FEEC/UNICAMP 262
DCOM: Desenvolvimento
Desenvolver aplicações distribuídas em DCOM exige:
• experiência com o “mundo Windows”, principalmente com a tecnologia COM/COM+;
• um ambiente de desenvolvimento que contenha gerador de GUID (guidgen), compilador MIDL (midl), compilador da linguagem alvo, etc. Os ambientes Microsoft Visual C++, Basic e J++ contém estes aplicativos.
Nos ambientes Microsoft, clientes e servidores COM/DCOM são desenvolvidos a partir de um wizard (ATL COM AppWizard).
(c) FEEC/UNICAMP 263
DCOM: Servidores
Servidores DCOM podem ser instanciados de duas maneiras:
• por demanda, quando uma requisição para um objeto for gerada por um cliente;• de forma persistente, como um serviço do sistema operacional (Windows-NT apenas);
NOTA: o Register do Windows é empregado para mapear classes de objetos e suas interfaces (através de seus GUIDs) em servidores (programas executáveis). Funciona, portanto, como o repositório de implementação do CORBA.
NOTA: o SCM do Windows funciona para o DCOM como os daemons de ativação do CORBA (orbixd, OAD).
(c) FEEC/UNICAMP 264
CORBA x DCOM
A favor do CORBA:
• CORBA é uma arquitetura aberta, independente de plataforma ou fornecedor;• CORBA é mais aceito por fornecedores de software;• desenvolvimento em CORBA é mais simples que em DCOM;• CORBA se integra melhor com Java/Internet que DCOM;• CORBA é um middleware mais completo que DCOM;• CORBA permite late-binding via DII; • mercado de produtos CORBA bem superior ao mercado de produtos DCOM;• CORBA também opera em ambientes Windows.
(c) FEEC/UNICAMP 265
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.).