Aula 6 - Comunicação
Propaganda
SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 6 – NOMEAÇÃO E COMUNICAÇÃO 1. INTRODUÇÃO A comunicação entre processos é o “coração” de um Sistema Distribuído. Isto definirá como se realizarão os processos de troca de informações em as diferentes máquinas. Na comunicação entre processos é desejável obter modelos onde a complexidade da comunicação seja transparente para o desenvolvedor, ou seja, o desenvolvedor não deve se preocupar em como a comunicação se dá e sim no seu resultado. Outro aspecto importante da comunicação é a nomeação, utilizado para que um processo possa identificar outro na rede. 2. COMUNICAÇÃO 2.1. Modelo Cliente-Servidor Neste modelo os servidores implementam um serviço específico, os clientes solicitam ao servidor um determinado serviço e espera pela resposta. Figura 1 - Comportamento requisição-resposta 1 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br 2.2. Protocolos em Camadas Figura 2 - Camada, interface e protocolos do RM OSI - Camada Física: Camada responsável pelo envio de bits. Trata da padronização das interfaces elétrica, mecânica e de sinalização. Seus protocolos são dependentes do meio de transmissão do link. - Camada de Enlace: Camada responsável pelo envio de frames entre os links. Nela um datagrama pode ser manipulado por diferentes tipos de protocolos da camada de enlace: Ethernet (CSMA/CD), PPP. Cada protocolo diferente pode ou não implementar um conjunto de serviços. Ex.: Entrega confiável da informação. - Camada de Rede: Redes de longa distância são constituídas de muitos nós com diferentes caminhos entre eles. Para definir como definir um caminho entre um par origem-destino é utilizado o roteamento, que é a principal tarefa da camada de rede. Nesta camada também está o Internet Protocol, protocolo sem conexão, onde pacotes são roteados de forma independente best-effort service. - Camada de Transporte: Camada responsável pela comunicação lógica entre diferentes processos sendo executados em diferentes hosts (fim-a-fim). Os protocolos da camada de transporte não estão implementados nos roteadores. Esta camada pode fornecer os seguintes serviços: multiplexing/demultiplexing, transmissão confiável, garantias de banda, retardo, etc. Esta camada apresenta dois protocolo de transporte na Internet: TCP e UDP. O primeiro orientado a Conexão, confiável, porém “lento”. O segundo sem conexão, “rápido”, porém não confiável. - Camada de Aplicação: Esta camada define os protocolos que dão suporte a uma aplicação para redes. Ex.: Aplicação WEB (HTTP), Aplicação e-mail (SMTP). Os protocolos definem os tipos de mensagens trocadas e sua sintaxe. - Camada de Middleware: Camada de software que é situada logicamente entre uma camada de nível mais alto, composta de usuários e aplicações e uma camada subjacente, que consiste de facilidades básicas de comunicação. O funcionamento do middleware depende de autenticação, comprometimento e comunicação de alto nível. 2 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br Figura 3 - Modelo de referencia adaptado para comunicação em rede 2.3. Sockets Os sockets são responsáveis por possibilitar a troca de informações entre processos operando em hosts diferentes. É o ponto final de uma comunicação full-duplex entre dois processos. O socket é a porta entre o processo da aplicação e o protocolo de transporte. Na pilha de protocolos TCP/IP as mensagens são enviadas através da utilização de sockets. Figura 4 - Sockets 2.3.1. SOCKETS JAVA Para comunicação distribuída à linguagem Java fornece três tipos diferentes de Sockets: 3 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Sockets orientados a conexão (TCP): Implementados com a Classe Socket - Sockets sem Conexão (UDP): Implementados com a classe DatagramSocket - Sockets sem Conexão Multicast: Implementado com a classe MulticastSocket Neste processo de comunicação as informações são strings de bytes, sem significado aparente. (Vide implementação de um socket em Java no endereço http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html). Na comunicação não existe a transparência de distribuição. Toda comunicação está explícita, através de procedimentos send e receive. As funções mais sofisticadas devem ser feitas na camada de aplicação. Diante deste contexto é necessário oferecer uma comunicação de mais alto nível denominado Middlware de comunicação, que independe da aplicação. 2.4. Middleware de Comunicação Middlewares são softwares que em sistemas distribuídos ajudam a prover: - Portabilidade - Habilitam a mudança de um sistema ou componente de um ambiente (incluindo hardware e software) para outro sem alterar o sistema ou componente que está sendo transferido -Transparência - Interoperabilidade Eles fornecem interfaces de programação padronizadas para habilitar comunicação interprocessos entre computadores remotos. Estas interfaces proporcionam portabilidade e transparência. Os middleware de comunicação podem ser de três tipos: - Chamadas de Procedimento Remoto - Comunicação orientada a Mensagens - Comunicação orientada a fluxo 2.4.1. TIPOS DE COMUNICAÇÃO (MIDDLEWARE) 2.4.1.1. Quanto a Persistência - Persistente: Mensagem é armazenada pelo middleware de comunicação durante o tempo que for necessário para entregá-la ao receptor. - Transiente: Mensagem é armazenada somente durante o tempo em que a aplicação remetente e a aplicação receptora estiverem executando. 2.4.1.2. Quanto a Sincronização - Assíncrona: O remetente continua sua execução imediatamente após ter apresentado sua mensagem para transmissão 4 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Síncrona: O remetente é bloqueado até saber que sua requisição foi aceita. Durante a comunicação o middleware avisa que se encarregará da transmissão. O bloqueio permanece até que a requisição seja entregue ao receptor e o receptor retorne uma resposta. 2.4.1.3. Quanto a Granularidade - Discreta: Partes se comunicam por mensagens e cada mensagem forma uma unidade de informação completa. - Fluxo: Várias mensagens, sendo que as mensagens estão relacionadas uma com as outras pela ordem ou pela relação temporal. 2.5. Chamada de Procedimento Remoto (RPC) A comunicação usando sockets é considerada uma forma de comunicação de baixo nível entre processos ou threads distribuídos. Um dos motivos é que os sockets só permitem a troca de um fluxo não estruturado de bytes entre os threads. É de responsabilidade da aplicação cliente ou servidor impor uma estrutura aos dados. Um método alternativo aos sockets é a chamada de procedimento remota, RPC. O RPC permite a processos chamar procedimentos localizados em outros hosts. O desenvolvedor não precisa se preocupar mais com detalhes de implementação de rede, ou seja, não é mais necessária a utilização de sockets. A vantagem de RPC ao Sockets é que RPC gerencia o canal de comunicação, por isso os programas podem ser escritos de modo que a localização de um procedimento seja transparente; Em tese tudo é muito simples, contudo este modelo implementa algumas complicações, tais como: - Arquiteturas de duas máquinas podem ser diferentes - Espaços de endereçamentos diversos - Passagem de parâmetros A idéia básica por trás do RPC é fazer com que uma chamada de procedimento remoto pareça com uma chamada local. Isto representa o princípio da transparência. Esta transparência é alcançada por meio do uso de stubs. O stub do cliente é responsável por empacotar os parâmetros em uma mensagem e enviar a mensagem para a máquina do servidor. Quando a resposta chega, o resultado é copiado para o cliente, e controle volta para o servidor. - O stub do servidor é responsável por desempacotar parâmetros, chamar o procedimento do servidor e retornar resposta para máquina do cliente. 5 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br Transporte de mensagens na rede Figura 5 - Funcionamento do Stub 2.5.1. ETAPAS DO FUNCIONAMENTO DO RPC - Um processo do cliente chama um procedimento local conhecido como stub cliente; - O stub do cliente empacota as informações, constrói uma mensagem (marshaling) e chama o Sistema Operacional; - O Sistema Operacional envia a mensagem para Sistema Operacional remoto; - O Sistema Operacional remoto repassa a mensagem para o stub do servidor; - O stub do servidor desempacota parâmetros e chama procedimento servidor; - O procedimento do servidor executa e retorna o resultado desejado; - O stub do servidor empacota resultado em uma mensagem e chama o Sistema Operacional; - O Sistema Operacional remoto envia mensagem para Sistema Operacional da máquina cliente; - O Sistema Operacional do cliente passa a mensagem para stub cliente; - O stub cliente desempacota resultado, repassando-o para o cliente. A função do stub do cliente é pegar seus parâmetros, empacotá-los em uma mensagem e enviá-los ao stub do servidor (montagem de parâmetros - parameter marshaling). Em todo este processo os stubs interagem com o kernel dos sistemas operacionais na qual estão hospedados os processos clientes. 6 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br Figura 6 - RPC entre um cliente e servidor O conceito de chamada de Procedimento Remoto esconde todos os detalhes do código de rede dentro dos procedimentos STUB. Isso facilita aos programas de aplicações, cliente e servidor, e principalmente ao programador, não precisar conhecer os detalhes de rede como: sockets, ordem de byte na rede, dentre outros. Facilmente permite a construção de aplicações distribuídas. RPC encontra-se entre a camada de aplicação e apresentação do modelo OSI. 2.5.2. PROBLEMAS - O RPC trabalha com TCP ou UDP, logo diferentes níveis de confiabilidade. - Como o processo de emissão da RPC e de seu correspondente Stub cliente reside em diferentes espaços de endereçamento de memória a passagem de ponteiros como parâmetros é dificultada, logo limitando a transparência e a capacidade da RPC. - O desempenho e segurança levam ao desenvolvimento de protocolos adicionais, logo não é uma boa solução para comunicação distribuída. Em suma o RPC permite a um cliente o acesso a um serviço remoto por meio de uma simples chamada a um procedimento local, possibilitando que programas clientes sejam escritos de modo simples. Estes podem localizar automaticamente o servidor e estabelece a comunicação entre software cliente e software servidor. 7 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br 3. NOMEAÇÃO O processo de nomeação é o principal responsável pela transparência nas comunicações entre os nós de um sistema distribuído, uma vez que cada nó constitui uma entidade. 3.1. Nomes, Identificadores e Endereços Em sistemas distribuídos entidades pode ser qualquer coisa, sejam elas máquinas, impressoras, processos, usuários, páginas web, mensagens, etc. 3.1.1. ENDEREÇO O acesso a uma entidade se dá através de um ponto de acesso, ou simplesmente, endereço. Exemplo: Servidor e seu número IP Um endereço pode ser utilizado como uma maneira de nomear, identificar uma entidade. O problema é que uma entidade pode facilmente mudar seu ponto de acesso. Dessa forma, para nomear entidades, sem utilizar especificamente seu endereço, ou seja, nomeá-las independentemente da sua posição física (localização) deve usar identificadores ou nomes amigáveis a seres humanos. É comum estabelecer nomes de países, de jogadores de futebol do passado ou de deuses mitológicos. É mais fácil ao usuário entender que “Afrodite” não está disponível do que “XPTO001X” está indisponível. 3.1.2. IDENTIFICADORES Os identificadores são cadeias aleatórias de bits, com algumas propriedades: - Um identificador referencia, no máximo, 01(uma) entidade; - Cada entidade é referenciada por, no máximo, um identificador; - Um identificador sempre referencia a mesma entidade, isto é, nunca é reutilizado. Exemplo: Identificadores de entidades em sistemas P2P baseados no sistema Chord. 3.1.3. NOMES AMIGÁVEIS São nomes representados por uma cadeia de caracteres, como pathnames, domínios de Internet, números de processos, etc. 8 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br Exemplo: http://www.ricardobarcelar.com.br Diante desses conceitos é necessário resolver a questão dos nomes e identificadores para endereços. Solução para isto é a utilização de um Sistema de Nomeação. 3.2. Sistema de Nomeação Um sistema de nomeação, em princípio mantém uma vinculação nome-endereço que na forma mais simples é uma tabela de pares (nome, endereço). Contudo, em sistemas que abrangem redes de grande porte, uma tabela centralizada não vai funcionar devido aos muitos recursos a nomear. Existem três classes diferentes de nomeação: - Nomeação Simples - Nomeação Estruturada - Nomeação Baseada em Atributo 3.2.1. NOMEAÇÃO SIMPLES A nomeação simples é aplicada a identificadores. São representados por cadeias aleatórias de bits, conhecidos como nomes simples. Estes nomes não contêm sequer uma informação sobre como localizar o ponto de acesso de uma entidade associada, tornando-se um problema na localização do ponto de acesso (endereço). Para localizar uma entidade quando se tem somente o nomes simples em redes locais é possível utilizar soluções como: - Broadcasting e multicasting - Localização Nativa - Tabelas de Hash Distribuídas (DHT) 3.2.1.1. Broacasting e multicasting São aplicáveis somente a redes locais. Seu funcionamento consiste em enviar uma mensagem broadcast que contém o identificador da entidade. Máquinas com ponto de acesso para a entidade enviam uma mensagem que contém o endereço procurado. Essa estratégia é ineficiente quando a rede cresce, visto que largura de banda da rede é desperdiçada, e com grande número de mensagens de requisição aumenta a probabilidade de colisões de mensagens, diminuindo o throughput do sistema. O multicast também pode ser utilizado para localizar entidades em uma rede ponto-aponto, na qual somente um grupo restrito de máquinas recebe a requisição como, por exemplo, em um banco de dados replicado. Um endereço multicast pode também estar associado a uma entidade replicada, na qual para cada requisição para o endereço multicast, a réplica responde com seu endereço IP. 9 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br Figura 7 - Multicast 3.2.1.2. Localização Nativa Outra solução é a localização nativa, que consiste em uma abordagem para suportar entidades móveis em redes de grande escala. Nesta solução é monitorada a localização corrente de uma entidade. Um exemplo em que a abordagem da localização nativa é usada é em Mobile IP. Nesta abordagem cada host móvel usa um endereço fixo e toda a comunicação é dirigida inicialmente ao agente nativo do host móvel (situado na rede local do endereço do host). Ao mudar de rede, o host recebe um endereço externo (care-of-adress) e registra no agente nativo. Quando o agente nativo recebe um pacote para o host móvel ele consulta a localização corrente do hospedeiro. Se estiver na rede local o pacote repassado, senão o pacote é envida por um túnel até a localização corrente do hospedeiro. 10 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br Figura 8 – Princípio do Mobile IP As desvantagens dessa estratégia é que para se comunicar com uma entidade móvel, em primeiro lugar um cliente tem que contatar a localização nativa, que pode estar em um lugar completamente diferente gerando grande latência de comunicação. 3.2.1.3. Tabelas de hash distribuídas (DHT) Esta é outra forma de resolver um identificador para o endereço da entidade associada. Este modelo é bem representado pelo sistema Chord, na qual existem “nós” organizados logicamente em um anel. O sistema Chord é extremamente simples no que se refere à funcionalidade que provê. A única função que oferece é mapear chaves e seus respectivos objetos em nós do sistema. O sistema Chord usa um espaço de identificadores de m1 bits para designar nós e entidades específicas (arquivos, processos). Assim, uma entidade com chave k cai sob a jurisdição do nó que tenha o menor identificador id >= k. Esse nó é denominado sucessor de k e denotado por succ(k). Para resolver com eficiência uma chave k para o endereço de succ(k) utiliza-se uma das abordagens abaixo: - Abordagem linear: Cada nó p monitora o sucessor succ(p+1) e o predecessor pred(p). Ao receber uma requisição para a chave k, p repassa a requisição para os seus vizinhos, a menos que pred(p) < k <= p, caso em que o nó p retorna o próprio endereço. Esta é uma estratégia não escalável. 1 Número m bits é usualmente 128 ou 160 11 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br Caso 1) Suponhamos que p = 4 receba uma requisição para k = 7 → succ(p+1) → repassa a requisição ao nó = 9. Caso 2) Suponhamos que p = 4 receba uma requisição para k = 3 → como pred(4) = 1< 3<=4 → retorna o próprio endereço. Figura 9 – Sistema Chord - Tabela de Derivação (Finger Table): Diferente da abordagem linear para a consulta de chaves, cada nó Chord mantém uma tabela de derivação de no máximo, m entradas. Denotando a tabela de derivação de p por Ftp, temos: Ftp[i]=succ(p+2 i -1), ou seja, a iésima entrada aponta para o primeiro nó que sucede p por no mínimo 2 i -1. Para encontrar uma entidade k, as referências na tabela de derivação são usadas como atalhos para nós existentes no espaço de identificadores. A distância do atalho em relação ao nó p aumenta exponencialmente à medida que o índice na tabela de derivação cresce. Para consultar uma chave k, o nó p repassará a requisição ao nó q com índice j na tabela de derivação de p, ou seja, q = Ftp [ j ] <= k <= Ftp [j+1] Exemplo: Considere a resolução de k=26, a partir do nó 1. 1) Nó 1 consultará k=26 → verifica que o valor é maior do que FT1[5]. 2) Requisição será repassada para o nó 18. 12 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br 3) O nó 18 selecionará o nó 20, porque FT18[2] < k<= FT18[3]. 4) Por fim, requisição é repassada do nó 20 para o nó 21 e deste para 28 O problema dessa solução é que a organização lógica dos nós em uma rede de sobreposição (orvelay) pode levar a uma escolha errada no roteamento de mensagens, portanto k e succ(k+1) podem estar muito longe fisicamente. Existem três solução para este problema, a saber: - Identificar nós com base na topologia, de modo que dois nós próximos tenham identificadores que também estejam próximos um do outro. - Roteamento por proximidade que consiste em manter mais de um sucessor e repassar a requisição para o mais próximo. - Seleção de vizinho por proximidade. Ao escolher um vizinho (não em Chord), pegue o mais próximo. 3.2.2. NOMEAÇÃO ESTRUTURADA Nomes simples são bons para máquinas, mas não são convenientes para a utilização de seres humanos. Como alternativa os sistemas de nomeação comumente suportam nomes estruturados. Exemplo: Nomeação de arquivos, hosts na Internet Nomes são organizados em um espaço de nomes que podem ser representados como um grafo dirigido, com dois tipos de nós: - Nó-folha: contém informações da entidade - Nó de diretório: entidade que se refere a outros nós Cada nó de diretório possui uma tabela de diretório<nome aresta, nome nó>. Figura 10 – Gráfico de nomeação geral com um único nó-raiz Sistemas de nomeação possuem, na maioria, um nó raiz, onde cada caminho no grafo de nomeação pode ser referenciado pela sequência dos labels nas arestas. N:<label1, label2, ..., labeln> 13 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br Onde N se refere ao primeiro nó do caminho. Tal sequência é denominado nome de caminho, que pode ser: - Nome de caminho absoluto: primeiro nó no caminho é a raiz - Nome de caminho relativo: primeiro nó pode ser qualquer nó. 3.2.2.1. Resolução de nomes Os espaços de nomes oferecem um mecanismo para armazenar e recuperar informações sobre entidades por meio de nomes. Dado um nome de caminho, deve ser possível consultar qualquer informação armazenada no nó referenciado por aquele nome. O problema é que para resolver um nome, precisa-se de um nó de diretório inicial. Para isso existem algumas soluções: - Mecanismo de fechamento: Trata da seleção do nó inicial em um espaço de nomes a partir do qual a resolução de nomes deve começar. Exemplo: - www.ricardobarcelar.com.br: início da resolução é feito através do servidor de nome DNS - /home/publico/arquivos: início da resolução ocorre no servidor local NFS Vide Figura 10 – Gráfico de nomeação geral com um único nó-raiz 3.2.2.2. Alias (Apelidos) Define outro nome para a mesma entidade, ou seja, vários nomes absolutos para o mesmo nó (hard link). Exemplo: O nome de caminho /home/steen/Keys, que referencia um nó que contém o nome de caminho absoluto /Keys. Vide Figura 10 – Gráfico de nomeação geral com um único nó-raiz 3.2.2.3. Implementação de um Espaço de Nomes Este é um serviço que permite que usuários e processo adicionem, removam e consultem nomes. Um serviço de nomeação é implementado por servidores de nomes e devem prover: - Escalabilidade - Manutenção descentralizada - Tolerância a falhas, robustez - Escopo global: Nomes possuem o mesmo significado em todos os lugares Um espaço de nomes, em geral, é organizado em hierarquia de três camadas: - Camada global (Raiz e seus filhos) - Camada administrativa (Nós de diretórios) - Camada gerencial (Mantido por administradores e usuários finais) 14 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br Figura 11 - Repartição do espaço de nomes DNS A resolução de nomes pode ser: - Resolução Iterativa: servidor responde somente o que sabe: o nome do próximo servidor que deve ser buscado. O cliente procura iterativamente os outros servidores. - Resolução Recursiva: servidor passa o resultado para o próximo servidor que encontrar. Para o cliente, existe somente uma mensagem de retorno: o endereço do nome ou 'não encontrado'. Figura 12 – Comparação entre resolução recursiva e iterativa de nomes 3.2.2.3. Domain Name System (DNS) O DNS é usado para realizar o mapeamento entre nome e endereço IP. Para isso ele utiliza uma base de dados distribuída implementada na hierarquia de muitos servidores de 15 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br nomes. O protocolo da camada de aplicação permite que hospedeiros, roteadores, servidores de nomes e comuniquem para resolver nomes (tradução endereço/nome). A razão de não se centralizar o DNS é não impor um ponto único de falha, diminuir o volume de tráfego, evitar base de dados centralizada e distante e proporcionar uma melhor manutenção da base de dados, além do que possibilita uma estrutura escalável. Figura 13 – Base de dados Hierárquica e distribuída Se procurado no servidor local não for possível resolver o nome, a requisição deverá ser remetida ao servidor raiz. Este é responsável por: - procurar o servidor oficial se o mapeamento for desconhecido - obter a tradução - devolver o mapeamento ao servidor local São 13 os servidores raiz “espalhados” pelo mundo. Figura 14 – Servidores raiz 16 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br 3.2.3. NOMEAÇÃO BASEADA EM ATRIBUTO Este modelo descreve uma entidade em termos de pares <atributo, valor>. A premissa é que uma entidade tem um conjunto associado de atributos. Quando um usuário especifica quais valores um determinado atributo deve ter, ele restringe o conjunto de entidades nas quais está interessado. Cabe ao sistema de nomeação retornar uma ou mais entidades que atendam à descrição do usuário. Sistemas de nomeação baseado em atributos também são conhecidos como serviços de diretórios. Uma abordagem comum para tratar serviços distribuídos de diretórios é combinar nomeação estruturada com nomeação baseada em atributos. Esta abordagem tem sido adotada no serviço Active Diretory da Microsoft. Muitos desses sistemas usam, ou dependem, do protocolo leve de acesso a diretório (Lightwight Diretory Access Protocol – LDAP). 3.2.3.1. LDAP O LDAP é um protocolo padrão IETF, projetado para operar em Internet. Sua definição considera o LDAP como um gateway para os servidores de diretório X.500. Pelo fato de utilizar a pilha TCP/IP, em lugar da mais complexa pilha OSI, permite uma implementação mais eficiente e simplificada de forma a poder executar em máquinas de diferentes portes, tais como PCs, PDAs, equipamentos Wireless, entre outros. O LDAP torna possível gerenciar usuários, grupos, dispositivos, e outros objetos, evitando a necessidade de gerenciar aplicações de diretórios específicos (tais como de correio eletrônico). É um padrão suportado por diferentes plataformas que torna a aplicação independente de fabricantes ou plataformas específicas de sistema operacional ou rede. Reduz o custo pelo fato de diminuir o número de diretórios distintos a serem gerenciados e economiza tempo de desenvolvimento pelo fato de não ser necessário construir bases de dados específicas para gerenciamento de usuários e grupos. O LDAP cria 4 (quatro) modelos: - Modelo de informação: define os tipos de dados que podem ser colocados no diretório. - Modelo de nomes: define como os dados do diretório são organizados e referenciados. - Modelo funcional: define como acessar e atualizar as informações no diretório. - Modelo de segurança: define como as informações no diretório são protegidas de acessos não autorizados. Este modelo ainda define uma forma de referenciarmos as informações, assim, uma entrada possui somente um único nome dado por um DN (Distinguished names). Um DN é uma concatenação de RDN (Relative Distinguished names), por exemplo, um DN poderia ser expresso como: OU = Recursos, Ou = Servidores, Cn = Web Server. Um RDN para o DN acima poderia ser Ou = Recursos ou Cn = Web Server. Eis uma série de chaves geralmente utilizadas: - uid (userid): identificador único obrigatório - cn (common name): apelido da pessoa - givenname: nome - Sn (surname): apelido da pessoa 17 SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - o (organization): empresa da pessoa - u (organizational unit): serviço da empresa na qual a pessoa trabalha - mail: endereço de correio eletrônico da pessoa Figura 15 - Árvore LDAP 18
