Transparências do curso (IA844)

INTRODUÇÃO ÀS
PLATAFORMAS DISTRIBUÍDAS
Introdução aos
Sistemas Distribuídos
Eleri Cardozo
FEEC/UNICAMP
http://www.fee.unicamp.br/~eleri
Julho de 2002
(c) FEEC/UNICAMP
1
Um sistema distribuído é um sistema computacional
com as seguintes propriedades:
Sistemas Abertos são sistemas implementados
segundo padrões abertos.
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.
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.
3
Sistemas Abertos: Uma Classificação
(c) FEEC/UNICAMP
4
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.
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
2
Sistemas Abertos
Sistemas Distribuídos: Definição
(c) FEEC/UNICAMP
(c) FEEC/UNICAMP
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.
5
(c) FEEC/UNICAMP
6
Arquiteturas de Referência
Arquiteturas
Uma arquitetura de referência é similar a um modelo
de referência, mas prescreve interfaces entre seus
componentes.
Exemplos: TINA, CORBAservices.
Uma arquitetura é similar a um modelo ou arquitetura
de referência, mas prescreve protocolos de interoperabilidade 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
e possibilidades de extensões. Estas lacunas tendem
a comprometer a interoperabilidade entre diferentes
implementações da arquitetura.
(c) FEEC/UNICAMP
Arquiteturas provêem interoperabilidade mínima entre
suas implementações.
7
Implementações de Referência
(c) FEEC/UNICAMP
8
Exemplo de Padrão Aberto: CORBA
Objetos de
Aplicação
CORBA
Facilities
(vertical)
CORBA
Facilities
(horizontal)
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.
O modelo de
referência OMA.
Implementações de referência garantem o maior
nível possível de interoperabilidade para implementações de sistemas abertos.
CORBA especifica o Object Request Broker do modelo OMA.
Interoperabilidade entre implementações CORBA é garantida
pela linguagem IDL e pelo protocolo IIOP.
(c) FEEC/UNICAMP
Object Request Broker (ORB)
9
(c) FEEC/UNICAMP
10
Sistemas Abertos: Conclusão
Exemplo de Padrão Aberto: CORBA
Sistemas abertos são fundamentais para:
• IDL e IIOP garantem que duas implementações
CORBA sempre irão interoperar no tocante a
invocação remota de métodos.
• 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.
• 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
Serviços CORBA
(CORBAservices)
11
(c) FEEC/UNICAMP
12
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
13
Agente
Telecomunicações
} Domínio de aplicação
APRESENTAÇÃO
SESSÃO
SESSÃO
TRANSPORTE
Um novo Modelo OSI: camada nível 8
contendo funções típicas dos vários
domínios de aplicação:Medicina,
Finanças, Telecomunicações, etc.
TRANSPORTE
REDE
REDE
ENLACE
ENLACE
FÍSICO
FÍSICO
(c) FEEC/UNICAMP
15
(c) FEEC/UNICAMP
16
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
SESSÃO
TRANSPORTE
REDE
Gerenciamento de Rede
APLICAÇÃO
APRESENTAÇÃO
ENLACE
}
Agente
Ex: funções típicas de
telecomunicações
APLICAÇÃO
APLICAÇÃO
Cliente
Finanças
Medicina
14
Conceito de Middleware e o Modelo OSI
Conceito de Middleware e o Modelo OSI
APRESENTAÇÃO
(c) FEEC/UNICAMP
Contexto das
Comunicações
APRESENTAÇÃO
A Camada de Transporte
é um divisor entre o
mundo das aplicações e o
mundo das comunicações
SESSÃO
TRANSPORTE
MIDDLEWARE
REDE
ENLACE
FÍSICO
FÍSICO
(c) FEEC/UNICAMP
17
(c) FEEC/UNICAMP
18
Conceito de Middleware e o Modelo OSI
Evolução em Middleware
Domínio da aplicação
agentes
APLICAÇÃO
componentes
APRESENTAÇÃO
objetos
distribuídos
chamada de
procedimento
remoto (RPC)
Necessidade de
Padronização do
Middleware
SESSÃO
troca de
mensagens
}
Sistema
Operacional
+
Hardware
Sistemas Heterogêneos!
1977
(c) FEEC/UNICAMP
Evolução do Conceito de Middleware
CPC-I
2007
20
tarefa 2
tarefa 1
Receive
Socket
Named Pipes
API independente do
transporte
send(M1)
send(M1)
tarefa 2
tarefa 1 receive(M2)
SNA
2002
(c) FEEC/UNICAMP
Aplicação
Send
TLI
1997
1992
1987
Troca de Mensagens: Semântica
Troca de Mensagens (primitivas SEND/RECEIVE)
Aplicação
1982
19
TCP/IP
IPX/SPX
NetBIOS
receive(M1)
receive(M2)
Pilhas de Transporte
bloqueio
NDIS
ODI
...
Token-ring
Ethernet
send(M2)
Drivers de Rede
Placas de Rede
ISDN
(c) FEEC/UNICAMP
21
(c) FEEC/UNICAMP
22
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
espaço do núcleo
CPC-I
Socket
Named Pipes
port (endpoint)
API
(socket)
buffer
sistema de
transporte
(TCP/IP)
API
(socket)
SNA
sistema de
transporte
(TCP/IP)
TCP/IP
IPX/SPX
NDIS
NetBIOS
ODI
LAN / WAN
Token-ring
(c) FEEC/UNICAMP
23
Ethernet
(c) FEEC/UNICAMP
ISDN
24
RPC: Implementação
RPC: Semântica
cliente
servidor
cliente
servidor
R = call P2(a1,a2)
cliente
call P2(a1,a2)
servidor
call P2(a1,a2)
1
4
5
dispatcher
empacota
desempacota
parâmetros resultado
P2 executa
P2
P3
P2
P2(a1,a2)
bloqueio
P1
retorno
8
P1
P3
2
retorno
desempacota
parâmetros
3
7
a2
API
(socket)
(c) FEEC/UNICAMP
25
Evolução do Conceito de Middleware
empacota
resultado
bibliotecas
RPC
6
a1 P2
resultado
API
(socket)
(c) FEEC/UNICAMP
26
Objetos: Constituição
Objetos Distribuídos
• O conceito de objetos surgiu para atender os requisitos
estado: define um conjunto de variáveis
internas que armazenam o estado
corrente do objeto
relacionados ao aumento na complexidade do desenvolvimento
de software
Reusabilidade
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
internos ao objeto
Barramento de Software
Interface Padrão
(c) FEEC/UNICAMP
27
Objetos: Regras de Interação
(c) FEEC/UNICAMP
Objetos: Conceitos Básicos
• toda a interação com um objeto se dá através da invocação de
seus métodos declarados como públicos;
Classificação: objetos são organizados em classes. Uma
classe define o comportamento dos objetos dela derivados.
• métodos declarados como privados só podem ser invocados
pelos demais métodos definidos pelo objeto;
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).
• 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
28
29
(c) FEEC/UNICAMP
30
Objetos: Conceitos Básicos
Objetos: Conceitos Básicos
classe
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.
encapsulamento
classe
relação
herança (especialização)
instanciação
estado
classe
Identidade: objetos possuem identidade única capaz de diferenciar
um objeto dos demais.
métodos
(c) FEEC/UNICAMP
M3
M1
interface
invocação de métodos
identidade
Polimorfismo: métodos de mesmo nome podem apresentar
diferentes comportamentos, dependendo do objeto que o
implementa.
M2
polimorfismo
31
Objetos Distribuídos
M2
(c) FEEC/UNICAMP
Objetos Distribuídos: Vantagens
Deve-se notar que as tecnologias de middleware procuram
acompanhar as tecnologias de desenvolvimento de software:
Objetos distribuídos apresentam as seguintes vantagens
sobre troca de mensagens e RPC:
• troca de mensagens: estende o paradigma de programação
não estruturada à programação de sistemas distribuídos
(programação distribuída);
• 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 autocontidas 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.
• 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
33
Objetos Distribuídos: Interação
(c) FEEC/UNICAMP
34
Interfaces Remotas
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).
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.
Estes padrões são oferecidos por uma infra-estrutura denominada
ORB (Object Request Broker). Por exemplo, RMI é o ORB nativo
da linguagem Java.
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
32
RMI, por ser uma solução puramente Java, utiliza interfaces Java
derivadas da interface Remote para definir interfaces remotas.
35
(c) FEEC/UNICAMP
36
Referência de Objetos
Objetos Distribuídos: Implementação
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.
ORB (biblioteca)
Descrição da(s)
Interface(s)
Compilador
(C++, Java, ...)
Compilador de
Interfaces
RMI utiliza as próprias instâncias das classes Java que
implementam interfaces remotas para identificar objetos
distribuídos.
Implementação
dos Servants
(C++, Java, ...)
Stubs / Skeletons
OBS: Uma referência pode ser persistente ou transiente.
servant
(c) FEEC/UNICAMP
37
Stubs e Skeletons
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
interface
remota
cliente
Stub
invocação local
M1
M2
M3
Rede
protocolo
de RPC
Skeleton
upcall
M1
M1
M2
M3
objeto
distribuído
(c) FEEC/UNICAMP
39
Binding
cliente
servidor
de nomes
3. invoke
(c) FEEC/UNICAMP
(c) FEEC/UNICAMP
40
Invocação Remota de Métodos
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.
2. lookup
38
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
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.
M1
(c) FEEC/UNICAMP
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.
1. bind/rebind
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.
objeto
distribuído
41
(c) FEEC/UNICAMP
42
Arquitetura de Distribuição
Middleware: Padrões
servidor
cliente
servant
Indústria
objeto
distribuído
Consórcios
Stub
Skeleton
Object Request Broker
Serviços
Nomes
Eventos
Segurança
(c) FEEC/UNICAMP
43
DCOM
(Microsoft)
RMI
(SUN)
DCE
(OSF)
EJB
(Sun)
CORBA
(OMG)
.NET
(Microsoft)
SOAP
(W3C)
OSI
ODP
ISO/ITU-T
TCP/IP
sockets
WWW
Internet
1977
1982
RPC
1987
1992
1997
2002
(c) FEEC/UNICAMP
44
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).
Plataforma Java
Linguagem Java
Máquina Virtual
APIs
(c) FEEC/UNICAMP
45
Plataforma Java 2: Arquitetura
Classes Java
Estendidas
Classes Java
Básicas
Máquina Virtual Java
A SUN Microsystems fornece três tipos de plataformas Java 2:
Suporte às
Aplicações
• 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;
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 entradasaída, interfaces gráficas de usuários, entre outras;
Interface de
Portabilidade
Adaptador
Browser
Adaptador
• Java 2 Platform, Enterprise Edition (J2EE): plataforma de
S.O. Java
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).
S.O.
S.O.
Hardware
Hardware
(c) FEEC/UNICAMP
46
Plataformas Java 2
APIs
Applets, Pacotes, Frameworks
(c) FEEC/UNICAMP
Java Chip
47
(c) FEEC/UNICAMP
48
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
aplicações baseadas em componentes. Utiliza RMI para
comunicação cliente-servidor.
Provê acesso unificado a serviços de nomes e de diretório para as
aplicações Java.
service providers
Servidor EJB
OMG COSNaming
EJB Home
Interface
JNDI SPI
JNDI API
Container EJB
RMI Registry
EJB Bean
JNDI Naming
Manager
Cliente
Cliente
EJB Remote
Interface
Internet LDAP
Database
Novell NDS
(c) FEEC/UNICAMP
49
Plataforma Java 2EE: Tecnologias
Plataforma Java 2EE: Tecnologias
Provê uma interface uniforme para acesso a bases de dados.
JDBC
Driver
API
50
• JTA (Java Transaction API) e JTS (Java
Transaction Service)
• JBDC (Java Database Connectivity)
JDBC API
(c) FEEC/UNICAMP
JDBC
Driver A
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.
Database A
Transaction
Coordinator
JTS API
JTA API
JDBC
Cliente
JDBC
Driver B
Database B
JDBC
Driver C
Database C
Transaction
Manager(s)
JTS
Cliente
Resource
Manager(s)
Datastores
(c) FEEC/UNICAMP
51
Plataforma Java 2EE: Tecnologias
• RMI-IIOP (Java Remote Method Invocation CORBA Internet Inter-ORB Protocol)
Permite aplicações Java interoperarem com outras plataformas
CORBA (ex. Orbix). Prove compilador IDL e ORB simples que
suporta IIOP.
Cliente
CORBA
(C++)
Servidor
EJB
Permite clientes Java acessarem, via RMI, serviços disponibilizados
em CORBA (e vice-versa). RMI-IIOP utiliza JNDI.
Servidor
CORBA
(C++)
Cliente
RMI
Cliente
CORBA
Servidor
RMI
Servidor
CORBA
RMI-IIOP
API
IIOP
Orbix
Java 2 ORB
52
Plataforma Java 2EE: Tecnologias
• Java IDL (Interface Definition Language)
Applet
Java
(c) FEEC/UNICAMP
RMI ORB
CORBA ORB
IIOP
(c) FEEC/UNICAMP
53
(c) FEEC/UNICAMP
54
Plataforma Java 2EE: API Específicas,
Extensões, Pacotes e Produtos
Plataforma Java 2EE: Tecnologias
• Outras Tecnologias:
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 !!!
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
55
(c) FEEC/UNICAMP
Java Remote Method Invocation (RMI)
56
RMI: Visão Geral
Naming.lookup
rmi://host:port/Name
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.
cliente RMI
host
rmiregistry
Naming.bind
rmi://host:port/Name
ObjRef
ObjRef
Naming
s.M1(...)
servidor RMI
Naming
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).
rmic
M1
M2
M3
stub
Servant
M1
JRMP
TCP/IP
M2
M3
skel.
socket
socket
IIOP
(c) FEEC/UNICAMP
57
Java RMI
58
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).
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
TCP/IP
(c)
FEEC/UNICAMP
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;
}
59
(c) FEEC/UNICAMP
60
RMI: Passagem de Parâmetros em Métodos
de Interfaces Remotas
RMI: Servants
import java.rmi.*;
import java.rmi.server.*;
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).
public class AccountServant implements Account
{
long balance;
long limit;
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.
public AccountServant(long lim) throws RemoteException {
super();
balance = 0;
limit = lim;
}
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
61
(c) FEEC/UNICAMP
RMI: Servants (cont.)
RMI: Classes
<<interface>>
Remote
public void deposit( long amount ) throws RemoteException {
balance = balance + amount;
}
AccountServant_Stub
extends
<<interface>>
Account
deposit()
withdraw()
balance()
deposit()
withdraw()
balance()
geradas por rmic
AccountServant_Skel
deposit()
withdraw()
balance()
public long balance() throws RemoteException {
return balance;
}
}
63
RMI: rmic (Compilador RMI)
implements
deposit()
withdraw()
balance()
(c) FEEC/UNICAMP
64
RMI: Serviço de Nomes
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 *.class
Account.class
AccountServant.class
C:\ rmic AccountServant
C:\ dir *.class
Account.class
AccountServant.class
AccountServant_Stub.class
AccountServant_Skel.class
(c) FEEC/UNICAMP
AccountClient
AccountServant
public void withdraw( long amount ) throws RemoteException {
if((limit + balance - amount) < 0)
throw new RemoteException("Limit Exceeded");
balance = balance - amount;
}
(c) FEEC/UNICAMP
62
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/AccountServer
O 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).
65
(c) FEEC/UNICAMP
66
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;
• 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
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());
}
67
(c) FEEC/UNICAMP
RMI: Servidores (cont.)
68
RMI: Clientes
import java.rmi.*;
import java.net.*;
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
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);
69
RMI: Clientes (cont.)
70
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"
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());
}
}
grant {
permission java.net.SocketPermission "*.dca.fee.unicamp.br",
"listen,accept,connect";
permission java.net.SocketPermission "localhost:1099",
"connect";
};
}
(c) FEEC/UNICAMP
(c) FEEC/UNICAMP
71
(c) FEEC/UNICAMP
72
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
tunelar-se a requisição RMI sobre o protocolo HTTP.
cliente
RMI
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.
Serv. HTTP
Firewall
HTTP POST
Stub
proxy
HTTP
script CGI
(java-rmi.cgi)
servidor
RMI
Skeleton
sockets especiais
(c) FEEC/UNICAMP
73
(c) FEEC/UNICAMP
74
Modelo OSI
O Modelo OSI possui algumas funcionalidades na
camada 7 para o desenvolvimento de sistemas
distribuídos:
ODP (Open Distributed
Processing)
• ROSE (Remote Operation Service Element);
• CCR (Concurrency, Commitment, Recovery);
• TP (Transaction Processing);
• DS (Directory Service);
• MHS (Message Handling System).
(c) FEEC/UNICAMP
75
Modelo OSI
(c) FEEC/UNICAMP
ODP: Open Distributed Processing
Problemas no desenvolvimento de Sistemas Distribuídos
diretamente sobre o OSI:
Padrão OSI/ITU-T para processamento distribuído aberto
(ITU-T X.901,902,903,904).
• 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.
É um modelo de referência apenas (protocolos não
são especificados) que vem influenciando outras
atividades de padronização (exemplo: CORBA).
(c) FEEC/UNICAMP
76
Seu desenvolvimento foi fortemente influenciado pelo
projeto ANSA (Universidade de Lancaster, UK).
77
(c) FEEC/UNICAMP
78
ODP: Pontos de Vista
ODP: Pontos de Vista
Empresa
Pontos de vista não são hierarquizados, mas
sim diferentes visões de um mesmo sistema.
Informação
Computação
especificação
SD
SD
implementação
ponto de vista
Engenharia
Tecnologia
(c) FEEC/UNICAMP
79
especificação
ODP: Pontos de Vista
80
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.
Empresa
Em linhas gerais, pode ser considerada um “resumo executivo”
do sistema, onde suas principais características são levantadas.
SD
Informação
implementação
(c) FEEC/UNICAMP
ORB
Engenharia
Computação
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.
Tecnologia
(c) FEEC/UNICAMP
81
(c) FEEC/UNICAMP
ODP: Ponto de Vista de Empresa
ODP: Ponto de Vista de Informação
Grandezas relevantes para este ponto de vista:
O ponto de vista de informação tem por
objetivo modelar o sistema enfocando a
informação produzida e consumida pelo
sistema.
• 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
82
Neste ponto de vista são levantados os
principais componentes manipuladores
de informação, componentes estes
denominados objetos de informação.
83
(c) FEEC/UNICAMP
84
ODP: Ponto de Vista de Informação
ODP: Ponto de Vista de Computaçã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.
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,
principalmente).
Este ponto de vista pode ser descrito através de
notação gráfica introduzidas por metodologias de
desenvolvimento orientado a objeto (UML,
principalmente).
(c) FEEC/UNICAMP
85
(c) FEEC/UNICAMP
ODP: Ponto de Vista de Computação
ODP: Interfaces Computacionais
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.
iniciador
respondedor
sinal
sinal
cliente
servidor
evocação
operação
interface computacional
terminação
BCO
produtor
T2
T1
86
tipo da interface
(c) FEEC/UNICAMP
stream
87
consumidor
fluxo
(c) FEEC/UNICAMP
88
ODP: Ligação (Binding) Primitiva
ODP: Ligação (Binding) Composta
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.
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). Exemplo: ligação tipo
publicador-consumidor.
T
T’
interface
de controle
BCO
BCO
T’: tipo complementar a T
T
(c) FEEC/UNICAMP
89
BCO
BO
BCO
T
T’
(c) FEEC/UNICAMP
T’
90
ODP: Ponto de Vista de Engenharia
ODP: Ponto de Vista de Engenharia
Objetos Básicos de
Engenharia (BEO)
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 UML de colaboração, de sequência, de
atividade de distribuição, etc.
(c) FEEC/UNICAMP
checkpoint, recover, delete, ...
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 denominadas interfaces de
engenharia.
91
interface de
gerenciamento
BEO
interface de engenharia
(c) FEEC/UNICAMP
ODP: Regras de Estruturação
92
ODP: Regras de Estruturação
Cluster
checkpoint, recover, delete, ...
Cápsula
checkpoint, recover, delete, ...
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
(exemplo: pacote Java, agente
móvel).
Cápsula é um agregado de
clusters. Um BEO especial na
cápsula (Gerente de Cápsula)
provê uma interface de gerenciamento para a cápsula. É a
unidade de alocação de
recursos do ODP (exemplo:
processo UNIX).
GCL
BEO
GCP
GCL
GCL
CLUSTER
CLUSTER
CÁPSULA
CLUSTER
(c) FEEC/UNICAMP
93
(c) FEEC/UNICAMP
ODP: Regras de Estruturação
ODP: Regras de Estruturação
Canal
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:
computador conectado à rede.
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.
CÁPSULA
núcleo
NÓ
(c) FEEC/UNICAMP
94
CÁPSULA
95
BEO2
BEO1
interface
de controle
stub
stub
contr.
de canal
binders
protocol adapters
canal
rede
(c) FEEC/UNICAMP
96
ODP: Canal
ODP: Canal
Stub
Binder
Stub é responsável pelos serviços de
apresentação (conversão/compactação de
dados, criptografia, etc) do canal.
Binder é responsável pelo gerenciamento fim-afim 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.
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
Possui interfaces de dados para o stub e
protocol adapter, além de uma interface de
controle utilizadada pelo controlador de canal.
97
(c) FEEC/UNICAMP
ODP: Canal
98
ODP: Canal
Protocol Adapter
Controlador de Canal
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.
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.
Apresenta uma interface de dados para o
binder e uma interface de controle utilizada
pelo controlador de canal.
(c) FEEC/UNICAMP
Controlador de canal interage com os demais
objetos do canal para realizar a ação de controle
solicitada em sua interface.
99
ODP: Canal (exemplo)
cliente
(c) FEEC/UNICAMP
100
ODP: Mapeamento Computação/Engenharia
BEO2
BEO1
BCO1
servant
stub
stub
Stub
STUB
Skeleton
RMI
BINDER
RMI
ADAP. PROTOCOLO
TCP/IP
TCP/IP
contr.
de canal
BO
binders
protocol adapters
BCO2
canal
transparência
(c) FEEC/UNICAMP
101
(c) FEEC/UNICAMP
rede
102
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
do sistema) se aproximar da visão de computação
(associada ao modelamento do sistema).
• acesso;
• localização;
• migração;
• concorrência (transação);
• relocação;
• falha;
• replicação;
• persistência.
Transparência deve ser provida pelo núcleo,
canal e demais infra-estruturas de suporte à
implementação (ORBs, repositórios, etc.).
As transparências de acesso e localização são as mais
comumente encontradas nos sistemas distribuídos.
(c) FEEC/UNICAMP
103
(c) FEEC/UNICAMP
104
Object Management Group (OMG)
CORBA (Common Object
Request Broker
Architecture)
(c) FEEC/UNICAMP
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.
105
OMG: Missão
(c) FEEC/UNICAMP
106
OMG: Estrutura
O OMG é estruturado em três comitês:
A missão do OMG é prover a indústria com especificaçõ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
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).
107
(c) FEEC/UNICAMP
108
OMG: Processo de Padronização
OMG: Padrões Alternativos
As principais tecnologias que competem com as
padronizadas pelo OMG sã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).
• 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
109
(c) FEEC/UNICAMP
A Arquitetura OMA
OMA: Componentes
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
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).
•
111
OMA: Componentes
Application
Interfaces
Domain
Interfaces
(c) FEEC/UNICAMP
112
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:
Common
Facilities
• 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.).
Object Request Broker (ORB)
Object
Services
(c) FEEC/UNICAMP
110
113
(c) FEEC/UNICAMP
114
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;
• ciclo de vida;
• transações;
• persistência;
• externalização/ internalização;
• segurança;
• coleções.
• agentes móveis;
• data interchange;
• interfaceamento com o usuário;
• gerenciamento da informação;
• gerenciamento de sistemas;
• gerenciamento de tarefas (workflow).
dentre muitos outros ...
(c) FEEC/UNICAMP
115
OMA: Interfaces Específicas do Domínio
116
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.
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
(c) FEEC/UNICAMP
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).
117
A Arquitetura CORBA
(c) FEEC/UNICAMP
118
CORBA: Características
• Estabelece uma arquitetura orientada a objetos;
A Arquitetura CORBA (Common Object Request Broker
Architecture) especifica um ORB para a Arquitetura de
Referência OMA.
• Separa a interface do serviço de sua implementação;
• Prevê uma vasta gama se serviços e funcionalidades;
Os demais elementos da OMA, quando implementados
sobre CORBA são denominados CORBAservices
(serviço de objetos) e CORBAfacilities (facilidades
comuns).
(c) FEEC/UNICAMP
• 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).
119
(c) FEEC/UNICAMP
120
CORBA: Arquitetura
CORBA: Arquitetura
A Arquitetura CORBA é composta dos seguintes
componentes básicos:
servidor
cliente
• 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.
IDL stub
DII
ORB
interface
POA
ORB
Repositório de
Implementação
Repositório
de Interfaces
(c) FEEC/UNICAMP
IDL
skeleton
121
(c) FEEC/UNICAMP
CORBA: Object Request Broker (ORB)
122
CORBA: ORB
É o componente básico de interconexão da
Arquitetura CORBA, sendo responsável pelo
encaminhamento de requisições de métodos
para objetos remotos.
cliente (Java)
Windows NT
O ORB provê independência de plataforma,
localização e linguagem de implementação dos
objetos comunicantes.
servidor (C++)
Solaris
ORB
Usualmente é implementado como um daemon
que executa em todas as máquinas da rede.
(c) FEEC/UNICAMP
123
(c) FEEC/UNICAMP
124
CORBA: Interface Definition Language
(OMG IDL)
CORBA: Internet Inter-ORB Protocol (IIOP)
Objetivo: Prover interoperabilidade entre ORBs de
diferentes fornecedores.
Objetivo: especificar interfaces (métodos e
atributos) de objetos.
cliente
OMG IDL não é linguagem de programação;
ORB (IONA)
INTERNET
(TCP/IP)
A especificação CORBA provê mapeamentos de
IDL para linguagens orientadas e não orientadas
a objetos (C, C++, Java, etc.).
servidor
IIOP
ORB (IBM)
(c) FEEC/UNICAMP
125
(c) FEEC/UNICAMP
126
OMG IDL: Compiladores
IDL: Estrutura de uma Interface
Módulo
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.
Definições (tipos complexos, exceções)
Interface
Atributos
Operações
Dependendo da linguagem alvo, compiladores IDL
podem gerar tambem código auxiliar para a
manipulação de tipos e passagem de parâmetros.
Interface
Atributos
Operações
(c) FEEC/UNICAMP
127
IDL: Tipos Básicos
(c) FEEC/UNICAMP
128
IDL: Tipos Complexos
Enumerações:
• um conjunto de possíveis valores
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
Outros Tipos:
• boolean: TRUE ou FALSE
• char: 8 bits (usualmente ASCII)
• octet: 8 bits (opaco)
• any: armazena qualquer tipo IDL
Estruturas:
• um conjunto de tipos (básicos ou complexos) "empacotados".
Exemplo:
struct cliente {
string nome;
long idade;
};
Nota: IDL não define inteiros !
(c) FEEC/UNICAMP
129
IDL: Tipos Complexos (cont.)
(c) FEEC/UNICAMP
130
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
};
Exemplo:
enum moeda {real, dolar, euro, peso};
moeda.real, moeda.dolar, moeda.iene
Strings:
• armazenam uma sequência de caracteres ASCII com tamanho
máximo especificado (bounded) ou não (unbounded).
Exemplos:
string<30> cliente; // maximo 30 caracteres
string cliente;
// tamanho ilimitado
131
(c) FEEC/UNICAMP
132
IDL: Tipos Complexos (cont.)
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).
Arrays:
• armazenam um mesmo tipo IDL em uma estrutura multidimensional.
Exemplos:
sequence<string, 10> nomes; // máximo 10 elementos
sequence<string> nomes;
sequence<DataStruct> vencimentos;
(c) FEEC/UNICAMP
Exemplos:
DataStruct vencimentos[16];
float Z[50][50];
133
IDL: Tipos Complexos (cont.)
134
IDL: Tipos Complexos (cont.)
Constantes:
• permite associar valores a um identificador.
Tipo Fixo:
• permite representar um número em duas partes: valor e
escala (posição do ponto decimal).
Exemplos:
const float pi = 3.1415926535;
const string palmeiras = "alviverde imponente";
Exemplos:
fixed<6,2> preco;
// (-/+)9999.99
fixed<4,3> taxaDolar; // (-/+)9.999
(c) FEEC/UNICAMP
(c) FEEC/UNICAMP
135
IDL: Tipos Complexos (cont.)
(c) FEEC/UNICAMP
136
IDL: Tipos Complexos (cont.)
Typedefs:
• permitem definir nomes para tipos complexos.
Tipo Any:
• permite armazenar um valor pertencente a qualquer tipo
IDL (simples ou complexo), inclusive outro tipo any.
Exemplos:
typedef sequence<DataStruct> Datas;
Datas vencimentos;
typedef long integer;
integer dataDigital;
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
137
(c) FEEC/UNICAMP
138
IDL: Exceções
IDL: Interfaces
Operações nas interfaces IDL podem lançar exceções.
Exceções são declaradas em IDL da seguinte forma:
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
};
exception <nome> {
parâmetros
};
Exemplos:
exception operationFailed {
string reason;
short errorCode;
};
exception noFunds {};
(c) FEEC/UNICAMP
Exemplo:
interface Account {
void deposit (in long amount);
void withdraw(in long amount) raises {noFunds, operationFailed};
long balance();
};
139
IDL: Atributos de Interfaces
(c) FEEC/UNICAMP
140
IDL: Operações
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:
Operações são definidas no escopo de uma interface IDL da seguinte
forma:
<tipo> <nome> (<indireção> <tipo> parâmetro, ...) raises {E1, ... En};
<readonly> attribute <nome>;
Exemplos:
void withdraw(in long amount) raises {noFunds, operationFailed};
long balance();
Exemplo:
interface Account {
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
141
IDL: Parâmetros de Operações
(c) FEEC/UNICAMP
142
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:
• 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.
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();
Nota: parâmetros com valor NULL são proibidos !
(c) FEEC/UNICAMP
143
(c) FEEC/UNICAMP
144
IDL: Interfaces e Tipos Complexos
IDL: Definições Postergadas
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:
É 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 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
145
IDL: Herança de Interfaces
IDL
module
boolean
char
octet
string
short, unsigned short
long, unsigned long
long long, unsigned long long
float
double
fixed
interface D : A,B,C {
...
};
Exemplo:
interface SavingAccount : Account {
readonly attribute float interestRate;
float computeInterest();
};
147
Mapeamento IDL-Java
IDL
enum, struct, union
sequence, array
interface
constant (fora de uma interface)
constant (em uma interface)
exception
any
typedef
readonly attribute
readwrite attribute
operação
Java
package
boolean
char
byte
java.lang.String
short
int
long
float
double
java.math.BigDecimal
(c) FEEC/UNICAMP
148
Parâmetros out e inout em Java
Java
class
array
interface, helper & holder classes
public interface
fields na interface Java
class
org.omg.CORBA.Any
helper classes
accessor method
accessor and modifer methods
método
(c) FEEC/UNICAMP
146
Mapeamento IDL-Java
IDL permite herança simples e múltipla de interfaces.
(c) FEEC/UNICAMP
(c) FEEC/UNICAMP
149
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
150
Parâmetros out e inout em Java (cont.)
Classes Helper
Exemplo:
// IDL
interface Account {
...
void withdraw(inout long amount);
};
// Java
intHolder amt = new IntHolder();
amt.value = 10000;
acc.withdraw(amt);
System.out.println("Amount: " +
amt.value);
// Java
public interface AccountOperations {
...
void withdraw(intHolder amount);
};
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
151
(c) FEEC/UNICAMP
Mapeamento IDL-Java: Exemplo
152
Exemplo: Account.idl
Account.idl
interface Account {
exception LimitExceeded{string reason;};
Compilador IDL
Interface
AccountOperations
Interface
Account
class
AccountHolder
class
_AccountStub
class
AccountHelper
class
AccountPOA
(c) FEEC/UNICAMP
void deposit(
in long long arg0 );
void withdraw(
in long long arg0 ) raises (LimitExceeded);
long long balance( );
};
153
Exemplo: AccountOpeations.java
154
Exemplo: Account.java
public interface AccountOperations
{
void deposit (long arg0);
void withdraw (long arg0) throws AccountPackage.LimitExceeded;
long balance ();
} // interface AccountOperations
(c) FEEC/UNICAMP
(c) FEEC/UNICAMP
public interface Account extends AccountOperations,
org.omg.CORBA.Object,
org.omg.CORBA.portable.IDLEntity
{
}
155
(c) FEEC/UNICAMP
156
Exemplo: AccountHolder.java
Exemplo: AccountHelper.java
abstract public class AccountHelper
{
private static String _id = "IDL:Account:1.0"
public final class AccountHolder implements
org.omg.CORBA.portable.Streamable
{
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)
{
value = initialValue;
}
...
}
(c) FEEC/UNICAMP
public static Account narrow (org.omg.CORBA.Object obj)
{ .... }
public static String id ()
{ return _id;}
}
157
Exemplo LimitExceeded.java
(c) FEEC/UNICAMP
158
IDL: Passagem de Objetos por Valor
package AccountPackage;
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).
public final class LimitExceeded extends org.omg.CORBA.UserException
{
public String reason = null;
public LimitExceeded ()
{
super(LimitExceededHelper.id());
} // ctor
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.
public LimitExceeded (String _reason)
{
super(LimitExceededHelper.id());
reason = _reason;
} // ctor
(c) FEEC/UNICAMP
159
(c) FEEC/UNICAMP
IDL: OBV
IDL: OBV (cont.)
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 ?
classes
Helper,
Holder
valuetype
estado
métodos
construtor
Compilador IDL
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
160
Value
Factory
161
Default
Factory
(c) FEEC/UNICAMP
Objeto
Java
Implementação
do Objeto
162
IDL: Valuetypes
IDL: Uso de Valuetypes
// "objeto" a ser passado por valor
valuetype Empregado {
// definicao do estado
public string nome;
public string cargo;
public float idade;
public long salario;
// interface que utiliza o "objeto"
interface RH
Empregado obtemEmpregado(in string nome);
void adicionaEmpregado(in Empregado emp);
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
163
IDL: Implementação de Valuetypes
(c) FEEC/UNICAMP
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;
}
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
public int computaSalario () {
if(cargo.equals("gerente")) return(8000);
return(3000);
}
}
165
IDL: Valuetypes - lado cliente
(c) FEEC/UNICAMP
166
IDL: Valutypes - lado servidor
import org.omg.CORBA.*;
import java.util.*;
// creia fabrica de Empregados (local)
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;
Hashtable empregados = null;
float massaSalarial = 0;
Empregado e1 = rh.obtemEmpregado("Joao");
System.out.println("Empregado obtido: " + e1.nome +
" - cargo: " + e1.cargo + " - idade: " + e1.idade);
public RHServant() {
// cria fabrica e hashtable
the_factory = new EmpregadoDefaultFactory();
empregados = new Hashtable();
}
System.out.println("O salario de " + e1.nome + " e' " +
e1.computaSalario()); // <<< chamada local !!
(c) FEEC/UNICAMP
164
167
(c) FEEC/UNICAMP
168
IDL: Valutypes - lado servidor (cont.)
CORBA: Basic Object Adapter (BOA)
public Empregado obtemEmpregado (String nome) {
Empregado e = (Empregado)empregados.get(nome);
if(e == null) e = the_factory.init("", "", (float)0.0);
return e;
}
Objetivo: instanciar (criar) servidores e controlar a
execução de métodos.
O BOA identifica o código dos objetos servidores
interagindo com o Repositório de Implementação.
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);
}
Usualmente, o BOA provê três tipos de instanciação
de servidores:
• compartilhada;
• não compartilhada;
• por método.
public void removeEmpregado (Empregado emp) {
if(empregados.remove(emp.nome) != null)
massaSalarial -= emp.computaSalario(); // <<< chamada local !
}
}
(c) FEEC/UNICAMP
169
(c) FEEC/UNICAMP
CORBA: BOA
compartilhada
não compartilhada
M1
M1
CORBA: BOA
por método
M1
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
O BOA implementa também funções elementares
de segurança (Ex: verificação se um cliente possui
permissão para instanciar um servidor) via atributos
do sistema de arquivos.
M2
M3
método
processo
M2
M2
M3
M3
M2
(c) FEEC/UNICAMP
Pode-se implementar diferentes adaptadores de
objetos em prejuizo da portabilidade.
171
Adaptador de Objeto Portável (POA)
(c) FEEC/UNICAMP
172
POA: Stubs e Skeletons Portáveis
cliente
servant
result = get(n, m)
value = gridRef.get(x,y)
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 implementação.
result = get(n, m)
out
in
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.
stub
out
skeleton
in
invoke
out = invoke(”get”,in)
in = invoke(out)
get n m
invoke
ORB
(c) FEEC/UNICAMP
170
173
IIOP
result
(c) FEEC/UNICAMP
ORB
174
POA: Arquitetura
Servidor CORBA
POA Manager
POA Raiz
POA P2
Políticas
POA P1
Servant Manager
(default)
POA Raiz é obtido através do método
resolve_initial_references("RootPOA")
disponibilizado pelo ORB.
Definidas pelo
desenvolvedor
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.
Object ID
Object ID
Object ID
Object ID
Mapa de
Objetos Ativos
POA P3
(c) FEEC/UNICAMP
Servant Manager
175
Servants
(implementações)
POA: Arquitetura
código
suprido pelo
desenvolvedor
(c) FEEC/UNICAMP
POA: Operação Típica
176
POA: Políticas
POA define 7 políticas:
1. Atribuição de OIDs: USER_ID; SYSTEM_ID (default)
servant
POA
mapa objs.
ativos
2. Retenção de Servants: RETAIN (servants são retidos no mapa
de objetos ativos); NON_RETAIN (não existe mapa de objetos
ativos).
upcall M(...)
_invoke(M, ...)
skeleton
OID
3. Processamento de Requisição:
USE_ACTIVE_OBJECT_MAP_ONLY (default);
USE_DEFAULT_SERVANT; USE_SERVANT_MANAGER.
parâmetros
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.
_invoke
(c) FEEC/UNICAMP
177
(c) FEEC/UNICAMP
POA: Políticas (cont.)
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".
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).
POA
POA
ORB
(c) FEEC/UNICAMP
178
179
POA
ORB
(c) FEEC/UNICAMP
ORB
180
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
estados abaixo:
• 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;
• 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).
• 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
181
POA: Indentificadores de Objeto (OID)
182
CORBA: Static Invocation Interface (SII)
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).
SII é a forma mais simples do cliente invocar
um método num servidor.
SII requer que todas as interfaces de servidores
sejam conhecidas em tempo de compilação
(portanto, SII é type-safe).
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
(c) FEEC/UNICAMP
183
CORBA: SII
(c) FEEC/UNICAMP
184
CORBA: Dynamic Invocation Interface (DII)
DII é um conjunto de serviços que permitem a clientes:
servidor
cliente
• Verificar a existência de interfaces no Repositório de
Interfaces;
proxy
IDL stub
• Descobrir os parâmetros (tipos) e métodos (protótipos)
de determinada interface;
IDL skeleton
POA
• Preparar passo-a-passo uma evocação para um
servidor que implementa esta interface.
ORB
(c) FEEC/UNICAMP
185
(c) FEEC/UNICAMP
186
CORBA: Repositórios de Interfaces e
Implementação
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.
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).
Nota: O uso de DII no lado cliente não implica
no uso de DSI no lado servidor e vice-versa.
(c) FEEC/UNICAMP
As implementações CORBA provêem aplicativos
para a manutenção destes repositórios.
187
CORBA: CORBAservices
(c) FEEC/UNICAMP
188
CORBAservices: Nomes
CORBAservices define arquiteturas e interfaces (não
implementações !) para os seguintes serviços:
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.
• nomes (diretório);
• eventos;
• ciclo de vida;
• segurança;
• transações;
• time;
• persistência;
interfaces IDL
do serviço
servant
CORBA
servidor de nomes
diretório de nomes
(persistente ou transiente)
dentre muitos outros !
(c) FEEC/UNICAMP
189
CORBAServices: Ciclo de Vida
encontra
create_object
cria
copy
move
remove
190
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.
O serviço de propriedades proporciona operações que
permitem criar, destruir, copiar objetos.
find_factories
(c) FEEC/UNICAMP
servant
CORBA
create_propertyset
create_initial_propertyset
create_constrained_propertyset
FactoryFinder
CORBA.Object obj =
GenericFactory.CreateObject(pars);
servant
CORBA
servant
CORBA
PropertySetFactory
define_property
get_property
delete_property
GenericFactory
servant
CORBA
......
servidor de propriedades
LifeCycleObject
(c) FEEC/UNICAMP
191
(c) FEEC/UNICAMP
servant
CORBA
PropertySet
192
CORBAServices: Eventos
CORBAServices: Object Transaction Service
O serviço de eventos prove um mecanismo de notificação
segundo os modelos push e pull.
OTS (Object Transaction Service) implementa um
serviço de transações aberto baseado no protocolo
2-phase commit.
obtain_push_consumer
obtain_push_supplier
connect_push_consumer
connect_push_supplier
disconnect_push_supplier
interfaces IDL
do serviço
- begin
- commit
- abort, ...
push
push
evento
push supplier
servant
CORBA
interface XA
(X/Open)
servidor OTS
canal de eventos
push consumers
permite a integração com
produtos que implementam
esta interface
servidor de eventos
(c) FEEC/UNICAMP
193
CORBAservices: Trader
4
Trader
3
2
(c) FEEC/UNICAMP
194
Java IDL
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.
cliente
CORBA
base de dados
(Oracle, Sybase, etc.)
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:
servidor
CORBA
• 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).
1
ORB
1. exporta capacidades do servidor (desempenho, custo, etc.)
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
195
(c) FEEC/UNICAMP
196
Considerações Finais: Tendências em
Plataformas Distribuídas
Java IDL
• existe uma clara convergência de plataformas distribuídas
com a Internet;
Java IDL suporta:
• Adaptador de Objeto Portável (POA);
• servidores persistentes;
• passagem de objeto por valor (Object by Value);
• Intercerceptadores Portáveis (suporte parcial).
• neste contexto, as tecnologias voltadas para XML têm papel
chave nas plataformas distribuídas;
• a comunicação através de RPC deve ser expandida com a
introdução de novas formas de comunicação (messaging,
streamming, etc.);
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
• plataformas distribuídas devem suportar o desenvolvimento
de aplicações ubíquas (onipresentes). Dispositivos "leves" sem
fio devem ser capazes de se comunicar com a aplicação.
197
(c) FEEC/UNICAMP
198
Plataformas Distribuídas: Cenário
WML
Dispositivo
Sem Fio
Considerações Finais: Tendências Futuras
XML, SOAP,
WSDL, UDDI
Servidor Web
Aplicações
de Negócio
Firewall
HTML, Java, XML
HTTP
• mais componentes e menos objetos;
• mais especificação e menos codificação;
• mais evolução e menos adaptação;
• mais qualidade e menos complexidade;
• mais integração e menos substituição;
• mais padrões abertos e menos soluções proprietárias;
• mais serviços e menos aplicativos.
RMI, CORBA, EJB
Desktop
Servlet/JSP
INTERNET/TCP-IP
XML
Pode-se especular o seguinte cenário futuro para as
plataformas distribuídas:
Servidor de
Aplicação
WAP
Bases
Corporativas
Sistemas
Legados
JDBC, SQLX
SOAP
Servidor
Corporativo
Segurança (SSL, Cert. Digital, Criptografia, etc.)
(c) FEEC/UNICAMP
199
(c) FEEC/UNICAMP
200