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

Estrutura da Apresentação Objetivos Revisão da literatura Arquitetura de Arcademis RME Avaliação

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.

Revisão da Literatura Arcabouços de desenvolvimento de software Plataformas de Middleware Quarterware Padrões de projeto

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

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.

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. 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 Y B C Host T

Comunicação entre Objetos Distribuídos Objetos se comunicam via representantes locais: stubs e skeletons. RemObj { m1(); } Objeto Cliente Stub { m1(); } Skeleton Host T Host S

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.

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

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.

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

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;

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. Falar que existe um dilema entre vendedores e desenvolvedores. Os primeiros querem que suas plataformas suportem uma ampla variedade de requisitos e possam ser usadas nos mais variados cenários. Já os desenvolvedores querem que as plataformas de middleware possuam arquiteturas otimizadas para suportar cenários específicos, como aplicações de tempo real e a comunicação sem fio.

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.

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.

A Arquitetura de Arcademis Parâmetros de Configuração Principais Componentes

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.

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 Desenvolvedor de Middleware Desenvolvedor de Aplicações Distribuídas Arcademis 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 Skeleton Scheduler Protocolo do Middleware Lembrar que algumas das caixinhas representam conjuntos de componentes. Request Receiver Response Sender Request Sender Response Receiver Protocolo de Serialização Cadeia de Dispatchers Cadeia de Invokers Protocolo de Transporte Connector Acceptor

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.

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.

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

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

Exemplos de Decoradores

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.

Padrão Acceptor-Connector ConnectionServer +accept(): +getChannel():Ch Acceptor +accept(): Connector +connect(epid): <<creates>> <<creates>> Channel +send(byte[]): +recv():byte[] +connect(Epid): <<creates>> <<creates>> <<uses>> <<uses>> ServiceHandler +open(channel): XxxxxHandler 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. Quando um evento ocorre, o tratador adequado é notificado.

O Padrão Reactor Opções de configuração: Event +eventTriggered():boolean +getHandle():Object Notifier +handleEvents(): +registerEvent(Event): +removeEvent(Id):Event 0..* EventHandler +handleEvent(event): 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;

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.

Exemplo de Classe Serializável 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(); <<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

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;

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: request-sender, request-receiver, response-sender e response-receiver. Objeto Cliente Objeto Remoto Request Sender Request Receiver Skeleton Stub Response Receiver Response Sender Host S 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. 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, request-receiver, response-sender e response-receiver. Mensagens são convertidas em bytes pela classe arcademis.Protocol. Protocol RequestSender RequestReceiver +send(Message m): +recv():Message +open(Channel ch); +open(Channel ch); ResponseReceiver ResponseSender Channel +send(byte[] b): +recv():byte b +open(Channel ch); +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; 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 RemoteReference +RemoteReference(Epid,Id): +equals(Object):boolean +toString():String +hashCode():int +getEpid():Epid +getId():Identifier Objetos remotos também são responsáveis pela criação de stubs e skeltons. 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 publish() find() Aplicação Cliente 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;

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 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. Invoker <<interface>> +invoke(RemoteCall, RemoteReference):Stream Stub RequestSender InvokerDecorator +invoke(RemoteCall, RemoteReference):Stream

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.

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.

Despacho de Chamadas Remotas DispatcherDecorator RequestReceiver Dispatcher Scheduler Skeleton ResponseSender RemoteObject

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.

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.

Ativação de Objetos Remotos (from arcademis.server) Active <<Interface>> +activate(): +deactivate(): from arcademis.server) RemoteObject <<abstract>> from arcademis.server) Activator <<abstract>> +getRef():RemoteReference +getStub():Stub +getSkeleton():Skeleton +equals(Object):boolean +toString():String +hashCode():int

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. Dizer que a criação de componetnes a partir de fábricas carregfa a sintaxe de programação, e por isso a fachada é útil.

Aplicações Distribuídas A Classe ORB Aplicações Distribuídas ORB 16 fábricas Fábrica de Invoker Fábrica de Dispatcher Fábrica de Channel Fábrica de Activator Fábrica de Connector Fábrica de Message Fábrica de Epid Fábrica de Notifier Fábrica de Acceptor Fábrica de Stream Fábrica de Scheduler Fábrica de Identifier Fábrica de Buffer Fábrica de ServiceHandler Fábrica de Protocol Fábrica de ConnectionServer Sistema Operacional

RME (RMI for J2ME) Motivação Descrição de RME Exemplo de aplicação Testes de desempenho

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.

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.

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.

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.

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.

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.

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

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

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();

Ambiente de Execução - J2ME Wireless Toolkit 2.0

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

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.

RME/J2SE × RMI - Testes em Rede

Comparação entre Tamanho de Bibliotecas

Conclusões Contribuições Avaliação Trabalhos Futuros

Contribuições Contribuições metodológicas: Contribuições práticas: 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.

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.

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.

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.

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