Agenda - JMS. Introdução. Vagner Sacramento. Laboratory for Advanced Collaboration - LAC Departamento de Informática - PUC-Rio

Transcrição

1 Java Message Service JMS e Wireless CORBA Specification - WCORBA Vagner Sacramento vagner@lac.inf.puc-rio.br 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

2 O que é 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 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/ 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

3 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

4 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

5 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 13 XML,...; 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

6 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

7 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

8 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 TopicConnectionFactory factory = jndi.properties no CPATH) (TopicConnectionFactory) ctx.lookup(nomejboss); 24

9 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

10 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

11 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

12 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 Stream de bytes não interpretados StreamMessage Seqüência de tipos primitivos Java ObjectMessage Objeto Java serializado 35 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; 36

13 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; [2] Sun Microsystems. The Java Message Service Specification; 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, [4] Open Source Implementation of Sun Microsystems's JMS Especification; 38 Wireless Access and Terminal Mobility in CORBA specification Vagner Sacramento Laboratory for Advanced Collaboration - LAC Departamento de Informática - PUC-Rio Rio de Janeiro-RJ

14 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 Estação cliente LES Ponto de Acesso 2 Rede Cabeada Ponto de Acesso 1 4º Andar do DI 5º Andar do DI 41 Princí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; Simplicidade Especificar 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) 42

15 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 Conhece Encapsula, repassa ou ignora Similar ao a Access Bridge GTP que Protocolo a de tunelamento TB mensagens GIOP/TCP (IIOP) Não estáfaz associada FORWARDGIOP abstrato; Redireciona Desencapsula e repassa as Gera eventos requisições de mobilidade Protocolos para a concretos de AB mensagens do túnel GIOP Encapsula que o terminal e desencapsula está transporte associado tunelados TCP, UDP e Gera eventos de mobilidade mensagens GTP WAP Listaosserviçosdisponíveis Permite somente um único túnel GTP entre as Bridges GTP IIOP Naming Service REDE Wireless Source: Telecom Wireless CORBA, OMG Document dtc/

16 Comunicação na Arquitetura CORBA para R Sem Fio Servidor MóvelM Access Bridge Cliente Remoto na rede fixa Objeto Servidor ORB Access Bridge Rede Rede Wireles FIXA s Cliente Terminal Bridge ORB ORB Platform Platform Platform GIOP Tunnel Rede sem fio IIOP Rede cabeada 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 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

17 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 MIOR TM1 NEEDS_ADDRFull MIOR TM1 Object key Location Access Bridge 1 ESSING_MOD E Forward para AB1 Ou Object_Not_ Exist Home Location Agent Access Bridge 2 IIOP GIOP/TCP 50 Naming Service TM1- MIOR IOR TM1 NEEDS_ADDRES Object IOR MIOR TM1 SING_MODE full HLA key Access Bridge 1 Rede Wireless GTP TM1 Location Forward para AB2 Ou Home Location Agent Location Update Access Bridge 2 Handoff Object_Not _Exist TM1 IIOP GIOP/TCP 51

18 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

19 Pilha de Protocolo de Tunelamento GIOP Object CORBA invocations Object GIOP GTP GTP adaptation layer transport GTP msgs GIOP messages GTP GTP adaptation layer transport IIOP TCP IIOP messages TCP byte stream GIOP IIOP TCP Terminal ORB Access Bridge ORB entidade remota ORB 55 Protocolo de Tunelamento 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

20 GTP Message Structure GTPHeader GTPMessageBody struct GTPHeader { unsigned short unsigned short octet octet unsigned short }; seq_no; last_seq_no_received; gtp_msg_type; flags; 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

21 Handoff inicializado pela Rede 61 Handoff inicializado pela Terminal TB old AB new AB HLA Establishment of transport connectivity EstablishTunnelRequest ReleaseTunnelRequest ReleaseTunnelReply HandoffNotification EstablishTunnelReply handoff_in_progress notify other ABs DepartingTerminalNotification location_upadte ArrivingTerminalNotification 62 Access Recovery 1 TB old AB new AB HLA Establishment of transport connectivity EstablishTunnelRequest HandoffNotification EstablishTunnelReply recovery_request notify other ABs DepartingTerminalNotification location_upadte ArrivingTerminalNotification Retransmissions thru the new Access Bridge 63

22 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

23 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/ , 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/ , June 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