• Nenhum resultado encontrado

Gestão de Nomes. Gestão de nomes: Objectivo

N/A
N/A
Protected

Academic year: 2021

Share "Gestão de Nomes. Gestão de nomes: Objectivo"

Copied!
55
0
0

Texto

(1)

Sistemas Distribuídos 2009/10 1

Gestão de Nomes

Departamento de Engenharia Informática

Gestão de nomes: Objectivo

• Objectos podem ser computadores, serviços, objectos remotos, ficheiros, utilizadores, etc • Nomes facilitam comunicação e partilha de

recursos

– Necessários quando de faz pedido a um sistema para actuar sobre um determinado recurso (de entre vários)

• Exemplo: URL para abrir página

– Permitem partilhar recursos

• Exemplo: objecto remoto

– Permitem comunicar

• Exemplo: endereço email permite a utilizadores trocarem mensagens

– Permitem associar atributos a recursos descritivos a recursos, e fazer procuras baseadas em atributos

• Exemplo: procurar impressora a cores na rede local

Associar nomes a objectos para: – Identificar os objectos – Localizar os objectos – Partilhar os objectos – Obter atributos associados ao objecto – Simplificar a interface com os utentes – Simplificar a gestão do sistema

(2)

Sistemas Distribuídos 3

Exemplos de nomes

• Nome ficheiro

• URL

• UUID

• Número de telefone

• Matrículas de automóveis

• Número do Bilhete de Identidade

• Nome de uma empresa

• Nome de um produto

Departamento de Engenharia Informática

Exemplos de Utilização

• Resolver para encontrar o objecto

– Endereço IP – Nome DNS

– Número de Telefone – URL

– Nome de ficheiro

• Resolver para obter um atributo do objecto

– Servidor de email de um domínio DNS – Morada associada a uma entrada UDDI – Nome da Empresa

• Resolver para verificar se o objecto é o mesmo

– Número do Bilhete de identidade – Nome de um produto

(3)

Sistemas Distribuídos 5

Conceitos Base

• Espaço de Nomes  conjunto de regras que

define um universo de nomes admissíveis

• Autoridade  gere o recurso que suporta a

implementação do objecto

– Define as regras de gestão dos identificadores

– Deve garantir que as regras de gestão de nomes são

cumpridas

– Autoridade pode ser delegada (hierarquias)

Departamento de Engenharia Informática

Gestão de nomes:

Nomes e autoridades

Nome

Autoridade

Endereço IP IANA (Internet Assigned Numbers Authority)

Endereço Ethernet Xerox e fabricante da placa Endereço do controlador de disco Configuração do computador Nome de um ficheiro Sistema de ficheiros

UUID DCE; IETF standard

(4)

Sistemas Distribuídos 7

Gestão de nomes: Conceitos base

• Identificador  mecanismo de discriminação de um objecto

– Sob controlo do sistema

• Sem carga semântica para os humanos • Sequências de bits

– Se o identificador permitir encontrar directamente o objecto é normalmente designado por endereço (um endereço pode deixar de referenciar o objecto se este mudar de localização)

• Nome  mecanismo de discriminação de um objecto

– Usado por humanos

• Programadores, utentes, etc.

• Com carga semântica para os humanos • sequências legíveis de caracteres

– Permite normalmente obter um identificador para o objecto

• Um nome num contexto pode ser um endereço noutro

• Nomes vs. Identificadores: nomes representam marcas  gera contenção. Exemplo: quem detém o nome nissan.com?

Departamento de Engenharia Informática

Nomes vs Endereços vs Caminhos

rmi://ist.utl.p t:1099/Arist oteles http://www.i st.utl.pt/~SD Devido ao IP routing, hoje em dia não é importante /SD/public _html/inde x.html Do Tagus Park, ir

para o sul durante 400 metros, virar à direita e depois à esquerda. Vive na 3ª casa à direita. Caminhos Sequences of names or addresses specifying steps to follow to get to named entities Sometimes called paths

??? inode #43876 130.235.63.13 inode #43876 Rua do Cruzeiro, n1, Oeiras Endereços

Identifiers of places to find the named entities Aristoteles (print server) SD Ficticio Home Page ccc3.ist.utl.pt index.html João Silva Nomes

(Abstract) strings or other data types that refer to specific entities in a system Um objecto remoto Uma pagina Web Um computador Um ficheiro Uma pessoa Exemplos

(5)

Sistemas Distribuídos 9

Associações nomenome e nomeobjecto

(bindings)

• O nome que identifica um objecto raramente é o

identificador que permite aceder-lhe

• A associação nomeobjecto é lógica

• A partir do nome de um objecto existe uma cadeia de

associações entre nomes, geralmente de espaço de nomes

diferentes

• Exemplo:

– Nome de ficheiro UNIX

a/b/c  i-number  inode  partição e bloco de disco

– Nó da rede Internet

mega.ist.utl.pt  endereço IP  endereço Ethernet

Departamento de Engenharia Informática

Gestão de nomes:

Conceitos base

• Contexto  conjunto de associações pertencentes a um

determinado espaço de nomes

– Define domínio em que se considera válidos um determinado conjunto de nomes

• Directório  tabela (ou conjunto de tabelas) que

materializa(m) as associações entre nomes e objectos de

um contexto

– Um directório também é um objecto que tem de ter um nome associado

(6)

Sistemas Distribuídos 11

Contexto vs. Directório

Contexto objectos Directório objectos Directório Contexto objectos Directório Contexto

Departamento de Engenharia Informática

Propriedades dos Nomes

• Unicidade referencial

• Âmbito

• Homogeneidade/heterogeneidade

• Pureza

(7)

Sistemas Distribuídos 13

Unicidade referencial

• Num determinado contexto, um nome só pode

estar associado a um objecto

– Caso contrário, haveria ambiguidade referencial

• Não se poderia distinguir o objecto • Não se poderia endereça-lo

– A situação inversa não é verdadeira, um objecto pode

estar associado a vários nomes

– Os nomes simbólicos são normalmente nomes

alternativos para um mesmo objecto no mesmo

contexto

Departamento de Engenharia Informática

Gestão de espaços de nomes:

Atribuição de nomes globais

• Problema: garantir a unicidade referencial

– É preciso garantir que um dado nome é resolvido sempre para o mesmo objecto em todo e qualquer contexto

• Soluções:

– Atribuição central

• Grande latência, ponto único de falha – Endereços IP oficiais (públicos) – Endereços Ethernet (de fábrica)

– Atribuição local e difusão para os outros contextos

• Impraticável em larga escala • Simples e prático em redes locais

(8)

Sistemas Distribuídos 15

Gestão de espaços de nomes:

Atribuição de nomes globais

– Nomes não estruturados com grande amplitude

referencial

• Podem ser atribuídos independentemente por qualquer contexto

• Podem ser gerados de forma pseudo-aleatoriamente ou mesmo totalmente aleatória

– Identificadores com 128 ou mais bits

– Nomes hierárquicos  nomes globais compostos pela

concatenação de nomes locais

– Números de telefone (ex. +351 21 3100000) – Nomes DNS (ex. mega.ist.utl.pt.)

– Nomes de ficheiros (ex. /a/b/b)

Departamento de Engenharia Informática

Nome Hierárquico

http://www.cdk3.net:8888/WebExamples/earth.html URL

Resource ID (IP number, port number, pathname)

Network address 2:60:8c:2:b0:5a file Web server 55.55.55.55 8888 WebExamples/earth.html DNS lookup Socket

(9)

Sistemas Distribuídos 17

Namespaces: Solução hierárquica de nomes no

XML

• Problema: troca de dados XML entre organizações

• <banco> pode referir-se a uma instituição bancária num documento e a uma peça de mobiliário noutro

• Solução: usar tags na forma “nome único : nome do elemento” • Para comprimir os nomes únicos usam-se XML Namespaces

<bank Xmlns:FB=‘http://www.FirstBank.com’> … <FB:branch> <FB:branchname>Downtown</FB:branchname> <FB:branchcity>Brooklyn</FB:branchcity> </FB:branch> … </bank>

Departamento de Engenharia Informática

Âmbito de um nome

• Global (absoluto)  um nome tem o mesmo significado

em todos os contextos onde o espaço de nomes é válido

• Independentes da localização do utilizador • Simples de transferir entre contextos

• Difíceis de criar para garantir a unicidade referencial

• Local (relativo)  O contexto apenas engloba parte do

sistema, os nomes são válidos só nesse contexto. Nomes

são atribuídos independentemente em cada contexto.

• Permite criação eficiente de nomes

• Nomes têm que ser traduzidos quando transferidos para outros contextos

• Exemplo: Endereços IP?

(10)

Sistemas Distribuídos 19

Heterogeneidade/Homogeneidade

• Homogéneo:

– Formado por uma única componente

• Endereço de uma placa Ethernet

– Formado por várias componentes com igual estrutura e significado

• Pathname UNIX: /a/b/c

• Heterogéneos

– Formado por várias componentes com estruturas e significados diferentes

• Pathname Windows: C:/a/b/c • URL: http://máquina:[porto]/a/b/c

Departamento de Engenharia Informática

Pureza dos nomes

Puro: o nome não contém informação sobre a localização do

objecto

– O nome não contém identificadores

– O nome não reflecte os mecanismos de resolução do sistema ☺ Flexibilidade, facilidade de reconfiguração

 Impraticável em larga escala

Impuro  parcelas do conteúdo do nome são utilizadas na

sua resolução

– O nome contém identificadores ou informação topológica – O nome reflecte os mecanismos de resolução do sistema

Realização fácil, extensível, escalável  Reconfiguração difícil

(11)

Exercício

• Âmbito, pureza, homogeneidade dos seguintes

espaços de nomes?

– Porto TCP/IP ou UDP/IP

– UUID - DCE/IETF

– Tag XML

– URN

– URL

– Número de rede num endereço IP (público)

Departamento de Engenharia Informática

Exemplos de âmbito e pureza

Pureza Puro Impuro Âmbito Global UUID - DCE/IETF Endereço Ethernet Número de rede num

endereço IP (público) URN

Porto TCP/IP ou UDP/IP URL

Endereço IP (público) Pathname AFS

Pathname UNIX (/XXX/)

Local

Nome de um ficheiro num directório UNIX Servidor Sun RPC Tag XML

i-numbers num directório UNIX Endereço IP (qualquer)

Pathname UNIX (XXX/) Pathname NFS

(12)

Sistemas Distribuídos 23

Persistência

• Uma referência é persistente se não estiver ligada

a nenhum domínio administrativo ou entidade

– Implica que o objecto possa mudar de domínio

administrativo sem que a referência seja perdida

• Exemplos:

– URLs: Problemático... Mudança de ISP implica um

“HTTP redirect” permanente no ISP anterior

– Números de telemóvel em Portugal: persistência foi

imposta por legislação

Departamento de Engenharia Informática

Propriedades do espaço de nomes:

Relevância consoante a acção

• Relevantes para o registo de nomes

(registo de

associações nomesobjecto)

– Unicidade referencial

– Âmbito

– Homogeneidade

– Persistência

• Relevantes para a resolução de nomes

(obtenção de

um objecto dado um nome)

(13)

Sistemas Distribuídos 25

Exemplo: URIs, URLs, URNs, etc.

• Visão “clássica” (anterior a meados do anos 90)

– URI é nomes que identifica um recurso na Internet. Divididos em:

• URN – Nomes puros (sem informação de localização) – Ex.: “ISBN:0-201-62433-8”

• URL – Nomes impuros (contêm localização) – Ex.: http://mega.rnl.ist.utl.pt/~ic-sod/

• Visão “contemporânea”

– Há alguns serviços que resolvem URNs em atributos, mas pouco usados.

• URN: identificador único, global, persistente de um recurso • Normalmente mapeados para um URL para serem localizados

– URLs muito usados

• Serviços que os usam tentam assegurar que localização é imutável

Departamento de Engenharia Informática

Exemplo: UUID na Interface em IDL DCE

[ uuid(00918A0C-4D50-1C17-9BB3-92C1040B0000), version(1.0) ] interface banco { typedef enum { SUCESSO, ERRO, ERRO_NA_CRIACAO, CONTA_INEXISTENTE, FUNDOS_INSUFICIENTES } resultado Identificador global, homogéneo, puro, persistente

Gerado por uma aplicação

(14)

Sistemas Distribuídos 27

Exemplo: Sun RPC

Resolução do nome Local ao servidor de nomes da máquina identificada em host bancoprog_1(char *host) { CLIENT *clnt; pedirExtratoIn pedirextrato_1_arg; #define MAXLINE 1024 char comando[MAXLINE];

clnt = clnt_create(host, BANCOPROG, BANCOVERS, "tcp"); if (clnt == (CLIENT *) NULL) {

clnt_pcreateerror(host); exit(1);

}

Departamento de Engenharia Informática

(15)

Sistemas Distribuídos 29

Serviços de Directório

• Os serviços de nomes

– tinham por objectivo efectuar a tradução de nomes em identificadores de objectos

– A sua estrutura era constituída por pares <nome, atributo>

• Serviços mais complexos podem armazenar relações entre

nomes e múltiplos atributos e permitir a pesquisa por

atributos

– São normalmente designados serviços de directórios. – Permite genericamente dois tipos de serviços de procura:

• White-pages: capacidade de procura por nome

• Yellow-pages: capacidade de procura por conteúdo semântico associado aos nomes

Departamento de Engenharia Informática

Serviços de Directório

• Um directório é constituído por:

– Esquema – mapa lógico da base de dados. O esquema inclui quais os objectos que podem ser criados, os atributos dos objectos, e os tipos de dados

– Classes – tipos abstractos que podem ser herdados – Atributos – define informação sobre objectos

– Valores – para um atributo ter significado tem de ser instanciado por um valor

– Objecto – instancia de uma classe com os respectivos atributos

• Os serviços de directório podem ser usados para diversos

nomes utilizados pelo sistema ou por aplicações ex.:

utilizadores, credenciais de segurança, etc.

(16)

Sistemas Distribuídos 31

Arquitectura dos Serviços de Nomes e

Directório

Departamento de Engenharia Informática

Serviços de nomes: Funcionalidade

• Registo das associações

– Verifica se a sintaxe do nome respeita o espaço de nomes – Armazena a associação

• Distribuição das associações

– Actualização dos directórios nos contextos onde a associação deve ser válida

• Resolução dos nomes

– Tradução do nome noutro nome ou num identificador

– Normalmente feita sem conhecimento da estrutura completa do nome

– Processo pode ser repetido recursivamente em vários níveis

• Resolução inversa

(17)

Sistemas Distribuídos 33

Serviços de nomes:

Características dos sistemas distribuídos

• Larga escala

• Distribuição geográfica

• Heterogeneidade de nomes e protocolos

• Necessidade de grande disponibilidade

– Uso de caches

• Estabilidade

– Os nomes variam pouco

• Consistência fraca

– Manutenção de caches com algum grau de erro

Departamento de Engenharia Informática

Arquitectura dos serviços de nomes:

Evolução da Arquitectura

1)

Ficheiros replicados em todas as máquinas

Ficheiros UNIX /etc/hosts, /etc/services, etc. Ficheiro Windows LmHosts

2)

Pedido em difusão

– respondendo o nó que tem o objecto

NetBIOS IP ARP

3)

Arquitectura cliente-servidor (solução habitual)

– Pergunta directa dos clientes a servidores específicos

(18)

Sistemas Distribuídos 35

Arquitectura dos serviços de nomes:

Componentes

• Agente do serviço de nomes

– Efectua o processamento do cliente

– Oferece uma interface ao programador

• Servidores de nomes

– Realizam o serviço de nomes

• Base de dados de nomes

– Mecanismo de armazenamento persistente da

informação nos servidores

Departamento de Engenharia Informática

Arquitectura dos serviços de nomes:

Diagrama de interacções

aplicação Código que usa o SN Agente do SN servidor servidor servidor servidor Informação do SN

(19)

Sistemas Distribuídos 37

Arquitectura dos serviços de nomes:

Agente

• Conjunto de utilitários e rotinas de adaptação (stubs)

– Que efectuam os pedidos aos servidores

– Exemplos: gethostbyname, gethostbyaddr, JNDI – Java naming & Directory Interface

• Localização do(s) servidor(es):

– Porto do servidor é fixo (well-known)

• Ex. Sun RPC, DNS

– Difusão periódica do endereço dos servidores – Pedido do cliente em difusão

• Ex. NIS

Departamento de Engenharia Informática

Arquitectura dos serviços de nomes:

Modelos de resolução de nomes

• Iterativo:

– o servidor resolve a parte do nome que conseguir

– e devolve o restante ao cliente, que reencaminha o pedido para outro servidor

• Recursivo:

– o servidor resolve a parte do nome que conseguir

– e reenvia o pedido a outro servidor, até terminar a resolução do nome

– Quando o processo terminar responde ao cliente

• Transitivo:

– o servidor resolve a parte do nome que conseguir

(20)

Sistemas Distribuídos 39

Arquitectura dos serviços de nomes: Comparação

dos modelos

• Iterativo:

– A mais complexa para o agente

• Pode interactuar com vários servidores • Tem que manter contexto de resolução • Mais fácil lidar com falhas

• Recursivo:

– A mais simples para o agente • Apenas interactua com um servidor – A mais complexa para os servidores

• Tem que manter contexto de resolução – Permite fazer caching nos servidores

– Simplifica a coabitação com barreiras de segurança

• Transitivo:

– Simplifica clientes e servidores

– Responsabilidade da tradução fica diluída

Departamento de Engenharia Informática

Arquitectura dos serviços de nomes:

Modelos de resolução de nomes

• Baseada em multicast

• Iterativo

• Interativo controlado pelo servidor

• Recursivo

(21)

Sistemas Distribuídos 41

Arquitectura dos serviços de nomes:

Modelo de resolução baseado em multicast

• Cliente envia nome a resolver em difusão para

múltiplos servidores de nomes

• Quem souber, responde

• O que assumir se ninguém responde?

• Escalável para redes de grande escala?

Departamento de Engenharia Informática

Arquitectura dos serviços de nomes:

Modelo de resolução iterativo

Client 1 2 3 NS2 NS1 NS3 Name servers

(22)

Sistemas Distribuídos 43

Arquitectura dos serviços de nomes:

Modelos de resolução controlada pelo servidor

1 2 3 5 1 2 3 4 4 client client Recursiva NS2 NS1 NS3 NS2 NS1 NS3 Iterativa

controlada pelo servidor

Departamento de Engenharia Informática

Arquitectura dos serviços de nomes: Comparação

dos modelos

• Iterativo:

– A mais complexa para o agente

• Pode interactuar com vários servidores • Tem que manter contexto de resolução • Mais fácil lidar com falhas

• Recursivo:

– A mais simples para o agente

• Apenas interactua com um servidor

– A mais complexa para os servidores

• Tem que manter contexto de resolução

– Permite fazer caching nos servidores

– Simplifica a coabitação com barreiras de segurança

• Iterativo controlado pelo servidor

(23)

Sistemas Distribuídos 45

Arquitectura dos serviços de nomes:

Servidores

• Aproximação simplista: servidor centralizado

– Ponto singular de falha – Excesso de informação – Estrangulamento no acesso

– Complexidade do controlo de acesso

• Aspectos relevantes para a optimização:

– Os nomes mudam com pouca frequência

– Incoerências na resolução de nomes são normalmente toleráveis • Podem ser contornadas por repetição da resolução

É viável usar caches ou replicação em clientes e servidores intermediários

Departamento de Engenharia Informática

Arquitectura dos serviços de nomes:

Servidores e caches

• Um servidor centralizado, caches nos clientes

– Não existe partilha das caches pelos clientes

– Não facilita os registos

• Múltiplos servidores e caches

– Caches em servidores intermédios podem ser usadas

por vários clientes

(24)

Sistemas Distribuídos 47

Análise de Serviços de Nomes

Departamento de Engenharia Informática

Exemplos de Serviços de Nomes e

Directório

• Serviço de Nomes

– DNS (Domain Name System)

• Serviços de Directórios

– NIS (Network Information System) – X500

– Active Directory da Microsoft – DCE:

• CDS (Cell Directory Service) • GDS (Global Directory Service)

(25)

Sistemas Distribuídos 49

Características Genéricas

• Organização do espaço de nomes

– Esquema de nomes – estrutura, atributos

– Propriedades

• Arquitectura Cliente-servidor

– Esquema de autoridades

– Persistência

– Disponibilidade

• Replicação de Servidores

– Desempenho

• Cache em clientes e servidores

Departamento de Engenharia Informática

DNS (Domain Name Service):

Introdução

• Arquitectura para registo e resolução de nomes de

máquinas da Internet

– Inicialmente proposta em 1983

• Concretizações:

UNIX: BIND (

Berkeley Internet Name Domain

)

Microsoft: Windows 2000 DNS

(26)

Sistemas Distribuídos 51

DNS:

Características

• Espaço de nomes hierárquico, e homogéneo

• Âmbito dos nomes:

– Global (Fully Qualified Domain Name) Ex. mega.ist.utl.pt.

– Local (resolvido no domínio corrente) Ex. mega

• Cada contexto designa-se por domínio

• Cada domínio é gerido por uma entidade administrativa:

– Pode criar e remover nomes – Resolve nomes

– Pode delegar responsabilidades em sub-domínios

• Nomes impuros

Departamento de Engenharia Informática

DNS: Estrutura

Note: Name server names are in italics, and the corresponding domains are in parentheses.

Arrows denote name server entries a.root-servers.net (root) ns0.ja.net (ac.uk) dns0.dcs.qmw.ac.uk (dcs.qmw.ac.uk) alpha.qmw.ac.uk (qmw.ac.uk) dns0-doc.ic.ac.uk (ic.ac.uk) ns.purdue.edu (purdue.edu) uk purdue.edu ic.ac.uk qmw.ac.uk dcs.qmw.ac.uk *.qmw.ac.uk *.ic.ac.uk *.dcs.qmw.ac.uk * .purdue.edu ns1.nic.uk (uk) ac.uk co.uk yahoo.com

(27)

Sistemas Distribuídos 53

DNS: Estrutura

edu

com net org

mit

lcs

amazon Gerido pelo

Internet Network Information Center

Gerido pelo MIT

MIT

linux

iso gov / int / mil

MIT Domain . Nome de domínio Tipo de organização com Comercial edu Educação org Sem fins lucrativos net Redes

gov Governamental (não militar)

mil Governamental e militar num Números de telefone arpa Reverse DNS xx Código de país

(2 letras) ISO 3166

Departamento de Engenharia Informática

DNS: Zonas

• Unidades de fraccionamento da hierarquia de autoridades

• Uma zona é uma unidade de administração:

– Cada domínio pertence a uma zona

– Cada zona pode gerir um ou mais domínios – A Zona constitui a autoridade.

(28)

Sistemas Distribuídos 55

Servidores DNS

• Associado a uma zona existe sempre um servidor

– Contém a base de dados com os nomes desse conjunto de domínios

• Servidor sempre replicado

– Primário: mantém a base de dados, onde se efectuam as actualizações

– Secundário: contém uma cópia da informação do primário, actualizada periodicamente com um protocolo dedicado

• Todos os servidores mantêm caches

– Validade indicada pelo parâmetro TTL

• Cada servidor indica a sua autoridade sobre os dados que

fornece

– Primário: autoridade total sobre os dados do domínio – Secundários: não possuem autoridade alguma

Departamento de Engenharia Informática

DNS: Esquema de Informação

• Registos RR (Resource Register)

– Pares nomevalor tipificados – A tipificação exprime:

Classe: família de nomes (ex. IN para endereços IP) Tipo: semântica de utilização do nome

– Cada RR possui um TTL (time to live)

• Serve para invalidar periodicamente RR em cache

• Informação estrutural (RRs do tipo NS)

(29)

Sistemas Distribuídos 57

DNS: Tipos de registos

Tipo de registo Conteúdo

A Endereço IP

CNAME Nome simbólico para outro nome DNS HINFO Arquitectura e sistema operativo do nó NS Servidor de uma zona

MX Máquina ou domínio do servidor preferencial de e-mail SOA Parâmetros que definem a zona

PTR Nome DNS para resolução inversa de um endereço IP TXT Texto arbitrário

WKS Descrição de um serviço com os respectivos nomes e protocolos

Departamento de Engenharia Informática

DNS:

Informação do domínio ist.utl.pt

$ORIGIN ist.utl.pt.

@ 1D IN SOA ciistr1 root.ciistr1 ( 1999080607 ; serial 4H ; refresh 2H ; retry 1W ; expiry 1D ) ; minimum

ciistr1 1D IN TXT "The_Domain_Name_Server_for ist.utl.pt" www 1D IN CNAME ci ftp 1D IN CNAME ci proxy 1D IN CNAME ci samba 1D IN CNAME ci @ 1D IN NS ciistr1 1D IN NS alfa 1D IN NS ci 1D IN NS ns.utl.pt. 1D IN NS civil2.civil 1D IN NS inesc.inesc.pt. rnl 1D IN NS ns2.rnl 1D IN NS ciistr1 1D IN NS ns.rnl @ 1D IN MX 5 ciistr1 secreta 1D IN MX 5 seca Definições da zona (Obrigatório no ficheiro do primário) Servidores da zona ist.utl.pt Servidores da zona rnl.ist.utl.pt alfa 1D IN A 193.136.128.24 Nomes simbólicos Servidores de email Nome IP

(30)

Sistemas Distribuídos 59

DNS:

Resoluções recursivas ou iterativas

resolver pt sapo www recursive query pt. Name Server . Name Server (root server) sapo.pt. Name Server Name Server 1 8 2 3 4 5 6 7 iterative queries

o cliente pede o IP de www.sapo.pt. .

Departamento de Engenharia Informática

BIND

Berkeley Internet Name Domain

• Implementação do DNS para Unix

• Contém 2 componentes:

– resolver: conjunto de rotinas cliente

• Integradas na biblioteca de C (/lib/libc.a) • Usadas pelas rotinas de resolução de nomes

(gethostbyname, gethostbyaddr)

(31)

Sistemas Distribuídos 61

BIND - Servidores de Nomes

• Master: autoridade no domínio

– Mantém todos os dados do domínio – Carrega a base de dados de disco

– Secondary master: na inicialização recebe a base de dados do primary server. Periodicamente contacta o primary master para a actualizar – Um servidor pode ser master para mais que um domínio, sendo primary

para um e secondary para outros

• Caching: apenas mantém dados em cache

– Contacta os outros servidores para obter a informação – Não é autoridade para nenhum domínio

• Remote: servidor remoto

• Slave: redirige os pedidos que não consegue servir para uma lista de servidores, e não para os master

Departamento de Engenharia Informática

Exemplo de Arquitectura

do BIND

Servidor Secundário Programa Utilizador resolve Servidor de Reencaminha-mento Resposta Servidor Primário Pedido Actualização

(32)

Sistemas Distribuídos 63

NIS (Network Information System)

• Arquitectura para resolução de nomes usados pelos

sistemas operativos UNIX numa rede local proposta pela

SUN

– Inicialmente chamado YP (Yellow Pages)

– Permite simplificar a gestão de ficheiros de configuração UNIX:

• Surgiu em conjunto com o NFS

hosts passwd group services … / etc

Departamento de Engenharia Informática

Evolução

• Se os nomes DNS das máquinas podem ser

eficazmente guardados num serviço distribuído

porque não estender o serviço para guardar a

maioria de informação de gestão da rede e dos

sistemas que pode haver interesse de aceder de

forma distribuída

• Objectivos

– Simplifica a mobilidade dos utilizadores

– Reduz inconsistência

(33)

Sistemas Distribuídos 65

NIS: Espaço de Nomes

• Espaço de nomes local e heterogéneo

– Nomes impuros: (domínio, mapa, chave)

• Cada espaço de nomes designa-se por domínio

– Não existe qualquer relação entre domínios diferentes – Um domínio NIS ≠ domínio DNS

• Mas o NIS pode actuar como intermediário entre o cliente e o DNS para resolver nomes DNS

• Cada domínio possui um conjunto de mapas

– Um mapa é um contexto para resolver nomes (chaves) de dado tipo

• Nome ou IP de máquina, username ou UID de utente, etc.

– Cada tipo de nome pode ser resolvido em um ou mais mapas

• A escolha do mapa é feita por quem pede a resolução • Em cada mapa o nome pode referenciar objectos diferentes

Departamento de Engenharia Informática

NIS: Estrutura

• Em cada domínio existe

– Um servidor mestre

– Zero ou mais servidores escravos

• Servidor mestre

– Os seus mapas são construídos a partir dos ficheiros UNIX locais – Actualiza os mapas dos escravos quando os seus são actualizados

• Servidor escravo

– Possui uma cópia local dos mapas do mestre – Pode importar em qualquer momento novas cópias

(34)

Sistemas Distribuídos 67

NIS: Acesso aos servidores

• Em cada máquina existe um servidor de ligação (ypbind)

– O ypbind descobre um servidor ypserv por difusão – As aplicações interagem sempre com o ypbind local

Máquina A Aplicação Máquina B ypbind ypserv Biblioteca C RPC RPC Mapas

Departamento de Engenharia Informática

NIS: Mapas

• Os mapas são listas de pares nomevalor onde:

– Os valores são tipicamente linhas completas dos ficheiros UNIX originais

– Os nomes são componentes dessas mesmas linhas

hosts.byname: mega  ”mega 146.193.4.38” hosts.byaddr: 146.193.4.38  ”mega 146.193.4.38”

• Cada ficheiro pode originar vários mapas

– Um mapa por cada tipo de resolução pretendida

/etc/passwd  passwd.byname, passwd.byuid /etc/hosts  hosts.byname, hosts.byaddr

(35)

Sistemas Distribuídos 69

NIS:

Tipos de resoluções

• Directas

– Dado um nome e um mapa, é devolvido um valor

getpwuid ( UID )  linha de /etc/passwd (estruturada)

• Iterativas

– São devolvidos sequencialmente todos os pares nomevalor de um mapa

• A iteração é feita pelo cliente com vários RPCs • Os servidores não mantêm estado

get_first ( domain, map ) get_next ( domain, map, last )

– É devolvido um mapa sobre o qual o cliente itera

• A iteração é feita pelo cliente após um RPC

Departamento de Engenharia Informática

Norma X.500: Introdução

• Arquitectura para um directório de nomes em aplicações

informáticas à escala mundial

– Inicialmente proposta em 1988

– Foi desenhado para armazenar informação respeitantes a países, organizações, pessoas, máquinas, etc.

• Concretizações:

– DCE GDS, NDS (Novell), Active Directory (Microsoft) – Protocolo de acesso LDAP

(36)

Sistemas Distribuídos 71

X.500: Características

• Espaço de nomes global, hierárquico e homogéneo

– Nomes impuros

• Cada entrada é uma instância de uma classe (object class)

– Cada classe define os atributos obrigatórios e opcionais dos objectos que os nomes podem referir

– Um objecto pode ser referenciado por entradas pertencentes a diferentes classes

• Cada entrada da hierarquia é formada por um conjunto de atributos

– Cada atributo tem um tipo e um ou mais valores – Um nome é uma selecção dentro desses atributos

• O conjunto de classes define o “esquema” do espaço de nomes

Departamento de Engenharia Informática

X.500: Características

• Tipos de nomes:

– Relative Distinguished Name (RDN)

• Nome que identifica uma entrada concreta num dado contexto de resolução (Nome local)

C = PT O = IST OU = Secretaria

– Distinguished Name (DN)

• Concatenação não âmbigua de RDNs desde a raíz (nome global)

/…/C=PT/O=IST/OU=Secretaria

• Sintaxe dos nomes

– O X.500 não define

• Apenas define a sua estrutura – Cada concretização usa a sua sintaxe

• A interacção é garantida por troca de informação estrutural

(37)

Sistemas Distribuídos 73

X.500: Exemplo

... France (country)Great Britain (country)Greece (country)...

BT Plc (organization)University of Gormenghast (organization)

... ...

Department of Computer Science (organizationalUnit) Computing Service (organizationalUnit)

Engineering Department (organizationalUnit) ...

... X.500 Service (root)

Departmental Staff (organizationalUnit)

Research Students (organizationalUnit) ely (applicationProcess)

...

...

Alice Flintstone (person) Pat King (person)James Healey (person) ...

... ... Janet Papworth (person)

Departamento de Engenharia Informática

X.500: Estrutura

• DIB (Directory Information Base)

– Contém toda a informação do serviço de nomes

• DIT (Directory Information Tree)

– Contém a informação estrutural do DIB

• Classes de objectos

– Cada nível da hierarquia é descrito por uma classe de

objectos

(38)

Sistemas Distribuídos 75

X.500: Arquitectura

• DSAs (Directory Service Agents)

– Servidores

• DUAs (Directory User Agents)

– Clientes

Departamento de Engenharia Informática

X.500: Arquitectura

DSA

DSA

DSA

DSA

DSA

DSA

DUA

DUA

DUA

(39)

Sistemas Distribuídos 77

X.500: Esquema de classes

N a m e B in d i n g D e fi n i t io n Mandatory Opcional DIT Structure Naming Naming Rule in force Attributes Attributes

D IT Co n t e n t R u le D e fi n i t io n Mandatory Optional Precluded Allowed Attributes Attributes Attributes Auxiliary Object Classes

Object Mandatory Optional Subclass Class Attributes Attributes Of Kind

Obje c t Cla s s D e fi n i tio n

D IT S t ru c t u re R u le Allowed Superior

Structure Rules

Att ri bu te D e fi n i t i o n

Subtype Attribute Matching Operational Multi - Collective Derivation Syntax Rules Attribution valued Attributed Defined Flag Flag Flag

Ma tc h i n g R u le s Assertion

Syntax

S t ru c t u ra l o bje c t c la s s

Departamento de Engenharia Informática

Lightweight Directory Access Protocol - LDAP

• Baseado na proposta da Universidade de Michigan em que

o acesso ao Directório X500 é efectuado directamente

sobre TCP/IP.

• Define o protocolo não a estrutura do servidor

• O LDAP substituiu a codificação ASN.1 por caracteres

(texto).

• A API também é mais simples

• O LDAP pode ser usado com Directórios que não sejam

X500 o exemplo mais importante é a utilização do Active

Directory da Microsoft

(40)

Sistemas Distribuídos 79

Active Directory

• Introduzido pela Microsoft em 2000

• Um directório é constituído por uma floresta que contém

uma ou várias árvores do Active Directory

• Active Directory – algumas características:

– servidor DNS – Usa LDAP

– Kerberos para autenticação

– ACL para controlar o acesso aos objectos – Certificados X.509

Departamento de Engenharia Informática

Universal Description Discovery &

Integration (UDDI)

(41)

Sistemas Distribuídos 81

Universal Description Discovery & Integration

(UDDI)

• Definição de um conjunto de serviços que suportam a descrição e a localização de:

– Entidades que disponibilizam Web Services (empresas, organizações) – Os Web Services disponibilizados

– As interfaces a serem usadas para aceder aos Web Services

• Baseada em standards Web: HTTP, XML, XML Schema, SOAP • Norma definida por um consórcio alargado: Accenture, Ariba,

Commerce One, Fujitsu, HP, i2 Technologies, Intel, IBM, Microsoft, Oracle, SAP, Sun e Verisign

• Versão actual: UDDI Version 3.0, 19 Jul 2002 • http://uddi.org/pubs/uddi_v3.htm

Departamento de Engenharia Informática

Informação representada na UDDI

• A UDDI permite pesquisar informação muito variada

sobre os Web Services. Ex:

– Procurar Web Services que obedeçam a uma determinada interface abstracta

– Procurar Web Services que estejam classificados de acordo com um esquema conhecido de classificação

– Determinar os protocolos de transporte e segurança suportados por um determinado Web Service

– Procurar Web Services classificados com uma palavra-chave

• O acesso é via as API definidas mas os operadores também

disponibilizam sites para acesso via web

(42)

Sistemas Distribuídos 83

Modelo estrutural da informação

• businessEntity: descreve uma empresa ou organização

que exporta Web Services

– A informação encontra-se conceptualmente dividida em:

– Páginas brancas – informação geral de contacto

– Páginas amarelas – Classificação do tipo de serviço e localização – Páginas verdes – Detalhes sobre a invocação do serviço

• businessService: descreve um conjunto de Web Services

exportado por uma businessEntity

• bindingTemplate: descreve a informação técnica

necessária para usar um determinado serviço

• tModel: descreve o “modelo técnico” de uma entidade

reutilizável, como um tipo de Web Service, o binding a um

protocolo usado por um Web Service, etc.

Departamento de Engenharia Informática

(43)

Sistemas Distribuídos 85

Modelo estrutural da informação

Pag 186

Departamento de Engenharia Informática

Exemplo: Modelo estrutural da informação

TModel: NAICS Key: COB9FE13 -179 - 413D - 8A5B 5004DB8E5BB2 TModel: UNSPSC Key: C1ACF26D -9672 – 4404 - 9D70 39B756E62AB4 TModel: GEO Key: C1ACF26D -9672 – 4404 - 9D70 39B756E62AB4 TModel: D-U-N-S Key: C1ACF26D -9672 4404 - 9D70 39B756E62AB4

TModel: SEMC IeBS Key: 61A08700 -0684 – 4E05 – BB7D 39B756E62AB4 TModel: e-Torus Key: F2390501 -A240 – 4470 – 8A5A 6088EE5B1A14 TModels businessService “Catalog” bindings categoryBag (Yellow Pages) web accessPoint: (URL) tModels businessService “Order Status” bindings categoryBag (Yellow Pages) web accessPoint: (URL) tModelsSOAP accessPoint: (URL) tModels BusinessEntity (White Pages) Name: SkatesTown description: contacts: businessServices identifierBag categoryBag (Yellow Pages)

(44)

Sistemas Distribuídos 87

BusinessEntity

• Conceito mais alto na hierarquia

• Contém informação descritiva sobre a empresa

• É identificado por uma

businessKey que é definida no registo ou criada nessa altura pelo registry

• Tens as referências para os serviços que disponibiliza • CategoryBag permite

descrever a entidade de acordo

com várias taxonomias <categoryBag> <keyedReference

tModelKey=”uddi:ubr.uddi.org:categorization:geo3166—2” keyName=”Connecticut. USA”

keyVa] ue=”US-CT” /> </categoryBag>

Departamento de Engenharia Informática

businessService

• Referencia um serviço lógico e tem a descrição de um Web

Service em termos de negócio

• Tem uma chave própria e uma chave para o businessEntity

de que descende

• CategoryBag serve para descrever o serviço de acordo com

múltiplas taxionomias

(45)

Sistemas Distribuídos 89

bindingTemplate

• Contém a informação necessária para que o cliente

possa invocar o serviço

<bindingTemplates>

<bindingTemplate bindingKey=”” serviceKey=””

<description>Flute ATM Service via HTTP</description> <accessPoint URLType=”http”>

http://www.f1utebank.com/services/accesspoint> </bindingTemplates>

Departamento de Engenharia Informática

tModel

• Permitem a reutilização e a normalização dentro da

arquitectura do serviço UDDI

• Os technology Models são descritos no tModel e efectuam

a ligação à implementação concreta de um serviço

• Cada tmodel é identificado univocamente por um uuid que

constitui a sua chave

• A unicidade de referência aos tmodels evita duplicações

• Um tmodel para um web service tem a referência para o

(46)

Sistemas Distribuídos 91

Key Name Description URL

1 Java-class Represents a fully qualified name of a java class

http://www.javasoft.com

2 Jndi-home Represents a JNDI name. Look at the J2EE specification

http://www.javasoft.com

company name: mycompany company name: mycompany company name: mycompany company name: mycompany Service name: helpline Service name: helpline Service name: helpline Service name: helpline

tModel: key=11 (representing telephoneline), name=telephone, tModel: key=11 (representing telephoneline), name=telephone, tModel: key=11 (representing telephoneline), name=telephone, tModel: key=11 (representing telephoneline), name=telephone, description=telephone, stuff, url: some at&t url description=telephone, stuff, url: some at&t url description=telephone, stuff, url: some at&t url description=telephone, stuff, url: some at&t url binding: binding: binding: binding: accesspoint: 1 accesspoint: 1 accesspoint: 1

accesspoint: 1----800800800800----mymymymy----helpline helpline helpline helpline tModelInstanceInfo: 11

tModelInstanceInfo: 11 tModelInstanceInfo: 11 tModelInstanceInfo: 11

Departamento de Engenharia Informática

Taxionomia

• Os serviços registados devem ser categorizados em

taxionomias que os permitam pesquisar

• Existem várias taxionomias normalizadas, ex.:

– ISO 3166 – geografias

– D-U-N-S – Data Universal Numbering System – Dun&Bradstreet – UN/SPSC- produtos e serviços – ONU

• O UDDI permite que todas as entidades sejam

classificadas

• As pesquisas podem usar múltiplas classificações

• Para uso interno das organizações podem ser definidos os

seus esquemas de classificação. Ex.: qualidade de serviço

do fornecedor do web service

(47)

Sistemas Distribuídos 93

Arquitectura UDDI - Registries

• Um Registry é composto por um ou mais nós

UDDI

• Os nós de um Registry gerem colectivamente um

conjunto bem definido de dados UDDI.

Tipicamente, isto é suportado com replicação entre

os nós do Registry

• A representação física de um Registry é deixada à

escolha das implementações

Departamento de Engenharia Informática

Registry Server privado

• Gere a base de dados com

os registos UDDI

• Modos de acesso

– Aplicações JAX-R – Registry Browser – Xindice

• Interfaces

– API

(48)

Sistemas Distribuídos 95

UDDI Operators

• Operadores públicos que disponibilizam informação

estruturada de acordo com o UDDI

• IBM Microsoft - fecharam o teste no final de 2005

http://uddi.sap.com

• Um operador tem de aderir a um conjunto de regras sobre,

replicação dos dados, politica de privacidade, politica de

segurança.

• Os serviços poderiam ser registados em qualquer operador

e seriam replicados aos Registries dos restantes

• Contudo existe informação adicional que o operador pode

pedir e que não é replicada

Departamento de Engenharia Informática

Arquitectura UDDI – APIs e nós

• Node API sets:

– Inquiry, Publication, Security, Custody Transfer, Subscription, Replication

• Client API sets:

– Subscription Listener, Value Set

• Nó UDDI

– Suporta a interacção com Dados UDDI através de uma ou mais UDDI API sets

– É membro de exactamente um UDDI registry

– Conceptualmente tem acesso e manipula uma cópia lógica dos dados UDDI do seu UDDI registry

(49)

Sistemas Distribuídos 97

API UDDI

• API de Mensagens para as funções CRUD (

create,

retrieve, update, delete

) definidas pelas UDDI Spec

Business Service Binding tModel Save/Update save_business save_service save_binding save_tModel Delete delete_business delete_service delete_binding delete_tModel Find find_business find_service find_binding find_tModel GetDetail get_businessDetail get_serviceDetail get_bindingDetail get_tModelDetail

Departamento de Engenharia Informática

API na Norma

• Node API Sets

– UDDI Inquiry

– UDDI Publication

– UDDI Security

– UDDI Custody Transfer

– UDDI Subscription

– UDDI Replication

• Client API Sets

– UDDI Subscription Listener

– UDDI Value Set

(50)

Sistemas Distribuídos 99

Inquiry API Set

• Permite localizar e obter informação sobre registos de um

UDDI Registry. Suporta 3 tipos de padrão:

– Browse: dirigida à listagem dos serviços existentes. Ex:

• Lista a informação disponibilizada por uma organização

• Informação dessa lista é usada para descer na árvore e pesquisar essa informação

– Drill-down: dirigida à obtenção de informação detalhada sobre determinados serviços

• Usa a chave única de cada entidade e API’s como get_businessDetail para obter a informação detalhada dessa entidade

– Invocação: obtém o binding template que permite comunicar com o Web Service

• É uma API não autenticada

Departamento de Engenharia Informática

Publication API Set

• Funções que permitem publicar e actualizar a

informação de um UDDI Registry

• Todas as entidades têm uma chave única, atribuída

pelo sistema ou escolhida por quem publica o

(51)

Sistemas Distribuídos 101

Subscription API Set

• Permite que clientes se registem para receberem

informações sobre alterações num UDDI Registry.

• Podem ser recebidas notificações relativamente às

seguintes entidades:

– businessEntity – businessService – bindingTemplate – tModel – related businessEntity – publisherAssertion

Departamento de Engenharia Informática

JAX-R

(52)

Sistemas Distribuídos 103

Registry Server

Ferramentas de Acesso

• Registry Browser

– Utiliza a API JAX-R $> jaxr-browser

ou

Start -> ... -> jwsdp -> JAX-R Registry Browser

• Xindice

– Acesso directo aos registos da BD

http://localhost:8080/Xindice/

Departamento de Engenharia Informática

JAX-R

(53)

Sistemas Distribuídos 105

JAX-R API

Estruturas de dados

• O JAX-R tem um modelo de

dados muito próximo do

standard UDDI

– O mapeamento de um para outro é quase directo

– Só mudam alguns nomes

• Pacote de classes que

implementam o modelo de

dados:

– javax.xml.registry.infomodel

Departamento de Engenharia Informática

JAX-R API

Classes Principais

• Connection

– Representa a ligação entre o cliente JAX-R e o servidor JAX-R (Registry Server)

– Efectua a autenticação necessária

• RegistryService

– Publicação

• BusinessLifeCycleManager – Adicionar e remover registos

– Tipicamente, é feito sobre uma ligação autenticada

– Pesquisa

• BusinessQueryManager – Consultar registos

(54)

Sistemas Distribuídos 107

JAX-R API

Publish

• Regista no Registry os vários tipos de informação associados a

uma organização

– contactos, serviços e localizações de serviços

• Devolve uma chave que identifica univocamente o serviço

• Exemplo:

BusinessLifeCycleManager blcm;

Organization org = blcm.createOrganization(“my.org”);

// preencher org com os seus dados

Collection orgs; orgs.add(org);

String key = blcm.saveOrganizations(orgs);

Departamento de Engenharia Informática

JAX-R API

Delete

• Elimina um registo do Registry usando a chave do

serviço

• Exemplo:

BusinessLifeCycleManager blcm; Collection keys;

// adicionar ao keys as chaves dos serviços a remover

(55)

Sistemas Distribuídos 109

JAX-R API

Inquiry

• Procura serviços que respeitem um dado critério de selecção:

– findQualifiers – namePatterns – classifications – specifications – externalIdentifiers – externalLinks

• Exemplo:

BusinessQueryManager bqm;

// passar como argumentos os critérios de procura

Referências

Documentos relacionados

O presente Termo de Compromisso tem por objeto a destinação de resíduos sólidos recicláveis separados na Coleta Seletiva Solidária praticada nas dependências da Empresa às

Espírito Santo Rendimento Dinâmico – Fundo Especial de Investimento Aberto Espírito Santo Rendimento Fixo – Fundo Especial de Investimento Aberto Espírito Santo Rendimento Fixo

O velho homem que temos que crucificar é a velha vida de pecado, antigas formas de pensar e falar. Deixar o velho homem também pode significar deixar um antigo sistema de vida e

Desde 1988 que o Parlamento Europeu atribui o Prémio Sakharov para a Liberdade de Pensamento a pessoas e organizações que tenham dado um contributo excecional para a luta em

Outra característica marcante dessa onda evangélica é sua articulação com a cultura popular. Porém, entre 1800 e 1850, batistas e metodistas no Sul dos Estados Unidos não

Nesse item a banca queria saber se o candidato sabia qual o significado (tradução) do termo “FOR INSTANCE”. Aqui não é preciso ter grandes conhecimentos de gramática. Aliás,

Mesmo considerando que a minha geração, de certa forma, rompeu com o marxismo, com o socialismo oficial, com o stalinismo, vamos dizer assim, nós, socialistas, grande parte com

De acordo com a Resolução Normativa 279, publicada pela Agência Nacional de Saúde Suple-mentar (ANS) em 25/11/2011, com vigência a partir de 01 de junho de 2012, que