Cap. 5 Objetos Distribuídos e Invocação Remota

Transcrição

1 1 Cap. 5 Objetos Distribuídos e Invocação Remota Aplicação distribuída: conjunto de processos que cooperam entre si; Precisam invocar operações em processos remotos para realizar serviços. Modelos de programação usados: Chamada de procedimentos: extendida no RPC para permitir a chamada de procedimentos remotos; Invocação de métodos: extendida no RMI para permitir a invocação de métodos em objetos remotos; Programação orientada a eventos: permite a objetos receber notificações de eventos em objetos onde registraram interesse. Extendida para permitir notificação sobre eventos distribuídos. Middleware Aplicações RMI, RPC e eventos Protocolo request reply Representação externa de dados Sistema operacional Middleware Aspectos importantes: Transparência de localização: no RPC, quem chama uma função não sabe se ela é local ou não, se roda no mesmo processo ou num diferente. Se for remota, não se sabe onde está o processo que vai ser executado. Recebendo um evento distribuído, o processo não sabe onde está o processo que o gerou. Protocolos: são independentes do sistema de comunicação básico. Diferenças de hardware: são encobertas por operações de marshalling com EDR. Sistema operacional: a aplicação que usa o middleware não depende do SO local. Linguagens diferentes: alguns middlewares permitem independência de linguagem. Um objeto escrito numa linguagem pode invocar métodos em objetos escritos em outra Interfaces Na programação por módulos, o relacionamento entre módulos é feito via uma interface. Nela, relaciona-se quais métodos estão disponíveis para acessar determinado módulo. Enquanto a interface permanecer igual, o acesso ao módulo não é alterado, mesmo que a implementação mude. Interfaces em SDs Num programa distribuído, um módulo não pode acessar variáveis de outro. A interface de um módulo não pode especificar acesso a variáveis. O IDL do CORBA permite especificar atributos, mas o acesso não é direto. A plataforma insere funções de consulta e atualização de variáveis automaticamente. Os mecanismos de passagem de parâmetros das chamadas locais não se aplicam em programas distribuídos (passagem por valor ou por referência). Na interface, a especificação de parâmetros indica apenas input e/ou output:

2 Input: parâmetros passados para a função invocada que fornecem valores para o seu algoritmo; Output: parâmetros que recebem resultados da função invocada. Ponteiros não podem ser usados em invocações de funções. 2 Diferença entre RPC e RMI: Interface de serviço: conjunto de funções disponíveis para acessar os serviços de um servidor no modelo cliente-servidor; Interface remota: métodos de um objeto disponíveis para invocação por outros objetos; o Define parâmetros e forma de acesso; o Aceita passagem de objetos como argumentos; o Permite passagem de referências para objetos. 5.2 Comunicação entre objetos distribuídos Modelo de Objetos Exceções Tipos de erros que um processo pode encontrar durante sua execução: Erros controláveis: valores inconsistentes de argumentos, falha em encontrar um dado num BD, etc. Erros externos: falha em acessar arquivos ou sockets, etc. Erros internos: divisão por zero, endereços de memória inválidos, etc. Erros de dependência: ocorrem em processos hierarquicamente superiores. O modelo de objetos permite colocar tratamento de erros através de comandos throw. Isso evita que o programador insira todos os testes no meio do código de um serviço. O tratamento é colocado em blocos separados e a execução desvia para esses blocos quando um evento é catched pelo programa. Garbage collection Objetos ocupam espaço e devem ser liberados quando não são mais necessários. Algumas linguagens (ex. Java) possuem mecanismos para liberar objetos quando não são mais referenciados. Outras não possuem e obrigam o programador a fazer esse controle (ex. C++). Operação sujeita a erros Objetos distribuídos Objetos distribuídos podem se organizar de várias formas. A invocação de seus métodos segue modelos previamente estudados. Um dos pontos importantes é verificar se um determinado objeto (ou método) pode ser invocado concorrentemente (+ de uma invocação no mesmo intervalo uma invocação feita antes da anterior ser executada). O fato de que os dados de um objeto são acessados apenas pelos seus métodos permite aplicar técnicas de controle: Ex.: Java - métodos sinchronized;

3 Objetos podem ser copiados para caches locais, sendo acessados diretamente; Invocação via RMI permite acesso ao mesmo objeto por plataformas diferentes possíveis conversões são feitas por EDR O modelo de objetos distribuídos Tipos de invocação: Local: feitas dentro do mesmo processo; Remota: feita entre processos diferentes podem residir ou não em máquinas diferentes. Para ser acessado remotamente, um objeto deve ter uma referência remota. Cada objeto remoto deve ter uma interface remota, que especifica quais dos seus métodos podem ser acessados remotamente. Referência a objeto remoto Identificador que permite acessar um objeto remotamente. É único no sistema inteiro e permite identificar um objeto determinado, independente de sua localização. Seu formato é diferente de uma referência local. Referências remotas podem ser passadas como argumentos. Interfaces remotas A classe de um objeto remoto implementa os métodos de sua interface remota. Outros objetos só podem invocar métodos de um objeto que pertencem a sua interface remota Quetões de projeto para RMI Diferenças entre chamadas locais e remotas: Chamadas locais são executadas exatamente 1 vez; sobre chamadas remotas já não é sempre assim; O nível de transparência do RMI precisa ser definido. Semânticas de invocação RMI Escolhas sobre protocolos request-reply: Mensagens retry: até quando retransmitir uma requisição, antes de receber a resposta ou assumir que o servidor falhou; Filtro de duplicados: com a possibilidade de retransmissões, se o servidor deve usar um filtro; Retransmissão de resultados: se um histórico deve ser mantido em vez de re-executar sempre cada comando; Medidas de tolerância a falhas Filtro de duplicados Retransmitir requisições Não Não aplicável Re-executar ou retransmitir reply Não aplicável Semânticas de invocação Maybe

4 Sim Não Re-executar At-least-once Sim Sim Retransmite At-most-once 4 Obs.: para invocação de métodos locais, a semântica é exactly-once! Transparência No RPC, certas atividades (marshalling, envio de mensagens, retransmissão da requisição após um timeout) são escondidas do programador e realizadas de forma transparente. Com objetos distribuídos, isso é extendido para localizar e contactar objetos remotos. Invocações remotas são diferentes das locais porque envolvem redes. Pode haver falhas de rede ou máquina sem que se possa distinguir uma da outra. A grande questão é se a máquina destino recebeu a msg e se conseguiu executá-la. Isso obriga os objetos remotos a tratamentos para recuperação de cada caso. O atraso de uma invocação remota é enorme comparado a uma operação local. Então, é interessante minimisar esse custo. Apesar de se procurar por transparência, é interessante que a diferença entre invocações locais e remotas sejam explícitas, já que as implicações são grandes. Ex.: Corba repassa ao programa erros de comunicação como exceção; A IDL também permite especificar o tipo de semântica que se deseja isso informa o projetista sobre que tipo de operação o objeto deve realizar; Java RMI separa invocações locais de remotas Implementação de RMI Módulo de comunicação Executa o protocolo request-reply; Especifica tipo de msg, requestid, referência remota; Determina a semântica; No servidor, seleciona o dispatcher. Módulo de referência remota Tradução entre referências remotas e locais; Cria referências remotas; Mantém uma tabela de objetos remotos: o Entradas para todos os objetos remotos relacionados ao processo; o Entradas para cada proxy local. Software RMI Camada entre objetos da aplicação e módulos de comunicação e referência remota. Função de seus componentes: Proxy: o Torna transparente para o cliente as invocações (comporta-se como um objeto local, mas repassa as invocações para os objetos remotos);

5 5 SD Cap. 5-6 o Esconde detalhes da referência remota, marshalling, unmarshalling, envio e recepção de msgs; o Um proxy para cada objeto remoto que o processo usa. Dispatcher: o Servidores possuem um dispatcher e um skeleton para cada classe de objetos remotos; o Recebe requisições; methodid diz que método deve ser chamado; passa a requisição. Skeleton: o Implementa os métodos de uma interface; o Faz unmarshall da requisição e invoca o método correspondente do objeto remoto; o Faz marshall do resultado (e exceções); o Passa a msg reply para o proxy para transmissão. Métodos fábricas Interfaces não incluem construtores; Assim, objetos remotos não podem ser criados por invocação remota; São criados na inicialização de processos ou em métodos de interfaces remotas; Um método fábrica é aquele que cria objetos remotos; Objeto fábrica é aquele que possui métodos fábricas. Binder Serviço de um SD que mantém tabelas de mapeamento entre nomes de serviços e referências remotas. Permite aos servidores se registrarem e aos clientes procurar um serviço. Corba: Corba Name Service; Java: RMIregistry. Ativação de objetos remotos As aplicações necessitam que as informações sejam mantidas por longos períodos. Isso não justifica manter objetos em processos se eles não são necessários todo o tempo. Assim, os processos são disparados quando necessário. Um objeto remoto que pode ser invocado é chamado de ativo. Se ele não está ativo, mas pode ser ativado, é chamado de passivo. Um objeto passivo: Implementação dos métodos; Seu estado na forma marshalled. Processos que disparam servidores para manter objetos remotos são chamados de ativadores. Armazéns de objetos persistentes Objeto persistente: pode manter seu estado e informações entre períodos de ativação. Ex.: Serviço de objetos persistentes Corba; Java Persistente. O processo de ativação é transparente. O estado dos objetos é salvo periodicamente em pontos íntegros para fins de tolerância a falhas.

6 6 SD Cap. 5-6 Duas abordagens para decidir se um objeto é persistente ou não: Raízes persistentes: objetos acessíveis através de uma raiz persistente é um objeto persistente. Ex.: Java Persistente e PerDis; Classes persistentes: objetos persistentes são instâncias dessas classes ou derivados delas. Ex.: Arjuna. Alguns armazéns permitem a ativação de objetos em caches dos clientes. Ex.: PerDis e Khazana. Isso exige um protocolo de consistência de caches. 5.3 Remote Procedure Calling - RPC Programa distribuído: Conjunto de componentes de software; Executam sobre um número de computadores da rede. Modelo cliente-servidor: Uma aplicação pode ser cliente de qualquer serviço da rede; Um servidor pode ser cliente de outros serviços; Cada serviço possui um conjunto de operações que podem ser invocadas pelos clientes; A comunicação entre clientes e servidores é baseada no protocolo requisição-resposta; O cliente sempre espera pela resposta para continuar, mesmo que não haja retorno de valor (pode haver erro!). RPC: Integração entre clientes e servidores de forma conveniente; Clientes se comunicam com servidores através da chamada de procedimentos; A chamada é feita no programa local; A execução ocorre num programa remoto. Serviço ao nível RPC: Uma interface que é exportada para os programas de um sistema; Conjunto de funções que operam sobre certos dados ou recursos; Aspectos semânticos de RPC: Parâmetros de entrada e saída: Parâmetros de entrada são passados para o servidor; Valores enviados na requisição e copiados nas variáveis do servidor; Parâmetros de saída são enviados para o cliente na resposta; Substituem as variáveis da chamada; Parâmetros podem ser I/O. Parâmetros de entrada ~ passagem por valor Se passagem por referência (ptr em C): Indicar se é I, O ou I/O; Motivo para uma linguagem de definição de interface. Procedimento remoto: Executado em ambiente diferente de quem chama; Não pode acessar dados do cliente (ex.: globais); Endereços de memória do cliente não tem significado para o servidor;

7 7 Conclusão: parâmetros não podem incluir ponteiros! Referência opaca: Referência que o cliente passa para o servidor; Endereço do servidor; Não tem significado para o cliente. Estruturas complexas podem ser serializadas: Ex.: uma árvore pode ser convertida em uma expressão. Questões de projeto Histórico: Xerox Courier RPC: padrão de desenvolvimento de aplicações remotas; Birrel e Nelson: RPC para o ambiente de programação Cedar; Datagramas sobre a Internet da Xerox; Linguagem Mesa. Classes de RPC: 1. o mecanismo RPC é integrado com uma linguagem específica; inclui uma notação de definição de interface; ex.: Cedar, Argus, Arjuna; pode incluir construções específicas para RPC (ex.: exceções); 2. linguagem de definição de interfaces (pré-compilador?!). ex.: SUN RPC (base do NFS); Matchmaker (Jones e Rashid, 1986): pode ser usado com C, Pascal, LISP, MIG (Mach Interface Generator); Não é ligado a um ambiente particular. Linguagem de definição de interfaces: Especifica as características do servidor que são visíveis para o cliente; Nomes de procedimentos, tipos dos parâmetros; Tipo de acesso a um parâmetro: I, O ou I/O; O acesso indica se o valor precisa ser encapsulado na requisição ou na resposta (marshaling); Compiladores de interfaces podem gerar descrições que podem ser usadas em diferentes linguagens, permitindo a comunicação de clientes e servidores de plataformas diferentes. Tratamento de exceções: Qualquer RPC pode falhar: Falha no servidor; Sobrecarga do servidor (atraso na resposta). RPC deve devolver erros: Timeouts (inerente à distribuição); Erros de execução (FD inválido, leitura após EOF, divisão por zero, etc.). Erros detectados pelos procedimentos (códigos inválidos, datas erradas, etc.).

8 8 Obs.: na falta de um mecanismo de indicação de erros (como exceções em JAVA), o sistema pode usar um método bem definido de indicação de problemas (retorno de 0 ou 1 em UNIX). Garantia de entrega: Implementações possíveis do DoOperation: Repetição da requisição: até receber uma resposta ou assumir que o servidor falhou; Filtro de duplicados: usado com retransmissão, para evitar duplicação no servidor; Retransmissão da resposta: evita a reexecução de uma requisição. Garantia de Entrega Repete Req. Filtra Duplic. N - S N S S Reexec/Retra ns - Reexecuta Retransmite Semântica RPC Maybe At-least-once At-most-once Tipos de semânticas RPC: 1. Maybe: sem tolerância a falhas. Não há garantias de que o procedimento foi executado. Não se pode saber se o servidor executou a requisição ou se a resposta foi perdida. 2. At-least-once: o cliente é informado de que um timeout ocorreu e retransmite a requisição. Eventualmente o servidor receberá uma requisição duplicada. Se ele for projetado para executar operações idempotentes, não há problema. 3. At-most-once: o servidor filtra requisições duplicadas e retransmite as respostas. Transparência: O modelo Birrel e Nelson garante que a chamada a procedimentos remotos é igual à chamada dos locais; RPC Cedar: identifica os procedimentos remotos; acrescenta o código necessário para o marshalling e unmarshalling; faz retransmissão da requisição após um timeout; a duração de uma chamada é indefinida desde que o servidor permaneça ativo. RPC é mais vulnerável do que chamadas locais: envolve redes, outros computadores e outro processos; consome muito mais tempo do que chamadas locais; deve tratar erros que não acontecem nas chamadas locais. Implementação O software de suporte ao RPC tem 3 funções: Processamento da interface: marshalling e unmarshalling; despacho das requisições. Tratamento da comunicação: Transmitir requisições e receber as respostas; Binding: Localização de um servidor para um serviço qualquer.

9 Processamento da interface: 9 Requisição Cliente Servidor Chamad Marshall Send Receive Unmarsh Executa a. Seleção! Retorno Unmarsh Receive Send Marshall Retorno Resposta Cada procedimento de uma interface é numerado com um número único (0, 1, 2, 3,...). Construindo um programa cliente: Stub: converte chamada local em remota; faz o casamento dos parâmentros. Construindo o programa servidor: entregador (despatcher); conjunto de stubs servidores. Compilador de interfaces: processa as definições de uma IDL. 1. Gera os stubs do cliente; 2. Gera os stubs do servidor; 3. Gera as operações de marshall e unmarshall; 4. Fornece os cabeçalhos das funções (o corpo o que a função faz deve ser fornecido pelo programador). Binding Mapeamento de um nome para um objeto determinado (identificador de comunicação). Ex.: no Unix, um socket com número IP e Porta. Ex.: Mach, Chorus e Amoeba, uma porta independente de localização. Evita a recompilação dos clientes quando o servidor muda de porta. Se o endereço inclui a identificação do host, o cliente precisa ser recompilado toda vez que o servidor mudar de host. Num sistema distribuído, o binding é um serviço separado que mantém tabelas associando nomes de serviços com portas de servidores. Ex.: o próprio Binding, DNS, etc. Funções: Register(serviço: string, porta: port, versão: integer); Withdraw(serviço: string; pota: port; versão: integer); LookUp(serviço: string; versão: integer): port. Quando um servidor inicia seus serviços, ele envia uma mensagem para o Binding para se registrar. Quando ele encerra suas atividades, ele pede para ser retirado das tabelas do Binding. Quando um cliente quer usar um serviço, manda uma mensagem ao Binding para descobrir o endereço do servidor. Se o servidor falha, o cliente pode requisitar ao Binding a porta de outro servidor do mesmo serviço.

10 10 SD Cap. 5-6 Se o sistema usa portas independentes de localização, um servidor pode se mover para outro host sem informar o Binding. Os clientes não são afetados pela mudança. Se o identificador de porta inclui o host, o Binding deve ser informado toda vez que o servidor for movido. Os clientes vão ter requisições ignoradas. Eles devem contatar o Binding para descobrir o novo endereço do serviço. Serviço único: todos os outros dependem dele: Tolerante a falhas (ex.: salvando as tabelas em arquivos toda vez que elas são alteradas); Um sistema distribuído dependente de um único Binder não é escalável: As tabelas podem ser particionadas (maior desempenho); Também podem ser replicadas em um grupo de Binders (tolerância a falhas). Alguns serviços são representados por múltiplos servidores, cada um rodando em um host diferente: Cada um deles é uma instância de um serviço; Um Binder deve ser capaz de registrar as várias instâncias de um serviço; Se o Binder não usa a instância de um serviço, o cliente deve informar qual delas ele quer usar (número seqüencial); Numa falha, o cliente pega a próxima instância. Se o Binder usar a instância, ele pode distribuir os clientes pelas diversas instâncias de um serviço (balanceamento de carga) Exportação: registro de um nome de interface associado com a porta de um servidor. Importação: pergunta ao Binder pelo nome de um serviço retornando um número de porta. Localização do Binder: Endereço bem definido, compilado em todos os clientes; Clientes e servidores precisam ser recompilados se o Binder for mudado; O Kernel informa o endereço do Binder (ex.: variável de ambiente). Permite a relocação ocasional do Binder; Quando clientes ou servidores iniciam, mandam mensagens de broadcast para localizar o Binder (ex.: no Unix, o Binder fica numa porta bem conhecida. Num broadcast, o Binder que receber informa qual é o seu host). RPC Assíncrono Ex.: sistema de janelas X-11 Utiliza uma forma assíncrona de RPC: X-11 é um servidor de janelas; As aplicações que querem mostrar alguma coisa na tela (texto, gráficos, etc.) são os clientes. Características: Para gerar ou atualizar a informação de uma janela, o cliente envia várias requisições ao servidor, cada uma delas com uma pequena quantidade de informações: Strings, troca de fonte, um caracter. O cliente não recebe respostas para suas requisições; Cliente e servidor trabalham em paralelo;

11 11 SD Cap. 5-6 Algumas requisições podem exigir intensa computação - há ganhos em realizá-las enquanto o servidor atende requisições anteriores; O servidor pode manipular requisições de vários clientes; Ou mesmo de dispositivos; O servidor tem uma performance melhor se ele não precisa enviar respostas para as requisições. RPC sem respostas e sem bloqueio é chamado de assíncrono. Comparação: No RPC síncrono, não existe paralelismo; No RPC assíncrono, o cliente faz todas as requisições de que necessita; só então espera pelos resultados; A espera no lado do cliente se resume ao intervalo entre a última requisição e a recepção da primeira resposta; Se não houver necessidade de resposta às requisições, o tempo de espera não existe. Otimização possível: Armazenar as requisições no lado do servidor até que ocorra um timeout ou que o cliente peça uma resposta; Só então as requisições são enviadas como uma comunicação só; Isto reduz a latência de rede. Requisições paralelas para vários servidores Ex.: considere um banco com vários servidores, cada um responsável por registrar os lançamentos feitos em uma agência. Para saber o saldo de uma conta, é preciso consultar os lançamentos de todas as agências; RPC síncrono: O cliente faz requisições para um servidor de cada vez, esperando a resposta; Só após chegar uma resposta, ele manda a requisição para o próximo. RPC assíncrono: O cliente envia as requisições para todos os servidores em seqüência e depois espera por todas as respostas; Os servidores trabalham em paralelo. Comparação entre RPC síncrono e assíncrono:

12 12 RPC síncrono argumentos marshall send receive unmarshall processa argumentos marshall send receive unmarshall processa receive unmarshall transmissão executa marshall send receive unmarshall executa marshall send Cliente Servidor RPC assíncrono argumentos marshall send argumentos marshall send receive unmarshall processa receive unmarshall executa marshall send receive unmarshall executa marshall send receive unmarshall

13 processa 13 Cliente Servidor RPC assíncrono no sistema Mercury Otimizações necessárias no paradigma RPC: Se não há necessidade de resposta, o cliente pode fazer um RPC e continuar sua execução; Se não há necessidade de resposta, várias requisições podem ser armazenadas e enviadas no mesmo send; Se há necessidade de resposta, o cliente pode processar até que ela seja necessária para só então requisitá-la. Sistema Mercury MIT, 1988: Call-stream: combina RPC síncronos e assíncronos; As diferenças nos métodos de comunicação não são visíveis para os servidores: Eles só recebem requisições e devolvem respostas. Simplifica o projeto dos servidores; O cliente determina o método que vai utilizar; Diferente de outros sistemas onde a interface define o método e o servidor precisa ser projetado de acordo; Se o cliente não precisa da resposta a uma requisição, o call-stream não a devolve para o cliente. Promessas Liskov e Shrira, 1988; Uma promessa é criada no momento de uma chamada a um servidor; Pode assumir dois estados possíveis: Bloqueado; Pronto. Quando criada, a promessa fica no estado bloqueado; Uma promessa é associada com uma requisição específica; Quando chega a resposta a essa requisição, ela é armazenada na promessa correspondente; Neste caso, o estado da promessa passa para pronto; Funções: claim(): extrai a resposta de uma promessa; se ela estiver no estado bloqueado, o cliente bloqueia até que a promessa passe para o estado de pronto ou que ocorra uma exceção. ready(): testa o estado de uma promessa. 5.4 Eventos e notificações

14 14 SD Cap. 5-6 Objetos que geram eventos numa plataforma distribuída publicam os eventos disponíveis para observação por outros objetos; Objetos que querem receber notificações de eventos publicados assinam tipos de eventos em que têm interesse; Objetos que representam eventos são chamados de notificações. Sistemas baseados em eventos têm 2 características principais: Heterogêneos: permite que objetos não projetados para interoperação trabalhem em conjunto. Um sistema de eventos que permite publicação e assinatura pode permitir trabalho conjunto para objetos que não foram projetados com esse fim; Assíncronos: permite notificação de eventos aos assinantes sem necessidade de sincronismo, o que significa bloqueio dos envolvidos Participantes em notificações de eventos distribuídos Arquitetura que permite independência entre autores e assinantes: Banco de dados com eventos publicados e interesse dos assinantes; Quando ocorre um evento que possui interessados, uma notificação é enviada. Participantes: Objetos de interesse: aqueles que possuem métodos que podem alterar estados isso gera eventos que podem ter interessados; Evento: ocorre como resultado da execução de um método; Notificação: objeto que contém informações sobre um evento: Assinante: assina algum tipo de evento em outro objeto recebe notificações dele; Observadores: objetos que isolam autores de assinantes. Eles monitoram os eventos e notificam aqueles assinados; Autor: objeto que declara que vai gerar notificações de certos tipos de eventos. Pode ser um objeto de interesse ou um observador. Possíveis casos de comportamento em um serviço de eventos: Objetos de Interesse enviam notificações diretamente aos assinantes; OdI enviam notificações via observadores aos assinantes; OdI fora do serviço de eventos. Observadores fazem consultas ao OdI para descobrir quando ocorre um evento. Ele é notificado aos assinantes. Papéis dos observadores Encaminhar notificações para os assinantes de um ou + objetos de interesse. São os objetos de interesse que informam os observadores sobre seus assinantes; Filtros de notificações: aplicados pelos observadores para reduzir a quantidade de notificações. São baseados em regras informadas pelos assinantes. Ex.: num banco, retiradas, mas apenas as maiores que 10000,00; Padrões de eventos: relação de eventos entre si. Ex.: num banco, quero ser informado sempre que houver 3 retiradas sem um depósito; Caixas de correio para notificações: usadas para encaminhar notificações sem que o assinante receba na hora. Ex.: ele não possui uma conexão permanente, ou tornou-se passivo. As notificações são recuperadas mais tarde.

15 15

16 16 Cap. 6 Suporte dos Sistemas Operacionais 6.1 Introdução Função importantes de um SD: compartilhamento de recursos. Clientes invocam operações sobre recursos em outros nós ou outros processos. Middleware: permite a interação entre aplicações clientes e recursos (gerentes). O SO fica abaixo do middleware; O que importa aqui é o relacionamento entre os dois; Como o SO permite ao middleware o acesso aos recursos físicos, como ele implementa políticas de acesso, etc. Abstrações: SO fornece modelos para manipular certos recursos; Ex.: arquivos x blocos de disco; Ex.: sockets x fluxo de redes. Num SO de rede (Unix, NT, etc.), o usuário que precisa executar um programa numa máquina diferente precisa se envolver: Telnet, fornece senha, executa o programa. SO Distribuído: O usuário não se preocupa com o nó em que seu programa executa; Não importa onde estão os recursos; O usuário vê uma única imagem do sistema; A esolha de um nó para executar um programa depende da política de escalonamento. Caracterização de um SOD: Permite a programação de um SD, permitindo a implementação de uma grande gama de aplicações; Apresenta para as aplicações abstrações genéricas e orientadas aos problemas dos recursos do sistema; Num SD aberto, o SOD é implementado como um conjunto de kernels e servidores. Não há uma distinção clara entre os serviços do sistema e as aplicações que rodam no topo do SOD. Exemplos: Mach e Chorus. Resultados de grandes períodos de pesquisa nos anos 80 e 90; Alto nível de interesse técnico e comercial; Outros exemplos técnicos: Amoeba, Clouds, V System; Não aceitos para uso geral; Todos esses projetos empregam microkernel. SOD: Infraestrutura de gerenciamento genérico de recursos e transparente em rede; Recursos de baixo nível: processadores, memória, placas de rede, periféricos em geral;

17 Plataforma para recursos de alto nível: planilhas, troca de mensagens eletrônicas, janelas; Oferecidos aos clientes pelos serviços do sistema; 17 Acesso aos recursos pelo sistema: Feito de forma transparente; Identificadores independentes de localização; Uso das mesmas propriedades; Transparência fornecida no nível mais baixo, para que não precise ser feita em cada serviço; Um SOD deve fornecer ferramentas para encapsular recursos: De forma modular; Modo protegido; Amplo acesso via rede. Encapsulamento de recursos: Interface padronizada implementação escondida do usuário; Concorrência recursos compartilhados por vários usuários; Proteção segurança contra acesso ilegítimo. Os clientes acessam os recursos através da passagem de identificadores como argumentos: Em system calls para o kernel; RPC para um servidor. Invocação: acesso a um recurso encapsulado. Tarefas relacionadas com a invocação de recursos: Resolução de nomes localização; Comunicação para acesso aos recursos; Escalonamento: processamento das invocações no kernel. Middleware x SOs de rede Não há SOs distribuídos em uso corrente hoje; Apenas SOs de rede (Unix, NT, MacOS, etc.); Motivos: o Usuários se preocupam com suas aplicações de uso comum; o Não trocam seus SOs por melhor que seja um outro produto se não puderem executar suas aplicações; o Usuários preferem ter um certo controle sobre suas máquinas; o A idéia de entregar os recursos a outros usuários sem controle é estranha. Por outro lado, o uso de um middleware com um SO de rede é + versátil e aceitável: O usuário consegue rodar seus programas favoritos; Ele tem controle sobre os recursos de sua máquina; Os usuários remotos têm um certo grau de transparência no acesso aos recursos da rede; É possível acessar recursos compartilhados com um certo grau de concorrência. 6.2 Camada de sistema operacional Aplicações, serviços

18 18 Middleware OS1 Processos, threads, comunicação, etc. Hardware do computador e rede OS2 Processos, threads, comunicação, etc. Hardware do computador e rede Nó 1 Nó 2 As interfaces apresentadas por kernels e servidores devem apresentar pelo menos o seguinte: Encapsulamento: conjunto mínimo de operações fornecidas aos clientes. Detalhes de implementação escondidos; Proteção: evita acessos indevidos; Concorrência: clientes devem acessar os recursos de forma concorrente. Isso deve ser transparente para eles. Kernel Kernels e proteção: O Kernel executa com privilégio de acesso total; Ex.: pode controlar a unidade de MM; Pode conceder privilégio de acesso a recursos físicos; Determina o espaço de endereçamento: Permite que os processos se protejam uns dos outros; Evita que um processo invada áreas indevidas. Modo supervisor e usuário: Processos usuários podem rodar em modo supervisor quando tem acesso direto a um dispositivo; System call trap: mecanismo de invocação de recursos gerenciados pelo kernel; Kernel monolítico e microkernel um SOD aberto deve permitir: Executar apenas o suficiente para tornar o ambiente operacional (módulos supérfluos gastam recursos); Alterações no software ou sistema que implementa um serviço, independentemente de outros elementos; Alternativas do mesmo serviço para atender usuários ou aplicações diferentes; Introdução de novos serviços sem prejudicar os existentes. Um certo grau de abertura é obtido com a utilização de kernels tradicionais como base. Ex.: o DCE da OSF usa Unix, VMS, OS/2, etc. Permitem a execução de processos servidores; Suportam protocolos (ex.: RPC); Possuem binding e serviços de nomes; Serviços de tempo (sincronização); Segurança; Threads.

19 Unix: Monolítico; Sugere um sistema massivo; Executa todas as operações básicas do sistema; 1 MB de código e dados; Não diferenciável: codificado de forma não modular; Intratável: a alteração de um módulo para adequação a novos requisitos é muito difícil. 19 Sn Carregado dinamicamente S1 S2 S3 S1 S2 S3 Kernel monolítico MicroKernel Principais funções de um microkernel: Processos; Memória; IPC; Todos os outros serviços carregados dinamicamente em servidores específicos; Um serviço extra só é carregado na máquina que precisa dele; Acesso via invocação (RPC). O microkernel na hierarquia de um sistema: Serviços abertos processos/objetos das aplicações Suporte de linguagem Suporte de linguagem Microkernel Hardware Emulação de OS Comparação: Abertura; Modularidade; Um kernel pequeno tem mais chances de ter menos bugs; Mais fácil de manter; Kernel monolítico é mais difícil de ser modular; Impossível extrair um módulo para execução remota; Um bug num módulo pode se espalhar para os demais; Alterar um módulo implica em recompilar o kernel e reiniciá-lo; Vantagem: eficiência para realizar as tarefas. Arquitetura de um microkernel

20 Em princípio, não há uma definição clara de quais módulos um microkernel deve ter. Todos os produtos dessa categoria incluem: Gerência de processos; Gerência de memória; Passagem de mensagens local. Tamanho: 10 KB até várias centenas de KB de código e dados estáticos. 20 Microkernels são projetados para serem portáveis: A maior parte de seu código é escrito em linguagem de alto nível (C, C++, etc.); Recursos físicos são agrupados em camadas; Componentes dependentes de máquina são reduzidos: Manipulação do processador, unidade de gerência de memória, registradores da unidade de ponto flutuante; Tratamento de interrupções; Traps; Exceções. A arquitetura de um microkernel geral pode ser visto na figura: Aplicações Gerente de Processos Gerente de Comunicações Gerente de Threads Gerente de Memória Supervisor Hardware Gerente de processos: criação, interface, etc. Gerente de Threads: criação, sincronização, escalonamento. Processadores disponíveis. Política de escalonamento a critério do usuário. Gerente de comunicação: IPC. Gerente de memória: memória física, MMU, caches. Supervisor: tratamento de interrupções, system calls, exceções. 6.4 Processos e threads Unix: 1 processo, 1 atividade de processamento (1980). Processo: recurso caro para criar e manter. O compartilhamento entre atividades relacionadas é caro e complexo. Solução: generalização do conceito de processo. Associar mais de uma atividade ao mesmo processo. Processo: ambiente de execução + 1 ou mais threads. Thread: abstração de atividade do sistema operacional. "Thread of execution". Ambiente de execução: unidade de gerenciamento de recursos. Coleção de recursos gerenciados pelo kernel local, aos quais suas threads têm acesso;