Programação de aplicações com requisitos temporais em sistemas abertos : o modelo de objetos reflexivo tempo-real distribuido

UNIVERSIDADE

FEDERAL

DE

SANTA

CATARINA

PROGRAMA

DE

POS-GRADUAÇÃO

EM

ENGENHARIA

ELETRICA

PROGRAMAÇÃO

DE

APLICAÇÕES

COM

REQUISI'I*OS

TEIVIP-ORAIS

EM

SISTEMAS

ABERTOS

:

O

MODELO

DE

0E.I;E'I'OS

REFLEXIVO

TEMPO-REAL

DISTRIEIIIÍDO

DISSERTAÇÃO

SUBMETIDA

À

UNIVERSIDADE

FEDERAL DE

SANTA

CATARINA

PARA

A

OBTENÇÃO

DO GRAU

DE

MESTRE

EM

ENGENHARIA

PROGRAMAÇÃO

DE APLIÇAÇOES

COM» REQUISITOS

TEMPORAIS

EM

SISTEMAS

ABERTOS

;

O

MODELO

DE OBJETOS

REFLEXIVO

TEMPO-REAL

DISTRIBUIDO

FRANK

SIQUEIRA

ESTA

DISSERTAÇÃO

POI

JULGADA

PARA

A OBTENÇÃO

DO

TITULO DE

MESTRE

EM

ENGENHARIA,

r _

ESPECIALIDADE

ENGENHARIA

ELETRICA,

AREA

DE

CONCENTRAÇÃO

“SISTEMAS

DE

CONTROLE

E

AUTOMAÇÃO

INDUSTRIAL”,

E

APROVADA

EM

SUA

FORMA

FINAL

PELO

CURSO

DE PÓS-GRADUAÇÃO.

BANCA

EXAMINADORA

Pro _ V 1 da Sil

agaí

/

Orientador

H

Prof. Enio

Valmor

Kassick; Dr.

Coordenador do Curso de Pós-Graduação

em

Engenharia Elétrica

/T

- ›

/L

Pro .J aSilva Fraga, r '

A

`

Orientador

WE vc¿z

Prof. Jean-M Ie Farines,

Prof. Orlando G. Loques FI O, Ph.D.

Universidade Federal Fluminense

fia¬`/\z-~f»_z¡õ

./¬/

fz./Í»

Prof.

Raimundo

J. ‹£l`AfàújóI<izÍz/eai),

PED.

Resumo

Este trabalho apresenta

um

modelo para aplicações distribuidas

com

restrições tempo- real

em

sistemas abertos.

O

Modelo

Reflexivo Tempo-Real

_(RTR)

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

RTR

possui dois niveis :

um

nível-base que trata da funcionalidade do sistema, e

um

nivel-

meta que lida

com

escalonamento, restrições temporais e de sincronização, assim

como

tratamento de exceções.

O

Modelo

RTR

é implementado

em

sistemas distribuidos abertos utilizando 0 padrão

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

.

Descreveremos o

mapeamento

e a implementação de

um

protótipo do

Modelo

RTR

Distribuído sobre 0 sistema o eracional Solaris.

As

caracteristicas .rinci ais P do

modelo

proposto são ilustradas

em

um

exemplo de aplicação de multimídia distribuída.

O

Abstract

This work presents a model for distributed applications with real-time constraints in

open systems.

The

Real-Time Reflective

(RTR) Model

adopts the reflective paradigm

according to the meta-object approach, which provides the separation

among

functionality

and

management when

programming applications. Consequently, the

RTR

model has

two

levels 1 a base-level which deals with system functionality, and a meta-level which

manages

scheduling, time and synchronization constraints, as well as exception handling. z A

_

The

RTR

model is implemented in open distributed systems using the

CÚRBA

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

we

will describe the mapping and implementation of a prototype of the

RTR

Distributed

Model

on the Solaris operating system.

The

main characteristicsof the proposed model are

shown

in an example of a distributed multimedia application. `

j,; _ ;

\ ~

Índice

1.

INTRODUÇÃO

1 1.1 OBJETIVOS

DO TRABALHO

1.2

ESTRUTURA DA

DISSERTAÇÃO

2.

ANÁLISE

DO CONTEXTO DO TRABALHO

_A

3 4

6

2.1

AMBIENTES ABERTOS

E

O

PROCESSAMENTO

EM

TEMPO-REAL

' 2.1.1 CARACTERÍSTICAS DE SISTEMAS DISTRIBUÍDOS ABERTOS

2.1.2 PRINCIPAIS PROPOSTAS E EXPERIÊNCIAS PARA

PROGRAMAÇÃO EM

SISTEMAS

ABERTOS

2.1.2.1

SPML

2.1.2.2

DCE

e

OO-DCE

2.1.2.3

ODP

e

ANSA

2.1.2.4

ORB

e

CORBA

` 2.1.3 SISTEMAS TEMPO-REAL O 2.1.4 TEMPO-REAL

EM

SISTEMAS ABERTOS

2.1.4.1

Modem

de Objetos Tempo-Real

ANSA

2.1.4.2

CORBA

em

Sistemas Operacionais Tempo-Real `

2.2

PROPOSTA

DE

ABORDAGEM

DO

PROBLEMA

2.2.1

ADOÇÃO

DE

UM

MODELO

DE OBJETOS DISTRIBUIDOS 2.2.2

REFLEXÃO COMPUTACIONAL

`

2.2.2.1 Open

C++

2.2.2.2

ABCL

2.2.2.3

DRO

e

DROL

2.2.3 INOORPORÃÇÃO DE ASPECTOS RELACIONADOS À DISTRIBUIÇÃO 2.3

SUMÁRIO

6 7 8 9 ll 13 15 19 21 22 24 25 25 27 29 29 30 31 32

3.

O

MODELO

DE

PROGRAMAÇÃO

REFLEXIVO

TEMPO-REAL

33

3.1 CARACTERISTICAS

DO

MODELO

₃₃

3.1.1 UTILIZAÇÃO

DA

REFLEXÃO

COMPUTAÇIONAL

NO

MODELO

33 3.1.2 INTERAÇÕES ENTRE OS OBJETOS

DO

MODELO

34

3.1.3 CARACTERIZAÇÃO DE

MÉTODOS SEGUNDO

SEU

COMPORTAMENTO

TEMPORAL

35 3.1.4

TRATAMENTO

DE EXCEÇÕES 3 5 3.1.5 META-OBJETOS ADICIONAIS

DO

MODELO

36

3.1.6 DINÂMICA

DO

MODELO

37

3.2 DEFINIÇÃO

DA

ESTRUTURA Dos OBJETOS

DO

MODELO

38

`

3.2.1 ESTRUTURA

DO

OBJETO-BASE 38

3.2.2 ESTRUTURA

DO

META-OBJETO GERENCIADOR 39

3.3

SUMÁRIO

43

4.OMODELO

RTR

DISTRIBUIDO

ff O_O _ Í.

Mm

Ç44

4.1

INTRODUÇÃO DA

NOÇÃO

DE

TEMPO

No

MODELO

45

4.1.1

CHAMADAS

EM

OBJETOS-BASE 45 4.1.2 ANÁLISE

DA

CONSISTÊNCIA DE

ESTADO

NA COMUNICAÇÃO

47

4.1.2.1 Abordagens Utilizadas para Solucionar O Problema de Inconsistência de Estado48

4.1.2.2 Manutenção da Consistência de Estado no Modelo

RTR

Distribuído 49

4.2

ESTRUTURAÇÃO

DO

MODELO

SOBRE

O

CORBA

51

4.2.1 UTILIZAÇÃO

DO

CORBA

PARA

COMUNICAÇÃO

No

MODELO

RTR

DISTRIBUIDO 53 4.2.2 META-OBJETOS DE

COMUNICAÇÃO

53 4.3

COMPORTAMENTO

DA

COMUNICAÇÃO

NO

MODELO

RTR

DISTRIBUÍDO 55

4.3.1

COMPORTAMENTO

DE

UM

OBJETO

DO

MODELO

INTERAGINDO

COMO

_CLIENTE 55 4.3.2

COMPORTAMENTO

DE

UM

OBJETO

DO

MODELO

INTERAGINDO

COMO

SERVIDOR 56 4.3.3 DESCRIÇÃO

DO PROTOCOLO

PARA

CHAMADA

DE

MÉTODOS

TEMPO-REAL 57

4.4 ASPECTOS

RELATIVOS

AO ESCALONAMENTO

59

4.4.1 ESTUDO DE CASOS DE

ESCALONAMENTO

. 61 '

4.4.1.1 Caso 1 : Método Chamado Pertence ao

Mesmo

Objeto 62

4.4.1.2 Caso 2 2 Objeto Chamador e Objeto Chamado no

Mesmo

Nó

62

4.4.1.3 Caso 3 :-Objeto Chamador e Objeto Chamado

em

Nós Diferentes 65 4.4.2 OPERAÇÕES DE

ESCALONAMENTO

₆₆

.

MAPEAMENTO

DO

MODELO

SOBRE A

PLATAFORMA

DE

EXECUÇÃO

. és

5.1

A

PLATAFORMA

DE

EXECUÇÃO ADOTADA

68

5.1.1

ADEQUAÇÃO

DO

SOLARIS Aos PADRÕES INTERNACIONAIS 68 5.1.2 SOLARIS -

ESÇALONAMENTO

DE PROCESSOS TEMPO-REAL ₆₉

5 . 1 .3 SOLARIS - BLOQUEIO DE PÁGINAS DE

MEMÓRIA

E I/O ASSINÇRONO 71

V 5.2

MODELO

DE

EXECUÇÃO

SOBRE

O

SOLARIS 71

5.2.1

MAPEAMENTO

DOS ELEMENTOS

DO

MODELO

SOERE O SOLARIS 72 5.2.2

ESTRUTURA

INTERNA Dos OEIETOS

TEMPO-REAL

72 5.2.3

ESTRUTURA

DO

META-OEIETO

ESÇALONADOR

E

DO META-OBJETO

RELOGIO. 77

5.2.4 ATRIEUIÇÃO DE PRIORIDADES A PROCESSOS 73 5.2.5 ATRIEUIÇÃO DE PRIORIDADES A IHIIEADS

u

S0

5.3

COMPORTAMENTO

DINÃMIÇO Dos OBJETOS

DO

MODELO

81

5.3.1

CEAMADAS

SINCRONAS DE

METODOS

. 81

5.3.2

ÇEAMADAS

ASSINCRONAS E SEMI-SINÇRONAS DE

METODOS

82

5.4

SUMÁRIO

33

ç.

IMPLEMENTAÇÃO

DO

PROTÓTIPO

DO

MODELO

RTRÇ DISTRIBUIDO*

_ _{__} . . 84 6.1

O

SUPORTE

DE

PROGRAMAÇÃO

A 34

6.2 RESTRIÇÕES RELATIVAS

AO

MODELO

GLOBAL

85

6.3

IMPLEMENTAÇÃO

DE

OBJETOS

TEMPO-REAL

36

6.3.1 OBJETOS CLIENTES,

METASTUBS

E

METADII

86

6.3.2 META~OBJETOS GERENCIADORES 88 6.3.3 META-OBJETO RELÓGIO 89 6.3.4 META~OBJETO

ESCALONADOR

89 6.4

PROPOSTA DE FERRAMENTAS DE

AUXÍLIO

À

PROGRAMAÇÃO

90

6.5

EXEMPLO

DE

PROGRAMAÇÃO

UTILIZANDO

O

MODELO

91

6.5.1 ESTRUTURA

DA SOLUÇÃO

93 6.5.2 IMPLEMENTAÇÃO

DO EXEMPLO

SOBRE O

MODELO

RTR

DISTRIBUIDO 94 6.5.2.1

A

Descrição de Interface do Sewidor 95 6.5.2.2 Descrição do Servidor de Mídia 95 6.5.2.3 Descrição dos Clientes de Mídia 98

6.5.2.4 Meta-Objetos de Comunicação 99

6.5.3 ANÁLISE Dos RESULTADOS OETIDOS Nos TESTES '

100 6.5.4 CONSIDERAÇÕES RELATIVAS

À

IMPLEMENTAÇÃO 102

6.6

SUMÁRIO

7.

CONCLUSÕES

E

PERSPECTIVAS

7.1 ANÁLISE DOS

RESULTADOS

OBTIDOS _ 7.2

RELAÇÃO

COM

OUTROS

PROJETOS

EM

CURSO

7.3

PROPOSTAS

DE

CONTINUIDADE

DO

TRABALHO

E PERSPECTIVAS

FUTURAS

BIBIOGRAFIA

_

Figuras

Figura 2.1 -Interfaces de Programação de Aplicação do

DCE

*

12 Figura 2.2

-

O

Modelo

de Referência da Arquitetura

OMA

16 Figura 2.3

-

A

Arquitetura

CORBA

17

Figura 2.4

-

O

Modelo

de Objetos Tempo-Real

ANSA

22

Figura 2.5

-

Implementações do

CORBA

em

Sistemas Operacionais'

Tempo-Real

24

Figura 2.6

-

Reflexão

Computacional Segundo a

Abordagem

de Meta-Obj etos 28

Figura 3.1

-

Estrutura Geral e Dinâmicatdo

Modelo

37

Figura 4.1

-

Inconsistêncía na

Comunicação

entre Cliente e Servidor 47

Figura 4.2

-

Estrutura do

Modelo

RTR

Distribuído 52

Figura 4.3

-

Estrutura da

Comunicação

no

Modelo

RTR

Distribuído . 54

Figura 4.4

-

Protocolo para

Chamada

de

Métodos

Tempo-Real

_J

58

Figura 4.5

~

Método

Chamado

Pertence ao

Mesmo

Objeto 62

Figura 4.6

-

Objeto

Chamador

e Objeto

Chamado

no

Mesmo

Nó

_ 63

Figura 4.7

-

Objeto

Mais

Prioritário do

Mesmo Nó

Assume

Antes- do Objeto

Chamado

63

Figura 4.8

»

Método

do Objeto

Chamador

Impedido de se Executar Antes do Objeto

Chamado

64

Figura 4.9

~

Objeto

Chamador

e Objeto

Chamado

em

Nós

Diferentes 65

Figura 4.10 -

Método

do Obj etc;

Chamador

Impedido de Executar Devido a

Chamada

Síncrona

U

66

Figura 5.1

-

Prioridades de Escalonamento para as Classes de Processos '

69

Figura 5.2

~

Estrutura Interna de

um

Objeto do

Modelo

73

Figura 5.3

-

Prioridades de Escalonamento para as Classes de Processos » 79

Figura 5.4

-

Prioridades de Escalonamento para as Threads de Objetos do

Modelo

81

Figura 6.1

-

Desenvolvimento de Aplicações Distribuídas no Protótipo do

Modelo

RTR

91

Figura 6.2

-

Exemplo

de Aplicação do

Modelo

92

~

Listagens

Listagem 3.1

-

Descrição de

um

Objeto-Base 38

Listagem 3.2

-

Descrição de

um

Método

no Objeto-Base g 38

Listagem 3.3

-

Descrição de

um

Meta-Objeto 40

Listagem 4.1

-

Chamada

de

Método

no Obj eto-Base '

46

Listagem 4.2

Mecanismo

de Sincronização de Estado entre Cliente e Servidor

em

Caso de

T

imeout 51

Listagem 6.1

- Os

Parâmetros Temporais 86

Listagem 6.2 -

Método

de Invocação

com

Controle de

T

imeout do Meta-Objeto MetaDII 87

Listagem 6.3 -Interface

IDL

para o Servidor de Mídia ç 95

Listagem 6.4

-

Descrição do (V)bjeto-Base Servidor de Mídia 96

Listagem 6.5

-

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

96

Listagem 6.6

~ Método

open_media do Meta-Objeto Servidor de Midi a 97

Listagem 6.7

-

Abertura do Arquivo de Mídia no Cliente de

Imagem

MPEG

98

Listagem 6.8

-

MetaStub para o Objeto Servidor de Mídia 99

Ta

be

I

as

1

~

Introdução

A

proliferação de sistemas computacionais

em

nossa sociedade resultou

em

sua

utilização nas mais diversas atividades e

campos

de atuação.

A

interligação dos equipamentos

em

redes de computadores veio logo

em

seguida, permitindo o acesso a dados de forma mais

ampla

e imediata, otimizando o

fluxo

de informação e facilitando a comunicação entre os diversos níveis organizacionais de empresas e instituições.

Em

uma

etapa posterior, as várias redes locais se interligaram devido à necessidade de

troca de infonnações

com

o

mundo

exterior. Surgiram então dificuldades relacionadas à

conexão entre máquinas de fabricantes diferentes, protocolos de comunicação incompatíveis,

padrões de sinal diferentes a nivel de rede, entre outros.

Devido ao crescimento desordenado das redes,

com

fabricantes adotando padrões

distintos, e devido ao alto investimento que já havia sido realizado neste tipo de equipamento,

os trabalhos de padronização não obtiveram 0 sucesso desejado. Passou a ser necessária a

convivência

com

as diferenças.

A

partir deste

momento

se intensificou a pesquisa nesta área,

objetivando a obtenção de sistemas ~

nos quais máquinas diferentes possam não só se

comunicar,

mas

também

executar trabalho cooperativo.

As

redes globais já são

uma

realidade acessível a

um

grande

número

de pessoas.

Com

o popularização da Intemet, a interligação entre equipamentos e a troca de informação entre

a

---

CAPÍTULO 1 - INTRODUÇÃO

interconexão de equipamentos garante apenas a possibilidade de comunicação entre

máquinas, não a cooperação entre estas necessária

em

aplicações mais complexas, diferentes

da simples troca de mensagens eletrônicas e arquivos via rede.

Com

o surgimento de aplicações

em

rede de maior complexidade,

como

aplicações

multimídia envolvendo o processamento de dados, voz e vídeo

em

tempo-real, foram

introduzidos requisitos temporais que precisam ser considerados na construção e na execução destas aplicações.

Devemos

levar

em

consideração

também

o fato de o suporte adotado nas

redes de computadores utilizadas atualmente não possibilitar a agilidade desejada por

aplicações nas quais há restrições quanto ao tempo no qual determinados dados

devem

estar disponíveis, ou nos casos

em

que o

fluxo

de dados é muito elevado,

como

em

certas

aplicações de multimídia.

Para

um

futuro próximo pode-se antever

um

crescimento ainda maior da interligação e

integração dos diversos equipamentos de comunicação, transmissão e reprodução de voz e _de

imagem, dispositivos de segurança e de controle de equipamentos, que

em

sua maioria já

possuem algum poder de processamento. _

Como

pode ser observado, existe

uma

crescente necessidade de coordenar de

modo

flexivel os recursos computacionais, de

modo

a atender os novos requisitos relativos ao

processamento de informação

em

sistemas computacionais globalmente distribuidos. Entre os

requisitos deste tipo de sistema, alérn do fato de administrar todo o

fluxo

de informação e

executar todo o processamento relativo às atividades a eles impostas, estaria ainda a

necessidade de não tomá-los complexos demais ao ponto de limitar o acesso de pessoas

sem

formação específica para poder tirar proveito do conjunto máquina e soƒiware.

Todos estes aspectos tem sido objeto de intensa pesquisa e alvo de grandes

investimentos da indústria de informática.

No

entanto, o simples investimento no poder de

processamento e na capacidade de transmissão das máquinas não garante necessariamente

que os requisitos temporais de sistemas tempo-real sejam satisfeitos.

A

integração de questões *de _tempo-real

em

_{sistemas abertos ainda não se encontra}

devidamente estabelecida.

O

tratamento de forma eficaz destas questões requer a adoção de

arquiteturas e modelos de distribuição

bem

estruturados.

A

complexidade das aplicações destinadas a este tipo de ambiente trás à tona a necessidade de técnicas de programação

L

`t

--_

CAPÍTULO 1 - INTRODUÇÃQ

peculiaridades envolvidas ao abordar problemas relativos a distribuição, heterogeneidade do

ambiente e verificação dos requisitos temporais da aplicação.

Justifica-se então o estudo e a proposta de

um

modelo de programação destinado a

aplicações tempo-real

em

sistemas abertos, que permita que os recursos do sistema sejam

alocados considerando os requisitos temporais impostos pelo ambiente. Tais requisitos,

expressos na forma

de

restrições temporais impostas às atividades do sistema,

devem

ser

verificados

em

tempo de execução, e procedimentos altemativos de tratamento de erros

devem

ser executados. nos casos

em

que não for possível o cumprimento das restrições

temporais. Este modelo de programação deve ser estruturado de

modo

a liberar 0 usuário

final de todo o trabalho relativo à administração de recursos compartilhados, distribuição

geográfica dos equipamentos, e conversão de dados

em

um

formato padrão, entre outros.

\ ..

lí

1.1

Objetivos

do

Trabalho

.. .

.¬

Neste trabalho será proposto

um

modelo de objetos distribuídos para sistemas abertos,

que auxilie a programação de aplicações nas quais estejam envolvidas restrições temporais.

O

modelo

deve adequar-se aos padrões já propostos para sistemas _de objetos distribuídos, e utilizar paradigmas de programação que facilitem o desenvolvimento

de

aplicações¡tempo-

real distribuídas. i

A

,z

Como

ponto de partida adotaremos o modelo de objetos tempo-real proposto

em

[Fur95].

O

Modelo

Reflexivo Tempo-Real

_(RTR)

utiliza o paradigma de reflexão

computacional para permitir o gerenciamento dos requisitos temporais da aplicação.

Aspectos relativos à distribuição serão introduzidos no modelo

RTR

através _{da adoção}

do padrão

CORBA

(Common

Object Request Broker Architecture), proposto pela

OMG

[OMG96]

e amplamente aceito e utilizado no meio acadêmico e na indústria de software

em

geral.

Os

mecanismos de controle do comportamento temporal das aplicações existentes no

modelo

devem

ser modificados para sua adequação a sistemas abertos, através da inserção de

novas construções temporais que considerem as especificidades presentes neste tipo de

sistema que afetam o comportamento das interações entre os objetos distribuídos.

Este trabalho envolve ainda o

mapeamento

do modelo 'reflexivo tempo-real distribuído

--_

CAPÍTULO 1- INTRODUÇÃO

e de

um

exemplo de aplicação de multimídia distribuída

com

requisitos temporais que demonstre a funcionalidade do modelo.

O

modelo proposto deve ser adotado na elaboração de

um

protótipo de

um

ambiente

de suporte para programação de aplicações distribuídas baseado

em

Objetos e

com

características de

tempo

real e tolerância a falhas. Este trabalho se insere no contexto do

projeto

ASAP,

financiado pelo Protem-CC, do qual

fazem

parte o Laboratório de Controle e

Microlnformática

(LCMI)

da Universidade Federal de Santa Catarina _(UFSC), a Universidade

Federal Fluminense (UFF), a Universidade Estadual de

Campinas

(Unicamp) e a

Universidade Federal do Ceará (UFC).

O

modelo distribuído aqui descrito

compõe

a

_camada

de tempo-real do referido suporte de programação distribuída, que deve possuir ainda mecanismos de tolerância a

faltas, ferramentas ara _P es _P ecifica ão Ç e validação de so íware, e .

uma

lin 811a 8

em

de

programação orientada a objetos que tire proveito de todas as características do sistema.

1.2

Estrutura

da

Dissertação

l

O

texto descrevendo o

modelo

reflexivo tempo-real distribuído proposto nesta dissertação será organizado da seguinte forma :

~

_No

capitulo 2 serão analisadas as caracteristicas do ambiente, os diversos sistemas e

modelos existentes que se encontrem no

mesmo

contexto do modelo a ser proposto, os

paradigmas de programação que serão adotados, e a fomia

como

o problema será

abordado; _

-

_O

terceiro capítulo será apresentado

em

detalhes O modelo de programação adotado,

abstraindo-se de aspectos relacionados à distribuição;

-

_No

capítulo 4 serão descritos Os aspectos relativos à distribuição do modelo, as

conseqüências do ponto de vista temporal, e a estruturação do modelo sobre o suporte

de comunicação; V

~

-

_O

_mapeamento

_{do modelo sobre a platafonna de execução} será apresentado no quinto

capítulo; _

«

V

--_-

CAPÍTULO 1- INTRODUÇÃO

-

_O

_{sexto capítulo descreve a implementação de}

_um

_{protótipo do sistema, e}

_um

_exemplo

de aplicação implementado sobre esta plataforma de testes;

-

_No

_{sétimo e último} capítulo serão apresentadas as conclusões e perspectivas de

continuidade deste trabalho.

2

Análise

do

Contexto

do

Trabalho

Neste capítulo analisaremos cuidadosamente o contexto _no qual se insere o trabalho a

ser desenvolvido, enaltecendo aspectos relativos à integração de características de tempo-real

em

sistemas distribuídos abertos. Serão descritos os principais requisitos presentes neste tipo

de sistema e apresentadas soluções propostas na literatura, basicamente suportes e

arquiteturas 'destinados a programação tempo-real

em

sistemas abertos.

Em

seguida,

introduziremos _a abordagem utilizada neste trabalho para integração dos aspectos de tempo-

real e sistemas abertos

em

mn

modelo de programação, ressaltando as características que

diferenciam esta proposta das demais encontradas na literatura.

2.1

Ambientes

Abertos

e

o

Processamento

em

Tempo-Real

Este trabalho trata da programação de aplicações

com

restrições de tempo-real no

contexto de sistemas distribuídos abertos.

Em

seguida analisaremos as características de ambientes abertos, sistemas tempo-real,

e a integração de características de

ambos

em

um

mesmo

ambiente.

Ao

longo desta análise

---

CAPÍTULO 2 - ANÁLISE DO CONTEXTO DO TRABALHO

2.1.1

Características

de Sistemas

Distribuídos

Abertos

Sistemas abertos são caracterizados pela heterogeneidade de seus componentes,

presente a nível de máquinas, de sistemas operacionais e de linguagens de programação. Para

possibilitar a interação

em

ambiente aberto são utilizados mecanismos de suporte e

protocolos de comunicação que tratam as diferenças na troca de dados entre os componentes do sistema.

Devido à complexidade envolvida na programação de aplicações distribuídas,

podem

ser encontradas na literatura diversas propostas de suportes e modelos- para facilitar a

programação de aplicações

em

ambiente distribuído. Estes modelos e suportes incorporam

abstrações que facilitam a decomposição da aplicação

em

componentes de

menor

complexidade, e ferramentas que pemiitem a programação de aplicações de maneira

transparente

em

relação à distribuição.

A

transparência

em

relação ao ambientedistribuído pode ser dividida nos seguintes

pontos [Li94]:

'

'

-- _{transparência}

em

_{relação a localização} : permite que o programador abstraia-se

em

relação à localização fisica do componente responsável por prover

um

detenninado

serviço; .

i

-

_{transparência no acesso} 1 mascara as diferenças entre métodos de invocação de

serviços e na representação de dados e mensagens de controle;

-

_{transparência}

_em

_{relação a concorrência} 1 mascara o paralelismo presente na execução

de aplicações de maneira concorrente

em

diversos processadores;-

-

transparência de réplica : pennite que serviços implementados de maneira redundante

sejam utilizados

sem

que o cliente

modifique

a forma de invocação;

~- _{transparência}

_em

_{caso de falha} 1 faz

com

que a recuperação de serviços

em

caso de

falha seja realizada

sem

prejudicar a evolução do sistema;

J

-

_{transparência}

_em

_{relação aos recursos} : permite que os recursos do sistema

tenham

sua

forma de representação

modificada sem

necessitar que a maneira de acessar estes 1

recursos seja alterada;

-§-

CAPÍTULO 2 - ANÁLISE DO CONTEXTO DO TRABALHO

-

_{transparência na migração} : mascara modificações na localização de

um

serviço

dentro do sistema distribuído; .

_

-

_{transparência de federação} : permite que limites administrativos e tecnológicos

existentes no sistema sejam ignorados.

Usualmente,

em

suportes e modelos para programação distribuída, são adotadas

bibliotecas ou ferramentas para geração de código que permitem a interação entre

componentes de software de

modo

transparente para o programador. Para a comunicação são

comumente

utilizados mecanismos de

chamada

remota de procedimentos (ou métodos, no

caso de

um

modelo de objetos).

As

interações entre aplicações nestes sistemas são

estruturadas na forma cliente-servidor.

Uma

série de esforços de padronização

tem

sido realizados para pennitir a

interoperabilidade

em

sistemas distribuídos abertos.

Um

dos primeiros esforços de

padronização efetuados partiu da

ISO

(International Standards Organisation), que propôs o

modelo

de referência

OSI

(Open Systems Interconnection) [Tan94].

O

modelo de referência

OSI

é composto por camadas nas quais são tratados os diversos problemas existentes

em

sistemas abertos

em

níveis

de

abstração diferentes, partindo do nível fisico, onde são definidos os padrões de sinais de transmissão nos cabos, e terminando no nivel de aplicação,

onde a comunicação é tratada a nível de transmissão de arquivos,-mensagens, e outros serviços presentes a nível de usuário.

Devido à limitada aceitação do modelo de referência OSI-ISO, novas propostas de

padronização

vem

surgindo.

Podemos

destacar o trabalho realizado pela

OSF

(Open Software

Foundation), pelo grupo de trabalho

ODP

(Open Distributed Processing) da ISO, pelo

consórcio

ANSA

e pela

OMG

(Object

Management

Group).

No

entanto, aspectos

relacionados ao processamento tempo-real não

têm

sido contemplados na maioria destes

trabalhos.

2.1.2

Principais

Propostas

e Experiências para

Programação

em

.

Sistemas Abertos

Em

seguida serão apresentados e analisados alguns modelos e suportes para

---~_CAPiTULo

2 - ANÁLISE Do CoNrExro no TRABALHO 2.1.2.1

SPML

Ao

longo das últimas décadas foram apresentadas inúmeras propostas de linguagens

de programação destinadas a sistemas distribuídos. Estas linguagens, geralmente extensões de

linguagens de programação convencionais, c incorporam conceitos de concorrência,

comunicação e sincronismo, aliados a mecanismos de configuração.

De

fonna geral, a adoção de novas linguagens para programação distribuída dificultao

reaproveitamento de software já existente, além de

em

geral restringir a concepção de

software a ambientes homogêneos de programação.

Com

o intuito de resolver estas

limitações passou a ser adotada

uma

outra abordagem, baseada na “

programação

em

múltiplas linguagens' ou “programação mista”, que consiste

em

pennitir que componentes de soƒiware

desenvolvidos utilizando diferentes linguagens de programação convencionais e se

executando

em

um

ambiente heterogêneo sejam configurados de

modo

a

compor

uma

aplicação distribuída.

Os

problemas a serem sanados por suportes que permitam a

programação

em

múltiplas linguagens consistem basicamente

em

lidar

com

a incompatibilidade entre linguagens diferentes ou entre implementações de

uma mesma

linguagem, e

com

os problemas derivados das diferentes representações de dados

em

arquiteturas de máquinas distintas.

O

SPML

(Suporte para Programação Distribuída

em

Múltiplas Linguagens) [Bod92]

[Bod93] tem

como

propósito afastar o programador da aplicação da problemática da

heterogeneidade de linguagens e demáquinas, sendo baseado

em

um

modelo

que apresenta

abordagem diferenciada para programação

em

pequena e

em

larga escala.

O

SPML

aproveita a experiência obtida pelo grupo de pesquisa

em

sistemas

distribuídos do

LCMI

da

UFSC

com

o desenvolvimento do sistema

ADES

(Ambiente de

Desenvolvimento e Execução de Soƒíware Distribuído) [Fra89], utilizando

um

modelo

de

programação bastante semelhante.

O

modelo é composto por

um

conjunto de tarefas,

entidades elementares de concorrência, que cooperam através da troca de mensagens.

Os

portos são as interfaces uni- ou bidirecionais, através das quais tarefas se

comunicam

via

transmissão síncrona ou assíncrona de mensagens tipadas.

A

comunicação e a sincronização entre tarefas são efetivadas através de operações de

_--

CAPÍTULO 2 ¬- ANÁLISE DO CONTEXTO DO TRABALHO

bloqueante; envio sincrono (bloqueante), aguardando recepção; e envio síncrono, aguardando

resposta. H _ _

_

No

SPML

as tarefasde

uma

aplicação

podem

ser implementados

em

linguagens

diferentes.

O

suporte para programação é composto de três ferramentas principais, descritas

brevemente a seguir : _

_

-

_uma

_{linguagem de} descrição de interface de

módulo (DIM)

pennite ao programador

descrever as interfaces dos componentes de software da aplicação.

O

compilador da

linguagem (o tradutor

DIM)

é responsável por, a partir das descrições de interface dos

componentes do sistema, gerar dados para configuração daiaplicação e_ rotinas de

interfaceamento (stubs) para comunicação e conversão (linearização) de dados utilizando

uma

representação de dados padrão, o

XDR

(eXternal

Data

Representatíon).

As

stubs são geradas na linguagem de programação utilizada pelo

componente correspondente (linguagem hospedeiro).

.

~

uma

linguagem de configuração de sistemas (LINCS) permite que a aplicação seja

estruturada `a partir da composição de componentes de software heterogêneos, `

baseando-se

em uma

descrição da aplicação distribuída.

A

tradução desta descrição

pennite o carregamento, a instanciação e a interconexão de componentes.

- _{o suporte de tempo de execução (o Gerenciador de Estação) implementa as abstrações}

de software definidas no modelo de programação distribuída.

A

unifonnidade das

interfaces dos serviços de comunicação e de sincronismo fomecidos pelo suporte garante a total transparência na codificação da aplicação.

O

gerenciador implementa

uma

política de escalonamento “preemptivo” dirigido por eventos (event-dríven),

sobreposta ao escalonamento do sistema operacional, baseada

em

prioridades

dinâmicas estabelecidas pelo programador da aplicação.

Com

estas ferramentas, o

SPML

contorna problemas relacionados à incompatibilidade

entre linguagens e máquinas diferentes presente

em

um

ambiente distribuído e heterogêneo.

O

SPML

foi implementado

em

uma

rede Ethernet composta por estações Sun, e foi

desenvolvido suporte para geração de rotinas de interfaceamento nas linguagens C, Fortan e

Pascal.

A

adição de novas linguagens ao suporte é facilitada

com

a utilização de

uma

----

CAPÍTULO 2 - ANÁLISE DO CONTEXTO DO TRABALHO 2.1.2.2

DCE

e

OO-DCE

O DCE

(Distributed Computing Environment) [Ros92] [OSF92] trata-se de

um

suporte para sistemas distribuídos bastante robusto, resultado de

um

trabalho de padronização

coordenado pela

OSF

(Open Soƒiware Foundation),

um

consórcio de empresas formado

com

o objetivo de propor padrões para sistemas abertos.. '

O DCE

tem

como

objetivo facilitar o convívio

em

redes de computadores de

diferentes tecnologias, tanto de hardware quanto de soƒiware, alem de fornecer serviços que

facilitam o trabalho cooperativo, distribuem eficientemente a carga do sistema, e facilitam o

acesso a dados de forma distribuída,

sem

que ocorra perda de segurança no que se refere aos

dados e recursos do sistema, e

sem

que se perca a visão global e ordenada dos eventos que

ocorrem no sistema.

Os

componentes do

DCE

trabalham conjuntamente para tornar possivel

um

sistema

aberto

com

tais características, procurando minimizar o impacto na rede, tanto no que se refere à carga do sistema

em

termos de poder de processamento e comunicação, quanto na

visão do usuário

comum,

que não deve ter sua interação

com

o sistema dificultada.

As

aplicações construídas sobre o

DCE

precisam interagir somente

com

os

mecanismos de sofiware de alto nível disponíveis,

sem

se preocupar

com

a forma na qual a

comunicação realmente ocorre a nível ñsico ou de rede, ou quanto à necessidade de

reordenação de dados na comunicação entre máquinas incompatíveis ouconversão entre tipos

de dados de linguagens de programação

com

formatos diferentes.

O

DCE

adota para estruturação do ambiente distribuído o modelo cliente-servidor,

com

utilização do

mecanismo

de

RPC

(Remote Procedure Call) para comunicação.

Um

componente de aplicação distribuída, necessitando ativar

um

procedimento remotamente ein

um

servidor,

chama

uma

rotina stub local que, utilizando os protocolos de comunicação e de

conversão de dados, ativará o respectivo procedimento no servidor, passando a este os

parâmetros da

chamada

e retomando os resultados ao cliente, que reassume então seu fluxo

de execução.

A

.sintaxe de

uma

chamada RPC,

com

seus parâmetros de entrada e saída, torna-se

conhecida de

um

cliente através de

uma

descrição de interface realizada utilizando a

--i

CAPÍTULO 2 - ANÁLISE no Cormzxro Do TRABALHO

semelhante aos da linguagem C.

A

compilação de

um

arquivo de descrição de interface gera

rotinas de stub de cliente e servidor, que

devem

ser incorporadas ao espaço de endereçamento

dos respectivos componentes de aplicação para que seja possível a interação

com

'outros

componentes distribuídos no sistema utilizando os mecanismos disponíveis no

DCE.

O

componente de software que utiliza o

RPC

no

DCE

para comunicação, através do

código de stubs geradas automaticamente pelo compilador IDL, se baseia no serviço de

diretório para procura de

um

servidor compatível

com

a

chamada

que está sendo executada.

A

chamada

RPC

se utiliza de protocolos queiadministram aspectos. específicos de transporte e

de rede, gerenciam conexões e,

em

alguns casos,

podem

fornecer algum suporte para

tratamento de falhas de servidores ou de serviços de rede.

_

O

DCE

comporta-se

como

uma

camada

de software que mascara as diferenças entre

arquitetura de máquinas, entre sistemas operacionais e redes de computadores distintos.

O

DCE

pode ser visto

como uma

camada

situada sobre 0 sistema operacional e oprotocolo de

transporte, que fomece seus serviços às aplicações situadas

um

nível acima na hierarquia de

camadas. `

A

Figura 2.1 mostra a forma

como

são estruturadas as interfaces de programação de

aplicação do

DCE

sobre o sistema operacional e a

camada

de transporte da rede de

comunicação.

Os

serviços de Threads e

RPC

são a base do

DCE,

e são indispensáveis

em

todos os sistemas onde o

DCE

esteja instalado.

Os

serviços de segurança, de diretório

(CDS

- _Cell

Directory Service, o padrão X.500, e o

XDS

-

X500

_{Directory Service) e 0 serviço de}

tempo

distribuído

(DTS

- _Distributed Time _{Service) são implementados utilizando as}

camadas

_de

Threads e

RPC

do

DCE.

~._.›. _ _- _. ~ ,_\-_‹.-1-nr-v,z_.-... , . .~-/ - -~»z'q7,~,¿¿,~= ' »

Vi-,S ÇEYIÇO d¢..f;‹: :sf -S, ¢fY1Ç0.úd¢.z»z=

fiflçfisâ

;.~¿;¿,- .¿,;¡.›.,- -._._'.~.,f-_t‹›-;_ -=_;¬,-:fz '

, . - _ - '.z.~::z::›';z.-«'-if fi, :1=,.=‹',1==,\;1.'zz'~l‹fi~.‹ .í '~‹. -*›.

!`Í~"`¡` .:, i

_,

;.-;2_›'.;.‹'._~.-5"- -..~',,-,;¢'¬Í3'~': I.-.wtf-'^._f‹' ,, ›,'-'r7'âí'._-í.-Ç~II '_' "'TI-FS-_\«`:'z:-Jf=:'.í'›¡°.-. ' . -F ¬ ›\-›: z..‹ -.<-›..-¢z ‹;¬.-ri :.¬‹ zz- -=t › ~ <sub>-›</sub> _ V .- .. ~ ._z,.~-.<z›,-§-- « .f._ ,-‹.\_.. z -¿~_ '~-=' ›› ~› - f-= - =.~= '›..¬z -;V--.- :-:V ;,z,,‹.; _ . ‹.._‹--z. fl * W ~‹' " <sub>X</sub> V .ø ~. ›› /: "›:z=zzâ ;.›.s-1;é=.;s›`; z wiv*.»‹.z2':<ëàfi'êQfirzrffirznf «J "~=.r.-,:-,‹=z‹'~@¿-wi' -V - ,pera›

---

CAPÍTULO 2 - ANÁLISE Do CoNTExTo Do TRABALHO

O

sistema de arquivos distribuído do

DCE,

o

DFS

(Distributed File Service), roda a

nível de aplicação, utilizando todos os serviços disponíveis no

DCE,

além de interagir

diretamente

com

o sistema operacional.

O

fato de 0

DFS

rodar a nível de aplicação e não

dentro do núcleo do sistema operacional,

como

no

Sun

NFS©,

evita sobrecarregar o núcleo

tomando-o ineficiente e inadequado a aplicações

tempo

real, além de evitar que os fabricantes de sistemas operacionais tenham que modificá-los para acomodar o DFS. Esta

abordagem é mais condizente

com

as caracteristicas de

um

sistema aberto, e a implementação

do

DFS

pennite

um

convívio pacifico

com

a versão do sistema de arquivos nativo do sistema

hospedeiro.

V

O

OO-DCE

(Object Oriented

DCE)

[Dil93] e'

uma

extensão do

DCE

para o

desenvolvimento de aplicações distribuídas orientadas a objetos.

O

OO-DCE

é composto por

uma

biblioteca defclasses de objetos que auxilia o programador no desenvolvimento de

aplicações sobre o

DCE,

aliado ao

mapeamento

das definições de interfaces de componentes

DCE,

descritas

em

IDL, para classes de objetos clientes e servidores codificados na

linguagem C++. '

i

Outras formas de estender o

DCE

de forma a torná-lo maisnadequado à programação

orientada a objetos são propostas na literatura.

Uma

delas é o

DC++

[Sch93], de

modo

geral

bastante semelhante ao

OO-DCE,

mas

que diferencia-se fundamentalmente por suportar a

migração dinâmica de objetos. L

Apesar da distribuição e do tratamento de heterogeneidades de linguagem e máquinas

de forma transparente, o

DCE

não possui suporte algum destinado a aplicações tempo-real.

A

integração da orientação de objetos ao

DCE

não é totalmente satisfatória, pois a linguagem de

descrição de interface do

DCE

não possui 'mecanismos de herança, e os mecanismos de

invocação de objetos presentes no

OO-DCE

e no

DC++

não são suficientemente completos

para abranger os diferentes modelos de objetos existentes.

2.1.2.3

ODP

e

ANSA

F

O

corpo de definição de padrões da

ISO

iniciou

um

programa

com

o objetivo de

estabelecer

um

modelo de referência para processamento distribuido

em

sistemas abertos.

O

___-

CAPÍTULO 2 - ANÁLISE no CoN'ri:xro no TRABALHO

objetivo permitir a interoperabilidade entre aplicações e o compartilhamento de informações

entre instituições. ~

O

modelo

ODP

é composto por

um

conjunto composto por cinco níveis (apresentados

como

°linguagens”) que descrevem a estrutura de sistemas distribuídos sob diferentes pontos de vista : empreendimento, informação, computacional, engenharia e tecnologia.

Com

esta

estrutura

em

níveis o

ODP

objetiva fazer a conexão entre os requisitos do sistema e as

soluções técnicas na forma de produtos industriais.

O

modelo

ANSA

(Advanced Network Systems Architecture) [Lin93] [LÍ93] é

uma

implementação do

modelo

de referência

ODP.

O

modelo

ANSA

é dividido

em

um

modelo

computacional,

um

modelo

de engenharia, e

um

modelo

de execução de objetos.

O

modelo

de engenharia

ANSA

provê

um

ambiente para especificação de mecanismos de suporte à

distribuição de aplicações de acordo

com

o modelo computacional, sendo composto por :

-

_{mecanismos que permitem a transparência do ponto de vista do programador}

(transparência de localização, acesso, concorrência, replicação, falha, recursos,

migração e federação); V

-

_um

_{núcleo que encapsula} as diferenças entre arquiteturas de processador e dispositivos

de memória;

O

modelo de engenharia

ANSA

pode ser visto

como

um

conjunto formado pelos

componentes descritos a seguir :

-

cápsulas, compostas por objetos de aplicação, mecanismos de transparência e

um

núcleo, que

formam

um

nodo virtual na rede;

-

threads, que

modelam

uma

atividade potencialmente concorrente dentro de

uma

cápsula;

-

_{tarefas, que consistem}

_em

_{processadores virtuais que}

_fomecem

_{recursos necessários}

para execução de threads;

-

referências para interfaces, que

em

posse de

um

cliente

(um

objeto) permitem a

comunicação

com

um

servidor

(um

outro objeto) através da interface denotada pela

referência; e

-i--

CAPÍTULO 2 - ANÁLISE DO CONTEXTO DO TRABALHO

-

_um

°interpretador”, que consiste basicamente

em uma

parte do núcleo que interpreta

invocações entre objetos

como

se estas fossem instruções de

uma

máquina virtual

distribuída. ~

De

acordo

com

o modelo de objetos

ANSA,

cada objeto deve possuir

uma

ou mais

interfaces, que são os pontos de ativação dos serviços implementados pelo objeto.

As

requisições são enviadas a

uma

interface através de chamadas remotas de procedimento, e são

executadas por

uma

tarefa ou

um

grupo de tarefas associados a esta interface.

As

tarefas são

escalonadas pelo núcleo do sistema operacional de acordo

com

prioridades definidas durante

a sua criação.

ANSAware

[Li94] consiste

em

umaimplementação

do modelo computacional e

um

exemplo do modelo de engenharia

AN

SA, organizada na fonna de

um

suporte composto por

uma

plataforma de execução, aplicações de gerenciamento de sistema e ferramentas

de

auxílio à programação que pennitem a construção de sistemas

com

base no

modelo

de,

referência

ODP.

Este suporte pennite que componentes heterogêneos de aplicações

distribuídas interoperem.

2.1.2.4

ORB

e

CORBA

V

ORB

(Object Request Broker) e

CORBA

(Common

Object Request Broker

Architecture) são propostas da

OMG

(Object

Management

Group),

um

consórcio de

mais

de

400 empresas, que busca promover a utilização do modelo de programação orientada a

objetos no desenvolvimento de software distribuido.

A

OMG

tem

como

objetivo proporcionar

um

ambiente no qual seja possível o

desenvolvimento de aplicações distribuídas

em

ambientes heterogêneos, utilizando objetos

como

componentes, e de maneira transparente

em

relação à heterogeneidade e à distribuição

do ambiente, buscando simultaneamente incrementar a reutilização, a portabilidade e a

interoperabilidade.

Com

este propósito, a

OMG

especificou a arquitetura

OMA

(Object

Management

Architecture),

um

ambiente que tem

como

principal característica suportar aplicações

cooperantes compostas por objetos distribuídos

_[OMG92].

A

Figura 2.2 mostra os

componentes do modelo de referência da arquitetura

OMA.

.

---

CAPÍTULO 2 - ANÁLisi: DO CONTEXTO DO TRABALHO

Objetos de Aplicação Facilidades

.~: -i -.<- .. _ _.,-.~_^,-vzr, :,›.\_.-;:.›,:1z'*íw-'(51.zç.:›zz:;:.-,:

-'1.›';›' t*'»1~í:; 2,z¬'rÉf,',‹';.ê,.f,:` ¬ F3*-, i-',-; ~'«z':-zé =;'~:'=¿,=z,z_.i-',;zzi‹ -;-.`.~":-‹.-`\'¬

~i\.z=.~*z`‹l:-¿fi›="«*\°š-'f~«^«,'-;fzâ z1›:~ffzf;¿f,z-z..:=št›`,;1-li /\,áfl.eíi'‹.‹z=-3»‹2éz1vàf§~;::fi::-é

‹ "f'-1'.f:~;zzii1-zz'z= ' '~1-íàí;/:>f¬ '

ORB

[Object Request Broker]

.i ›"‹š'‹;'.z_ :!*'!`=z'f-`Í.""~Í\ ,'›':'v`;'vI.-`;“›\\"Í.-'*.-'›`i». .,z,\'»-.`=,~'~'-.:f,

*M5$2›;š¡ëiig§«}=r§¬¢=?¿,eé ,¿~›››¿i›';;'‹:z_f«“,' zz`:f,rfâ:vã'z;=›1:«z;=\¡

*.-,\,~`z,:;¿z>ä‹~zI,t»<›z,,,e@â§=zâ;z.mu-\

Figura 2.2

-

O

Modelo

de Referência da Arquitetura

OMA

Os

objetos de aplicação são criados pelo usuário, particularizados conforme seus

objetivos.

As

facilidades são serviços de propósito geral, utilizadas pelas mais diversas

aplicações.

E

os serviços de objetos são compostos por servidores (interfaces e os objetos

propriamente ditos) que permitem a implementação e utilização de objetos

em

um

ambiente

aberto.

O

ORB

(Object Request Broker) é O componente mais importante da arquitetura

proposta pela

OMG.

Ele permite que objetos façam e recebam requisições de métodos

transparentemente

em

um

ambiente distribuído e heterogêneo.

4

Uma

requisição de método originada por

um

cliente é enviada a

uma

implementação

de objeto (servidor) através do

ORB.

O ORB

é O elemento intermediário responsável por

encontrar O objeto ao qual se destina a requisição, e enviar os parâmetros da requisição no

formato reconhecido por este.

O

ORB

também

faz o processo inverso, retomando os

parâmetros de saída da requisição, se houver algum, para o cliente.

A

interface

com

a qual o cliente tem contato é completamente independente de onde o

objeto está localizado, de qual linguagem de programação foi utilizada na sua

í--

CAPÍTULO 2 - ANÁLISE no CoNTExro no TRABALHO

se executa, e de quaisquer outros aspectos relacionados à heterogeneidade do ambiente

distribuído no qual se encontram os objetos de

uma

detenninada aplicação.

Qualquer suporte que faça a intermediação de requisições de métodos de objetos

em

um

ambiente distribuído é

um

ORB.

QRBs

diferentes

podem

adotar estilos de implementação

diferentes, resultando

em

serviços destinados a clientes e objetos

com

diferentes propriedades

e qualidades.

O

CQRBA

_[OMG96]

é

uma

arquitetura específica de

ORB,

cujas interfaces e

componentes foram padronizados pela

OMG.

Na

Figura 2.3 é apresentada a arquitetura

CORBA

e suas interfaces, através das quais ocorre a interação entre o

ORB

e os clientes _{e implementações de} objetos.

› iii "'”** fi 'GJ Cliente * Implementação do Objeto t _il _. et .é iÍ`“'@‹“››.f nterface d I Es ueletos Es ueletos

In V oca ão Slubs ' IDLÍ Interface qIDL Digâmicos Adaptador

. . . C10

ÔRB

1f..r:.=z=z=:z=:z¬:.fssf;mtrz¬.;¬õ:.=:;-z'z:z¬.1.=_'fz- de Objetø I ` Núcleo

ORB

l . I

(ORB

Core)

_ Interface idêntica para todas as implementações de

ORB

Stubs e esqueletos específicos para cada tipo objeto

Podem

haver vários adaptadores de objeto

Interface dependente do

ORB

'

Figura 2.3

-

A

Arquitetura

CORBA

No

CORBA,

interfaces de objetos são descritas

em uma

linguagem

IDL

(Interface

Definition Language),

uma

linguagem puramente declarativa

com

sintaxe semelhante ao C++. Através da

IDL

são declarados os dados e métodos que

podem

ser acessados

externamente contidos no objeto correspondente à interface que esta sendo descrita. '

Para fazer

uma

requisição 'de

um

_{serviço a}

um

_{objeto, o cliente pode utilizar stubs}

geradas na compilação da descrição de interface da implementação do objeto, ou,

í--_-

CAPÍTULO 2 - ANÁLISE DO CONTEXTO DO TRABALHO

(Dynamic

Invocation Interface). Para que isto seja possível, a interface do objeto deve ser

adicionada a uin depósito de interfaces (Interface Repository), permitindo o acesso

em

tempo

de execução à infonnação relativa aos serviços implementados pelo objeto e à forma de

acesso destes (métodos e parâmetros de chamada) . _

Um

cliente, para fazer

uma

requisição, deve conhecer

uma

referência para o objeto

destinatário da requisição, e especificar a operação que deseja executar juntamente

com

os

parâmetros da chamada. 'A partir de então, o cliente pode

chamar

_a rotina stub

correspondente, ou construir a requisição dinamicamente através da DII.

O

receptor da

mensagem

não conhece qual dos métodos foi utilizado na requisição, pois todos os aspectos

que os diferenciam são tratados internamente pelo

ORB.

-Realizada a requisição, o

ORB

localiza o código da implementação, transmite os

parâmetros de

chamada

e transfere o controle para a implementação de objeto através de

um

esqueleto IDL, específico à interface e ao adaptador de objeto utilizado.

Ao

executar o serviço solicitado, a implementação do objeto pode acessar serviços

providos pelo

ORB

através de

um

adaptador de objeto.

Podem

haver vários adaptadores de

objeto, e a implementação do objeto escolhe qual irá utilizar baseando-se no serviço que

deseja obter do

ORB.

O

padrão

CORBA

utiliza

um

adaptador básico de objetos

(BOA

-

Basic

Object Adapter), que procura abranger serviços úteis para

um

grande conjunto de objetos

com

implementações convencionais.

ç

A

,interface do

ORB

é idêntica' para todas as '

implementações

CORBA,

'independentemente do adaptador de objetos utilizado. Através dela

podem

ser invocadas

o

operações executadas pelo

ORB

úteis tanto para os clientes quanto para as implementações

de objeto.

A

interface de esqueletos dinâmicos (DSI

-Dynamic

Skeleton Interface), acrescentada

na versão 2.0 do

CORBA,

é utilizada para_interconexão de

ORBS. Quando

o

BOA

recebe

uma

invocação de

um

objeto para 0 qual não possui esqueletos, esta invocação passa, através da

interface DSI, para a interface DII de

um

outro

ORB

que possua esqueletos para o objeto, que fará a invocação.

O

núcleo

ORB

basicamente provê mecanismos de comunicação para que seja possivel

processar e executar as requisições de métodos remotos.

As

interfaces do

CORBA

foram

---

CAPÍTULO 2 - ANÁLISE Do CoNTr:xTo no TRABALHO

estruturadas sobrepondo-se ao núcleo

ORB,

permitindo que as diferenças entre as diferentes

implementações de núcleo sejam mascaradas completamente. `

A

interoperabilidade entre objetos toma-se possível através da adoção do protocolo

IIOP (Internet Inter-ORB Protocol), que trata-se de

um

protocolo padronizado pela

OMG

que

permite comunicação entre diferentes implementações de

ORBs

compatíveis

com

a

especificação

CORBA.

O

IIOP especializa o protocolo TCP/IP (Transport Control Protocol/

Intenet Protocol), padrão de facto para comunicação

em

redes, de

modo

a otimizá-lo para

transmissão dos tipos de dados utilizados pelo

CORBA.

V

2.1.3.

Sistemas

Tempo-Real

Sistemas

com

características de tempo-real [Ram94] [Shi94] possuem atividades que

devem

ser executadas corretamente dentro de intervalos de tempo especificados, não

bastando apenas a correção lógica! do resultado de

uma

atividade do sistema para considerá-lo

válido,

mas

sendo necessária

também

a sua correção temporal. Neste tipo de sistema,

um

resultado correto entregue fora do prazo especificado para ser apresentado tem o

mesmo

efeito de

um

resultado incorreto. '

'

Para possibilitar a verificação de sua correção temporal, as atividades do sistema são

associadas a restrições temporais, especificadas na .fonna de parâmetros que

regem

o

comportamento temporal da atividade,

como

o período de ativação, o tempo

máximo

de

execução, o intervalo

mínimo

entre ativações, e o prazo

máximo

de conclusão da tarefa

(deadline).

Em

determinados casos, a violação de

uma

restrição temporal pode levar a

um

prejuízo maior do que todo o beneficio conseguido

com

aquela atividade. Sistemas

com

atividades deste tipo, chamadas falhas catastróficas, são denominados sistemas tempo-real

críticos (hard real-time systems).

Os

sistemas tempo-real não-críticos (soft real-time systems),

ou do tipo melhor esforço, são aqueles que não possuem

nenhuma

atividade que possa causar

uma

falha catastrófica [Fer94]. .

A

previsibilidade do comportamento

do

sistema consiste _no fator de maior

importância na análise de sistemas tempo-real. Através do conhecimento prévio da carga

-í-

CAPÍTULO 2 - ANÁLISE DO CONTEXTO DO TRABALHO

veriñcação do cumprimento dasrestrições temporais impostas pelo ambiente, realizando

testes de escalonabilidade que considerem situações de sobrecarga. Garantido o

funcionamento do sistema sob a maior carga esperada, temos a garantia de que as restrições

temporais serão cumpridas

em

qualquer outra situação.

No

entanto,

em

alguns sistemas não existe a possibilidade de prevermos estaticamente

a carga à qual este será submetido e

nem mesmo

delimitarmos os tempos de execução de

algumas atividades,

como

o tempo de acesso ao meio de comunicação, o

tempo

de

transmissão de

uma

mensagem,

ou o

máximo

tempo de espera pela liberação de

um

recurso

compartilhado.

_N§§es

sistemas, ditos não-detenninistas, torna-se necessário adotar

uma

4 I I

politica probabilista, garantindo

uma

taxa de erro aceitavel dentro da qual

devem

ser

cumpridas as restrições temporais impostas pelo ambiente [Oli95]. 'Í

Em

função da previsibilidade temporal do comportamento do sistema pode ser

-Ç”

L

definido o mecanismo de escalonamento a ser adotado.

_Os

processadores `p"‹¿iÍ`ciern ser alocados

estaticamente a tarefas nos casos

em

que a carga for conhecida previamente. Neste caso,

testes de escalonabilidade

podem

ser executados para verificar o cumprimento das restrições

temporais

em

tempo de projeto.

Em

sistemas probabilistas, onde a carga e os tempos

envolvidos na execução _das atividades do sistema não são conhecidos a_¿r¿r_íori, o

escalonamento de tarefas deve ser realizado

em

tempo

de execução. ` ” '

_'

Um

suporte para tempo-real deve refletir o tipo de" _{sistema para o} 'qual _{se destina.}

Em

um

suporte para sistemas hard deve haver

uma

total previsibilidade do comportamento do

sistema, permitindo que todas as restrições de

tempo

sejam examinadas previamente através

de testes de escalonamento de atividades. Já

em

suportes para sistemas soft, são toleradas

algumas falhas

em

caso de sobrecarga, devendo inclusive ser adotada

uma

política de melhor

esforço (best-efibrt) para estabelecer o

fluxo

de execução das atividades do sistema.

Em

sistemas distribuídos, usualmente são adotados mecanismos de solução do

escalonamento

em

etapas, segundo os quais primeiramente é escolhido o processador no qual

uma

determinada 'tarefa _{deve ser executada.}

Em

_{seguida, ocorre 0 escalonamento a nível}

---

CAPÍTULO 2 - ANÁLISE Do CoN'rEx*ro _Do TRABALHO,

_

2.1.4

Tempo-Real

em

Sistemas

Abertos»

O

tratamento de questões presentes

em

sistemas tempo-real no contexto de sistemas abertos é dificultada devidoià existência de fatores conflitantes,

mas

não inconciliáveis.

De

forma a integrar 'características de tempo-real

em

sistemas distribuidos 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; i

-

_{a carga de cada máquina' nestes sistemas e 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. `

Como

não existe total previsibilidade acerca do comportamento do sistema, toma-se

impossível garantir que as restrições temporais sejam satisfeitas. Isto conduz à adoção de

políticas de melhor esforço (best-effort) para o escalonamento das atividades do sistema,

com

o intuito de evitar que atividades sejam executadas fora de suas especificações temporais.

Caso alguma restrição temporal imposta pelo ambiente não seja ctunprida, deve haver

uma

notificação ao solicitante da atividade associada à restrição violada, e

um

procedimento de

tratamento de exceção previsto para tal, deve ser executado prontamente de

modo

a permitira

recuperação do erro ocorrido. '

Adicionalmente, é desejável que o programador disponha de mecanismos que

viabilizem a

mudança

de comportamento do sistema de

modo

flexível, possibilitando por

exemplo

a introdução de diferentes mecanismos de controle ou a modificação da política de

--í

CAPÍTULO 2 - ANÁLISE DO CONTEXTO DO TRABALHO

uma

aplicação específica ou ainda para melhorar o

desempenho

obtido na execução de

uma

aplicação.

Alguns modelos, suportes e arquiteturas apresentados na literatura tem

como

objetivo

principal integrar aspectos de tempo-real

em

sistemas abertos.

Em

seguida serão analisadas

algumas destas propostas. V

2.1.4.1

Modelo de

Objetos

Tempo-Real

ANSA

O

modelo

ANSA

sofreu adaptações de

modo

a considerar aspectos presentes

em

sistemas tempo-real. Este processo resultou na especificação do modelo de objetos tempo-

real

AN

SA

[Li93] [Li94b], que permite a alocação explícita de recursos, o escalonamento e a

comunicação através da adoção de

um

modelo de tarefas e de

um

modelo de comunicação

ligeiramente modificados

em

relação ao modelo de objetos

ANSA

original para tratar as

questões referentes a processamento

em

tempo-real.

"

' '

_ '

As

tarefas neste modelo incorporam a noção defilas de entrada (entry) associadas às

respectivas interfaces.

As

requisições dirigidas à interface associada são dispostas na ñla de

entrada segundo

uma

politica de escalonamento determinada na instanciação da fila. Esta

política pode ser definida pelo sistema ou provida pela aplicação.

fila de

n

“fr

gfUP°_§1Ç_FatÇ_f.as_\

~

Figura 2.4 -.

O

Modelo

de Objetos

Tempo-Real

ANSA

As

requisições contidas

em uma

fila de entrada são atendidas por tarefas ou grupos de

tarefas, que por sua ¡vez são escalonadas pelo núcleo do sistema operacional..

O