DSD 1bim

DESENVOLVIMENTO DE SISTEMAS DISTRIBUIDOS
Prof. Marcelo de Sá Barbosa
versão draft 1
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
versão draft 2
versão draft 3
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
versão draft 4
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.
versão draft 5

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. versão draft 6
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.
versão draft 7
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.
versão draft 8
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.
versão draft 9
Modelos de Sistema
Camadas de Software
Applications, services
Middleware
Operating system
Platform
Computer and network hardware
versão draft 10
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.
versão draft 11
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
versão draft 12
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.
versão draft 13
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).
versão draft 14
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).
versão draft 15

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

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].
versão draft 17
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.
versão draft 18
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).
versão draft 19
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].
versão draft 20
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.
versão draft 21
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].
versão draft 22
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.
versão draft 23
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.
versão draft 24
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.
versão draft 25
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 Server

invocation
result result
Server
Client
Key:
Process: Computer:
versão draft 26

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

Peer 2
Peer 1
Application
Application
Sharable Peer 3
objects
Application
Peer 4
Application
Peers 5 .... N
versão draft 28
Comunicação entre processos

Serão estudadas caracteristicas da camada middleware.
Applications, services
RMI and RPC
request-reply protocol Middleware

This
layers
chapter
marshalling and external data representation
UDP and TCP
versão draft 29
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.
versão draft 30
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.
versão draft 31
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.
versão draft 32
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.
versão draft 33
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?
versão draft 34
versão draft 35
MÓDULO 4:
Sistemas de Arquivos distribuídos.
MÓDULO 5:
Sistemas distribuídos baseados na Web;
versão draft 36
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
versão draft 37
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.
versão draft 38

• Introdução
Sun NFS: foi amplamente adotado na indústria e nos ambientes
acadêmicos, desde sua introdução em 1985. O projeto e
desenvolvimento do NFS foram feitos pelo pessoal da Sun
Microsystems em 1984. 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.
versão draft 39

• Arquitetura do serviço de arquivos
Client computer Server computer
Application Application Directory service

program program
Flat file service
Client module
versão draft 40

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

• Estudo de caso: Sun Network File System
Client computer Server computer
Application Application
program program
UNIX
system calls
UNIX kernel
UNIX kernel Virtual file system Virtual file system
Local Remote
file system
UNIX NFS NFS UNIX

file file
Other
client server
system system
NFS
protocol
versão draft 42
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
versão draft 43
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
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.
versão draft 45
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
versão draft 46
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

versão draft 47
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
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 50.000 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
versão um
draft leilão termine. 49
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.
versão draft 50
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,
JAVA script, Perl, Python.NET,
versão draft
C++, C# e Visual Basic. 51
O protocolo SOAP (simple object access protocol)
versão draft 52
O protocolo SOAP (simple object access protocol)
envelope
header
header element header element
body
body element body element
versão draft 53
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 versão
nasdraft
mensagens de resposta do servidor. 54
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>
versão draft 55
Exemplo 1: SOAP
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<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> versão draft 56
Exemplo 2: SOAP
flight bookinga
flight bookingb
Travel Agent
Client
Service hire car booking
a
hire car booking

b
hotel booking
a hotel booking
b
versão draft 57
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.
versão draft 58
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.
versão draft 59
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
versão draft e resposta. 60
Os principais elementos de uma descrição WSDL
definitions
interface bindings services

types message
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
versão draft 61
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
versão draft 62
Serviço de nome: lista telefônica ou serviço de páginas brancas.
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 e-mails, 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.
versão draft 63
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.
versão draft 64
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. versão draft 65
As principais estruturas de dados - UDDI
businessEntity businessServices
human readable businessServices
information
businessServices bindingTemplate
about the publisher
human readable
bindingTemplate
information URL
about a bindingTemplate tModel
family of services information tModel
about the
URL
serviceinterfaces
service interfaces
tModel
key URL
key service descriptions
key
versão draft 66
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?
UMA DAS PRINCIPAIS PLATAFORMAS UTILIZADAS EM WEB SERVICE ESTA
8
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?
CARACTERIZE AS PRINCIPAIS ESTRUTURAS DO PROTOCOLO SOAP. ELABORE UM
16
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.
O QUE É UM SERVIÇO DE DIRETORIO? EXEMPLIFIQUE E CARACTERIZE UM SERVIÇO DE
20
PAGINAS AMARELAS NA WEB.
versão draft 67
versão draft 68
MÓDULO 6:
Sistemas distribuídos baseados em coordenação.
Coordenação de serviços Web
MÓDULO 7:
Sistemas peer to peer
versão draft 69
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.
versão draft 70
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.
versão draft 71
Transações distribuídas planas e aninhadas
M
X
T11
X
Client T1 N
T T 12
Y
T
T
T
21
T2
Client
Y
P
Z
T
22
(a) Flat transaction (b) Nested transactions

versão draft 72
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
X
Client T1 A a.withdraw(10)
T
T = openTransaction Y
openSubTransaction T B b.withdraw(20)
2
a.withdraw(10);
openSubTransaction
b.withdraw(20); Z
openSubTransaction
c.deposit(10); T3 C c.deposit(10)
openSubTransaction
d.deposit(20); T4 D d.deposit(20)
closeTransactionversão draft 73
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.
versão draft 74

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

Peer 2
Peer 1
Application
Application
Sharable Peer 3
objects
Application
Peer 4
Application
Peers 5 .... N
versão draft 76

DSD 1bim

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

DSD 1bim

Enviado por

Direitos autorais:

Formatos disponíveis

DESENVOLVIMENTO DE SISTEMAS DISTRIBUIDOS

Prof. Marcelo de Sá Barbosa

Caracterização de Sistemas Distribuídos:

Caracterização de Sistemas Distribuídos:

Caracterização de Sistemas Distribuídos:

Escalabilidade: um sistema distribuído é considerado escalável se o

Caracterização de Sistemas Distribuídos:

Concorrência: a presença de múltiplos usuários em um sistema

Transparência: o objetivo é tornar certos aspectos da distribuição

Um modelo de arquitetura de um sistema distribuído envolve o

Computer and network hardware

O termo middleware se aplica a uma camada de software que

CORBA ( Common Object Request Broker Architecture ).

CORBA ( Common Object Request Broker Architecture ):

Tecnologia padrão de objetos e sistemas distribuidos, definido

Serviços CORBA são descritos através de uma linguagem

JAVA RMI ( Remote Method Invocation ):

O Remote Method Invocation (RMI) fornece um modelo simples

RMI é orientado a objetos em todos os níveis, mensagens são

JAVA RMI ( Remote Method Invocation ).

JAVA RMI ( Remote Method Invocation ).

JAVA RMI ( Remote Method Invocation ).

Clientes que conhecem um determinado serviço podem consultar

O Distribuited Component Object Model – DCOM é o modelo de

Um servidor DCOM é uma camada de código que é capaz de

O tipo de comunicação em DCOM é do tipo cliente/servidor. Na

Apesar de CORBA e DCOM possuírem algumas semelhanças

A princípio toda plataforma que utilize a arquitetura de software

COM suporta chamadas estáticas e dinâmicas de objetos, e é

O mecanismo de criação de objetos DCOM é o mesmo das

A partir do nome do servidor e identificador de classe(CLSID), parte

Modelos de Sistema - Arquitetura de sistema

Client invocation Server

Modelos de Sistema - Arquitetura de sistema

Modelos de Sistema - Arquitetura de sistema

Comunicação entre processos

RMI and RPC

request-reply protocol Middleware

UDP and TCP

Comunicação entre processos

No modelo OSI a camada de transporte trata basicamente dos

Comunicação entre processos

Comunicação entre processos

Comunicação por fluxo TCP:

Emprego do TCP: Muitos serviços frequentemente usados são

Prof. Marcelo de Sá Barbosa

Sistemas de Arquivos distribuídos.

Sistemas de Arquivos distribuídos

Sistemas de Arquivos distribuídos

Sistemas de Arquivos distribuídos

Client computer Server computer

Application Application Directory service

Flat file service

Sistemas de Arquivos distribuídos

Sistemas de Arquivos distribuídos

UNIX NFS NFS UNIX

Grade (grid) é o nome usado para referenciar uma plataforma de

Infraestrutura e componentes dos serviços web

Web Services Service descriptions (in WSDL)

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

URL – inclui informações de localização do recurso, como nome de

URN - uniform resource names – são independentes da localização. Eles

SOAP – especifica as regras de utilização da XML, para empacotar