Arquitetura de Software

Aplicaes
para
Distribudas
Marco Tlio de Oliveira Valente

Middleware

Marco Tlio de Oliveira Valente

Middleware

Desenvolver uma aplicao distribuda mais difcil do

que desenvolver uma aplicao centralizada
Problemas tpicos: comunicao, heterogeneidade, falhas,
concorrncia, segurana, escalabilidade etc
Middleware: infra-estrutura de software que fica entre o
sistema operacional e uma aplicao distribuda
Objetivo: tornar mais simples e produtivo o desenvolvimento de
uma
aplicao distribuda
Idia: oferecer abstraes/recursos de mais alto nvel que
tornem transparente ao programador detalhes de programao
em redes
Fazer com que programao distribuda seja o mais semelhante
a
programao centralizada

Middleware

Middleware e linguagens de programao:

LP: escondem o hardware (registradores, instrues de
mquina,
modos de endereamento, perifricos etc)
Middleware: escondem a rede (endereos IP, portas,
sockets, formato de mensagens, conexes, falhas etc)
Veja que hoje a rede o computador

Classificao de sistemas de middleware:

De acordo com o nvel de abstrao provido
De acordo com o tipo de abstrao provida
De acordo com o domnio de aplicao ou tecnologia de rede

Middleware: Nveis de Abstrao

Sistemas de middleware que fornecem uma infra-estrutura

para execuo de aplicaes (host infrastructure middleware)
Abstraem e unificam em uma API particularidades de
um hardware ou sistema operacional
Fornecem primitivas para criao de threads,
sincronizao, comunicao via TCP ou UDP etc
Exemplos: Sun JVM, .NET CLR

Sistemas de middleware que fornecem uma infra-estrutura

de comunicao (communication ou distribution middleware)
Exemplos: Java RMI, CORBA, DCOM, SOAP, .NET Remoting
Framework, JavaSpaces, Servios Web etc
Uso mais comum do termo middleware
5

Middleware: Nveis de Abstrao

Sistemas de middleware que fornecem outros servios, alm

de comunicao (common based middleware)
Servios: persistncia, transaes, nomes, autenticao etc
Exemplos: EJB, CCM (Corba Component Model)
Conhecidos como middleware baseados em componentes

Requisitos funcionais: o que o sistema faz (ou seja,

as funcionalidades do sistema)
Requisitos no-funcionais: como o sistema funciona (atributos
de qualidade)
Exemplos: distribuio, persistncia, desempenho, segurana,
concorrncia, confiabilidade, tolerncia a falhas

Middleware: Abstraes de
Comunicao

Classificao baseada nas primitivas de comunicao entre

componentes fornecidas pela plataforma de middleware
Exemplos:
Chamada remota de procedimentos (Sun RPC, DCE RPC
etc)
Chamada remota de mtodos (Java RMI, CORBA, DCOM
etc)
Mensagens/eventos (JMS, IBM MQSeries etc)
Espaos de tuplas (TSpaces, Java Spaces etc)
Transaes (CICS, MTS, JTS, Encina, Tuxedo etc)

Middleware: Domnios de Aplicao

Middleware para domnios de aplicao especficos

(domain specific middleware):
Exemplos: telemedicina, ensino a distncia, comrcio
eletrnico, jogos digitais, multimdia, vdeo sob demanda etc
Nestes casos, o middleware um framework (esqueleto de
uma aplicao que vai ser terminada pelo usurio do
middleware)

Middleware para tecnologias e ambientes de rede especficos:

Exemplos: computao mvel, grades computacionais
(grids), sistemas embutidos, TV Digital etc

Prximos Captulos

RPC

Middleware Orientado por Objetos: Viso Geral

Java RMI
CORBA

Middleware Orientado por Objetos: Recursos

Avanados
Chamadas assncronas
Reflexo computacional

Web Services, Estilos Arquiteturais e REST

Arquiteturas orientadas a servios

RPC

Birrell, A.D. & Nelson, B.J. "Implementing Remote Procedure

ACM Transactions on Computer Systems 2, 1 (Feb. 1984): 39-59.
Calls."
The primary purpose of our RPC project was to make distributed
computation easy. Previously, it was observed within our research
community that the construction of communicating programs was a
difficult task, undertaken only by members of a select group of
communication experts. Even researchers with substantial
systems experience found it difficult to acquire the specialized
expertise required to build distributed systems with existing tools.
This seemed undesirable ....
The existing communication mechanisms appeared to be a
major factor constraining further development of distributed
computing. Our hope is that by providing communication with
almost as much ease as local procedure calls, people will be
encouraged to build and experiment with distributed applications.
10

RPC: Idia Bsica

Cliente
r= soma(x,y)

Servidor
float soma(x,y) {
return x+y;
}

11

RPC: Marshalling e Unmarshalling

Quando cliente A chama procedimentos de um servidor B:

Pode ser necessrio passar como parmetro (e receber como
resultado) estruturas mais complexas (objetos, vetores etc)
Cliente A:
Deve converter os parmetros para um formato que possa ser
transmitido por um protocolo de transporte (TCP, por exemplo)
Este processo chamado de marshalling
Servidor B:
Deve converter mensagem recebida em uma estrutura de
dados
Este processo chamado de unmarhalling
Processo de marshalling/unmarshalling
tedioso e sujeito a
erros
Portanto, deve ser automatizado pela plataforma de middleware
12

RPC: Stubs

Funcionamento interno baseado em mdulos chamados de stubs

Stubs: encapsulam detalhes de comunicao no cliente e servidor
Automatizam processo de marshalling e unmarshalling
Automatizam comunicao com o processo remoto
(interagindo com o protocolo de transporte)
Marshalling/unmarshalling realizado por stubs chamado
de esttico

13

RPC: Arquitetura Interna

Cliente

Servidor

r= soma(x,y)
(6)

Stub
Cliente

(1)

float soma(x,y) {
}

float soma(x,y) {
return x+y;
}
(3)

(2)

(4)

Stub
Servidor

(5)

Questo fundamental: Quem gera os stubs?

Evidentemente, gerao manual no faz
sentido
14

RPC: Arquitetura Interna

Stubs so gerados automaticamente, por um compilador de stubs

Entrada deste compilador: assinatura dos procedimentos
remotos,
em uma linguagem chamada XDR (External Data Representation)
Genericamente, conhecida como linguagem para definio
de interfaces
Sada deste compilador: cdigo fonte dos stubs
client_stub.c

arquivo XDR

rpcgen
server_stub.c

15

Sistemas de Middleware Orientados

por Objetos

Extenso de RPC para o paradigma orientado por objetos

Idia bsica: objetos clientes podem chamar mtodos de objetos
remotos com transparncia de acesso (isto , com a mesma
sintaxe de chamadas locais)
Principal abstrao: chamada remota de mtodos (RMI)
Objetos remotos so manipulados usando-se referncias de rede
Sistemas: CORBA, Java RMI, DCOM, .NET Remoting etc
Servidor (de aplicao): instancia objeto remoto e o registra
no servidor de nomes (registrar= dar um nome para o objeto)
Servidor de nomes: tabela (nome, referncia de rede)
Cliente: consulta servidor de nomes (fornecendo o nome do
objeto), obtm uma referncia de rede para o objeto remoto), usa
essa referncia para realizar chamadas remotas
16

Java RMI

Middleware para programao distribuda em Java

Implementado como um pacote da linguagem
Ann Wollrath, Roger Riggs, Jim Waldo. A Distributed Object Model
for the Java System. COOTS 1996

17

Java RMI: Exemplo de Aplicao

Codificar um servidor com um objeto da seguinte

classe:
class ContaImpl .... { ......
float obterSaldo ();
........
}

Codificar um cliente que chame remotamente o mtodo

obterSaldo() deste objeto

18

Java RMI: Exemplo de Aplicao

Passo 1: Definio da interface remota (assinatura dos

mtodos que sero invocados remotamente)
// arquivo Conta.java
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface Conta extends Remote { ...... float
obterSaldo () throws RemoteException; ......
}

19

Java RMI: Exemplo de Aplicao

Passo 2: Implementao da Interface Remota (servidor)

// arquivo ContaImpl.java
import java.rmi.*;
import java.rmi.server.*;
class ContaImpl extends UnicastRemoteObject implements Conta {
private int numero; private float saldo= 0.0;
public ContaImpl (int n) throws RemoteException {
numero= n;
}
public float obterSaldo
() throws RemoteException
{ return saldo;
}
public static void main (String[] args) {
......
Conta c= new ContaImpl (804);
Naming.rebind (Conta804, c);
//
registra este objeto
}

20

Java RMI: Exemplo de Aplicao

Passo 3: Implementao do Cliente

// arquivo ClienteImpl.java
import java.rmi.*;
import java.rmi.server.*;
public class ClienteImpl {
public static void main (String[] args) {
......
Conta c= (Conta) Naming.lookup ( // + args[0]
+/Conta804);
float s= c.obterSaldo(); // chamada remota
/
/ mesma sintaxe
chamada local
......
}

21

Java RMI: Exemplo de Aplicao

Passo 4: Compilao
Compilao do servidor e do cliente (javac)
Gerao de stubs:
rmic ContaImpl
rmic gera os seguintes arquivos:
ComtaImpl_Stub.class: stub do cliente
ContaImpl_Skel.class: skeleton
(apenas RMI < JDK
1.4)
Passo 5: Execuo

Execuo
do Servidor:
rmiregistry
// registry (permanece em
execuo)
java ContaImpl
// servidor (outro processo)
Execuo do Cliente:

java clienteImpl server01.dcc.ufmg.br

22

Java RMI: Passagem de Parmetros

Objetos serializveis so passador por valor:

Classe do objeto deve implementar a interface Serializable
Passa-se uma cpia do objeto (atributos + mtodos)
Objetos remotos so passadas por referncia:
Passa-se a referncia (e no o objeto), a qual pode ser
utilizada para realizar um callback no cliente
Callback: servidor chama mtodo do cliente
Usado, por exemplo, quando o servidor deseja notificar o
cliente sobre a ocorrncia de algum evento

23

Exemplo de Callback

void g ()
{..... }

Cliente

Servidor

objeto
remoto

objeto remoto

a
s
s.f(a);

v
o
i
d
f
(
A
a

24

Java RMI - Chat

Aplicao de chat
interface:

usando Java RMI, com a seguinte

25

Sistema de Chat em Java RMI

remoto

conectados

remoto
display (s)
c
s.conecta(c);
......
s.envia(Bom dia!);

void conecta(C c) { adiciona c em

conectados } void envia (String s)
{ for (int i= 0; i < conectados.size; i++)
conectados[i].display(s); // callback
}
remoto
display (s)

c
s.conecta(c);

remoto
display (s)
c
s.conecta(c);
26

CORBA

CORBA: Common Object Request Broker Architecture

Padro para desenvolvimento de aplicaes distribudas
para
sistemas heterogneos usando orientao por objetos
OMG: Object Management Group (http://www.omg.org)
Consrcio de empresas responsvel pela proposio e
manuteno do padro CORBA
Criado em 1989, possui atualmente diversas empresas
OMA: Object Management Architecture
Arquitetura para construo de aplicaes distribudas
Primeira especificao importante da OMG
Objetivo da OMG: propor uma arquitetura e, em seguida,
propor padres para os componentes da mesma
27

CORBA

Steve Vinoski, CORBA: Integrating Diverse Applications Within

Distributed Heterogeneous Environments, IEEE
Communications Magazine, vol. 14, no. 2, February 1997.
Steve Vinoski: New Features for CORBA 3.0. Commun.
ACM 41(10): 44-52 (1998)

28

IIOP: Internet Inter-ORB Protocol

Protocolo, baseado em TCP/IP, para troca de mensagens entre

ORBs de diferentes fabricantes
Objetivo: interoperabilidade

ORB IONA

IIOP
ORB Java

29

IDL: Interface Definition Language

Linguagem para definir a interface de um objeto remoto

Especifica a assinatura das operaes que sero
implementadas
por um objeto remoto
Linguagem declarativa (sem cdigo)
Tipos pr-definidos: long, short, float, double, char, boolean,
enum
Tipos estruturados: struct, union, string, sequence
Tratamento de excees
Modos de passagem de parmetros: in, out e in out
Herana mltipla de interfaces
Idia: especificar interface em uma linguagem neutra

30

IDL: Interface Definition Language

Exemplo:
typedef sequence<string> extrato;
struct Data {
short dia, mes,ano;
};
interface conta {
float obterSaldo ();
extrato obterExtrato (in
Data inicio, in Data
fim);
.......
};

31

IDL: Interface Definition Language

Compiladores de IDL geram automaticamente:

stub (clientes)
skeleton (servidor)
Independncia de linguagem:
Compiladores IDL implementam gerao de cdigo para C, C+
+, Smalltalk, Ada, COBOL, Java etc
CORBA especifica como deve ser o mapeamento (binding)
de IDL para cada uma das linguagem acima

32

Desenvolvimento de Aplicaes em
CORBA: Viso Geral
Fonte IDL

Cliente

cliente.java

ORB A
Run-time

Servidor

Compilador
IDL-Java

Compilador
IDL-C++

stub.java

skel.cpp

Cliente

Servidor
IIOP

servidor.cpp

ORB B
Run-time
33

CORBA: Vantagens e Desvantagens

Vantagens:
Padro (independncia de LP, SO, fornecedor)
Middleware bastante completo (diversos servios)
Desvantagens:
Padro imposto por um grande comit: solues extensas,
duplicadas, sobrecarregadas, para atender a todos os gostos
etc
Vide linguagens propostas por comits (ADA, PL/I etc)
Ditado: Um camelo um cavalo projetado por um comit
The only way to reach agreement during the submission
process for a CORBA specification is to take the grand
union of the feature sets of all the pre-existing proprietary
implementations (ICE home page)
Soluo fechada, monoltica, inflexvel, com poucos pontos de
configurao, customizao, personalizao etc
Caixa-preta, one size fits all

34

Transparncia

Idia: distribuio deve ser transparente aos programadores

Principais tipos de transparncia (segundo ISO RM-ODP):
Transparncia de acesso: a maneira por meio da qual um
componente A acessa servios de um componente B
independe do fato de B ser local ou remoto
Transparncia de localizao: para que um componente A
acesse servios de um componente B, ele no precisa
conhecer o endereo fsico de B (mas apenas seu nome lgico)
Transparncia de migrao: componente B pode migrar de
uma mquina para outra sem impactar componente A
Transparncia de replicao: componente A pode acessar
o componente B ou uma de suas rplicas
Transparncia fundamental para aumentar o nvel de
abstrao, bem como para prover escalabilidade (no caso de
migrao e replicao)
35

Transparncia em CORBA e RMI

Transparncia de acesso: mtodos remotos so chamados com

a mesma sintaxe de mtodos locais
Java RMI: Sim
CORBA: Sim

Transparncia de localizao: para efetuar uma chamada remota,

clientes no precisam conhecer o nome da mquina onde
localiza- se o objeto servidor
Java RMI: no, pois mtodo lookup tem como parmetro o
nome da mquina do objeto servidor
CORBA: sim, pois clientes precisam conhecer a localizao
de uma nica mquina (o servidor de nomes da rede)

36

Crticas a Transparncia

Jim Waldo, Geoff Wyant, Ann Wollrath, Samuel C. Kendall: A Note

on Distributed Computing. Mobile Object Systems 1996: 49-64
There is an overall vision of distributed object-oriented computing
in which, from the programmers point of view, there is no essential
distinction between objects that share an address space and
objects that are on two machines with different architectures located
on different continents.
It is the thesis of this note that this unified view of objects is
mistaken. There are fundamental differences between tthe
interactions of distributed objects and the interactions of nondistributed objects. Further, work in distributed object-oriented
systems that is based on a model that ignores or denies these
differences is doomed to failure, and could easily lead to an
industry-wide rejection of the notion of distributed objectbased systems.
37

Computao Local x Remota

Latncia:
Ignoring the difference between the performance of local and
remote invocations can lead to designs whose implementations
are virtually assured of having performance problems because
the design requires a large amount of communication between
components that are in different address spaces and on
different machines.
Acesso a Memria:
A more fundamental difference between local and remote
computing concerns the access to memory in the two cases
specifically in the use of pointers. Simply put, pointers in a local
address space are not valid in another (remote) address
space. The system can paper over this difference ... Two
choices exist: either all memory access must be controlled by
the underlying system, or the programmer must be aware of
the different types of accesslocal and remote.

38

Computao Local x Remota

Falhas:
Being robust in the face of partial failure requires some
expression at the interface level. Merely improving the
implementation of one component is not sufficient. The
interfaces that connect the components must be able to state
whenever possible the cause of failure
Concorrncia:
Distributed objects by their nature must handle concurrent
method invocations

39

Reflexo Computacional

Marco Tlio de Oliveira Valente

Reflexo Computacional

Capacidade de um sistema se auto-inspecionar e auto-manipular

Um sistema reflexivo possui dois nveis:
Nvel bsico: contm objetos do domnio da aplicao
Meta-nvel: contm objetos que permitem acessar
propriedades e manipular objetos do nvel bsico
Objeto do meta-nvel so chamados de meta-objetos
Protocolo de meta-objetos: protocolo de interao com metaobjetos
Reificao: ao de transformar em meta-objetos informaes
do nvel base
Reflexo envolve duas atividades:
Inspeo: quando meta-nvel inspeciona informaes do nvel
bsico
Interseo: quando meta-nvel interfere no comportamento ou
na estrutura do nvel bsico

41

Reflexo Computacional

A atividade de intercesso pode ser:

Estrutural
Comportamental
Reflexo estrutural: permite alterar estruturas de dados do
programa (criar classes, criar objetos, adicionar mtodos
em classes, adicionar campos em classes etc)
Reflexo comportamental: permite interferir na execuo do
programa, interceptando alguns eventos (chamadas de
mtodos, criao de objetos etc)
Reflexo desde o incio foi usada para implementar
diversos requisitos no funcionais tpicos de sistemas
distribudos:
Transaes, segurana, tolerncia a falhas, balanceamento
de carga, logging, persistncia etc
Vantagem: separao de interesses

42

Reflexo em Java

Tudo comea com um meta-objeto do tipo Class

Exemplo: Class c= Class.forName(java.util.Stack);
Pode-se usar mtodos do tipo Class para inspeo de
informaes:
Obter a super-classe do tipo base
Obter interfaces que so implementadas pelo tipo base
Obter informaes sobre os construtores do tipo base
Obter informaes sobre os mtodos do tipo base
(modificadores, tipo de retorno, tipo dos
parmetros)
Pode-se ainda interceder no nvel bsico do programa
para:
Criar objetos de tipos cujos nomes somente sero
conhecidos em tempo de execuo
Obter/definir valores de atributos cujos nomes somente
tempo de execuo
sero conhecidos em tempo de execuo

43

Reflexo em Java

Programa que lista informaes sobre uma interface cujo nome

informado pelo usurio:
Console.readString(s);
// le nome da interface do teclado
Class c= Class.forName(s);
Method[] theMethods= c.getMethods();
for (int i = 0; i < theMethods.length; i++)
String { methodString=
theMethods[i].getName();
System.out.println("Name:
" + methodString);
String returnString= theMethods[i].getReturnType().getName();
System.out.println(" Return Type: " + returnString);
Class[] parameterTypes= theMethods[i].getParameterTypes();
System.out.print(" Parameter Types:");
for (int k= 0; k < parameterTypes.length; k ++)
{ String parameterString=
parameterTypes[k].getName();
System.out.print(" " + parameterString);
}
System.out.println();
}

44

Reflexo em Java

Permite inspeo do nvel base

Permite forma limitada de reflexo estrutural:
Pode-se criar objetos e chamar mtodos de forma reflexiva
No se pode adicionar atributos/mtodos em classes, mudar
o nome de um mtodo, mudar modificadores etc
Permite forma limitada de reflexo comportamental:
Interceptao de chamadas de mtodos via classes proxy
dinmicas
Solues mais poderosas:
Sistemas como Javassist (reflexo estrutural) e Kava
(reflexo comportamental).
Programao orientada por aspectos
Em linhas gerais,

AOP= reflexo sem reificao

45

Classes Proxy Dinmicas

Recurso de reflexo de Java para criao dinmica de proxies

Proxy: padro de projeto comum em aplicaes distribudas
Proxy: objeto que implementa a mesma interface de um objeto
base
Age como um intermedirio entre objeto base e seus clientes
Normalmente, possuem uma referncia para objeto base
e interceptam todas as chamadas destinadas ao mesmo
Exemplo: stubs so exemplos de proxy
Em Java, classes proxy dinmicas tm duas propriedades:
Seu cdigo criado em tempo de execuo
Implementam interfaces definidas em tempo de criao
Instncias de classes proxy dinmicas tm ainda um objeto
manipulador de invocao (invocation handler), o qual
definido pelo cliente que solicitou a criao das mesmas.
46

Classes Proxy Dinmicas

Toda a invocao de mtodo sobre uma instncia de uma classe

proxy dinmica enviada automaticamente para o mtodo invoke
do manipulador desta instncia, passando os seguintes
parmetros:
a instncia da classe proxy sobre a qual a invocao
foi realizada;
um objeto da classe java.lang.reflect.Method, o qual reifica
o mtodo que est sendo chamado;
um vetor do tipo Object que contm os argumentos deste
mtodo.

47

Classes Proxy Dinmicas

<<interface>>
Service
service

implements

Client

references

DynamicProxyClass

ServiceImpl

service

service

references
<<interface>>
InvocationHandle
r
invoke(Object,
Method,
Object[])

implements

InvocationHandlerIm
pl

references

invoke(Object,
Method,
Object[])
48

Exemplo de Classe Proxy

class DebugHandler implements java.lang.reflect.InvocationHandler {
private Object base;
private DebugHandler(Object base) {
this.base = base;
}
public Object invoke(Object proxy, Method m, Object[] args)
throws Throwable {
Object result;
try {
System.out.prin
tln("before
// forward to base object
result = m.invoke(base, args);
method " +
} catch
(...) {
m.getName())
...
;
} finally {
System.out.println("after method " + m.getName());
}
return result;
}
} // class DebugHandler

49

Exemplo de Classe Proxy

Exemplo de Uso:

public interface Foo {

Object bar(Object obj) throws BazException;
}
public class FooImpl implements Foo {
Object bar(Object obj) throws BazException { ... }
}
.....
Foo base= new FooImpl();
DebugHandler handler= new DebugHandler(base);
Class c= base.getClass();
Foo proxy= Proxy.newProxyInstance(c.getClassLoader(),
c.getInterfaces(), handler);
.....
proxy.bar(....);

50

Outros Recursos de Sistemas

de
Middleware
Marco Tlio de Oliveira Valente

Sincronizao de Requisies

Normalmente, chamadas remotas so sncronas

Cliente fica bloqueado, esperando resultado da chamada remota

No entanto, dependendo da durao de uma chamada

remota, pode no ser interessante que o cliente fique
bloqueado

Chamadas oneway:
Controle retorna ao cliente quando middleware recebe
requisio
Despacho/execuo da chamada e execuo do cliente
ocorrem de forma assncrona
Somente podem ser aplicadas a mtodos com retorno void
No ativam uma exceo em caso de falha na execuo da
chamada remota; recomendadas quando o cliente no
necessita do resultado da chamada remota

52

Chamadas Assncronas

Primeira soluo: baseada em polling (tambm chamada

de deferred synchronous)
Quando cliente realiza uma chamada assncrona, a mesma
retorna um objeto de um tipo Future (ou Promises ou outro nome
similar)
Future x= s.f(....);

Cliente ento prossegue sua execuo

Middleware despacha a chamada de forma assncrona (em
uma thread independente). Quando o resultado chega, o
mesmo associado ao objeto do tipo Future.
Em um determinado momento, o cliente pode precisar do
resultado da chamada remota.
Para isso, basta realizar um polling no Future:
Object o= x.getResult();
53

Chamadas Assncronas

Segunda soluo: usando callback

Chamadas remotas possuem sempre um primeiro parmetro que
um objeto sobre o qual ser realizado o callback
Quando resultado estiver disponvel, chama-se mtodo
deste objeto
Interface provida pelo sistema:
interface Listener { void setResult (Object x); }

Interface criada pelo programador e implementada pelo obj.

remoto:
interface A { String f (int x); }

Interface gerada pelo sistema

interface A_Async extends A {void async_f(Listener x, int
y);}

Chamada Assncrona:
Async_A a= Naming.lookup(....);
Listener x= new MyListener();
a.async_f(x, 10);

54

Trader: Servio de Negociao

Servio de nome mais avanado existente em CORBA

Servios de nomes tradicionais funcionam como as pginas
brancas de uma lista telefnica
Requerem que clientes conheam previamente os nomes dos
objetos remotos que acessam (ou pelo menos do primeiro
objeto remoto acessado)
Este fato pode ser uma limitao importante, principalmente em
ambientes mais dinmicos
Trader: objeto remoto pesquisado com base em
suas propriedades, caractersticas, qualidade de
servio etc
Semelhante s pginas amarelas de uma lista
telefnica
Requer o uso de uma Trader Constraint Language
para consultas
Exemplo: (page_min > 5) and ((page_type=A4) or

55

CORBA Trader

Objetivo: maior independncia entre clientes e servidores

Clientes no precisam conhecer nomes de objetos remotos
No entanto, clientes ainda precisam conhecer:
o nome da interface dos objetos remotos
os nomes das propriedades dos objetos remotos
Reflexo pode ajudar a obter estas informaes, mas
cdigo reflexivo extenso, sujeito a erros etc
56

Coleta de Lixo Distribuda

Suponha as seguintes interfaces remotas:

interface Srv extends Remote { Msg getMsg(); }
interface Msg extends Remote { ... }

Suponha um servidor com um objeto remoto que

implementa Srv:
Msg getMsg() { return new MsgImpl(); }

Suponha ainda uma classe remota MsgImpl, que

implementa Msg
Cdigo do cliente:
void foo() {
Srv s= "referncia para objeto remoto que
implementa Srv"
Msg msg;
for (int i= 0; i<100; i++)
msg= s.getMsd();
// cria 100
objetos remotos no servidor
}

Quando estes objetos so destrudos?

57

Coleta de Lixo Distribuda

Em sistemas distribudos, o coletor de lixo necessita

remover aqueles objetos remotos que:
No so referenciados localmente (como usual)
E que tambm no so referenciados por clientes
localizados em
um espao de endereamento remoto

Java RMI usa um algoritmo de coleta de lixo distribuda baseado

na tcnica de contagem de referncias
Tcnica usada pela primeira vez em Modula-3 (Network Objects)
Idia bsica:
Objetos remotos possuem dois mtodos: dirty() e clean()
Objetos remotos possuem um contador de referncias externas
para os mesmos

58

Coleta de Lixo Distribuda

Cliente:
Ao instanciar um stub de um objeto remoto: chama obj.dirty()
Ao destruir um stub de um objeto remoto: chama obj.clean()
Servidor:
obj.dirty(): incrementa contador de referncias externas
obj.clean(): decrementa contador de referncias externas
Ncleo de RMI: deixa de referenciar obj quando contador == 0
Problemas: falhas no cliente ou na rede podem impedir o envio
de uma mensagem obj.clean()
Soluo: lease
Cliente reenvia object.dirty() de tempos em tempos
Servidor armazena no s um contador, mas tambm a
identificao de cada cliente que possui uma referncia para
ele
Servidor decrementa contador quando lease no renovado

59

Jini

Jim Waldo: The Jini Architecture for Network-Centric

Computing. CACM 42(7): 76-82 (1999)
Sistema para construo de aplicaes distribudas em
ambientes de computao mvel, ubqua, pervasiva etc
Redes sujeitas a constantes reconfiguraes, redes espontneas
Utiliza Java RMI como
infra-estrutura bsica de comunicao
Possui um servio de nomes
prprio, chamado lookup service
Utiliza um protocolo mais flexvel para registro, pesquisa e
remoo
de informaes do servio de nomes
Consultas ao servidor de nomes so realizadas usando
interfaces e/ou propriedades do servio que est sendo solicitado
Servidores e clientes no precisam conhecer previamente o
endereo do servidor de nomes da rede qual esto
conectados

60

Jini

Exemplo: conexo de um novo servio de impresso em uma

rede
Ao se conectar, servidor de impresso difunde uma
mensagem procurando pelo servidor de nomes
Clientes procurando por um servio de impresso tambm
localizam o servio de nomes difundindo uma mensagem
Comunicao entre cliente e servidor de impresso via RMI

61

Jini

Jini possibilita que novos servios possam ser acrescentados

transparentemente em um sistema distribudo, sem necessidade
de suporte por parte dos administradores do mesmo
Permite que servios possam ser tambm automaticamente
desconectados de uma rede
Para isso, associa-se a toda referncia de rede registrada
no servio de nomes um lease
Isto , um perodo de tempo durante o qual este registro
permanece vlido.
Servidores devem renovar o lease de um servio, caso
pretendam continuar disponibilizando o mesmo
Por outro lado, caso um servidor se desconecte da rede,
mesmo que de forma inesperada, seus servios
sero
automaticamente removidos do servio de nomes assim que
expire seu lease
Outros recursos de Jini: notificao de eventos e transaes

62

Servios Web

Marco Tlio de Oliveira Valente

Servios Web
Extenso e adaptao dos conceito de chamada remota
de mtodos para a Web
Informaes estruturadas, com interfaces bem definidas
Principais padres: HTTP, XML, SOAP, WSDL e UDDI
Exemplo: servio Web para obter cotao do dlar

Mensagens
SOAP + XML
dolar= getDolar();
HTTP

Servidor
Web

float getDolar() {
............
.............
}

Principal aplicao: integrao de

aplicaes
64

Servios Web

Servios Web so aplicaes distribudas que se comunicam por

meio de mensagens XML, formatadas e encapsuladas segundo
o protocolo SOAP e transportadas via HTTP.
Servios Web tm suas interfaces definidas em uma linguagem
denominada WSDL e so registrados em servidores UDDI
Para quem conhece 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 servio de nomes em CORBA
Simplificando, servios Web so semelhantes a CORBA,
porm usando protocolos da Web

65

Arquiteturas Orientadas por Servios

UDDI

SOAP

WSDL
Fonte: Web Services: Concepts, Architecture and Applications. Gustavo Alonso,
Fabio Casati, Harumi Kuno, Vijay Machiraju. Springer Verlag, 2004

66

SOAP

SOAP: Simple Object Access Protocol

Protocolo W3C para troca de informaes na Internet
Utiliza XML para codificao de mensagens e HTTP para
transporte
de mensagens de um nodo a outro
Permite adicionar servios a um servidor Web e ento
acessar estes servios a partir de programas comuns
Servios: objetos, com mtodos chamados remotamente
SOAP especifica como representar em XML todas
informaes
necessrias para se executar uma chamada remota
Define o formato da mensagem de ida (com os
argumentos)
Define o formato da mensagem de volta (com o resultado)
Independente de linguagem de programao

67

SOAP: Mensagens
Suponha a seguinte implementao de um servio Web:

String sayHello(String name) {

return "Hello, " + name;
}

Quando um cliente invocar o mtodo acima, passando Bob

como parmetro, ser gerado e transmitido o seguinte envelope
SOAP:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="htt
p://schemas.xmlsoap.
org/soap/envelope/"
xmlns:xsd="http://ww
w.w3.org/1999/XMLSch
ema">
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:sayHello
xmlns:ns1="Hello"
SOAPNV:encodingStyle

68

SOAP: Arquitetura

69

Fonte: Paulo Pires e Marta Matoso. Tecnologia de Servios Web. Mini-curso SBES 2005.

WSDL

WSDL: Web Service Description Language

Linguagem para descrever a localizao e a interface de um
servio
Web, isto :
Nome e URL do servio (binding information)
Assinatura dos mtodos disponveis para chamada
remota (abstract interface)
Semelhante a IDL em CORBA, porm com uma sintaxe
baseada
em XML
Existem ferramentas que geram especificaes WSDL a partir,
por exemplo, de interfaces Java

70

Exemplo de Arquivo WSDL

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="urn:hello"
......
<wsdl:message name="sayHelloResponse">
<wsdl:part name="sayHelloReturn" type="xsd:string"/>
</wsdl:message>
<wsdl:message name="sayHelloRequest">
<wsdl:part name="in0" type="xsd:string"/>
</wsdl:message>
<wsdl:portType name="HelloServer">
<wsdl:operation name="sayHello" parameterOrder="in0">
<wsdl:input message="intf:sayHelloRequest" name="sayHelloRequest"/>
<wsdl:output message="intf:sayHelloResponse" name="sayHelloResponse"/>
</wsdl:operation>
</wsdl:portType>
..........
</wsdl:binding>
<wsdl:service name="HelloServerService">
<wsdl:port binding="intf:rpcrouterSoapBinding" name="rpcrouter">
<wsdlsoap:address location="http://localhost8080/soap/servlet/rpcrouter"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
71

UDDI

UDDI: Universal Description, Discovery and Integration

Especificao em WSDL: permite a um cliente obter todas as
informaes para interagir com um servio Web
Mas com obter obter informaes sobre um servio Web ?
Resposta clssica: junto a um servidor de nomes
UDDI: conjunto de especificaes para:
Registrar um servio Web
Pesquisar por servio Web, via interface Web ou SOAP
Pesquisas por um servio podem ser realizadas em:
Pginas brancas: contm nome e informaes de contato
Pginas amarelas: servios organizados em categorias
Permite a criao de uma hierarquia de servidores UDDI

72

SOA vs DOA

Comparing Service-Oriented and Distributed Object

Architectures. Sen Baker and Simon Dobson. DOA 2005
DOA: Distributed Object Architectures (CORBA, RMI etc)
Bastante estvel
Integrao de sistemas de informao corporativos
SOA: Service Oriented Architectures (Web Services)
Extenso de DOA para alm das fronteiras de uma
corporao
Integrao de sistemas fracamente acoplados
Tecnologicamente mais neutro do que CORBA
Questes que sempre surgem?
SOA uma reinveno de DOA?
SOA uma readaptao de DOA para HTTP/XML?
Principais semelhanas:
Servios = objetos,
WSDL = IDL, SOAP = IIOP

73

SOA vs DOA: Diferenas

Granularidade:
Interfaces DOA possuem um menor nvel de
granularidade
Exemplo: agncia de viagem

74

SOA vs DOA: Diferenas

Em DOA:
Interfaces remotas usam tipos Itinerrio, Reserva, Cliente
etc

void createCustomer(Customer)
(interface Cliente)
Exemplos
de mtodos:

void addItinerary(Itinerary)
float getCost()

(interface Booking)
(interface Booking)

Em SOA:
Mtodos so agrupados em uma nica interface
(TravelAgencyService)

Exemplos de mtodos:

int createCustomer(String, String, String)

void addItineraryToBooking(int, int)
float getCost(int)

Em SOA, tipos Itinerrio, Reserva, Cliente etc podem existir

internamente, mas no so expostos nas interfaces
remotas
Modelo de objetos interno de SOA pode ser idntico ao de

75

SOA vs DOA: Diferenas

SOA: interfaces seguem uma perspectiva de negcio

Um agente de turismo uma entidade que merece uma
interface
O mesmo no ocorre com Itinerrios, Reservas etc

DOA: interfaces seguem uma perspectiva de sistemas

Logo, Itinerrios, Reservas, Clientes etc so
entidades relevantes do domnio que est sendo
modelado
Merecem ser expostos nas interfaces como objetos

76

SOA vs DOA: Diferenas

There are significant advantages to the SOA view. It reduces the

surface area of interfaces, and hence the learning curve for
client programmers. It also tends to produce interfaces that
perform operations in fewer interactions.

The DOA view may lead to interactions that are too chatty, in the
sense of requiring a number of interactions to accomplish the
same effect. In many systems this will increase the number of
network operations to accomplish a single business level task,
reducing system throughput.

77

BPEL

Business Process Execution Language (BPEL)

Desenvolvida pela IBM, Microsoft, BEA, SAP etc
Linguagem baseada em XML usada para descrever (ou
orquestrar)
o fluxo de execuo de um processo de um negcio
Exemplo: habilitao de um terminal telefnico
Verificar se usurio tem o nome limpo (sistema de crdito)
Verificar se h disponibilidade fsica para instalao do ramal
telefnico (sistema de engenharia)
Cadastrar usurio (sistema de cobrana)
Cadastrar terminal (sistema de engenharia)
BPEL poderia ser usada para modelar o fluxo de um processo
de
negcio como o descrito acima
Sistemas devem possuir interfaces de comunicao baseadas
em servios Web

78

BPEL: Exemplo 1

79

BPEL: Exemplo 2

Processo que:
Dada uma string, realiza uma consulta ao Google
Para cada item da resposta, retorna as pginas armazenadas
no
cache do Google (para isso, volta a consultar o Google)

<variables>
<variable name="search" messageType="goo:doGoogleSearch"/>
<variable name="searchResponse"
messageType="goo:doGoogleSearchResponse"/>
<variable name="cache"
messageType="goo:doGetCachedPage"/>
name="i" type="xsi:int"/>
<variable
<variable name="cacheResponse"
name="query" type="xsi:string"/>
<variable
messageType="goo:doGetCachedPageResponse"/>
<variable name="itemNb" type="xsi:int"/>
</variables>

80

BPEL: Exemplo 2
<sequence>
<assign>
<copy>
<from>
<search>
<key>0123456789
</key>
<q>ucl computer
science</q>
<start>1</start
>
<maxResults>5</
maxResults>
<filter>true</f
ilter>
<restrict/>
<safeSearch>tru
e</safeSearch>
<lr/>
<ie>latin1</ie>
</assign><oe>latin1</oe>
</search>

81

BPEL: Exemplo 2
<invoke partnerLink="goo:GoogleSearchService"
portType="goo:GoogleSearchPort"
operation="goo:doGoogleSearch"
inputVariable="search"
outputVariable="searchResponse"/>
<assign>
<copy>
<from expression="1"/>
<to variable="i"/>
</copy>
<copy>
<from variable="searchResponse" part="return"
query="count(/return/resultElements/item)"/>
<to variable="itemNb"/>
</copy>
<copy>
<from variable="search" part="key"/>
<to variable="cache" part="key"/>
</copy>
</assign>

82

BPEL: Exemplo 2
<while condition="bpws:getVariableData(i) &lt;=
bpws:getVariableData(itemNb)">
<sequence>
<assign>
<copy>
<from expression="concat(
/return/resultElements/item[,
bpws:getVariableData(i), ]/URL)"/>
<to variable="cache" part="url"/>
</copy>
<copy>
<from
expression=
"bpws:getVa
riableData(
i)+1"/>
<to
variable="i
"/>
</copy>
</assign>

</sequence>
<invoke partnerLink="goo:GoogleSearchService"
portType="goo:GoogleSearchPort operation="goo:doGetCachedPage"

83

Ferramentas para Programao

com BPEL

84

Outros Paradigmas para

Computao Distribuda
(diferentes Cliente/Servidor)
Marco Tlio de Oliveira Valente

Espaos de Tuplas e Linda

Marco Tlio de Oliveira Valente

Espaos de Tuplas e Linda

Linda: modelo de coordenao baseado na idia de espao

de tuplas (David Gelernter, 1985)
Diversas implementaes: TSpaces (IBM), JavaSpaces,
LightTS etc
Modelo de coordenao: comunicao e sincronizao
de processos distribudos
Espao de tuplas
Memria compartilhada, persistente, associativa e
global
Processos distribudos podem inserir, ler e retirar
tuplas desta
memria
Tupla: sequncia ordenada de valores
Exemplos de tuplas:

( "Joo", "Rua Cinco", 125 )

( "Joo", "pisd" ) (
"Maria", "pisd" )

87

Operaes sobre Espao de Tuplas

Trs operaes bsicas

out t: deposita uma tupla t no espao
in p: retira uma tupla do espao que "case" com o padro p; se
no existir, fica bloqueado at que exista
rd p: l (sem retirar) uma tupla do espao que que "case" com
o padro p;
se no existir, fica bloqueado at que exista
No caso de in e rd, se existir mais de uma tupla que case com o
padro, uma delas no-deterministicamente escolhida
Operaes so atmicas e podem ser chamadas remotamente
Existem ainda operaes do tipo "probe":
inp p: retira uma tupla do espao que "case" com o padro p e
retorna true; se no existir, retorna FALSE
rdp p: l (sem retirar) uma tupla do espao que que "case"
com o padro p e retorna true; se no existir, retorna false

88

Casamento de Padres

Se x um varivel do tipo t, ?x casa com qualquer valor do tipo t

Exemplo 1:
int i;
out(1, 2, "xyz")
rd(?i, 2, "xyz) bem sucedido (i= 1)

Exemplo 2:
int i, j;
out(1, 2, "xyz")

rd(?i, ?j, "xyz) bem sucedido (i= 1 e j= 2)

Exemplo 3:

int i, j; string s;
out(1, 2, "xyz")
rd(?i, ?j, ?s) bem sucedido (i= 1, j= 2, s= xyz)

89

Casamento de Padres

Exemplo 4:
int i, j=2; string s;
out(1, 2, "xyz")
rd(?i, j, ?s) bem
sucedido (i=

Exemplo 5:

int i, j=3; string s;

out(1, 2, "xyz")
rd(?i, j, ?s) no
bem sucedido
Exemplo
6:

1, s= xyz)

(e permanece suspenso)

int i, j;
out(1, 2, "xyz")
rd (?i, ?j, "abc) no bem sucedido

Exemplo 7:
out("string", 10.1, 21, "another string")
real f; int i;
rd("string", ?f, ?i, "another string") bem sucedido (f=10.1 e i=21)
in("string", ?f, ?i, "another string") bem sucedido (f=10.1 e i=21)
90
rd("string", ?f, ?i, "another string") permance suspenso

Espao de Tuplas

Espao de Tuplas uma memria:

Compartilhada: por diversos processos distribudos
Persistente
Global: um espao uitlizado por diversos processos
Associativa: valores armazenados na memria (tuplas) so
recuperados (operaes in e rd) usando-se padres (e no
por meio de endereos, como ocorre em uma memria
tradicional).
Linda foi originalmente proposto para implementao de sistemas
paralelos
Periodicamente, interesse por Linda renovado
Razo: modelo de programao assncrono e desacoplado de
Linda interessante em redes abertas, reconfigurveis etc
91

Jantar dos Filsofos

process phil(i: 0 to n-1) { // cria n processos
int i;
while(true) {
think();
in("fork", i);
in("fork", (i+1)%n);
eat();
out("fork", i);
out("fork", (i+1)%n);
}
}
process main() {
int i;
for (i=0, i<n, i++)
out("fork", i);
}
92

Chat

Tupla que identifica a prxima mensagem

out("nextmsg", 0)

// identificador da prxima mensagem

Para enviar uma mensagem s:

int i;
in("nextmsg", ?i);
i++;
out("nextmsg", i);
out("msg", i, s);

Para receber uma

mensagem s:
i= 1;
while(true) {
rd("msg", i, ?
s); print s; i+
+;
}

Deve existir ainda

um processo

93

RPC/RMI

Suponha um servidor com mtodos soma(x,y) e

mult(x,y)
Chamada remota realizada por um cliente c1:
int r;
out(c1,soma,2,3)
in(c1,somares,?
r);
int c,x,y,r; string m;
while(true) {
Servidor:
in(?c,?m,?x,?y)
if (m == soma) r= soma(x,y);
if (m ==
r= mult(x,y);
mult)
out(c,m+res,r)

E se os mtodos tivessem nmero e tipo de parmetros

diferentes
Vantagens: transparncia de localizao, mltiplos
servidores (tolerncia falhas e balanceamento de carga),
comunicao multicast, chamadas assncronas etc

94

Sistema de Leiles

Vendedor coloca um produto venda:

out(pda, palm, lifedrive, 1500, id)

Comprador interessado em saber se existe um palm venda:

rdp(pda, palm, ?modelo, ?preco, ?id)

Comprador interessado em saber se existe um palm venda ou em

ser notificado quando um palm for colocado venda :
rd(pda, palm, ?modelo, ?preco, ?id)

Existem implementaes de Linda que possuem operaes que

recuperam todas as tuplas que so compatveis com um padro
til quando o comprador quer conhecer todos os palms venda
Existem ainda implementaes que possuem estratgias de
casamento de padres mais sofisticadas.
Exemplo: rdp(pda, palm, ?modelo, ?preco < 1000, ?id)

95

Linda: Caractersticas Interessantes

Comunicao em Linda distribuda no espao e no tempo.

Distribuda no tempo porque um processo produtor pode
inserir uma mensagem no espao persistente, a qual somente
ser recuperada mais tarde por um processo consumidor. Assim,
no necessria a existncia de uma conexo temporal entre
processos para que eles possam interagir.
J distribuio no espao possvel graas ao fato de que tuplas
depositadas no repositrio compartilhado so visveis aos diversos
nodos de um sistema distribudo. Alm disso, graas ao uso de
padres para ler e remover tuplas, processos no precisam
conhecer mutuamente seus identificadores para trocar
mensagens. Por exemplo, processos consumidores so capazes
de remover mensagens baseados no contedo das mesmas, sem
que necessariamente tenham conhecimento da identidade dos
processos produtores.
96

Mestre/Escravos

97

Nmeros Primos
Process main(int argc, char *argv[]) {
int primes[LIMIT] = {2,3}; /* my table of primes */
int limit, i, isprime;
int numPrimes = 2, value = 5;
limit = atoi(argv[1]);
/* number of primes to
generate */
/* put first candidate in bag */
OUT("candidate", value);
/* get results from workers in increasing order */
while (numPrimes < limit) {
IN("result", value, ?isprime);
if (isprime) { /* put value in table and TS */
primes[numPrimes] = value;
numPrimes++;
OUT("prime", numPrimes, value);
}
value= value + 2;
}
/* tell workers to quit, then print the primes */
OUT("stop");
for (i = 0; i < limit; i++) printf("%d\n", primes[i]);

98

Nmeros Primos
process worker(1 to numWorkers) { // create numWorkers processes
int primes[LIMIT] = {2,3}; /* table of primes */
int numPrimes = 1, i, candidate, isprime;
/* repeatedly get candidates and check them */
while(true) {
if (RDP("stop")) /* check for termination */
return;
IN("candidate", ?candidate);
/* get candidate */
OUT("candidate", candidate+2);
/* output next one */
i = 0; isprime = 1;
while (primes[i]*primes[i] <= candidate) {
if (candidate%primes[i] == 0) /* not prime */
{ isprime = 0; break; }
i++;
if (i > numPrimes) /* need another prime */
{ numPrimes++; RD("prime", numPrimes, ?primes[numPrimes]); }
}
/* tell manager the result */
OUT("result", candidate, isprime);
}
99
}

Caractersticas Interessantes

Comunicao "desacoplada no tempo

Produtor e consumidor de mensagens no precisam estar
temporalmente conectados para que ocorra uma comunicao
No se precisa estabelecer uma "conexo" para que
processos possam se comunicar
Importante, por exemplo, em sistemas para computao mvel
Comunicao "desacoplada no espao
Cliente no precisa conhecer localizao do servidor (e viceversa)
Comunicao baseada em "casamento de padres" dispensa
o uso de endereos fsicos para identificar mensagens
Tuplas no so recuperadas com base em "endereos
de destino", mas no contedo das mesmas
Facilita estratgias de tolerncia a falhas, balanceamento
de carga, replicao etc
100

Caractersticas Interessantes

Comunicao unicast e multicast

Unicast: "recepo" usando in
Multicast: "recepo" usando rd
Sincronizao inerente ao modelo
in e rd possuem uma semntica de bloqueio
"Consumidor" fica bloqueado se tentar consumir uma
mensagem que ainda no foi gerada por um "produtor
Modelo de comunicao generativo (generative)
Para se comunicar, processos no trocam mensagens (no
sentido tradicional, via canais) nem compartilham
variveis
Em vez, mensagens so geradas, depositadas e
recuperadas de
um espao de tuplas
101

Sistemas Publish/Subscribe

Sistemas Publish/Subscribe

Eugster, Felber, Guerraoui, Kermarrec: The many faces of

publish/subscribe. ACM Computing Surveys 35(2): 114-131 (2003)
Motivao: modelo de comunicao ponto-a-ponto e sncrono de
sistemas baseados em RPC por demais rgido e esttico
quando aplicado em sistemas distribudos de larga escala
(Internet) ou dinmicos (redes mveis)
Nestes ambientes, modelos de comunicao fracamente
acoplados
so mais interessantes
Sistemas Publish/Subscribe:
Assinantes manifestam interesse em um determinado evento
ou em um conjunto de eventos
Produtores publicam eventos
Eventos so assincronamente publicados para seus assinantes
103

Sistemas Publish/Subscribe

Servio de eventos:
Mediador entre produtores e assinantes
Gerencia e armazena assinaturas
Despacha eventos para respectivos assinantes
Incluso e remoo de produtores e assinantes simples
Oferecem desacoplamento no espao, no tempo e de
sincronizao

104

Desacoplamento

Desacoplamento no espao:
Produtores no conhecem assinantes (e vice-versa)
Produtores no tem referncias para assinantes (e vice-versa)
Participantes no se conhecem mutuamente
Desacoplamento no tempo:
Produtor pode gerar evento quando assinante desconectado
Assinante pode receber evento quando produtor desconectado
No necessrio estabelecer uma conexo entre participantes
Desacoplamento de sincronizao:
Produo/consumo no acontece no fluxo principal de
execuo
Produtores no ficam bloqueados enquanto evento enviado
Assinantes so notificados assincronamento (via um callback)
Importncia em sistemas de larga escala e dinmicos:
remover amarras ou ligaes entre participantes
105

Desacoplamento

106

Alternativas

Troca de mensagens
RPC
Espaos de Tuplas
Filas de Mensagens

107

Troca de Mensagens

Forma de comunicao de mais baixo nvel

Duas primitivas: send (assncrono) e receive (sncrono)
Exemplo: sockets
Hoje, raramente utilizada pois torna visvel camada de aplicao:
Marshalling/unmarshalling, falhas, retransmisses etc
No prov desacoplamento no tempo e no espao

108

RPC e derivados

Torna programao distribuda muito fcil (MT: exagero ??)

No prov desacoplamento no tempo
No prov desacoplamento no espao (clientes devem possuir uma
referncia para servidores)
Produtor: emite reply

Legenda, no entanto,
continua parecendo
errada

Nota de rodap: the distinction of consumer/producer roles is not straightforward in

RPC. We assume here that an RPC which yields a reply attributes a consumer role to
the invoker, while the invokee acts as producer. As we will point out, the roles are
109
inversed with asynchronous invocations (no reply).

RPC e derivados

Tentativas de diminuir desacoplamento de sincronizao:

Chamadas one-way e chamadas assncronas
Como no h reply,
Neste caso, o servidor
o consumidor

Como h reply, o
servidor o produtor

Legenda, no entanto,
continua parecendo
errada
110

Espaos de Tuplas

Prov desacoplamento no tempo e no espao

Desvantagem: consumidores retiram tuplas de forma sncrona, o
que limita escalabilidade de clientes (MT: basta usar inp ou usar in
em uma thread independente)

111

Fila de Messagens

Sistemas de middleware orientados por mensagens (MOM)

Exemplos: JMS, IBM MQSeries, Oracle AQ, BEA Tuxedo
Desvantagem: consumidores so sncronos, isto , no
prov
desacoplamento de sincronizao

112

Resumo

Caracterstica distintiva de P/S:

Desacoplamento no espao
Desacoplamento no tempo
Desacoplamento de
sincronizao
113

Sistemas Publish/Subscribe

Esquemas de assinatura de eventos:

Baseada em Tpicos
Baseada em Contedo
Baseada em Tipo

114

Assinatura baseada em Tpicos

Eventos publicados e assinados so identificados por tpicos

Tpico: conjunto de palavras chave, normalmente hierarquizadas
Cliente assina eventos sobre um tpico especificamente
Exemplos: LondonStockMarket/Stock/StockQuotes

115

Assinatura baseada em Contedo

Esquema de assinatura mais flexvel e dinmico, baseado

no contedo real dos eventos gerados
Assinantes selecionam eventos usando filtros especificados
em uma linguagem de assinatura

116

Assinatura baseada em Tipo

Assinante manifesta interesse em eventos do tipo t

implementando mtodo notify que espera como parmetro um
objeto deste tipo

interface Subscriber<S> {
notify(S s);
}

117

Mobilidade de Cdigo e
Agentes Mveis

Mobilidade de Cdigo

Estilo mais difundido de mobilidade

Tambm chamado de mobilidade fraca
Mobilidade de cdigo: designa programas capazes de trafegar
por uma rede heterognea, cruzando diferentes domnios
administrativos, e que so automaticamente executados ao
atingirem uma estao de destino
Mobilidade apenas do cdigo da aplicao (fonte ou
intermedirio)
No um conceito novo: linguagem Postscript (Adobe, 1985)
Vantagens de mobilidade de cdigo:
Viabiliza a execuo na diversidade de arquiteturas da Internet
Viabiliza a construo de aplicaes Internet interativas
Simplifica a administrao e manuteno de redes
119

Mobilidade de Agentes

Agente:
Programa que realiza uma tarefa para a qual recebeu
delegao
por parte de um usurio
Usados em Robtica, Inteligncia Artificial, Bancos de
Dados, Recuperao de Informao etc
Agente Mvel:
Agente cuja execuo no se restringe a uma nica mquina
Programa que autonomamente se desloca pelas diversas
mquinas de uma rede a fim de melhor realizar a tarefa que
lhe foi delegada.
Mobilidade: cdigo + dados + controle
Mobilidade de estado ou mobilidade de cdigo forte
Agentes mveis: modelo alternativo para construo de
aplicaes
distribudas
napara
Internet
Idia: mover
computao
junto de seus

dados

120

Modelos de Aplicaes Distribudas

Principais modelos para implementao de aplicaes

distribudas:
Modelo Cliente/Servidor
Avaliao Remota
Agentes Mveis
Avaliao Remota (REV):
Generalizao do modelo de RPC, permitindo a passagem
de procedimentos como parmetros
Exemplo de REV:
float integral (float (*fun)(float), float inferior, float
superior)

Principais vantagens de REV:

Flexibilidade: no fixa conjunto de servios que podem ser
invocados remotamente
Reduo do montante de comunicao: envia-se o
programa para junto dos dados que ir manipular

121

RPC x REV x Agentes Mveis

parmetros (dados)

RPC

Cliente

Servidor
resultado (dados)

procedimento (cdigo)

REV

Cliente

Servidor
resultado (dados)

Agentes
Mveis

Nodo
Origem

agente (cdigo + dados)

agente

agente
agente
Nodo n

Nodo 1

Nodo 2
122

Vantagens de Agentes Mveis

Principais vantagens:
Reduo de trfego na rede
Eliminao da latncia da rede
Aplicaes que podem se beneficiar do modelo de agentes mveis:
Comrcio eletrnico, gerncia de redes de telecomunicaes,
aplicaes de workflow e groupware, recuperao de
informao

Cliente

Servidor

Cliente

Servidor
Agente

Modelo
Cliente/Servidor

Modelo de Agentes
Mveis

123

Linguagens com Suporte a

Mobilidade de Agentes

Principais linguagens com suporte a mobilidade de

agentes:
Obliq
Telescript
Linguagens baseadas em Java:
Aglets
Voyager
JavaSeal
etc

124

Dynamically
and Reconfigurable
Programmable
Middleware
Services
Manuel Romn, Nayeem Islam
Middleware Conference, 2004

Introduo

Manuel Romn, Nayeem Islam: Dynamically Programmable and

Reconfigurable Middleware Services. Middleware 2004: 372396
Desenvolvido no NTT DoCoMo Labs (USA)
Middleware para telefones celulares deve atender aos
requisitos:
Configurao esttica e dinmica: cliente ou cliente/servidor,
com ou sem interceptadores, protocolo (IIOP, SOAP etc) etc
Correo dinmica (updateability): 10% dos celulares
possuem
erros de software que implicam em retorno aos fabricantes
Atualizao dinmica: novas funcionalidades,
protocolos, interfaces etc
Proposta: infra-estrutura de middleware para celular que
permite:
Corrigir, configurar e atualizar o comportamento do sistema de

126

Introduo

Baseado em uma tcnica chamada de externalizao

Idia: externalizar o estado, a lgica e a estrutura de
componentes
internos do middleware
Externalizar: tornar visvel e sujeito a inspeo e modificao
Objetivo: permitir que desenvolvedores (e pessoal de
suporte) possuam controle sobre servios providos pelo
middleware
Externalizao:
Estrutura: componentes que compem o middleware
Lgica: regras de interao entre componentes
Estado: atributos internos do middleware

Structure

Logic

State
127

DPRS

Dynamically Programmable and Reconfigurable

Middleware Services
Arquitetura para construo de sistemas de middleware
com suporte a externalizao
Vantagens:
Configurability
Updateability
Upgrateability
Trs abstraes principais:
Micro Building Blocks (MBBs)
Ao
Domnio

128

MBB

Menor unidade funcional do sistema (componente

mnimo)
Em DPRS, um middleware formado por um conjunto de MBBs
MBB:
Recebe um conjunto de parmetros de entrada
Executa uma ao (que pode atualizar seu estado)
Produz um conjunto de parmetros de sada
Exemplo: registerObject
Entrada: nome do objeto e referncia de rede para o mesmo
Ao: atualizar tabela interna de objetos registrados
Sada: void

129

MBB

Entrada, estado e sada: tuplas na forma (nome,

valor)
Estado armazenado em uma rea gerenciada pelo sistema
Facilita troca do MBB, j que no necessrio transferir
estado
MBBs no possuem referncias para outros MBBs

130

Ao

Especifica a ordem de execuo dos MBBs (lgica do sistema)

Pode ser interpretada ou compilada
Ao interpretada: grafo
Nodos so MBBs e arestas definem o fluxo de execuo
Arestas podem possuir uma condio usada para determinar
o prximo MBB a ser executado
Artigo no mostra como grafo definido (funo de transio etc)
Programadores podem modificar o grafo em tempo de execuo

131

Ao Compilada

Uma ao compilada um fragmento de cdigo que especifica

a ordem de invocao de MBBs

Artigo no define linguagem usada para descrever o cdigo da

ao
Cdigo pode chamar mtodos da biblioteca do sistema
Ao compilada: execuo mais rpida que a ao interpretada
Porm, ao contrrio da ao interpretada, no permite inspeo e
modificao em tempo de execuo (menos flexvel)
Modificaes
cdigo
da ao
naeordem
recompilao
de execuo requerem modificaes no 132

Domnio

Coleo de MBBs + memria de estado + coleo de

aes
Especificado via um descritor de arquitetura
Domnios podem ser hierarquicamente organizados

133

Run-time

MBB Scheduler: controla execuo do sistema (percorre o grafo

de execuo, avalia condies e chama MBBs)
MBB Scheduler pode ser substitudo/configurado pelo usurio
(real- time, tolerncia a falhas, concorrncia etc)
MBB Scheduler externaliza as seguintes informaes:
Ao que est sendo executada
MBB que est sendo executado (bem como seus parmetros)
134

Run-time

MBB Manager: mdulo responsvel pela insero, remoo

e substituio de MBBs
Pontos de reconfigurao: pontos onde possvel reconfigurar
o sistema de forma segura e consistente
Principal contribuio do modelo de execuo de DPRS: pontos
de reconfigurao podem ser determinados automaticamente
Em DPRS, pontos de reconfigurao ocorrem entre invocaes de
MBBs

135

Exemplo de Uso e
Avaliao

136

ExORB

Middleware construdo seguindo a arquitetura DPRS:

Funcionalidade cliente ou cliente/servidor
Protocolos de middleware: IIOP ou XML-RPC
28 MBBs, pertencentes a 11 domnios, ocupando ao todo 70 KB

137

ExORB: Domnios
1.

2.

3.
4.
5.
6.

7.
8.
9.
10.
11.

Gerenciamento de parmetros no formato CDR: marshal e

unmarshall em CDR (padro CORBA de representao de
dados)
Gerenciamento de parmetros XML-RPC:
idem, mas XMLRPC
Codificao e decodificao de mensagens IIOP
Codificao e decodificao de mensagens XML-RPC
Envio e recebimento de dados pela rede
Invocao de objetos: preparao e invocao de mtodos
remotos
Recebimento de Conexes TCP
Estabelecimento de Conexes TCP
Registro de objetos remotos
Identificao do protocolo de middleware (IIOP ou XMLRPC)
Gerenciamento de URIs: dada a URI de um objeto, retorna
identificao do mesmo

138

ExORB: Avaliao Quantitativa

Servidor: mtodo que calcula o cubo de um dado inteiro

Cliente: chama servidor 10 mil vezes
Chamadas/segundo foram medidas para:
1.
Configurao esttica : implementao no baseada em
MBBs
2.
Verso no otimizada de ExORB
3.
Verso de ExORB com aes compiladas
4.
Verso de ExORB com aes interpretadas e com a
memria consistindo de tuplas na forma (inteiro, valor), isto ,
variveis so ndices de um vetor e no mais strings usadas
como chaves de uma tabela hash
5.
Verso de ExORB com aes compiladas e ndices

139

ExORB: Avaliao Quantitativa

Diferena entre aes compiladas vs interpretadas no

grande
Otimizaes introduzem algum ganho de desempenho

140

ExORB: Avaliao Qualitativa

Configurability:
Verso com apenas funcionalidade cliente e XML-RPC (43 KB)
Verso foi gerada modificando o descritor de arquitetura

141

ExORB: Avaliao Qualitativa

Updateability:
MBBs e aes podem ser modificados pelo MBB Manager
Experimento realizado: alterao da ao para primeiro realizar
o
marshalling dos parmetros e depois conectar com objeto
remoto

142

ExORB: Avaliao Qualitativa

Upgradeability:
Criptografia de mensagens (novos MBBs para criptografar e
descriptografar mensagens; nova verso da ao para
chamar estes MBBs)

143