8/28/2003 José Alves Marques 1
Gestão de nomes
Departamento de Engenharia Informática
Gestão de nomes: Objectivo
• Associar nomes a objectos para:
– Identificar os objectos
– Localizar os objectos
– Partilhar os objectos
– Simplificar a interface com os utentes
– Simplificar a gestão do sistema
8/28/2003 José Alves Marques 3
Gestão de nomes: Conceitos base
• Identificador mecanismo de discriminação de um objecto– Atribuído por uma autoridade
• Sem carga semântica para os humanos • Sequências de bits
– Se o identificador permitir encontrar 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
– Atribuído 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
• Autoridade gere o objecto
– Suporta a sua concretização
– Define as regras de gestão dos identificadores
– Deve garantir que as regras de gestão de nomes são cumpridas
Departamento de Engenharia Informática
Gestão de nomes:
identificadores e autoridades
FCCN em Portugal Nome DNS
DCE; IETF standard UUID Sistema de ficheiros Nome de um ficheiro
Autoridade
Identificador
Configuração do computador Endereço do controlador de discoXerox e fabricante da placa Endereço Ethernet
IANA (Internet Assigned Numbers Authority) Endereço IP
Gestor de memória virtual no SO Endereço de memória real
8/28/2003 José Alves Marques 5
Gestão de nomes:
Conceitos base
• Espaço de Nomes
conjunto de regras que define um
universo de nomes admissíveis
• Contexto
domínio em que se considera valido um
determinado espaço de nomes
• Directório
tabela que num contexto descreve as
associações entre nomes e objectos
– Um directório também é um objecto que tem de ter um nome associado
Departamento de Engenharia Informática
Conceitos de Base
Contexto objectos Directório objectos Directório Contexto Contexto8/28/2003 José Alves Marques 7
Associações nome objecto
• O nome porque um objecto é conhecido raramente é o
identificador que lhe permite aceder
• A associação nome objecto é 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
Propriedades dos Nomes
• Unicidade referencial
• Âmbito
• Homogeneidade/heterogeneidade
• Pureza
8/28/2003 José Alves Marques 9
Unicidade referencial
• Num determinado contexto, um nome só pode
estar associado a um objecto
– Caso contrário, haveria ambiguidade referencial
– 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 np mesmo
contexto
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
8/28/2003 José Alves Marques 11
http://www.cdk3.net:8888/WebExamples/earth.htmn
URL
DNS lookup
Resource ID (IP number, port number, pathname)
55.55.55.55 8888 WebExamples/earth.html Network address 2:60:8c:2:b0:5a file Web server Socket
Nome Hierárquico
Departamento de Engenharia Informática
Universal Resource Identifier - URI
• URI eram na versão inicial a classe de nomes
superior que podia ser especializada em URL ou
URN como por exemplo, URN
: ISBN:0-201-62433-8
• Hoje designam qualquer tipo de espaço de nomes
que permite atribuir um nome a um recurso na
rede sem implicar a sua localização
8/28/2003 José Alves Marques 13
Namespaces: Solução hierarquica de nomes no
XML
• XML data has to be exchanged between organizations
• Same tag name may have different meaning in different organizations, causing confusion on exchanged documents
• Specifying a unique string as an element name avoids confusion • Better solution: use unique-name:element-name
• Avoid using long unique names all over document by using 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
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
8/28/2003 José Alves Marques 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
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
8/28/2003 José Alves Marques 17
Pureza dos nomes
Puro: o algoritmo de resolução do nome não utiliza o seu conteúdo para
inferir a localização do objecto ou a autoridade que o controla
– 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
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 nomes objecto)
– Unicidade referencial
– Âmbito
– Homogeneidade
• Relevantes para a resolução de nomes
(obtenção de
um objecto dado um nome)
– Pureza
8/28/2003 José Alves Marques 19
Exemplos de âmbito e pureza
PurezaÂmbito
i-numbers num directório UNIX
Endereço IP (qualquer)
Pathname UNIX Pathname NFS
Nome de um ficheiro num directório UNIX Servidor Sun RPC Local
Porto TCP/IP ou UDP/IP URL
Endereço IP (público)
Pathname AFS
UUID - DCE/IETF Endereço Ethernet Número de rede num
endereço IP (público) URI
Global
Impuro Puro
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 Gerado por uma aplicação
8/28/2003 José Alves Marques 21
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
8/28/2003 José Alves Marques 23
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
• Os primeiros são normalmente designados servidores de
nomes e os segundos por 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.
8/28/2003 José Alves Marques 25
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
8/28/2003 José Alves Marques 27
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
8/28/2003 José Alves Marques 29
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ção8/28/2003 José Alves Marques 31
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
8/28/2003 José Alves Marques 33
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 • 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:
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
8/28/2003 José Alves Marques 35
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
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) – UDDI
8/28/2003 José Alves Marques 37
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)
• Servidor named, biblioteca resolverMicrosoft: Windows 2000 DNS
• Integrado com o Active Directory (é um servidor DNS nativo)
Departamento de Engenharia Informática
DNS:
Características
• Espaço de nomes global, hierárquico, e homogéneo– Nomes impuros
• 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
• Âmbito dos nomes:
– Global (Fully Qualified Domain Name)
Ex. mega.ist.utl.pt.
– Local (resolvido no domínio corrente)
8/28/2003 José Alves Marques 39
DNS: Estrutura
edu
com net org
mit
lcs
amazon
Gerido pelo
Internet Network Information Center
Gerido pelo MIT
linux iso gov / int / mil
MIT Domain . Código de país (2 letras) ISO 3166 xx Reverse DNS arpa Números de telefone num Governamental e militar mil Governamental (não militar) gov Redes net
Sem fins lucrativos org Educação edu Comercial com Tipo de organização Nome de domínio
Departamento de Engenharia Informática
DNS: Zonas
• Unidades de fraccionamento da hierarquia • 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.
• Por cada zona existe um conjunto de servidores:
– Primário
– Secundários (com réplicas da BD do primário)
• 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
8/28/2003 José Alves Marques 41
DNS: Informação em cada domínio
• Registos RR (Resource Register)
– Pares nome valor tipificados – A tipificação exprime:
Classe: família de nomes (ex. IP 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)
– Localização de servidores de zonas
Departamento de Engenharia Informática
DNS: Tipos de registos
Texto arbitrário TXT
Nome DNS para resolução inversa de um endereço IP PTR
Parâmetros que definem a zona SOA
Máquina ou domínio do servidor preferencial de e-mail MX
Servidor de uma zona NS
Arquitectura e sistema operativo do nó HINFO
Nome simbólico para outro nome DNS CNAME
Endereço IP A
Conteúdo Tipo de registo
8/28/2003 José Alves Marques 43
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
Departamento de Engenharia Informática
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
8/28/2003 José Alves Marques 45
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)
8/28/2003 José Alves Marques 47
BIND - Servidores de Nomes
• Master: autoridade no domínio
– Mantém todos os dados do domínio
– Primary master: 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ção8/28/2003 José Alves Marques 49
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
NIS: Características
• Espaço de nomes local, plano 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 com 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
8/28/2003 José Alves Marques 51
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
Departamento de Engenharia Informática
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
8/28/2003 José Alves Marques 53
NIS: Mapas
• Os mapas são listas de pares nome valor 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
Departamento de Engenharia Informática
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 nome valor 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
8/28/2003 José Alves Marques 55
Norma X.500: Introdução
• Arquitectura para registo e resolução de nomes à 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
Departamento de Engenharia Informática
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
8/28/2003 José Alves Marques 57
X.500: Características
• Tipos de nomes:
– Relative Distinguished Name (RDN)
• Nome que identifica uma entrada concreta num dado contexto de resolução
C = PT O = IST OU = Secretaria – Distinguished Name (DN)
• Concatenação não âmbigua de RDNs desde a raíz
/…/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
LDAP “OU=Secretaria, O=IST, C=PT”
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
8/28/2003 José Alves Marques 59
X.500: Esquema de classes
Name Binding Definition
Mandatory Opcional DIT Structure Naming Naming Rule in force Attributes Attributes
DIT Content Rule Definition
Mandatory Optional Precluded Allowed Attributes Attributes Attributes Auxiliary Object Classes
Object Mandatory Optional Subclass Class Attributes Attributes Of Kind
Object Class Definition
DIT Structure Rule
Allowed Superior Structure Rules
Attribute Definition
Subtype Attribute Matching Operational Multi - Collective Derivation Syntax Rules Attribution valued Attributed Defined Flag Flag Flag
Matching Rules
Assertion Syntax
Structural object class
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 substitui 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
8/28/2003 José Alves Marques 61
Active Directory
• Introduzido pela Microsoft em 2000
• Um directório é constituído por uma floresta que contem
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)
• 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
8/28/2003 José Alves Marques 63
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
Departamento de Engenharia Informática
Arquitectura UDDI – Dados
• Dados UDDI (entities): instâncias dos seguintes tipos (expressos em XML)
– 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 – Calssificaçã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, um protocolo usado por um Web Service, etc. – publisherAssertion: descreve relações entre businessEntities
8/28/2003 José Alves Marques 65
UDDI – modelo de 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)
Departamento de Engenharia Informática
UDDI:
Modelo de Informação Exemplificadoname = Departamento de Engenharia Informática ID = DEI
description = Departamento de Engenharia Informática do Instituto Superior Técnico : Organization -name -ID -description Organization -name -phone -email Contact -name -description Service Classification IndustryClassification RegionalClassification CustomClassification 0..* 1 * * 0..* 1 0..1 1 * * name = Dona Teresinha
phone = +351 218 417 784 email = teresinha@dei.ist.utl.pt
: Contact
name = Atendimento description = Atendimento dos alunos
8/28/2003 José Alves Marques 67
tModel
• A descrição que permite o acesso aos serviços tem a ver
com os binding
• A descrição abstracta do serviços pode ser criada por
diversas entidades, uma instância particular do serviço
pode ser associado a uma abstracção já existente
• Os technology Models são descritos no tModel e efectuam
a ligação à implementação concreta de um serviço
• Todos os elementos da descrição tem identificadores
únicos - UUID
Departamento de Engenharia Informática
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
8/28/2003 José Alves Marques 69
Registry Server
• Gere a base de dados com
os registos UDDI
• Modos de acesso
– Aplicações JAX-R – Registry Browser – Xindice• Interfaces
– API– Acesso directo aos registos
Departamento de Engenharia Informática