Java Message Service - PUC-Rio

Java Message Service – JMS
e
Wireless CORBA Specification - WCORBA
Vagner Sacramento
[email protected]
Laboratory for Advanced Collaboration - LAC
Departamento de Informática - PUC-Rio
Agenda - JMS
•
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
2
Introduçã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);
3
1
O que é Messaging?
Messaging?
• 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);
4
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
implementações proprietárias ( e incompatíveis);
tempo
em
• 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/
5
Por que “Messaging
”?
“Messaging”?
• 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.
6
2
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;
7
Messaging vs. RMI/RPC
• Sistema de Messaging com
paradigma pub/sub
• JMS
• Sistema RMI/RPC (Java RMI ou
CORBA)
• WCORBA
8
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.
9
3
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);
10
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;
11
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;
12
4
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,...;
13
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);
14
Arquitetura JMS
15
5
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);
16
Domínio pub/sub (publica/inscreve)
17
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;
18
6
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;
19
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
20
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;
21
7
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);
22
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");
23
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
Precisa
ser
definido
– Context ctx = new InitialContext();
(geralmente
arquivo
jndi.properties no CPATH)
– TopicConnectionFactory factory =
(TopicConnectionFactory) ctx.lookup(nomeJBoss);
24
8
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();
25
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);
26
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)
27
9
Envio e recebimento de mensagens
28
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
29
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;
30
10
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
31
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
32
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");
33
11
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
34
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
•
StreamMessage
•
ObjectMessage
– Stream de bytes não interpretados
– Seqüência de tipos primitivos Java
– Objeto Java serializado
35
Criação de mensagens
• Para cada tipo de mensagem, Session fornece método create();
– createMessage(),
createTextMessage(),
createObjectMessage(), createMapMessage(),
createStreamMessage()
createBytesMessage(),
• 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;
36
12
OpenJMS
•
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
37
Referências
• [1] Kim Haase. The JMS Tutorial. Sun Microsystems,
2002; http://java.sun.com/products/jms/tutorial
• [2] Sun Microsystems. The Java Message Service
Specification;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
Source
Implementation
of
Sun
Microsystems's
JMS
Especification;
38
Wireless Access and Terminal Mobility in
CORBA specification
Vagner Sacramento
[email protected]
Laboratory for Advanced Collaboration - LAC
Departamento de Informática - PUC-Rio
Rio de JaneiroJaneiro-RJ
13
Sumário
• Motivação
• Objetivos da Wireless CORBA
• Framework arquitetural
• Componentes Principais da Wireless CORBA
• Mobile IOR
• Protocolo de Tunelamento GIOP
• Handoff
• Conclusão
40
Motivaçã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.
Internet
Rede Cabeada
Estação cliente
LES
Ponto de Acesso 2
4º Andar do DI
Ponto de Acesso 1
5º Andar do DI
41
Princípios da Wireless CORBA
• Transparência
9Clientes que invocam operações em objetos servidores executando em terminais
móveis não precisam estar ciente desta especificação;
9Objetos servidores na rede fixa não precisam estar ciente de que as requisições
foram originadas a partir de terminais móveis;
• Simplicidade
9Especificar as funcionalidades mínimas para suportar aplicações CORBA
móveis;
9Definir requisitos obrigatórios para prover suporte a mobilidade;
9Ser factível de implementação;
9Preservar 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)
42
14
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;
43
Principais 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)
44
Arquitetura de Mobilidade
Encapsula,
repassa ou ignora
ŒŒConhece
a Access
a
ΠSimilar ao
AccessBridge
Bridge–que
ŒGTP
Protocolo
de tunelamento
mensagens
GIOP/TCP (IIOP)
TB
estáfaz
associada
Œ Não
FORWARDGIOP abstrato;
Œ
Desencapsula
e
repassa
as
ŒRedireciona
requisições
para a concretos de
ΠGera eventos
de mobilidade
ŒProtocolos
mensagens
do túnel
GIOP
AB
que o terminal
está
associado
ΠEncapsula
e desencapsula
transporte
tunelados TCP, UDP e
ΠGera eventos de mobilidade
mensagens GTP
WAP
Œ Lista os serviços disponíveis
ŒPermite somente um único túnel
Naming
GTP entre as Bridges
Service
GTP
IIOP
REDE
Wireless
Source: Telecom Wireless CORBA, OMG Document dtc/01-06-02
45
15
Comunicação na Arquitetura CORBA para R Sem Fio
Servidor Mó
Móvel
Cliente Remoto na rede
fixa
Access Bridge
Objeto
Servidor
Cliente
Access Bridge
Rede
Wireles
s
ORB
Terminal Bridge
Rede
FIXA
ORB
Platform
ORB
Platform
GIOP
Tunnel
Platform
IIOP
Rede
cabeada
Rede sem fio
46
Mobile 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::ProfileBodyComponents
Components
• IIOP Profile no Mobile IOR identifica o HLA ou a AB atual
(não o objeto servidor de destino)
– O mecanismo Location Forward é utilizado para rotear as requisições da
Access Bridge anterior ou do HLA para a Access Bridge atual.
47
Mobile 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;
48
16
Mobile Terminal Profile
struct 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
49
Naming
Service
Rede Wireless
GTP
TM1
Access Bridge
1
MIOR – TM1 –
NEE
TM1 –
IOR –Full
D _AMIOR
ESLSocS
atioDnObject
DR key
G_M
FoIN
rw
O
E ard D
para
AB
1
Home Location
Ou
Agent
Obje
ct_N
o
t_
Exist
Access Bridge
2
IIOP
GIOP/TCP
50
Rede Wireless
Naming
Service
TM1MIOR –
TM1 –
IOR
Object
NEEDS_ADDRES
IORfull
Æ
HLA
key
SING_MODE
MIOR – TM1
Locatio
Forwa n
rd
para A
B2
Ou
Object_
No
_Exist t
Home Location
Agent
GTP
TM1
Access Bridge
1
Handoff
Location
Update
Access Bridge
2
TM1
IIOP
GIOP/TCP
51
17
Comunicação via WCORBA
52
Protocolo de Tunelamento GIOP - GTP
Visã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.
54
18
Pilha de Protocolo de Tunelamento GIOP
CORBA invocations
Object
Object
GIOP messages
GIOP
GIOP
GTP
GTP
msgs
GTP adaptation layer
transport
Terminal ORB
GTP
GTP adaptation layer
transport
IIOP
TCP
IIOP messages
TCP byte stream
Access Bridge ORB
IIOP
TCP
entidade remota ORB
55
Protocolo de Tunelamento GIOP–
GIOP– 1/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).
56
Protocolo de Tunelamento GIOP – 2/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
57
19
GTP Message Structure
GTPHeader GTPMessageBody
struct GTPHeader {
unsigned short seq_no;
unsigned short last_seq_no_received;
octet
gtp_msg_type;
octet
flags;
unsigned short content_length;
};
58
Procedimentos 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;
59
Procedimentos 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;
60
20
Handoff inicializado pela Rede
61
Handoff inicializado pela Terminal
old AB
TB
new AB
Establishment of transport connectivity
EstablishTunnelRequest
HLA
location_upadte
handoff_in_progress
EstablishTunnelReply
ArrivingTerminalNotification
ReleaseTunnelRequest
ReleaseTunnelReply
HandoffNotification
notify other ABs
DepartingTerminalNotification
62
Access Recovery 1
old AB
TB
new AB
Establishment of transport connectivity
EstablishTunnelRequest
HLA
location_upadte
recovery_request
EstablishTunnelReply
notify other ABs
HandoffNotification
ArrivingTerminalNotification
DepartingTerminalNotification
Retransmissions thru the
new Access Bridge
63
21
Access Recovery 2
64
Handoff no meio de uma requisição do terminal
móvel
O protocolo GIOP requer que as
respostas sejam enviadas através
das mesma conexão GIOP da
requisição
Interfaces para repasse de msgs
entre a antiga e nova Access
Bridges:
gtp_to_terminal(),
gtp_from_terminal;
A AB corrente utiliza a msg
GTPFoward para enviar a msg GTP
para o terminal. O terminal tb
responde uma GTPFoward para
esta comunicação
65
Handoff no meio de uma requisição de um cliente
na rede fixa
66
22
Conclusão
• A especificação provê mecanismos fundamentais para dar suporte a
mobilidade 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;
67
Referê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 Support
Terminal 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. Adopted
sepecification. OMG Document dtc/01-06-02, June 2001.
• DOLMEN (EC/ACTS Project AC036), Implementation of an
Enhanced Distributed Processing Platform for DOLMEN, Deliverable
MP3, April 1997;
• Black, Currey, Kangasharju, Lansio, Raatikainen Wireless Access
and Terminal Mobility in CORBA White Paper, 2001;
68
23