serviço - INF

Sistemas Distribuídos
Serviço de Nomes
e
Serviço de Diretório
Instituto de Informática – UFG
Verão 2005
Baseado em: Emmerich, Capítulo 4
Roteiro
Conceitos básicos de serviços de nomes
Exemplos de serviços de nomes
– CORBA Naming Service
– RMI Registry
Serviço de Trading
Motivação
Evitar o uso de endereços físicos para a localização
de componentes
Naming
– 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
Serviços de Nomes
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 “amarrada” a uma referência de objeto
– name binding
Um nome pode ser resolvido para se obter a referência de
objeto correspondente
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 “name bindings”
• 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 construída através de contextos de
nomes
Princípios Básicos:
Contextos de Nomes
Princípios Básicos:
Nomes Compostos
Nomes podem ser formados através da composição de
vários nomes simples (strings)
A seqüência de componentes de um nome descreve
um caminho através do grafo de contextos de nomes
Exemplo: Nome do objeto representado o time
Chelsea:
– (“UEFA”, “England”, “Premier”, “Chelsea”)
Princípios Básicos: Servidor de Nomes
• “Amarraçõ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
O Serviço de Nomes de CORBA
Suporta a amarração de nomes (name binding) 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
Nomes em CORBA
Nomes de objetos são compostos por nomes simples
Nomes simples (componentes): 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
Tipos IDL para Nomes
module CosNaming {
typedef string Istring;
struct NameComponent {
Istring id;
Istring kind;
};
typedef sequence <NameComponent> Name;
...
};
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
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);
};
Interface BindingIterator
interface BindingIterator {
boolean next_one(out Binding b);
boolean next_n(in unsigned long how_many,
out BindingList bl);
void destroy();
}
Cenário de Uso do Serviço de Nomes:
Registro de Nomes
Exemplo: Promover um time para a 1a. divisão e
rebaixar outro
c:Client
root: Naming
Context
1L=resolve("UEFA","Germany","1. Liga")
bind("Arm. Bielefeld", bielefeld)
unbind("Eintr. Frankfurt")
1L:Naming
Context
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);
}
}
Um Cenário para o Serviço de Nomes:
Resolução
Exemplo: Imprimir o elenco de um time
c:Client
root: Naming
Context
D=resolve("UEFA","Germany")
do=resolve("1. Liga","BVB")
print()
D:Naming
do:Team
Context
Cenário de uso do Serviço de Nomes:
Iteração
Exemplo: Imprimir os nomes de todos os times do
campeonato
c:Client
list(0,bl,bi)
t=next_one().value
name()
t=next_one().value
name()
t=next_one().value
name()
...
1.Liga:Naming bi:Binding
Context
Iterator
t:Team
O Serviço de Nomes em Java 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
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;
Usando o RMI Registry
:Locate
Registry
root=getRegistry(“ns.fifa.org”)
c:Client
E=lookup("UEFA")
D=lookup(“Germany”)
1L=lookup(“1. Liga”)
BVB=lookup(“BVB”)
print()
root:
D:
1L:
E:
Registry Registry Registry Registry
BVB:
Team
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
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 qualidades, mas
não sabe (ou não precisa saber) em que servidor:
– Comércio eletrônico
– Vídeo sob demanda
– Venda automática de bilhetes de cinema
Trading
Motivação
Localização de objetos com base no seu tipo e 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 objetos servidores
– há múltiplos objetos servidores para o mesmo serviço
– para o cliente, não importa qual o objeto é utilizado – o que
importa é o serviço oferecido
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
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
Características de um Serviço de Trading
(cont.)
Linguagem comum entre cliente e servidor, baseada em:
– Tipos de serviço
– Qualidades ou propriedades do serviço
Usada para:
• Servidor se registrar junto ao Trader
• Servidor definir uma qualidade de serviço (QoS) garantida
– Definição estática de QoS
– Definição dinâmica de QoS
Características de um Serviço de Trading
(cont.)
Clientes consultam o Trader para obter
– um serviço de um certo tipo
– e com um certo nível de qualidade
O Trader oferece suporte para
– comparação de tipos de serviço com as propriedades
especificadas
– busca por serviços
Exemplo
Serviço de vídeo-sob-demanda
Server
MGM
Warner
Independent
Video-ondemand
provider
Trader
User
O Processo de Trading
Exemplo: servidor de vídeo-sob-demanda
:Client
:Trader
MGM:VoDS
Warner:VoDS
export()
export()
query()
modify()
download()
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
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;
}
Hierarquia de Tipos de Serviço
• Um tipo de objeto pode ter várias implementações com
diferentes níveis de QoS
• O mesmo tipo de objeto pode ser usado em diferentes tipos
de serviço (i.e., variando-se as propriedades de QoS)
• 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
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 bandwidth>=256
Em uma consulta, o trader considera apenas aquelas ofertas de
serviço que obedeçam à restrição
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)
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
Grafo de Trading
T1
query.hop_count=4
def_follow_policy=always
max_hop_count=5
T2
Service Offer
T4
Trader Attribute
Link
max_hop_count=1
T3
query.hop_count=0
O Serviço de Trading de CORBA
Application
Objects
Domain
Interfaces
CORBA
facilities
Object Request Broker
Object
Trader
CORBAservices
Interfaces do Serviço de Trading de
CORBA
Admin
list_offers()
…
LinkAttributes
TraderComponents
Link
add_link()
remove_link()
describe_link()
modify_link()
Support Attributes
Lookup
query()
ImportAttributes
Register
export()
withdraw()
modify()
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;
};
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 (...);
};
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 (...);
};
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