1
2 Caracterização de Sistemas Distribuídos: Os sistemas distribuídos estão em toda parte. A Internet permite que usuários de todo o mundo acessem seus serviços onde quer que possam estar. Cada organização gerencia uma intranet, a qual fornece serviços locais e serviços Internet para usuários locais e remotos. Sistemas distribuídos de pequena escala podem ser construídos a partir de computadores móveis e outros dispositivos computacionais portáteis interligados através de redes sem fio. O compartilhamento de recursos é o principal fator de motivação para a construção de sistemas distribuídos. Recursos como impressoras, arquivos, páginas web ou registros de banco de dados são gerenciados por servidores de tipo apropriado, por exemplo, servidores web gerenciam páginas web. Os recursos são acessados por clientes específicos, por exemplo; os clientes dos servidores web geralmente são chamados de navegadores.
3 Caracterização de Sistemas Distribuídos: A construção de sistemas distribuídos gera muitos desafios: Heterogeneidade: eles devem ser construídos a partir de uma variedade de redes, sistemas operacionais, hardware e linguagens de programação diferentes. Os protocolos de comunicação da Internet mascaram a diferença existente nas redes e o middleware pode cuidar das outras diferenças. Sistemas abertos: os sistemas distribuídos devem ser extensíveis - o primeiro passo é publicar as interfaces dos componentes, mas a integração de componentes escritos por diferentes programadores é um desafio real. Segurança: a criptografia pode ser usada para proporcionar proteção adequada para os recursos compartilhados e para manter informações sigilosas em segredo, quando são transmitidas em mensagens por uma rede. Os ataques de negação de serviço ainda são um problema.
4 Caracterização de Sistemas Distribuídos: Escalabilidade: um sistema distribuído é considerado escalável se o custo da adição de um usuário for um valor constante, em termos dos recursos que devem ser adicionados. Os algoritmos usados para acessar dados compartilhados devem evitar gargalos de desempenho e os dados devem ser estruturados hierarquicamente para se obter os melhores tempos de acesso. Os dados acessados freqüentemente podem ser replicados. Tratamento de falhas: qualquer processo, computador ou rede pode falhar, independentemente dos outros. Portanto, cada componente precisa conhecer as maneiras possíveis pelas quais os componentes de que depende podem falhar e ser projetado de forma a tratar de cada uma dessas falhas apropriadamente.
5 Caracterização de Sistemas Distribuídos: Concorrência: a presença de múltiplos usuários em um sistema distribuído é uma fonte de pedidos concorrentes para seus recursos. Em um ambiente concorrente, cada recurso deve ser projeta do para manter a consistência nos estados de seus dados. Transparência: o objetivo é tornar certos aspectos da distribuição invisíveis para o programador de aplicativos, para que este se preocupe apenas com o projeto de seu aplicativo em particular. Por exemplo, ele não precisa estar preocupado com sua localização ou com os detalhes sobre como suas operações serão acessadas por outros componentes, nem se será replicado ou migrado. As falhas de rede e de processos podem ser apresentadas aos programadores de aplicativos na forma de exceções mas elas devem ser tratadas.
6 Modelos de Sistema Um modelo de arquitetura de um sistema distribuído envolve o posicionamento de suas partes e os relacionamentos entre elas. Exemplos incluem o modelo cliente-servidor e o modelo peer-topeer. Não existe a noção de relógio global em um sistema distribuido, portanto os relógios de diferentes computadores não fornecem necessariamente a mesma hora. Toda comunicação entre processos é obtida por meio de troca de mensagens. A comunicação por troca de mensagens em uma rede de computadores pode ser afetada por atrasos, pode sofrer uma variedade de falhas e é vulnerável a ataques contra a segurança.
7 Modelos de Sistema Camadas de Software Applications, services Middleware Operating system Platform Computer and network hardware
8 Modelos de Sistema Plataforma: As camadas de hardware e software de mais baixo nível são frequentemente denominadas de plataforma para sistemas e aplicativos distribuidos. Essas camadas de mais baixo nível fornecem serviços para as camadas que estão acima delas de forma a levar a interface de programação do sistema a um nível de facilita a comunicação e a coordenação entre processos. Intel x86/windows, Intel x86/solaris, Power PC/Mac, são exemplos importantes de plataformas.
Modelos de Sistema SISTEMAS DISTRIBUIDOS 9 Middleware: O termo middleware se aplica a uma camada de software que fornece abstração de programação, assim como o mascaramento de heterogeneidade das redes, do hardware, de sistemas operacionais e linguagens de programação subjacentes. Exemplos de middleware: CORBA ( Common Object Request Broker Architecture ). JAVA RMI ( Remote Method Invocation ). MICROSOFT - DCOM
10 CORBA ( Common Object Request Broker Architecture ): Tecnologia padrão de objetos e sistemas distribuidos, definido pelo OMG ( The object management group ). Mais de 700 empresas participantes como: HP, IBM, etc... CORBA oferece grande portabilidade integrando, por exemplo, linguagem COBOL com outras com suporte a CORBA. Serviços CORBA são descritos através de uma linguagem chamada IDL ( interface definition language ) que é a maneira de especificar as interfaces dos objetos servidores que os objestos clientes precisam conhecer. CORBA permite a troca de dados entre dois sistemas remotos.
CORBA ( Common Object Request Broker Architecture ): Para que ocorra a comunicação entre os clientes e os servidores CORBA, as chamadas dos clientes são repassadas para o mecanismo de comunicação da arquitetura CORBA que são os ORBs(Object Request Brokers) que baseiam-se no protocolo para objetos remotos IIOP(Internet Inter-ORB Protocol). O ORB atua como um barramento de comunicação sobre o qual todo objeto CORBA interage, transparentemente, com outros objetos CORBA localizados remota ou localmente. Um objeto CORBA interage com o ORB através da interface ORB ou através de um Object Adapter (um BOA Basic Object Adapter ou POA Portable Object Adapter). 11
12 JAVA RMI ( Remote Method Invocation ): O Remote Method Invocation (RMI) fornece um modelo simples e direto para computação distribuída com objetos java. Estes objetos podem ser objetos java, ou podem ser wrappers java [JAV2000a]. RMI é orientado a objetos em todos os níveis, mensagens são enviadas para objetos remotos, e objetos podem ser passados e retornados. É um componente do JDK idealizado para suportar chamadas de métodos remotos através de máquinas virtuais Java (JVM).
13 JAVA RMI ( Remote Method Invocation ). O RMI traz um modelo de objetos distribuídos para a linguagem Java. Através de RMI, objetos podem ser passados e retornados como parâmetros, diferente da maioria dos mecanismos baseados em chamadas de procedimentos remotos que exigem que os parâmetros sejam tipos de dados primitivos ou estruturas compostas de tipos primitivos. Isto significa que um novo código pode ser enviado através da rede dinamicamente carregado em tempo de execução por máquinas virtuais estrangeiras [JAV2000]. Um objeto RMI é basicamente um objeto Java remoto cujos métodos podem ser chamados por outra JVM(que pode estar em qualquer ponto da rede). Os métodos do objeto remoto RMI podem ser chamados como se o objeto fosse local. Uma referência para um objeto remoto pode ser passada em um argumento ou retornada como resultado. Não há necessidade de usar uma IDL, como em CORBA, para definir a interface dos objetos remotos.
14 JAVA RMI ( Remote Method Invocation ). Os objetos remotos são criados usando interfaces normais Java. Fornece facilidades semelhantes a um ORB de modelo Java para modelo Java. A desvantagem é que o RMI é proprietário. Ele não foi projetado para trabalhar com outros ORBs ou linguagens diferentes de Java[ORF97]. Ao trabalhar com serviços remotos, clientes RMI podem acessar novas versões de serviços Java quando estas são disponibilizadas. Não há necessidade de distribuir código para todos os clientes que poderiam conectar-se. O código pode ser acessado de um sistema de arquivos local ou remoto, ou ainda de um servidor web, facilitando mais a distribuição. Um registro(registry) é mantido para permitir aos clientes realizarem consultas para um determinado serviço. A figura a seguir mostra a interação entre diferentes componentes de um sistema RMI[JAV2000].
15 JAVA RMI ( Remote Method Invocation ). Clientes que conhecem um determinado serviço podem consultar sua localização em um registro e acessar o serviço. Caso seja necessário uma nova classe, ela pode ser carregada de um servidor web.
16 MICROSOFT DCOM: O Distribuited Component Object Model DCOM é o modelo de objetos distribuídos proposto pela Microsoft. É a tecnologia básica para ActiveX e Microsoft Internet Explorer. Todos os produtos Microsoft baseiam-se neste modelo. Ao contrário do que poderia se pensar, DCOM possui implementações não somente em Windows, sua plataforma principal, mas também em Mac OS, Solaris, AIX, MVS e Linux. O DCOM suporta objetos remotos através de um protocolo denominado Object Remote Procedure Call (ORPC).
17 MICROSOFT DCOM: Um servidor DCOM é uma camada de código que é capaz de servir objetos de um determinado tipo em tempo de execução. Um servidor de objetos DCOM pode ter múltiplas interfaces, cada uma representando um diferente comportamento do objeto. Um cliente DCOM chama os métodos disponíveis de um servidor DCOM obtendo um ponteiro para uma das interfaces de objeto deste. O objeto cliente pode então iniciar a chamar os métodos disponíveis no servidor, através do ponteiro para a interface, como se o objeto servidor residisse no espaço de endereçamento do cliente. Como a especificação COM está em nível binário, ela permite servidores DCOM serem escritos em n linguagens distintas como: Java, C++, Delphi, Visual Basic e COBOL [RAJ99].
18 MICROSOFT DCOM: O tipo de comunicação em DCOM é do tipo cliente/servidor. Na solicitação de um serviço, um cliente invoca um método implementado por um objeto remoto, que faz o papel de servidor. O serviço fornecido pelo servidor é encapsulado como um objeto e a interface deste objeto é descrita através de uma IDL(Interface Definition Language) assim como em CORBA. Desta maneira fica separada a interface do objeto da sua implementação. As interfaces que são especificadas em um arquivo IDL são as regras para a comunicação entre um servidor e seus clientes. Os clientes irão então poder interagir com os objetos remotos invocando os métodos que estão definidos nesta IDL. A implementação do objeto fica escondida do cliente.
19 MICROSOFT DCOM: Apesar de CORBA e DCOM possuírem algumas semelhanças como ambos utilizarem uma IDL para declaração de interface de objetos, CORBA é baseado em um modelo de objetos clássico; DCOM não. DCOM não suporta especificação de herança múltipla em IDL, porém pode ter múltiplas interfaces, para o mesmo objeto, e obter reuso encapsulando as interfaces de componentes internos e representando-os para um cliente. Obtémse reuso com DCOM através de inclusão e agregação ao invés de herança [ORF97].
20 MICROSOFT DCOM: A princípio toda plataforma que utilize a arquitetura de software baseada em componentes da Microsoft COM (Modelo de Objetos componentes) pode utilizar DCOM. Um objeto COM permite múltiplas interfaces, cada uma representando um comportamento ou visão diferente deste objeto. DCOM é basicamente a extensão de COM para permitir acesso a objetos em máquinas diferentes de maneira transparente(em uma rede local, Internet ou longa distância). Pode utilizar n protocolos de transporte, como NetBios, TCP/IP, IPX/SPX e UDP.
MICROSOFT DCOM: SISTEMAS DISTRIBUIDOS 21 COM suporta chamadas estáticas e dinâmicas de objetos, e é diferente da maneira como CORBA faz através de sua DII (Dynamic Invocation Interface) ou Java por meio de reflexão. Para a invocação estática funcionar, o compilador Microsoft IDL cria o código proxy e stub quando rodar no arquivo IDL. Estes são gravados em registros(registry) do sistema para permitir maior flexibilidade no seu uso[raj97]. O mecanismo de criação de objetos DCOM é o mesmo das bibliotecas COM apenas aperfeiçoado para permitir a criação de objetos em outras máquinas. Para criar um objeto remotamente, as bibliotecas devem saber o nome da máquina onde está localizado o objeto servidor.
MICROSOFT DCOM: SISTEMAS DISTRIBUIDOS 22 A partir do nome do servidor e identificador de classe(clsid), parte das bibliotecas COM chamadas Service Control Manager(SCM) da máquina cliente conecta-se com o SCM na máquina servidora e requisita a criação do objeto. A comunicação entre objeto servidor e cliente são implementados como Comunicações do tipo Remote Procedure Call(RPC) orientada a objetos. Para chamar uma função remota, o cliente efetua uma chamada para o cliente stub(proxy). O stub repassa os parâmetros da chamada para uma mensagem de requisição e invoca um protocolo de transporte para levar! a mensagem para o servidor. Após receber do protocolo a mensagem, o stub do servidor desempacota a mensagem de requisição e chama a função específica no objeto.
23 Modelos de Sistema - Arquitetura de sistema Cliente Servidor: Essa é a arquitetura mais citada quando os sistemas distribuídos são discutidos. Historicamente ela é a mais importante e continua sendo amplamente empregada. Client invocation invocation Server result Server result Client Key: Process: Computer:
24 Modelos de Sistema - Arquitetura de sistema Peer to Peer Nessa arquitetura todos os processos envolvidos em uma tarefa ou atividade desempenham funções semelhantes, interagindo cooperativamente como pares ( peers ) sem distinção entre processos clientes e servidores nem entre os computadores em que são executados. Embora o modelo cliente servidor ofereça uma estratégia direta e ralativamente simples para o compartilhamento de dados e outros recursos ele não flexível em termos de escalabilidade. O objetivo da arquitetura peer to peer é explorar os recursos, tanto de dados quanto de hardware, de um grande número de computadores para o cumprimento de uma tarefa ou atividade.
25 Modelos de Sistema - Arquitetura de sistema Peer 2 Peer 1 Application Application Sharable objects Peer 3 Application Peer 4 Application Peers 5... N
26 Comunicação entre processos Serão estudadas caracteristicas da camada middleware. Applications, services RMI and RPC This chapter request-reply protocol marshalling and external data representation Middleware layers UDP and TCP
27 Comunicação entre processos No modelo OSI a camada de transporte trata basicamente dos protocolos UDP e TCP. Estudaremos como o middleware e como os aplicativos podem utilizar esses protocolos.
28 Comunicação entre processos Características: A passagem de mensagens entre um par de processos pode ser suportada por duas operações de comunicação de mensagem: send e receive, definidas em termos de destinos e mensagens. Para que um processo se comunique com outro, um deles, envia ( send ) uma mensagem para um destino e o outro processo, no destino, recebe (receive) a mensagem.
29 Comunicação entre processos Comunicação Síncrona Comunicação Assíncrona Emprego do protocolo UDP: Para algumas aplicações é aceitável usar um serviço que esteja exposto a falhas por omissões ocasionais. Por exemplo o Domain Name Service, que pesquisa nomes DNS na Internet é implementado sobre UDP. O voice over IP ( VOIP ) também é executado sobre UDP. Às vezes os datagramas UDP são uma escolha atraente, pois eles não sofrem as sobrecargas necessárias a entrega de mensagens garantidas.
30 Comunicação por fluxo TCP: Emprego do TCP: Muitos serviços frequentemente usados são executados em conexões TCP com números de portas reservados. Eles incluem os seguintes: HTTP: o protocolo de trasnferência de hipertexto é usado para comunicação entre navegadores e servidores web. FTP: o protocolo de transferência de arquivos permite a navegação em diretórios em um computador remoto e que arquivos sejam transferidos de um computador para outro por meio de uma conexão. TELNET: este serviço dá acesso a um computador remoto por meio de uma sessão de terminal. SMTP: o protocolo de transferência de correio eletrônico usado para enviar correspondência entre computadores.