PLATAFORMAS DISTRIBUÍDAS

1. PLATAFORMAS DISTRIBUÍDAS Eleri Cardozo FEEC/UNICAMP http://www.fee.unicamp.br/~eleri Julho de 2002 (c) FEEC/UNICAMP

2. Introdução aos Sistemas Distribuídos (c) FEEC/UNICAMP

3. Sistemas Distribuídos: Definição Um sistema distribuído é um sistema computacional com as seguintes propriedades: 1. distribuição: um subconjunto de seus componentes encontram-se geograficamente dispersos; 2. concorrência: um subconjunto de seus componentes executam concorrentemente (em paralelo); 3. ausência de estado global: é impossível determinar-se precisamente o estado global do sistema; 4. falhas parciais: qualquer componente do sistema pode falhar independente dos demais; 5. assincronismo: as atividades do sistema não são regidas por um relógio global. (c) FEEC/UNICAMP

4. Sistemas Distribuídos: Motivação Evolução em microprocessadores:constante incremento da capacidade de processamento com decréscimo de custo. Evolução em redes de comunicação: velocidades de Gigabits/s já disponíveis a custo atrativo. Portanto, a utilização de uma rede rápida de processadores poderosos é atrativa para abrigar sistemas complexos de software. (c) FEEC/UNICAMP

5. MIPS 100000 20 BIPS 10000 1000 DEC Alpha HP PA 100 Pentium Mips 10 486 386 286 1 1982 2002 1997 1992 1987 2007 Evolução em Microprocessadores (c) FEEC/UNICAMP

6. Mbits/s 10000 10 Gbits/s 1000 ATM Gigabit Ethernet 100 T. Ring Fast Ethernet FDDI 10 Ethernet ISDN Frame Relay X.25 1 1982 2002 1997 1992 1987 2007 Evolução em Redes (c) FEEC/UNICAMP

7. Downsizing $$$ $$$ (c) FEEC/UNICAMP

8. Downsizing: Benefícios • liberdade de escolha (fornecedores, produtos, etc.); • confiabilidade (múltiplos pontos de falha); • processamento espacial da informação; • aumento incremental da capacidade de processamento; • atualização tecnológica constante. (c) FEEC/UNICAMP

9. Internet (c) FEEC/UNICAMP

10. Sistemas Abertos Sistemas Abertos são sistemas implementados segundo padrões abertos. Padrão aberto: documento estabelecido por consenso e publicado por organismo de padronização acreditado para uso comum e repetitivo. NOTA: esta definição exclui muitos padrões de-facto tais como Java, Windows e MATLAB. (c) FEEC/UNICAMP

11. Sistemas Abertos: Uma Classificação Podemos classificar Sistemas Abertos em quatro categorias: 1. Modelos de Referência; 2. Arquiteturas de Referência; 3. Arquiteturas Abertas; 4. Implementações de Referência. (c) FEEC/UNICAMP

12. Modelos de Referência Um modelo de referência é uma descrição de todos os possíveis componentes do sistema, bem como suas funções, relações, e formas de interação [SEI]. Exemplos: OSI, RM-ODP, OMA. Por não imporem restrições para a realização de seus componentes, modelos de referência não garantem interoperabilidade entre diferentes implementações. Entretanto, modelos de referência são úteis para a concepção de arquiteturas para sistemas abertos. (c) FEEC/UNICAMP

13. Arquiteturas de Referência Uma arquitetura de referência é similar a um modelo de referência, mas prescreve interfaces entre seus componentes. Exemplos: TINA, CORBAservices. Arquiteturas de referência possuem lacunas na especificação que levam a diferentes interpretações e possibilidades de extensões. Estas lacunas tendem a comprometer a interoperabilidade entre diferentes implementações da arquitetura. (c) FEEC/UNICAMP

14. Arquiteturas Uma arquitetura é similar a um modelo ou arquitetura de referência, mas prescreve protocolos de interopera-bilidade para todos os seus componentes. Exemplos: CORBA, H.323, TCP/IP, ISDN. Arquiteturas provêem interoperabilidade mínima entre suas implementações. (c) FEEC/UNICAMP

15. Implementações de Referência Uma implementação de referência provê código fonte aberto (não necessariamente gratuito) para os componentes de uma arquitetura que são fundamentais para a interoperabilidade entre diferentes implementações desta arquitetura. Exemplos: FreeDCE, TMN API, HTTPd. Implementações de referência garantem o maior nível possível de interoperabilidade para implemen-tações de sistemas abertos. (c) FEEC/UNICAMP

16. CORBA Facilities (horizontal) CORBA Facilities (vertical) Objetos de Aplicação Object Request Broker (ORB) Serviços CORBA (CORBAservices) Exemplo de Padrão Aberto: CORBA O modelo de referência OMA. CORBA especifica o Object Request Broker do modelo OMA. Interoperabilidade entre implementações CORBA é garantida pela linguagem IDL e pelo protocolo IIOP. (c) FEEC/UNICAMP

17. Exemplo de Padrão Aberto: CORBA • IDL e IIOP garantem que duas implementações CORBA sempre irão interoperar no tocante a invocação remota demétodos. • Serviços CORBA (CORBAservices) nem sempre interoperam pois apenas suas interfaces são especificadas (faltam implementações de referência e/ou melhor especificação de comportamento). • Gerência, configuração e recursos avançados de diferentes implementações CORBA não interoperam. (c) FEEC/UNICAMP

18. Sistemas Abertos: Conclusão • Sistemas abertos são fundamentais para: • tornar as implementações menos dependentes de fornecedor individual; • incentivar a competição entre diferentes fornecedores por melhores produtos; • desenvolver aplicações portáveis, confiáveis, com alto grau de interoperabilidade e capazes de evoluir de forma ordenada; • incentivar a inserção de novas tecnologias. (c) FEEC/UNICAMP

19. O Conceito de Middleware (c) FEEC/UNICAMP

20. OPA! Isto eu conheço!!! APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO O Conceito de MiddlewareVisão a Partir do Modelo OSI (c) FEEC/UNICAMP

21. Telecomunicações Finanças Medicina APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO Conceito de Middleware e o Modelo OSI (c) FEEC/UNICAMP

22. } Cliente Agente Agente Gerenciamento de Rede APLICAÇÃO }Domínio de aplicação APRESENTAÇÃO Ex: funções típicas de telecomunicações SESSÃO TRANSPORTE REDE Um novo Modelo OSI: camada nível 8 contendo funções típicas dos vários domínios de aplicação:Medicina, Finanças, Telecomunicações, etc. ENLACE FÍSICO Conceito de Middleware e o Modelo OSI (c) FEEC/UNICAMP

23. APLICAÇÃO APRESENTAÇÃO Domínio da aplicação SESSÃO Contexto da Aplicação TRANSPORTE A Camada de Transporte é um divisor entre o mundo das aplicações e o mundo das comunicações REDE ENLACE FÍSICO Contexto das Comunicações Conceito de Middleware e o Modelo OSI (c) FEEC/UNICAMP

24. APLICAÇÃO Domínio da aplicação APRESENTAÇÃO SESSÃO TRANSPORTE REDE MIDDLEWARE ENLACE FÍSICO Conceito de Middleware e o Modelo OSI (c) FEEC/UNICAMP

25. Domínio da aplicação Necessidade de Padronização do Middleware APLICAÇÃO APRESENTAÇÃO SESSÃO } Sistema Operacional + Hardware Sistemas Heterogêneos! Conceito de Middleware e o Modelo OSI (c) FEEC/UNICAMP

26. agentes componentes objetos distribuídos chamada de procedimento remoto (RPC) troca de mensagens 1977 1982 2002 1997 1992 1987 2007 Evolução em Middleware (c) FEEC/UNICAMP

27. Aplicação Aplicação Send Receive API independente do transporte TLI CPC-I Socket Named Pipes SNA TCP/IP IPX/SPX NetBIOS Pilhas de Transporte NDIS ODI Drivers de Rede ... Placas de Rede Ethernet ISDN Token-ring Evolução do Conceito de MiddlewareTroca de Mensagens (primitivas SEND/RECEIVE) (c) FEEC/UNICAMP

28. tarefa 2 tarefa 1 send(M1) send(M1) tarefa 2 tarefa 1 receive(M1) receive(M2) receive(M2) bloqueio send(M2) Troca de Mensagens: Semântica (c) FEEC/UNICAMP

29. Troca de Mensagens: Implementação espaço do usuário espaço do núcleo port (endpoint) API (socket) API (socket) buffer sistema de transporte (TCP/IP) sistema de transporte (TCP/IP) LAN / WAN (c) FEEC/UNICAMP

30. Aplicação Aplicação 2- Call (…) 1- Register (…) 3- Call (…) Remote Procedure Call (RPC) TLI CPC-I Socket Named Pipes SNA TCP/IP IPX/SPX NetBIOS NDIS ODI Ethernet Token-ring ISDN Evolução do Conceito de MiddlewareChamada Remota de Procedimento (RPC) (c) FEEC/UNICAMP

31. cliente servidor call P2(a1,a2) call P2(a1,a2) cliente servidor bloqueio P1 P2 executa P2 retorno P3 retorno RPC: Semântica (c) FEEC/UNICAMP

32. cliente servidor R = call P2(a1,a2) P3 P2 P1 1 5 8 4 P2(a1,a2) dispatcher empacota parâmetros desempacota parâmetros empacota resultado desempacota resultado bibliotecas RPC 2 3 6 7 a2 a1 P2 API (socket) API (socket) resultado RPC: Implementação (c) FEEC/UNICAMP

33. Objeto Barramento de Software Interface Padrão Evolução do Conceito de MiddlewareObjetos Distribuídos • O conceito de objetos surgiu para atender os requisitos • relacionados ao aumento na complexidade do desenvolvimento • de software Reusabilidade (c) FEEC/UNICAMP

34. estado: define um conjunto de variáveis internas que armazenam o estado corrente do objeto interface: define, em termos de protótipo, um conjunto de operações (ou métodos) implementação: código dos métodos definidos tanto pelas interfaces quantos internos ao objeto Objetos: Constituição (c) FEEC/UNICAMP

35. Objetos: Regras de Interação • toda a interação com um objeto se dá através da invocação de seus métodos declarados como públicos; • métodos declarados como privados só podem ser invocados pelos demais métodos definidos pelo objeto; • as variáveis de estado são manipuladas apenas pelos métodos (públicos ou privados) definidos pelo objeto (isto é, são invisíveis externamente ao objeto). (c) FEEC/UNICAMP

36. Objetos: Conceitos Básicos • Classificação: objetos são organizados em classes. Uma classe define o comportamento dos objetos dela derivados. • Relacionamento: classes podem apresentar relações de interdependência, por exemplo • herança (relação tipo é-um/é-uma); • composição (relação tipo parte-de); • colaboração (relações tipo usa, delega, autoriza, etc). (c) FEEC/UNICAMP

37. Objetos: Conceitos Básicos Instanciação: objetos são criados através de uma operação (denominada de instanciação) sobre uma classe. Encapsulamento: objetos “escondem” detalhes de sua implementação interna, expondo apenas suas interfaces para o meio externo. Identidade: objetos possuem identidade única capaz de diferenciar um objeto dos demais. Polimorfismo: métodos de mesmo nome podem apresentar diferentes comportamentos, dependendo do objeto que o implementa. (c) FEEC/UNICAMP

38. classe classe relação herança (especialização) encapsulamento instanciação estado classe métodos interface M3 M1 invocação de métodos identidade M2 polimorfismo M2 Objetos: Conceitos Básicos (c) FEEC/UNICAMP

39. Objetos Distribuídos • Deve-se notar que as tecnologias de middleware procuram acompanhar as tecnologias de desenvolvimento de software: • troca de mensagens: estende o paradigma de programação não estruturada à programação de sistemas distribuídos (programação distribuída); • RPC: estende o paradigma de programação estruturada à programação distribuída; • objetos distribuídos: estende o paradigma de programação orientada a objetos à programação distribuída. (c) FEEC/UNICAMP

40. Objetos Distribuídos: Vantagens • Objetos distribuídos apresentam as seguintes vantagens sobre troca de mensagens e RPC: • flexibilidade: qualquer entidade de software pode ser transformada em um objeto distribuído; • granularidade: objetos distribuídos podem apresentar diferentes níveis de granularidade; • confiabilidade: objetos distribuídos são entidades auto-contidas o que facilita a identificação, isolação e correção de falhas; • custo: o desenvolvimento de objetos distribuídos é mais econômico graças ao reuso de software propiciado pela programação orientada a objetos. (c) FEEC/UNICAMP

41. Objetos Distribuídos: Interação • Objetos distribuídos são capazes de interagir através de uma rede de comunicação (LAN, Intranet, Internet) de forma semelhante à interação entre objetos locais. Para tanto, padrões são necessários para prover: • definição de interfaces remotas; • identificação de objetos (referências); • "nomeação" de objetos (naming); • associação nome-referência (binding); • suporte à invocação remota de métodos (RPC). • Estes padrões são oferecidos por uma infra-estrutura denominada ORB (Object Request Broker). Por exemplo, RMI é o ORB nativo da linguagem Java. (c) FEEC/UNICAMP

42. Interfaces Remotas Objetos distribuídos devem definir pelo menos uma interface remota capaz de processar invocações através da rede. Em padrões neutros (independentes de linguagem de programação) como CORBA e DCOM, uma linguagem de definição de interface (IDL) é especificada. ORBs provêem compiladores IDL para cada linguagem alvo. RMI, por ser uma solução puramente Java, utiliza interfaces Java derivadas da interface Remote para definir interfaces remotas. Um servant (ou implementação) é um objeto que implementa uma interface remota (i.e., supre código para os métodos da interface). Um objeto distribuído é constituído por um ou mais servants. (c) FEEC/UNICAMP

43. Compilador de Interfaces Objetos Distribuídos: Implementação ORB (biblioteca) Descrição da(s) Interface(s) Compilador (C++, Java, ...) Implementação dos Servants (C++, Java, ...) Stubs / Skeletons servant (c) FEEC/UNICAMP

44. Referência de Objetos Objetos distribuídos devem possuir uma identificação (referência) capaz de localizá-lo na rede. Esta identificação é dependente do ORB. Por exemplo, CORBA utiliza um identificador denominado IOR (Interoperable Object Reference) que agrega o endereço de rede do objeto (host e port do servidor), sua classe, seu identificador no servidor, etc. IOR é armazenado em uma cadeia de bytes. RMI utiliza as próprias instâncias das classes Java que implementam interfaces remotas para identificar objetos distribuídos. OBS: Uma referência pode ser persistente ou transiente. (c) FEEC/UNICAMP

45. interface remota cliente Rede Skeleton Stub M1 M1 M1 M2 M3 objeto distribuído M1 M2 M3 upcall protocolo de RPC invocação local Stubs e Skeletons Para interagir com um objeto remoto, um objeto cliente deve obter a referência do objeto remoto e converte-la em um objeto local denomindo proxy ou stub. Stubs definem os mesmos métodos da interface remota do objeto. Ao invocar um método no stub, o stub encaminha a requisição para o objeto remoto, recebe o retorno e o devolve como resultado da interação. Skeletons fazem o papel inverso do stub no lado do objeto remoto. (c) FEEC/UNICAMP

46. Atribuição de Nomes ORBs convencionam esquemas de nomes para os objetos distribuídos. Por exemplo, CORBA utiliza um espaço hierárquico e arbitrário de nomes definido em um contexto. RMI utiliza uma notação padrão URL: rmi://ferrugem.dca.fee.unicamp.br:8088/Servers/AccountServer //143.106.50.188/AccountServer (c) FEEC/UNICAMP

47. servidor de nomes 1. bind/rebind 2. lookup objeto distribuído 3. invoke cliente Binding ORBs provêem serviços de nomes para armazenar e recuperar associações nome-referência de objeto. No caso do RMI, um servidor de nomes denominado rmiregistry é fornecido com a plataforma Java. (c) FEEC/UNICAMP

48. Invocação Remota de Métodos • A invocação de métodos remotos exige protocolos de RPC (Remote Procedure Call). Tais protocolos especificam: • como parâmetros são codificados (número de parâmetros, tipos, valores e indireções); • como invocações e retornos são estruturados; • que protocolo de transporte é utilizado (TCP ou UDP); • como exceções são propagadas de volta para o cliente. • CORBA especifica o protocolo IIOP (Internet Inter-ORB Protocol), enquanto RMI especifica JRMP (Java Remote Method Protocol). Opcionalmente, para fins de interoperabilidade com CORBA, RMI pode utilizar IIOP. (c) FEEC/UNICAMP

49. servidor cliente servant objeto distribuído Stub Skeleton Object Request Broker Nomes Eventos Segurança Serviços Arquitetura de Distribuição (c) FEEC/UNICAMP

50. Middleware: Padrões DCOM (Microsoft) EJB (Sun) Indústria .NET (Microsoft) RMI (SUN) DCE (OSF) CORBA (OMG) SOAP (W3C) Consórcios ISO/ITU-T OSI ODP Internet WWW RPC TCP/IP sockets 1977 1992 2002 1982 1997 1987 (c) FEEC/UNICAMP