Arcademis: um Arcabouço para o
Desenvolvimento de Middleware
Fernando Magno Quintão Pereira
Orientador: Roberto S Bigonha
Co-orientador: Marco Túlio O Valente

LLP
Estrutura da Apresentação
• Objetivos
• Revisão da literatura
• Arquitetura de Arcademis
• RME
• Avaliação

LLP
Objetivos da Dissertação
• Projetar e implementar um arcabouço voltado para o
desenvolvimento de plataformas de middleware.
– Plataformas de middleware específicas, que disponibilizam
às aplicações conjuntos mínimos de funcionalidades.
• Separar os diversos aspectos que constituem as
plataformas de middleware baseadas em objetos
distribuídos, especificando quais características são
comuns a todos os sistemas e quais admitem
variações.

LLP
• Desenvolver um serviço de invocação remota de
métodos para o perfil CLDC da plataforma J2ME.
Revisão da Literatura
Arcabouços de desenvolvimento de software
Plataformas de Middleware
Quarterware
Padrões de projeto

LLP
Arcabouços para o Desenvolvimento de
Software.
• Arcabouços, ou frameworks, são uma técnica de
reúso de código e de projeto.
• Arcabouços são constituídos por um conjunto de
componentes, concretos e abstratos, que se
relacionam de forma a compor o esqueleto de uma
aplicação[Jonhson 97].

LLP
Tipos de Arcabouços
• Existem dois tipos de arcabouços:
– Sistemas do tipo caixa-branca:
• São formados por componentes abstratos que o desenvolvedor
deve estender.
• Possibilitam maior flexibilidade.
• Demandam maior conhecimento dos componentes utilizados.
– Sistemas do tipo caixa-preta:
• São constituídos por componentes concretos que podem ser
combinados pelo desenvolvedor de aplicações sem qualquer
modificação.
• Não demandam grande conhecimento sobre os componentes
utilizados.
• Apresentam menor flexibilidade que os sistemas caixa-branca.

LLP
• Arcademis apresenta características de ambos.
Plataformas de Middleware
• Camada de software interposta entre o sistema
operacional e as aplicações distribuídas.
• Fornece aos desenvolvedores de aplicações uma
interface de programação de mais alto nível que as
primitivas de comunicação dos sistemas operacionais.
• Exemplos: CORBA, Linda, Java RMI, PeerSpaces.

LLP
Aplicação
Livraria Virtual
Middleware
J2EE
Sistema Operacional
Unix
Plataformas de Middleware Orientadas
por Objetos
• Objetos distribuídos vistos pelo desenvolvedor como
se localizados no mesmo espaço de endereçamento.
• Invocação remota de métodos.
• Exemplos: CORBA, Java RMI, .NET.
Host S
X
A
B

LLP
C
Y
Host T
Comunicação entre Objetos Distribuídos
• Objetos se comunicam via representantes locais:
stubs e skeletons.
Objeto
Cliente
Stub {
m1();
}

LLP
Host S
RemObj {
m1();
}
Skeleton
Host T
Sistemas de Middleware configuráveis
• Podem ser configurados para melhor lidar com
características específicas do ambiente de execução.
• Plataforma de middleware fornece às aplicações
distribuídas somente as funcionalidades de que elas
necessitam.
• Exemplos:
– configuração estática: TAO;
– configuração dinâmica: DynamicTAO, UIC CORBA,
OpenCOM, LegORB.

LLP
• Configuração dinâmica baseada em reflexividade,
implementada por meio de metaobjetos.
Problemas com Configuração Dinâmica
• Sistemas que podem ser dinamicamente
configurados são grandes e complexos.
– Monitoramento do estado interno de cada componente:
demanda capacidade de processamento e torna mais lento
o sistema.
– Dependências entre objetos: reconfiguração pode levar a
estados inconsistentes.
– Metaobjetos ocupam espaço: bibliotecas grandes.
• Exemplo:
– LegORB configurado estaticamente: 22.5KB

LLP
– LegORB configurado dinamicamente: 141.5KB
Quarterware
• Quarterware é um arcabouço para o desenvolvimento
de middleware implementado em C++.
• 6 Parâmetros de configuração.
– Estratégia de serialização.
– Manipulação de referências remotas.
– Protocolo de transporte de dados.
– Protocolo de comunicação.
– Política de invocação e despacho de chamadas remotas.
– Política de processamento de chamadas remotas.

LLP
Quarterware
• Sistema mais flexível que plataformas de middleware
configuráveis, como TAO ou DynamicTAO.
• Exemplos de uso de Quarterware:
– implementação de CORBA;
– implementação de Java RMI;
– implementação de MPI (Message Passing Interface);
• Diferenças em relação a Arcademis.
– Parâmetros de configuração: Arcademis apresenta maior
número de opções de configuração.
– Implementação em C++.

LLP
Padrões de Projeto
• Um padrão de projeto é um tratado que descreve
uma família de problemas relacionados e uma
solução comum para todos eles.
• Arcademis utiliza diversos padrões de projeto:

LLP
– fábricas de objetos;
– flyweights;
– singletons;
– estratégias;
– objetos decoradores;
– objetos ativos (TAO);
– objetos adaptadores;
– conectores/receptores (TAO);
– proxies;
– reactor(TAO);
– fachadas;
– requisição/resposta;
Motivação
• A generalidade das plataformas tradicionais
compromete a sua flexibilidade.
– Desenvolvedores de middleware × desenvolvedores de
aplicações distribuídas.
– Plataformas muito gerais são grandes e complexas.
• Sistemas de middleware tradicionais são monolíticos:
– implementações de CORBA como ORBIX ou VisiBroker
ocupam dezenas de megabytes de memória e não podem
ser utilizadas em dispositivos dotados de poucos recursos.
• Sistemas de middleware tradicionais oferecem
poucas opções de reconfiguração.

LLP
– Ex.: semântica de invocação remota em Java RMI.
Motivação
• O desenvolvimento de plataformas de middleware é uma
atividade complexa.
– Desenvolvedores de aplicações distribuídas podem se
beneficiar de uma ferramenta que permita a obtenção de
plataformas de middleware adequadas para domínios
específicos.
• Esta dissertação propõe Arcademis, um arcabouço a partir
do qual podem ser desenvolvidas plataformas de
middleware.
• Arquitetura baseada em padrões de projeto.

LLP
• Gera sistemas de middleware que podem ser estaticamente
configurados para suportar aplicações com requisitos
específicos.
Vantagens do uso de Arcademis
• Agiliza o processo de desenvolvimento de
middleware.
• Reduz a possibilidade de ocorrência de erros de
programação.
• Produz plataformas cuja arquitetura não é monolítica.
– Uma instância de Arcademis não precisa utilizar todos os
seus componentes.
• Gera sistemas de middleware que podem ser
facilmente reconfigurados.
– Componentes podem ser configurados separadamente.

LLP
A Arquitetura de Arcademis
Parâmetros de Configuração
Principais Componentes

LLP
Arcademis
• Arcademis é um conjunto de componentes que
colaboram para descrever uma arquitetura de
middleware orientada por objetos.
• Arquitetura baseada em componentes.
• Arcademis possui componentes abstratos e concretos.
– Arcabouço caixa-branca: implementação de componentes
abstratos via herança.
– Arcabouço caixa-preta: composição de componentes concretos.

LLP
Três Níveis de Abstração
• A programação baseada em Arcademis pode ser
dividida em três níveis de abstração:
– Nível do desenvolvedor do arcabouço;
– Nível do desenvolvedor de middleware;
– Nível do desenvolvedor de aplicações distribuídas.
Desenvolvedor de
Arcademis

LLP
Desenvolvedor de
Middleware
Arcademis
Desenvolvedor de
Aplicações Distribuídas
Plataforma de
Middleware
Aplicação
Distribuída
Arquitetura Baseada em Componentes
Aplicação
Cliente
Agência de
Localização
Objeto
Remoto
Camada de aplicação
Camada de Middleware
Referência
Remota
Stub
Activator
Scheduler
Protocolo do
Middleware
Cadeia de
Invokers

LLP
Request
Sender
Response
Receiver
Protocolo de
Serialização
Protocolo de
Transporte
Connector
Acceptor
Skeleton
Request
Receiver
Response
Sender
Cadeia de
Dispatchers
Parâmetros de Configuração
• Arcademis especifica 12 aspectos configuráveis de
plataformas de middleware orientadas por objetos.
1 - Protocolo de transporte de dados.
2 - Estabelecimento de conexões.
3 - Tratamento de eventos.
4 - Estratégia de serialização.
5 - Semântica de chamadas remotas.
6 - Protocolo de comunicação do middleware.

LLP
Parâmetros de Configuração
• Demais parâmetros de configuração definidos por
Arcademis.
7 - Representação de objetos remotos.
8 - Localização de objetos distribuídos.
9 - Estratégia de invocação.
10 - Despacho de chamada remota.
11 - Distribuição de prioridades.
12 - Ativação de objetos remotos.

LLP
1º Parâmetro - Protocolo de Transporte
de Dados
• Existem diversos tipos de protocolos de transporte:
TCP, UDP, HTTP, SOAP, etc.
• O protocolo de transporte é implementado por dois
componentes:
– a interface Channel;
– a classe abstrata ConnectionServer;
Channel
<< interface >>

LLP
+connect(Epid epid):void
+send(byte[] a): void
+recv(): byte[]
+close(): void
+getLocalEpid(): Epid
+setTimeout(int t): void
+getTimeout(): int
ConnectionServer
Epid epid
+ConnectionServer(Epid epid)
+abstract accept():void
+abstract getChannel():Channel
+abstract setTimeout(int t):void
+abstract getTimeout():int
Decoradores de Canais
• Decorator : padrão de projeto que permite agregar
funcionalidades extras a um componente mediante
um objeto interceptador[Gamma 94].
Channel
<<interface>>
TcpChannel
<<arcademis.concrete>>

LLP
ChannelDecorator
<< decorator >>
ZipChannel
<< decorator >>
BufferedChannel
<< decorator >>
Exemplos de Decoradores
BufferedChannel
CheckedChannel

LLP
Adiciona um buffer ao canal, de
modo que nem toda operação de
leitura/escrita causa envio de dados.
Mantém um checksum de bytes
enquanto estes são enviados
PrintChannel
Imprime na saída padrão os dados
transmitidos pelo canal.
XorChannel
Aplica um algoritmo de criptografia
simples aos bytes transmitidos.
ZipChannel
Aplica um algoritmo de
compactação às mensagens
transmitidas pelo canal.
2º parâmetro - Estabelecimento de
Conexões
• Conexões são estabelecidas segundo o padrão
acceptor-connector [Schmidt 94].
• Separa elementos responsáveis pelo estabelecimento
da conexão (Acceptor e Connector) dos elementos
responsáveis pelo seu uso (subclasses de
ServiceHandler).
• Opções de configuração:
– estabelecimento de conexões síncrona ou assincronamente;
– reúso de canais de comunicação ou criação de novos canais;

LLP
– recepção de conexões em thread separada ou na mesma
thread da aplicação.
Padrão Acceptor-Connector
ConnectionServer
+accept():
+getChannel():Ch
Connector
+connect(epid):
<<creates>>
<<creates>>
<<creates>>
Channel
+send(byte[]):
+recv():byte[]
+connect(Epid):
<<uses>>

LLP
XxxxxHandler
Acceptor
+accept():
<<creates>>
<<uses>>
ServiceHandler
+open(channel):
YyyyyHandler
3º parâmetro - Tratamento de Eventos
• Padrão reactor.
– Separa as entidades responsáveis pela notificação de eventos
das entidades responsáveis pelo tratamento dos mesmos
• Ouvintes de eventos são registrados em uma estrutura
denominada Notifier.
• Para cada ouvinte de eventos existe um tratador de
eventos correspondente.
• O notifier continuamente verifica a ocorrência de algum
evento.

LLP
• Quando um evento ocorre, o tratador adequado é
notificado.
O Padrão Reactor
Event
Notifier
0..*
+handleEvents():
+registerEvent(Event):
+removeEvent(Id):Event
+eventTriggered():boolean
+getHandle():Object
EventHandler
+handleEvent(event):
• Opções de configuração:
– política de threads implementada pelo Notifier:
• mesma thread que a aplicação principal;

LLP
• uma única thread para notificação de eventos;
• uma thread para notificar cada evento registrado;
4º Parâmetro - Estratégia de Serialização
• Serializar um objeto significa transformá-lo em uma
seqüência de bytes de forma que outros objetos, com o
mesmo conteúdo que o objeto original possam ser
instanciados a partir daquela seqüência.
– Gravação de objetos em meio persistente.
– Transmissão de objetos em uma rede.
• Em Arcademis, a serialização de objetos é deixada a
cargo do desenvolvedor de aplicações.
– Objetos serializáveis implementam a interface Marshalable.

LLP
• O protocolo de serialização é definido pela interface
Stream.
Exemplo de Classe Serializável
<<interface>>
Marshalable
(from arcademis)
+marshal(Stream b);
import arcademis.*;
public class Example
implements Marshalable {
int argument = 0;
+unmarshal(Stream b);
public Example (int argument) {
this.argument = argument;
}
<<interface>>
Stream
(from arcademis)

LLP
+write(byte b):
+write(char c):
...
+write(Object o):
+readByte():byte
+readChar():char
...
+readObject():Object
public void marshal(Stream b) {
b.write(argument);
}
public void unmarshal(Stream b) {
this.argument = b.readInt();
}
}
5º Parâmetro - Semântica de Chamadas
Remotas
• A semântica de invocação de uma chamada remota
determina quais garantias acerca do processamento
daquela chamada o desenvolvedor de aplicações
pode esperar.
• Exemplos:
– best-effort;
– at-most-once;
– at-least-once;

LLP
Semântica de Chamadas Remotas
• O padrão Request-Response permite configurar a semântica de
chamadas remotas.
• Padrão definido por quatro processadores de serviço: requestsender, request-receiver, response-sender e response-receiver.
Objeto
Remoto
Objeto
Cliente
Reques
t
Sender
Stub

LLP
Host S
Request
Receiver
Skeleton
Response
Receiver
Respons
e
Sender
Host T
6º Parâmetro - Protocolo de Comunicação
do Middleware
• O protocolo de comunicação do Middleware é definido
por um conjunto de mensagens e por uma máquina de
estados que determina quando cada mensagem deve
ser transmitida.
• Em Arcademis mensagens são implementações da
interface arcademis.Message.
• Todas as mensagens são objetos serializáveis:
arcademis.Message extends Marshalable.

LLP
• A implementação dos métodos marshal e unmarshal
define quais informações são transmitidas por cada
mensagem.
Protocolo de Comunicação do Middleware
• A máquina de estados do protocolo é implementada
pelos processadores de serviço request-sender, requestreceiver, response-sender e response-receiver.
• Mensagens são convertidas em bytes pela classe
arcademis.Protocol.
RequestSender
Protocol
+open(Channel ch);
+send(Message m):
+recv():Message
ResponseReceiver

LLP
+open(Channel ch);
Channel
+send(byte[] b):
+recv():byte b
RequestReceiver
+open(Channel ch);
ResponseSender
+open(Channel ch);
7º Parâmetro - Representação de Objetos
Remotos
• Objetos remotos são instâncias de arcademis.RemoteObject.
• Referências remotas são instâncias de
arcademis.RemoteReference.
• Objetos remotos possuem identificadores únicos, instâncias de
arcademis.Identifier.
• Objetos remotos possuem um endereço, instância de
arcademis.Epid.
• Para determinar a semântica de operações como equals(),
toString() e hashCode():
– localmente: implementação de RemoteObject;
– remotamente: implementação de RemoteReference;

LLP
• Objetos remotos são responsáveis pela criação de stubs e
skeletons.
Representação de Objetos Remotos
Marshalable
<<Interface>>
RemoteObject
<<abstract>>
+activate():
+deactivate():
+getRef():RemoteReference
+getStub():Stub
+getSkeleton():Skeleton
+equals(Object):boolean
+toString():String
+hashCode():int

LLP
RemoteReference
+RemoteReference(Epid,Id):
+equals(Object):boolean
+toString():String
+hashCode():int
+getEpid():Epid
+getId():Identifier
Epid
<<Interface>>
Identifier
<<Interface>>
8º Parâmetro - Localização de Objetos
Distribuídos
• Arquitetura orientada por serviços:
– provedores de serviços;
– clientes;
– agências de localização.
Agência de
Localização
Identificador
de serviço
find()

LLP
Aplicação
Cliente
publish()
Fornecedor
de Serviço
Localização de Objetos Distribuídos
• A definição de agência de localização, em
Arcademis, é parte de seu conjunto de componentes
concretos, e não do núcleo do arcabouço.
– Nem todas as funcionalidade de uma agência de localização
são utilizadas por certas aplicações. Ex.: aplicações clientes
não utilizam a operação publish, e aplicações servidoras
não utilizam find.
• Diferentes identificadores de serviço:
– nomes (cadeias de caracteres);
– descritor de interface ou classe;

LLP
Localização de Objetos Distribuídos
• Arcademis define duas interfaces para a agência de
localização, uma baseada em nomes e a outra
baseada em descritores de classe.

LLP
package arcademis.concrete;
public interface NameBasedNaming {
public Remote find(String name)
throws NotBoundException,
ArcademisException;
}
package arcademis.concrete.server;
public interface NameBasedNaming {
public void publish
(String name, Stub obj)
throws AlreadyBoundException,
ArcademisException;
}
package arcademis.concrete;
public interface
InterfaceBasedNaming {
public Remote find(Class service)
throws NotBoundException,
ArcademisException;
}
package arcademis.concrete.server;
public interface
InterfaceBasedNaming {
public void
publish(RemoteObject obj)
throws AlreadyBoundException,
ArcademisException;
}
9º Parâmetro - Estratégia de Invocação
• Determina como requisições são despachadas pelo
cliente.
• Estratégia implementada por instâncias de
arcademis.Invoker.
Stub
Invoker
<<interface>>
+invoke(RemoteCall,
RemoteReference):Stream
InvokerDecorator

LLP
+invoke(RemoteCall,
RemoteReference):Stream
RequestSender
Estratégia de Invocação
• Diferentes funcionalidades podem ser agregadas aos
invocadores por meio de decoradores.
– Caches: chamadas que não causam efeitos colaterais, não
disparam exceções e sempre retornam os mesmos valores
para os mesmos parâmetros.
– Enfileiramento de mensagens: várias invocações remotas
podem ser enviadas em um mesmo pacote.
– Geração de log.
– Simulação de anomalias de rede.

LLP
– Distribuição de carga: se o stub tem acesso a mais de uma
referência remota, chamadas podem ser distribuídas entre
elas.
10º Parâmetro - Despacho de Chamadas
Remotas
• Determina como requisições, tendo sido recebidas
do lado servidor, são despachadas para o objeto
que as irá processar.
– Arquitetura do Servidor.
• uso de escalonador de invocações.
– Política de threads adotada pelo servidor.
• Estratégia implementada por instâncias de
arcademis.server.Dispatcher.
• Funcionalidades extra podem ser adicionadas ao
dispatcher por meio de decoradores:
– geração de arquivos de log.

LLP
– verificação da procedência de mensagens recebidas.
Despacho de Chamadas Remotas
DispatcherDecorator
RequestReceiver
Dispatcher
Scheduler
Skeleton
ResponseSender
RemoteObject

LLP
11º Parâmetro - Distribuição de
Prioridades
• Chamadas remotas podem ser associadas a prioridades.
• O elemento responsável por ordenar as invocações
recebidas é uma instância de
arcademis.server.Scheduler.
• Prioridades podem ser atribuídas a chamadas remotas de
diferentes modos:
– First in, first out.
– Implementação do stub determina a prioridade de cada método.
– Servidores atributem a cada cliente uma prioridade diferente.

LLP
– Prioridades por endereços remotos: servidor pode receber
invocações remotas em mais de um endereço.
12º Parâmetro - Ativação de Objetos
Remotos
• Em Arcademis, objetos distribuídos somente recebem chamadas
remotas após terem sido ativados.
• A ativação de um objeto remoto separa recursos para que este
possa processar chamadas:
– instancia e inicializa os componentes skeleton,
dispatcher, scheduler e acceptor.
– cria threads para receber conexões.
– associa o objeto remoto a um ponto de rede (Epid) no qual
este receberá conexões de clientes.
– cria um identificador para o objeto remoto, o qual é único na
rede.

LLP
• As rotinas de ativação são implementadas em subclasses de
arcademis.server.Activator.
Ativação de Objetos Remotos
(from arcademis.server)
Active
<<Interface>>
+activate():
+deactivate():
from arcademis.server)
RemoteObject
<<abstract>>
+getRef():RemoteReference
+getStub():Stub
+getSkeleton():Skeleton
+equals(Object):boolean
+toString():String
+hashCode():int

LLP
from arcademis.server)
Activator
<<abstract>>
A Classe ORB
• Todos os componentes de Arcademis são criados por fábricas
abstratas[Gamma 94].
– Facilita a configuração de instâncias de Arcademis.
• As fábricas estão associadas a um componente denominado
ORB (arcademis.ORB).
• A classe ORB não pode ser instanciada ou estendida, e todos
os seus métodos são estáticos.
• Configurar uma instância de Arcademis significa definir quais
fábricas farão parte do ORB.

LLP
• Arcademis fornece uma fachada para a criação de
componentes a partir de fábricas: a classe
arcademis.OrbAccessor.
A Classe ORB
Aplicações Distribuídas
ORB
Fábrica de
Invoker
Fábrica de
Message
Fábrica de
Identifier

LLP
Fábrica de
Dispatcher
Fábrica de
Epid
Fábrica de
Buffer
Fábrica de
Channel
Fábrica de
Notifier
16 fábricas
Fábrica de
Activator
Fábrica de
Acceptor
Fábrica de
ServiceHandler
Fábrica de
Stream
Fábrica de
Protocol
Sistema Operacional
Fábrica de
Connector
Fábrica de
Scheduler
Fábrica de
ConnectionServer
RME (RMI for J2ME)
Motivação
Descrição de RME
Exemplo de aplicação
Testes de desempenho

LLP
Objetivos de RME
• Fornecer ao perfil CLDC de J2ME um serviço de
invocação remota de métodos semelhante a Java
RMI.
• Demonstrar como Arcademis pode ser utilizado na
instanciação de plataformas de middleware.
• Constituir um ponto de partida para a derivação de
outras plataformas de middleware orientadas por
objetos.

LLP
Java 2 Micro Edition - J2ME
• Distribuição da linguagem Java voltada para
dispositivos de menor capacidade computacional:
aparelhos celulares, palmtops, pagers, etc.
• Duas configurações mais populares
– CDC: Connected Device Configuration
– CLDC: Connected, Limited Device Configuration
• Principais capacidades ausentes em CLDC
– Números de ponto flutuante.
– Reflexividade.

LLP
Java RMI
• Java RMI é o serviço de invocação remota de
métodos padrão da linguagem Java.
– Coleta de lixo distribuída.
– Serviço de localização de objetos.
– Gerador de stubs e skeletons.
– Serialização de Objetos.
• Serialização de objetos baseada em reflexividade.
– Java RMI não pode ser utilizado em CLDC porque não é
possível utilizar outra estratégia de serialização que não
seja baseada em reflexividade.

LLP
Características de RME
• Treze fábricas associadas ao ORB. Três fábricas de
Arcademis não foram utilizadas.
• Transporte de dados: TCP/IP.
• Estabelecimento de conexões: estabelecimento
síncrono com reúso de canais.
• Tratamento de eventos: não é implementado.
• Protocolo do middleware: quatro mensagens: call,
ret, ping e ack.

LLP
• Semântica de chamadas remotas: duas opções:
best-effort e at-most-once.
Características de RME
• Serviço de localização de nomes: mesma interface
fornecida por Java RMI.
• Estratégia de invocação: chamadas síncronas, alguns
decoradores de invoker implementados.
• Despacho de requisições: chamadas remotas passadas
diretamente para o skeleton.
• Política de prioridades: todas as chamadas possuem a
mesma prioridade.

LLP
Versões e Ferramentas Auxiliares
• Duas versões de RME:
– RME_J2ME:
• fornece somente funções de aplicações clientes.
– RME_J2SE:
• fornece funções de aplicações clientes e servidoras.
– RME_J2ME é um subconjunto de RME_J2SE, a exceção da
implementação de Channel e ConnectionServer.
• Serviço de nomes com a mesma interface de Java
RMI.

LLP
• RmeC: gera código de stubs e skeletons a partir de
uma classe que estende RmeRemoteObject.
Exemplo de Aplicação: Catálogo Telefônico
import rme.*;
import arcademis.*;
public interface PhoneCatalogue extends Remote {
public PhoneAddress getPhoneAddress(String name)
throws ArcademisException;
}
import java.io.*;

LLP
import java.util.*;
public class PhoneBook extends rme.server.RmeRemoteObject
implements PhoneCatalogue
{
Hashtable h = null;
public PhoneAddress getPhoneAddress(String name) {
return (PhoneAddress)h.get(name);
}
private void insert(String name, String number, String address)
{ ... }
}
Implementação do Objeto PhoneAddress
import arcademis.*;
public class PhoneAddress implements Marshalable {
private String name, phoneNumber, address;

LLP
public PhoneAddress(String n, String p, String a){
name = n;
phoneNumber = p;
address = a;
}
public void marshal(Stream b) {
b.write(phoneNumber);
b.write(name);
b.write(address);
}
public void unmarshal(Stream b) {
this.phoneNumber = (String)b.readObject();
this.name = (String)b.readObject();
this.address = (String)b.readObject();
}
// other method’s implementations: get’s and set’s
}
Aplicação Servidora
public class Server {
public static void main(String args[]) {
try {
rme.RmeConfigurator c = new rme.RmeConfigurator();
c.configure();
PhoneBook o = new PhoneBook();
rme.naming.RmeNaming.bind("obj", o);
o.activate();
o.readFile(args[0]); // fills the phone book
}
catch (arcademis.ArcademisException e){}
catch (arcademis.concreteComponents.MalformedURLException e){}
catch (rme.naming.AlreadyBoundException e){}
catch (java.io.IOException e){}
}
}

LLP
Aplicação Cliente (J2SE)
import arcademis.*;
import rme.*;

LLP
public class Client {
public static void main(String a[]) {
try {
RmeConfigurator c = new RmeConfigurator();
c.configure();
PhoneCatalogue phoneBook = (PhoneCatalogue)
RmeNaming.lookup("algol.dcc.ufmg.br/obj");
PhoneAddress a =
phoneBook.getPhoneAddress(“Machado de Assis”);
System.out.println(a.toString());
} catch (Exception e) {}
}
}
Configuração do ORB
package rme;
import rme.server.*;
import arcademis.*;
public final class RmeConfigurator implements Configurator {
public void configure() throws ReconfigurationException {
if(ORB.isOpenForReconfiguration()) {
// Define the channel factory
ChannelFc cnFc = new RmeChannelFc();
ORB.setChannelFactory(cnFc);
// Define the connection server factory
ConnectionServerFc csFc = new RmeConServerFc();
ORB.setConnectionServerFactory(csFc);
// Define the other 7 factories ...
// close the ORB for furter reconfigurations
ORB.closeForReconfiguration();

LLP
}
else throw new ReconfigurationException();
}
}
Ambiente de Execução J2ME Wireless Toolkit 2.0

LLP
Testes de Desempenho
• Dois Pentium 4, 2.0GHz, 512MB RAM conectados por rede
Ethernet de 10Mb/s.
• Emulador de KVM capaz de executar 100 bytecodes/s e
capacidade de transmissão de 1200 bits/s.
• Média de 10 seqüências de 10.000 requisições de cada um dos
métodos da interface abaixo.
import arcademis.*;
public interface MethodSet extends Remote {
public short getShort() throws ArcademisException;
public char getChar() throws ArcademisException;
public long getLong() throws ArcademisException;
public String[] getStrs() throws ArcademisException;
public void passArgs(byte b, short sh, char c, int i,
long l, String st, String[] sts) throws ArcademisException;

LLP
public String passLongs (long[] l) throws ArcademisException;
public String passStrs (String[] s) throws ArcademisException;
}
RME/J2ME × sockets - Testes em Rede
Foi desenvolvida uma aplicação baseada em sockets para trocar mensagens
de mesmo tamanho que aquelas trocadas por invocações remotas de métodos
em RME. Esta aplicação serviu como um limite superior de desempenho.
Método

LLP
Tamanho de
mensagens
Req/s
RME_J2ME
getShort
200/70
5.08
5.11
0.99
getChar
200/70
5.05
5.12
0.98
getLong
200/76
5.02
5.07
0.99
getStrs
200/201
2.96
5.00
0.59
passArgs
351/69
2.57
5.02
0.52
passLongs
282/82
3.03
5.04
0.61
323/170
2.12
4.97
0.43
passStrs
Req/s RME_J2ME/
sockets
sockets
RME/J2SE × RMI - Testes em Rede
Método

LLP
Req/s RME_J2SE
Req/s Java RMI
RME_J2SE/
Java RMI
getShort
1814.31
2691.97
0.67
getChar
1831.17
2749.71
0.67
getLong
1802.86
2711.50
0.66
getStrs
1405.88
1555.27
0.90
passArgs
1208.71
1512.11
0.80
passLongs
1376.37
1859.17
0.74
passStrs
1100.11
1329.17
0.82
Comparação entre Tamanho de Bibliotecas

LLP
Arcademis Cliente
19.2KB
Arcademis/RME Cliente sem fábricas
29.2KB
Arcademis/RME cliente
37.1KB
Arcademis/RME servidor
68.2KB
LegORB configurado estaticamente
22.5KB
LegORB configurado dinamicamente
141.5KB
UIC CORBA (PalmOS)
18KB
UIC CORBA (Windows CE)
29KB
UIC CORBA (Windows 2000)
72KB
Conclusões
Contribuições
Avaliação
Trabalhos Futuros

LLP
Contribuições
• Contribuições metodológicas:
– descrição da arquitetura de sistemas de middleware orientados
por objetos;
– enumeração de vários parâmetros de configurações de
plataformas de middleware;
– utilização de padrões de projeto no desenvolvimento de
plataformas de middleware;
– descrição do padrão de projeto request-response.
• Contribuições práticas:
– implementação de um arcabouço para o desenvolvimento de
plataformas de middleware em Java;

LLP
– implementação de RME.
Avaliação
• Sistema flexível.
– Arcademis pode ser utilizado em um ambiente (J2ME/CLDC) em
que Java RMI não pode ser empregado.
– Projeto baseado em fábricas de objetos facilita a configuração:
para alterar a semântica de chamadas remotas em RME, basta
alterar a fábrica associada ao ORB.
– Muitos dos padrões de projeto utilizados em Arcademis prevêem
diferentes configurações; ex.: acceptor-connector.
– Arcademis pode ser utilizado tanto em J2SE quanto em J2ME.
• Os componentes de Arcademis utilizam apenas elementos
comuns a ambas as plataformas; ex.: números de ponto
flutuante não são utilizados.

LLP
– A maior flexibilidade de RME não compromete sobremaneira o seu
desempenho.
Avaliação
• Arcademis não depende de um ambiente de
execução específico.
– O arcabouço está implementado na linguagem Java.
• O sistema não fornece reconfiguração dinâmica, mas
permite que diferentes táticas de invocação sejam
associadas aos métodos remotos em tempo de
execução.

LLP
Trabalhos Futuros
• Pretende-se utilizar Arcademis e suas instâncias como um
laboratório em que experimentos sobre arquiteturas de
middleware possam ser realizados.
• Derivação de plataformas de middleware baseadas em
outros paradigmas diferentes do orientado por objetos.
• Parametrização de diferentes mecanismos de coleta de
lixo distribuída.
• Otimizar RME com relação a tamanho, desempenho e
tolerância a falhas.

LLP
• Desenvolver um sistema em que o usuário tenha como
especificar as táticas utilizadas em invocação remota de
métodos.
Download
http://www.dcc.ufmg.br/llp/arcademis/

LLP