Sistemas Distribuídos Localização de Objetos Distribuídos - INF

Sistemas Distribuídos
Localização de Objetos
Distribuídos
Especialização em Redes de
Computadores
Prof. Fábio M. Costa
Instituto de Informática - UFG
Motivação
• Evitar o uso de endereços físicos para a
localização de componentes
• Nomeação
– Localização de componentes por meio de
nomes externos
– Similar às páginas brancas de um catálogo
telefônico
• Trading
– Localização de componentes por meio de
características de serviço
– Similar às páginas amarelas
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
2
Visão Geral
• Nomeação de Objetos
–
–
–
–
Princípios
Serviço de Nomes de CORBA
COM Monikers
Java/RMI Registry
• Trading de Objetos
– Princípios
– Serviço de Trading de CORBA
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
3
Nomeação
Princípios Básicos
• Plataformas de middleware orientadas a objetos
utilizam-se de referências de objetos para
endereçar objetos servidores
• É necessária uma forma de obter tais referências
de objetos sem a necessidade de suposições sobre
localização física
• Um nome é uma seqüência de cadeias de
caracteres que pode ser “ligada” a uma referência
de objeto (name binding)
• Um nome pode ser resolvido para se obter a
referência de objeto correspondente
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
5
Princípios Básicos (cont.)
• Pode haver muitos objetos servidores em um
sistema de objetos distribuídos
• Objetos servidores podem ter vários nomes
• Isto leva a um grande número de “ligações de
nomes”
• O espaço de nomes deve ser organizado em uma
hierarquia para evitar
– conflitos de nomes
– baixo desempenho na resolução de nomes
• Esta hierarquia pode ser obtida através de
contextos de nomes
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
6
Princípios Básicos:
Contextos de Nomes
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
7
Princípios Básicos:
Nomes Compostos
• Nomes são compostos por possivelmente
mais do que um componente (string)
• A seqüência de componentes de um nome
descreve uma caminho através do grafo de
contextos de nomes
• Exemplo:
– (“UEFA”, “England”, “Premier”, “Chelsea”)
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
8
Princípios Básicos:
Servidor de Nomes
• “Ligações” de nomes (a referências de objetos)
são administradas por servidores de nomes
• Nem todo objeto servidor precisa de um nome
• Alguns objetos servidores podem ter vários nomes
• Os servidores de nomes devem armazenar as
amarrações de nomes persistentemente
• Os servidores de nomes devem ser “calibrados”
com vistas à eficiência na resolução de nomes
• O próprio servidor de nomes pode ser distribuído
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
9
O Serviço de Nomes de CORBA
• Suporta a ligação (binding) de nomes a
referências de objetos CORBA
• Escopo de um nome: contexto de nomes
• Múltiplos nomes podem ser definidos para
uma mesma referência de objeto
• Nem todas as referências de objetos
precisam de nomes
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
10
Nomes em CORBA
• Nomes são compostos por nomes simples
• Nomes simples: pares valor-tipo
• O atributo valor é usado para resolução de
nomes
• O atributo tipo é usado para fornecer
informação a respeito do papel do objeto
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
11
Tipos IDL para Nomes
module CosNaming {
typedef string Istring;
struct NameComponent {
Istring id;
Istring kind;
};
typedef sequence <NameComponent> Name;
...
};
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
12
Interfaces IDL do Serviço de
Nomes
• O Serviço de Nomes é especificado através
de duas interfaces
– NamingContext define operações para ligar
objetos a nomes e para a resolução de nomes
– BindingIterator define operações para iterar
em um conjunto de nomes definido em um
dado contexto de nomes
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
13
Interface NamingContext
interface NamingContext {
void bind(in Name n, in Object obj)
raises (NotFound, ...);
Object resolve(in Name n)
raises (NotFound,CannotProceed,...);
void unbind (in Name n)
raises (NotFound, CannotProceed...);
NamingContext new_context();
NamingContext bind_new_context(in Name n)
raises (NotFound, ...)
void list(in unsigned long how_many,
out BindingList bl,
out BindingIterator bi);
};
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
14
Interface BindingIterator
interface BindingIterator {
boolean next_one(out Binding b);
boolean next_n(in unsigned long how_many,
out BindingList bl);
void destroy();
}
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
15
Um Cenário para o Serviço de
Nomes: Ligação
• Exemplo: Promover um time para a 1a.
Divisão e rebaixar outro
root: Naming
Context
c:Client
1L:Naming
Context
1L=resolve("UEFA","Germany","1. Liga")
bind("Arm. Bielefeld", bielefeld)
unbind("Eintr. Frankfurt")
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
16
Inicialização do Serviço de
Nomes
– Como obter o Contexto de Nomes Raiz?
– Através da Interface do ORB
module CORBA {
interface ORB {
typedef string ObjectId;
typedef sequence <ObjectId> ObjectIdList;
exception InvalidName{};
ObjectIdList list_initial_services();
Object resolve_initial_references
(in ObjectId identifier) raises(InvalidName);
}
}
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
17
Um Cenário para o Serviço de
Nomes: Resolução
• Exemplo: Imprimir o elenco de um time
root: Naming
Context
c:Client
D:Naming
do:Team
Context
D=resolve("UEFA","Germany")
do=resolve("1. Liga","BVB")
print()
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
18
Cenário para o Serviço de
Nomes: Iteração
• Imprimir os nomes de todos os times do
campeonato
c:Client
1.Liga:Naming bi:Binding
Context
Iterator
t:Team
list(0,bl,bi)
t=next_one().value
name()
t=next_one().value
name()
t=next_one().value
name()
...
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
19
O Serviço de Nomes em COM:
Monikers
• Em COM, monikers são usados para
“desacoplar os clientes dos algoritmos e da
informação que são necessários para
encontrar objetos servidores” [Don Box, 98]
• Suporta a ligação e resolução de nomes
• O espaço de nomes pode ser estruturado
hierarquicamente
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
20
O Serviço de Nomes em COM:
Interface IMoniker
interface IMoniker : IPersistStream {
HRESULT BindToObject([in] IBindCtx *pbc,
[in, unique] IMoniker *pmkToLeft,
[in] REFIID riid,
[out, iid_is(riid)] void **ppv);
...
}
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
21
Criação de Monikers: Interface
IParseDisplayName
• Para ser nomeável, objetos servidores precisam
implementar esta interface
• Cria-se um objeto moniker a partir de um nome
textual externo, chamado de display name
interface IParseDisplayName {
HRESULT MkParseDisplayName([in] IBindCtx *pbc,
[in,string] const OLECHAR *pwszName,
[out] ULONG *ppchEaten
[out] IMoniker **ppmk);
}
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
22
Avaliação
• COM suporta nomes internos (monikers) e
nomes externos (display names)
– Isto complica o esquema de nomes
• O Serviço de Nomes de COM é estreitamente
ligado a outras partes da especificação de
COM (containers)
• O Serviço de Nomes de COM não é
transparente para os designers de objetos
servidores, que precisam implementar a
interface IParseDisplayName
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
23
O Serviço de Nomes em RMI:
RMI Registry
• Versão simplificada do Serviço de Nomes
de CORBA
• Sem suporte para nomes compostos
• Restrição de segurança: ligações de nomes
não podem ser criadas a partir de máquinas
remotas
• Deve haver um registry em cada máquina
• Diferentes registries devem estar integrados
dentro de um espaço de nomes federado
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
24
RMI Registry
package java.rmi.registry;
public interface Registry extends java.rmi.Remote {
public static final int REGISTRY_PORT = 1099;
public java.rmi.Remote lookup(String name)
throws java.rmi.RemoteException,
java.rmi.NotBoundException,
java.rmi.AccessException;
public void bind(String name, java.rmi.Remote obj)
throws java.rmi.RemoteException,
java.rmi.AlreadyBoundException,
java.rmi.AccessException;
public void rebind(String name, java.rmi.Remote obj)
throws java.rmi.RemoteException,
java.rmi.AccessException;
public void unbind(String name)
throws java.rmi.RemoteException,
java.rmi.NotBoundException,
java.rmi.AccessException;
public String[] list()
throws java.rmi.RemoteException,
java.rmi.AccessException;
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
25
Usando o RMI Registry
:Locate
Registry
root=getRegistry(“ns.fifa.org”)
c:Client
root:
1L:
BVB:
E:
do:Team
Registry Registry Registry Registry
E=lookup("UEFA")
D=lookup(“Germany”)
1L=lookup(“1. Liga”)
BVB=lookup(“BVB”)
print()
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
26
Avaliação
• A ausência de nomes hierárquicos aumenta
o número de operações remotas necessárias
para a resolução de nomes
• A descoberta do registry raiz não é
necessariamente transparente de localização
• A restrição de segurança quebra o conceito
de transparência de localização
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
27
Limitações de Serviços de
Nomes
• Em todas as abordagens mencionadas:
– Os clientes sempre devem identificar o servidor
específico por meio de um nome
• Inapropriado se o cliente apenas deseja usar
um serviço com certas características e
qualidade, mas não sabe em que servidor:
– Comércio eletrônico
– Vídeo sob demanda
– Venda automática de bilhetes de cinema
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
28
Trading
Motivação
• Localização de objetos de maneira transparente de
localização
• O uso de um serviço de nomes é simples, mas
pode não ser apropriado quando:
– clientes não conhecem os servidores
– há múltiplos servidores para o mesmo serviço
• Trading oferece suporte para a localização de
servidores com base na funcionalidade e qualidade
de serviço
• Serviço de Nomes ↔ Páginas brancas
• Trading ↔ Páginas Amarelas
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
30
Características de um Serviço de
Trading
• O Trader opera como um intermediador
entre clientes e servidores (mas não no
mesmo sentido que o ORB!)
• Permite ao cliente mudar de perspectiva
– de “quem” para “o que”
Trader
3:invoke
Exporter
Importer
• Análogo à idéia de um corretor de seguros
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
31
Características de um Serviço de
Trading (cont.)
• Linguagem comum entre cliente e servidor
– Tipos de serviço
– Qualidades de serviço
• Servidor se registra junto ao trader
• Servidor define uma qualidade de serviço
(QoS) garantida
– Definição estática de QoS
– Definição dinâmica de QoS
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
32
Características de um Serviço de
Trading (cont.)
• Clientes consultam o trader para obter
– um serviço de um certo tipo
– com um certo nível de qualidade
• O trader oferece suporte para
– comparação de tipos de serviço com as
propriedades especificadas
– pesquisa por serviços
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
33
Exemplo
• Serviço de vídeo-sob-demanda da Hongkong
Telecom:
Server
MGM
Warner
Video-ondemand
provider
User
Trader
Independent
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
34
O Processo de Trading
• Exemplo: servidor de vídeo-sob-demanda
:Client
:Trader
MGM:VoDS
Warner:VoDS
export()
export()
query()
modify()
download()
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
35
Definição de Tipos de Serviço
• Um tipo de serviço define:
– A funcionalidade provida por um serviço
– As qualidades desta do serviço provido
• A funcionalidade é definida por meio de um tipo
de objeto (interface)
• QoS é definida com base em propriedades
–
–
–
–
nome da propriedade
tipo da propriedade
valor da propriedade
modo da propriedade
• obrigatório / opcional
• leitura apenas / modificável
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
36
Exemplo de Tipo de Serviço
typedef enum {VGA,SVGA,XGA} Resolution;
service video_on_demand {
interface VideoServer;
readonly mandatory property float fee;
readonly mandatory property Resolution res;
modifiable optional property float bandwidth;
}
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
37
Hierarquia de Tipos de Serviço
• Um tipo de objeto pode ter várias implementações
com diferentes QoS
• O mesmo tipo de objeto pode ser usado em
diferentes tipos de serviço
• Tipo de serviço S é um subtipo do tipo de serviço S´
sse
– o tipo de objeto de S é idêntico ou é um subtipo do tipo
de objeto de S´
– S tem pelo menos todas as propriedades definidas para S´
• Relação de sub-tipagem pode ser explorada pelo
trader na busca por serviços de um determinado
tipo
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
38
Definição de Restrições
• O importador (cliente) define, como parte da
consulta ao trader, as qualidades de serviço
desejáveis
• Exemplo:
– custo<10 AND res>=SVGA AND bandewidth>=256
• Em uma consulta, o trader considera apenas aquelas ofertas
de serviço que obedeçam à restrição
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
39
Políticas de Trading
• Dependendo das restrições e dos serviços
disponíveis, um grande conjunto de ofertas pode
ser retornado por uma consulta
• Políticas de trading são usadas para restringir o
tamanho da lista de ofertas de serviço retornadas
– Especificação de um limite máximo
– Restrição sobre a substituição de serviço (por subtipos)
– Restrição sobre as propriedades modificáveis (as quais
podem ser alteradas no período entre a busca do serviço
e seu efetivo uso através de requisições do cliente)
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
40
Federação de Traders
• Demanda por escalabilidade
• Um trader participando de uma federação:
– oferece para os demais traders os serviços sobre
os quais ele tem conhecimento
– encaminha para outros traders consultas para
serviços sobre os quais não tem conhecimento
• Problemas
– importações de serviços podem não terminar
– duplicação de ofertas
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
41
Grafo de Trading
T1
query.hop_count=4
def_follow_policy=always
max_hop_count=5
T2
Service Offer
T4
Trader Attribute
Link
Original: Wolfgang Emmerich, 2000
max_hop_count=1
T3
query.hop_count=0
Prof. Fábio M. Costa - Instituto de Informática / UFG
42
O Serviço de Trading de CORBA
Application
Objects
Domain
Interfaces
CORBA
facilities
Object Request Broker
Object
Trader
CORBAservices
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
43
Interfaces do Serviço de Trading
de CORBA
Admin
list_offers()
…
LinkAttributes
TraderComponents
Link
add_link()
remove_link()
describe_link()
modify_link()
Original: Wolfgang Emmerich, 2000
Support Attributes
Lookup
query()
ImportAttributes
Register
export()
withdraw()
modify()
Prof. Fábio M. Costa - Instituto de Informática / UFG
44
Definindo Qualidade de Serviço
typedef Istring PropertyName;
typedef sequence<PropertyName> PropertyNameSeq;
typedef any PropertyValue;
struct Property {
PropertyName name;
PropertyValue value;
};
typedef sequence<Property> PropertySeq;
enum HowManyProps {none, some, all}
union SpecifiedProps switch (HowManyProps) {
case some : PropertyNameSeq prop_names;
};
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
45
Interface do Trader para
Exportadores de Serviços
interface Register {
OfferId export(in Object reference,
in ServiceTypeName type,
in PropertySeq properties)
raises(...);
OfferId withdraw(in OfferId id)
raises(...);
void modify(in OfferId id,
in PropertyNameSeq del_list,
in PropertySeq modify_list)
raises (...);
Original: Wolfgang Emmerich, 2000
};
Prof. Fábio M. Costa - Instituto de Informática / UFG
46
Interface do Trader para
Importadores de Serviços
interface Lookup {
void query(in ServiceTypeName type,
in Constraint const,
in Preference pref,
in PolicySeq policies,
in SpecifiedProps desired_props,
in unsigned long how_many,
out OfferSeq offers,
out OfferIterator offer_itr,
out PolicyNameSeq Limits_applied)
raises (...);
Original: Wolfgang Emmerich, 2000
};
Prof. Fábio M. Costa - Instituto de Informática / UFG
47
Pontos-Chave
• Objetos distribuídos podem ser localizados por
meio de um serviço de nomes ou de trading
• Um serviço de nomes liga nomes (conhecidos
externamente) a referências de objetos oferece
suporte para resolução de nomes para revelar a
referência de objeto ligada
• Trading oferece suporte para a localização de
objetos com base na funcionalidade que os
mesmos oferecem, bem como na qualidade que
garantem
Original: Wolfgang Emmerich, 2000
Prof. Fábio M. Costa - Instituto de Informática / UFG
48