CORBA em dispositivos móveis

Overview de CORBA Framework para programação distribuída independente de

linguagem, mantida pela OMG. Componente central: ORB, que é responsável por traduzir as

chamadas em mensagens de rede entre os clientes e servidores.

Independência de linguagem obtida através da IDL e compiladores de IDL específicos para cada linguagem.

Concebida originalmente para redes fixas, cabeadas e o seu uso em ambientes sem fio requer adaptação.

Interoperabilidade em CORBA (1)

Em CORBA, objetos são identificados pelas IORs (Interoperable Object References).

Uma IOR pode conter uma seqüência não vazia de perfis, onde cada perfil está associado a um protocolo e contém as informações necessárias para fazer invocações utilizando esse protocolo.

O protocolo que garante a interoperabilidade é o GIOP (General Inter Orb Protocol), que é um protocolo abstrato que apenas especifica as mensagens a serem trocadas e como elas devem ser tratadas.

Interoperabilidade em CORBA (2)

GIOP não especifica o protocolo de transporte, mas requer que este seja confiável, orientado a conexões e notifique perda de conexão.

Como GIOP é abstrato, ele precisa ser mapeado para algum protocolo de transporte que atenda aos requisitos impostos.

CORBA fornece um desses mapeamentos: IIOP (Internet Inter-Orb Protocol) ou GIOP sobre TCP.

GIOP define oito mensagens, das quais as mais importantes são Request e Reply.

Interoperabilidade em CORBA (3)

Para que todas as partes envolvidas compreendam as mensagens enviadas, é necessária a adoção de um formato para representação dos dados.

Em CORBA isso se dá pela CDR (Common Data Representation), que especifica para cada tipo primitivo de CORBA IDL como deve ser sua representação em bytes para ser incluído em uma mensagem GIOP.

Tipos compostos são representados recursivamente em termos dos seus componentes.

Concepção do Wireless CORBA

1999 – criação de uma RFP (Request for Proposals) para acesso sem fio e mobilidade de terminais em CORBA.

2000 – OMG recebe duas submissões iniciais para a RFP, uma da Nokia e Vertel e outra da Inprise e Highlander.

2001 – OMG recebe dos dois grupos uma proposta única e revisada, que foi adotada como a especificação Wireless Access and Terminal Mobility in CORBA, também conhecida por Wireless CORBA.

2003 – Lançamento da versão 1.0 da especificação. 2004 – Lançamento da versão 1.1.

Especificação Wireless CORBA

Objetivos Principais Definir uma forma de comunicação entre objetos CORBA

utilizando um link sem fio. Tratar e permitir a mobilidade dos objetos CORBA. Manter a interoperabilidade com ORBs que não implementam

essa especificação. Um cliente em um ORB desses deve poder fazer uma invocação para um terminal móvel sem conhecimento da mobilidade do mesmo.

Domínios e seus conteúdos

Home Domain Home administrativo do terminal móvel. Tem como principal componente o Home Location Agent. O Home Location Agent fornece operações para consulta e

atualização dos terminais móveis sob sua jurisdição. O HLA também fornece operações para obtenção de

referências CORBA para serviços disponíveis no Home Domain.

Alguns terminais não estão associados a um Home Domain e são conhecidos por terminais homeless.

Terminal Domain Consiste em tudo que está no terminal móvel. A interface do Terminal Domain é a Terminal Bridge. Todas as invocações originadas ou destinadas a um terminal

móvel passam pela Terminal Bridge, que se comunica com sua parte similar na rede fixa através de um protocolo específico.

Pode permitir handoff do terminal móvel além de fornecer notificações de eventos relacionados à movimentação do terminal para quem tiver interesse.

Visited Domain Localizada na rede fixa. Tem como principal componente as Access Bridges, que são

as contrapartes das Terminal Bridges nos terminais móveis. A Access Bridge encapsula / desencapsula as mensagens

GIOP enviadas / recebidas da Terminal Bridge usando um protocolo de tunelamento.

Possui operações de suporte a handoff dos terminais móveis e notificação de eventos relacionados à movimentação dos terminais.

IORs Móveis (1) IOR especial que esconde a mobilidade do terminal dos

clientes que invocam operações em objetos nesse terminal. Em uma IOR móvel, há um perfil adicional, o Mobile Terminal

Profile, que contém informações do terminal móvel. O perfil IIOP dessas IORs contém o endereço e porta do HLA

do terminal (ou da Access Bridge para terminais homeless). Invocações destinadas a um terminal móvel devem de

alguma forma ser direcionadas para a Access Bridge atualmente conectada ao terminal.

IORs Móveis (2)

IORs Móveis (3) HLA recebe uma invocação para um terminal móvel, lê o

Mobile Terminal Profile da IOR e responde ao cliente com status LOCATION_FORWARD para redirecionar a invocação para a AB. Lança UnknownTerminalId caso o terminal não esteja sob sua jurisdição.

A AB por sua vez pode responder ao cliente com status LOCATION_FORWARD caso o terminal tenha executado handoff e esteja agora associado a outra AB. Caso ela desconheça a localização do objeto, responde com status OBJECT_NOT_EXIST.

Tunelamento A duas Bridges se comunicam entre si usando como

protocolo o GTP (GIOP Tunneling Protocol). Assim como o GIOP, o GTP é um protocolo abstrato. Define os formatos das mensagens para estabelecer, liberar

e re-estabelecer (recuperar) o túnel, além de mensagens para transmitir e redirecionar mensagens GIOP.

A especificação define quatro protocolos de tunelamento concretos: TCP, UDP, WAP e Bluetooth.

Arquitetura do protocolo

Tunelamento A Access Bridge é responsável pela tradução entre o

protocolo IIOP usado pelo objeto na rede fixa e o protocolo GTP usado pelo terminal.

Mensagens GTP sobre o link sem fio são transferidas pela camada de adaptação, que garante a confiabilidade e entrega ordenada das mensagens.

Mensagens GTP (1) GTP define 17 mensagens, a maioria em pares Request-Reply. Podem ser agrupadas em quatro categorias:

Gerenciamento do tunelamento Uso da conexão GIOP Redirecionamento GTP Outros propósitos

Mensagens GTP (2) As mensagens de gerenciamento do tunelamento são

compostas por 3 pares Request-Reply: EstablishTunnel, ReleaseTunnel e HandoffTunnel

EstablishTunnelRequest é enviada pela Terminal Bridge para estabelecer uma conexão com a Access Bridge.

ReleaseTunnelRequest é enviada por ambas as partes para fechar a conexão GTP.

HandoffTunnelRequest é usada pela Access Bridge para iniciar um handoff originado pela rede fixa.

Mensagens GTP (3) As mensagens relacionadas ao uso da conexão GIOP são

dois pares Request-Reply: OpenConnection e CloseConnection, além das mensagens GIOPDataError, GIOPData e CloseConnectionIndication.

OpenConnectionRequest é usada para abrir uma conexão GIOP e CloseConnectionRequest para fechá-la. As mensagens GIOP são encapsuladas em mensagens GIOPData e transmitidas pelo túnel GTP.

CloseConnectionIndication alerta o outro lado do túnel que a conexão foi fechada de forma assíncrona e não como resposta a uma CloseConnectionRequest.

Mensagens GTP (4) Mensagens de redirecionamento são compostas por um

único par Request-Reply: GTPForward. GTPForwardRequest é enviada pela TB ou pela AB para

redirecionar mensagens para / de uma AB antiga. Essa mensagem contém uma referência para uma AB.

Se foi originada pela TB, a referência contida na mensagem é uma referência para uma AB antiga. Nesse caso, a AB atual redireciona a mensagem executando a operação gtp_from_terminal na AB antiga.

Se foi originada pela AB, então a referência aponta para a AB que originou a chamada redirecionada.

Mensagens GTP (5) A última categoria contém as mensagens IdleSync e Error. IdleSync é usada para sincronizar as mensagens recebidas

para efetuar o descarte das mensagens enviadas de tempos em tempos.

Error indica que algo deu errado de modo que recuperação não é possível e que o túnel GTP será fechado.

Handoff Backward handoff: quando uma conexão existente é

modificada para passar por um novo ponto de acesso. Forward handoff: quando uma conexão perdida é re-

estabelecida. A especificação se refere a esses dois tipos como handoff e

recuperação de acesso. O handoff pode ainda ser dividido em dois casos,

dependendo se o procedimento é iniciado pela rede ou pelo terminal móvel.

Participantes e Observadores Quatro participantes: Terminal Bridge (TB), Access Bridge

antiga (old AB), Access Bridge nova (new AB) e o Home Location Agent (HLA).

Quando o terminal se move, as ABs antigas podem precisar redirecionar mensagens para ele. Para isso, elas podem invocar subscribe_handoff_notice na AB atual para indicar que tem interesse na movimentação do terminal.

Em um handoff, a AB atual invoca handoff_notice em todas as ABs registradas e automaticamente se registra na nova AB.

Handoff iniciado pela rede Presume-se a presença de um controlador externo que

invoca start_handoff na interface da AB antiga, passando o id to terminal e uma referência para a nova AB.

AB antiga envia para o terminal HandoffTunnelRequest. Terminal envia EstablishTunnelRequest para a nova AB,

junto com uma referência para a AB antiga. Nova AB primeiro informa ao HLA a nova localização do

terminal e depois envia EstablishTunnelReply para o mesmo.

Terminal envia HandoffTunnelReply para a AB antiga e libera o túnel usado.

Eventos apropriados são notificados aos interessados.

Handoff iniciado pela rede

Handoff iniciado pelo terminal Terminal Bridge decide alterar sua AB. Primeiro, ela envia a mensagem EstablishTunnelRequest

para a nova AB, junto com uma referência para a AB antiga. A nova AB informa o HLA invocando update_location e a AB

antiga com uma invocação handoff_in_progress. Depois disso, envia a mensagem EstablishTunnelReply de

volta para a TB. TB fecha o túnel com a AB antiga, todas as Bridges geram os

eventos apropriados e a AB antiga notifica as ABs interessadas sobre o handoff.

Handoff iniciado pelo terminal

Recuperação de acesso Similar ao procedimento de handoff iniciado pelo terminal. Depois da recuperação, a TB e a AB antiga precisam re-

enviar as mensagens não concluídas. A AB antiga faz isso invocando gtp_to_terminal na nova AB,

que por sua vez redireciona a mensagem para o terminal em mensagens GTPForward.

A TB, por outro lado, envia GTPForward para a nova AB, que por sua vez repassa para a AB antiga invocando gtp_from_terminal.

Recuperação de acesso

Exemplos: invocação do terminal para a rede fixa

Exemplos: invocação da rede fixa para o terminal

Exemplos: handoff no meio de invocação originada pelo terminal

Exemplos: handoff no meio de invocação originada pela rede fixa

Conclusões Define modos de lidar com a comunicação sem fio entre

objetos CORBA e com a mobilidade desses objetos. Garante a interoperabilidade com ORBs que não

implementam essa especificação. O foco é a comunicação sem fio e mobilidade, não restrições

devido a escassez de recursos (Minimum-CORBA). Algumas implementações disponíveis (Ex: MIWCO – MICO is

Wireless CORBA), mas nenhum teste de interoperabilidade entre essas implementações foi feito até agora.