Monografia do Curso de

Introdução à Computação Móvel

CORBA para Computação Móvel

Aluno: Antônio Tadeu Azevedo Gomes

Prof. Markus Endler

Departamento de Informática

PUC-Rio

22 de novembro de 2001

1

1 Introdução

O objetivo desde trabalho é dar uma visão geral dos problemas encontrados ao se utilizar

plataformas para sistemas distribuídos em ambientes de computação móvel, e apresentar

algumas soluções propostas na literatura. Sucintamente, a função essencial das plataformas

para sistemas distribuídos – também chamadas algumas vezes de plataformas de

middleware ou simplesmente middlewares – é prover aos desenvolvedores de aplicações

distribuídas um conjunto de abstrações que mascarem a complexidade e heterogeneidade

normalmente encontradas em infra-estruturas distribuídas, infra-estruturas estas que

compreendem não só os sistemas responsáveis pela comunicação (redes e pilhas de

protocolos) mas também os sistemas de computação (máquinas e sistemas operacionais).

Os ambientes de execução de aplicações providos por esses middlewares são muitas vezes

denominados também de ambientes de processamento distribuído – DPEs (Distributed

Processing Environments).

Pode-se citar como exemplos de middlewares, no contexto deste trabalho, a arquitetura

CORBA (Common Object Request Broker Architecture) [OMG98], o modelo DCOM

(Distributed Component Object Model) [Microsoft98] e o sistema Java RMI (Remote

Method Invocation) [Sun98]. Desses três exemplos, a arquitetura CORBA é a de escopo

mais abrangente, e por isso será usada como referência para o restante deste trabalho.

1.1 A Arquitetura CORBA

Primeiramente, deve-se notar que a arquitetura CORBA é na verdade um elemento de uma

arquitetura maior definida pelo OMG (Object Management Group), a arquitetura OMA

(Object Management Architecture). Como mostra o modelo de referência ilustrado na

Figura 1, a arquitetura OMA especifica um conjunto de entidades arquiteturais que fazem

uso de uma espécie de “barramento” comum por meio do qual tais entidades podem se

comunicar. Esse meio de comunicação, chamado de ORB (Object Request Broker), é o

elemento principal da arquitetura CORBA, e constitui-se no foco principal deste trabalho.

Além do ORB, há também uma entidade arquitetural OMA que é importante para este

trabalho: o conjunto de serviços de objetos (CORBAservices), que englobam componentes

responsáveis pelos serviços de nomes, localização, segurança e transações, entre outros. As

2

outras entidades arquiteturais OMA são responsáveis por serviços de mais alto nível, como

billing, por exemplo, e não serão abordadas no presente trabalho.

ORBORB

Applicationinterfaces

Applicationinterfaces

DomaininterfacesDomain

interfaces

CORBAServicesCORBAServices

Commonfacilities

Commonfacilities

Figura 1 – Modelo de Referência para a arquitetura OMA.

A estrutura geral da arquitetura CORBA é ilustrada na Figura 2. Fundamentalmente, a

arquitetura CORBA define um framework para o desenvolvimento de aplicações

distribuídas orientadas a objetos. Mais especificamente, ela provê, juntamente com os

CORBAServices, os serviços de middleware que permitem a aplicações clientes

executarem invocações de métodos em objetos servidores remotos.

ObjectAdaptor

ORB Core

stubskeleton

Client application

Serverobject

ORBInterface

Figura 2 – Arquitetura CORBA

Alguns outros elementos da arquitetura CORBA não ilustrados na figura anterior são

apresentados nas subseções a seguir. Ao final desta Seção é dado um exemplo de como

ocorre, em linhas gerais, uma seqüência típica de invocação de método em um objeto

servidor na arquitetura CORBA

3

1.1.1 A Linguagem de Definição de Interfaces

A linguagem de definição de interfaces – IDL (Interface Definition Language) – é uma

linguagem na qual interfaces de objetos servidores podem ser especificadas de modo

independente da forma como esses objetos são implementados. A IDL oferece facilidades

de tipagem de dados, mas não tem nenhuma sintaxe para computação, ou seja, nenhum

código pode ser especificado nela.

// IDL

interface WWWServer {

string get( in string URL );

}

Figura 3 – Exemplo de definição de interface de objeto em IDL.

1.1.2 Protocolos Inter-ORB

O termo protocolo inter-ORB – IOP (Inter-ORB Protocol) – designa, como o nome sugere,

protocolos que permitem a interação entre ORBs. O propósito principal de um IOP é

transportar invocações de métodos e suas respectivas respostas entre aplicações clientes e

objetos servidores. Inicialmente, a arquitetura CORBA não padronizava a

interoperabilidade entre ORBs implementados por diferentes fabricantes. Versões mais

recentes da arquitetura CORBA trataram esse problema por meio da definição de um

protocolo Inter-ORB genérico – GIOP (Generic IOP) – que permite a interação entre ORBs

implementados por diferentes fabricantes.

O GIOP foi projetado de forma a ser o mais simples e facilmente implementável possível,

ou seja, quaisquer requisitos específicos a um determinado domínio de aplicação (por

exemplo, operações em tempo real) devem ser providos por IOPs proprietários. Uma das

conseqüências dessa decisão de projeto é que o GIOP assume que suas mensagens são

transmitidas por meio de um serviço de comunicação confiável. Com isso, uma conexão

GIOP possui informações de estado mínimas. A implementação mais comum do GIOP é

sobre a pilha de protocolos TCP/IP [Comer95], e nesse contexto esse protocolo é chamado

de IIOP (Internet Inter-ORB Protocol). Basicamente, uma conexão IIOP é mapeada em

uma única conexão TCP.

4

1.1.3 Exemplo de Operação

Uma seqüência de invocação de um método em um objeto servidor começa quando a

aplicação cliente obtém uma referência do objeto servidor – OR (Object Reference). Essa

referência pode ser obtida, por exemplo, por meio de um serviço de nomes ou de um valor

de retorno de uma invocação remota anterior. A aplicação cliente se associa ao OR e, como

resultado, recebe uma referência real (dependente da linguagem de programação em uso na

aplicação cliente) a um objeto stub, que atua como representante do objeto servidor no

ORB local da aplicação cliente. É por meio desse stub que a aplicação pode invocar

métodos no objeto servidor. Um stub é criado a partir da compilação da IDL que define a

interface do objeto servidor de acordo com a linguagem de programação em uso na

aplicação cliente. A função de um stub é basicamente encapsular (marshalling) valores de

argumentos e desencapsular (unmarshalling) valores de retorno de um método invocado, de

modo que esses valores possam ser enviados por meio de um IOP. Algo similar acontece

com o objeto servidor, e a interface entre o ORB e o objeto servidor é de responsabilidade

de um objeto skeleton. Um adaptador de objetos – OA (Object Adapter) – oferece aos

objetos servidores um ambiente de execução uniforme, independente do ambiente de

execução local onde se encontra o objeto1. Em geral, toda a comunicação entre um stub e

um skeleton é feita no contexto de uma conexão IOP, ou seja, várias invocações de

métodos de uma aplicação cliente em um objeto servidor são normalmente feitas por meio

de uma única conexão IOP, que permanece ativa pelo menos até que a OR seja liberada

pela aplicação cliente. Diz-se então que uma aplicação pode invocar métodos em um objeto

servidor remoto se eles estiverem conectados entre si.

1 A funcionalidade no ORB do objeto servidor é mais complexa e inclui outros elementos não ilustrados na

Figura 2, porém preferiu-se não entrar em maiores detalhes acerca da arquitetura CORBA por julgar-se que

isso está fora do escopo do presente trabalho.

5

2 Processamento Distribuído e Mobilidade

O uso da arquitetura CORBA em um ambiente de computação móvel mostra-se muito

atraente. Isto porque, por um lado, CORBA torna transparente para o desenvolvedor de

uma aplicação distribuída questões como as linguagens de programação utilizadas na

construção dos componentes a serem utilizados pela sua aplicação, bem como a localização

desses componentes no ambiente. Por outro lado, um ambiente de computação móvel

permite que a idéia de transparência de localização de componentes seja estendida para o

caso em que tais componentes possam se mover durante o tempo de operação da aplicação.

Porém, ao se utilizar a arquitetura CORBA nesse tipo de ambiente várias considerações

devem ser feitas. Primeiramente, a quantidade de recursos disponíveis na maioria das

unidades móveis, como capacidade de processamento e armazenamento, é em geral inferior

à de unidades fixos. Há também outros recursos restritivos (em especial, a energia finita

provida por baterias) geralmente só encontrados em unidades móveis. A arquitetura

CORBA se baseia nos ORBs para prover às aplicações a infra-estrutura de processamento e

comunicação necessária, porém normalmente esses ORBs demandam muitos recursos do

sistema computacional. Em segundo lugar, redes sem fio oferecem menos largura de banda

e menos confiabilidade que as redes cabeadas tradicionais (chamadas neste trabalho de

redes fixas), por causa das características intrínsecas ao meio físico de transmissão. Uma

conseqüência disso é que a conectividade de uma unidade móvel é em geral fraca e muitas

vezes intermitente. Os IOPs definidos pela arquitetura CORBA, em particular o IIOP,

foram projetados inicialmente visando ambientes sem mobilidade. Como exemplo, assume-

se no IIOP que uma conexão TCP utilizada por uma conexão IIOP dificilmente será

encerrada abruptamente. O IIOP não oferece suporte à manutenção de uma conexão IIOP

que se estende sobre mais de uma conexão TCP, o que permitiria ao IIOP recuperar erros

provocados pelo encerramento abrupto de uma conexão TCP, ocorrido por exemplo graças

a um período de queda na intensidade do sinal no meio. Além disso, o formato de

codificação das mensagens IIOP privilegia a facilidade de implementação do protocolo e

não a otimização de uso da largura de banda do meio. Ou seja, o IIOP assume uma rede

com largura de banda relativamente alta.

6

O conjunto de considerações acima pode ser na verdade apresentado sob um único enfoque

mais geral:

Em um ambiente de computação móvel, as aplicações podem encontrar variações abruptas

na disponibilidade de recursos tanto nos sistemas computacionais como nos sistemas de

comunicação.

Para permitir que as aplicações mantenham-se operacionais em ambientes tão dinâmicos, é

necessário que essas aplicações ou os sistemas em si reajam a essas variações por meio de

ajustes dinâmicos em sua funcionalidade. Em outras palavras, é necessário que esses

elementos – aplicações ou sistemas – sejam adaptáveis.

Em [Satyanarayanan96] é feita uma classificação das possíveis formas de adaptação em

ambientes móveis. Essa classificação é feita com base no elemento a ser responsável pela

adaptação, e apresenta dois extremos. Em um extremo, encontram-se aquelas aplicações

que são inteiramente responsáveis pela adaptação e que dispensam qualquer suporte à

mobilidade oferecido pelo sistema. Além dos problemas de controle de alocação de

recursos apresentados em [Satyanarayanan96], essa forma de adaptação apresenta como

inconveniente a delegação de toda a responsabilidade pela adaptação aos desenvolvedores

das aplicações. Na arquitetura CORBA esse problema aumenta na medida em que,

tipicamente, diversos componentes que sejam do interesse de uma aplicação podem ter sido

construídos por desenvolvedores distintos segundo estratégias (isto é, heurísticas, políticas

e parâmetros) de adaptação distintas. No outro extremo da classificação proposta,

encontram-se aqueles sistemas que são completamente responsáveis por todas as

adaptações que forem necessárias, ou seja, as adaptações são transparentes para as

aplicações. Entre esses dois extremos surge um grande número de outras formas de

adaptação possíveis. Porém, todas elas têm em comum o fato de que a adaptação é uma

tarefa que envolve a colaboração entre as aplicações e o sistema, ou seja, as aplicações

tomam conhecimento das adaptações e sabem informar ao sistema quando elas são

adequadas (por exemplo, por meio de parâmetros de QoS), enquanto o sistema, por outro

lado, preserva sua habilidade em controlar a alocação de recursos.

As seções a seguir apresentam algumas das propostas encontradas na literatura que definem

modos de se utilizar eficientemente a arquitetura CORBA em ambientes de computação

7

móvel, levando em conta a classificação acima. É feita neste trabalho também uma

classificação quanto ao tipo de arquitetura de software utilizado na comunicação entre

ORBs de unidades móveis com ORBs que compõem o DPE na rede fixa. Por exemplo, em

uma arquitetura cliente-representante-servidor (ou cliente-proxy-servidor) o ORB de uma

unidade móvel é ciente das questões de mobilidade e faz uso explícito de um ORB

representante na rede fixa para se comunicar com o DPE na rede fixa. Já em uma

arquitetura cliente-interceptador-servidor é utilizado um ORB convencional na unidade

móvel. Sob o ponto de vista desse ORB, a sua comunicação com o restante do DPE na rede

fixa ocorre de modo similar à comunicação entre ORBs fixos. Porém, o que ocorre na

realidade é a interceptação dessa comunicação por um elemento presente na própria

unidade móvel (um interceptador), que se liga ao DPE na rede fixa por meio de um ORB

representante. A descrição dessas propostas inclui também os diversos métodos de

otimização de comunicação e de gerenciamento de localização por elas utilizadas. Essa

descrição é feita também levando em conta a nomenclatura introduzida em

[Satyanarayanan96].

8

3 Projeto DOLMEN

Em [Raatikainen97] é apresentado o projeto DOLMEN (service machine Development for

an Open Long-term Mobile and fixed network ENvironment), pertencente ao programa

europeu ACTS (Advanced Communications Techonology and Services). Esse documento,

submetido para apreciação junto ao OMG como candidato a novo padrão CORBA, propõe

novas facilidades a serem incluídas nessa arquitetura quando ambientes móveis estão

envolvidos na comunicação entre objetos. Nesse projeto é demonstrado como o padrão para

interoperabilidade da arquitetura CORBA, juntamente com alguns CORBAServices, pode

ser usado para dar às aplicações um suporte transparente à mobilidade.

A solução faz uso de uma arquitetura cliente-interceptador-servidor, e baseia-se no conceito

de pontes de interoperabilidade (interoperability bridges) descrito na arquitetura CORBA.

No projeto DOLMEN, são propostos dois tipos de pontes: as pontes fixas – FDBRs (Fixed

DPE Bridges) – que residem em nós presentes na rede fixa, e as pontes móveis – MDBRs

(Mobile DPE Bridges) – que residem nas unidades móveis. As MDBRs conectam o ORB

presente na unidade móvel ao DPE presente na rede fixa por meio de interações com uma

FDBR. A Figura 4 ilustra o relacionamento entre MDBRs e FDBRs em um DPE. O

ambiente de computação móvel é dividido em domínios de mobilidade. Cada domínio de

mobilidade tem associado uma ou mais FDBRs, que servem como pontos de acesso ao

DPE presente na rede fixa.

Mobility domain A

Mobility domain B

Mobility domain C

DPE(core network)

FDBR

MDBR

MU ORB

Figura 4 – Pontes de acesso e unidades móveis no projeto DOLMEN.

9

Uma invocação de método gerada na unidade móvel e direcionada a um objeto servidor que

esteja fora do ORB local é direcionada à MDBR, que encaminha a invocação à FDBR

associada, que então invoca diretamente o método no objeto desejado por meio do DPE na

rede fixa. A FDBR age então como representante da unidade móvel na rede fixa. A FDBR

também aceita invocações de métodos geradas na rede fixa e direcionadas a objetos

servidores presentes em unidades móveis, encaminhando-as à MDBR correta, que por sua

vez invoca diretamente o método no objeto desejado e retorna a resposta por meio da

FDBR. Nota-se nesse ponto que uma conexão entre uma aplicação cliente e um objeto

servidor envolve na verdade duas conexões IOP: uma conexão entre a FDBR e um ORB na

rede fixa e uma conexão entre o ORB na unidade móvel e a MDBR. Dessa forma, FDBRs e

MDBRs tornam transparentes tanto para as aplicações quanto para os objetos servidores os

problemas inerentes a um ambiente de computação móvel.

3.1 Gerenciamento de Localização

O gerenciamento de localização de objetos proposto pelo projeto DOLMEN constitui-se

basicamente em uma estrutura two-tier acrescida de ponteiros de redirecionamento que

objetivam reduzir os custos com atualizações de posição. [Raatikainen97] define uma

associação entre pontes como sendo um relacionamento lógico entre uma MDBR e uma

FDBR. Uma associação entre pontes é criada sempre que uma unidade móvel ingressa em

um novo domínio de mobilidade, e continuará a existir enquanto houver objetos usando

essa associação particular. A associação mais recentemente criada para uma dada MDBR é

chamada de associação primária e define o relacionamento entre essa MDBR e a FDBR

que atualmente serve como ponto de acesso da MDBR ao DPE da rede fixa. Conforme uma

unidade móvel muda para um novo domínio, ele deixa uma trilha de associações

secundárias nas FDBRs dos domínios anteriores, que aponta para a FDBR atual. Essas

associações secundárias são mantidas enquanto houver conexões entre aplicações clientes e

objetos servidores que façam uso das associações. Quando uma FDBR recebe, por

exemplo, uma resposta de invocação que é destinada a uma aplicação cliente presente em

uma unidade móvel que não está mais em seu domínio, a FDBR faz uso de um mecanismo

de tunelamento (análogo ao Mobile IP) pelo qual a resposta da invocação é repassada à

10

outra FDBR, e assim por diante, até que se alcance a FDBR que contém uma associação

primária com a MDBR da unidade móvel onde se encontra a aplicação cliente.

Como se percebe, associações secundárias são fundamentais para aquelas conexões que

ainda estão em andamento quando uma unidade móvel participante da conexão (na

condição de cliente ou servidor) muda de domínio. Porém, quando uma unidade móvel

contém objetos servidores, atualizações de posição são necessárias mesmo que não haja

conexões estabelecidas entre aplicações clientes e objetos servidores. O problema é que as

IORs (Interoperable ORs), as ORs tradicionalmente utilizadas na arquitetura CORBA,

incluem implicitamente a localização dos objetos no DPE2.

Como as FDBRs são as representantes das unidades móveis no DPE, as IORs dos objetos

servidores presentes nessas unidades móveis deveriam incluir informações sobre a

localização das FDBRs. Com isso, cada vez que uma unidade móvel mudasse de domínio

de mobilidade, as IORs dos objetos servidores presentes nessa unidade móvel teriam que

ser alteradas. A estratégia de atualização de posição de objetos servidores apresentada em

[Raatikainen97] faz uso de RORs (Relocatable Object References), um tipo de OR

introduzido na arquitetura CORBA que dá suporte à migração de objetos entre ORBs

diferentes. Ao contrário das IORs, RORs não incluem necessariamente informações de

localização dos objetos. Porém, o uso puro e simples dessa abordagem traria como

conseqüência o fato de que o desenvolvedor de um objeto servidor teria que explicitamente

indicar que esse objeto pode migrar. Essa é uma limitação imposta pela arquitetura

CORBA, pois é através dessa indicação que a migração de objetos pode ser gerenciada.

Esse gerenciamento é normalmente feito por meio de um CORBAService, que pode ser um

serviço de nomes ou então mais especificamente um serviço de registro de localização –

LR (Location Register).

Em [Raatikainen97] o problema de localização de objetos servidores é resolvido da

seguinte forma. RORs são definidas somente no contexto das FDBRs. Essa OR é

construída de forma a incluir, implicitamente, uma identificação unívoca da unidade móvel

onde o objeto servidor se encontra – o GTID (Global Terminal Identifier). O mapeamento

2 Uma IOR contém, pelo menos, o par (nome_da_maquina, porta_de_acesso_ao_objeto), que na arquitetura

TCP/IP corresponde ao nome DNS de um host e a porta TCP utilizada para a comunicação com o objeto.

11

de qual FDBR é a representante atual de uma unidade móvel (identificado pelo seu GTID)

é mantido por um LR. Do ponto de vista do DPE, é como se objeto migrasse entre

diferentes máquinas. Ao receber uma requisição de estabelecimento de conexão com um

objeto cuja referência seja uma ROR, a FDBR extrai da mesma o GTID, e repassa a

requisição à unidade móvel em questão. Quando uma unidade móvel muda de domínio, é

necessário que a entrada no LR relativa à unidade móvel seja atualizada com a identificação

da nova FDBR. Obviamente, quando um novo objeto servidor é criado em uma unidade

móvel, a MDBR deve informar à FDBR com o qual mantém uma associação primária sobre

essa criação, a fim de que a FDBR possa criar uma ROR para o objeto e disponibilizá-la às

aplicações, por meio da inserção de novas informações nos serviços de nomes e de registro

de localização.

Mesmo com todos os mecanismos de atualização de posição supracitados, a identificação

da FDBR representante de um objeto servidor, já obtida em conexões anteriores por uma

aplicação cliente, pode ficar desatualizada por causa de uma movimentação de uma unidade

móvel. Com isso a FDBR que era representante anterior de um objeto servidor pode ainda

receber requisições de conexão para esse objeto. Para permitir que tais conexões sejam

bem-sucedidas, as FDBRs fazem uso do mecanismo de redirecionamento automático de

localização oferecido pela arquitetura CORBA. Quando uma aplicação cliente requisita

uma conexão com um objeto servidor por meio de uma FDBR que não é mais representante

do mesmo, essa FDBR informa ao objeto stub associado à aplicação cliente, por meio de

uma mensagem LOCATION_FORWARD, a nova FDBR representante do objeto (por

meio de uma nova ROR), e a requisição pode ser então redirecionada. Como o tratamento

do redirecionamento é feito pelo stub, a aplicação não percebe essas atualizações de

posição.

3.2 Otimização de comunicação

As principais formas de otimização propostas pelo projeto DOLMEN encontram-se no

contexto da comunicação entre MDBRs e FDBRs. A Figura 5 ilustra a decomposição

funcional desses dois elementos, com destaque para a comunicação entre os mesmos. Os

componentes hachurados representam as partes específicas das pontes que tratam a questão

12

da mobilidade. Nem todos os componentes apresentados em [Raatikainen97] estão aqui

ilustrados por motivo de simplificação.

Figura 5 – Relacionamento entre MDBRs e FDBRs.

O adaptador de rede móvel – MNA (Mobile Network Adapter) – provê uma interface de

adaptação que esconde dos ORBs das MDBRs e FDBRs as diferenças entre as várias

tecnologias de redes móveis, oferecendo um serviço orientado à conexão confiável no

contexto de um domínio de mobilidade. Ou seja, o serviço provido pelo MNA é confiável

contanto que a MDBR não mude de domínio durante uma comunicação em decurso. O

protocolo LW-IOP (Light-Weight IIOP) provê exatamente o mesmo serviço que o IIOP,

porém é acrescido de algumas otimizações para funcionar de modo mais eficiente em um

meio sem fio. Como exemplos de otimizações possíveis, [Raatikainen97] apresenta

sucintamente a sintaxe de transferência LWR (Light-Weight Representation), que é

utilizada pelo LW-IOP em lugar da sintaxe padrão CDR (Common Data Representation)

utilizada pelo IIOP. Essa sintaxe basicamente otimiza a representação de tipos de dados

primitivos (inteiros, strings, etc.) e tipos de dados compostos (estruturas, arrays, etc.). Além

disso, [Raatikainen97] apresenta também um esquema de caching de tipos de dados longos

(strings, arrays, estruturas, etc.). O mecanismo de cache é embutido nos mecanismos de

marshalling. Quando uma string, por exemplo, está sendo encapsulada para envio por uma

das pontas de uma conexão LW-IOP, é primeiramente verificado se a string está no cache

emissor. Se estiver, somente a referência do cache é enviada, na invocação encapsulada, à

outra ponta da conexão LW-IOP. Senão, é verificado se a string está no cache receptor. Se

estiver, somente a referência do cache é enviada. Senão, a string é colocada no cache

TCP/IP

IIOP

ORB Bridgingfunction

MNA

LW-IOP

TCP/IP

IIOP

ORBBridgingfunction

MNA

LW-IOP

LR

Standard CORBA communicationwithin DPE

Standard CORBA communicationwithin mobile unit

CORBA communicationwithin wireless

NS

13

emissor e tanto a string como a nova referência a ela no cache emissor são enviados. Ao

receber uma referência junto com a string correspondente em uma invocação encapsulada,

a outra ponta da conexão LW-IOP insere uma nova entrada no cache receptor. A Figura 6

ilustra o mecanismo de cache.

Emmitercache

Receivercache

Emmitercache

Receivercache datadata

1: check emitter cache

2: check receiver cache

cache reference-

cache entry update-

cache entry remove

cache entry remove ack

Figura 6 – Caching de tipos de dados longos e encapsulamentos.

O gerenciamento do cache é baseado na política LRU (Least Recently Used) e em um

mecanismo de coleta de lixo. Quando o cache emissor enche, as entradas menos acessadas

ultimamente são escolhidas para remoção e uma mensagem LW-IOP específica para

atualização de cache é enviada, indicando que as entradas equivalentes no cache receptor da

outra ponta da conexão LW-IOP devem ser removidas. As entradas no cache emissor só

serão efetivamente removidas quando a outra ponta da conexão LW-IOP enviar de volta

um reconhecimento da mensagem de atualização de cache.

14

4 Arquitetura ALICE

A Referência [Haahr99] apresenta a arquitetura ALICE (Architecture for Location

Independent CORBA Environments), desenvolvida pelo grupo de pesquisa de sistemas

distribuídos do Trinity College Dublin, na Irlanda. A arquitetura ALICE faz uso de uma

arquitetura cliente-representante-servidor. Os gateways de interoperabilidade – MGs

(Mobility Gateways) – são os elementos da arquitetura ALICE responsáveis por exercer a

função de representante da unidade móvel, de modo análogo às FDBRs no projeto

DOLMEN. A Figura 7 ilustra o relacionamento entre as unidades móveis e os MGs na

arquitetura ALICE.

MG

MG Fixed host

Mobile unitnew

logical connection

old logical

connection

IIOP connections

Internet

Figura 7 – Gateways de interoperabilidade e unidades móveis na arquitetura ALICE.

Uma requisição de conexão, gerada em uma unidade móvel ou cujo destinatário seja um

objeto servidor em uma unidade móvel, é tratada na arquitetura ALICE de modo similar ao

projeto DOLMEN. A principal diferença está na questão da transparência de mobilidade.

Os MGs permitem que as aplicações presentes em unidades móveis invoquem métodos em

objetos servidores presentes na DPE da rede fixa do mesmo modo que uma aplicação na

rede fixa, porém objetos servidores presentes em unidades móveis precisam utilizar funções

específicas relacionadas à mobilidade providas pelo ORB específico de unidade móvel da

arquitetura ALICE. Essas funções específicas são estruturadas em duas camadas que

residem entre a camada provida pelo IIOP e a provida pelo TCP, denominadas de camada

15

S/IIOP (Swizzling IIOP) e camada de mobilidade – ML (Mobility Layer). Ambas as

camadas são encontradas também nos MGs, e são elas que implementam efetivamente as

funções de interceptação de requisições de conexão e de representação de ORBs móveis. A

Figura 8 ilustra o posicionamento dessas camadas na arquitetura ALICE. As tarefas

executadas por cada camada são explicadas nas subseções a seguir.

Figura 8 – Visão geral das camadas S/IIOP e ML na arquitetura ALICE.

4.1 Gerenciamento de Localização

O esquema de gerenciamento de localização de objetos proposto pela arquitetura ALICE é

basicamente o mesmo que o descrito no projeto DOLMEN. [Haahr99] define como uma

conexão lógica uma conexão IIOP estabelecida entre o ORB de uma unidade móvel e seu

representante (o seu MG atual). Uma nova conexão lógica é criada sempre que uma

requisição de conexão é (1) disparada por uma aplicação cliente na unidade móvel ou (2)

destinada a um objeto servidor na unidade móvel.

No primeiro caso, a IOR do objeto servidor é tratada pela entidade S-IIOP da unidade

móvel, que pede à ML o estabelecimento de uma conexão lógica com o MG. Após o

estabelecimento da conexão lógica, a entidade ML do MG envia à entidade ML da unidade

móvel um identificador de conexão lógica – LCID (Logical Connection Identifier). Em

seguida, a entidade S-IIOP da unidade móvel pede à entidade S-IIOP do MG a criação de

uma conexão IIOP na rede fixa com o ORB onde está o objeto servidor. O LCID passa a

definir então uma associação entre a conexão lógica e a conexão IIOP na rede fixa.

S/IIOP

IIOP

TCP/IP

IIOP

TCP/IP

ORB ORB

ML

S/IIOP

TCP/IP

ML

application<->object connection

logical connection

IIOP connection

exchange of LCID info,

handoffrequest, ...

IORsIORsIORsSIORsSIORsSIORs

16

No segundo caso, quando o objeto servidor é criado, primeiramente sua IOR é enviada pela

entidade S-IIOP da unidade móvel à entidade S-IIOP do MG. A entidade S-IIOP nesse MG

define então uma IOR específica para si, denominada SIOR (Swizzled IOR) e retorna à

entidade S-IIOP da unidade móvel essa SIOR. Quando um cliente tentar requisitar uma

conexão com o objeto servidor presente na unidade móvel, ele usará SIOR como referência.

Quando a entidade S-IIOP recebe um pedido de requisição de conexão, a entidade ML do

MG estabelece uma conexão lógica com a unidade móvel e repassa à entidade ML nessa

unidade móvel o novo LCID criado.

Em todos os casos, as MLs das unidades móveis e dos MGs armazenam em um cache os

LCIDs e as informações de estado das conexões lógicas associadas, para poder consultá-los

posteriormente. Como percebe-se, uma das diferenças principais entre a arquitetura ALICE

e o projeto DOLMEN é que no primeiro são utilizados IORs ao invés de RORs na

divulgação de serviços na rede fixa. As implicações dessa decisão de projeto serão vistas

mais adiante.

Quando, em decorrência de uma movimentação, uma unidade móvel se associa a um novo

MG, a entidade ML da unidade móvel envia uma mensagem de requisição de handoff à

entidade ML do novo MG. Essa requisição inclui o endereço do MG anterior e os LCIDs

que haviam sido criados juntos a esse MG. Ao receber a mensagem de requisição de

handoff, a entidade ML no novo MG cria, para cada LCID recebida, uma conexão TCP

com o MG anterior e envia um reconhecimento da requisição de handoff. Nesse momento,

a entidade ML do MG anterior envia à entidade ML do novo MG as informações de estado,

residentes em seu cache, de todas as conexões lógicas existentes entre a unidade móvel e o

MG anterior no momento em que ocorreu a movimentação. Em seguida, a entidade ML do

MG anterior retira de seu cache as informações de estado passadas à entidade ML do novo

MG e envia a esta última uma mensagem de encerramento de handoff. A entidade ML do

novo MG repassa então essa mensagem à entidade ML da unidade móvel. Nesse estágio,

várias conexões IIOP podem ainda existir entre ORBs na rede fixa e o MG anterior,

referentes a conexões ainda abertas entre aplicações clientes e objetos servidores. Novas

invocações no contexto dessas conexões serão tuneladas por meio das conexões TCP

criadas entre o novo MG e o MG anterior.

17

No caso de unidades móveis que contém objetos servidores, o gerenciamento de

localização faz uso de callbacks para notificar às entidades S-IIOP da unidade móvel e dos

MGs envolvidos a ocorrência de uma movimentação. A arquitetura ALICE define na

interface provida pela camada ML duas operações adicionais às operações de sockets

[Comer95] tradicionalmente oferecidas pelos sistemas operacionais para que os serviços

providos pela pilha de protocolos TCP/IP possam ser utilizados: operações de registro e

deregistro de callbacks (operações add_callback() e delete_callback()). Um callback

configurado por meio dessas operações será disparado sempre que a unidade móvel mudar

de MG, e retornará informações sobre o novo MG. O callback é disparado pelas entidades

ML da unidade móvel e dos MGs no momento em que a mensagem de encerramento de

handoff é gerada no MG anterior e tratada no novo MG e na unidade móvel. Dessa forma, a

entidade S-IIOP do MG anterior tem como conhecer o correspondente atual do objeto

servidor procurado. O MG anterior pode então, frente à requisições de conexão para o

objeto servidor, encaminhar essas requisições utilizando o redirecionamento automático de

localização oferecido pela arquitetura CORBA por meio da mensagem

LOCATION_FORWARD. Cabe aqui ressaltar outra diferença importante entre a

arquitetura ALICE e o projeto DOLMEN, que é o fato de que o suporte a objetos servidores

instalados em unidades móveis na arquitetura ALICE não faz uso de um serviço de registro

de localização específico. O que ocorre então é que requisições de conexão sempre serão

feitas inicialmente ao primeiro MG a ser utilizado como correspondente de um determinado

objeto servidor, que redirecionará a requisição utilizando a mensagem

LOCATION_FORWARD para o segundo MG, e assim por diante, até alcançar o MG atual.

Para um ambiente com taxas de mobilidade altas o custo de redirecionamentos pode se

tornar também alto demais. De uma forma geral, pode-se dizer que o projeto DOLMEN

privilegia a redução nos custos de consulta de localização, enquanto que a arquitetura

ALICE privilegia a redução nos custos de atualização de localização.

4.2 Otimização da comunicação

Em [Haahr99] praticamente nada é dito a respeito de possíveis otimizações na comunicação

pela rede sem fio. Pôde-se perceber, no entanto, que a arquitetura ALICE tenta resolver os

problemas referentes à mobilidade sem definir protocolos específicos para a comunicação

18

entre unidades móveis e ORBs representantes. Ou seja, a pilha de protocolos TCP/IP é

utilizada também na comunicação entre as unidades móveis e os MGs. Isso traz como

vantagem a maior facilidade de implantação dessa solução, porém a eficiência da

comunicação pode ser bastante comprometida. Na verdade, o objetivo principal da

arquitetura ALICE não é a eficiência, mas sim a confiabilidade da comunicação, uma vez

que uma das funções mais importantes da camada ML é manter funcional a conexão entre

aplicação cliente e objeto servidor, mesmo na ocorrência de handoffs ou de interrupções

abruptas de conexões lógicas no meio sem fio.

19

5 Outras Propostas

O projeto OnTheMove [Kemp96] apresenta outra proposta para a utilização da arquitetura

CORBA em ambientes de computação móvel, porém seu foco é na definição de uma

camada similar à camada ML da arquitetura ALICE e cuja principal tarefa é manter a

funcionalidade de conexões entre aplicações clientes e objetos servidores mesmo na

ocorrência de interrupções de conexões de transporte no meio sem fio. Porém, a solução

não leva em conta a possibilidade de ocorrência de handoffs.

A arquitetura Mobiware [Angin98] permite a implementação de aplicações multimídia

adaptáveis com relação às condições variáveis de QoS normalmente oferecidas pelas redes

sem fio, aproveitando-se das características intrisecas de escalabilidade associadas a mídias

de representação contínuas, como áudio e vídeo. Sucintamente, a arquitetura Mobiware

permite que dispositivos de aquisição, codificação e apresentação de mídias (câmeras,

decodificadoras de vídeo, monitores de vídeo, etc.) bem como dispositivos de comunicação

(placas de rede, roteadores, etc.) possam ser representados como objetos, e que possam ser

portanto controlados por aplicações clientes utilizando a arquitetura CORBA como o DPE

necessário para a comunicação entre aplicações clientes e objetos. Obviamente, a

arquitetura Mobiware leva em conta o fato de que esses objetos (ou seja, os dispositivos)

podem ser encontrados em unidades móveis. Por isso, entre outras características, a

arquitetura Mobiware implementa um algoritmo de handoff com controle de QoS que

permite que um fluxo de mídia contínua possa ser reescalonado de forma adequada (por

meio de filtragem ou compactação, por exemplo) quando ocorre um handoff e a

disponibilidade de largura de banda varia abruptamente. Como exemplo de funcionamento

desse algoritmo, quando um servidor de vídeo móvel sofre um handoff e a largura de banda

é reduzida, a aplicação cliente pode ser notificada. Ela pode então requisitar aos objetos

participantes da comunicação com o servidor de vídeo móvel uma redução controlada na

qualidade do vídeo que não ultrapasse a qualidade esperada pelo usuário final.

20

6 Referências

[Angin98] Angin, O., Campbell, A. T., Kounavis, M. E., Liao, R. R.-F. The

Mobiware Toolkit: Programmable Support for Adaptive Mobile

Networking. In IEEE Personal Communications Magazine, agosto

de 1998.

[Comer95] Comer, D. Internetworking with TCP/IP, Volume 1. 3rd edition,

Prentice-Hall, 1995.

[Raatikainen97] Raatikainen, K. et al. Bridging and Wireless Access for Terminal

Mobility in CORBA. DOLMEN Project Technical Contribution LK-

OMG01, novembro de 1997.

[Haahr99] Haahr, M., Cunningham, R., Cahill, V. Supporting CORBA

Applications in a Mobile Environment. In Proceedings of the 5th

Annual ACM/IEEE International Conference on Mobile Computing

and Networking (Mobicom’99), Seattle, WA, EUA, 1999.

[Kemp96] Kemp, P. et al. Design of MASE V2. Internet publication –

http://www.sics.se/~onthemove/docs/OTM_d33.doc, 1996.

[Microsoft98] Microsoft Corporation. Microsoft COM Technologies – DCOM.

Internet publication – http://www.microsoft.com/com/tech/dcom.asp,

março de 1998.

[OMG98] Object Management Group. The Common Object Request Broker:

Architecture and Specification, V2.2. Object Management Group,

agosto de 1998.

[Satyanarayanan96] Satyanarayanan, M. Fundamental Challenges in Mobile Computing.

In Proceedings of the 15th ACM Symposium on Principles of

Distributed Computing, Philadelphia, PA, EUA, maio de 1996.

[Sun98] Sun Microsystems. Java Remote Method Invocation – Distributed

Computing for Java. Internet publication – http://www.sun.com,

White Paper, 1998