Upload
duongduong
View
238
Download
0
Embed Size (px)
Citation preview
Departamento de Engenharia Informática
Sistemas Distribuídos 2009/10 1
Gestão de Nomes
Departamento de Engenharia Informática
Sistemas Distribuídos 2
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 4
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 6
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
Nome DNS IANA/ICANN + delegação (FCCN em Portugal)
Departamento de Engenharia Informática
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.pt:1099/Aristoteles
http://www.ist.utl.pt/~SD
Devido ao IP routing, hoje em dia não éimportante
/SD/public_html/index.html
Do Tagus Park, irpara o sul durante400 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.13inode#43876
Rua do Cruzeiro, n1, Oeiras
Endereços
Identifiers of places to find the named entities
Aristoteles(print server)
SD FicticioHome Page
ccc3.ist.utl.ptindex.htmlJoão SilvaNomes
(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 pessoaExemplos
Departamento de Engenharia Informática
Sistemas Distribuídos 9
Associações nome�nome e nome�objecto(bindings)
• O nome que identifica um objecto raramente é o identificador que permite aceder-lhe
• 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
Sistemas Distribuídos 10
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 12
Propriedades dos Nomes
• Unicidade referencial
• Âmbito
• Homogeneidade/heterogeneidade
• Pureza
• Persistência
Departamento de Engenharia Informática
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
Sistemas Distribuídos 14
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 16
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:5afile
Web server
55.55.55.55 WebExamples/earth.html8888
DNS lookup
Socket
Departamento de Engenharia Informática
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
Sistemas Distribuídos 18
Â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?– Respostas diferentes consoante se considera existência de NATs
Departamento de Engenharia Informática
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
Sistemas Distribuídos 20
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 22
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 24
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
– Persistência
• Relevantes para a resolução de nomes (obtenção de um objecto dado um nome)
– Pureza
Departamento de Engenharia Informática
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
Sistemas Distribuídos 26
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
Departamento de Engenharia Informática
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 1024char comando[MAXLINE];
clnt = clnt_create(host, BANCOPROG, BANCOVERS, "tcp");if (clnt == (CLIENT *) NULL) {
clnt_pcreateerror(host);exit(1);
}
Departamento de Engenharia Informática
Sistemas Distribuídos 28
Serviços de Directório
Departamento de Engenharia Informática
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
Sistemas Distribuídos 30
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.
• Não têm uma linguagem de query como as bases de dados
Departamento de Engenharia Informática
Sistemas Distribuídos 31
Arquitectura dos Serviços de Nomes e Directório
Departamento de Engenharia Informática
Sistemas Distribuídos 32
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– Dado um identificador, devolve o seu nome
Departamento de Engenharia Informática
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
Sistemas Distribuídos 34
Arquitectura dos serviços de nomes:Evolução da Arquitectura
1) Ficheiros replicados em todas as máquinasFicheiros UNIX /etc/hosts, /etc/services, etc. Ficheiro Windows LmHosts
2) Pedido em difusão– respondendo o nó que tem o objecto
NetBIOSIP ARP
3) Arquitectura cliente-servidor (solução habitual)– Pergunta directa dos clientes a servidores específicos
DNS, NIS, UDDI, Active Directory
Departamento de Engenharia Informática
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
Sistemas Distribuídos 36
Arquitectura dos serviços de nomes:Diagrama de interacções
aplicação
Código que
usa o SN
Agente
do SNservidor
servidor
servidor
servidor
Informação
do SN
Departamento de Engenharia Informática
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
Sistemas Distribuídos 38
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– e reenvia o pedido a outro servidor, que responde ao cliente
Departamento de Engenharia Informática
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
Sistemas Distribuídos 40
Arquitectura dos serviços de nomes:Modelos de resolução de nomes
• Baseada em multicast
• Iterativo
• Interativo controlado pelo servidor
• Recursivo
Departamento de Engenharia Informática
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
Sistemas Distribuídos 42
Arquitectura dos serviços de nomes:Modelo de resolução iterativo
Client1
2
3
NS2
NS1
NS3
Nameservers
Departamento de Engenharia Informática
Sistemas Distribuídos 43
Arquitectura dos serviços de nomes:Modelos de resolução controlada pelo servidor
1
2
3
5
1
2
34
4
client client
Recursiva
NS2
NS1
NS3
NS2
NS1
NS3
Iterativa
controlada pelo servidor
Departamento de Engenharia Informática
Sistemas Distribuídos 44
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– Combina algumas vantagens de ambos. Quais?
Departamento de Engenharia Informática
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
Sistemas Distribuídos 46
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
Sistemas Distribuídos 47
Análise de Serviços de Nomes
Departamento de Engenharia Informática
Sistemas Distribuídos 48
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 50
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
• Integrado com o Active Directory
Departamento de Engenharia Informática
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
Sistemas Distribuídos 52
DNS: EstruturaNote: 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)
ukpurdue.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
Departamento de Engenharia Informática
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ãomilitar)
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
Sistemas Distribuídos 54
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.
Departamento de Engenharia Informática
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
Sistemas Distribuídos 56
DNS: Esquema de Informação
• Registos RR (Resource Register)– Pares nome�valor 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)– Localização de servidores de zonas
Departamento de Engenharia Informática
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
Sistemas Distribuídos 58
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 60
BINDBerkeley 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)
– named: servidor de nomes
Departamento de Engenharia Informática
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
Sistemas Distribuídos 62
Exemplo de Arquitecturado BIND
ServidorSecundário
ProgramaUtilizador
resolve
Servidorde
Reencaminha-mentoResposta
ServidorPrimário
Pedido
Actualização
Departamento de Engenharia Informática
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
Sistemas Distribuídos 64
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 – Simplifica a gestão global
Departamento de Engenharia Informática
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
Sistemas Distribuídos 66
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
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
Sistemas Distribuídos 68
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
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 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
Departamento de Engenharia Informática
Sistemas Distribuídos 70
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 72
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 estruturalLDAP ���� “OU=Secretaria, O=IST, C=PT”
Departamento de Engenharia Informática
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
Sistemas Distribuídos 74
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
Departamento de Engenharia Informática
Sistemas Distribuídos 75
X.500: Arquitectura
• DSAs (Directory Service Agents)– Servidores
• DUAs (Directory User Agents)– Clientes
Departamento de Engenharia Informática
Sistemas Distribuídos 76
X.500: Arquitectura
DSA
DSA
DSA
DSA
DSADSADUA
DUA
DUA
Departamento de Engenharia Informática
Sistemas Distribuídos 77
X.500: Esquema de classes
Name Binding Defin ition
Mandatory Opcional DIT Structure
Naming Naming Rule in force
Attributes Attributes
DIT Conten t Rule Definition
Mandatory Optional Precluded Allowed
Attributes Attributes Attributes Auxiliary
Object
Classes
Object Mandatory Optional Subclass
Class Attributes Attributes Of
Kind
Object Class De fin ition
DIT Structure Rule
Allowed Superior
Structure Rules
Attribu te De fin ition
Subtype Attribute Matching Operational Multi - Collective
Derivation Syntax Rules Attribution valued Attributed
Defined Flag Flag Flag
Matching Rules
Assertion Syntax
Structural object c lass
Departamento de Engenharia Informática
Sistemas Distribuídos 78
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 80
Universal Description Discovery & Integration (UDDI)
Departamento de Engenharia Informática
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
Sistemas Distribuídos 82
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
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
Sistemas Distribuídos 84
Modelo Estrutural da Informação
Departamento de Engenharia Informática
Sistemas Distribuídos 85
Modelo estrutural da informação
Pag 186
Departamento de Engenharia Informática
Sistemas Distribuídos 86
Exemplo: Modelo estrutural da informação
TModel: NAICSKey: COB9FE13 -179 - 413D - 8A5B5004DB8E5BB2
TModel: UNSPSCKey: C1ACF26D -9672 – 4404 - 9D7039B756E62AB4
TModel: GEOKey: C1ACF26D -9672 – 4404 - 9D7039B756E62AB4
TModel: D-U-N-SKey: C1ACF26D -9672 4404 - 9D7039B756E62AB4
TModel: SEMC IeBSKey: 61A08700 -0684 – 4E05 – BB7D39B756E62AB4
TModel: e-TorusKey: F2390501 -A240 – 4470 – 8A5A6088EE5B1A14
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: SkatesTowndescription:contacts:
businessServices
identifierBag
categoryBag(Yellow Pages)
Departamento de Engenharia Informática
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
Sistemas Distribuídos 88
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 90
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 documento WSDL
Departamento de Engenharia Informática
Sistemas Distribuídos 91
KeyName 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: 1accesspoint: 1accesspoint: 1accesspoint: 1----800800800800----mymymymy----helpline helpline helpline helpline tModelInstanceInfo: 11tModelInstanceInfo: 11tModelInstanceInfo: 11tModelInstanceInfo: 11
Departamento de Engenharia Informática
Sistemas Distribuídos 92
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 94
Registry Server privado
• 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
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
Sistemas Distribuídos 96
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 98
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
Departamento de Engenharia Informática
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
Sistemas Distribuídos 100
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 nome
Departamento de Engenharia Informática
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
Sistemas Distribuídos 102
JAX-RArquitectura
Departamento de Engenharia Informática
Sistemas Distribuídos 103
Registry ServerFerramentas de Acesso
• Registry Browser– Utiliza a API JAX-R
$> jaxr-browser
ouStart -> ... -> jwsdp ->
JAX-R Registry Browser
• Xindice– Acesso directo aos registos da
BDhttp://localhost:8080/Xindice/
Departamento de Engenharia Informática
Sistemas Distribuídos 104
JAX-RArquitectura dos clientes
Departamento de Engenharia Informática
Sistemas Distribuídos 105
JAX-R APIEstruturas 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
Sistemas Distribuídos 106
JAX-R APIClasses 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– Tipicamente, não precisa de autenticação
Departamento de Engenharia Informática
Sistemas Distribuídos 107
JAX-R APIPublish
• 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
Sistemas Distribuídos 108
JAX-R APIDelete
• 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
blcm.deleteOrganizations(keys);
Departamento de Engenharia Informática
Sistemas Distribuídos 109
JAX-R APIInquiry
• 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
BulkResponse response = bqm.findOrganizations(…);