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