Programação de Aplicações Tempo-Real em SistemasAbertos: O Modelo Reflexivo Tempo-Real Distribuído

Frank Siqueira e Joni Fraga

Laboratório de Controle e Microinformática – LCMIDepartamento de Engenharia Elétrica – Universidade Federal de Santa Catarina

Cx. Postal 476, Florianópolis, SC, Brasil. CEP 88040–900E-mail: {fraga,frank}@lcmi.ufsc.br

Resumo

Este artigo apresenta um modelo para aplicações distribuídas com restrições tempo-real emsistemas abertos. O modelo proposto utiliza o paradigma de reflexão computacional segundo aabordagem de meta-objetos, que provê a separação entre funcionalidade e gerenciamento naprogramação de aplicações. Conseqüentemente, o modelo possui dois níveis : um nível-base quetrata da funcionalidade do sistema, e um nível-meta que lida com escalonamento, restriçõestemporais e de sincronização, assim como tratamento de exceções. O modelo é implementadoutilizando o padrão para sistemas distribuídos abertos CORBA, e tratando as restrições de tempolocalmente a partir da especificação de um timeout no cliente e do deadline associado no servidor.Desta forma, o modelo garante um tratamento adequado para aplicações tempo-real do tipomelhor esforço em ambientes distribuídos abertos. Finalmente, as características principais domodelo proposto são ilustradas em um exemplo de aplicação de multimídia distribuída.

Abstract

This paper presents a model for distributed applications with real-time constraints in opensystems. The proposed model adopts the reflective paradigm according to the meta-objectapproach, which provides the separation among functionality and management whenprogramming applications. Consequently, the model has two levels : a base-level which dealswith system functionality, and a meta-level which manages scheduling, time and synchronizationconstraints, as well as exception handling. The model is implemented using the CORBA standardfor open distributed systems, and dealing with timing constraints locally, specifying timeouts inthe client and the associated deadlines in the server. Then, the model ensures an adequatetreatment of best-effort real-time applications in open distributed systems. Finally, the maincharacteristics of the proposed model are shown in an example of a distributed multimediaapplication.

1 Introdução

A interligação de computadores em redes de longa distância levou ao surgimento deproblemas derivados da heterogeneidade de equipamentos e das dimensões do sistema comoum todo. O surgimento destes problemas levou à adoção de arquiteturas abertas para otratamento deste tipo de sistema. Com a evolução das aplicações em rede, que evoluíram dosimples correio eletrônico até o processamento de dados, som e imagem em tempo-real, foramintroduzidos requisitos temporais que devem ser considerados na construção e na execuçãodestas aplicações. A integração destas questões de tempo-real em sistemas abertos tem sidoobjeto de intensa pesquisa, mas ainda não se encontra devidamente estabelecida.

Este trabalho trata basicamente de aplicações com restrições de tempo-real em sistemasdistribuídos abertos, seguindo uma abordagem de melhor esforço (best-effort). Objetivandopermitir a programação de aplicações tempo-real em um ambiente distribuído e heterogêneo,adotamos um modelo de programação, o Modelo Reflexivo Tempo-Real (RTR), e integramosa este características da arquitetura CORBA e mecanismos para tratamento das questõestemporais presentes em sistemas distribuídos abertos.

Neste artigo descreveremos as características principais do resultado deste trabalho deintegração, o Modelo Reflexivo Tempo-Real Distribuído, e apresentaremos o mapeamento e aimplementação deste sobre uma plataforma composta pelo sistema operacional Solarisadicionado de um suporte compatível com o CORBA. Ao final do artigo, apresentamos umexemplo de aplicação de multimídia distribuída, consistindo basicamente em um sistema detransmissão de mídias sob demanda, implementado com o objetivo de demonstrar a adequaçãodo modelo na programação de aplicações distribuídas com requisitos temporais.

2 Sistemas Abertos e Tempo-Real

Requisitos como previsibilidade, correção temporal e performance precisam ser levadosem conta na construção de aplicações com características de tempo-real. Para que taisrequisitos sejam satisfeitos, torna-se necessária a adoção de mecanismos e políticas adequadaspara o controle das restrições temporais da aplicação e o gerenciamento dos recursos dosistema.

Em sistemas distribuídos abertos, por outro lado, é indispensável dispor de mecanismosque permitam a transparência em relação à distribuição e à heterogeneidade de equipamentos.Os meios acadêmico e industrial tem considerado como soluções satisfatórias para sistemasdistribuídos abertos a adoção de arquiteturas e suportes tais como CORBA [OMG 93], ODP eANSA [Li 94]. No entanto, aspectos relacionados a questões temporais não são consideradosnestas propostas de modelos e arquiteturas para sistemas abertos.

O tratamento de questões presentes em sistemas tempo-real no contexto de sistemasabertos é dificultada devido à existência de fatores conflitantes, mas não inconciliáveis. Deforma a integrar características de tempo-real em sistemas distribuídos abertos, devemosconsiderar os seguintes aspectos [Tak 92][Li 93] :

– não existe a possibilidade de sincronização dos relógios locais dentro dos níveis degranularidade desejáveis, o que impede que um tempo global seja utilizado naverificação de restrições presentes em sistemas tempo-real;

– os tempos relativos à comunicação não são delimitados, o que implica na adoção demecanismos probabilistas para determinação do tempo gasto na interação entre oscomponentes de uma aplicação distribuída;

– a carga de cada máquina nestes sistemas é dinâmica e imprevisível; com isto, nãopodemos impor garantias quanto à execução de nenhuma das atividades do sistemadentro do tempo desejado.

Diante destas características, pressupõe-se que a verificação do cumprimento dasrestrições temporais impostas às diversas atividades do sistema seja realizado com base norelógio local de cada componente da aplicação. A ausência de previsibilidade do sistema,tanto a nível local como global, impossibilita o uso de políticas que garantam a satisfaçãocompleta das restrições temporais, e leva à adoção de políticas de melhor esforço (best-effort)para o escalonamento das atividades do sistema.

Nas propostas de arquiteturas para sistemas abertos, as interações são estruturadasusualmente segundo o modelo cliente-servidor. O processamento tempo-real neste modeloimplica em restrições de tempo tanto no cliente quanto no servidor da aplicação. Estasrestrições são especificadas na forma de um timeout do lado cliente, quando da ativação deuma requisição de serviço, e na forma de um deadline quando da execução do serviçorequisitado do lado do servidor.

Algumas propostas de implementação de suportes para o processamento tempo-real emambientes abertos podem ser encontradas na literatura. Os sistemas RIDE e ANSAware/RT[Li 94], ambos implementações de modelo de objetos tempo-real ANSA, tratam as restriçõestemporais adotando os mecanismos citados acima (timeout, deadline), tendo como base seusrelógios locais. Nestas propostas, o escalonamento é realizado a nível de suporte deprogramação. RIDE e ANSAware/RT implementam os mecanismos para controle dasrestrições temporais e os algoritmos de escalonamento no suporte de execução. A alteração oua introdução de novos mecanismos ou algoritmos torna necessário efetuar modificações nopróprio suporte.

Por outro lado, em implementações do modelo CORBA sobre sistemas operacionaistempo-real, como ORBeline 2.0 e Orbix-RT*, é possível usufruir de mecanismos tempo-realdisponíveis no sistema hospedeiro. No entanto, não é acrescentada funcionalidade apropriadapara o tratamento de restrições temporais nas interações em sistema aberto. Para utilizar estessuportes de execução é indispensável que em todos os nodos do sistema sejam utilizadossuportes com características similares; esta exigência leva a uma escolha de um mesmo sistemaoperacional ou a introdução de camadas adicionais no suporte para proporcionarcompatibilidade entre suportes.

O modelo RTR trata as questões temporais nas interações em sistemas distribuídosabertos de forma similar aos suportes e modelos citados. Entretanto, se diferencia destes portratar os mecanismos de controle do tempo e o escalonamento tempo-real a nível de aplicação,independentemente do suporte de execução, o que aumenta a flexibilidade e permite maiorheterogeneidade a nível de suporte. Assim sendo, a abordagem apresentada neste artigopermite a alteração ou a introdução de novos mecanismos e algoritmos pelo programador, semque seja afetado o suporte ou o código da aplicação. Desta forma, a heterogeneidade a nível desuporte de execução pode ser garantida sem a necessidade de introduzir modificações nestenível.

3 Características do Modelo RTR Distribuído

3.1 O Modelo Reflexivo Tempo-Real

O modelo RTR [Fur 95], desenvolvido para expressar e implementar as restriçõestemporais em aplicações tempo-real, é fundamentado em conceitos de programação orientadaa objetos e reflexão computacional.

O paradigma reflexivo permite que um sistema execute processamento sobre si mesmo,para o ajuste ou a modificação de seu comportamento. A reflexão computacional é introduzidano modelo RTR através da abordagem de meta-objetos [Mae 87], [Fab 95],[Hon 94]. Segundo esta abordagem, “objetos-base” implementam a funcionalidade da

* ORBeline é marca registrada da Post Modern Computing. Orbix é marca registrada da Iona Technologies.

aplicação e “meta-objetos” executam procedimentos de controle sobre o comportamento daaplicação.

Os objetos-base tempo-real apresentam estrutura e comportamento similar ao dosobjetos convencionais. Adicionalmente, são associadas aos seus métodos restrições temporais(predefinidas ou construídas pelo programador) e manipuladores de exceção. Restriçõestemporais construídas pelo programador são declaradas no objeto-base e implementadasatravés de procedimentos no meta-objeto gerenciador correspondente.

Os aspectos relativos a restrições temporais e de sincronização, escalonamento tempo-real, e exceções temporais são tratados a nível-meta no modelo RTR. A nível-meta o modelopossui um meta-objetos gerenciador para cada objeto-base da aplicação, e mais dois meta-objetos especiais – meta-objeto escalonador e meta-objeto relógio.

Os meta-objetos gerenciadores são objetos multi-threadeds responsáveis pelogerenciamento dos pedidos de ativação dos métodos de seus objetos-base correspondentes,pelo controle de concorrência em um objeto-base, pelo gerenciamento das restrições desincronização e pelo processamento das restrições temporais, quando é efetivamente decididopela ativação do método solicitado ou pelo levantamento de uma exceção temporal.

Para cada pedido de ativação recebido pelo meta-objeto gerenciador, é ativada umanova thread de controle, viabilizando o tratamento concorrente dos pedidos e permitindo umtratamento mais efetivo das restrições temporais a eles associadas.

Por outro lado, um mecanismo de controle da concorrência garante a exclusão mútuano objeto-base, permitindo que somente um de seus métodos esteja em execução em umdeterminado momento. Este controle é realizado em função do estado do objeto-base, mantidoa nível de meta-objeto.

O meta-objeto escalonador tem como função básica receber, ordenar e liberar pedidosde escalonamento de métodos dos objetos base que compõem a aplicação de acordo comdeterminada política de escalonamento (predefinida ou introduzida pelo programador), visandosatisfazer as restrições temporais da aplicação dentro de uma política de melhor esforço. Destaforma, diferentes pedidos de escalonamento, originados de um ou vários meta-objetosgerenciadores, podem ser analisados globalmente e ordenados de acordo com a política deescalonamento vigente.

O meta-objeto escalonador recebe do meta-objeto gerenciador requisições deescalonamento de métodos com restrições temporais, e determina, de acordo com a política deescalonamento implementada e com as restrições temporais associadas, o momento a partir doqual o método em questão pode ser liberado para execução. Com a liberação para execução dométodo, em função da disponibilidade de tempo e observados os aspectos de sincronização econcorrência, o meta-objeto gerenciador decide pela liberação da execução do métodosolicitado ou pelo levantamento de uma exceção temporal. Em seguida, após a execução dométodo a nível-base, o controle é devolvido para o meta-objeto gerenciador, que libera ometa-objeto escalonador para que processe o próximo pedido da fila de requisições, e retornao resultado da execução do método para o objeto que efetuou a requisição.

O meta-objeto relógio é uma abstração do relógio do sistema, estruturada na forma deobjeto. Sua função básica é receber pedidos do meta-objeto gerenciador para ativar métodosnum tempo futuro, detectar violação de timeouts e eventuais violações de restrições associadascom métodos que estão aguardando para ser escalonados ou que aguardam o estabelecimentode concorrência ou sincronização.

Na figura a apresentamos a dinâmica de uma chamada de método em uma aplicaçãoestruturada segundo o modelo RTR, composta por um conjunto de objetos-base e meta-objetos gerenciadores.

META-OBJETO

RELÓGIO

¹¹

META-OBJETO

ESCALONADOR

5555555555

Meta-ObjetoGerenciador

Objeto-Base

Nível-MetaNível-Base

�

��

��

�

Meta-ObjetoGerenciador

Objeto-Base

Meta-ObjetoGerenciador

Objeto-Base

Figura A – Estrutura Geral do Modelo RTR

A interação entre objetos-base e meta-objetos do modelo inicia com um pedido deativação de um método de um determinado objeto-base, que é desviado para seu meta-objetogerenciador correspondente (ação � da figura a). O meta-objeto gerenciador, por sua vez,interage com o meta-objeto escalonador (ação �) e com o meta-objeto relógio (ação �) paraprocessar as restrições temporais associadas ao método solicitado, e se estas restrições nãoforem violadas, ativa o método solicitado no objeto-base (ação �), retornando em seguida, viameta-objeto gerenciador para o objeto que deu origem a chamada (ações � e �).

3.2 Incorporação da Distribuição ao Modelo RTR

As interações entre os componentes do modelo RTR seguem o paradigma cliente-servidor. Objetos são divididos em nível-base e nível-meta tanto no cliente quanto no servidorda aplicação. Em cada nodo do sistema temos, além dos pares de objetos-base e meta-objetosgerenciadores, um meta-objeto relógio e um meta-objeto escalonador [Fra 95].

No modelo RTR distribuído o escalonamento é tratado a nível local. Desta forma, cadanó possui um meta-objeto escalonador que trabalha independentemente na rede, influenciandoapenas o escalonamento local. As tarefas são primeiro alocadas aos nodos do sistema paraposteriormente serem escalonadas segundo critérios locais [Aud 90].

O escalonamento no Modelo RTR Distribuído ocorre em dois níveis distintos. Em umprimeiro nível, há o escalonamento de métodos de objetos-base realizado pelo meta-objetoescalonador. Em um nível mais baixo há o escalonamento realizado pelo núcleo do sistemaoperacional subjacente.

De modo semelhante, cada nó do sistema possui um meta-objeto relógio local, quetrabalha independentemente dos outros relógios localizados nos demais nós da rede. Em umarequisição de método, tanto o objeto cliente quanto o servidor do método verificam ocumprimento de restrições temporais utilizando um meta-objeto relógio. O cliente verifica ocumprimento do timeout da chamada com base no meta-objeto relógio local, enquanto oobjeto servidor controla o deadline do método.

Obtemos a desejada interoperabilidade entre componentes distribuídos heterogêneos dosistema incorporando a funcionalidade da arquitetura CORBA ao modelo RTR.

3.2.1 A Arquitetura CORBA

CORBA (Common Object Request Broker Architecture) é um conjunto de padrões econceitos propostos pela OMG (Object Management Group) para sistemas abertos. Naarquitetura proposta, requisições de métodos de objetos são feitas transparentemente em umambiente distribuído e heterogêneo através do ORB (Object Request Broker).

A especificação CORBA [OMG 93] define as interfaces do ORB e estabelece o papelde cada um de seus componentes no ambiente distribuído. As interfaces CORBA sãoespecificadas como uma camada, mascarando diferenças entre as diversas implementaçõespossíveis.

Em um ambiente CORBA, cada objeto tem sua interface especificada na linguagemIDL (Interface Definition Language), uma linguagem puramente declarativa com sintaxe etipos predefinidos baseados na linguagem C++. Para requisitar a execução de um método, umcliente CORBA utiliza stubs geradas na compilação da especificação de interface IDL doobjeto servidor, ou pode construir uma requisição utilizando a interface de invocação dinâmicaDII (Dynamic Invocation Interface). Para permitir invocações dinâmicas, interfaces de objetosdevem ser armazenadas em um depósito de interfaces (Interface Repository).

O ORB implementa semânticas e abstrações da comunicação entre objetos na rede; eletransmite a requisição através da rede e transfere o controle para um adaptador de objetos,utilizado para ativar a operação na implementação do objeto (ou seja, no servidor) através deskeletons IDL. O objeto servidor trata a requisição da mesma forma, independentemente domecanismo de invocação de método utilizado – estático (stubs) ou dinâmico (DII).

3.2.2 Objetos-Base e Meta-Objetos de Comunicação

Na chamada remota de métodos, interfaces CORBA (stubs, DII e skeletons) sãotransparentes para objetos-base. Aspectos referentes à comunicação remota entre processossão tratados por meta-objetos adicionais de comunicação, que encapsulam os aspectosreferentes às interfaces ORB.

As chamadas de métodos remotos originadas de um objeto-base são redirecionadaspara MetaStubs, que modificam as stubs geradas pelo compilador IDL-CORBA de modo atratar os requisitos temporais de aplicações tempo-real. MetaStubs são responsáveis por,interagindo com o meta-objeto relógio, controlar o timeout das chamadas de métodos doobjeto-base. Como alternativa à chamada por stubs, pode ser utilizada a interface de invocaçãodinâmica (DII) do CORBA e o meta-objeto MetaDII.

As chamadas de métodos originárias de objetos remotos e destinadas a um determinadoobjeto do modelo são recebidas através de skeletons e de MetaSkeletons, que modificam afuncionalidade dos skeletons gerados pelo compilador IDL. Estes objetos recebem a requisiçãoatravés do ORB e chamam o respectivo método no objeto-base. Esta chamada é desviada parao meta-objeto correspondente de modo a estabelecer o protocolo definido pelo modelo deobjetos tempo-real, impondo restrições temporais e de sincronização através da interação como meta-objeto escalonador e com o meta-objeto relógio de seu nodo.

Em uma aplicação distribuída, um cliente pode utilizar serviços de diferentesservidores; isto implica que o cliente precisa de um MetaStub para cada servidor do modelo.Se a ligação entre cliente e servidor for dinâmica, um MetaDII é suficiente; o cliente estabelece

conexões com servidores utilizando a mesma interface DII CORBA. Da mesma forma,servidores podem suportar vários MetaSkeletons. A estrutura do modelo construído segundouma arquitetura CORBA é apresentada na figura b.

OBJECT REQUEST BROKER

SERVIDORCLIENTE

Meta Stub / DIIMeta Stub / DIIMeta-ObjetoGerenciador

Objeto-Base

Meta-Objeto deComunicação

(MetaStub/DII)

Meta Stub / DIIMeta Stub / DIIObjeto-Base deComunicação

(Stub/DII)

Meta Stub / DIIMeta Stub / DII Meta-ObjetoGerenciador

Objeto-Base

Meta-Objeto deComunicação

(MetaSkeleton)

Meta Stub / DIIMeta Stub / DIIObjeto-Base deComunicação

(Skeleton)

META-OBJETO

RELÓGIO

¹¹

META-OBJETO

ESCALONADOR

5555555555

META-OBJETO

RELÓGIO

¹¹

META-OBJETO

ESCALONADOR

5555555555

Nível-MetaNível-Base

Nível-MetaNível-Base�

���

��� �

��

�

���

�

Figura B – Estrutura do Modelo RTR em uma Arquitetura CORBA

3.2.3 Comportamento da Comunicação no Modelo

O suporte de comunicação pode tratar chamadas de métodos síncronas e assíncronas.Na figura b é mostrado o comportamento dos componentes do modelo no caso a umachamada síncrona. No cliente, a chamada de um método do objeto-base servidor deve estipularas restrições temporais e procedimentos de exceção para o caso destas restrições seremvioladas, em uma estrutura como a que segue abaixo:

< id-objeto-servidor > . < id-método > ( < parâmetros > ),Timeout ( < valor-do-timeout > ),Exception{

case reject : < procedimento-de-exceção >case abort : < procedimento-de-exceção >case timeout : < procedimento-de-exceção >

}

Em sistemas abertos, além das exceções reject (restrição violada antes do início daexecução do método do objeto-base) e abort (execução do método já havia sido iniciada)definidas pelo modelo RTR, deve ser previsto um novo tipo de exceção de modo a indicar aocorrência de uma violação do timeout imposto pelo cliente. A exceção timeout é detectadapelo cliente com o auxílio do meta-objeto relógio e comunicada ao meta-objeto servidoratravés do suporte de comunicação.

A chamada realizada pelo cliente é encaminhada via um MetaStub para o servidor aoqual se destina a requisição (ação � da figura b). O MetaStub requisita o método chamadopelo objeto-base através do ORB utilizando stubs (ação �), e envia ao meta-objeto relógio ovalor de timeout associado à chamada (ação �). O MetaStub passa a aguardar uma mensagemde resposta do servidor, ou do meta-objeto relógio, sinalizando uma violação de timeout.

A requisição do método chega ao servidor correspondente através do ORB, que ativa ométodo utilizando skeletons CORBA e MetaSkeletons. A ativação é desviada para o meta-objeto gerenciador do servidor (ação � da figura b), que interage com o meta-objeto

escalonador do servidor (ação �), aguardando por uma autorização para ativar o métodorequisitado. Quando o meta-objeto escalonador sinaliza que o método deve ser executado, ometa-objeto gerenciador do servidor verifica se as restrições temporais (ação �) e desincronização foram violadas, retornando uma exceção reject neste caso. Caso contrário, ométodo é chamado no objeto-base do servidor (ação �). Concluída a chamada, ocorrenovamente a verificação das restrições temporais, resultando em uma exceção abort casoestas tenham sido violadas. O resultado da chamada é enviado na forma de parâmetros aoobjeto-base do cliente, passando através do ORB (usando stubs e skeletons) e de MetaStub(ações �, �e �).

No caso de, antes da finalização do protocolo, o meta-objeto relógio reportar aMetaStub uma violação de timeout (ação � da figura b), uma indicação de exceção é enviadaao objeto cliente (ação �). Em seguida, MetaStub remete através do ORB e do MetaSkeletona indicação de exceção do tipo timeout ao meta-objeto gerenciador do servidor (ações �, �e �), que se encarrega de cancelar a execução do método, retirando a requisição da fila depedidos do escalonador ou interrompendo a execução do método no objeto-base.

Utilizamos uma estrutura semelhante na implementação da chamada assíncrona,permitindo no entanto que o objeto-base do cliente continue seu processamento assim queefetuada a chamada. Caso o cliente venha a necessitar futuramente de dados de respostaprovenientes da execução do método no servidor (ou seja, em uma chamada do tipo semi-síncrona), este pode verificar se a resposta se encontra disponível em um momento posterior,ou mesmo bloquear-se à espera da chegada da resposta.

4 Mapeamento e Implementação do Modelo

4.1 Mapeamento do Modelo RTR Distribuído

Para testar a potencialidade do Modelo RTR, realizamos o mapeamento das abstraçõesdefinidas pelo modelo para elementos do sistema operacional Solaris*. O Solaris possuicaracterísticas que o tornam adequado para utilização em ambiente tempo-real, como ummecanismo de escalonamento baseado em prioridades e classes de escalonamento, dentro dasquais vigoram políticas distintas; bloqueio de páginas de memória; operações de entrada esaída assíncronas; e multi-threading.

Cada par composto por um objeto-base e seu meta-objeto gerenciador, juntamentecomo os objetos adicionais de comunicação utilizados na interação com outros objetos domodelo – stubs e MetaStubs, MetaDII, skeletons e MetaSkeletons – corresponde a umprocesso Solaris. Meta-objeto escalonador e meta-objeto relógio são implementados emprocessos distintos.

Utilizamos threads para permitir concorrência interna nos meta-objetos, em conjuntocom ORBs que possibilitem o multi-threading em objetos CORBA. Desta forma, váriasrequisições poderão ser processadas simultaneamente pelo meta-objeto. Cada meta-objeto domodelo RTR deve possuir threads de gerenciamento, responsáveis pela interação com o ORB,recebendo e enviando requisições de métodos, e pela criação de uma thread de dispatch paracada invocação de método do objeto. As threads de dispatch de métodos processam as

* Solaris é uma marca registrada da Sun Microsystems

requisições recebidas pelos objetos, tratando-as segundo o modelo RTR distribuído conformeespecificado na seção 3.2.3.

Objetos do modelo devem pertencer à classe de escalonamento Real-Time (RT)Solaris, com quantum de tempo infinito (ou seja, tempo de execução do processo ilimitado). Aatribuição de prioridades tempo-real aos processos aos quais pertencem os objetos-base emeta-objetos do modelo ocorre durante a criação do meta-objeto.

Através do estabelecimento de prioridades utilizadas pelo Solaris no escalonamento aprocessos e threads, em conjunto com a utilização do meta-objeto escalonador para determinara ordem a ser obedecida na execução dos métodos requisitados, será obtido o comportamentodesejado dos objetos da aplicação em conformidade com o especificado pelo modelo.

Se analisarmos apenas o processamento de métodos a nível-base, haverá ‘preempção’de métodos dos objetos-base somente quando o método em execução chamar de modosíncrono um outro método com restrições de tempo associadas, e residente em outro objeto –ou seja, em caso de chamadas aninhadas. Neste caso, será processada a chamada, o métodoaguardará a execução desta, mas o suporte deve impedir que aconteça a execução de um outrométodo do mesmo objeto em nível-base devido às restrições de exclusão mútua que devem sergarantidas no objeto-base.

Enquanto estiverem somente processando requisições de métodos a nível-meta, osprocessos com objetos do modelo devem possuir uma mesma prioridade fixa. No caso doprocesso receber a liberação do meta-objeto escalonador para executar um método a nível-base, este deve modificar sua prioridade para o valor que lhe for atribuído pelo escalonador,situado dentro de uma faixa de prioridades de nível-base, que será determinado em função donúmero de objetos suspensos aguardando o retorno de chamadas síncronas aninhadas naquelenodo da rede. Deste modo, garantimos que o objeto que realizou a chamada aninhada iráreassumir o processador assim que terminar a execução do método requisitado.

4.2 Implementação do Modelo RTR Distribuído

A implementação do protótipo do modelo RTR distribuído foi realizada sobre osistema operacional Solaris versão 2.4. Para suprir as necessidades do modelo relacionadas àutilização de uma plataforma CORBA, empregamos o ORBeline 1.0, uma implementaçãocomercial de ORB de responsabilidade da Post Modern Computing. O ORBeline 1.0 écompatível com a primeira versão da especificação CORBA e de acesso gratuito parauniversidades e institutos de pesquisa.

O protótipo do modelo RTR se encontra em pleno funcionamento. Foram necessáriasalgumas restrições e simplificações em relação ao mapeamento do modelo RTR distribuído,devido às limitações encontradas no suporte utilizado (não-disponibilidade de threads e bugsencontrados no ORBeline). Desta forma, alguns aspectos não puderam estar presentes naimplementação do protótipo.

Foi suprimida a concorrência interna dentro do meta-objeto devido à impossibilidade deutilização de threads juntamente com o ORBeline. Deste modo, cada meta-objeto podeatender somente uma requisição por vez, resultando na criação de uma fila com ordenaçãoFIFO onde são armazenadas as requisições de métodos que chegam a um determinado objeto-base. A concorrência entre requisições direcionadas a objetos-base diferentes continuaexistindo e seguindo a política de escalonamento implementada no meta-objeto escalonador domodelo.

Os valores de restrições e exceções temporais, que inicialmente deveriam sertransmitidos respectivamente na forma de objetos de contexto e exceções CORBA, forampassados como parâmetros adicionais de chamada, devido a problemas tanto nos objetos decontexto quanto nas exceções implementadas no ORBeline 1.0. Desta forma, os métodosdescritos na declaração de interface de um objeto ganharam um parâmetro adicional, visívelapenas nos meta-objetos gerenciadores e de comunicação, adicionado posteriormente aosparâmetros originais do método.

Devido à inexistência de um suporte para threads no ORB, os meta-objetos decomunicação foram implementados utilizando a interface de invocação dinâmica e o depósitode interfaces do ORBeline. O comportamento desejado nas chamadas de métodos de objetosdo modelo foi obtido através da utilização de MetaDII, implementado através de sobrecarga defunção nas requisições criadas pela interface de invocação dinâmica. Se forem utilizadas stubs,o cliente deve optar em tempo de compilação pela utilização das stubs originais geradas pelocompilador IDL-CORBA, ou optar por MetaStubs que implementem a funcionalidade domodelo que utilizem MetaDII de maneira transparente.

Os objetos-base são implementados como objetos C++ (e não objetos CORBA),enquanto somente os meta-objetos gerenciadores correspondentes são visíveis externamentedo ponto de vista do CORBA.

Cada meta-objeto gerenciador possui um apontador direcionado para o objeto-basecorrespondente, possibilitando o acesso aos métodos de nível-base. O objeto-base não recebedo meta-objeto os parâmetros relativos às restrições temporais, o que garante a transparênciaem sua programação.

O meta-objeto gerenciador interage com os meta-objetos adicionais do modelo – meta-objeto escalonador e meta-objeto relógio – através de stubs de comunicação, que simplificam ainteração com os referidos meta-objetos do ponto de vista do programador da aplicação anível-meta.

5 Desenvolvimento de Aplicações Utilizando oModelo

O desenvolvimento de aplicações distribuídas segundo o modelo reflexivo tempo-realsegue as etapas ilustradas na figura c.

Consiste em uma obrigação do usuário escrever o código da aplicação a nível-meta enível-base, de maneira a definir a funcionalidade do objeto e os mecanismos de controle aosquais o mesmo deve ser submetido. Adicionalmente, no protótipo do modelo implementadoneste trabalho, o usuário deve descrever a interface do servidor da aplicação em linguagemIDL e, como não dispomos de um gerador de código para MetaStubs e MetaSkeletons a partirda especificação IDL, a codificação dos meta-objetos de comunicação também deve serrealizada pelo programador da aplicação.

O suporte provido pelo protótipo do modelo RTR distribuído simplificaconsideravelmente a programação a nível-meta através da utilização de restrições temporais,procedimentos de exceção e métodos de gerenciamento predefinidos, contidos em umabiblioteca, que podem ser incorporados ao código da aplicação no procedimento de‘linkagem’. Para os casos em que o cliente da aplicação utilizar a interface de invocaçãodinâmica (DII) na interação com o servidor, basta para o programador incluir um arquivo como código de MetaDII no meta-objeto cliente, tornando desnecessária a codificação de qualquerobjeto adicional além do código do cliente nos níveis base e meta.

SERVIDORDA APLICAÇÃO

CLIENTEDA APLICAÇÃO

CódigoFonte do

MetaSkeleton

Compilador IDL - CORBA

Cód. Fontedo Obj-Base

Cliente

CódigoFonte dasMetaStubs

Cód. Fontedo Meta-Obj

Cliente

Compilador da Linguagem (C, C++, Java, ...)

CódigoExecutáveldo Cliente

CódigoFonte doSkeleton

Descrição deInterface IDLdo Servidor

Base

CódigoFonte das

Stubs

Cód. Fontedo Obj-Base

Servidor

Cód. Fontedo Meta-Obj

Servidor

CódigoObjeto do

MetaSkeleton

Cód. Objetodo Obj-Base

Cliente

CódigoObjeto dasMetaStubs

Cód. Objetodo Meta-Obj

Cliente

CódigoObjeto doSkeleton

CódigoObjeto das

Stubs

Cód. Objetodo Obj-Base

Servidor

Cód. Objetodo Meta-Obj

Servidor

Linker do Sistema

CódigoExecutáveldo Servidor

Figura C – Desenvolvimento de Aplicações Distribuídas no Modelo RTR

6 Exemplo de Aplicação do Modelo RTR Distribuído

Ilustraremos o uso do modelo proposto através de uma exemplo de aplicação. Oexemplo escolhido consiste na exibição de um documento multimídia, onde dados de diversasmídias são obtidos de servidores localizados em diferentes nodos de uma rede heterogênea.

A forma proposta para implementação do exemplo de exibição de um documentomultimídia segue o modelo cliente-servidor. A figura d mostra a obtenção progressiva e oesquema de apresentação de um documento multimídia, envolvendo diferentes servidores demídia : som, imagem, texto, e possivelmente outras mídias.

O arquivo descrevendo o documento a ser composto é armazenado em uma base dedados local, que contém informações acerca das partes dos documentos, seus tempos deapresentação, e o cenário relativo à sincronização das mídias. A partir deste cenário, oprograma de composição do documento cria os clientes de cada mídia contida no documento.

Os clientes são os elementos responsáveis pela obtenção e exibição de uma mídiaespecífica. Cada cliente de uma determinada mídia utilizada no documento deve requisitar aoservidor correspondente, receber e armazenar em buffers a informação descrevendo a mídiaem questão. Cada cliente deve possuir dois buffers para evitar a descontinuidade naapresentação, solucionando problemas como jitter e overhead. Enquanto um dos buffersestiver sendo esvaziado, o outro deve ser preenchido com informações da mídia recebida.

Os dados são fornecidos ao cliente e reunidos para a construção do documentomultimídia. Os dados do documento são obtidos e apresentados pelos clientes de mídia em‘tempo-real’ – ou seja, os dados são exibidos assim que recebidos do servidor.

Os servidores atuam em um esquema de fornecimento de mídia sob demanda, ou seja,os dados são enviados ao cliente quando for recebida uma requisição. Desta forma fazemoscom que o servidor respeite o fluxo de execução e a taxa de transmissão de dados impostospelo cliente.

Estação A Estação B Estação C

Servidorde Texto ���

���

Servidorde Som

Cliente de Som

Composição doDocumento Multimídia

Servidorde Imagem

Clientede Imagem

Clientede Texto

Figura D – Exemplo de Aplicação do Modelo RTR Distribuído

A forma de armazenamento de dados utilizada – disco rígido, fita, CD, ou qualqueroutro dispositivo de armazenamento de informação – compete exclusivamente ao servidor demídia. O cliente de uma determinada mídia conhece apenas a interface do servidorcorrespondente, recebendo os dados referentes à mídia através de requisições de serviçoenviadas a este servidor.

Mecanismos de sincronização entre as mídias podem ser utilizados neste tipo deaplicação, com o objetivo de manter uma relação de sincronismo imposta pelo documentomultimídia entre as diversas mídias utilizadas. Em muitos casos, pode haver a necessidade desincronização entre imagem e som (para sincronização de lábios), ou imagem e texto(legendas), por exemplo.

6.1 Estrutura da Solução

Foram implementados pares cliente-servidor para áudio e imagem. Os servidores deáudio e imagem possuem uma mesma estrutura, recuperando a informação relativa à mídia naforma de arquivos armazenados em disco. O servidor possui operações de abertura doarquivo, leitura de parte do arquivo, e retrocedimento até o início do mesmo.

Os clientes foram implementados utilizando código de software de domínio públicopara exibição das mídias de modo centralizado (não distribuído). Isto mostra a perfeitaadequação do modelo para reutilização de software de modo simples e flexível. Devido àscaracterísticas do modelo RTR, não foram necessárias alterações no corpo destes programaspara adaptação ao ambiente distribuído e para controle de requisitos temporais, pois estasalterações puderam ser realizadas a nível-meta. Alterações na funcionalidade dos programas,efetuadas a nível-base, foram necessárias principalmente para suprimir o tratamento local damídia (leitura de arquivos substituída por chamadas aos servidores) e para permitir a exibiçãoda mídia antes do recebimento de toda a informação.

Para emissão de áudio foi utilizado o código do programa de domínio público Xplay(versão 0.7, © Robert S. Thau, MIT AI Lab), adicionado de algumas adaptações necessáriaspara permitir a emissão do som de modo simultâneo ao recebimento dos dados (a versão

original do Xplay só emite o som após a leitura completa do arquivo). O programa Xplaypode manipular arquivos nos formatos Sun Audio, Windows Wave, e AIFF, e possui umainterface gráfica de acordo com o padrão Motif ®, permitindo operações de pausa, retorno eavanço do som, controle de volume e do dispositivo de saída utilizado (alto-falante ou fone deouvido).

Para exibição da imagem utilizamos um decodificador de arquivos no formato MPEG,o programa de domínio público mpeg_play (versão 2.0, © Computer Science Division,University of California at Berkeley). A versão utilizada adota uma interface gráfica Motif ®para o mpeg_play (© The Geometry Center; University of Minnesota), com comandos depausa, avanço quadro a quadro e retrocesso da imagem. Adicionalmente, existe a possibilidadede, no momento da chamada do programa, especificar os algoritmos de dithering que devemser utilizados na decodificação e exibição da imagem.

6.2 Implementação do Exemplo sobre o Modelo RTR Distribuído

O paradigma reflexivo adotado pelo modelo implica que os clientes e servidoresapresentados na figura d devem ser implementados na forma de objetos-base e meta-objetos.

Os clientes de mídia devem especificar as restrições temporais impostas ao processo derecuperação da mídia armazenada no servidor. Os valores das restrições temporais devem serobtidos em função da qualidade de serviço exigida pelo cliente, considerando fatores como otempo necessário para que não ocorram interrupções perceptíveis na exibição da mídia naestação cliente e a quantidade de dados disponíveis no buffer do cliente aguardando para serexibidos.

Neste exemplo foi utilizado o meta-objeto escalonador que implementa a política deescalonamento tempo-real com base em deadlines (EDF - Earliest Deadline First). A políticautilizada mostrou-se adequada para este tipo de aplicação.

6.2.1 A Descrição de Interface do Servidor

Um descrição de interface IDL para o objeto servidor de mídia é apresentada nalistagem a. A tradução desta interface IDL gera os objetos-base stub e skeletons para oservidor de mídia.

No arquivo IDL que descreve a interface do servidor de mídia foi declarado o tipoBufType, utilizado pelo buffer através do qual a mídia é transmitida ao cliente, como sendouma seqüência do tipo octet, um tipo definido pelo CORBA de tamanho igual a um byte(oito bits) e que não sofre nenhum tipo de conversão de dados na sua transmissão.

#include “RTparams.idl”

interface media{ typedef sequence<octet> BufType;

long open_media ( in string name, inout RTparams rt ); void rewind_media ( inout RTparams rt ); long read_media ( out BufType buffer, in long length, inout RTparams rt );};

Listagem A – Interface IDL para o Servidor de Mídia

São declaradas na interface do servidor operações de abertura do processo detransmissão de uma determinada mídia (open_media), retorno ao início da mídia(rewind_media) e leitura de uma quantidade de dados especificada pelo cliente referente àmídia em questão (read_media).

Aspectos relacionados à implementação do mecanismo de transmissão de parâmetros eexceções temporais são tratados no arquivo incluído ‘RTparams.idl’.

6.2.2 Descrição do Servidor de Mídia

A funcionalidade dos servidores de mídia, implementada a nível-base, consiste apenasem recuperar a informação relativa à mídia em questão que se encontra armazenada emarquivos codificados segundo um determinado padrão. A informação recuperada deste arquivoé enviada ao cliente, que deve decodificar a informação e exibir a mídia.

class media_server{ /* Global file pointer to incoming data. */ FILE *input;

/* public methods */ public: media_server () { input = NULL; }

CORBA::Long open_media ( const CORBA::String& name ); void rewind_media (); CORBA::Long read_media ( media::BufType*& buffer,

CORBA::Long length );

};

Listagem B – Descrição do Objeto-Base Servidor de Mídia

Na listagem b apresentamos a descrição do objeto-base servidor de mídia,implementado em C++. Como tanto áudio e imagem são armazenados e transmitidos damesma maneira (através de arquivos decodificados pelo cliente), o mesmo servidor é utilizadopara ambas as mídias.

Em cada servidor de mídia, a operação de obtenção dos dados é vista como umaoperação aperiódica, e um deadline especifica o tempo máximo dentro do qual a operaçãodeve ser executada.

A verificação de restrições temporais e de sincronização, e o tratamento de exceções,assim como a comunicação entre objetos via ORB, são tratados a nível-meta.

A listagem c apresenta a descrição do meta-objeto servidor de mídia. Como podemosobservar, este objeto herda as operações de interfaceamento com o ORB a partir da classemeta_impl, gerada pelo compilador IDL-CORBA. Em adição aos parâmetros do objeto-base, este meta-objeto recebe como último parâmetro de cada uma das três operaçõesdefinidas em sua interface um descritor rt, do tipo RTparams, onde são especificados osvalores das restrições temporais impostas na execução do método e indicada a ocorrência deuma exceção temporal, se for o caso.

class MetaMedia : public media_impl{ /* Base-Object */ media_server media_base;

/* public methods */ public: MetaMedia ( const char *object_name );

CORBA::Long open_media ( const CORBA::String& name , RTparams& rt );

void rewind_media ( RTparams& rt ); CORBA::Long read_media ( media::BufType*& buffer,

CORBA::Long length, RTparams& rt );

};

Listagem C – Descrição do Meta-Objeto Servidor de Mídia

Na listagem d apresentamos o método open_media do meta-objeto do servidor. Estemétodo processa a requisição recebida do cliente e interage com os meta-objetos escalonador erelógio de modo a estabelecer o comportamento desejado pelo modelo conforme a política demelhor esforço para execução do método a nível-base.

CORBA::Long MetaMedia::open_media ( const CORBA::String& name ,RTparams& rt )

{CORBA::Long ret; // valor de retorno do método

// Inicia contador do meta-objeto relógiometaclock.start_time();

// Aguarda permissão para executar do meta-obj escalonadormetasched.getprio(rt.deadline());

// Avalia se existe tempo para executar o métodoif( (rt.deadline() !=0) && ( (metaclock.get_time()+rt.tme()) > rt.deadline() ) ) {

rt.exc(REJECT); // Não há tempo → rejeitar} else { // Há tempo // Muda prioridade para a definida pelo escalonador metasched.raiseprio();

// Executa o método do objeto-base ret = media_base.open_media(name);

// Verifica o tempo total gasto na execução do método if ( ( rt.deadline() != 0 ) && ( metaclock.get_time() > rt.deadline() ) ) {

rt.exc(ABORT); // Deadline violado → abortar }}

// Devolve a permissão ao escalonador e retornametasched.release();return ret;

}

Listagem D – Método open_media do Meta-Objeto Servidor de Mídia

6.2.3 Descrição dos Clientes de Mídia

Os objetos de nível-base dos clientes recebem os dados dos servidores e exibem estamídia na estação do usuário, utilizando dispositivos periféricos como o alto-falante e omonitor. O código destes objetos consiste basicamente nos programas de exibição de mídiascitados anteriormente.

A cada requisição enviada por um cliente a um servidor de mídia, um valor de timeoutexpressa o tempo de espera aceitável do cliente para estes dados. A verificação e o tratamentode exceções são realizados no objeto-base. Em caso de uma exceção do tipo reject, oestado do servidor não é alterado e o cliente pode tentar executar a requisição novamente,desde que respeitadas as restrições impostas. No caso de exceções do tipo abort outimeout, o estado do servidor foi alterado e o cliente não pode continuar o procedimento deexibição da mídia sem perda de informação, devendo então indicar a exceção e interromper suaexecução.

A listagem e mostra a forma como o objeto-base do cliente de imagem, implementadona linguagem C++, requisita ao servidor correspondente a mídia armazenada na forma de umaarquivo MPEG. O cliente especifica o número máximo de bytes que devem ser lidos(parâmetro num_bytes) e as restrições temporais associadas (parâmetro rt, do tipoRTparams). A informação lida é depositada em um buffer (mybuf) e a chamada retorna onúmero de bytes lidos (num_read). Através do campo de indicação de exceções exc doparâmetro rt é verificado se ocorreu alguma violação de exceção temporal.

... num_read = mediaserv->read_media ( mybuf, num_bytes, rt ); switch ( rt.exc() ) { case NONE : break; case REJECT : cerr << “Exception REJECT raised “ << “reading MPEG media" << endl; return(0); case ABORT : cerr << “Exception ABORT raised “ << “reading MPEG media" << endl; exit(1); case TIMEOUT: cerr << “Exception TIMEOUT raised “ << “reading MPEG media" << endl; exit(1); default : cerr << “Timing exception unknown “ << “reading MPEG media" << endl; exit(1); } ...

Listagem E – Abertura do Arquivo de Mídia no Cliente de Imagem MPEG

A nível-meta os clientes implementam a semântica de comunicação do modelo,utilizando o ORB, e controlando as restrições impostas à execução das chamadas remotas demétodos.

6.2.4 Meta-Objetos de Comunicação

Os meta-objetos de comunicação – MetaStub e MetaSkeleton – interagem com osuporte de comunicação provido pelo ORB, modificando o comportamento de stubs eskeletons gerados pelo compilador IDL.

No protótipo implementado, MetaStubs utilizam a interface de invocação dinâmicapara fazerem uma requisição de um método de um servidor remoto. Não houve necessidade de

alterar o comportamento dos skeletons IDL, o que implicou na utilização de MetaSkeletonsnulos, que apenas repassam as chamadas recebidas ao meta-objeto do servidor.

A implementação do método open_media da MetaStub do servidor de mídia émostrada na listagem f.

#include <media_c.hh>#include "MetaDII.h"...CORBA::Long media::open_media( const CORBA::String& name, RTparams& rt, CORBA::Environment& _env){static CORBA_DII::Request *req = NULL; // requisiçãoCORBA::Long ret; // valor retornado

// Cria requisição e faz o bind com o servidorif ( req == NULL ){

req = CORBA_DII::Request::create("media","open_media", "testrep", _env);if ( _env.check_exception() ) {

handle_exception( _env );return (0);

}

req->bind(this->_object_name());_env = req->_environment();if ( _env.check_exception()) {

handle_exception( _env );return(0);

} }

// Atribui os valores dos argumentos da chamada (parâmetros)req->arg((CORBA::Long)0, new CORBA::ValueString(name) );req->arg(1)->member("timeout") = rt.timeout();req->arg(1)->member("deadline") = rt.deadline();req->arg(1)->member("exc") = (CORBA::Long)rt.exc();

// Invoca o método com o timeout especificadoreq->invoke( rt.timeout() );

// Atualiza exceção com valor retornado pelo servidorrt.exc ( (timing_exception_id)req->arg(1)->member("exc") );

// Obtém o valor retornado pelo método do servidorif (rt.exc() == NONE ) ret = (CORBA::Long)(*req->result());

return ret;}...

Listagem F – MetaStub para o Objeto Servidor de Mídia

6.3 Considerações Relativas à Implementação

A solução adotada para resolver o problema de transferência de mídias em um sistemaaberto para a composição de um documento multimídia mostra algumas das características do

modelo reflexivo tempo-real distribuído que facilitam a programação de aplicações comrestrições temporais em sistemas abertos.

A análise da implementação realizada sobre o protótipo do modelo RTR distribuídonos leva a fazer as seguintes constatações em relação à programação da aplicação :

– O projeto da aplicação tem como ponto de partida técnicas de orientação a objetotradicionais e bem conhecidas pelos programadores, não introduzindo novas abstraçõesou conceitos de difícil compreensão.

– O modelo permite um alto grau de reutilização de código de aplicações já existentes naimplementação da funcionalidade dos objetos-base – neste exemplo, podemos constatartal fato nos objetos-base de exibição de mídia. A programação destes objetos-base nãosofreu grandes alterações derivadas da distribuição intrínseca do sistema, e nem mesmodevido aos requisitos de tempo-real exigidos da aplicação.

– A transparência na programação a nível-base, tanto no cliente quanto no servidor daaplicação, são fatores de vital importância para permitir ao programador preocupar-sesomente com a implementação da funcionalidade da aplicação na definição docomportamento do objeto-base. Estudos mostram que a solução de grandes problemasé bastante facilitada quando estes são divididos em problemas menores que podem sersolucionados isoladamente.

– A forma na qual foi estruturada a aplicação conduz a um grande índice de flexibilidadede programação. Componentes podem ser trocados, inseridos ou removidos semimplicar em modificações em diversas partes do código da aplicação.

– A troca da política de escalonamento utilizada pode ser efetuada através da simplessubstituição do meta-objeto escalonador por um outro. A manutenção da interfaceutilizada pelos meta-objetos gerenciadores para comunicação com o meta-objetoescalonador garante que não serão necessárias alterações no código da aplicação.

– A manutenção do sistema fica bastante simplificada, pelo fato de a aplicaçãopropriamente dita, implementada a nível-base, estar separada dos mecanismos desuporte que permitem a comunicação no ambiente distribuído e o controle dosrequisitos temporais da aplicação, efetuados pelos meta-objetos. Um programador, semtomar conhecimento do código a nível-meta, pode realizar a manutenção do software anível-base. De modo semelhante, a correção do comportamento temporal ou doprotocolo de comunicação exigem conhecimento apenas dos meta-objetos utilizados,abstraindo completamente a funcionalidade da aplicação.

– Restrições temporais e meta-objetos (inclusive escalonador, relógio e meta-objetos decomunicação) podem ser reutilizados em outras aplicações implementadas de acordocom o modelo RTR.

7 Conclusões e Perspectivas

Este artigo descreveu um modelo de programação de aplicações tempo-real emsistemas distribuídos abertos, o Modelo Reflexivo Tempo-Real (RTR) Distribuído, seumapeamento e implementação sobre uma plataforma de execução, e o desenvolvimento deuma aplicação tempo-real utilizando o referido modelo.

O Modelo RTR permite que mecanismos de controle de restrições temporais e políticasde escalonamento adequados às necessidades específicas de uma aplicação sejam introduzidose/ou modificados diretamente pelo programador da aplicação a nível-meta, sem implicar em

alterações no código da aplicação ou no suporte de execução, conforme visto no exemplo deaplicação.

Em adição à flexibilidade provida pela possibilidade de programação em nível-meta, ouso de reflexão computacional no Modelo RTR, ao permitir que a funcionalidade de umaaplicação seja implementada separadamente do controle de seu comportamento, proporcionaum maior grau de reutilização e facilita o desenvolvimento e a manutenção de aplicaçõestempo-real.

O modelo de programação RTR é integrado a sistemas abertos utilizando o modelo deobjetos adotado pelo CORBA, no qual as interações acontecem segundo o paradigma cliente-servidor, e através da adoção de mecanismos de tratamento da questão temporal adequados aoambiente distribuído e heterogêneo. As restrições de tempo são tratadas localmente a partir daespecificação de um timeout no cliente e do deadline associado no servidor. Desta forma, omodelo garante um tratamento adequado para aplicações tempo-real do tipo melhor esforçoem ambientes distribuídos abertos.

Adicionalmente, foram realizados o mapeamento e a implementação do modelo numaplataforma distribuída. O mapeamento do modelo considerou como base uma plataformaCORBA e o sistema operacional Solaris, da Sun Microsystems. A implementação do modelodistribuído se encontra concluída e em pleno funcionamento.

O processo de desenvolvimento de aplicações distribuídas com restrições temporaisenvolvidas foi ilustrado através de um exemplo de programação de uma aplicação demultimídia distribuída, consistindo basicamente de um sistema de fornecimento de mídias sobdemanda para composição de um documento multimídia.

A continuidade do trabalho apresentado neste artigo segue atualmente várias direções,como a utilização do modelo RTR distribuído em aplicações de multimídia distribuída, odesenvolvimento de ferramentas de análise temporal, e a especificação de uma linguagemtempo-real com base nas características do modelo RTR.

Encontra-se em fase de especificação uma linguagem de programação tempo-realbaseada na linguagem Java. A linguagem Java-RTR irá incorporar as características presentesno modelo RTR. Java-RTR será construída de maneira a permitir o cálculo do tempo máximode execução de programas e a utilização de ferramentas para análise do comportamentotemporal dos mesmos.

O desenvolvimento de ferramentas para análise temporal de programas consiste emoutra das atividades em curso, previstas no sentido de providenciar um ambiente deprogramação para o tipo de aplicações citadas. Através destas ferramentas será possívelanalisar o comportamento temporal de programas desenvolvidos segundo o modelo reflexivotempo-real.

A utilização do modelo RTR distribuído para a programação de aplicações demultimídia consiste em um outro trabalho que se encontra em andamento. As características domodelo serão exploradas de modo a permitir a transmissão e exibição de mídias em sistemasabertos levando em conta requisitos de tempo e sincronismo derivados da qualidade de serviçoimposta pelos clientes da aplicação. Serão explorados mecanismos de computação imprecisaatravés de múltiplas versões de métodos que propiciem serviços com níveis de qualidadediferentes, de modo a permitir a satisfação das restrições impostas sem implicar na interrupçãodo funcionamento da aplicação.

Além dos trabalhos que se encontram em andamento e que de alguma forma estãorelacionados com o modelo reflexivo tempo-real, podemos destacar outras propostas decontinuidade do trabalho desenvolvido nesta dissertação.

Primeiramente, apresentamos como proposta de trabalho a ser desenvolvido aimplementação de ferramentas de auxílio à programação de aplicações utilizando o modeloRTR distribuído.

Uma outra possibilidade de continuidade do trabalho apresentado nesta dissertaçãoconsiste no mapeamento do modelo RTR distribuído sobre outras plataformas de execução,além da plataforma Solaris. Este trabalho seria seguido da implementação do modelo sobreestas novas plataformas adicionada de um ORB para prover a comunicação em ambienteaberto.

Finalmente, como perspectiva de um futuro trabalho propomos a validação do modeloRTR distribuído a partir de aplicações com maior grau de complexidade, envolvendo umambiente realmente heterogêneo, o que seria possível a partir do mapeamento do modelo sobreoutras plataformas de execução, e a avaliação do modelo comparando-o com outros modelostempo-real como os apresentados em [Hon 94], [Kim 94], [Li 94] e [Tak 92].

8 Bibliografia

[Aud 90] Audsley, N. ; Burns, A. “Real Time System Scheduling”, Specification and Design forDependability, PDCS - Predictability Dependable Computer Systems - ESPRIT, 1st YearReport, LAAS, Toulouse, May 1990.

[Fab 95] J.-C. Fabre; V. Nicomette; T. Pérennou; Z. Wu “Implementing Fault-TolerantApplications using Reflective Object-Oriented Programming”, 25th IEEE Workshop onFuture Trends in Computer Science (FTCS’95), June 1995.

[Fra 95] J. Fraga; J.-M. Farines; O. Furtado; F. Siqueira “A Programming Model for Real-TimeApplications in Open Distributed Systems”, 2nd IEEE Workshop on Future Trends inDistributed Computing Systems (FTDCS’95), August 1995.

[Fur 95] O. J. V. Furtado “Um Modelo e uma Linguagem para Aplicações Tempo Real”, Exame deQualificação para Doutorado, PGEEL–UFSC, Outubro 1995.

[Hon 94] Y. Honda; M. Tokoro “Reflection and Time-Dependent Computing: Experiences with theR2 Architecture”, Sony Computer Science Laboratory Inc., Technical Report SCSL-TR-93-017, Tokio, Japan, July 1994.

[Kar 93] A. Karmouch “Multimedia Distributed Cooperative System”, Computer Communications,Vol. 16, No. 9, September 1993.

[Kim 94] K.H. Kim; H. Kopetz “A Real-Time Object Model RTO.k and an ExperimentalInvestigation of Its Potentials”, COMPSAC’94 Proceedings, November 1994.

[Li 93] G. Li “Supporting Distributed Real-Time Computing”, PhD Thesis, University ofCambridge Computer Laboratory, Technical Report 322, August 1993.

[Li 94] G. Li “Distributed Real-Time Objects : the ANSA Approach”, 1st Workshop on Object-oriented Real-time Dependable Systems, September 1994.

[Mae 87] P. Maes "Concepts and Experiments in Computational Reflection"; OOPSLA'87Conference Proceedings, pp. 147-155, October 1987.

[OMG 93] OMG – Object Management Group “The Common Object Request Broker : Architectureand Specification”, Revision 1.2, OMG Document Number 93-12-43, December 1993.

[Tak 92] K. Takashio; M. Tokoro “DROL : An Object-Oriented Programming Language forDistributed Real-Time Systems”, OOPSLA’92 Conference Proceedings, October 1992.