Upload
internet
View
104
Download
1
Embed Size (px)
Citation preview
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/