1

Java Java MessageMessage ServiceService –– JMSJMSee

WirelessWireless CORBA CORBA SpecificationSpecification -- WCORBAWCORBA

Vagner Sacramentovagner@lac.inf.puc-rio.br

Laboratory for Advanced Collaboration - LAC

Departamento de Informática - PUC-Rio

22

Agenda Agenda -- JMSJMS• Introdução

– Messaging e Message-Oriented Middlewares (MOMs)– Quando usar MOMs? Vantagens e Desvantagens– O que é o Java Message Service?

• Conceitos fundamentais do JMS– Arquitetura JMS– Domínios: ponto-a-ponto e pub/sub – Produção e consumo de mensagens

• Plataforma de desenvolvimento JMS – Objetos gerenciados– Conexões, sessões, produtores, consumidores, mensagens

• Exemplos de aplicações– Configuração do ambiente ( J2EE RI)– Exemplo de aplicação ponto-a-ponto– Exemplo de aplicação pub/sub

33

IntroduçãoIntrodução• O objetivo desta apresentação é introduzir o modelo de

comunicações baseado em mensagens (messaging) e demonstrar como implementa-lo em aplicações Java usando o Java Message Service (JMS);

• Conceitos fundamentais de messaging e MOMs

• Apresentar a API JMS para uso do MOM;

• Exemplos de aplicações (estilo "Hello World") para os dois paradigmas de messaging (Point-to-Point e Pub/Sub);

2

44

O que é O que é MessagingMessaging??• Método de comunicação entre componentes ou aplicações

– Usado em uma arquitetura peer-to-peer com serviço centralizado para repasse de mensagens recebidas e enviadas;

– Neste modelo de comunicação clientes e servidores enviam e recebem mensagens para canais administrados através de serviço central de mensagens (MOM);

55

Message-oriented Middleware (MOM)• Infraestrutura de mensagem que suporta “messaging”;

• Sistemas de messaging são freqüentemente chamados de Message-Oriented Middleware (MOM)– Conceito não é novo: já existe há algum tempo em

implementações proprietárias ( e incompatíveis);• Tibco/Rendezvous• BEA Tuxedo/Q• Microsoft MSMQ

– JMS API: solução independente de fabricante para acessar serviços MOM a partir de clientes Java;

• Alguns produtos MOM compatíveis com JMS– ****Open Source: JBossMQ, OpenJMS, JORAM*****– IBM MQSeries, IPlanet MQ, Bea WebLogic, HP-MS, Progress

SoniqMQ– Mais em: java.sun.com/products/jms/

66

Por que “Por que “MessagingMessaging”?”?• Viabiliza comunicação distribuída com acoplamento fraco

– Interface genérica: MOM ignora conteúdo e repassa qualquer coisa. Formato do conteúdo deve ser conhecido pelas partes;

– Assíncrona: Comunicação pode ocorrer mesmo que o cliente e servidor não estejam disponíveis ao mesmo tempo

• Desempenho: Não bloqueante quando desempenhando um Request.

• Confiabilidade: Garantia de entrega mesmo se o destinatário estiver inativo. O MOM fica encarregado de rotear a mensagem para o destinatário assim que ele estiver ativo novamente. O emissor e receptor não tem que estarem disponíveis ao mesmo tempo para comunicarem.

3

77

Messaging vs. RMI/RPC• Messaging / JMS

– Mensagens são representadas como eventos;– Interface genérica (pode ser reutilizada para aplicações

diferentes);– Arquitetura centralizada (tudo passa pelo MOM);– Serviços de diretórios localizam canais de comunicação (

destinos);

• RMI/RPC (Corba, Java RMI, etc.) / WCORBA– Mensagens são representadas como chamadas para métodos

remotos;– Cada aplicação se comunica através de uma interface definida;– Pode ser descentralizado (rede de ORBs ligados por IIOP);– Serviços de diretórios localizam objetos;

88

Messaging vs. RMI/RPC• Sistema de Messaging com

paradigma pub/sub

• JMS

• Sistema RMI/RPC (Java RMI ou CORBA)• WCORBA

99

Desvantagens dos MOMs• Desvantagens

– Camada adicional para repasse de mensagens– Centralização em único ponto introduz risco de falha de todo o

sistema caso o serviço de mensagens falhe;• Solução: replicação, ...

• Desvantagens relativas – Muito genérica: aplicações precisam decifrar as mensagens para

que possam operar; esconde a interface de programação remota dentro das mensagens

– Comunicação assíncrona (geralmente): dificulta a criação de aplicações que necessitam de comunicação síncrona.

4

1010

Vantagens dos MOMs (1)• Escalabilidade

– Para aumentar a capacidade servidora, basta acrescentar mais servidores ( não é preciso mexer nos componentes);

– Novos clientes podem se conectar para usar mensagens em outras aplicações;

– Infra-estrutura é reutilizada para novas aplicações;

• Comunicação assíncrona– Componentes podem realizar outras tarefas enquanto não estão

ocupados lidando com requisições;– Podem sondar o servidor em busca de novas mensagens

quando estiverem livres (PoinToPoint);– Podem se cadastrar para, quando houver novas mensagens,

receber notificação (pub/sub);

1111

Vantagens dos MOMs (2)• Desacoplamento

– Maior modularidade, maior reuso (substituibilidade), maior simplicidade, maior robustez

– Papéis bem definidos simplificam o desenvolvimento: produtor, consumidor e serviço tem única interface, independente da aplicação;

– Servidor de messaging é responsável pela qualidade do serviço ( não é preocupação dos componentes);

• Flexibilidade– API definida pelo tipo das mensagens ( e não por interfaces);– Meio comum é a mensagem: se componentes a entendem, o

resto (linguagens, plataformas, etc.) não importa!;– O elementos envolvidos na comunicação não se conhecem;

1212

Quando usar um MOM em vez de RMI/RPC?• ... ou, quando decidir por acoplamento mais fraco?

– Quando a comunicação se baseia mais no formato de mensagens que em interfaces rígidas ( componentes não dependem da interface de outros componentes);

– Quando a disponibilidade dos componentes é imprevisível, mas sua aplicação precisa rodar mesmo que componentes não estejam todos acessíveis;

– Quando for preciso suportar comunicação assíncrona: componente pode enviar informações para outro e continuar a operar mesmo sem receber resposta imediata;

5

1313

Java Message Service – JMS (1)• É um serviço para comunicação baseada em mensagens (ponto a

ponto ou pub/sub) através de MOMs;

• Provê uma interface Java única para unir as MOMs incompatíveis– JMS API: solução independente de fabricante para acessar serviços

MOM a partir de clientes Java;

• JMS API permite que aplicações criem, enviem, recebam e leiam mensagens através de um MOM– API consiste principalmente de interfaces ( implementadas pelo

fabricante do MOM)– Parte integral da plataforma J2EE (IPlanet e RI) ( acrescenta

possibilidade comunicação assíncrona a EJBs);

• Resumo das metas (segundo a especificação JMS)– Oferecer uma API simples, unificada e compatível com aplicações

existentes (não-JMS);– Suportar aplicações heterogêneas em diferentes SOs, plataformas,

arquiteturas;– Suportar mensagens contendo objetos serializados Java e arquivos

XML,...;

1414

Java Message Service – JMS (2)• Principais características

– Modelo flexível de desenvolvimento baseado em dois domínios: ponto-a-ponto e publish/subscribe;

– Controle de persistência, tempo de vida, prioridades e durabilidade associados a serviços e mensagens;

– Suporte à comunicação síncrona e assíncrona ;– Suporte a transações no envio e recebimento de mensagens– Roteamento seletivo através da filtragem de propriedades das

mensagens ( suporta subconjunto do SQL-92 usado para fazer queries em mensagens);

– Suportado por todos os servidores de aplicação J2EE ( implementam os dois domínios: PTP e pub/sub);

1515

Arquitetura JMS

6

1616

Domínio ptp (ponto-a-ponto)• Baseado no conceito de filas, remetentes e destinatários

– Um para um: cada mensagem é enviada para uma fila específica e é consumida por um destinatário ( que pode ou não estar disponível no momento);

– Destinatário confirma que a mensagem foi recebida e processada corretamente (acknowledgement);

– Filas retém mensagens até que sejam consumidas (ou expirem);

1717

Domínio pub/sub (publica/inscreve)

1818

Canais duráveis e não-duráveis• Cada mensagem enviada a um canal pode ter múltiplos

consumidores;– Mensagem permanece disponível até que todos os assinantes a

tenham retirado ou expirem;– Em canais não-duráveis assinante perde as mensagens

enviadas nos seus períodos de inatividade;

7

1919

Consumo de mensagens• Sistemas de messaging são sempre assíncronos no

sentido de que não há dependência quanto ao tempo de envio e recebimento das mensagens;

• JMS porém permite um tipo de sincronismo– Pode-se bloquear as operações em um destinatário até que uma

determinada mensagem chegue;

• O consumo pode ser: – Síncrona: quando o destinatário envia uma chamada receive() e

fica aguardando pelo recebimento de mensagens;– Assíncrona: o cliente registra-se como ouvinte de mensagens e

é notificado quando elas chegam;

2020

Desenvolvimento de aplicações JMS• Para escrever aplicações que

enviam ou recebem mensagens é preciso realizar uma série de etapas

– Obter um destino e uma fábrica de conexões via JNDI;

– Usar a fábrica para obter uma conexão;

– Usar a conexão para obter uma ou mais sessões;

– Usar a sessão para criar uma mensagem;

– Iniciar a sessão;

• Depois, pode-se– Enviar mensagens– Receber mensagens– Cadastrar ouvintes– receber mensagens

automaticamente

2121

Interfaces: dois domínios• É preciso escolher um domínio

– Para cada domínio há um destino, fábrica de conexões, conexão, sessão, produtor e consumidor;

– Interfaces são semelhantes;

8

2222

Objetos gerenciados• Destinos ( filas e tópicos) e fábricas de conexões

– São criados pelo provedor JMS e ligados a JNDI através de suas ferramentas administrativas. No J2EE-RI:

– > j2eeadmin -addJmsDestination queue/MinhaFila queue

• Para usar um objeto gerenciado– O cliente precisa obtê-lo através de uma consulta ( lookup) no serviço

de nomes JNDI;– Não há padronização do espaço de nomes (nomes default variam entre

fabricantes)

• Exemplo (obtenção de um destino do tipo Topic):– String nomeJRI ="jms/Topic"; //Default J2EE RI– String nomeJBoss ="topic/testTopic"; // Default JBossMQ

– Context ctx =new InitialContext();– Topic canal =(Topic) ctx.lookup(nomeJBoss);

2323

Há dois tipos de destinos JMS• Filas (Queue)

– Para comunicação PTP;– Retêm todas as mensagens que recebem até que sejam

retiradas ou expirem– Para cada mensagem enviada, apenas um cliente pode retirá-la

• Queue fila =(Queue) ctx.lookup("jms/Queue");

• Canais (Topic)– Para comunicação Pub/Sub;– Cada canal pode ter vários clientes assinantes;– Cada assinante recebe uma cópia das mensagens enviadas;– Para receber uma mensagem publicada em um canal, clientes

precisam já ser assinantes dele antes do envio;– Em canais "duráveis", assinantes não precisam estar ativos no

momento do envio. Retornando, receberão mensagens nao lidas;• Topic canal =(Topic) ctx.lookup("jms/Topic");

2424

Fábricas de conexões• Antes que se possa

– enviar uma mensagem para uma fila,– publicar uma mensagem em um canal,– consumir uma mensagem de uma fila ou– fazer uma assinatura de um canal

é preciso obter uma conexão ao provedor JMS.• Isto é feito através de uma fábrica de conexões. Há duas:

– TopicConnectionFactory - para conexões no domínio Topic– QueueConnectionFactory - para conexões no domínio Queue

• É preciso conhecer o nome JNDI – String nomeJRI =“ TopicConnectionFactory"; //default J2EE-RI– String nomeJBoss ="ConnectionFactory"; // JBossMQ

– Context ctx = new InitialContext();– TopicConnectionFactory factory =

(TopicConnectionFactory) ctx.lookup(nomeJBoss);

Precisa ser definido (geralmente arquivo jndi.properties no CPATH)

9

2525

Conexões• Encapsulam uma conexão virtual com o provedor JMS

– Suportam múltiplas sessões (threads)

• Uma vez obtida uma fábrica de conexões, pode-se obter uma conexão– QueueConnection queueCon =

queueConnectionFactory.createQueueConnection();– TopicConnection topicCon =

topicConnectionFactory.createTopicConnection();

• Quando for preciso encerrar a comunicação, é preciso fechar a conexão– O fechamento fecha todas as seções, produtores e consumidores

associados à conexão• queueCon.close();• topicCon.close();

2626

Sessões• Contexto onde se produz e se consome mensagens

– Criam produtores, consumidores e mensagens;– Processam a execução de ouvintes;– Single-threaded;

• Podem ser configuradas para definir – forma de acknowledgement;– uso ou não de transações (tratar uma série de

envios/recebimentos como unidade atômica e controlá-la via commit e rollback);

2727

Produtores de mensagens• Objeto criado pela sessão e usado para enviar

mensagens para um destino– QueueSender: domínio ponto-a-ponto– TopicPublisher: domínio pub/sub

• QueueSender sender = queueSession.createSender(fila);• TopicPublisher publisher =

topicSession.createPublisher(canal);

• Uma vez criado o produtor, ele pode ser usado para enviar mensagens;– send() no domínio ponto-a-ponto

• sender.send( message );– publish() no domínio pub/sub

• publisher.publish( message );

Durante o envio cliente pode definir qualidade do serviço como modo (persistente ou não), prioridade ( sobrepõe comportamento FIFO) e tempo de vida ( TTL)

10

2828

Envio e recebimento de mensagens

2929

Qualidade do Serviço• Persistência: Guaranteed Message Delivery (GMD)

– Mensagens persistem em banco de dados, arquivo, etc. até que seja enviada a um consumidor e ele confirme o correto recebimento;

• Variações de GMD (depende do fabricante)– Certified Message Delivery: não só garante a entrega como gera um

recibo de consumo enviado de volta ao criador da mensagem;– Store and Forward: permite que um produtor de mensagem envie uma

mensagem com sucesso a um sistema MOM inativo;

• Prioridades: 0 a 9– Uma fila FIFO para cada prioridade ( mensagens de prioridade maior

tomam a frente das de menor prioridade)

• Tempo de Vida (Time To Live)– No envio, pode-se definir o tempo (ms) de vida de uma mensagem;– Ela irá expirar quando o tempo chegar ao fim: 0 = sem expiração

3030

Consumidores de mensagens• Objeto criado pela sessão e usado para receber mensagens

– QueueReceiver e QueueBrowser: domínio ponto-a-ponto– TopicSubscriber: domínio pub/sub

• QueueReceiver receiver = queueSession.createReceiver(fila);• TopicSubscriber subscriber =

topicSession.createSubscriber(canal);

• É preciso iniciar a conexão antes de começar a consumir:– topicCon.start();

• Depois, pode consumir mensagens de forma síncrona ( método é o mesmo para domínios PTP e pub/sub– Message queueMsg = receiver.receive();– Message topicMsg = subscriber.receive(1000);

• Para consumir mensagens de forma assíncrona é preciso criar um MessageListener;

11

3131

MessageListener• É o Event handler que detecta o recebimento de mensagens. Para

usar, implemente MessageListener e seu método onMessage():public class MyListener implements MessageListener{

public void onMessage(Message msg) {TextMessage txtMsg =(TextMessage) msg;System.out.println( "Mensagem recebida: "txtMsg.getText() )

}}

• Método onMessage() não deve deixar escapar exceções– Código acima deve estar em um bloco try-catch;

• Para que objeto seja notificado, é preciso registrá-lo em um QueueReceiver ou TopicSubscriber– subscriber.setMessageListener( new MyListener() );– topicCon.start(); // iniciar a conexão

3232

Mensagens• Mensagens são compostas de três partes

– Propriedades ( opcionais): pares nome/valor (nomes e valores arbitrários definidos pela aplicação); contém tipos primitivos Java (int, boolean, etc.) ou String;

– Cabeçalhos: propriedades com nomes e tipos de valores padrão definidos na especificação JMS;

– Corpo: conteúdo que não pode ser representado através de propriedades;

• Os tipos de mensagem correspondem a formatos de dados armazenados no corpo de mensagem – Texto, objetos serializados, bytes, valores primitivos, etc.

• Mensagens são criadas a partir de uma Session

3333

Cabeçalhos e propriedades• Cabeçalhos: conjunto de propriedades (chave: valor)

definidas na especificação JMS e usadas pelo sistema para identificar e rotear mensagens;– Chaves começam com "JMS". Ex: JMSMessageID,

JMSDestination, JMSExpiration, JMSPriority, JMSType– A maioria são criadas automaticamente durante a chamada do

método de envio (dependem dos parâmetros do método)

• Propriedades definidas pelo programador– Pode guardar informações de conteúdo textual em mensagens

simples sem corpo (onde a mensagem consiste das propriedades);

– Usadas para qualificar a mensagem e permitir sua filtragem;– Úteis para preservar a compatibilidade com outros sistemas de

messaging;message.setStringProperty("Formato", "Imagem JPEG");

12

3434

Filtros (seletores) de mensagens• Consumidor pode especificar quais as mensagens que lhe

interessam através de expressões SQL;– Expressão deve retornar valor booleano;– Consiste de String passado como argumento de métodos

createReceiver() e createSubscriber();– Expressão é tipicamente usada para comparar valores de propriedades

de mensagens;– Consumidor só consome as mensagens em que propriedades, aplicadas

à expressão resultem verdadeiro;

• Exemplo

3535

Seis tipos de mensagens• Message

– Mensagem genérica sem corpo (contendo apenas cabeçalho e possíveis propriedades);

• TextMessage– Objeto do tipo String ( ex: conteúdo

XML)

• MapMessage– Conjunto de pares nome/valor onde

nomes são Strings e valores são tipos primitivos

• BytesMessage– Stream de bytes não interpretados

• StreamMessage– Seqüência de tipos primitivos Java

• ObjectMessage– Objeto Java serializado

3636

Criação de mensagens• Para cada tipo de mensagem, Session fornece método create();

– createMessage(), createTextMessage(), createBytesMessage(), createObjectMessage(), createMapMessage(),createStreamMessage()

• Após receber uma mensagem, via receive() ou onMessage(), é preciso fazer o cast para ter acesso aos métodos específicos de cada tipo de mensagem;

13

3737

OpenJMSOpenJMS• Point-to-Point and publish-subscribe messaging models• Guaranteed delivery of messages• Synchronous and asynchronous message delivery• Persistence using JDBC • Local transactions• Message filtering using SQL92-like selectors• Authentication• Administration GUI • XML-based configuration files • In-memory and database garbage collection• Automatic client disconnection detection• Applet support• Integrates with Servlet containers such as Jakarta Tomcat• Support for RMI, TCP, HTTP and SSL protocol stacks• Support for large numbers of destinations and subscribers

3838

Referências• [1] Kim Haase. The JMS Tutorial. Sun Microsystems,

2002; http://java.sun.com/products/jms/tutorial

• [2] Sun Microsystems. The Java Message ServiceSpecification;http://www.javasoft.com/products/jms/docs.html

• [3] Hapner, Mark; Burridge, Rich; Sharma, Rahul; Fialli, Joseph; haase, Kim. Java Message Service API Tutorial and Reference. Messaging for the J2EE Platform, Addison-Wesley, 2002.

• [4] http://openjms.sourceforge.net; Open SourceImplementation of Sun Microsystems's JMS Especification;

Wireless Access and Terminal Mobility in Wireless Access and Terminal Mobility in CORBA specificationCORBA specification

Vagner SacramentoVagner Sacramentovagner@lac.inf.puc-rio.br

Laboratory for Advanced Collaboration - LAC

Departamento de Informática - PUC-Rio

Rio de JaneiroRio de Janeiro--RJRJ

14

4040

SumárioSumário• Motivação

• Objetivos da Wireless CORBA

• Framework arquitetural

• Componentes Principais da Wireless CORBA

• Mobile IOR

• Protocolo de Tunelamento GIOP

• Handoff

• Conclusão

4141

MotivaçãoMotivação• Arquitetura CORBA forneça transparência de localização e de mobilidade dos objetos CORBA executando em terminais móveis;

• A transparência de localização seja estendida para o caso em que os objetos CORBA possam se mover durante o tempo de operação da aplicação.

Ponto de Acesso 1Ponto de Acesso 1Ponto de Acesso 2Ponto de Acesso 2

Rede Rede CabeadaCabeada

4º Andar do DI4º Andar do DI 5º Andar do DI5º Andar do DI

Estação clienteLES

Internet

4242

Princípios da Wireless CORBAPrincípios da Wireless CORBA• Transparência

Clientes que invocam operações em objetos servidores executando em terminais móveis não precisam estar ciente desta especificação;Objetos servidores na rede fixa não precisam estar ciente de que as requisições foram originadas a partir de terminais móveis;

• SimplicidadeEspecificar as funcionalidades mínimas para suportar aplicações CORBA móveis;Definir requisitos obrigatórios para prover suporte a mobilidade;Ser factível de implementação;Preservar a interoperabilidade com ORB estacionários;

• O modelo teve muita influência do projeto DOLMEN;

• Universidade de Helsinki implementou a maior parte desta especifição como uma extensão do MICO (MiWco)

15

4343

Por que não IP Móvel?Por que não IP Móvel?• “IP móvel provê transparência de mobilidade somente

para macro-mobilidade, e não para movimentos entre pequenas células;”

• “O HA é importante demais;”

• “Ele não provê facilidades de uso e gerenciamento dos protocolos da rede sem fio;”

• “Ele oculta todos eventos de handoff, portanto, dificulta ou impossibilita o uso de serviços baseado na localização;”

• A total transparência de mobilidade nem sempre é desejável por todas aplicações;

4444

Principais Componentes da Wireless CORBAPrincipais Componentes da Wireless CORBA• Mobile IOR identifica o terminal móvel onde o objeto servidor

se encontra;• Home Location Agent mantém um caminho da localização

corrente do terminal móvel;• Access Bridge é o ponto final de um túnel GIOP no lado da

rede fixa; Encapsula as mensagens a serem enviadas para a terminal bridge e desencapsula as mensagens GIOP recebidas da Terminal Bridge;

• Terminal Bridge é o ponto final do túnel GIOP no lado do terminal;

• Protocolo de Tunelamento GIOP é o meio para transmitir as mensagens entre a Terminal Bridge e a Access Bridge;

O GTP é um protocolo abstrato, independente do protocolo de transporte utilizado. Três protocolos de tunelamento concreto são especificados: TCP, UDP, e WAP (tunelamento WDP)

4545

Arquitetura de MobilidadeArquitetura de MobilidadeEncapsula, repassa ou ignora

mensagens GIOP/TCP (IIOP)Desencapsula e repassa as

mensagens do túnel GIOPGera eventos de mobilidadeLista os serviços disponíveis

Similar ao Access BridgeNão faz FORWARDGera eventos de mobilidadeEncapsula e desencapsula

mensagens GTP

GTP – Protocolo de tunelamentoGIOP abstrato;Protocolos concretos de

transporte tunelados TCP, UDP e WAPPermite somente um único túnel

GTP entre as Bridges

Conhece a Access Bridge que a TB está associadaRedireciona requisições para a

AB que o terminal está associado

Source: Telecom Wireless CORBA, OMG Document dtc/01-06-02

REDE Wireless

IIOPGTP

NamingNamingServiceService

16

4646

Comunicação na Arquitetura CORBA para R Sem FioComunicação na Arquitetura CORBA para R Sem Fio

ObjetoServidor

Terminal Bridge

ORB

Platform

Servidor MServidor Móóvelvel

Platform

Access BridgeRede

Wireless

RedeFIXA

Access Bridge

ORB ORB

Platform

Cliente Remoto na rede Cliente Remoto na rede fixafixa

GIOP Tunnel

IIOP

Cliente

Rede sem fioRede sem fio Rede Rede cabeadacabeada

4747

Mobile IORMobile IOR• Mobile IOR oculta a mobilidade do terminal no qual o objeto

servidor se encontra.

• Mobile IOR transparente para os clientes;

• Mobile IOR possui– Pelo menos um IIOP Profile (TAG_INTERNET_IOP)– Um único Mobile Terminal profile (TAG_MOBILE_TERMINAL_IOP)– IIOP::ProfileBodyMobileProfile::ProfileBodyComponentsComponents

• IIOP Profile no Mobile IOR identifica o HLA ou a AB atual (não o objeto servidor de destino)

– O mecanismo Location ForwardLocation Forward é utilizado para rotear as requisições da Access Bridge anterior ou do HLA para a Access Bridge atual.

4848

Mobile IORMobile IOR

• Contém um Mobile Terminal Profile (MTP);– Exclusivo para o GIOP com versão >= 1.2;– ORBs que implementam GIOP 1.0 e 1.1 não tem MTP. Estes devem

utilizar um object key no cabeçalho da requisição GIOP, contendo o terminal id, terminal object key;

• Utiliza a Access Bridge ou Home Location Agent no IIOP Profile;

17

4949

Mobile Terminal ProfileMobile Terminal Profilestruct ProfileBody {

Version mior_version; // version of Mobile IOR

octet reserved;

TerminalId terminal_id; // unique terminal identifier

TerminalObjectKey terminal_object_key; // object_key on terminal

sequence <IOP::TaggedComponent> components;

};

O Componente TAG_HOME_LOCATION_INFO identifica o HLA (no máximo uma instância deste componente). Possui o IOR encapsulado do HLA

5050

Access Bridge 1

Access Bridge 2

Home Location Agent

Naming

Service

MIOR MIOR –– TM1TM1 ––ObjectObject keykey

Rede Rede WirelessWirelessGTPGTP

LocationForward para AB1Ou

Object_Not_Exist

MIOR MIOR –– TM1TM1 ––IOR IOR FullFullNEEDS_ADDRESSING_MODE

TM1

IIOP

GIOP/TCP

5151

Access Bridge 1

Access Bridge 2

Home Location Agent

Naming

Service

Location Update

Rede Rede WirelessWirelessGTPGTP

MIOR MIOR –– TM1TM1

LocationForward para AB2Ou

Object_Not_Exist

NEEDS_ADDRESSING_MODE

MIOR MIOR ––TM1TM1 ––ObjectObject

keykey

TM1

Handoff

TM1TM1-IORfullIOR HLA

IIOP

GIOP/TCP

18

5252

Comunicação via WCORBAComunicação via WCORBA

Protocolo de Tunelamento GIOP Protocolo de Tunelamento GIOP -- GTPGTP

5454

Visão Geral do GTPVisão Geral do GTP• Um meio de transferir e tunelar mensagens de controle

entre uma Terminal Bridge e uma Access Bridge;

• Existe somente um único túnel GIOP entre uma dada Terminal Bridge e Access Bridge;

• Um comportamento de handoff aprimorado é definido de modo que a Terminal Bridge possa transferir suavemente o túnel GIOP da AB corrente para uma nova AB

– Se o terminal pode ter conectividades de transporte simultâneas a duas ABs, então a Terminal Bridge cria um novo túnel para uma nova AB antes de encerrar o túnel aberto anteriormente com a AB atual.

• Um túnel é compartilhado por todas conexões GIOP que o terminal está associado.

19

5555

Pilha de Protocolo de Tunelamento GIOPPilha de Protocolo de Tunelamento GIOP

Terminal ORB Access Bridge ORB entidade remota ORB

GIOP GIOPGIOP messages

TCPTCP TCP byte stream

IIOPIIOPIIOP messages

GTP adaptation layer GTP adaptation layer

transport transport

GTP GTPGTP msgs

ObjectCORBA invocations

Object

5656

Protocolo de Tunelamento GIOPProtocolo de Tunelamento GIOP–– 1/21/2• Ele deve ser mapeado sobre um ou mais protocolos

concretos;

• GTP assume que o protocolo de tunelamento concreto, disponha da mesma confiabilidade de transmissão das mensagens defina pelo GIOP;

• Esta especificação define três protocolos de tunelamento concreto: TCP, UDP e WAP (Tunelamento WDP).

5757

Protocolo de Tunelamento GIOP Protocolo de Tunelamento GIOP –– 2/22/2• As mensagens GTP são utilizadas para

– estabelecer, encerrar e restabelecer um túnel;– transmitir e repassar (forwarding) mensagens GIOP;– repassar mensagens GTP da/para AB antiga;

• Devido o handoff ter uma característica opcional, o GTP tem duas versões:

– 1.0 sem suporte a handoff– 2.0 com suporte a handoff

20

5858

GTP Message StructureGTP Message Structure

struct GTPHeader {unsigned short seq_no;unsigned short last_seq_no_received;octet gtp_msg_type;octet flags;unsigned short content_length;

};

GTPHeader GTPMessageBody

5959

Procedimentos de HandoffProcedimentos de Handoff• Suporte a handoff é um requisito opcional

• Três procedimentos diferentes:– Handoff inicializado pela Rede

• Iniciado por uma aplicação externa;– Handoff inicializado pela Terminal

• Executado quando o terminal descobre uma nova Acess Bridge;– Access Recovery

• Reconstituição de acesso na mesma Acess Bridge ou com uma nova AB;

6060

Procedimentos de HandoffProcedimentos de Handoff• O HLA é informado;

• As Acess Bridges são informadas para permitir o repasse das conexões abertas;

• Eventos de mobilidade são gerados no Visited Domain e no Terminal Domain;

21

6161

Handoff inicializado pela RedeHandoff inicializado pela Rede

6262

Handoff inicializado pela TerminalHandoff inicializado pela Terminal

TB old AB new AB

EstablishTunnelRequestEstablishment of transport connectivity

HLA

location_upadte

EstablishTunnelReply

handoff_in_progress

ReleaseTunnelRequest

ReleaseTunnelReply notify other ABs

DepartingTerminalNotificationHandoffNotification

ArrivingTerminalNotification

6363

Access RecoveryAccess Recovery 11

TB old AB new AB

EstablishTunnelRequestEstablishment of transport connectivity

HLA

location_upadte

EstablishTunnelReply

recovery_request

notify other ABs

DepartingTerminalNotificationHandoffNotification

ArrivingTerminalNotification

Retransmissions thru the new Access Bridge

22

6464

Access Access RecoveryRecovery 22

6565

HandoffHandoff no meio de uma requisição do terminal no meio de uma requisição do terminal móvelmóvel

O protocolo GIOP requer que as respostas sejam enviadas através das mesma conexão GIOP da requisição

Interfaces para repasse de msgsentre a antiga e nova Access Bridges: gtp_to_terminal(), gtp_from_terminal;

A AB corrente utiliza a msgGTPFoward para enviar a msg GTP para o terminal. O terminal tbresponde uma GTPFoward para esta comunicação

6666

HandoffHandoff no meio de uma requisição de um cliente no meio de uma requisição de um cliente na rede fixana rede fixa

23

6767

ConclusãoConclusão

• A especificação provê mecanismos fundamentais para dar suporte amobilidade de terminais utilizando aplicações CORBA;

• A especificação resolve os problemas da gerência de mobilidade, mas não propõe nada em relação ao problema da limitação computacional;

• As características principais da especificação são: Mobile IOR que oculta a mobilidade de objetos servidores CORBA em terminais móveis e o GTP que possibilita o handoff e repasse de mensagens;

• Existe uma extensão do MICO (MIwCO – MICO is Wireless CORBA) que implementa todos requerimentos obrigatórios definidos pela especificação. Este é um excelente ponto de partida para testar a eficiência dos recursos definidos na especificação;

6868

ReferênciasReferências• [1] – OMG. Request for Information on Wireless Access and Mobility

in CORBA, OMG Document telecom/98-06-04, June 1998;

• M. Liljeberg, K. Raatikainen, M. Evans, S. Furnell, N. Maumon, E. Veltkamp, B. Wind, and S. Trigila: Using CORBA to SupportTerminal Mobility. In Proc. of the TINA'97 Conference (Nov, 1997; Santiago de Chile), IEEE Computer Society Press, 59-67;

• [4] Wireless Access and Terminal Mobility in CORBA. Adoptedsepecification. OMG Document dtc/01-06-02, June 2001.

• DOLMEN (EC/ACTS Project AC036), Implementation of anEnhanced Distributed Processing Platform for DOLMEN, DeliverableMP3, April 1997;

• Black, Currey, Kangasharju, Lansio, Raatikainen Wireless Access and Terminal Mobility in CORBA White Paper, 2001;