765084_SO_CPT_s114

Prévia do material em texto

1 
UD II: COMUNICAÇÃO ENTRE PROCESSOS E THREADS 
Referências: 
• FSO1ed : Fundamentos de Sistemas Operacionais, 1ª. ed. , 
Silberschatz, Galvin, Gagne, LTC, 2013. 
• SOMTB3ed (TANENBAUM, A. S. , Sistemas Operacionais Modernos. 
3a. ed. São Paulo: Pearson Prentice Hall, 2010): caps 1, 2, 6, 10 e 11 
• SOJ7ed (SILBERSCHATZ, Abraham; GALVIN, Peter B.; GAGNE. 
Sistemas Operacionais com Java, 7a. ed., Rio de Janeiro: Campus. 
2008): cap 6 e 7 
• ASOM4ed (MACHADO, F.B., Arquitetura de Sistemas Operacionais, 
4ªed., LTC , Rio de Janeiro, 2007): caps 5 e 7 
• SOD3ed (DEITEL, H.M., Sistemas Operacionais, 3ª. ed., SP: Pearson/ 
Prentice Hall, 2005) cap 4, 5 e 6 
• Programação Multithread em Java, Sistemas Distribuídos, Marco Túlio de 
Oliveira Valente, ©MTOV(2006). 
 
2 
Sumário 
• Introdução 
• Memória compartilhada 
• Sinais 
• Pipes 
• Troca de mensagens 
• Soquetes (sockets) 
• Remote and Local Procedure Calls 
• Middlewares 
– RPC, RMI, Web Services, etc. 
3 
Memória compartilhada (Fig 3.13 FSO1ed) 
(a) Troca de mensagens (b) Memória compartilhada 
4 
Memória compartilhada (SOD3ed) 
• Vantagens 
• Melhora o desempenho de processos que acessam freqüentemente 
dados compartilhados. 
• Os processos podem compartilhar a mesma quantidade de dados 
que podem endereçar. 
• Interface padronizada 
• Memória compartilhada System V 
• Memória compartilhada POSIX 
• Não permite que os processos mudem privilégios de um segmento 
de memória compartilhada. 
 
5 
POSIX shared memory 
segment id = shmget(IPC PRIVATE, 
size, S IRUSR | S IWUSR); 
 
shared memory = (char *) shmat(id, 
NULL, 0); 
 
sprintf(shared memory, "Writing to 
shared memory"); 
 
shmdt(shared memory); 
6 
Memória compartilhada: System V 
7 
Implementação de memória compartilhada 
• Trata a região da memória compartilhada como um arquivo. 
 
• As molduras de página de memória compartilhada são liberadas 
quando o arquivo é apagado. 
 
• O tmpfs (sistema de arquivo temporário) armazena esses arquivos. 
 
• As páginas do tmpfs podem ser trocadas. 
 
• É possível definir as permissões. 
 
• O sistema de arquivo não exige formatação. 
 
8 
Memória compartilhada: Windows (SOD3ed) 
 
• Mapeamento-de-arquivo 
• Processa o mapeamento de sua memória virtual para as 
mesmas estruturas de página na memória física. 
• Vários processos acessam o mesmo arquivo. 
• Não há garantia de sincronização. 
• Objeto mapeamento-de-arquivo 
• Mapeia um arquivo para memória principal. 
• Visualização de arquivo 
• Mapeia a memória virtual de um processo para a memória 
principal mapeada pelo objeto mapeamento-de-arquivo. 
9 
Uso de sinais (Fig 5.17 ASOM4ed) 
[ctrl-C]
Processo
interrupção sinal
Sistema Operacional
10 
Sinais, interrupções e exceções (Fig 5.18 ASOM4ed) 
Hardware
Sistema Operacional
Interrupções
Exceções
Sinais
Processo Processo
11 
Sinais 
 
São usados para notificar a ocorrência 
de certos eventos, tais como: resposta a 
interrupções e exceções (p. ex. a 
execução de uma instrução inválida), 
quando um processo encerra outro, etc. 
 
 
 
12 
Tratamento de Sinais (FSO1ed) 
 
• Um manipulador de sinal é usado tratar do sinal. 
1. Um sinal é gerado por um evento específico. 
2. O sinal gerado é distribuído para um processo. 
3. O sinal é tratado. 
• Geralmente, existem as seguintes opções: 
– Enviar o sinal para o thread ao qual o sinal é aplicado. 
– Enviar o sinal para cada thread do processo. 
– Enviar o sinal para certos threads do processo. 
– Atribui um thread específico para receber todos os sinais para o 
processo. 
 
13 
Sinais (SOD3ed) 
 
• Um processo/thread pode tratar um sinal: 
 
1. Ignorar (processos podem ignorar todos, exceto os sinais SIGSTOP 
e SIGKILL). 
2. Capturar (chama um tratador para responder ao sinal). 
3. Executar a ação default que o núcleo define para esse sinal. 
 
• Ações default: 
• Abortar: terminar imediatamente. 
• Descarga de memória: copia o contexto de execução antes de sair. 
• Ignorar. 
• Parar (isto é, suspender). 
• Continuar (isto é, retomar). 
14 
Bloqueio de sinal (SOD3ed) 
• Um processo ou thread pode bloquear um sinal. 
• O sinal não é entregue até que o processo/thread pare de bloqueá-lo. 
 
• Enquanto o tratador de sinal estiver em execução, os sinais desse tipo 
são bloqueados por default. 
• Ainda é possível receber sinais de um tipo diferente. 
 
• Os sinais comuns não são enfileirados. 
• Os sinais de tempo real podem ser enfileirados. 
15 
Sinais POSIX (Tab 10.2 SOMTB3ed) 
16 
Sinais POSIX (SODed) 
17 
Comunicação de Processos: pipes 
• Pipe: pseudo-arquivo usado para conectar dois processos. 
• O processo A envia dados ao processo B escrevendo no pipe 
como se este fosse um arquivo de saída. 
• O processo B lê os dados tratando o pipe como um arquivo de 
entrada. 
18 
Comunicação de Processos: Pipes 
entrada do
Processo A
saída do
Processo B
saída do
Processo A
entrada do
Processo B
Processo A Processo B
19 
pipe: exemplo 
 
ls -la | wc –l 
 
• Shell cria (fork) dois processos. 
• No primeiro processo carrega (exec) o código do programa externo: 
 ls –la 
• No segundo processo carrega (exec) o código do programa externo 
 wc –l 
• Shell cria um pipe para conectar os processos e espera (wait) eles 
terminarem. 
 
• Quando os dois processos terminam (exit), o shell volta a executar. 
 
 
20 
UNIX pipes (SOD3ed) 
• O processo produtor escreve dados para o pipe. Depois disso, o 
processo consumidor lê dados do pipe na ordem “primeiro a 
entrar, primeiro a sair”. 
• Quando um pipe é criado, um inode que aponta para o buffer do 
pipe (página de dados) é criado. 
• O acesso ao pipe é controlado por descritores de arquivo. 
• Podem ser passados entre processos relacionados (por exemplo, 
pai e filho). 
• Pipes nomeados (FIFOs). 
• Podem ser acessados por meio da árvore de diretório. 
• Limitação: buffer de tamanho fixo. 
 
21 
Comunicação interprocessos: Windows 
• Dados orientados 
• Pipes 
• Mailslots (filas de mensagens) 
• Memória compartilhada 
• Procedimento orientado/objeto orientado 
• Chamadas remotas de procedimento 
• Objetos do Modelo de Objeto Componente da Microsoft 
• Área de transferência 
• Recurso de arrastar-e-soltar da GUI 
22 
Windows pipes (SOD3ed) 
• Manipuladas com chamadas ao sistema de arquivo: 
• Ler 
• Escrever 
• Abrir 
• Servidor de pipe 
• Processo que cria o pipe. 
• Clientes de pipe 
• Processos que se conectam ao pipe. 
• Modos 
• Leitura: o servidor de pipe recebe dados dos clientes de pipe. 
• Escrita: o servidor de pipe envia dados aos clientes de pipe. 
• Dúplex: o servidor de pipe envia e recebe dados. 
23 
Windows pipes (SOD3ed) 
• Pipes anônimos 
• Usados para comunicação unidirecional. 
• Entre processos locais. 
• Síncronos. 
• Os manipuladores de pipe em geral são passados por 
herança. 
• Pipes com nomes 
• Comunicação unidirecional ou bidirecional. 
• Entre processos locais e remotos. 
• Síncronos ou assíncronos. 
• Abertos por nome. 
• Fluxo de bytes versus fluxo de mensagens. 
• Modo default versus modo de escrita direta. 
24 
Soquetes (sockets): Redes 
• Permite a conexão entre processos situados em máquinas diferentes 
conectadas através de uma rede de computadores . 
• É uma “ponta” (endpoint) de um canal de comunicação bidirecional 
entre dois programas rodando emuma rede de computadores 
(associado a uma porta TCP/IP) 
25 
Comunicação com sockets (Fig 3.18 FSO1ed) 
26 
Uso de sockets no Unix/Linux (Fig 10.14 SOMTB3ed) 
27 
Sockets 
• Socket é definido como uma extremidade de 
comunicação. 
 
• Concatenação de endereço IP e porta. 
 
• O socket 161.25.19.8:1625 se refere à porta 
1625 no host 161.25.19.8. 
 
• A comunicação ocorre entre um par de sockets. 
28 
Soquetes (SOD3ed) 
• Permitem que pares de processos troquem dados estabelecendo 
canais diretos de comunicação bidirecional. 
 
• Usados principalmente para comunicação bidirecional entre vários 
processos em sistemas diferentes, mas podem ser usados para 
processos no mesmo sistema. 
 
• Armazenados internamente como arquivos. 
 
• O nome do arquivo é usado como endereço do soquete, que é 
acessado por meio do VFS (Linux). 
29 
Windows Winsocks (SODeitel3ed) 
 
• Windows sockets 2 (Winsock 2). 
• Pode ser portado de soquetes BSD com poucas alterações. 
• Executa com uma variedade de protocolos de rede/transporte, 
como TCP/IP ou IPX/SPX. 
• Soquete de fluxo ou de datagrama. 
• Comunicação síncrona ou assíncrona. 
• Transparência de protocolo. 
30 
Troca de Mensagens (Fig 7.6 ASOM4ed) 
Processo
transmissor
Processo
receptor
SEND RECEIVE
Canal de comunicação
31 
 Comunicação direta (Fig 7.7 ASOM4ed) 
Processo A Processo B
32 
Comunicação indireta (Fig 7.8 ASOM4ed) 
Processo A Processo B
Mailbox
ou Port
33 
Troca de Mensagens 
• Mecanismo usado por processos para se comunicar e 
sincronizar suas ações. 
 
• Permite a comunicação entre sem a necessidade de 
compartilhamento de variáveis. 
 
• Operações básicas: 
– send(P, msg): envia msg para P. 
– receive(Q, msg): recebe msg oriunda de Q. 
34 
Filas de mensagens (SOD3ed) 
• Permitem que os processos transmitam informações que são 
compostas por um tipo de mensagem e por uma área de dados de 
tamanho variável. 
• Armazenadas em filas de mensagens, permanecem até que um 
processo esteja preparado para recebê-las. 
• Processos relacionados podem procurar um identificador de fila de 
mensagens em um arranjo global de descritores de fila de 
mensagens. 
• O descritor de fila de mensagens contém: 
• fila de mensagens pendentes; 
• fila de processos em espera de mensagens; 
• fila de processos em espera para enviar mensagens; 
• dados que descrevem o tamanho e o conteúdo da fila de 
mensagens. 
35 
Windows mailslots (SOD3ed) 
• Servidor de mailslot: cria o mailslot. 
• Clientes de mailslot: enviam mensagens ao mailslot. 
• Comunicação 
• Unidirecional. 
• Não fornece confirmação de recebimento. 
• Comunicação local ou remota. 
• Implentada como arquivos. 
• Dois modos 
• Datagrama: para pequenas mensagens. 
• Bloco de Mensagens do Servidor (SMB): para mensagens 
grandes. 
36 
Middleware (Fig 8.29 SOMTB3ed) 
37 
Middleware (Cap 5 SDCO4ed) 
Applications, services
Computer and network hardware
Platform
Operating system 
Middleware
38 
Middleware layers (Figure 5.1 - SDCO4ed) 
Applications 
Middleware 
layers Request reply protocol 
External data representation 
Operating System 
RMI, RPC and events 
39 
Middleware ©MTOV 
• Middleware: qualquer componente de software cujo 
objetivo é auxiliar a programação de uma aplicação 
distribuída 
– Componente de software: biblioteca, API, estrutura de 
dados etc 
– Situa-se acima da camada de transporte e abaixo da camada 
de aplicação 
 ©MTOV (copyright para Marco Túlio de Oliveira Valente) 
 
40 
Middleware ©MTOV 
 
• Middlewares: 
RPC, CORBA, Java RMI, Microsoft DCOM, 
Web Services, etc 
• Motivação: 
– Troca de mensagens: conceito pouco natural 
e primitivo 
– Podem ser usados mecanismos de mais alto 
nível para “esconder” (ou tornar 
transparente) a troca de mensagens 
41 
RPC: chamada a procedimento remoto ©MTOV 
r = soma(x,y) float soma(x,y) { 
 return x+y; 
} 
 
Cliente Servidor 
42 
Remote Procedure Call (RPC) 
• Abstrai o conceito de chamada de procedimento entre 
processos em sistemas em rede, possibilitando que um 
processo chame um procedimento em um outro 
computador. 
• Objetivo: simplificar o processo de escrita de 
aplicações distribuídas preservando a sintaxe de uma 
chamada a procedimento local e, ao mesmo tempo, 
iniciando de modo transparente uma comunicação de 
rede. 
• Stub (proxy) do cliente faz o empacotamento dos 
parâmetros. 
• Stub do servidor recebe a mensagem, desempacota 
os parâmetros e realiza o procedimento. 
43 
RPC : Remote Procedure Call 
• Automatizar o processo de marshalling (empacotamento) e 
unmarshalling (desempacotamento). 
 
• Facilita a comunicação em rede, fazendo com que chamadas 
remotas sejam solicitadas pelo usuário da mesma forma que são 
solicitadas as chamadas locais. 
 
• Abstrai, dos programadores, os passos necessários para localizar 
e executar trechos de programas localizados em outras máquinas. 
44 
RPC: passos (Fig 8.20 SOMTB3ed) 
45 
Modelo de comunicação da RPC (Fig 17.1 SOD3ed) 
46 
Execução de RPC (Fig 3.21 FSO1ed) 
47 
Fluxo da chamada RPC (SOD3ed) 
48 
RPC: Exemplo ©MTOV 
r = soma(x,y) 
float soma(x,y) { 
 
} 
 
float soma(x,y) { 
 
} 
 
float soma(x,y) { 
 return x+y; 
} 
 (1) 
(2) 
(3) (4) 
(5) 
(6) 
Cliente 
Stub 
Cliente 
Stub 
Servidor 
Servidor 
49 
RPC: Exemplo (detalhes) ©MTOV (1) 
• Passo 1: Chamada local: soma (x, y) 
• Passo 2: Stub do cliente “captura” chamada e realiza o 
marshalling de seus parâmetros 
• Passo 3: Envio de mensagem na rede com os parâmetros 
• Passo 4: Recebimento da mensagem na máquina remota 
e chamada ao stub do servidor 
• Passo 5: Stub do servidor realiza o unmarshalling dos 
parâmetros e chama o procedimento remoto 
50 
RPC: Exemplo (detalhes) ©MTOV (2) 
• Passo 6: Execução do procedimento remoto 
• Passo 7: Stub do servidor realiza o marshalling do 
resultado 
• Passo 8: Envio de mensagem de rede com o resultado 
• Passo 9: Recebimento do resultado e chamada ao stub 
do cliente 
• Passo 10: Stub do cliente realiza o unmarshalling do 
resultado e retorna o mesmo à aplicação cliente 
51 
RPC : Remote Procedure Call ©MTOV 
• RPC: Chamada Remota de Procedimento 
– Birrel & Nelson, 1984 
– Protocolo de Apresentação (nível 6) 
• Arquitetura: Utilização de stubs 
– Client Stub: programa instalado no cliente 
– Server Stub: programa instalado no servidor 
• Função dos stubs: 
– Automatizar o processo de marshalling e 
unmarshalling 
52 
Para emitir uma RPC (SOD3ed) 
• O processo do cliente faz uma chamada ao procedimento no 
stub do cliente. 
• O stub do cliente faz a montagem de dados para empacotar 
argumentos de procedimento com o nome do procedimento em 
uma mensagem para transmissão via rede. 
• O stub do cliente transfere a mensagem ao servidor. 
• O servidor transmite a mensagem ao stub do servidor. 
• A mensagem é desmontada. 
• O stub envia os parâmetros ao procedimento local apropriado. 
• Ao concluir o procedimento, o stub do servidor monta o 
resultado e o envia de volta ao cliente. 
• Finalmente, o stub do cliente desmonta o resultado, notifica o 
processo e transfere o resultado a ele. 
53 
RPC: implementações 
• CORBA - padrão independente de 
plataforma. 
• Sun RPC - plafaformas Unix e Linux 
• DCOM - plataforma Windows. 
• RMI - Java. 
• SOAP - padrão para webservices.54 
Windows LPC (Fig 3.17 FSO1ed) 
55 
Windows LPC (Local Procedure Call) 
 
• Somente entre processos do mesmo sistema. 
• Usa portas (como mailboxes) para estabelecer e manter 
canais de comunicação. 
• Cliente obtem um manipulador (handle) para o objeto 
porta de conexão do subsistema. 
• Cliente envia uma solicitação de conexão. 
• Servidor cria duas portas de comunicação privadas e 
retorna o manipulador de uma delas para o cliente. 
• Cliente e servidor usam o manipulador da porta 
correspondente para enviar mensagens ou retorno de 
chamadas e ouvir respotas. 
56 
Windows LPC e RPC (SOD3ed) 
• Processo servidor 
• Executa procedimentos. 
• Processo cliente 
• Chama procedimentos no processo servidor. 
• Chamada local de procedimento (LPC) 
• Processo cliente e processo servidor na mesma máquina. 
• Apenas threads de modo núcleo podem expor LPCs. 
• Chamada remota de procedimento (RPC) 
• Processo cliente e processo servidor em máquinas 
diferentes. 
• Chamada local remota de procedimento (LRPC) 
• Processo cliente e processo servidor na mesma máquina. 
• O processo cliente usa o protocolo RPC. 
57 
Windows LPC (Local Procedure Call - Cap 22 SOJ7ed) 
• LPC permite passar requisições e resultados entre processes clientes e 
servidores situados na mesma máquina. 
• Em particular, ela é usada para requisitar serviços dos vários sub-sistemas 
do Windows. 
• Quando um canal de LPC é criado, um dentre três técnicas de troca de 
mensagens precisa ser especificada: 
– A primeira técnica é adequada para pequenas mensagens (até 
algumas centenas de bytes). Neste caso, a fila de mensagens da porta é 
usada como armazenamento intermediário e as mensagens são 
copiadas de um processo para outro. 
– A segunda técnica é para copiar mensagens maiores. Neste caso, um 
objeto seção de memória compartilhada é criada para o canal. 
– A terceira técnica (denominada quick LPC) utiliza as APIs Win32 que 
leem e escrevem mo espaço de endereçamento de um processo. 
58 
RPC - implementação 
• Para desenvolver uma aplicação cliente 
servidor utilizando o RPC, os seguintes 
passos são necessários: 
– Especificar o protocolo utilizado para a 
comunicação entre o cliente e o servidor 
– Desenvolver aplicação servidor 
– Desenvolver aplicação cliente 
– Gerar os arquivos necessários à compilação 
– Compilar separadamente o servidor e o cliente 
59 
Sistema Sun RPC ©MTOV 
• Dois componentes principais: 
– Linguagem XDR 
– Compilador rpc 
• Linguagem XDR (External Data Representation): 
linguagem para definição do cabeçalho (assinatura) dos 
procedimentos remotos 
• Compilador rpc, chamado rpcgen: dada uma 
especificação em XDR, gera stubs do cliente e do 
servidor 
60 
Files interface in Sun XDR (Fig 5.9 SDCO4ed) 
const MAX = 1000; 
typedef int FileIdentifier; 
typedef int FilePointer; 
typedef int Length; 
struct Data { 
 int length; 
 char buffer[MAX]; 
}; 
struct writeargs { 
 FileIdentifier f; 
 FilePointer position; 
 Data data; 
}; 
struct readargs { 
 FileIdentifier f; 
 FilePointer position; 
 Length length; 
}; 
 
program FILEREADWRITE { 
 version VERSION { 
 void WRITE(writeargs)=1;
 1 
 Data READ(readargs)=2;
 2 
 }=2; 
} = 9999; 
61 
Objeto Remoto (SDCO4ed) 
• Um objeto remoto é aquele que pode ser invocado a partir de um 
outro processo. 
 
• Uma referência a um objeto remoto é um identificador para um 
objeto remoto que é usado para se referir a ele como o alvo de 
uma invocação remota e pode ser passada como um argumento 
ou resultado de uma invocação remota de método. 
 
• Clientes precisam de referência ao objeto remoto para fazer uma 
invocação remota. 
 
• Referências a objetos remotos podem ser obtidas através do 
binder ou como resultado de uma RMI. 
62 
Interface Remota (SDCO4ed) 
• Uma interface remota especifica os métodos de um 
objeto que são disponíveis invocação por objetos 
remotos em outros processos. 
 
63 
Objetos Distribuídos (SDTB) 
• Common organization of a remote object 
with client-side proxy. 
2-16 
64 
Remote object and its remote interface (Figure 5.4 SDCO4ed) 
interface 
remote 
m1 
m2 
m3 
m4 
m5 
m6 
Data 
implementation 
remote object 
{ 
of methods 
65 
Remote Method Invocation (FSO1ed) 
66 
Remote Method Invocation(FSO1ed) 
67 
RMI: Invocação a método remoto (SOD3ed) 
• Remote Method Invocation (RMI) possibilita que um programa 
Java invoque um método de um objeto remoto usando a mesma 
sintaxe de uma chamada a método local. O é mecanismo 
semelhante ao RPC. 
• Os detalhes da montagem de parâmetros e do transporte de 
mensagens por RMI são transparentes ao programa que emite a 
chamada 
• A camada de stub/esqueleto da RMI contém estruturas de 
montagem de parâmetros análogas aos stubs de cliente e 
servidor da RPC. 
• O stub emprega serialização de objeto e permite que os 
programas passem objetos Java como parâmetros e recebam 
objetos como valores de retorno. 
68 
Java RMI ©MTOV 
 
• Stub e Skeleton: equivalente a stubs de 
RPC 
– Stub: parte que executa no cliente 
– Skeleton: parte que executa no servidor 
 
• rmic: compilador usado para gerar stub e 
skeleton 
 
69 
Passos para RMI 
 
• Passo 1: Definição da Interface Remota 
• Passo 2: Implementação da Interface 
Remota (servidor) 
• Passo 3: Implementação do Cliente 
• Passo 4: Compilação 
• Passo 5: Execução 
70 
Exemplo 1: Servidor de data usando Java RMI 
• Exemplo do cap 4 (SO com JAVA (2004) pg 98) . 
• Codificar um servidor com um objeto da seguinte classe: 
 class RemoteDateImpl .... { ...... 
 public abstract Date getData( ) ; 
........ 
} 
Codificar um cliente que chame remotamente o método 
getData( ) deste objeto 
71 
Exemplo 1: RMI Interface RemoteDate 
/* interface RemoteDate (Interface do objeto remoto) 
 Exemplo do cap 4 (SO com JAVA (2004) pg 98) . 
*/ 
import java.rmi.*; 
import java.util.*; 
 
public interface RemoteDate extends Remote 
{ 
 public abstract Date getData() throws RemoteException; 
} 
72 
Implementação da Interface RemoteDate (1) 
import java.rmi.*; 
Import java.rmi.server.UnicastRemoteObject; 
import java.util.Date; 
public class RemoteDateImpl extends UnicastRemoteObject 
 implements RemoteDate 
{ 
 public RemoteDateImpl( ) throws RemoteException { }; 
 public Date getData( ) throws RemoteException 
 { 
 return new Date( ); 
 } 
73 
Implementação da Interface RemoteDate (2) 
public static void main(String[ ] args) { 
/* nomeia o objeto remoto nomeado como DataServer 
 try { 
 RemoteDate dataServer = new RemoteDateImpl( ); 
/* Associa essa estância de objeto ao nome “DateServer” */ 
 Naming.rebind("DateServer", dateServer); 
 } 
 catch( Exception e ) { 
 System.out.println( e ); 
 } 
 } 
} 
74 
Cliente RMI 
import java.rmi.*; 
public class RMIClient 
{ 
 public static void main(String[] args) { 
 try { /* localiza o objeto remoto nomeado DataService */ 
 /* Chama o método do objeto remoto (getData). */ 
 String host = "rmi:// 127.0.0.1 /DateServer"; 
 RemoteDate dataServer = (RemoteDate) Naming.lookup( 
host); 
 System.out.println( dataServer.getData()); 
 } 
 catch( Exception e ) { 
 System.out.println( e ); 
 } 
 } 
} 
75 
SOA: Modelo básico operacional 
76 
76 
Arquiteturas Orientadas por Serviços©MTOV 
UDDI 
SOAP 
WSDL 
Fonte: Web Services: Concepts, Architecture and Applications. Gustavo Alonso, 
Fabio Casati, Harumi Kuno, Vijay Machiraju. Springer Verlag, 2004 
77 
• Service provider (provedor de serviços): plataforma que hospeda o 
web service permitindo que os clientes acessem o serviço. 
 
• Service broker: registra e descobre os serviços na Web, lista os 
vários tipos de serviços, descrições e locais do serviços que 
auxiliam o solicitante dos serviços (service requestor) a encontrar e 
acessar os serviços requiridos. 
 
• Service requestor (solicitante ou usuário dos serviços): localiza o 
serviço usando o service broker, invoca o serviço requerido e o 
executa no service provider. 
SOA: Modelo básico operacional 
78 
Service-Oriented Architecture : SOA 
Arquitetura Orientada a Serviços (SOA: Service-Oriented 
Architecture): 
• Estratégia de TI (Tecnologia de informação) que transforma 
funções de negócios existentes nas aplicações das 
empresas em serviços de software que se comunicam 
entre si por meio de contratos bem definidos de tal modo 
que possam ser reutilizados. 
 
• As aplicações são quebradas em componentes de serviços, 
que por sua vez podem ser combinados e misturados com 
outros serviços de acordo com a necessidade dos 
negócios. 
79 
Service-Oriented Architecture : SOA 
• Disponibiliza aplicativos ou rotinas como serviços em uma 
rede de computadores (Internet ou Intranets) de forma 
independente e se comunicando através de padrões 
abertos. 
 
• SOA pode ser implementada usando qualquer tecnologia 
padronizada baseada em web. 
 
• A maior parte das implementações de SOA se utilizam da 
tecnologia de Web services. 
80 
WS: Serviços Web (SOD3ed) - 1 
• CORBA, DCOM não podem se comunicar facilmente, pois seus 
componentes precisam se comunicar via uma ponte (adaptador) 
COM/CORBA. 
 
• Se os protocolos subjacentes mudarem a ponte (adaptador) deve ser 
modificado para refletir estas modificações (SOD3ed). 
 
• Serviços Web (Web Services) usam padrões abertos para obter uma 
maior interoperabilidade e integração de aplicações 
independentemente de plataformas e linguagens de programação. 
 
81 
Serviços Web (SOD3ed) - 2 
• Compreendem um conjunto de padrões relacionados 
que podem habilitar aplicações de computador a 
comunicar-se e a trocar dados pela Internet. 
 
• Independem de tecnologia e plataforma. 
 
• Melhoram o desenvolvimento de software colaborativo 
por permitir que os desenvolvedores criem aplicações 
associando códigos escritos em qualquer linguagem 
em qualquer plataforma. 
82 
Serviços Web (SOD3ed) - 3 
• Promovem a programação modular. 
 
• Toda função específica em uma aplicação pode ser exibida 
como um serviço Web distinto. 
 
• Pessoas ou empresas podem criar suas próprias aplicações 
mesclando e associando serviços Web que ofereçam a 
funcionalidade de que precisam. 
 
• A modularização é menos propensa a erros e possibilita a 
reutilização de software. 
83 
WS: Serviços Web (SOD3ed) – 4 
• Facilitam a comunicação entre as aplicações que residem em 
múltiplas plataformas, usando diferentes modelos de objetos e 
padrões de interoperabilidade como XML, SOAP, WSDL e 
UDDI. 
 
• São semelhantes a CORBA, DCOM e Java RMI, porém usam 
protocolos e padrões da Web como HTTP, XML, SOAP, 
WSDL e UDDI. 
84 
Serviços Web (Web Services) 
• Abrangem um conjunto de padrões relacionados 
que podem habilitar quaisquer duas aplicações de 
computador a se comunicar e trocar dados via 
Internet (SO-Deitel-2005). 
 
• São aplicações distribuídas que se comunicam por 
meio de mensagens XML, formatadas e encapsuladas 
segundo o protocolo SOAP e transportadas via HTTP 
(©MTOV). 
 
• São uma extensão e adaptação do conceito de 
chamada remota de métodos para a Web, com 
informações estruturadas e interfaces bem definidas. 
85 
Serviços Web (Web Services) 
• Integração de aplicações 
 
• Serviços Web podem ser tão triviais como multiplicar dois 
números ou tão complexo quanto a função executada por um 
sistema de software CRM da FedEx para rastrear a localização 
e andamento de uma encomenda (fedex.com/us/tracking). 
 
• Exemplos: 
Sistemas B2B, Amazon Web Services (amazon.com/ 
gp/aws/landing.html), Google Web Service (google.com/apis). 
 
86 
Serviços Web (©MTOV) - 5 
• Interfaces são definidas na linguagem WSDL 
 
• São registrados em servidores UDDI. 
 
• No CORBA: 
– HTTP e TCP fazem o papel do TCP em CORBA 
– XML e SOAP fazem o papel do IIOP em CORBA 
– WSDL faz o papel de IDL em CORBA 
– UDDI faz o papel de um serviço de nomes em 
CORBA 
87 
WS x Outras soluções RPC (Java RMI e CORBA) 
Registro 
Descrição de 
Serviços 
Transporte 
Java RMI 
RMI Registry 
Java 
Java RMI 
CORBA 
COS Naming 
OMG IDL 
IIOP 
Web Services 
UDDI 
WSDL 
SOAP 
88 
SOAP: Estrutura da Mensagem (1) 
89 
SOAP: Arquitetura ©MTOV 
Fonte: Paulo Pires e Marta Matoso. Tecnologia de Serviços Web. Mini-curso SBES 
2005. 
90 
Simple Object Access Protocol: SOAP (©MTOV) - 1 
• Protocolo de mensagens, desenvolvido inicialmente pela 
Microsoft, IBM e Lotus, para transportar informações e instruções 
entre Serviços Web (SO-Deitel-2005). 
 
• É um protocolo W3C para executar métodos remotos através de 
RPC e trocar informações na Internet. 
 
• Utiliza XML para codificação de mensagens e HTTP (porta 80) 
para transporte de mensagens de um nodo a outro. 
 
• Permite adicionar serviços a um servidor Web e então acessar 
estes serviços a partir de programas comuns. 
91 
Simple Object Access Protocol: SOAP (©MTOV) - 2 
• Serviços: objetos, com métodos chamados remotamente. 
 
• SOAP especifica como representar em XML todas 
informações necessárias para se executar uma chamada 
remota: 
– Formato da mensagem de ida (com os argumentos) 
– Formato da mensagem de volta (com o resultado) 
 
• Independente de linguagem de programação 
92 
Web Service Description Language : WSDL - 1 
• Linguagem baseada em XML responsável por prover as 
informações necessárias para a invocação do Web Service, ou 
seja: localização, operações disponíveis e assinaturas. 
 
• Fornece um método padronizado para descrever Serviços Web e 
suas capacidades específicas (SOD3ed). 
 
• Descreve a localização e a interface de um WS: 
– Nome e URL do serviço (“binding information”) 
– Assinatura dos métodos disponíveis para chamada remota 
(“abstract interface”) 
 
93 
Web Service Description Language : WSDL - 2 
• É semelhante a IDL em CORBA, porém com a sintaxe baseada 
em XML 
 
• Permite, através da definição de um vocabulário em XML, a 
possibilidade de descrever serviços e a troca de mensagens. 
 
• Permite que um cliente de um Web Service obter o formato dos 
métodos a serem chamados, parâmetros a serem passados e e 
como processar uma requisição. 
 
• Existem ferramentas que geram especificações WSDL a partir, 
por exemplo, de interfaces Java. 
94 
Exemplos de utilização de SOAP com Web 
 
Exemplo 1: Acesso a Web Services através do Navegador 
 
 
Exemplo 2: Cliente acessa Web Services no servidor 
 
95 
Exemplo 1 
96 
Exemplo 2 
97 
A plataforma .NET da Microsoft (SODeitel3ed) - 1 
• Estende o conceito de reutilização de software à Internet permitindo que 
os desenvolvedores reutilizem componentes de software que residem em 
outras máquinas ou plataformas. 
 
• A iniciativa .NET 
• Inclui o ambientede desenvolvimento integrado Visual Studio .NET. 
• Permite que os programadores desenvolvam serviços Web em uma 
variedade de linguagens, incluindo: C++, C# e Visual Basic .NET 
• As tecnologias .NET são disponíveis para a plataforma Windows, 
mas existem implementações multiplataformas como o MONO. 
98 
A plataforma .NET da Microsoft (SODeitel3ed) - 2 
• Substitui a DCOM. 
• Aplicações locais conversam com aplicações remotas para executar 
requisições do usuário. 
• Serviços Web 
• Aplicações que podem ser acessadas na Web. 
• Os dados são transportados em XML sobre HTTP. 
• Interoperáveis. 
• Modelo de programação estrutura .NET 
• API estendida para a API do Windows para incluir suporte a serviços 
Web. 
• Visual Basic .NET, Visual C++ .NET, C#. 
• Componentes do servidor.NET : Sites Web, Windows 2003 Server etc. 
99 
Estrutura do Framework 
.NET 
100 
Tecnologia .Net: MSIL, CLR , ASP.NET 
101 
Modelo de execução de um programa .NET 
102 
.Net Framework (Glauber2007) 
• Ambiente para desenvolvimento e execução de programas 
que no Common Language Runtime (CLR), nas classes do 
Framework e na ASP.NET. 
 
• Pode usar diferentes linguagens e bibliotecas para criar 
aplicativos baseados na arquitetura do Windows. 
 
• O .Net framework em conjunto com o IIS permite construir, 
gerenciar, implantar e integrar aplicativos Web. 
 
103 
.Net Framework (Glauber2007) 
• MSIL (Microsoft Intermediate Language): indiferente de qual linguagem 
.Net que estiver sendo usada, o código é gerado em MSIL. 
• CLR (Common Language Runtime): sistema complexo responsável por 
executar o código MSIL no computador. Ele toma conta de todos os 
aspectos básicos envolvendo a comunicação com o Windows e com o 
IIS (Internet Information Services). 
• Linguagens .NET: linguagens de programação que obedecem a certos 
requerimentos estruturais específicos (conforme definido pela 
especificação CLR) e que podem ser então compiladas para MSIL. 
• ASP.NET: responsável por tratar assuntos referentes a tecnologia Web, 
usando o IIS para gerenciar páginas simples de código. 
• ADO.NET: responsável pelo processo de persistência a banco de dados e 
manipulação do mesmo. 
104 
Tecnologia Java: Plataforma e API’S