Programação de Aplicações Tempo-Real em Sistemas

Abertos: O Modelo Reflexivo Tempo-Real Distribuído

Frank Siqueira e Joni Fraga

Laboratório de Controle e Microinformática – LCMI

Departamento de Engenharia Elétrica – Universidade Federal de Santa Catarina
Cx. Postal 476, Florianópolis, SC, Brasil. CEP 88040–900
E-mail: {fraga,frank}@lcmi.ufsc.br

Resumo

Este artigo apresenta um modelo para aplicações distribuídas com restrições tempo-real em
sistemas abertos. O modelo proposto utiliza o paradigma de reflexão computacional segundo a
abordagem de meta-objetos, que provê a separação entre funcionalidade e gerenciamento na
programação de aplicações. Conseqüentemente, o modelo possui dois níveis : um nível-base que
trata da funcionalidade do sistema, e um nível-meta que lida com escalonamento, restrições
temporais e de sincronização, assim como tratamento de exceções. O modelo é implementado
utilizando o padrão para sistemas distribuídos abertos CORBA, e tratando as restrições de tempo
localmente 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 tipo
melhor esforço em ambientes distribuídos abertos. Finalmente, as características principais do
modelo 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 open
systems. The proposed model adopts the reflective paradigm according to the meta-object
approach, which provides the separation among functionality and management when
programming applications. Consequently, the model has two levels : a base-level which deals
with system functionality, and a meta-level which manages scheduling, time and synchronization
constraints, as well as exception handling. The model is implemented using the CORBA standard
for open distributed systems, and dealing with timing constraints locally, specifying timeouts in
the client and the associated deadlines in the server. Then, the model ensures an adequate
treatment of best-effort real-time applications in open distributed systems. Finally, the main
characteristics of the proposed model are shown in an example of a distributed multimedia
application.

1 Introdução
A interligação de computadores em redes de longa distância levou ao surgimento de
problemas derivados da heterogeneidade de equipamentos e das dimensões do sistema como
um todo. O surgimento destes problemas levou à adoção de arquiteturas abertas para o
tratamento deste tipo de sistema. Com a evolução das aplicações em rede, que evoluíram do
simples correio eletrônico até o processamento de dados, som e imagem em tempo-real, foram
introduzidos requisitos temporais que devem ser considerados na construção e na execução
destas aplicações. A integração destas questões de tempo-real em sistemas abertos tem sido
objeto 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 sistemas
distribuídos abertos, seguindo uma abordagem de melhor esforço (best-effort). Objetivando
permitir 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 integramos
a este características da arquitetura CORBA e mecanismos para tratamento das questões
temporais presentes em sistemas distribuídos abertos.
Neste artigo descreveremos as características principais do resultado deste trabalho de
integração, o Modelo Reflexivo Tempo-Real Distribuído, e apresentaremos o mapeamento e a
implementação deste sobre uma plataforma composta pelo sistema operacional Solaris
adicionado de um suporte compatível com o CORBA. Ao final do artigo, apresentamos um
exemplo de aplicação de multimídia distribuída, consistindo basicamente em um sistema de
transmissão de mídias sob demanda, implementado com o objetivo de demonstrar a adequação
do 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 levados
em conta na construção de aplicações com características de tempo-real. Para que tais
requisitos sejam satisfeitos, torna-se necessária a adoção de mecanismos e políticas adequadas
para o controle das restrições temporais da aplicação e o gerenciamento dos recursos do
sistema.
Em sistemas distribuídos abertos, por outro lado, é indispensável dispor de mecanismos
que 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 sistemas
distribuídos abertos a adoção de arquiteturas e suportes tais como CORBA [OMG 93], ODP e
ANSA [Li 94]. No entanto, aspectos relacionados a questões temporais não são considerados
nestas propostas de modelos e arquiteturas para sistemas abertos.
O tratamento de questões presentes em sistemas tempo-real no contexto de sistemas
abertos é dificultada devido à existência de fatores conflitantes, mas não inconciliáveis. De
forma a integrar características de tempo-real em sistemas distribuídos abertos, devemos
considerar os seguintes aspectos [Tak 92][Li 93] :
– não existe a possibilidade de sincronização dos relógios locais dentro dos níveis de
granularidade desejáveis, o que impede que um tempo global seja utilizado na
verificaçã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 de
mecanismos probabilistas para determinação do tempo gasto na interação entre os
componentes de uma aplicação distribuída;
– a carga de cada máquina nestes sistemas é dinâmica e imprevisível; com isto, não
podemos impor garantias quanto à execução de nenhuma das atividades do sistema
dentro do tempo desejado.
Diante destas características, pressupõe-se que a verificação do cumprimento das
restrições temporais impostas às diversas atividades do sistema seja realizado com base no
reló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ção
completa 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 estruturadas
usualmente segundo o modelo cliente-servidor. O processamento tempo-real neste modelo
implica em restrições de tempo tanto no cliente quanto no servidor da aplicação. Estas
restrições são especificadas na forma de um timeout do lado cliente, quando da ativação de
uma requisição de serviço, e na forma de um deadline quando da execução do serviço
requisitado do lado do servidor.
Algumas propostas de implementação de suportes para o processamento tempo-real em
ambientes 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ções
temporais adotando os mecanismos citados acima (timeout, deadline), tendo como base seus
relógios locais. Nestas propostas, o escalonamento é realizado a nível de suporte de
programação. RIDE e ANSAware/RT implementam os mecanismos para controle das
restrições temporais e os algoritmos de escalonamento no suporte de execução. A alteração ou
a introdução de novos mecanismos ou algoritmos torna necessário efetuar modificações no
próprio suporte.
Por outro lado, em implementações do modelo CORBA sobre sistemas operacionais
tempo-real, como ORBeline 2.0 e Orbix-RT*, é possível usufruir de mecanismos tempo-real
disponíveis no sistema hospedeiro. No entanto, não é acrescentada funcionalidade apropriada
para o tratamento de restrições temporais nas interações em sistema aberto. Para utilizar estes
suportes de execução é indispensável que em todos os nodos do sistema sejam utilizados
suportes com características similares; esta exigência leva a uma escolha de um mesmo sistema
operacional ou a introdução de camadas adicionais no suporte para proporcionar
compatibilidade entre suportes.
O modelo RTR trata as questões temporais nas interações em sistemas distribuídos
abertos de forma similar aos suportes e modelos citados. Entretanto, se diferencia destes por
tratar 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 maior
heterogeneidade a nível de suporte. Assim sendo, a abordagem apresentada neste artigo
permite a alteração ou a introdução de novos mecanismos e algoritmos pelo programador, sem
que seja afetado o suporte ou o código da aplicação. Desta forma, a heterogeneidade a nível de
suporte de execução pode ser garantida sem a necessidade de introduzir modificações neste
ní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ções
temporais em aplicações tempo-real, é fundamentado em conceitos de programação orientada
a 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 é introduzida
no 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 da
aplicação.
Os objetos-base tempo-real apresentam estrutura e comportamento similar ao dos
objetos convencionais. Adicionalmente, são associadas aos seus métodos restrições temporais
(predefinidas ou construídas pelo programador) e manipuladores de exceção. Restrições
temporais construídas pelo programador são declaradas no objeto-base e implementadas
atravé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 modelo
possui 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 pelo
gerenciamento 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 de
sincronização e pelo processamento das restrições temporais, quando é efetivamente decidido
pela 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 uma
nova thread de controle, viabilizando o tratamento concorrente dos pedidos e permitindo um
tratamento mais efetivo das restrições temporais a eles associadas.
Por outro lado, um mecanismo de controle da concorrência garante a exclusão mútua
no objeto-base, permitindo que somente um de seus métodos esteja em execução em um
determinado momento. Este controle é realizado em função do estado do objeto-base, mantido
a nível de meta-objeto.
O meta-objeto escalonador tem como função básica receber, ordenar e liberar pedidos
de escalonamento de métodos dos objetos base que compõem a aplicação de acordo com
determinada política de escalonamento (predefinida ou introduzida pelo programador), visando
satisfazer as restrições temporais da aplicação dentro de uma política de melhor esforço. Desta
forma, diferentes pedidos de escalonamento, originados de um ou vários meta-objetos
gerenciadores, podem ser analisados globalmente e ordenados de acordo com a política de
escalonamento vigente.
O meta-objeto escalonador recebe do meta-objeto gerenciador requisições de
escalonamento de métodos com restrições temporais, e determina, de acordo com a política de
escalonamento implementada e com as restrições temporais associadas, o momento a partir do
qual o método em questão pode ser liberado para execução. Com a liberação para execução do
método, em função da disponibilidade de tempo e observados os aspectos de sincronização e
concorrência, o meta-objeto gerenciador decide pela liberação da execução do método
solicitado ou pelo levantamento de uma exceção temporal. Em seguida, após a execução do
método a nível-base, o controle é devolvido para o meta-objeto gerenciador, que libera o
meta-objeto escalonador para que processe o próximo pedido da fila de requisições, e retorna
o 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 de
objeto. Sua função básica é receber pedidos do meta-objeto gerenciador para ativar métodos
num tempo futuro, detectar violação de timeouts e eventuais violações de restrições associadas
com métodos que estão aguardando para ser escalonados ou que aguardam o estabelecimento
de concorrência ou sincronização.
 Na figura a apresentamos a dinâmica de uma chamada de método em uma aplicação
estruturada segundo o modelo RTR, composta por um conjunto de objetos-base e meta-
objetos gerenciadores.
META-OBJETO META-OBJETO
ESCALONADOR RELÓGIO
55555 ¹
‚ ƒ

Meta-Objeto Meta-Objeto Meta-Objeto

Gerenciador Gerenciador Gerenciador
•
„ … Nível-Meta
Nível-Base
†
Objeto-Base Objeto-Base Objeto-Base

Figura A – Estrutura Geral do Modelo RTR

A interação entre objetos-base e meta-objetos do modelo inicia com um pedido de
ativação de um método de um determinado objeto-base, que é desviado para seu meta-objeto
gerenciador 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 ƒ) para
processar as restrições temporais associadas ao método solicitado, e se estas restrições não
forem violadas, ativa o método solicitado no objeto-base (ação „), retornando em seguida, via
meta-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 servidor
da aplicação. Em cada nodo do sistema temos, além dos pares de objetos-base e meta-objetos
gerenciadores, 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, cada
nó possui um meta-objeto escalonador que trabalha independentemente na rede, influenciando
apenas o escalonamento local. As tarefas são primeiro alocadas aos nodos do sistema para
posteriormente serem escalonadas segundo critérios locais [Aud 90].
O escalonamento no Modelo RTR Distribuído ocorre em dois níveis distintos. Em um
primeiro nível, há o escalonamento de métodos de objetos-base realizado pelo meta-objeto
escalonador. Em um nível mais baixo há o escalonamento realizado pelo núcleo do sistema
operacional subjacente.
De modo semelhante, cada nó do sistema possui um meta-objeto relógio local, que
trabalha independentemente dos outros relógios localizados nos demais nós da rede. Em uma
requisição de método, tanto o objeto cliente quanto o servidor do método verificam o
cumprimento de restrições temporais utilizando um meta-objeto relógio. O cliente verifica o
cumprimento do timeout da chamada com base no meta-objeto relógio local, enquanto o
objeto servidor controla o deadline do método.
 Obtemos a desejada interoperabilidade entre componentes distribuídos heterogêneos do
sistema 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 e
conceitos propostos pela OMG (Object Management Group) para sistemas abertos. Na
arquitetura proposta, requisições de métodos de objetos são feitas transparentemente em um
ambiente 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 papel
de cada um de seus componentes no ambiente distribuído. As interfaces CORBA são
especificadas como uma camada, mascarando diferenças entre as diversas implementações
possíveis.
Em um ambiente CORBA, cada objeto tem sua interface especificada na linguagem
IDL (Interface Definition Language), uma linguagem puramente declarativa com sintaxe e
tipos predefinidos baseados na linguagem C++. Para requisitar a execução de um método, um
cliente CORBA utiliza stubs geradas na compilação da especificação de interface IDL do
objeto servidor, ou pode construir uma requisição utilizando a interface de invocação dinâmica
DII (Dynamic Invocation Interface). Para permitir invocações dinâmicas, interfaces de objetos
devem 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; ele
transmite 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 de
skeletons IDL. O objeto servidor trata a requisição da mesma forma, independentemente do
mecanismo 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ão

transparentes para objetos-base. Aspectos referentes à comunicação remota entre processos
são tratados por meta-objetos adicionais de comunicação, que encapsulam os aspectos
referentes às interfaces ORB.
As chamadas de métodos remotos originadas de um objeto-base são redirecionadas
para MetaStubs, que modificam as stubs geradas pelo compilador IDL-CORBA de modo a
tratar 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 do
objeto-base. Como alternativa à chamada por stubs, pode ser utilizada a interface de invocação
dinâmica (DII) do CORBA e o meta-objeto MetaDII.
As chamadas de métodos originárias de objetos remotos e destinadas a um determinado
objeto do modelo são recebidas através de skeletons e de MetaSkeletons, que modificam a
funcionalidade dos skeletons gerados pelo compilador IDL. Estes objetos recebem a requisição
através do ORB e chamam o respectivo método no objeto-base. Esta chamada é desviada para
o meta-objeto correspondente de modo a estabelecer o protocolo definido pelo modelo de
objetos tempo-real, impondo restrições temporais e de sincronização através da interação com
o 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 diferentes
servidores; 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 segundo
uma arquitetura CORBA é apresentada na figura b.
META-OBJETO META-OBJETO META-OBJETO META-OBJETO
ESCALONADOR RELÓGIO RELÓGIO ESCALONADOR
55555 ¹ ¹ 55555
CLIENTE • Ž … SERVIDOR „

Meta-Objeto Meta-Objeto
Meta
Meta Stub de
Stub//DII
DII Meta-Objeto
MetaStub
Meta de
Stub//DII
DII Meta-Objeto
Gerenciador
Comunicação Comunicação ’ Gerenciador
(MetaStub/DII) (MetaSkeleton)
• ƒ
Nível-Meta ‚ • ‘ †Nível-Meta
Nível-Base
• ˆ ‡
Nível-Base
‰
Objeto-Base
Meta
Meta Stub de
Stub/ /DII
DII Objeto-Base
MetaStub
Meta de
Stub/ /DII
DII
Objeto-Base Comunicação Comunicação Objeto-Base
(Stub/DII) (Skeleton)

OBJECT REQUEST BROKER

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 uma
chamada síncrona. No cliente, a chamada de um método do objeto-base servidor deve estipular
as restrições temporais e procedimentos de exceção para o caso destas restrições serem
violadas, 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 da
execuçã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 a
ocorrência de uma violação do timeout imposto pelo cliente. A exceção timeout é detectada
pelo cliente com o auxílio do meta-objeto relógio e comunicada ao meta-objeto servidor
através do suporte de comunicação.
A chamada realizada pelo cliente é encaminhada via um MetaStub para o servidor ao
qual se destina a requisição (ação • da figura b). O MetaStub requisita o método chamado
pelo objeto-base através do ORB utilizando stubs (ação ‚), e envia ao meta-objeto relógio o
valor de timeout associado à chamada (ação •). O MetaStub passa a aguardar uma mensagem
de 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 o
mé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étodo
requisitado. Quando o meta-objeto escalonador sinaliza que o método deve ser executado, o
meta-objeto gerenciador do servidor verifica se as restrições temporais (ação …) e de
sincronização foram violadas, retornando uma exceção reject neste caso. Caso contrário, o
método é chamado no objeto-base do servidor (ação †). Concluída a chamada, ocorre
novamente a verificação das restrições temporais, resultando em uma exceção abort caso
estas tenham sido violadas. O resultado da chamada é enviado na forma de parâmetros ao
objeto-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 a
MetaStub uma violação de timeout (ação Ž da figura b), uma indicação de exceção é enviada
ao objeto cliente (ação •). Em seguida, MetaStub remete através do ORB e do MetaSkeleton
a 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 de
pedidos 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 que
efetuada a chamada. Caso o cliente venha a necessitar futuramente de dados de resposta
provenientes 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ções
definidas pelo modelo para elementos do sistema operacional Solaris*. O Solaris possui
características que o tornam adequado para utilização em ambiente tempo-real, como um
mecanismo de escalonamento baseado em prioridades e classes de escalonamento, dentro das
quais vigoram políticas distintas; bloqueio de páginas de memória; operações de entrada e
saída assíncronas; e multi-threading.
Cada par composto por um objeto-base e seu meta-objeto gerenciador, juntamente
como os objetos adicionais de comunicação utilizados na interação com outros objetos do
modelo – stubs e MetaStubs, MetaDII, skeletons e MetaSkeletons – corresponde a um
processo Solaris. Meta-objeto escalonador e meta-objeto relógio são implementados em
processos distintos.
Utilizamos threads para permitir concorrência interna nos meta-objetos, em conjunto
com ORBs que possibilitem o multi-threading em objetos CORBA. Desta forma, várias
requisições poderão ser processadas simultaneamente pelo meta-objeto. Cada meta-objeto do
modelo 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 para
cada 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 conforme
especificado 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). A
atribuição de prioridades tempo-real aos processos aos quais pertencem os objetos-base e
meta-objetos do modelo ocorre durante a criação do meta-objeto.
Através do estabelecimento de prioridades utilizadas pelo Solaris no escalonamento a
processos e threads, em conjunto com a utilização do meta-objeto escalonador para determinar
a ordem a ser obedecida na execução dos métodos requisitados, será obtido o comportamento
desejado 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 modo
sí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étodo
aguardará a execução desta, mas o suporte deve impedir que aconteça a execução de um outro
método do mesmo objeto em nível-base devido às restrições de exclusão mútua que devem ser
garantidas no objeto-base.
Enquanto estiverem somente processando requisições de métodos a nível-meta, os
processos com objetos do modelo devem possuir uma mesma prioridade fixa. No caso do
processo 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 do
número de objetos suspensos aguardando o retorno de chamadas síncronas aninhadas naquele
nodo 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 o
sistema 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ção
comercial 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 para
universidades e institutos de pesquisa.
O protótipo do modelo RTR se encontra em pleno funcionamento. Foram necessárias
algumas 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 bugs
encontrados no ORBeline). Desta forma, alguns aspectos não puderam estar presentes na
implementação do protótipo.
Foi suprimida a concorrência interna dentro do meta-objeto devido à impossibilidade de
utilização de threads juntamente com o ORBeline. Deste modo, cada meta-objeto pode
atender somente uma requisição por vez, resultando na criação de uma fila com ordenação
FIFO 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 continua
existindo e seguindo a política de escalonamento implementada no meta-objeto escalonador do
modelo.
 Os valores de restrições e exceções temporais, que inicialmente deveriam ser
transmitidos respectivamente na forma de objetos de contexto e exceções CORBA, foram
passados como parâmetros adicionais de chamada, devido a problemas tanto nos objetos de
contexto quanto nas exceções implementadas no ORBeline 1.0. Desta forma, os métodos
descritos na declaração de interface de um objeto ganharam um parâmetro adicional, visível
apenas nos meta-objetos gerenciadores e de comunicação, adicionado posteriormente aos
parâmetros originais do método.
Devido à inexistência de um suporte para threads no ORB, os meta-objetos de
comunicação foram implementados utilizando a interface de invocação dinâmica e o depósito
de interfaces do ORBeline. O comportamento desejado nas chamadas de métodos de objetos
do modelo foi obtido através da utilização de MetaDII, implementado através de sobrecarga de
funçã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 pelo
compilador IDL-CORBA, ou optar por MetaStubs que implementem a funcionalidade do
modelo 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 externamente
do ponto de vista do CORBA.
Cada meta-objeto gerenciador possui um apontador direcionado para o objeto-base
correspondente, possibilitando o acesso aos métodos de nível-base. O objeto-base não recebe
do meta-objeto os parâmetros relativos às restrições temporais, o que garante a transparência
em 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 a
interação com os referidos meta-objetos do ponto de vista do programador da aplicação a
nível-meta.

5 Desenvolvimento de Aplicações Utilizando o

Modelo
O desenvolvimento de aplicações distribuídas segundo o modelo reflexivo tempo-real
segue 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 e
nível-base, de maneira a definir a funcionalidade do objeto e os mecanismos de controle aos
quais o mesmo deve ser submetido. Adicionalmente, no protótipo do modelo implementado
neste trabalho, o usuário deve descrever a interface do servidor da aplicação em linguagem
IDL e, como não dispomos de um gerador de código para MetaStubs e MetaSkeletons a partir
da especificação IDL, a codificação dos meta-objetos de comunicação também deve ser
realizada pelo programador da aplicação.
O suporte provido pelo protótipo do modelo RTR distribuído simplifica
consideravelmente 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 uma
biblioteca, 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ção
dinâmica (DII) na interação com o servidor, basta para o programador incluir um arquivo com
o código de MetaDII no meta-objeto cliente, tornando desnecessária a codificação de qualquer
objeto adicional além do código do cliente nos níveis base e meta.
 Descrição de
Interface IDL
do Servidor
Base
Compilador IDL - CORBA

Cód. Fonte Cód. Fonte Código Código Código Código Cód. Fonte Cód. Fonte
do Obj-Base do Meta-Obj Fonte das Fonte das Fonte do Fonte do do Obj-Base do Meta-Obj
Cliente Cliente MetaStubs Stubs Skeleton MetaSkeleton Servidor Servidor

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

Cód. Objeto Cód. Objeto Código Código Código Código Cód. Objeto Cód. Objeto
do Obj-Base do Meta-Obj Objeto das Objeto das Objeto do Objeto do do Obj-Base do Meta-Obj
Cliente Cliente MetaStubs Stubs Skeleton MetaSkeleton Servidor Servidor

Linker do Sistema

Código Código
CLIENTE Executável Executável SERVIDOR
DA APLICAÇÃO do Cliente do Servidor DA APLICAÇÃO

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. O
exemplo escolhido consiste na exibição de um documento multimídia, onde dados de diversas
mí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 documento
multimídia segue o modelo cliente-servidor. A figura d mostra a obtenção progressiva e o
esquema de apresentação de um documento multimídia, envolvendo diferentes servidores de
mídia : som, imagem, texto, e possivelmente outras mídias.
O arquivo descrevendo o documento a ser composto é armazenado em uma base de
dados local, que contém informações acerca das partes dos documentos, seus tempos de
apresentação, e o cenário relativo à sincronização das mídias. A partir deste cenário, o
programa 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ídia
específica. Cada cliente de uma determinada mídia utilizada no documento deve requisitar ao
servidor correspondente, receber e armazenar em buffers a informação descrevendo a mídia
em questão. Cada cliente deve possuir dois buffers para evitar a descontinuidade na
apresentação, solucionando problemas como jitter e overhead. Enquanto um dos buffers
estiver 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 documento
multimí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 fazemos
com que o servidor respeite o fluxo de execução e a taxa de transmissão de dados impostos
pelo cliente.
 Estação A Estação B Estação C

Servidor Servidor Servidor

de Som de Imagem de Texto ŸŸŸ

Cliente Cliente Cliente

de Som de Imagem de Texto ŸŸŸ

Composição do
Documento Multimídia

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

A forma de armazenamento de dados utilizada – disco rígido, fita, CD, ou qualquer
outro dispositivo de armazenamento de informação – compete exclusivamente ao servidor de
mídia. O cliente de uma determinada mídia conhece apenas a interface do servidor
correspondente, recebendo os dados referentes à mídia através de requisições de serviço
enviadas a este servidor.
Mecanismos de sincronização entre as mídias podem ser utilizados neste tipo de
aplicação, com o objetivo de manter uma relação de sincronismo imposta pelo documento
multimídia entre as diversas mídias utilizadas. Em muitos casos, pode haver a necessidade de
sincronizaçã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 na
forma de arquivos armazenados em disco. O servidor possui operações de abertura do
arquivo, 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úblico
para exibição das mídias de modo centralizado (não distribuído). Isto mostra a perfeita
adequação do modelo para reutilização de software de modo simples e flexível. Devido às
características do modelo RTR, não foram necessárias alterações no corpo destes programas
para adaptação ao ambiente distribuído e para controle de requisitos temporais, pois estas
alteraçõ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 da
mídia (leitura de arquivos substituída por chamadas aos servidores) e para permitir a exibição
da 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árias
para 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 Xplay
pode manipular arquivos nos formatos Sun Audio, Windows Wave, e AIFF, e possui uma
interface gráfica de acordo com o padrão Motif ®, permitindo operações de pausa, retorno e
avanço do som, controle de volume e do dispositivo de saída utilizado (alto-falante ou fone de
ouvido).
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 de
pausa, avanço quadro a quadro e retrocesso da imagem. Adicionalmente, existe a possibilidade
de, no momento da chamada do programa, especificar os algoritmos de dithering que devem
ser 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 servidores
apresentados 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 de
recuperação da mídia armazenada no servidor. Os valores das restrições temporais devem ser
obtidos em função da qualidade de serviço exigida pelo cliente, considerando fatores como o
tempo necessário para que não ocorram interrupções perceptíveis na exibição da mídia na
estação cliente e a quantidade de dados disponíveis no buffer do cliente aguardando para ser
exibidos.
Neste exemplo foi utilizado o meta-objeto escalonador que implementa a política de
escalonamento tempo-real com base em deadlines (EDF - Earliest Deadline First). A política
utilizada 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 na

listagem a. A tradução desta interface IDL gera os objetos-base stub e skeletons para o
servidor de mídia.
No arquivo IDL que descreve a interface do servidor de mídia foi declarado o tipo
BufType, utilizado pelo buffer através do qual a mídia é transmitida ao cliente, como sendo
uma 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 de
transmissã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 e
exceçõ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 apenas

em recuperar a informação relativa à mídia em questão que se encontra armazenada em
arquivos 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 da
mesma maneira (através de arquivos decodificados pelo cliente), o mesmo servidor é utilizado
para ambas as mídias.
Em cada servidor de mídia, a operação de obtenção dos dados é vista como uma
operação aperiódica, e um deadline especifica o tempo máximo dentro do qual a operação
deve 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 podemos
observar, este objeto herda as operações de interfaceamento com o ORB a partir da classe
meta_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ções
definidas em sua interface um descritor rt, do tipo RTparams, onde são especificados os
valores das restrições temporais impostas na execução do método e indicada a ocorrência de
uma 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. Este
método processa a requisição recebida do cliente e interage com os meta-objetos escalonador e
relógio de modo a estabelecer o comportamento desejado pelo modelo conforme a política de
melhor 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ógio
metaclock.start_time();
// Aguarda permissão para executar do meta-obj escalonador
metasched.getprio(rt.deadline());
// Avalia se existe tempo para executar o método
if( (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 retorna
metasched.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 esta
mídia na estação do usuário, utilizando dispositivos periféricos como o alto-falante e o
monitor. O código destes objetos consiste basicamente nos programas de exibição de mídias
citados anteriormente.
A cada requisição enviada por um cliente a um servidor de mídia, um valor de timeout
expressa o tempo de espera aceitável do cliente para estes dados. A verificação e o tratamento
de exceções são realizados no objeto-base. Em caso de uma exceção do tipo reject, o
estado 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 ou
timeout, o estado do servidor foi alterado e o cliente não pode continuar o procedimento de
exibição da mídia sem perda de informação, devendo então indicar a exceção e interromper sua
execução.
A listagem e mostra a forma como o objeto-base do cliente de imagem, implementado
na linguagem C++, requisita ao servidor correspondente a mídia armazenada na forma de uma
arquivo 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 tipo
RTparams). A informação lida é depositada em um buffer (mybuf) e a chamada retorna o
número de bytes lidos (num_read). Através do campo de indicação de exceções exc do
parâ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 de
métodos.

6.2.4 Meta-Objetos de Comunicação

Os meta-objetos de comunicação – MetaStub e MetaSkeleton – interagem com o

suporte de comunicação provido pelo ORB, modificando o comportamento de stubs e
skeletons gerados pelo compilador IDL.
No protótipo implementado, MetaStubs utilizam a interface de invocação dinâmica
para 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 MetaSkeletons
nulos, 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ção
CORBA::Long ret; // valor retornado

// Cria requisição e faz o bind com o servidor

if ( 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 especificado

req->invoke( rt.timeout() );

// Atualiza exceção com valor retornado pelo servidor

rt.exc ( (timing_exception_id)req->arg(1)->member("exc") );

// Obtém o valor retornado pelo método do servidor

if (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 sistema
aberto 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 com
restrições temporais em sistemas abertos.
A análise da implementação realizada sobre o protótipo do modelo RTR distribuído
nos 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 objeto
tradicionais e bem conhecidas pelos programadores, não introduzindo novas abstrações
ou conceitos de difícil compreensão.
– O modelo permite um alto grau de reutilização de código de aplicações já existentes na
implementação da funcionalidade dos objetos-base – neste exemplo, podemos constatar
tal fato nos objetos-base de exibição de mídia. A programação destes objetos-base não
sofreu grandes alterações derivadas da distribuição intrínseca do sistema, e nem mesmo
devido 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 da
aplicação, são fatores de vital importância para permitir ao programador preocupar-se
somente com a implementação da funcionalidade da aplicação na definição do
comportamento do objeto-base. Estudos mostram que a solução de grandes problemas
é bastante facilitada quando estes são divididos em problemas menores que podem ser
solucionados isoladamente.
– A forma na qual foi estruturada a aplicação conduz a um grande índice de flexibilidade
de programação. Componentes podem ser trocados, inseridos ou removidos sem
implicar 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 simples
substituição do meta-objeto escalonador por um outro. A manutenção da interface
utilizada pelos meta-objetos gerenciadores para comunicação com o meta-objeto
escalonador 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ção
propriamente dita, implementada a nível-base, estar separada dos mecanismos de
suporte que permitem a comunicação no ambiente distribuído e o controle dos
requisitos temporais da aplicação, efetuados pelos meta-objetos. Um programador, sem
tomar conhecimento do código a nível-meta, pode realizar a manutenção do software a
nível-base. De modo semelhante, a correção do comportamento temporal ou do
protocolo 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 de
comunicação) podem ser reutilizados em outras aplicações implementadas de acordo
com o modelo RTR.

7 Conclusões e Perspectivas
Este artigo descreveu um modelo de programação de aplicações tempo-real em
sistemas distribuídos abertos, o Modelo Reflexivo Tempo-Real (RTR) Distribuído, seu
mapeamento e implementação sobre uma plataforma de execução, e o desenvolvimento de
uma aplicação tempo-real utilizando o referido modelo.
O Modelo RTR permite que mecanismos de controle de restrições temporais e políticas
de escalonamento adequados às necessidades específicas de uma aplicação sejam introduzidos
e/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 de
aplicação.
Em adição à flexibilidade provida pela possibilidade de programação em nível-meta, o
uso de reflexão computacional no Modelo RTR, ao permitir que a funcionalidade de uma
aplicação seja implementada separadamente do controle de seu comportamento, proporciona
um maior grau de reutilização e facilita o desenvolvimento e a manutenção de aplicações
tempo-real.
O modelo de programação RTR é integrado a sistemas abertos utilizando o modelo de
objetos 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 ao
ambiente distribuído e heterogêneo. As restrições de tempo são tratadas localmente 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 tipo melhor esforço
em ambientes distribuídos abertos.
Adicionalmente, foram realizados o mapeamento e a implementação do modelo numa
plataforma distribuída. O mapeamento do modelo considerou como base uma plataforma
CORBA e o sistema operacional Solaris, da Sun Microsystems. A implementação do modelo
distribuído se encontra concluída e em pleno funcionamento.
O processo de desenvolvimento de aplicações distribuídas com restrições temporais
envolvidas foi ilustrado através de um exemplo de programação de uma aplicação de
multimídia distribuída, consistindo basicamente de um sistema de fornecimento de mídias sob
demanda 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, o
desenvolvimento de ferramentas de análise temporal, e a especificação de uma linguagem
tempo-real com base nas características do modelo RTR.
Encontra-se em fase de especificação uma linguagem de programação tempo-real
baseada na linguagem Java. A linguagem Java-RTR irá incorporar as características presentes
no modelo RTR. Java-RTR será construída de maneira a permitir o cálculo do tempo máximo
de execução de programas e a utilização de ferramentas para análise do comportamento
temporal dos mesmos.
O desenvolvimento de ferramentas para análise temporal de programas consiste em
outra das atividades em curso, previstas no sentido de providenciar um ambiente de
programação para o tipo de aplicações citadas. Através destas ferramentas será possível
analisar o comportamento temporal de programas desenvolvidos segundo o modelo reflexivo
tempo-real.
A utilização do modelo RTR distribuído para a programação de aplicações de
multimídia consiste em um outro trabalho que se encontra em andamento. As características do
modelo serão exploradas de modo a permitir a transmissão e exibição de mídias em sistemas
abertos levando em conta requisitos de tempo e sincronismo derivados da qualidade de serviço
imposta pelos clientes da aplicação. Serão explorados mecanismos de computação imprecisa
através de múltiplas versões de métodos que propiciem serviços com níveis de qualidade
diferentes, de modo a permitir a satisfação das restrições impostas sem implicar na interrupção
do funcionamento da aplicação.
 Além dos trabalhos que se encontram em andamento e que de alguma forma estão
relacionados com o modelo reflexivo tempo-real, podemos destacar outras propostas de
continuidade do trabalho desenvolvido nesta dissertação.
Primeiramente, apresentamos como proposta de trabalho a ser desenvolvido a
implementação de ferramentas de auxílio à programação de aplicações utilizando o modelo
RTR distribuído.
Uma outra possibilidade de continuidade do trabalho apresentado nesta dissertação
consiste 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 sobre
estas novas plataformas adicionada de um ORB para prover a comunicação em ambiente
aberto.
Finalmente, como perspectiva de um futuro trabalho propomos a validação do modelo
RTR distribuído a partir de aplicações com maior grau de complexidade, envolvendo um
ambiente realmente heterogêneo, o que seria possível a partir do mapeamento do modelo sobre
outras plataformas de execução, e a avaliação do modelo comparando-o com outros modelos
tempo-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 for
Dependability, PDCS - Predictability Dependable Computer Systems - ESPRIT, 1st Year
Report, LAAS, Toulouse, May 1990.
[Fab 95] J.-C. Fabre; V. Nicomette; T. Pérennou; Z. Wu “Implementing Fault-Tolerant
Applications using Reflective Object-Oriented Programming”, 25th IEEE Workshop on
Future Trends in Computer Science (FTCS’95), June 1995.
[Fra 95] J. Fraga; J.-M. Farines; O. Furtado; F. Siqueira “A Programming Model for Real-Time
Applications in Open Distributed Systems”, 2nd IEEE Workshop on Future Trends in
Distributed Computing Systems (FTDCS’95), August 1995.
[Fur 95] O. J. V. Furtado “Um Modelo e uma Linguagem para Aplicações Tempo Real”, Exame de
Qualificação para Doutorado, PGEEL–UFSC, Outubro 1995.
[Hon 94] Y. Honda; M. Tokoro “Reflection and Time-Dependent Computing: Experiences with the
R2 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 Experimental
Investigation of Its Potentials”, COMPSAC’94 Proceedings, November 1994.
[Li 93] G. Li “Supporting Distributed Real-Time Computing”, PhD Thesis, University of
Cambridge 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'87
Conference Proceedings, pp. 147-155, October 1987.
[OMG 93] OMG – Object Management Group “The Common Object Request Broker : Architecture
and Specification”, Revision 1.2, OMG Document Number 93-12-43, December 1993.
[Tak 92] K. Takashio; M. Tokoro “DROL : An Object-Oriented Programming Language for
Distributed Real-Time Systems”, OOPSLA’92 Conference Proceedings, October 1992.