DESENVOLVIMENTO DE SISTEMAS DISTRIBUIDOS · MÓDULO 2: Modelos de Sistema; Cliente-Servidor; Java...

DESENVOLVIMENTO DE SISTEMAS DISTRIBUIDOS

1

Prof. Marcelo de Sá Barbosa

versão draft


2

data Comentários03/08/2011 Início do semestre.

10/08/2011

Entrega da ementa e comentários sobres os assuntos. Recomendação dabibliografia. Períodos de provas. Limite de faltas para aprovação. Revisão derede de computadores. MÓDULO 1: caracterização de sistemas distribuídos;internet; intranets; computação móvel e ubíqua; compartilhamento de recursose a web; serviços web

17/08/2011 MÓDULO 2: Modelos de Sistema; Cliente-Servidor; Java RMI; Corba; COM; DCOM. MÓDULO 3: Sistemas distribuídos baseados em objetos

24/08/2011 MÓDULO 4: Sistemas de Arquivos distribuídos. MÓDULO 5: Sistemas distribuídos baseados na Web; Exercicios de fixação

31/08/2011 MÓDULO 6: Sistemas distribuídos baseados em coordenação. Exercícios de 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ção05/10/2011 PROVA P1 - Turma Ciência da Computação

versão draft


3versão draft


�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

4versão draft


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.

5versão draft


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.


6versão draft


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.


7versão draft


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.


8versão draft


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

9versão draft


Modelos de Sistema

Camadas de Software

Applications, services

Computer and network hardware

Platform

Operating system

Middleware

10versão draft


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.

11versão draft


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

12versão draft


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.

13versão draft


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

14versão draft


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

15versão draft



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. 16versão draft



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

17versão draft



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.

18versão draft


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

19versão draft


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

20versão draft


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.

21versão draft


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ém-se reuso com DCOM através de inclusão e agregação ao invés de herança [ORF97].

22versão draft


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.

23versão draft


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.

24versão draft


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.

25versão draft


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.

Server

Client

Client

invocation

result

Serverinvocation

result

Process:Key:

Computer:

26versão draft


Modelos de SistemaModelos de Sistema - Arquitetura de sistema

Peer to PeerNessa 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.

27versão draft



Application

Application

Application

Peer 1

Peer 2

Peer 3

Peers 5 .... N

Sharableobjects

Application

Peer 4

28versão draft


Comunicação entre processos

Applications, services

Middlewarelayers

request-reply protocol

marshalling and external data representation

UDP and TCP

Thischapter

RMI and RPC

Serão estudadas caracteristicas da camada middleware.

29versão draft



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.

30versão draft



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.

31versão draft



Comunicação SíncronaComunicaçã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.

32versão draft


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.

33versão draft


QUESTÃO QUESTÃO – GRUPO 11 DEFINA SISTEMAS DISTRIBUIDOS2 QUAIS SÃO OS PRINCIPAIS DESAFIOS NA CONSTRUÇÃO DE SISTEMAS DISTRIBUIDOS?3 QUAIS SÃO AS CAMADAS DO MODELO DE SOFTWARE?4 DEFINA PLATAFORMA5 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?

10 EXPLIQUE O FUNCIONAMENTO DAS ARQUITETURAS CLIENTE SERVIDOR E PEER TO PEER, UTILIZANDO O CONCEITO DE PROCESSO.

11 O QUE É COMPUTAÇÃO MÓVEL E UBIQUA?

12 FAÇA UM RESUMO SOBRE A ORIGEM DA INTERNET UTILIZANDO OS CONCEITOS DE SISTEMAS DISTRIBUIDOS

13 EXPLIQUE TRÊS DIFERENÇAS FUNDAMENTAIS ENTRE INTERNET E INTRANET COM RELAÇÃO A ENDEREÇAMENTO IP E ROTEAMENTO.

14 ELABORE UM RESUMO SOBRE OS PRINCIPAIS SISTEMAS OPERACIONAIS UTILIZADOS EM EQUIPAMENTOS CELULARES INTELIGENTES, POR EXEMPLO SMARTPHONES

15

NO MÊS DE AGOSTO DE 2011 FOI DIVULGADA A FUSÃO ENTRE UMA DAS PRINCIPAIS EMPRESAS DESENVOLVEDORAS DE SISTEMA OPERACIONAL PARA SMARTPHONES E UMA EMPRESA FABRICANTE DE APARELHOS CELULARES. QUAIS SÃO ESSAS EMPRESAS? DESCREVA OS SISTEMAS OPERACIONAIS ENVOLVIDOS.

16 ENTREGA DE PESQUISA SOBRE QUAIS SÃO AS 5 PRINCIPAIS ESTRUTURAS DE UMA SISTEMA OPERACIONAL. ATIVIDADE ESCRITA DE PRÓPRIO PUNHO PELO ALUNO.

17 QUAL A PRINCIPAL MOTIVAÇÃO PARA CONSTRUÇÃO DE UM SISTEMA DISTRIBUIDO?

34versão draft



35versão draft


�MÓDULO 4: �Sistemas de Arquivos distribuídos.

�MÓDULO 5: �Sistemas distribuídos baseados na Web;

36versão draft


�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

37versão draft


Sistemas de Arquivos distribuídos

• Introdução

O compartilhamento de informações armazenadas talvez seja oaspecto mais importante dos recursos distribuídos. Os servidoresweb fornecem uma forma restrita de compartilhamento de dados,na qual os arquivos armazenados de forma local no servidor estãogerenciados 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.

38versão draft



•• Introdução

Sun NFS: foi amplamente adotado na indústria e nos ambientesacadêmicos, desde sua introdução em 1985. O projeto edesenvolvimento do NFS foram feitos pelo pessoal da SunMicrosystems em 1984. Para estimular sua adoção como padrão,as definições das principais interfaces foram colocadas emdomínio público, permitindo que outros fornecedores produzissemimplementações e o código fonte de um implementação dereferência fosse disponibilizado.

39versão draft



• Arquitetura do serviço de arquivos

Client computer Server computer

Applicationprogram

Applicationprogram

Client module

Flat file service

Directory service

40versão draft



• Arquitetura do serviço de arquivos

Serviço de arquivos plano: esse serviço de arquivo plano sepreocupa com a implementação de operações sobre o conteúdodos arquivos. São utilizados identificadores exclusivos dearquivos ( 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.

41versão draft



• Estudo de caso: Sun Network File System

UNIX kernel

protocol

Client computer Server computer

system calls

Local Remote

UNIXfile

system

NFSclient

NFSserver

UNIXfile

system

Applicationprogram

Applicationprogram

NFS

UNIX

UNIX kernel

Virtual file systemVirtual file system

Oth

erfil

e sy

stem

42versão draft


�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

43versão draft


IntroduçãoUm serviço web ( web service ) fornece uma interface de serviçoque permite aos clientes interagirem com servidores de umamaneira mais geral do que acontece com os navegadores web.Os clientes acessam as operações na interface de um serviço webpor de meio de requisições e respostas formatadas em XML enormalmente transmitidas por HTTP. Os serviços web podem seracessados de uma maneira ad hoc do que os serviços baseadosem CORBA, permitindo que eles sejam mais facilmente usados emaplicações internet.Assim como no CORBA e em JAVA, as interfaces dos serviços webpodem ser descritas em uma IDL. Mas para os serviços web,informações adicionais precisam ser descritas, incluindo acodificação e os protocolos de comunicação em uso e o local doserviço. Os usuários exigem uma maneira segura de criar,armazenar e modificar documentos e trocá-los na internet. Oscanais TLS não fornecem todos os requisitos necessários. Asegurança da XML se destina a suprir essa falta. 44versão draft


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

45versão draft


Security

Service descriptions (in WSDL)

Applications

Directory service

Web Services

XML

Choreography

SOAP

URIs (URLs or URNs) HTTP, SMTP or other transport

Infraestrutura e componentes dos serviços web

46versão draft


URI – uniform resource identifier – identificador de recurso geral, cujovalor pode ser um URL ou URN.

URL – inclui informações de localização do recurso, como nome dedomínio do servidor de um recurso que está sendo nomeado.

URN - uniform resource names – são independentes da localização. Elescontam com um serviço de pesquisa para fazer o mapeamento para osURL dos recursos.

SOAP – especifica as regras de utilização da XML, para empacotarmensagens, por exemplo para suportar um protocolo de requisição deresposta.

XML – representação textual que embora mais volumosa do que outrasrepresentações foi adotada por sua legibilidade e pela consequentefacilidade de depuração.

WSDL - Web services description language47versão draft


Serviços Web

Geralmente uma interface de serviço web consiste em umconjunto de operações que podem ser usadas por um cliente nainternet. As operações de um serviço web podem ser fornecidaspor uma variedade de recursos diferentes, por exemploprogramas, objetos ou bancos de dados. Um serviço web podeser gerenciado por um servidor web, junto com páginas web, oupode ser um serviço totalmente separado.A principal características da maioria dos serviços web é quepodem processar mensagens SOAP formatadas em XML. Umaalternativa é a estratégia REST, que está descrita em linhasgerais a seguir. Cada serviço web usa sua própria descriçãopara tratar das características específicas das mensagens querecebe.Muitos servidores web comerciais, incluindo Amazon, Yahoo,Google e eBay, oferecem interfaces de serviço que permitem aocliente manipular seus recursos web. 48versão draft


O serviço web da Amazon permite aos clientes adicionar umitem ao carrinho de compras ou verificar o status de umatransação. O serviços web da Amazon podem ser acessados porSOAP ou por REST. Isso permite que aplicações de outrosfornecedores construam serviços com valor agregado sobreaqueles fornecidos pela Amazon. Por exemplo, uma aplicaçãode controle de inventário e aquisição poderia pedir ofornecimento de mercadorias da Amazon, à medida que elasfossem necessárias e controlar automaticamente a mudança destatus de cada requisição. Mais de 50.000 desenvolvedores seregistraram para uso desses serviços web nos dois anos apóseles serem introduzidos [ Greenfield e Dornan 2004 ].Outro exemplo interessante de aplicação que exige a presençade um serviço web é a que implementa sniping em leilões daeBay. Sniping significa fazer um lance durante os últimossegundos antes que um leilão termine.

Serviços Web

49versão draft


Embora os seres humanos possam realizar as mesmas ações,por meio de interação direta com a página web, eles não podemfazer com tanta rapidez.Para possibilitar o uso de uma variedade de padrões decomunicação, o protocolo SOAP é baseado no empacotamentode mensagens unidirecionais únicas. Ele suporta interações derequisições e resposta usando pares de mensagens únicas eespecificando como vai representar as operações, seuargumentos e resultados.De acordo com Greenfield e Dornan [2004], 80% dos pedidos deserviços web no site Amazon são feitos por intermédio dainterface REST e os 20% restantes utilizam o SOAP.

50versão draft


SOAP:O protocolo SOAP (simple object access protocol) é projetadopara permitir tanto interação cliente servidor como assíncronapela internet. Ele define um esquema para uso de XML pararepresentar 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 HTTPmas a versão atual é projetada para usar uma variedade deprotocolos 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 demensagens individuais- Como duas mensagens podem ser combinadas para produzirum padrão de requisição e resposta.- As regras sobre como os destinatários das mensagens devemprocessar os elementos XML que elas contêm.API’s SOAP foram implementadas em muitas linguagens: JAVA,JAVA script, Perl, Python.NET, C++, C# e Visual Basic. 51versão draft


O protocolo SOAP (simple object access protocol)

52versão draft


envelope

header

body

header element

body element

header element

body element

O protocolo SOAP (simple object access protocol)

53versão draft


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 mensagem. Apenas nas mensagens de resposta do servidor. 54versão draft


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

De acordo com o W3Schools, a estrutura da mensagem SOAP édefinida em um documento XML que contém os seguinteselementos:

55versão draft


POST /StockQuote HTTP/1.1Host: www.stockquoteserver.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "Some-URI"<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Header><t:Transactionxmlns: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>

Exemplo 1: SOAP

56versão draft


hotel bookinga

Travel Agent

flight bookinga

hire car bookingaService

Client

flight bookingb

hotel bookingbhire car bookingb

Exemplo 2: SOAP

57versão draft


Web Service Description Language (WSDL)

Documento WSDLDe que forma um cliente de um Web Service sabe qualformato dos métodos a serem chamados e quaisparâmetros a serem passados? Como cliente e serviçosabem como processar uma requisição?Para solucionar estes tipos de perguntas foi criado umdocumento, que utiliza uma linguagem chamada WSDL.WSDL ou Web Service Description Language é umalinguagem baseada em XML, utilizada para descrever umWeb Service. Um Web Service deve, portanto, definir todasas suas interfaces, operações, esquemas de codificação,entre outros neste documento.

58versão draft


REST (representational state transfer)

É uma estratégia com um estilo de operação muito restrito, noqual os clientes usam URL’s e as operações HTTP GET, PUT,DELETE e POST para manipular recursos representados emXML. A análise está na manipulação de recursos de dados emvez de interfaces. Os clientes recebem o estado inteiro de umrecurso, em vez de chamar uma operação para fornecer algumaparte dele. Fielding acredita que, no contexto da internet, aproliferação de diferentes interfaces de serviço não será tão útilquanto um conjunto mínimo de operações simples e uniformes.Quando um novo recurso é criado, ele recebe um novo URL pormeio do qual pode ser acessado ou atualizado.

59versão draft


Descrições de serviço IDL para serviços Web

As definições de interface são necessárias para permitir que os clientesse comuniquem com os serviços. Para serviços web, as definições deinterface são fornecidas como parte de uma descrição de serviço maisgeral, que especifica duas outras características adicionais, como asmensagens devem ser comunicadas ( por exemplo, por SOAP comHTTP ) e o URI do serviço. Para fornecer serviço em ambiente commú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 eum servidor quanto ao serviço oferecido. Ela reúne todos os fatospertinentes ao serviço que são relevantes para seu clientes. Asdescrições de serviço geralmente são usadas para gerar stubs decliente que implementam automaticamente o comportamento corretopara o cliente.O componente do tipo IDL de uma descrição de serviço é mais flexíveldo que as outras IDL’s, pois um serviço pode ser especificado emtermos dos tipos de mensagens que enviará e receberá, ou em termosdas operações que suporta, para permitir a troca de documentos einterações estilo requisição e resposta. 60versão draft


abstract concrete

how where

definitions

types

target namespace

interface bindings servicesmessage

document stylerequest-reply style

Os principais elementos de uma descrição WSDL

Interface: conjunto de operações pertencentes a um serviço webBindings: escolha de protocolosService: escolha do endereço de ponto final ou do servidor

61versão draft


Um serviço de diretório para uso com serviços webExistem muitas maneiras pelas quais os clientes podem obterdescrições de serviço, por exemplo qualquer um que forneça umserviço web de mais alto nível, como o serviço de agente de viagensque quase que certamente faria uma página web anunciando o serviçoe os clientes em potencial se deparariam com a página ao procurarserviços desse tipo.Entretanto, qualquer organização que pretenda basear suas aplicaçõesem serviços web achará mais conveniente usar um serviço de diretóriopara tornar esses serviços disponíveis para os clientes. Esse é oobjetivo do UDDI (Universal Directory and Discovery Service) [Bellwod et al. 2003] que fornece um serviço de nome e um serviço dediretório.Serviço de diretório: um serviço que armazena conjuntos devínculos entre nomes e atributos e que pesquisa entradas quecorrespondem 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 depáginas amarelasServiço de nome: lista telefônica ou serviço de páginas brancas.

62versão draft


O Active Directory é uma implementação de serviço de diretório noprotocolo LDAP que armazena informações sobre objetos em rede decomputadores e disponibiliza essas informações a usuários eadministradores desta rede. É um software da Microsoft utilizado emambientes 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 sistemaprincipal da empresa, uma senha para ler seus e-mails, uma senhapara se logar no computador, e várias outras senhas, com a utilizaçãodo Active Directory, os usuários poderão ter apenas uma senha paraacessar todos os recursos disponíveis na rede. Podemos definir umdiretório como sendo um banco de dados que armazena asinformações dos usuários.

63versão draft


O Active Directory surgiu juntamente com o Windows 2000 Server.Objetos como usuários, grupos, membros dos grupos, senhas, contasde computadores, relações de confiança, informações sobre o domínio,unidades organizacionais, etc, ficam armazenados no banco de dadosdo Active Directory. Além de armazenar vários objetos em seu banco dedados, 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 centralizadada segurança utilizando políticas de grupo, entre outros serviços. Essesrecursos tornam a administração do Active Directory bem mais fácil,sendo possível administrar todos os recursos disponíveis na redecentralizadamente.

64versão draft


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 peloatributo ( serviço de diretório ou serviço de páginas amarelas ). Elaspodem ser acessadas diretamente por meio de seus URL’s o que éconveniente para desenvolvedores que estejam projetando programasclientes que utilizam o serviço.As estruturas de dados que suportam UDDI são projetadas de formaa permitir todos os estilos de acesso anteriores e podem incorporarqualquer 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çosweb, dando seu nome, endereço, atividades, etc...BusinessServices: armazena informações sobre um conjunto deinstâncias de um seviço web, como seu nome e uma descrição de seupropósito; por exemplo, agente de viagens ou livraria.BindingTemplate: contém o endereço de uma instância de serviçoweb e referências para descrições do serviçotModel: contém descrições de serviço, normalmente documentosWSDL, armazenadas fora do banco de dados e acessadas por meio deURL. 65versão draft


tModel

businessServices

tModel

businessEntity

information

about the publisher

tModel

businessServiceshuman readable

service descriptions key key

URL

URL

URL

businessServices

information about a family of services

human readable

service interfaces

bindingTemplate

bindingTemplate

bindingTemplateinformation about the

key

service interfaces

As principais estruturas de dados - UDDI

66versão draft


QUESTÃO QUESTÃO - GRUPO 21 DEFINA UFID2 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ÇÃO11 QUAL A DIFERENÇA A DIFERENÇA ENTRE URI, URL E URN12 DEFINA WSDL13 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 WSDL19 DEFINA O SERVIÇO UDDI.

20 O QUE É UM SERVIÇO DE DIRETORIO? EXEMPLIFIQUE E CARACTERIZE UM SERVIÇO DE PAGINAS AMARELAS NA WEB.

67versão draft



68versão draft


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

�MÓDULO 7: �Sistemas peer to peer

69versão draft


Coordenação de serviços Web

A infraestrutura SOAP suporta interações requisição-resposta 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.

70versão draft


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.

71versão draft


(a) Flat transaction (b) Nested transactions

Client

X

Y

Z

X

Y

M

NT1

T2

T11

Client

P

T

T12

T21

T22

T

T

Transações distribuídas planas e aninhadas

72versão draft


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

Coordenação de uma transação distribuida

a.withdraw(10)

c.deposit(10)

b.withdraw(20)

d.deposit(20)

Client A

B

C

T1

T2

T3

T4

T

D

X

Y

Z

T = openTransaction

openSubTransactiona.withdraw(10);

closeTransaction

openSubTransactionb.withdraw(20);

openSubTransactionc.deposit(10);

openSubTransactiond.deposit(20);

73versão draft


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.

74versão draft


Modelos de SistemaModelos de Sistema - Arquitetura de sistema

Peer to PeerNessa 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.

75versão draft



Application

Application

Application

Peer 1

Peer 2

Peer 3

Peers 5 .... N

Sharableobjects

Application

Peer 4

76versão draft

DESENVOLVIMENTO DE SISTEMAS DISTRIBUIDOS · MÓDULO 2: Modelos de Sistema; Cliente-Servidor; Java...

Documents

Transcript of DESENVOLVIMENTO DE SISTEMAS DISTRIBUIDOS · MÓDULO 2: Modelos de Sistema; Cliente-Servidor; Java...