DESENVOLVIMENTO DE SISTEMAS DISTRIBUIDOS. Prof. Marcelo de Sá Barbosa. versão draft

Transcrição

1 Prof. Marcelo de Sá Barbosa 1

2 data Comentários 03/08/2011 Início do semestre. Entrega da ementa e comentários sobres os assuntos. Recomendação da bibliografia. Períodos de provas. Limite de faltas para aprovação. Revisão de 10/08/2011 rede de computadores. MÓDULO 1: caracterização de sistemas distribuídos; internet; intranets; computação móvel e ubíqua; compartilhamento de recursos e a web; serviços web MÓDULO 2: Modelos de Sistema; Cliente-Servidor; Java RMI; Corba; COM; 17/08/2011 DCOM. MÓDULO 3: Sistemas distribuídos baseados em objetos MÓDULO 4: Sistemas de Arquivos distribuídos. MÓDULO 5: Sistemas 24/08/2011 distribuídos baseados na Web; Exercicios de fixação MÓDULO 6: Sistemas distribuídos baseados em coordenação. Exercícios de 31/08/2011 fixação 07/09/2011 FERIADO. PROCLAMAÇÃO DA INDEPENDÊNCIA DO BRASIL. 14/09/2011 MÓDULO 7: Sistemas peer-to-peer; 21/09/2011 REVISÃO MÓDULOS 1 A 7. PREPARAÇÃO PARA PROVA P1. 28/09/2011 PROVA P1 Turma Sistemas de informação 05/10/2011 PROVA P1 - Turma Ciência da Computação 2

3 3

4 MÓDULO 1: Caracterização de Sistemas Distribuídos; Internet; Intranets; Computação Móvel e Ubíqua; Compartilhamento de recursos e a web; Serviços Web MÓDULO 2: Modelos de Sistema; Cliente-Servidor; Java RMI; Corba; COM; DCOM. MÓDULO 3: Sistemas distribuídos baseados em objetos 4

5 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. 5

6 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. 6

7 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. 7

8 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. 8

9 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. 9

10 Modelos de Sistema Camadas de Software Applications, services Middleware Operating system Computer and network hardware Platform 10

11 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. 11

12 Modelos de Sistema 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 12

13 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. 13

14 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). 14

15 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). 15

16 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, versão para draft definir a interface dos objetos remotos. 16

17 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]. 17

18 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. 18

19 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). 19

20 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]. 20

21 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. 21

22 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]. 22

23 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. 23

24 MICROSOFT DCOM: 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. 24

25 MICROSOFT DCOM: 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. 25

26 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: 26

27 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. 27

28 Modelos de Sistema - Arquitetura de sistema Peer 2 Peer 1 Application Application Sharable objects Peer 3 Application Peer 4 Application Peers 5... N 28

29 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 29

30 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. 30

31 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. 31

32 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. 32

33 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. 33

34 QUESTÃO QUESTÃO GRUPO 1 1 DEFINA SISTEMAS DISTRIBUIDOS 2 QUAIS SÃO OS PRINCIPAIS DESAFIOS NA CONSTRUÇÃO DE SISTEMAS DISTRIBUIDOS? 3 QUAIS SÃO AS CAMADAS DO MODELO DE SOFTWARE? 4 DEFINA PLATAFORMA 5 O QUE É MIDDLEWARE? 6 QUAL O SIGNIFICADO DE CORBA? 7 QUAL A DIFERENÇA ENTRE JAVA RMI E DCOM? 8 QUAL A FUNÇÃO DE IDL? 9 DEFINA O PROTOCOLO IIOP. QUAL A SUA UTILIZAÇÃO? EXPLIQUE O FUNCIONAMENTO DAS ARQUITETURAS CLIENTE SERVIDOR E PEER TO 10 PEER, UTILIZANDO O CONCEITO DE PROCESSO. 11 O QUE É COMPUTAÇÃO MÓVEL E UBIQUA? FAÇA UM RESUMO SOBRE A ORIGEM DA INTERNET UTILIZANDO OS CONCEITOS DE 12 SISTEMAS DISTRIBUIDOS EXPLIQUE TRÊS DIFERENÇAS FUNDAMENTAIS ENTRE INTERNET E INTRANET COM 13 RELAÇÃO A ENDEREÇAMENTO IP E ROTEAMENTO. ELABORE UM RESUMO SOBRE OS PRINCIPAIS SISTEMAS OPERACIONAIS UTILIZADOS 14 EM EQUIPAMENTOS CELULARES INTELIGENTES, POR EXEMPLO SMARTPHONES NO MÊS DE AGOSTO DE 2011 FOI DIVULGADA A FUSÃO ENTRE UMA DAS PRINCIPAIS EMPRESAS DESENVOLVEDORAS DE SISTEMA OPERACIONAL PARA SMARTPHONES E 15 UMA EMPRESA FABRICANTE DE APARELHOS CELULARES. QUAIS SÃO ESSAS EMPRESAS? DESCREVA OS SISTEMAS OPERACIONAIS ENVOLVIDOS. ENTREGA DE PESQUISA SOBRE QUAIS SÃO AS 5 PRINCIPAIS ESTRUTURAS DE UMA 16 SISTEMA OPERACIONAL. ATIVIDADE ESCRITA DE PRÓPRIO PUNHO PELO ALUNO. 17 QUAL A PRINCIPAL MOTIVAÇÃO PARA CONSTRUÇÃO DE UM SISTEMA DISTRIBUIDO? 34

35 Prof. Marcelo de Sá Barbosa 35

36 MÓDULO 4: Sistemas de Arquivos distribuídos. MÓDULO 5: Sistemas distribuídos baseados na Web; 36

37 MÓDULO 4: Sistemas de Arquivos distribuídos. Introdução Arquitetura de serviço de arquivos Estudo de caso: Sun Network File System Aprimoramentos e outros desenvolvimentos 37

38 Sistemas de Arquivos distribuídos Introdução O compartilhamento de informações armazenadas talvez seja o aspecto mais importante dos recursos distribuídos. Os servidores web fornecem uma forma restrita de compartilhamento de dados, na qual os arquivos armazenados de forma local no servidor estão gerenciados e atualizados em sistemas de arquivo no servidor. Os sistemas de arquivos foram originalmente desenvolvidos para sistemas de computadores centralizados e computadores desktops. Os primeiros servidores de arquivos foram desenvolvidos por pesquisadores nos anos 70 e o Sun Network File System se tornou disponível no início dos anos 80. Um serviço de arquivos permite que os programas armazenem e acessem arquivos remotos exatamente como se fossem locais. 38

39 Sistemas de Arquivos distribuídos Introdução Sun NFS: foi amplamente adotado na indústria e nos ambientes acadêmicos, desde sua introdução em O projeto e desenvolvimento do NFS foram feitos pelo pessoal da Sun Microsystems em Para estimular sua adoção como padrão, as definições das principais interfaces foram colocadas em domínio público, permitindo que outros fornecedores produzissem implementações e o código fonte de um implementação de referência fosse disponibilizado. 39

40 Sistemas de Arquivos distribuídos Arquitetura do serviço de arquivos Client computer Server computer Application program Application program Directory service Flat file service Client module 40

41 Sistemas de Arquivos distribuídos Arquitetura do serviço de arquivos Serviço de arquivos plano: esse serviço de arquivo plano se preocupa com a implementação de operações sobre o conteúdo dos arquivos. São utilizados identificadores exclusivos de arquivos ( UFIDS unique file identifiers ). Serviço de diretório: esse serviço fornece um mapeamento entre os nomes textuais de arquivos e seus UFIDS. Módulo cliente: um módulo cliente é executado em cada computador cliente, integrando e estendendo as operações do serviço de arquivos plano e do serviço de diretório sob uma interface de clientes. 41

42 Sistemas de Arquivos distribuídos Estudo de caso: Sun Network File System Client computer Server computer UNIX system calls UNIX kernel Application program Application program Virtual file system UNIX kernel Virtual file system Local Remote UNIX file system Other file system NFS client NFS protocol NFS server UNIX file system 42

43 MÓDULO 5: Sistemas distribuídos baseados na Web. Introdução Serviços Web Descrições de serviço IDL para serviços Web Um serviço de diretório para uso com serviços web 43

44 Introdução Um serviço web ( web service ) fornece uma interface de serviço que permite aos clientes interagirem com servidores de uma maneira mais geral do que acontece com os navegadores web. Os clientes acessam as operações na interface de um serviço web por de meio de requisições e respostas formatadas em XML e normalmente transmitidas por HTTP. Os serviços web podem ser acessados de uma maneira ad hoc do que os serviços baseados em CORBA, permitindo que eles sejam mais facilmente usados em aplicações internet. Assim como no CORBA e em JAVA, as interfaces dos serviços web podem ser descritas em uma IDL. Mas para os serviços web, informações adicionais precisam ser descritas, incluindo a codificação e os protocolos de comunicação em uso e o local do serviço. Os usuários exigem uma maneira segura de criar, armazenar e modificar documentos e trocá-los na internet. Os canais TLS não fornecem todos os requisitos necessários. A segurança da XMLversão sedraft destina a suprir essa falta. 44

45 Grade (grid) é o nome usado para referenciar uma plataforma de middleware baseada em serviços web e projetada para uso por grandes grupos dispersos de usuários, com recursos maciços de dados que exige um processamento substancial. O World-Wide Telescope é uma aplicação típica de grade para colaboração científica na área da astronomia. As características da aplicações científicas com uso intenso de dados são derivadas de um estduo do World-Wide Telescope. Essas características levaram a um conjunto de requisitos para uma arquitetura de grade. 45

46 Infraestrutura e componentes dos serviços web Applications Directory servicesecurity Choreography Web Services Service descriptions (in WSDL) SOAP URIs (URLs or URNs) XML HTTP, SMTP or other transport 46

47 URI uniform resource identifier identificador de recurso geral, cujo valor pode ser um URL ou URN. URL inclui informações de localização do recurso, como nome de domínio do servidor de um recurso que está sendo nomeado. URN - uniform resource names são independentes da localização. Eles contam com um serviço de pesquisa para fazer o mapeamento para os URL dos recursos. SOAP especifica as regras de utilização da XML, para empacotar mensagens, por exemplo para suportar um protocolo de requisição de resposta. XML representação textual que embora mais volumosa do que outras representações foi adotada por sua legibilidade e pela consequente facilidade de depuração. WSDL - Web services description language 47

48 Serviços Web Geralmente uma interface de serviço web consiste em um conjunto de operações que podem ser usadas por um cliente na internet. As operações de um serviço web podem ser fornecidas por uma variedade de recursos diferentes, por exemplo programas, objetos ou bancos de dados. Um serviço web pode ser gerenciado por um servidor web, junto com páginas web, ou pode ser um serviço totalmente separado. A principal características da maioria dos serviços web é que podem processar mensagens SOAP formatadas em XML. Uma alternativa é a estratégia REST, que está descrita em linhas gerais a seguir. Cada serviço web usa sua própria descrição para tratar das características específicas das mensagens que recebe. Muitos servidores web comerciais, incluindo Amazon, Yahoo, Google e ebay, oferecem interfaces de serviço que permitem ao cliente manipular versão seus draftrecursos web. 48

49 Serviços Web O serviço web da Amazon permite aos clientes adicionar um item ao carrinho de compras ou verificar o status de uma transação. O serviços web da Amazon podem ser acessados por SOAP ou por REST. Isso permite que aplicações de outros fornecedores construam serviços com valor agregado sobre aqueles fornecidos pela Amazon. Por exemplo, uma aplicação de controle de inventário e aquisição poderia pedir o fornecimento de mercadorias da Amazon, à medida que elas fossem necessárias e controlar automaticamente a mudança de status de cada requisição. Mais de desenvolvedores se registraram para uso desses serviços web nos dois anos após eles serem introduzidos [ Greenfield e Dornan 2004 ]. Outro exemplo interessante de aplicação que exige a presença de um serviço web é a que implementa sniping em leilões da ebay. Sniping significa fazer um lance durante os últimos segundos antes que um leilão termine. 49

50 Embora os seres humanos possam realizar as mesmas ações, por meio de interação direta com a página web, eles não podem fazer com tanta rapidez. Para possibilitar o uso de uma variedade de padrões de comunicação, o protocolo SOAP é baseado no empacotamento de mensagens unidirecionais únicas. Ele suporta interações de requisições e resposta usando pares de mensagens únicas e especificando como vai representar as operações, seu argumentos e resultados. De acordo com Greenfield e Dornan [2004], 80% dos pedidos de serviços web no site Amazon são feitos por intermédio da interface REST e os 20% restantes utilizam o SOAP. 50

51 SOAP: O protocolo SOAP (simple object access protocol) é projetado para permitir tanto interação cliente servidor como assíncrona pela internet. Ele define um esquema para uso de XML para representar o conteúdo de mensagens de requisição e resposta, assim como um esquema para a comunicação de documentos. Originalmente o protocolo SOAP era baseado apenas em HTTP mas a versão atual é projetada para usar uma variedade de protocolos de transporte, incluindo SMTP, TCP ou UDP. A especificação do protocolo SOAP declara: -Como a XML deve se usada para representar o conteúdo de mensagens individuais - Como duas mensagens podem ser combinadas para produzir um padrão de requisição e resposta. - As regras sobre como os destinatários das mensagens devem processar os elementos XML que elas contêm. API s SOAP foram implementadas em muitas linguagens: JAVA, 51 JAVA script, Perl, Python.NET, C++, C# e Visual Basic.

52 O protocolo SOAP (simple object access protocol) 52

53 O protocolo SOAP (simple object access protocol) envelope header header element header element body body element body element 53

54 Estrutura do protocolo SOAP Envelope: Toda mensagem SOAP deve contê- lo. É o elemento raiz do documento XML. O Envelope pode conter declarações de namespaces e também atributos adicionais como o que define o estilo de codificação (encoding style).um "encoding style" define como os dados são representados no documento XML. Header: É um cabeçalho opcional. Ele carrega informações adicionais, como por exemplo, se a mensagem deve ser processada por um determinado nó intermediário (É importante lembrar que, ao trafegar pela rede, a mensagem normalmente passa por diversos pontos intermediários, até alcançar o destino final). Quando utilizado, o Header deve ser o primeiro elemento do Envelope. Body: Este elemento é obrigatório e contém o payload, ou a informação a ser transportada para o seu destino final. O elemento Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e erros retornadas pelos "nós" ao processarem a mensagem. Fault: contém as informações dos erros ocorridos no envio da 54 mensagem. Apenas nas mensagens de resposta do servidor.

55 De acordo com o W3Schools, a estrutura da mensagem SOAP é definida em um documento XML que contém os seguintes elementos: <SOAP-ENV:envelope> <! Elemento raiz do SOAP e define que essa é uma mensagem SOAP--> <SOAP-ENV:header> <! Especifica informações especificas como autenticação (opcional)--> </SOAP-ENV:header> <SOAP-ENV:body> <! O elemento BODY contém o corpo da mensagem--> <SOAP-ENV:fault> <! O elemento FAULT contém os erros que podem ocorrer--> </SOAP-ENV:fault> </SOAP-ENV:body> </SOAP-ENV:envelope> 55

56 Exemplo 1: SOAP POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Header> <t:transaction xmlns:t="some-uri" SOAP-ENV:mustUnderstand="1 >5 <t:transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:getlasttradeprice> xmlns:m="some-uri"> <symbol>dis</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 56

57 Exemplo 2: SOAP flight booking a flight booking b Client Travel Agent Service hire car booking a hotel booking a hotel booking b hire car booking b 57

58 Web Service Description Language (WSDL) Documento WSDL De que forma um cliente de um Web Service sabe qual formato dos métodos a serem chamados e quais parâmetros a serem passados? Como cliente e serviço sabem como processar uma requisição? Para solucionar estes tipos de perguntas foi criado um documento, que utiliza uma linguagem chamada WSDL. WSDL ou Web Service Description Language é uma linguagem baseada em XML, utilizada para descrever um Web Service. Um Web Service deve, portanto, definir todas as suas interfaces, operações, esquemas de codificação, entre outros neste documento. 58

59 REST (representational state transfer) É uma estratégia com um estilo de operação muito restrito, no qual os clientes usam URL s e as operações HTTP GET, PUT, DELETE e POST para manipular recursos representados em XML. A análise está na manipulação de recursos de dados em vez de interfaces. Os clientes recebem o estado inteiro de um recurso, em vez de chamar uma operação para fornecer alguma parte dele. Fielding acredita que, no contexto da internet, a proliferação de diferentes interfaces de serviço não será tão útil quanto um conjunto mínimo de operações simples e uniformes. Quando um novo recurso é criado, ele recebe um novo URL por meio do qual pode ser acessado ou atualizado. 59

60 Descrições de serviço IDL para serviços Web As definições de interface são necessárias para permitir que os clientes se comuniquem com os serviços. Para serviços web, as definições de interface são fornecidas como parte de uma descrição de serviço mais geral, que especifica duas outras características adicionais, como as mensagens devem ser comunicadas ( por exemplo, por SOAP com HTTP ) e o URI do serviço. Para fornecer serviço em ambiente com múltiplas linguagens, as descrições de serviço são escritas em XML. A descrição do serviço forma a base de um acordo entre um cliente e um servidor quanto ao serviço oferecido. Ela reúne todos os fatos pertinentes ao serviço que são relevantes para seu clientes. As descrições de serviço geralmente são usadas para gerar stubs de cliente que implementam automaticamente o comportamento correto para o cliente. O componente do tipo IDL de uma descrição de serviço é mais flexível do que as outras IDL s, pois um serviço pode ser especificado em termos dos tipos de mensagens que enviará e receberá, ou em termos das operações que suporta, para permitir a troca de documentos e interações estilo requisição e resposta. 60

61 Os principais elementos de uma descrição WSDL definitions types message interface bindings services target namespacedocument style request-reply style how where abstract concrete Interface: conjunto de operações pertencentes a um serviço web Bindings: escolha de protocolos Service: escolha do endereço de ponto final ou do servidor 61

62 Um serviço de diretório para uso com serviços web Existem muitas maneiras pelas quais os clientes podem obter descrições de serviço, por exemplo qualquer um que forneça um serviço web de mais alto nível, como o serviço de agente de viagens que quase que certamente faria uma página web anunciando o serviço e os clientes em potencial se deparariam com a página ao procurar serviços desse tipo. Entretanto, qualquer organização que pretenda basear suas aplicações em serviços web achará mais conveniente usar um serviço de diretório para tornar esses serviços disponíveis para os clientes. Esse é o objetivo do UDDI (Universal Directory and Discovery Service) [ Bellwod et al. 2003] que fornece um serviço de nome e um serviço de diretório. Serviço de diretório: um serviço que armazena conjuntos de vínculos entre nomes e atributos e que pesquisa entradas que correspondem a especificações baseada no atributo. Exemplo: Active Directory Services da Microsoft ou X.500 e se primo LDAP. Normalmente o serviço de diretório é chamado de serviços de páginas amarelas Serviço de nome: lista telefônica ou serviço de páginas brancas. 62

63 O Active Directory é uma implementação de serviço de diretório no protocolo LDAP que armazena informações sobre objetos em rede de computadores e disponibiliza essas informações a usuários e administradores desta rede. É um software da Microsoft utilizado em ambientes Windows. O Active Directory, surgiu da necessidade de se ter um único diretório, ou seja, ao invés do usuário ter uma senha para acessar o sistema principal da empresa, uma senha para ler seus s, uma senha para se logar no computador, e várias outras senhas, com a utilização do Active Directory, os usuários poderão ter apenas uma senha para acessar todos os recursos disponíveis na rede. Podemos definir um diretório como sendo um banco de dados que armazena as informações dos usuários. 63

64 O Active Directory surgiu juntamente com o Windows 2000 Server. Objetos como usuários, grupos, membros dos grupos, senhas, contas de computadores, relações de confiança, informações sobre o domínio, unidades organizacionais, etc, ficam armazenados no banco de dados do Active Directory. Além de armazenar vários objetos em seu banco de dados, o Active Directory disponibiliza vários serviços, como: autenticação dos usuários, replicação do seu banco de dados, pesquisa dos objetos disponíveis na rede, administração centralizada da segurança utilizando políticas de grupo, entre outros serviços. Esses recursos tornam a administração do Active Directory bem mais fácil, sendo possível administrar todos os recursos disponíveis na rede centralizadamente. 64

65 As descrições de serviço WSDL podem ser pesquisadas pelo nome ( um serviço de catálogo telefônico, ou serviço de nomes ) ou pelo atributo ( serviço de diretório ou serviço de páginas amarelas ). Elas podem ser acessadas diretamente por meio de seus URL s o que é conveniente para desenvolvedores que estejam projetando programas clientes que utilizam o serviço. As estruturas de dados que suportam UDDI são projetadas de forma a permitir todos os estilos de acesso anteriores e podem incorporar qualquer volume de informações legíveis para seres humanos. Os dados são organizados em quatro estruturas: BusinessEntity: descreve a organização que fornece esses serviços web, dando seu nome, endereço, atividades, etc... BusinessServices: armazena informações sobre um conjunto de instâncias de um seviço web, como seu nome e uma descrição de seu propósito; por exemplo, agente de viagens ou livraria. BindingTemplate: contém o endereço de uma instância de serviço web e referências para descrições do serviço tmodel: contém descrições de serviço, normalmente documentos WSDL, armazenadas fora do banco de dados e acessadas por meio de URL. 65

66 As principais estruturas de dados - UDDI businessentity businessservices human readable businessservices information businessservices about the publisher bindingtemplate human readable bindingtemplate information URL about a bindingtemplate family of services information about the URL service interfaces key URL key key tmodel tmodel tmodel service descriptions 66

67 QUESTÃO QUESTÃO - GRUPO 2 1 DEFINA UFID 2 CARACTERIZE SERVIÇO DE DIRETORIO E ARQUIVO DE CLIENTES. 3 EXPLIQUE SUCINTAMENTE SUN NETWORK FILE SYSTEM. 4 QUAL A FINALIDADE DO PROTOCOLO NFS. 5 DEFINA SUCINTAMENTE UM WEB SERVICE. 6 COMPARE O SERVIÇOS CORBA COM WEB SERVICE. 7 É POSSIVEL A UTILIZAÇÃO DE IDL PARA JAVA, CORBA E WEB SERVICE? 8 UMA DAS PRINCIPAIS PLATAFORMAS UTILIZADAS EM WEB SERVICE ESTA ESTRUTURADA EM GRANDE ESCALA. TRATA-SE DA ARQUITETURA GRID. DEFINA GRID. 9 DEFINA XML E OS PRINCIPAIS PROTOCOLOS DA CAMADA DE APLICAÇÃO. 10 QUAL O SIGNIFICADO SOAP. EXEMPLIFIQUE SUA UTILIZAÇÃO 11 QUAL A DIFERENÇA A DIFERENÇA ENTRE URI, URL E URN 12 DEFINA WSDL 13 FAÇA UM COMPARATIVO ENTRE SOAP E REST. 14 DEFINA SNIPING. QUAL A PRINCIPAL FINALIDADE DE UTILIZAÇÃO? 15 QUAIS SÃO AS PINCIPAIS LINGUAGENS QUE XML SUPORTA? 16 CARACTERIZE AS PRINCIPAIS ESTRUTURAS DO PROTOCOLO SOAP. ELABORE UM DESENHO REPRESENTATIVO DESSA ESTRUTURA 17 QUAIS SÃO OS PRINCIPAIS BLOCOS FUNCIONAIS DO XML DEFINIDOS PELO W3SCHOOL? 18 DEFINA OS PRINCIPAIS ELEMENTOS DE UMA DESCRIÇÃO WSDL 19 DEFINA O SERVIÇO UDDI. 20 O QUE É UM SERVIÇO DE DIRETORIO? EXEMPLIFIQUE E CARACTERIZE UM SERVIÇO DE PAGINAS AMARELAS NA WEB. 67

68 Prof. Marcelo de Sá Barbosa 68

69 MÓDULO 6: Sistemas distribuídos baseados em coordenação. Coordenação de serviços Web MÓDULO 7: Sistemas peer to peer 69

70 Coordenação de serviços Web A infraestrutura SOAP suporta interações requisiçãoresposta entre clientes e serviços web. Entretanto, muitas aplicações úteis envolvem várias requisições que precisam ser executadas em uma ordem em particular. Por exemplo, ao se fazer reservas para um vôo, são reunidas as informações sobre preço e disponibilidade, antes que as reservas sejam feitas. Quando o usuário interage com páginas web por intermédio de um navegador para fazer reserva em um vôo ou para dar um lance em um leilão, a interface fornecida pela navegador controla a sequência em que as operações são executadas. 70

71 Transações distribuidas planas e aninhadas Uma transação cliente se torna distribuida se ativa operações em vários servidores diferentes. Existem duas maneiras distintas pelas quais as transações distribuídas podem se estruturadas: como transações planas e transações aninhadas. Em um transação plana, um cliente faz pedidos para mais de um servidor. Em uma transação aninhada, a transação de nível superior pode abrir subtransações e assim sucessivamente em qualquer profundidade de aninhamento. 71

72 Transações distribuídas planas e aninhadas X T 11 M X T T Y Client T T 1 T 12 T 21 N Client Z T 2 Y P T 22 (a) Flat transaction (b) Nested transactions 72

73 Coordenação de uma transação distribuida Os servidores que executam pedidos como parte de uma transação distribuida precisam se comunicar uns com os outros para coordenar suas ações quando a transação é efetivada Client T T 1 X A a.withdraw(10) T = opentransaction Y opensubtransaction a.withdraw(10); opensubtransaction b.withdraw(20); opensubtransaction c.deposit(10); opensubtransaction d.deposit(20); closetransaction T 2 T 3 T 4 Z B C D b.withdraw(20) c. deposit(10) d.deposit(20) 73

74 Tem-se trabalhado em um modelo geral para a coordenação de serviços web, o qual é semelhante ao modelo de transação distribuida descrito anteriormente pois têm funções de coordenador e participante que são capazes de atuar em protocolos específicos, por exemplo, para executar uma transação distribuida. Esse trabalho, que é chamado WS-Coordination é descrito por Langworthy[2004]. Requisitos de coreografia: se destina a suportar interações entre serviços web que geralmente são gerenciadas por diferentes empresas e organizações. 74

75 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. 75

76 Modelos de Sistema - Arquitetura de sistema Peer 2 Peer 1 Application Application Sharable objects Peer 3 Application Peer 4 Application Peers 5... N 76