LLPLLP

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

LLPLLP

Estrutura da Apresentação

• Objetivos

• Revisão da literatura

• Arquitetura de Arcademis

• RME

• Avaliação

LLPLLP

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.

• Desenvolver um serviço de invocação remota de métodos para o perfil CLDC da plataforma J2ME.

LLPLLP

Revisão da Literatura

Arcabouços de desenvolvimento de software

Plataformas de Middleware

Quarterware

Padrões de projeto

LLPLLP

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

LLPLLP

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.

• Arcademis apresenta características de ambos.

LLPLLP

Plataformas de Middleware

Sistema OperacionalSistema Operacional

MiddlewareMiddleware

AplicaçãoAplicação

UnixUnix

J2EEJ2EE

Livraria VirtualLivraria Virtual

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

LLPLLP

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.

B

A

C

X

Y

Host S

Host T

LLPLLP

Comunicação entre Objetos Distribuídos

• Objetos se comunicam via representantes locais: stubs e skeletons.

RemObj { m1();}

Host S Host T

Stub { m1();}

Skeleton

ObjetoCliente

LLPLLP

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.

• Configuração dinâmica baseada em reflexividade, implementada por meio de metaobjetos.

LLPLLP

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

– LegORB configurado dinamicamente: 141.5KB

LLPLLP

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.

LLPLLP

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

LLPLLP

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:

– fábricas de objetos;

– singletons;

– objetos decoradores;

– objetos adaptadores;

– proxies;

– fachadas;

– flyweights;

– estratégias;

– objetos ativos (TAO);

– conectores/receptores (TAO);

– reactor(TAO);

– requisição/resposta;

LLPLLP

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.

– Ex.: semântica de invocação remota em Java RMI.

LLPLLP

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.

• Gera sistemas de middleware que podem ser estaticamente configurados para suportar aplicações com requisitos específicos.

LLPLLP

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.

LLPLLP

A Arquitetura de Arcademis

Parâmetros de Configuração

Principais Componentes

LLPLLP

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.

LLPLLP

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.

ArcademisPlataforma deMiddleware

AplicaçãoDistribuída

Desenvolvedor deArcademis

Desenvolvedor deMiddleware

Desenvolvedor deAplicações Distribuídas

LLPLLP

Arquitetura Baseada em Componentes

AplicaçãoCliente

Stub

Cadeia deInvokers

ReferênciaRemota

Protocolo doMiddleware

Protocolo deTransporte

Connector Acceptor

Agência deLocalização

Cadeia deDispatchers

Scheduler

Skeleton

ObjetoRemoto

Activator

Protocolo deSerialização

RequestSender

ResponseReceiver

RequestReceiver

ResponseSender

Camada de aplicação

Camada de Middleware

LLPLLP

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.

LLPLLP

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.

LLPLLP

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

+connect(Epid epid):void+send(byte[] a): void+recv(): byte[]+close(): void+getLocalEpid(): Epid+setTimeout(int t): void+getTimeout(): int

ConnectionServer

+ConnectionServer(Epid epid)+abstract accept():void+abstract getChannel():Channel+abstract setTimeout(int t):void+abstract getTimeout():int

Epid epid

LLPLLP

Decoradores de Canais

• Decorator : padrão de projeto que permite agregar funcionalidades extras a um componente mediante um objeto interceptador[Gamma 94].

Channel<<interface>>

ChannelDecorator<< decorator >>

TcpChannel<<arcademis.concrete>>

ZipChannel<< decorator >>

BufferedChannel<< decorator >>

LLPLLP

Exemplos de Decoradores

BufferedChannel Adiciona um buffer ao canal, demodo que nem toda operação deleitura/escrita causa envio de dados.

CheckedChannel Mantém um checksum de bytesenquanto estes são enviados

PrintChannel Imprime na saída padrão os dadostransmitidos pelo canal.

XorChannel Aplica um algoritmo de criptografiasimples aos bytes transmitidos.

ZipChannel Aplica um algoritmo decompactação às mensagenstransmitidas pelo canal.

LLPLLP

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;

– recepção de conexões em thread separada ou na mesma thread da aplicação.

LLPLLP

Padrão Acceptor-Connector

Connector+connect(epid):

Channel+send(byte[]): +recv():byte[]+connect(Epid):

Acceptor +accept():

XxxxxHandler YyyyyHandler

<<creates>>

<<uses>>

<<creates>>

<<creates>><<creates>>

<<uses>>

ServiceHandler+open(channel):

ConnectionServer+accept():+getChannel():Ch

LLPLLP

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.

• Quando um evento ocorre, o tratador adequado é notificado.

LLPLLP

O Padrão Reactor

Notifier

+handleEvents():+registerEvent(Event):+removeEvent(Id):Event

EventHandler

+handleEvent(event):

Event

+eventTriggered():boolean+getHandle():Object

0..*

• Opções de configuração:

– política de threads implementada pelo Notifier:

• mesma thread que a aplicação principal;

• uma única thread para notificação de eventos;

• uma thread para notificar cada evento registrado;

LLPLLP

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.

• O protocolo de serialização é definido pela interface Stream.

LLPLLP

Exemplo de Classe Serializável

<<interface>>Marshalable

(from arcademis)

+marshal(Stream b);

+unmarshal(Stream b);

<<interface>>Stream

(from arcademis)

+write(byte b):+write(char c):...+write(Object o):+readByte():byte+readChar():char...+readObject():Object

import arcademis.*;

public class Example implements Marshalable { int argument = 0;

public Example (int argument) { this.argument = argument; }

public void marshal(Stream b) { b.write(argument); }

public void unmarshal(Stream b) { this.argument = b.readInt(); }}

LLPLLP

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;

LLPLLP

Semântica de Chamadas Remotas

ObjetoRemoto

Host S

StubSkeleton

ObjetoCliente

Request

Sender

ResponseReceiver

RequestReceiver

Response

Sender Host T

• O padrão Request-Response permite configurar a semântica de chamadas remotas.

• Padrão definido por quatro processadores de serviço: request-sender, request-receiver, response-sender e response-receiver.

LLPLLP

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.

• A implementação dos métodos marshal e unmarshal define quais informações são transmitidas por cada mensagem.

LLPLLP

Protocolo de Comunicação do Middleware

• A máquina de estados do protocolo é implementada pelos processadores de serviço request-sender, request-receiver, response-sender e response-receiver.

• Mensagens são convertidas em bytes pela classe arcademis.Protocol.

RequestSender

+open(Channel ch);

ResponseReceiver

+open(Channel ch);

RequestReceiver

+open(Channel ch);

ResponseSender

+open(Channel ch);

Protocol

+send(Message m):+recv():Message

Channel

+send(byte[] b):+recv():byte b

LLPLLP

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;

• Objetos remotos são responsáveis pela criação de stubs e skeletons.

LLPLLP

Representação de Objetos Remotos

RemoteReference

+RemoteReference(Epid,Id):+equals(Object):boolean+toString():String+hashCode():int+getEpid():Epid+getId():Identifier

Epid<<Interface>>

Identifier<<Interface>>

Marshalable<<Interface>>

RemoteObject<<abstract>>

+activate():+deactivate():+getRef():RemoteReference+getStub():Stub+getSkeleton():Skeleton+equals(Object):boolean+toString():String+hashCode():int

LLPLLP

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 deLocalização

AplicaçãoCliente

Fornecedorde Serviço

Identificadorde serviço

find() publish()

LLPLLP

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;

LLPLLP

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.

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 interfaceInterfaceBasedNaming { public Remote find(Class service) throws NotBoundException, ArcademisException;}

package arcademis.concrete.server;public interfaceInterfaceBasedNaming { public void publish(RemoteObject obj) throws AlreadyBoundException, ArcademisException;}

LLPLLP

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.

StubInvoker

<<interface>>+invoke(RemoteCall,

RemoteReference):Stream

RequestSender

InvokerDecorator

+invoke(RemoteCall,RemoteReference):Stream

LLPLLP

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.

– Distribuição de carga: se o stub tem acesso a mais de uma referência remota, chamadas podem ser distribuídas entre elas.

LLPLLP

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.

– verificação da procedência de mensagens recebidas.

LLPLLP

Despacho de Chamadas Remotas

RequestReceiver

ResponseSender

Dispatcher Scheduler

Skeleton

RemoteObject

DispatcherDecorator

LLPLLP

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.

– Prioridades por endereços remotos: servidor pode receber invocações remotas em mais de um endereço.

LLPLLP

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.

• As rotinas de ativação são implementadas em subclasses de arcademis.server.Activator.

LLPLLP

Ativação de Objetos Remotos

+getRef():RemoteReference+getStub():Stub+getSkeleton():Skeleton+equals(Object):boolean+toString():String+hashCode():int

from arcademis.server)RemoteObject<<abstract>>

from arcademis.server)Activator

<<abstract>>

(from arcademis.server)Active

<<Interface>>

+activate():+deactivate():

LLPLLP

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.

• Arcademis fornece uma fachada para a criação de componentes a partir de fábricas: a classe arcademis.OrbAccessor.

LLPLLP

A Classe ORB

ORBORB

Sistema OperacionalSistema Operacional

Fábrica deInvoker

Fábrica deInvoker

Fábrica deDispatcherFábrica deDispatcher

Fábrica deChannel

Fábrica deChannel

Fábrica deActivatorFábrica deActivator

Fábrica deConnectorFábrica deConnector

Aplicações DistribuídasAplicações Distribuídas

Fábrica deMessage

Fábrica deMessage

Fábrica deServiceHandler

Fábrica deServiceHandler

Fábrica deAcceptorFábrica deAcceptor

Fábrica deStream

Fábrica deStream

Fábrica deSchedulerFábrica deScheduler

Fábrica deIdentifierFábrica deIdentifier

Fábrica deEpid

Fábrica deEpid

Fábrica deBuffer

Fábrica deBuffer

Fábrica deProtocolFábrica deProtocol

Fábrica deConnectionServer

Fábrica deConnectionServer

Fábrica deNotifierFábrica deNotifier

16 fábricas

LLPLLP

RME (RMI for J2ME)

Motivação

Descrição de RME

Exemplo de aplicação

Testes de desempenho

LLPLLP

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.

LLPLLP

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.

LLPLLP

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.

LLPLLP

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.

• Semântica de chamadas remotas: duas opções: best-effort e at-most-once.

LLPLLP

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.

LLPLLP

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.

• RmeC: gera código de stubs e skeletons a partir de uma classe que estende RmeRemoteObject.

LLPLLP

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 rme.*; import arcademis.*;

public interface PhoneCatalogue extends Remote { public PhoneAddress getPhoneAddress(String name) throws ArcademisException;}

import java.io.*; 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) { ... }}

import java.io.*; 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) { ... }}

LLPLLP

Implementação do Objeto PhoneAddress

import arcademis.*;

public class PhoneAddress implements Marshalable {

private String name, phoneNumber, address;

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}

import arcademis.*;

public class PhoneAddress implements Marshalable {

private String name, phoneNumber, address;

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}

LLPLLP

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){} }}

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){} }}

LLPLLP

Aplicação Cliente (J2SE)

import arcademis.*;import rme.*;

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) {} }}

import arcademis.*;import rme.*;

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) {} }}

LLPLLP

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(); } else throw new ReconfigurationException(); }}

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(); } else throw new ReconfigurationException(); }}

LLPLLP

Ambiente de Execução -J2ME Wireless Toolkit 2.0

LLPLLP

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;

public String passLongs (long[] l) throws ArcademisException; public String passStrs (String[] s) throws ArcademisException;}

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;

public String passLongs (long[] l) throws ArcademisException; public String passStrs (String[] s) throws ArcademisException;}

LLPLLP

RME/J2ME × sockets - Testes em Rede

Método Tamanho demensagens

Req/sRME_J2ME

Req/ssockets

RME_J2ME/sockets

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

passStrs 323/170 2.12 4.97 0.43

Foi desenvolvida uma aplicação baseada em sockets para trocar mensagensde mesmo tamanho que aquelas trocadas por invocações remotas de métodosem RME. Esta aplicação serviu como um limite superior de desempenho.

LLPLLP

RME/J2SE × RMI - Testes em Rede

Método 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

LLPLLP

Comparação entre Tamanho de Bibliotecas

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

LLPLLP

Conclusões

Contribuições

Avaliação

Trabalhos Futuros

LLPLLP

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;

– implementação de RME.

LLPLLP

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.

– A maior flexibilidade de RME não compromete sobremaneira o seu desempenho.

LLPLLP

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.

LLPLLP

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.

• Desenvolver um sistema em que o usuário tenha como especificar as táticas utilizadas em invocação remota de métodos.

LLPLLP

Download

http://www.dcc.ufmg.br/llp/arcademis/