Programao de Aplicaes Tempo-Real em Sistemas

Abertos: O Modelo Reflexivo Tempo-Real Distribudo

Frank Siqueira e Joni Fraga
Laboratrio de Controle e Microinformtica LCMI
Departamento de Engenharia Eltrica Universidade Federal de Santa Catarina
Cx. Postal 476, Florianpolis, SC, Brasil. CEP 88040900
E-mail: {fraga,frank}@lcmi.ufsc.br
Resumo
Este artigo apresenta um modelo para aplicaes distribudas com restries tempo-real em
sistemas abertos. O modelo proposto utiliza o paradigma de reflexo computacional segundo a
abordagem de meta-objetos, que prov a separao entre funcionalidade e gerenciamento na
programao de aplicaes. Conseqentemente, o modelo possui dois nveis : um nvel-base que
trata da funcionalidade do sistema, e um nvel-meta que lida com escalonamento, restries
temporais e de sincronizao, assim como tratamento de excees. O modelo implementado
utilizando o padro para sistemas distribudos abertos CORBA, e tratando as restries de tempo
localmente a partir da especificao de um timeout no cliente e do deadline associado no servidor.
Desta forma, o modelo garante um tratamento adequado para aplicaes tempo-real do tipo
melhor esforo em ambientes distribudos abertos. Finalmente, as caractersticas principais do
modelo proposto so ilustradas em um exemplo de aplicao de multimdia distribuda.
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.

Introduo

A interligao de computadores em redes de longa distncia levou ao surgimento de

problemas derivados da heterogeneidade de equipamentos e das dimenses do sistema como
um todo. O surgimento destes problemas levou adoo de arquiteturas abertas para o
tratamento deste tipo de sistema. Com a evoluo das aplicaes em rede, que evoluram do
simples correio eletrnico at o processamento de dados, som e imagem em tempo-real, foram
introduzidos requisitos temporais que devem ser considerados na construo e na execuo
destas aplicaes. A integrao destas questes de tempo-real em sistemas abertos tem sido
objeto de intensa pesquisa, mas ainda no se encontra devidamente estabelecida.

Este trabalho trata basicamente de aplicaes com restries de tempo-real em sistemas

distribudos abertos, seguindo uma abordagem de melhor esforo (best-effort). Objetivando
permitir a programao de aplicaes tempo-real em um ambiente distribudo e heterogneo,
adotamos um modelo de programao, o Modelo Reflexivo Tempo-Real (RTR), e integramos
a este caractersticas da arquitetura CORBA e mecanismos para tratamento das questes
temporais presentes em sistemas distribudos abertos.
Neste artigo descreveremos as caractersticas principais do resultado deste trabalho de
integrao, o Modelo Reflexivo Tempo-Real Distribudo, e apresentaremos o mapeamento e a
implementao deste sobre uma plataforma composta pelo sistema operacional Solaris
adicionado de um suporte compatvel com o CORBA. Ao final do artigo, apresentamos um
exemplo de aplicao de multimdia distribuda, consistindo basicamente em um sistema de
transmisso de mdias sob demanda, implementado com o objetivo de demonstrar a adequao
do modelo na programao de aplicaes distribudas com requisitos temporais.

Sistemas Abertos e Tempo-Real

Requisitos como previsibilidade, correo temporal e performance precisam ser levados

em conta na construo de aplicaes com caractersticas de tempo-real. Para que tais
requisitos sejam satisfeitos, torna-se necessria a adoo de mecanismos e polticas adequadas
para o controle das restries temporais da aplicao e o gerenciamento dos recursos do
sistema.
Em sistemas distribudos abertos, por outro lado, indispensvel dispor de mecanismos
que permitam a transparncia em relao distribuio e heterogeneidade de equipamentos.
Os meios acadmico e industrial tem considerado como solues satisfatrias para sistemas
distribudos abertos a adoo de arquiteturas e suportes tais como CORBA [OMG 93], ODP e
ANSA [Li 94]. No entanto, aspectos relacionados a questes temporais no so considerados
nestas propostas de modelos e arquiteturas para sistemas abertos.
O tratamento de questes presentes em sistemas tempo-real no contexto de sistemas
abertos dificultada devido existncia de fatores conflitantes, mas no inconciliveis. De
forma a integrar caractersticas de tempo-real em sistemas distribudos abertos, devemos
considerar os seguintes aspectos [Tak 92][Li 93] :
no existe a possibilidade de sincronizao dos relgios locais dentro dos nveis de
granularidade desejveis, o que impede que um tempo global seja utilizado na
verificao de restries presentes em sistemas tempo-real;
os tempos relativos comunicao no so delimitados, o que implica na adoo de
mecanismos probabilistas para determinao do tempo gasto na interao entre os
componentes de uma aplicao distribuda;
a carga de cada mquina nestes sistemas dinmica e imprevisvel; com isto, no
podemos impor garantias quanto execuo de nenhuma das atividades do sistema
dentro do tempo desejado.
Diante destas caractersticas, pressupe-se que a verificao do cumprimento das
restries temporais impostas s diversas atividades do sistema seja realizado com base no
relgio local de cada componente da aplicao. A ausncia de previsibilidade do sistema,
tanto a nvel local como global, impossibilita o uso de polticas que garantam a satisfao
completa das restries temporais, e leva adoo de polticas de melhor esforo (best-effort)
para o escalonamento das atividades do sistema.

Nas propostas de arquiteturas para sistemas abertos, as interaes so estruturadas

usualmente segundo o modelo cliente-servidor. O processamento tempo-real neste modelo
implica em restries de tempo tanto no cliente quanto no servidor da aplicao. Estas
restries so especificadas na forma de um timeout do lado cliente, quando da ativao de
uma requisio de servio, e na forma de um deadline quando da execuo do servio
requisitado do lado do servidor.
Algumas propostas de implementao de suportes para o processamento tempo-real em
ambientes abertos podem ser encontradas na literatura. Os sistemas RIDE e ANSAware/RT
[Li 94], ambos implementaes de modelo de objetos tempo-real ANSA, tratam as restries
temporais adotando os mecanismos citados acima (timeout, deadline), tendo como base seus
relgios locais. Nestas propostas, o escalonamento realizado a nvel de suporte de
programao. RIDE e ANSAware/RT implementam os mecanismos para controle das
restries temporais e os algoritmos de escalonamento no suporte de execuo. A alterao ou
a introduo de novos mecanismos ou algoritmos torna necessrio efetuar modificaes no
prprio suporte.
Por outro lado, em implementaes do modelo CORBA sobre sistemas operacionais
tempo-real, como ORBeline 2.0 e Orbix-RT*, possvel usufruir de mecanismos tempo-real
disponveis no sistema hospedeiro. No entanto, no acrescentada funcionalidade apropriada
para o tratamento de restries temporais nas interaes em sistema aberto. Para utilizar estes
suportes de execuo indispensvel que em todos os nodos do sistema sejam utilizados
suportes com caractersticas similares; esta exigncia leva a uma escolha de um mesmo sistema
operacional ou a introduo de camadas adicionais no suporte para proporcionar
compatibilidade entre suportes.
O modelo RTR trata as questes temporais nas interaes em sistemas distribudos
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 nvel de aplicao,
independentemente do suporte de execuo, o que aumenta a flexibilidade e permite maior
heterogeneidade a nvel de suporte. Assim sendo, a abordagem apresentada neste artigo
permite a alterao ou a introduo de novos mecanismos e algoritmos pelo programador, sem
que seja afetado o suporte ou o cdigo da aplicao. Desta forma, a heterogeneidade a nvel de
suporte de execuo pode ser garantida sem a necessidade de introduzir modificaes neste
nvel.

Caractersticas do Modelo RTR Distribudo

3.1 O Modelo Reflexivo Tempo-Real

O modelo RTR [Fur 95], desenvolvido para expressar e implementar as restries
temporais em aplicaes tempo-real, fundamentado em conceitos de programao orientada
a objetos e reflexo computacional.
O paradigma reflexivo permite que um sistema execute processamento sobre si mesmo,
para o ajuste ou a modificao de seu comportamento. A reflexo computacional introduzida
no modelo RTR atravs 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.

aplicao e meta-objetos executam procedimentos de controle sobre o comportamento da

aplicao.
Os objetos-base tempo-real apresentam estrutura e comportamento similar ao dos
objetos convencionais. Adicionalmente, so associadas aos seus mtodos restries temporais
(predefinidas ou construdas pelo programador) e manipuladores de exceo. Restries
temporais construdas pelo programador so declaradas no objeto-base e implementadas
atravs de procedimentos no meta-objeto gerenciador correspondente.
Os aspectos relativos a restries temporais e de sincronizao, escalonamento temporeal, e excees temporais so tratados a nvel-meta no modelo RTR. A nvel-meta o modelo
possui um meta-objetos gerenciador para cada objeto-base da aplicao, e mais dois metaobjetos especiais meta-objeto escalonador e meta-objeto relgio.
Os meta-objetos gerenciadores so objetos multi-threadeds responsveis pelo
gerenciamento dos pedidos de ativao dos mtodos de seus objetos-base correspondentes,
pelo controle de concorrncia em um objeto-base, pelo gerenciamento das restries de
sincronizao e pelo processamento das restries temporais, quando efetivamente decidido
pela ativao do mtodo solicitado ou pelo levantamento de uma exceo temporal.
Para cada pedido de ativao recebido pelo meta-objeto gerenciador, ativada uma
nova thread de controle, viabilizando o tratamento concorrente dos pedidos e permitindo um
tratamento mais efetivo das restries temporais a eles associadas.
Por outro lado, um mecanismo de controle da concorrncia garante a excluso mtua
no objeto-base, permitindo que somente um de seus mtodos esteja em execuo em um
determinado momento. Este controle realizado em funo do estado do objeto-base, mantido
a nvel de meta-objeto.
O meta-objeto escalonador tem como funo bsica receber, ordenar e liberar pedidos
de escalonamento de mtodos dos objetos base que compem a aplicao de acordo com
determinada poltica de escalonamento (predefinida ou introduzida pelo programador), visando
satisfazer as restries temporais da aplicao dentro de uma poltica de melhor esforo. Desta
forma, diferentes pedidos de escalonamento, originados de um ou vrios meta-objetos
gerenciadores, podem ser analisados globalmente e ordenados de acordo com a poltica de
escalonamento vigente.
O meta-objeto escalonador recebe do meta-objeto gerenciador requisies de
escalonamento de mtodos com restries temporais, e determina, de acordo com a poltica de
escalonamento implementada e com as restries temporais associadas, o momento a partir do
qual o mtodo em questo pode ser liberado para execuo. Com a liberao para execuo do
mtodo, em funo da disponibilidade de tempo e observados os aspectos de sincronizao e
concorrncia, o meta-objeto gerenciador decide pela liberao da execuo do mtodo
solicitado ou pelo levantamento de uma exceo temporal. Em seguida, aps a execuo do
mtodo a nvel-base, o controle devolvido para o meta-objeto gerenciador, que libera o
meta-objeto escalonador para que processe o prximo pedido da fila de requisies, e retorna
o resultado da execuo do mtodo para o objeto que efetuou a requisio.
O meta-objeto relgio uma abstrao do relgio do sistema, estruturada na forma de
objeto. Sua funo bsica receber pedidos do meta-objeto gerenciador para ativar mtodos
num tempo futuro, detectar violao de timeouts e eventuais violaes de restries associadas
com mtodos que esto aguardando para ser escalonados ou que aguardam o estabelecimento
de concorrncia ou sincronizao.

Na figura a apresentamos a dinmica de uma chamada de mtodo em uma aplicao

estruturada segundo o modelo RTR, composta por um conjunto de objetos-base e metaobjetos gerenciadores.
META-OBJETO
ESCALONADOR

META-OBJETO
RELGIO

55555

Meta-Objeto
Gerenciador

Meta-Objeto
Gerenciador

Objeto-Base

Objeto-Base

Meta-Objeto
Gerenciador
Nvel-Meta
Nvel-Base

Objeto-Base

Figura A Estrutura Geral do Modelo RTR

A interao entre objetos-base e meta-objetos do modelo inicia com um pedido de
ativao de um mtodo de um determinado objeto-base, que desviado para seu meta-objeto
gerenciador correspondente (ao da figura a). O meta-objeto gerenciador, por sua vez,
interage com o meta-objeto escalonador (ao ) e com o meta-objeto relgio (ao ) para
processar as restries temporais associadas ao mtodo solicitado, e se estas restries no
forem violadas, ativa o mtodo solicitado no objeto-base (ao ), retornando em seguida, via
meta-objeto gerenciador para o objeto que deu origem a chamada (aes e ).

3.2 Incorporao da Distribuio ao Modelo RTR

As interaes entre os componentes do modelo RTR seguem o paradigma clienteservidor. Objetos so divididos em nvel-base e nvel-meta tanto no cliente quanto no servidor
da aplicao. Em cada nodo do sistema temos, alm dos pares de objetos-base e meta-objetos
gerenciadores, um meta-objeto relgio e um meta-objeto escalonador [Fra 95].
No modelo RTR distribudo o escalonamento tratado a nvel local. Desta forma, cada
n possui um meta-objeto escalonador que trabalha independentemente na rede, influenciando
apenas o escalonamento local. As tarefas so primeiro alocadas aos nodos do sistema para
posteriormente serem escalonadas segundo critrios locais [Aud 90].
O escalonamento no Modelo RTR Distribudo ocorre em dois nveis distintos. Em um
primeiro nvel, h o escalonamento de mtodos de objetos-base realizado pelo meta-objeto
escalonador. Em um nvel mais baixo h o escalonamento realizado pelo ncleo do sistema
operacional subjacente.
De modo semelhante, cada n do sistema possui um meta-objeto relgio local, que
trabalha independentemente dos outros relgios localizados nos demais ns da rede. Em uma
requisio de mtodo, tanto o objeto cliente quanto o servidor do mtodo verificam o
cumprimento de restries temporais utilizando um meta-objeto relgio. O cliente verifica o
cumprimento do timeout da chamada com base no meta-objeto relgio local, enquanto o
objeto servidor controla o deadline do mtodo.

Obtemos a desejada interoperabilidade entre componentes distribudos heterogneos 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 padres e
conceitos propostos pela OMG (Object Management Group) para sistemas abertos. Na
arquitetura proposta, requisies de mtodos de objetos so feitas transparentemente em um
ambiente distribudo e heterogneo atravs do ORB (Object Request Broker).
A especificao CORBA [OMG 93] define as interfaces do ORB e estabelece o papel
de cada um de seus componentes no ambiente distribudo. As interfaces CORBA so
especificadas como uma camada, mascarando diferenas entre as diversas implementaes
possveis.
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 execuo de um mtodo, um
cliente CORBA utiliza stubs geradas na compilao da especificao de interface IDL do
objeto servidor, ou pode construir uma requisio utilizando a interface de invocao dinmica
DII (Dynamic Invocation Interface). Para permitir invocaes dinmicas, interfaces de objetos
devem ser armazenadas em um depsito de interfaces (Interface Repository).
O ORB implementa semnticas e abstraes da comunicao entre objetos na rede; ele
transmite a requisio atravs da rede e transfere o controle para um adaptador de objetos,
utilizado para ativar a operao na implementao do objeto (ou seja, no servidor) atravs de
skeletons IDL. O objeto servidor trata a requisio da mesma forma, independentemente do
mecanismo de invocao de mtodo utilizado esttico (stubs) ou dinmico (DII).

3.2.2 Objetos-Base e Meta-Objetos de Comunicao

Na chamada remota de mtodos, interfaces CORBA (stubs, DII e skeletons) so
transparentes para objetos-base. Aspectos referentes comunicao remota entre processos
so tratados por meta-objetos adicionais de comunicao, que encapsulam os aspectos
referentes s interfaces ORB.
As chamadas de mtodos remotos originadas de um objeto-base so redirecionadas
para MetaStubs, que modificam as stubs geradas pelo compilador IDL-CORBA de modo a
tratar os requisitos temporais de aplicaes tempo-real. MetaStubs so responsveis por,
interagindo com o meta-objeto relgio, controlar o timeout das chamadas de mtodos do
objeto-base. Como alternativa chamada por stubs, pode ser utilizada a interface de invocao
dinmica (DII) do CORBA e o meta-objeto MetaDII.
As chamadas de mtodos originrias de objetos remotos e destinadas a um determinado
objeto do modelo so recebidas atravs de skeletons e de MetaSkeletons, que modificam a
funcionalidade dos skeletons gerados pelo compilador IDL. Estes objetos recebem a requisio
atravs do ORB e chamam o respectivo mtodo 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 restries temporais e de sincronizao atravs da interao com
o meta-objeto escalonador e com o meta-objeto relgio de seu nodo.
Em uma aplicao distribuda, um cliente pode utilizar servios de diferentes
servidores; isto implica que o cliente precisa de um MetaStub para cada servidor do modelo.
Se a ligao entre cliente e servidor for dinmica, um MetaDII suficiente; o cliente estabelece

conexes com servidores utilizando a mesma interface DII CORBA. Da mesma forma,
servidores podem suportar vrios MetaSkeletons. A estrutura do modelo construdo segundo
uma arquitetura CORBA apresentada na figura b.
META-OBJETO
ESCALONADOR

META-OBJETO
RELGIO

55555

CLIENTE

Meta-Objeto
de
Meta
Stub
Meta
Stub//DII
DII
Comunicao
(MetaStub/DII)

Meta-Objeto
Gerenciador

Nvel-Meta
Nvel-Base

Objeto-Base

Objeto-Base
de
Meta
Stub
Meta
Stub/ /DII
DII
Comunicao
(Stub/DII)

META-OBJETO
ESCALONADOR

META-OBJETO
RELGIO

55555

Meta-Objeto
de
MetaStub
Stub//DII
DII
Meta
Comunicao
(MetaSkeleton)

SERVIDOR

Meta-Objeto
Gerenciador

Nvel-Meta
Nvel-Base

Objeto-Base
de
MetaStub
Stub/ /DII
DII
Meta
Comunicao
(Skeleton)

Objeto-Base

OBJECT REQUEST BROKER

Figura B Estrutura do Modelo RTR em uma Arquitetura CORBA

3.2.3 Comportamento da Comunicao no Modelo

O suporte de comunicao pode tratar chamadas de mtodos sncronas e assncronas.
Na figura b mostrado o comportamento dos componentes do modelo no caso a uma
chamada sncrona. No cliente, a chamada de um mtodo do objeto-base servidor deve estipular
as restries temporais e procedimentos de exceo para o caso destas restries serem
violadas, em uma estrutura como a que segue abaixo:
< id-objeto-servidor > . < id-mtodo > ( < parmetros > ),
Timeout ( < valor-do-timeout > ),
Exception
{
case reject : < procedimento-de-exceo >
case abort
: < procedimento-de-exceo >
case timeout : < procedimento-de-exceo >
}

Em sistemas abertos, alm das excees reject (restrio violada antes do incio da
execuo do mtodo do objeto-base) e abort (execuo do mtodo j havia sido iniciada)
definidas pelo modelo RTR, deve ser previsto um novo tipo de exceo de modo a indicar a
ocorrncia de uma violao do timeout imposto pelo cliente. A exceo timeout detectada
pelo cliente com o auxlio do meta-objeto relgio e comunicada ao meta-objeto servidor
atravs do suporte de comunicao.
A chamada realizada pelo cliente encaminhada via um MetaStub para o servidor ao
qual se destina a requisio (ao da figura b). O MetaStub requisita o mtodo chamado
pelo objeto-base atravs do ORB utilizando stubs (ao ), e envia ao meta-objeto relgio o
valor de timeout associado chamada (ao ). O MetaStub passa a aguardar uma mensagem
de resposta do servidor, ou do meta-objeto relgio, sinalizando uma violao de timeout.
A requisio do mtodo chega ao servidor correspondente atravs do ORB, que ativa o
mtodo utilizando skeletons CORBA e MetaSkeletons. A ativao desviada para o metaobjeto gerenciador do servidor (ao da figura b), que interage com o meta-objeto

escalonador do servidor (ao ), aguardando por uma autorizao para ativar o mtodo
requisitado. Quando o meta-objeto escalonador sinaliza que o mtodo deve ser executado, o
meta-objeto gerenciador do servidor verifica se as restries temporais (ao ) e de
sincronizao foram violadas, retornando uma exceo reject neste caso. Caso contrrio, o
mtodo chamado no objeto-base do servidor (ao ). Concluda a chamada, ocorre
novamente a verificao das restries temporais, resultando em uma exceo abort caso
estas tenham sido violadas. O resultado da chamada enviado na forma de parmetros ao
objeto-base do cliente, passando atravs do ORB (usando stubs e skeletons) e de MetaStub
(aes , e ).
No caso de, antes da finalizao do protocolo, o meta-objeto relgio reportar a
MetaStub uma violao de timeout (ao da figura b), uma indicao de exceo enviada
ao objeto cliente (ao ). Em seguida, MetaStub remete atravs do ORB e do MetaSkeleton
a indicao de exceo do tipo timeout ao meta-objeto gerenciador do servidor (aes ,
e ), que se encarrega de cancelar a execuo do mtodo, retirando a requisio da fila de
pedidos do escalonador ou interrompendo a execuo do mtodo no objeto-base.
Utilizamos uma estrutura semelhante na implementao da chamada assncrona,
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 execuo do mtodo no servidor (ou seja, em uma chamada do tipo semisncrona), este pode verificar se a resposta se encontra disponvel em um momento posterior,
ou mesmo bloquear-se espera da chegada da resposta.

Mapeamento e Implementao do Modelo

4.1 Mapeamento do Modelo RTR Distribudo

Para testar a potencialidade do Modelo RTR, realizamos o mapeamento das abstraes
definidas pelo modelo para elementos do sistema operacional Solaris*. O Solaris possui
caractersticas que o tornam adequado para utilizao em ambiente tempo-real, como um
mecanismo de escalonamento baseado em prioridades e classes de escalonamento, dentro das
quais vigoram polticas distintas; bloqueio de pginas de memria; operaes de entrada e
sada assncronas; e multi-threading.
Cada par composto por um objeto-base e seu meta-objeto gerenciador, juntamente
como os objetos adicionais de comunicao utilizados na interao com outros objetos do
modelo stubs e MetaStubs, MetaDII, skeletons e MetaSkeletons corresponde a um
processo Solaris. Meta-objeto escalonador e meta-objeto relgio so implementados em
processos distintos.
Utilizamos threads para permitir concorrncia interna nos meta-objetos, em conjunto
com ORBs que possibilitem o multi-threading em objetos CORBA. Desta forma, vrias
requisies podero ser processadas simultaneamente pelo meta-objeto. Cada meta-objeto do
modelo RTR deve possuir threads de gerenciamento, responsveis pela interao com o ORB,
recebendo e enviando requisies de mtodos, e pela criao de uma thread de dispatch para
cada invocao de mtodo do objeto. As threads de dispatch de mtodos processam as

Solaris uma marca registrada da Sun Microsystems

requisies recebidas pelos objetos, tratando-as segundo o modelo RTR distribudo conforme
especificado na seo 3.2.3.
Objetos do modelo devem pertencer classe de escalonamento Real-Time (RT)
Solaris, com quantum de tempo infinito (ou seja, tempo de execuo do processo ilimitado). A
atribuio de prioridades tempo-real aos processos aos quais pertencem os objetos-base e
meta-objetos do modelo ocorre durante a criao do meta-objeto.
Atravs do estabelecimento de prioridades utilizadas pelo Solaris no escalonamento a
processos e threads, em conjunto com a utilizao do meta-objeto escalonador para determinar
a ordem a ser obedecida na execuo dos mtodos requisitados, ser obtido o comportamento
desejado dos objetos da aplicao em conformidade com o especificado pelo modelo.
Se analisarmos apenas o processamento de mtodos a nvel-base, haver preempo
de mtodos dos objetos-base somente quando o mtodo em execuo chamar de modo
sncrono um outro mtodo com restries de tempo associadas, e residente em outro objeto
ou seja, em caso de chamadas aninhadas. Neste caso, ser processada a chamada, o mtodo
aguardar a execuo desta, mas o suporte deve impedir que acontea a execuo de um outro
mtodo do mesmo objeto em nvel-base devido s restries de excluso mtua que devem ser
garantidas no objeto-base.
Enquanto estiverem somente processando requisies de mtodos a nvel-meta, os
processos com objetos do modelo devem possuir uma mesma prioridade fixa. No caso do
processo receber a liberao do meta-objeto escalonador para executar um mtodo a nvelbase, este deve modificar sua prioridade para o valor que lhe for atribudo pelo escalonador,
situado dentro de uma faixa de prioridades de nvel-base, que ser determinado em funo do
nmero de objetos suspensos aguardando o retorno de chamadas sncronas aninhadas naquele
nodo da rede. Deste modo, garantimos que o objeto que realizou a chamada aninhada ir
reassumir o processador assim que terminar a execuo do mtodo requisitado.

4.2 Implementao do Modelo RTR Distribudo

A implementao do prottipo do modelo RTR distribudo foi realizada sobre o
sistema operacional Solaris verso 2.4. Para suprir as necessidades do modelo relacionadas
utilizao de uma plataforma CORBA, empregamos o ORBeline 1.0, uma implementao
comercial de ORB de responsabilidade da Post Modern Computing. O ORBeline 1.0
compatvel com a primeira verso da especificao CORBA e de acesso gratuito para
universidades e institutos de pesquisa.
O prottipo do modelo RTR se encontra em pleno funcionamento. Foram necessrias
algumas restries e simplificaes em relao ao mapeamento do modelo RTR distribudo,
devido s limitaes encontradas no suporte utilizado (no-disponibilidade de threads e bugs
encontrados no ORBeline). Desta forma, alguns aspectos no puderam estar presentes na
implementao do prottipo.
Foi suprimida a concorrncia interna dentro do meta-objeto devido impossibilidade de
utilizao de threads juntamente com o ORBeline. Deste modo, cada meta-objeto pode
atender somente uma requisio por vez, resultando na criao de uma fila com ordenao
FIFO onde so armazenadas as requisies de mtodos que chegam a um determinado objetobase. A concorrncia entre requisies direcionadas a objetos-base diferentes continua
existindo e seguindo a poltica de escalonamento implementada no meta-objeto escalonador do
modelo.

Os valores de restries e excees temporais, que inicialmente deveriam ser

transmitidos respectivamente na forma de objetos de contexto e excees CORBA, foram
passados como parmetros adicionais de chamada, devido a problemas tanto nos objetos de
contexto quanto nas excees implementadas no ORBeline 1.0. Desta forma, os mtodos
descritos na declarao de interface de um objeto ganharam um parmetro adicional, visvel
apenas nos meta-objetos gerenciadores e de comunicao, adicionado posteriormente aos
parmetros originais do mtodo.
Devido inexistncia de um suporte para threads no ORB, os meta-objetos de
comunicao foram implementados utilizando a interface de invocao dinmica e o depsito
de interfaces do ORBeline. O comportamento desejado nas chamadas de mtodos de objetos
do modelo foi obtido atravs da utilizao de MetaDII, implementado atravs de sobrecarga de
funo nas requisies criadas pela interface de invocao dinmica. Se forem utilizadas stubs,
o cliente deve optar em tempo de compilao pela utilizao 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 so implementados como objetos C++ (e no objetos CORBA),
enquanto somente os meta-objetos gerenciadores correspondentes so visveis externamente
do ponto de vista do CORBA.
Cada meta-objeto gerenciador possui um apontador direcionado para o objeto-base
correspondente, possibilitando o acesso aos mtodos de nvel-base. O objeto-base no recebe
do meta-objeto os parmetros relativos s restries temporais, o que garante a transparncia
em sua programao.
O meta-objeto gerenciador interage com os meta-objetos adicionais do modelo metaobjeto escalonador e meta-objeto relgio atravs de stubs de comunicao, que simplificam a
interao com os referidos meta-objetos do ponto de vista do programador da aplicao a
nvel-meta.

5 Desenvolvimento de Aplicaes Utilizando o

Modelo
O desenvolvimento de aplicaes distribudas segundo o modelo reflexivo tempo-real
segue as etapas ilustradas na figura c.
Consiste em uma obrigao do usurio escrever o cdigo da aplicao a nvel-meta e
nvel-base, de maneira a definir a funcionalidade do objeto e os mecanismos de controle aos
quais o mesmo deve ser submetido. Adicionalmente, no prottipo do modelo implementado
neste trabalho, o usurio deve descrever a interface do servidor da aplicao em linguagem
IDL e, como no dispomos de um gerador de cdigo para MetaStubs e MetaSkeletons a partir
da especificao IDL, a codificao dos meta-objetos de comunicao tambm deve ser
realizada pelo programador da aplicao.
O suporte provido pelo prottipo do modelo RTR distribudo simplifica
consideravelmente a programao a nvel-meta atravs da utilizao de restries temporais,
procedimentos de exceo e mtodos de gerenciamento predefinidos, contidos em uma
biblioteca, que podem ser incorporados ao cdigo da aplicao no procedimento de
linkagem. Para os casos em que o cliente da aplicao utilizar a interface de invocao
dinmica (DII) na interao com o servidor, basta para o programador incluir um arquivo com
o cdigo de MetaDII no meta-objeto cliente, tornando desnecessria a codificao de qualquer
objeto adicional alm do cdigo do cliente nos nveis base e meta.

Descrio de
Interface IDL
do Servidor
Base
Compilador IDL - CORBA
Cd. Fonte Cd. Fonte
Cdigo
do Obj-Base do Meta-Obj Fonte das
Cliente
Cliente
MetaStubs

Cdigo
Fonte das
Stubs

Cdigo
Fonte do
Skeleton

Cd. Fonte Cd. Fonte

Cdigo
do Obj-Base do Meta-Obj
Fonte do
Servidor
Servidor
MetaSkeleton

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

Cd. Objeto Cd. Objeto
Cdigo
do Obj-Base do Meta-Obj Objeto das
Cliente
Cliente
MetaStubs

Cdigo
Objeto das
Stubs

Cdigo
Objeto do
Skeleton

Cd. Objeto Cd. Objeto

Cdigo
Objeto do do Obj-Base do Meta-Obj
Servidor
MetaSkeleton Servidor

Linker do Sistema

CLIENTE
DA APLICAO

Cdigo
Executvel
do Cliente

Cdigo
Executvel
do Servidor

SERVIDOR
DA APLICAO

Figura C Desenvolvimento de Aplicaes Distribudas no Modelo RTR

Exemplo de Aplicao do Modelo RTR Distribudo

Ilustraremos o uso do modelo proposto atravs de uma exemplo de aplicao. O

exemplo escolhido consiste na exibio de um documento multimdia, onde dados de diversas
mdias so obtidos de servidores localizados em diferentes nodos de uma rede heterognea.
A forma proposta para implementao do exemplo de exibio de um documento
multimdia segue o modelo cliente-servidor. A figura d mostra a obteno progressiva e o
esquema de apresentao de um documento multimdia, envolvendo diferentes servidores de
mdia : som, imagem, texto, e possivelmente outras mdias.
O arquivo descrevendo o documento a ser composto armazenado em uma base de
dados local, que contm informaes acerca das partes dos documentos, seus tempos de
apresentao, e o cenrio relativo sincronizao das mdias. A partir deste cenrio, o
programa de composio do documento cria os clientes de cada mdia contida no documento.
Os clientes so os elementos responsveis pela obteno e exibio de uma mdia
especfica. Cada cliente de uma determinada mdia utilizada no documento deve requisitar ao
servidor correspondente, receber e armazenar em buffers a informao descrevendo a mdia
em questo. Cada cliente deve possuir dois buffers para evitar a descontinuidade na
apresentao, solucionando problemas como jitter e overhead. Enquanto um dos buffers
estiver sendo esvaziado, o outro deve ser preenchido com informaes da mdia recebida.
Os dados so fornecidos ao cliente e reunidos para a construo do documento
multimdia. Os dados do documento so obtidos e apresentados pelos clientes de mdia em
tempo-real ou seja, os dados so exibidos assim que recebidos do servidor.
Os servidores atuam em um esquema de fornecimento de mdia sob demanda, ou seja,
os dados so enviados ao cliente quando for recebida uma requisio. Desta forma fazemos
com que o servidor respeite o fluxo de execuo e a taxa de transmisso de dados impostos
pelo cliente.

Estao A

Estao B

Estao C

Servidor
de Som

Servidor
de Imagem

Servidor
de Texto

Cliente
de Som

Cliente
de Imagem

Cliente
de Texto

Composio do
Documento Multimdia

Figura D Exemplo de Aplicao do Modelo RTR Distribudo

A forma de armazenamento de dados utilizada disco rgido, fita, CD, ou qualquer
outro dispositivo de armazenamento de informao compete exclusivamente ao servidor de
mdia. O cliente de uma determinada mdia conhece apenas a interface do servidor
correspondente, recebendo os dados referentes mdia atravs de requisies de servio
enviadas a este servidor.
Mecanismos de sincronizao entre as mdias podem ser utilizados neste tipo de
aplicao, com o objetivo de manter uma relao de sincronismo imposta pelo documento
multimdia entre as diversas mdias utilizadas. Em muitos casos, pode haver a necessidade de
sincronizao entre imagem e som (para sincronizao de lbios), ou imagem e texto
(legendas), por exemplo.

6.1 Estrutura da Soluo

Foram implementados pares cliente-servidor para udio e imagem. Os servidores de
udio e imagem possuem uma mesma estrutura, recuperando a informao relativa mdia na
forma de arquivos armazenados em disco. O servidor possui operaes de abertura do
arquivo, leitura de parte do arquivo, e retrocedimento at o incio do mesmo.
Os clientes foram implementados utilizando cdigo de software de domnio pblico
para exibio das mdias de modo centralizado (no distribudo). Isto mostra a perfeita
adequao do modelo para reutilizao de software de modo simples e flexvel. Devido s
caractersticas do modelo RTR, no foram necessrias alteraes no corpo destes programas
para adaptao ao ambiente distribudo e para controle de requisitos temporais, pois estas
alteraes puderam ser realizadas a nvel-meta. Alteraes na funcionalidade dos programas,
efetuadas a nvel-base, foram necessrias principalmente para suprimir o tratamento local da
mdia (leitura de arquivos substituda por chamadas aos servidores) e para permitir a exibio
da mdia antes do recebimento de toda a informao.
Para emisso de udio foi utilizado o cdigo do programa de domnio pblico Xplay
(verso 0.7, Robert S. Thau, MIT AI Lab), adicionado de algumas adaptaes necessrias
para permitir a emisso do som de modo simultneo ao recebimento dos dados (a verso

original do Xplay s emite o som aps a leitura completa do arquivo). O programa Xplay
pode manipular arquivos nos formatos Sun Audio, Windows Wave, e AIFF, e possui uma
interface grfica de acordo com o padro Motif , permitindo operaes de pausa, retorno e
avano do som, controle de volume e do dispositivo de sada utilizado (alto-falante ou fone de
ouvido).
Para exibio da imagem utilizamos um decodificador de arquivos no formato MPEG,
o programa de domnio pblico mpeg_play (verso 2.0, Computer Science Division,
University of California at Berkeley). A verso utilizada adota uma interface grfica Motif
para o mpeg_play ( The Geometry Center; University of Minnesota), com comandos de
pausa, avano 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 decodificao e exibio da imagem.

6.2 Implementao do Exemplo sobre o Modelo RTR Distribudo

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 mdia devem especificar as restries temporais impostas ao processo de
recuperao da mdia armazenada no servidor. Os valores das restries temporais devem ser
obtidos em funo da qualidade de servio exigida pelo cliente, considerando fatores como o
tempo necessrio para que no ocorram interrupes perceptveis na exibio da mdia na
estao cliente e a quantidade de dados disponveis no buffer do cliente aguardando para ser
exibidos.
Neste exemplo foi utilizado o meta-objeto escalonador que implementa a poltica de
escalonamento tempo-real com base em deadlines (EDF - Earliest Deadline First). A poltica
utilizada mostrou-se adequada para este tipo de aplicao.

6.2.1 A Descrio de Interface do Servidor

Um descrio de interface IDL para o objeto servidor de mdia apresentada na
listagem a. A traduo desta interface IDL gera os objetos-base stub e skeletons para o
servidor de mdia.
No arquivo IDL que descreve a interface do servidor de mdia foi declarado o tipo
BufType, utilizado pelo buffer atravs do qual a mdia transmitida ao cliente, como sendo
uma seqncia do tipo octet, um tipo definido pelo CORBA de tamanho igual a um byte

(oito bits) e que no sofre nenhum tipo de converso de dados na sua transmisso.
#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 Mdia

So declaradas na interface do servidor operaes de abertura do processo de

transmisso de uma determinada mdia (open_media), retorno ao incio da mdia
(rewind_media) e leitura de uma quantidade de dados especificada pelo cliente referente
mdia em questo (read_media).
Aspectos relacionados implementao do mecanismo de transmisso de parmetros e
excees temporais so tratados no arquivo includo RTparams.idl.

6.2.2 Descrio do Servidor de Mdia

A funcionalidade dos servidores de mdia, implementada a nvel-base, consiste apenas
em recuperar a informao relativa mdia em questo que se encontra armazenada em
arquivos codificados segundo um determinado padro. A informao recuperada deste arquivo
enviada ao cliente, que deve decodificar a informao e exibir a mdia.
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 Descrio do Objeto-Base Servidor de Mdia

Na listagem b apresentamos a descrio do objeto-base servidor de mdia,
implementado em C++. Como tanto udio e imagem so armazenados e transmitidos da
mesma maneira (atravs de arquivos decodificados pelo cliente), o mesmo servidor utilizado
para ambas as mdias.
Em cada servidor de mdia, a operao de obteno dos dados vista como uma
operao aperidica, e um deadline especifica o tempo mximo dentro do qual a operao
deve ser executada.
A verificao de restries temporais e de sincronizao, e o tratamento de excees,
assim como a comunicao entre objetos via ORB, so tratados a nvel-meta.
A listagem c apresenta a descrio do meta-objeto servidor de mdia. Como podemos
observar, este objeto herda as operaes de interfaceamento com o ORB a partir da classe
meta_impl, gerada pelo compilador IDL-CORBA. Em adio aos parmetros do objetobase, este meta-objeto recebe como ltimo parmetro de cada uma das trs operaes
definidas em sua interface um descritor rt, do tipo RTparams, onde so especificados os
valores das restries temporais impostas na execuo do mtodo e indicada a ocorrncia de
uma exceo 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 Descrio do Meta-Objeto Servidor de Mdia

Na listagem d apresentamos o mtodo open_media do meta-objeto do servidor. Este
mtodo processa a requisio recebida do cliente e interage com os meta-objetos escalonador e
relgio de modo a estabelecer o comportamento desejado pelo modelo conforme a poltica de
melhor esforo para execuo do mtodo a nvel-base.
CORBA::Long MetaMedia::open_media ( const CORBA::String& name ,
RTparams& rt )
{
CORBA::Long ret;
// valor de retorno do mtodo
// Inicia contador do meta-objeto relgio
metaclock.start_time();
// Aguarda permisso para executar do meta-obj escalonador
metasched.getprio(rt.deadline());
// Avalia se existe tempo para executar o mtodo
if( (rt.deadline() !=0) &&
( (metaclock.get_time()+rt.tme()) > rt.deadline() ) ) {
rt.exc(REJECT);
// No h tempo rejeitar
} else {
// H tempo
// Muda prioridade para a definida pelo escalonador
metasched.raiseprio();
// Executa o mtodo do objeto-base
ret = media_base.open_media(name);
// Verifica o tempo total gasto na execuo do mtodo
if ( ( rt.deadline() != 0 ) &&
( metaclock.get_time() > rt.deadline() ) ) {
rt.exc(ABORT);
// Deadline violado abortar
}
}
// Devolve a permisso ao escalonador e retorna
metasched.release();
return ret;
}

Listagem D Mtodo open_media do Meta-Objeto Servidor de Mdia

6.2.3 Descrio dos Clientes de Mdia

Os objetos de nvel-base dos clientes recebem os dados dos servidores e exibem esta
mdia na estao do usurio, utilizando dispositivos perifricos como o alto-falante e o
monitor. O cdigo destes objetos consiste basicamente nos programas de exibio de mdias
citados anteriormente.
A cada requisio enviada por um cliente a um servidor de mdia, um valor de timeout
expressa o tempo de espera aceitvel do cliente para estes dados. A verificao e o tratamento
de excees so realizados no objeto-base. Em caso de uma exceo do tipo reject, o
estado do servidor no alterado e o cliente pode tentar executar a requisio novamente,
desde que respeitadas as restries impostas. No caso de excees do tipo abort ou
timeout, o estado do servidor foi alterado e o cliente no pode continuar o procedimento de
exibio da mdia sem perda de informao, devendo ento indicar a exceo e interromper sua
execuo.
A listagem e mostra a forma como o objeto-base do cliente de imagem, implementado
na linguagem C++, requisita ao servidor correspondente a mdia armazenada na forma de uma
arquivo MPEG. O cliente especifica o nmero mximo de bytes que devem ser lidos
(parmetro num_bytes) e as restries temporais associadas (parmetro rt, do tipo
RTparams). A informao lida depositada em um buffer (mybuf) e a chamada retorna o
nmero de bytes lidos (num_read). Atravs do campo de indicao de excees exc do
parmetro rt verificado se ocorreu alguma violao de exceo 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 Mdia no Cliente de Imagem MPEG

A nvel-meta os clientes implementam a semntica de comunicao do modelo,
utilizando o ORB, e controlando as restries impostas execuo das chamadas remotas de
mtodos.

6.2.4 Meta-Objetos de Comunicao

Os meta-objetos de comunicao MetaStub e MetaSkeleton interagem com o
suporte de comunicao provido pelo ORB, modificando o comportamento de stubs e
skeletons gerados pelo compilador IDL.
No prottipo implementado, MetaStubs utilizam a interface de invocao dinmica
para fazerem uma requisio de um mtodo de um servidor remoto. No houve necessidade de

alterar o comportamento dos skeletons IDL, o que implicou na utilizao de MetaSkeletons

nulos, que apenas repassam as chamadas recebidas ao meta-objeto do servidor.
A implementao do mtodo open_media da MetaStub do servidor de mdia
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; // requisio
CORBA::Long
ret;
// valor retornado
// Cria requisio 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 (parmetros)
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 mtodo com o timeout especificado
req->invoke( rt.timeout() );
// Atualiza exceo com valor retornado pelo servidor
rt.exc ( (timing_exception_id)req->arg(1)->member("exc") );
// Obtm o valor retornado pelo mtodo do servidor
if (rt.exc() == NONE )
ret = (CORBA::Long)(*req->result());
return ret;
}
...

Listagem F MetaStub para o Objeto Servidor de Mdia

6.3 Consideraes Relativas Implementao

A soluo adotada para resolver o problema de transferncia de mdias em um sistema
aberto para a composio de um documento multimdia mostra algumas das caractersticas do

modelo reflexivo tempo-real distribudo que facilitam a programao de aplicaes com

restries temporais em sistemas abertos.
A anlise da implementao realizada sobre o prottipo do modelo RTR distribudo
nos leva a fazer as seguintes constataes em relao programao da aplicao :
O projeto da aplicao tem como ponto de partida tcnicas de orientao a objeto
tradicionais e bem conhecidas pelos programadores, no introduzindo novas abstraes
ou conceitos de difcil compreenso.
O modelo permite um alto grau de reutilizao de cdigo de aplicaes j existentes na
implementao da funcionalidade dos objetos-base neste exemplo, podemos constatar
tal fato nos objetos-base de exibio de mdia. A programao destes objetos-base no
sofreu grandes alteraes derivadas da distribuio intrnseca do sistema, e nem mesmo
devido aos requisitos de tempo-real exigidos da aplicao.
A transparncia na programao a nvel-base, tanto no cliente quanto no servidor da
aplicao, so fatores de vital importncia para permitir ao programador preocupar-se
somente com a implementao da funcionalidade da aplicao na definio do
comportamento do objeto-base. Estudos mostram que a soluo de grandes problemas
bastante facilitada quando estes so divididos em problemas menores que podem ser
solucionados isoladamente.
A forma na qual foi estruturada a aplicao conduz a um grande ndice de flexibilidade
de programao. Componentes podem ser trocados, inseridos ou removidos sem
implicar em modificaes em diversas partes do cdigo da aplicao.
A troca da poltica de escalonamento utilizada pode ser efetuada atravs da simples
substituio do meta-objeto escalonador por um outro. A manuteno da interface
utilizada pelos meta-objetos gerenciadores para comunicao com o meta-objeto
escalonador garante que no sero necessrias alteraes no cdigo da aplicao.
A manuteno do sistema fica bastante simplificada, pelo fato de a aplicao
propriamente dita, implementada a nvel-base, estar separada dos mecanismos de
suporte que permitem a comunicao no ambiente distribudo e o controle dos
requisitos temporais da aplicao, efetuados pelos meta-objetos. Um programador, sem
tomar conhecimento do cdigo a nvel-meta, pode realizar a manuteno do software a
nvel-base. De modo semelhante, a correo do comportamento temporal ou do
protocolo de comunicao exigem conhecimento apenas dos meta-objetos utilizados,
abstraindo completamente a funcionalidade da aplicao.
Restries temporais e meta-objetos (inclusive escalonador, relgio e meta-objetos de
comunicao) podem ser reutilizados em outras aplicaes implementadas de acordo
com o modelo RTR.

Concluses e Perspectivas

Este artigo descreveu um modelo de programao de aplicaes tempo-real em

sistemas distribudos abertos, o Modelo Reflexivo Tempo-Real (RTR) Distribudo, seu
mapeamento e implementao sobre uma plataforma de execuo, e o desenvolvimento de
uma aplicao tempo-real utilizando o referido modelo.
O Modelo RTR permite que mecanismos de controle de restries temporais e polticas
de escalonamento adequados s necessidades especficas de uma aplicao sejam introduzidos
e/ou modificados diretamente pelo programador da aplicao a nvel-meta, sem implicar em

alteraes no cdigo da aplicao ou no suporte de execuo, conforme visto no exemplo de

aplicao.
Em adio flexibilidade provida pela possibilidade de programao em nvel-meta, o
uso de reflexo computacional no Modelo RTR, ao permitir que a funcionalidade de uma
aplicao seja implementada separadamente do controle de seu comportamento, proporciona
um maior grau de reutilizao e facilita o desenvolvimento e a manuteno de aplicaes
tempo-real.
O modelo de programao RTR integrado a sistemas abertos utilizando o modelo de
objetos adotado pelo CORBA, no qual as interaes acontecem segundo o paradigma clienteservidor, e atravs da adoo de mecanismos de tratamento da questo temporal adequados ao
ambiente distribudo e heterogneo. As restries de tempo so tratadas localmente a partir da
especificao de um timeout no cliente e do deadline associado no servidor. Desta forma, o
modelo garante um tratamento adequado para aplicaes tempo-real do tipo melhor esforo
em ambientes distribudos abertos.
Adicionalmente, foram realizados o mapeamento e a implementao do modelo numa
plataforma distribuda. O mapeamento do modelo considerou como base uma plataforma
CORBA e o sistema operacional Solaris, da Sun Microsystems. A implementao do modelo
distribudo se encontra concluda e em pleno funcionamento.
O processo de desenvolvimento de aplicaes distribudas com restries temporais
envolvidas foi ilustrado atravs de um exemplo de programao de uma aplicao de
multimdia distribuda, consistindo basicamente de um sistema de fornecimento de mdias sob
demanda para composio de um documento multimdia.
A continuidade do trabalho apresentado neste artigo segue atualmente vrias direes,
como a utilizao do modelo RTR distribudo em aplicaes de multimdia distribuda, o
desenvolvimento de ferramentas de anlise temporal, e a especificao de uma linguagem
tempo-real com base nas caractersticas do modelo RTR.
Encontra-se em fase de especificao uma linguagem de programao tempo-real
baseada na linguagem Java. A linguagem Java-RTR ir incorporar as caractersticas presentes
no modelo RTR. Java-RTR ser construda de maneira a permitir o clculo do tempo mximo
de execuo de programas e a utilizao de ferramentas para anlise do comportamento
temporal dos mesmos.
O desenvolvimento de ferramentas para anlise temporal de programas consiste em
outra das atividades em curso, previstas no sentido de providenciar um ambiente de
programao para o tipo de aplicaes citadas. Atravs destas ferramentas ser possvel
analisar o comportamento temporal de programas desenvolvidos segundo o modelo reflexivo
tempo-real.
A utilizao do modelo RTR distribudo para a programao de aplicaes de
multimdia consiste em um outro trabalho que se encontra em andamento. As caractersticas do
modelo sero exploradas de modo a permitir a transmisso e exibio de mdias em sistemas
abertos levando em conta requisitos de tempo e sincronismo derivados da qualidade de servio
imposta pelos clientes da aplicao. Sero explorados mecanismos de computao imprecisa
atravs de mltiplas verses de mtodos que propiciem servios com nveis de qualidade
diferentes, de modo a permitir a satisfao das restries impostas sem implicar na interrupo
do funcionamento da aplicao.

Alm dos trabalhos que se encontram em andamento e que de alguma forma esto
relacionados com o modelo reflexivo tempo-real, podemos destacar outras propostas de
continuidade do trabalho desenvolvido nesta dissertao.
Primeiramente, apresentamos como proposta de trabalho a ser desenvolvido a
implementao de ferramentas de auxlio programao de aplicaes utilizando o modelo
RTR distribudo.
Uma outra possibilidade de continuidade do trabalho apresentado nesta dissertao
consiste no mapeamento do modelo RTR distribudo sobre outras plataformas de execuo,
alm da plataforma Solaris. Este trabalho seria seguido da implementao do modelo sobre
estas novas plataformas adicionada de um ORB para prover a comunicao em ambiente
aberto.
Finalmente, como perspectiva de um futuro trabalho propomos a validao do modelo
RTR distribudo a partir de aplicaes com maior grau de complexidade, envolvendo um
ambiente realmente heterogneo, o que seria possvel a partir do mapeamento do modelo sobre
outras plataformas de execuo, e a avaliao do modelo comparando-o com outros modelos
tempo-real como os apresentados em [Hon 94], [Kim 94], [Li 94] e [Tak 92].

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. Prennou; Z. Wu Implementing Fault-Tolerant

Applications using Reflective Object-Oriented Programming, 25th IEEE Workshop on
Future Trends in Computer Science (FTCS95), 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 (FTDCS95), August 1995.

[Fur 95]

O. J. V. Furtado Um Modelo e uma Linguagem para Aplicaes Tempo Real, Exame de

Qualificao para Doutorado, PGEELUFSC, 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-TR93-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, COMPSAC94 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 Objectoriented 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, OOPSLA92 Conference Proceedings, October 1992.