A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

LLP Arcademis: um Arcabouço para o Desenvolvimento de Middleware Fernando Magno Quintão Pereira Orientador: Roberto S Bigonha Co-orientador: Marco Túlio.

Apresentações semelhantes


Apresentação em tema: "LLP Arcademis: um Arcabouço para o Desenvolvimento de Middleware Fernando Magno Quintão Pereira Orientador: Roberto S Bigonha Co-orientador: Marco Túlio."— Transcrição da apresentação:

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

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

3 LLP Objetivos da Dissertação Projetar e implementar um arcabouço voltado para o desenvolvimento de plataformas de middleware. –Plataformas de middleware específicas, que disponibilizam às aplicações conjuntos mínimos de funcionalidades. Separar os diversos aspectos que constituem as plataformas de middleware baseadas em objetos distribuídos, especificando quais características são comuns a todos os sistemas e quais admitem variações. Desenvolver um serviço de invocação remota de métodos para o perfil CLDC da plataforma J2ME.

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

5 LLP Arcabouços para o Desenvolvimento de Software. Arcabouços, ou frameworks, são uma técnica de reúso de código e de projeto. Arcabouços são constituídos por um conjunto de componentes, concretos e abstratos, que se relacionam de forma a compor o esqueleto de uma aplicação[Jonhson 97].

6 LLP Tipos de Arcabouços Existem dois tipos de arcabouços: –Sistemas do tipo caixa-branca: São formados por componentes abstratos que o desenvolvedor deve estender. Possibilitam maior flexibilidade. Demandam maior conhecimento dos componentes utilizados. –Sistemas do tipo caixa-preta: São constituídos por componentes concretos que podem ser combinados pelo desenvolvedor de aplicações sem qualquer modificação. Não demandam grande conhecimento sobre os componentes utilizados. Apresentam menor flexibilidade que os sistemas caixa-branca. Arcademis apresenta características de ambos.

7 LLP Plataformas de Middleware Sistema Operacional Middleware Aplicação Unix J2EE Livraria 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.

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

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

10 LLP 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.

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

12 LLP 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.

13 LLP Quarterware Sistema mais flexível que plataformas de middleware configuráveis, como TAO ou DynamicTAO. Exemplos de uso de Quarterware: –implementação de CORBA; –implementação de Java RMI; –implementação de MPI (Message Passing Interface); Diferenças em relação a Arcademis. –Parâmetros de configuração: Arcademis apresenta maior número de opções de configuração. –Implementação em C++.

14 LLP Padrões de Projeto Um padrão de projeto é um tratado que descreve uma família de problemas relacionados e uma solução comum para todos eles. Arcademis utiliza diversos padrões de projeto: –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;

15 LLP 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.

16 LLP 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.

17 LLP 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.

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

19 LLP Arcademis Arcademis é um conjunto de componentes que colaboram para descrever uma arquitetura de middleware orientada por objetos. Arquitetura baseada em componentes. Arcademis possui componentes abstratos e concretos. –Arcabouço caixa-branca: implementação de componentes abstratos via herança. –Arcabouço caixa-preta: composição de componentes concretos.

20 LLP Três Níveis de Abstração A programação baseada em Arcademis pode ser dividida em três níveis de abstração: –Nível do desenvolvedor do arcabouço; –Nível do desenvolvedor de middleware; –Nível do desenvolvedor de aplicações distribuídas. Arcademis Plataforma de Middleware Aplicação Distribuída Desenvolvedor de Arcademis Desenvolvedor de Middleware Desenvolvedor de Aplicações Distribuídas

21 LLP Arquitetura Baseada em Componentes Aplicação Cliente Stub Cadeia de Invokers Referência Remota Protocolo do Middleware Protocolo de Transporte ConnectorAcceptor Agência de Localização Cadeia de Dispatchers Scheduler Skeleton Objeto Remoto Activator Protocolo de Serialização Request Sender Response Receiver Request Receiver Response Sender Camada de aplicação Camada de Middleware

22 LLP 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.

23 LLP Parâmetros de Configuração Demais parâmetros de configuração definidos por Arcademis. 7 - Representação de objetos remotos. 8 - Localização de objetos distribuídos. 9 - Estratégia de invocação Despacho de chamada remota Distribuição de prioridades Ativação de objetos remotos.

24 LLP 1º Parâmetro - Protocolo de Transporte de Dados Existem diversos tipos de protocolos de transporte: TCP, UDP, HTTP, SOAP, etc. O protocolo de transporte é implementado por dois componentes: –a interface Channel ; –a classe abstrata ConnectionServer ; Channel > +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

25 LLP Decoradores de Canais Decorator : padrão de projeto que permite agregar funcionalidades extras a um componente mediante um objeto interceptador[Gamma 94]. Channel > ChannelDecorator > TcpChannel > ZipChannel > BufferedChannel >

26 LLP Exemplos de Decoradores

27 LLP 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.

28 LLP Padrão Acceptor-Connector Connector +connect(epid): Channel +send(byte[]): +recv():byte[] +connect(Epid): Acceptor +accept(): XxxxxHandlerYyyyyHandler > ServiceHandler +open(channel): ConnectionServer +accept(): +getChannel():Ch

29 LLP 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.

30 LLP 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;

31 LLP 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.

32 LLP Exemplo de Classe Serializável > Marshalable (from arcademis) +marshal(Stream b); +unmarshal(Stream b ); > 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(); }

33 LLP 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;

34 LLP Semântica de Chamadas Remotas Objeto Remoto Host S Stub Skeleton Objeto Cliente Reques t Sender Response Receiver Request Receiver Respons e 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.

35 LLP 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.

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

37 LLP 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.

38 LLP Representação de Objetos Remotos RemoteReference +RemoteReference(Epid,Id): +equals(Object):boolean +toString():String +hashCode():int +getEpid():Epid +getId():Identifier Epid > Identifier > Marshalable > RemoteObject > +activate(): +deactivate(): +getRef():RemoteReference +getStub():Stub +getSkeleton():Skeleton +equals(Object):boolean +toString():String +hashCode():int

39 LLP 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 Aplicação Cliente Fornecedor de Serviço Identificador de serviço find() publish()

40 LLP 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;

41 LLP Localização de Objetos Distribuídos Arcademis define duas interfaces para a agência de localização, uma baseada em nomes e a outra baseada em descritores de classe. 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; }

42 LLP 9º Parâmetro - Estratégia de Invocação Determina como requisições são despachadas pelo cliente. Estratégia implementada por instâncias de arcademis.Invoker. Stub Invoker > +invoke(RemoteCall, RemoteReference):Stream RequestSender InvokerDecorator +invoke(RemoteCall, RemoteReference):Stream

43 LLP 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.

44 LLP 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.

45 LLP Despacho de Chamadas Remotas RequestReceiver ResponseSender DispatcherScheduler Skeleton RemoteObject DispatcherDecorator

46 LLP 11º Parâmetro - Distribuição de Prioridades Chamadas remotas podem ser associadas a prioridades. O elemento responsável por ordenar as invocações recebidas é uma instância de arcademis.server.Scheduler. Prioridades podem ser atribuídas a chamadas remotas de diferentes modos: –First in, first out. –Implementação do stub determina a prioridade de cada método. –Servidores atributem a cada cliente uma prioridade diferente. –Prioridades por endereços remotos: servidor pode receber invocações remotas em mais de um endereço.

47 LLP 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.

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

49 LLP 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.

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

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

52 LLP Objetivos de RME Fornecer ao perfil CLDC de J2ME um serviço de invocação remota de métodos semelhante a Java RMI. Demonstrar como Arcademis pode ser utilizado na instanciação de plataformas de middleware. Constituir um ponto de partida para a derivação de outras plataformas de middleware orientadas por objetos.

53 LLP Java 2 Micro Edition - J2ME Distribuição da linguagem Java voltada para dispositivos de menor capacidade computacional: aparelhos celulares, palmtops, pagers, etc. Duas configurações mais populares –CDC: Connected Device Configuration –CLDC: Connected, Limited Device Configuration Principais capacidades ausentes em CLDC –Números de ponto flutuante. –Reflexividade.

54 LLP Java RMI Java RMI é o serviço de invocação remota de métodos padrão da linguagem Java. –Coleta de lixo distribuída. –Serviço de localização de objetos. –Gerador de stubs e skeletons. –Serialização de Objetos. Serialização de objetos baseada em reflexividade. –Java RMI não pode ser utilizado em CLDC porque não é possível utilizar outra estratégia de serialização que não seja baseada em reflexividade.

55 LLP Características de RME Treze fábricas associadas ao ORB. Três fábricas de Arcademis não foram utilizadas. Transporte de dados: TCP/IP. Estabelecimento de conexões: estabelecimento síncrono com reúso de canais. Tratamento de eventos: não é implementado. Protocolo do middleware: quatro mensagens: call, ret, ping e ack. Semântica de chamadas remotas: duas opções: best-effort e at-most-once.

56 LLP 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.

57 LLP Versões e Ferramentas Auxiliares Duas versões de RME: –RME_J2ME: fornece somente funções de aplicações clientes. –RME_J2SE: fornece funções de aplicações clientes e servidoras. –RME_J2ME é um subconjunto de RME_J2SE, a exceção da implementação de Channel e ConnectionServer. Serviço de nomes com a mesma interface de Java RMI. RmeC: gera código de stubs e skeletons a partir de uma classe que estende RmeRemoteObject.

58 LLP 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) {... } }

59 LLP 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 methods implementations: gets and sets }

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

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

62 LLP 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(); }

63 LLP Ambiente de Execução - J2ME Wireless Toolkit 2.0

64 LLP Testes de Desempenho Dois Pentium 4, 2.0GHz, 512MB RAM conectados por rede Ethernet de 10Mb/s. Emulador de KVM capaz de executar 100 bytecodes/s e capacidade de transmissão de 1200 bits/s. Média de 10 seqüências de 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; }

65 LLP 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.

66 LLP RME/J2SE × RMI - Testes em Rede

67 LLP Comparação entre Tamanho de Bibliotecas

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

69 LLP Contribuições Contribuições metodológicas: –descrição da arquitetura de sistemas de middleware orientados por objetos; –enumeração de vários parâmetros de configurações de plataformas de middleware; –utilização de padrões de projeto no desenvolvimento de plataformas de middleware; –descrição do padrão de projeto request-response. Contribuições práticas: –implementação de um arcabouço para o desenvolvimento de plataformas de middleware em Java; –implementação de RME.

70 LLP 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.

71 LLP 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.

72 LLP Trabalhos Futuros Pretende-se utilizar Arcademis e suas instâncias como um laboratório em que experimentos sobre arquiteturas de middleware possam ser realizados. Derivação de plataformas de middleware baseadas em outros paradigmas diferentes do orientado por objetos. Parametrização de diferentes mecanismos de coleta de lixo distribuída. Otimizar RME com relação a tamanho, desempenho e tolerância a falhas. Desenvolver um sistema em que o usuário tenha como especificar as táticas utilizadas em invocação remota de métodos.

73 LLP Download


Carregar ppt "LLP Arcademis: um Arcabouço para o Desenvolvimento de Middleware Fernando Magno Quintão Pereira Orientador: Roberto S Bigonha Co-orientador: Marco Túlio."

Apresentações semelhantes


Anúncios Google