§ Departamento de Informática

1、 Departamento de InformticaMJaco Integra?o do Multicast IP na Arquitetura CORBA Alysson Neves Bessani*, Joni da Silva Fraga* e Lau Cheuk Lung* Laboratrio de Controle e Microinformtica (LCMI) DAS CTC UFSCCampus Universitrio Caixa Postal 476 Trindade - CEP 88040-900 Florianpolis SC Brasile-mail: neves

2、,fragalcmi.ufsc.brDepartamento de InformticaFaculdade de Cincias da Universidade de LisboaBloco C5, Campo Grande, 1749-016 Lisboa Portugale-mail: laudi.fc.ul.ptResumoEste artigo apresenta nossas experincias na integra?o do MIOP (Multicast Inter-ORB Protocol) em um ORB que segue as especifica?es da O

3、MG.O modelo proposto para essa integra?o permite a coexistncia de duas pilhas de protocolos distintas (IIOP/TCP/IP e MIOP/UDP/IP multicast), possibilitando um mais amplo espectro de suporte de protocolos aos modelos de comunica?o de objetos distribudos. Esse modelo de integra?o discutido neste texto

4、, evidenciando a conformidade de nossa abordagem com as especifica?es CORBA.No sentido de avaliar o MJaco, foram realizados vrios testes envolvendo aspectos de interoperabilidade, desempenho e escalabilidade. Os resultados obtidos mostram que n?o h uma perda acentuada de eficincia com o nosso modelo

5、 de integra?o. Alm disso, o Mjaco traz as vantagens da programa?o de objetos distribudos s aplica?es que antes se limitavam ao uso de sockets UDP e outras interfaces de mais baixo nvel.Palavras chave: IP Multicast, Middleware, Protocolos de Comunica?o, SistemasAbertos.AbstractThis paper presents our

6、 experiences for integrating OMG MIOP (Multicast Inter-ORB Protocol) specifications into an ORB. We proposed a model of integration which allows the coexistence of two different protocol stacks (IIOP/TCP/IP and MIOP/UDP/IP multicast), making possible a wider spectrum ofmiddleware support for distrib

7、uted objects communication. That integration modelis discussed in this paper, giving evidence of the accordance of our approach withthe CORBA specifications. In order to evaluate that integration, differents tests were made considering the interoperability, performance and scalability aspects.The ob

8、tained results show that there is not a significant loss of performance withthat integration model, which brings the advantages of the objects distributed programming for applications that before were limited to the UDP sockets and other lower-level interfaces.Keywords: IP Multicast, Middleware,Inte

9、rnet Protocol, Open Systems.1. Introdu?oA arquitetura CORBA (Common Object Request Broker Architecture OMG01) introduzida pela OMG (Object Management Group1), corresponde nos dias de hoje as mais bem sucedidas especifica?es de middleware para suporte a sistemas de objetos distribudos. O principal co

10、mponente desta arquitetura o ORB (Object Request Broker) que entre outras coisas implementa as semanticas de comunica?o definidas na arquitetura. As mensagens geradas nas comunica?es seguem uma sintaxe de transferncia prpria: o General Inter ORB Protocol (GIOP). Esta sintaxe torna as mensagens envol

11、vidas nas comunica?es independentes das implementa?es de ORBs e das conseqncias de um ambiente heterogneo. O mapeamento do GIOP sobre o TCP/IP concretizado atravs do IIOP, Internet Inter ORB Protocol.O IIOP, seguindo as caractersticas do TCP, foi definido para comunica?es ponto a ponto. Apesar da co

12、mbina?o IIOP TCP/IP corresponder a uma boa solu?o para comunica?es que seguem este modelo abordando aspectos como controle de erro, ordena?o FIFO, etc. muitos outros paradigmas de comunica?o quando implementados sobre estes protocolos n?o aproveitam as caractersticas dos nveis mais baixos da rede. O

13、 reflexo desta dificuldade sempre recai em custos no desempenho destas comunica?es.Muitas aplica?es distribudas dependem de abstra?es como grupos de objetos ou da necessidade da dissemina?o de dados entre vrios hosts da rede. Estas aplica?es necessitam de um melhor aproveitamento dos servi?os de uma

14、 rede. Assim, em 1999 a OMG publicou um RFP (Request For Proposal) onde definia uma srie de requisitos para um servi?o de multicast n?o confivel que deveria ser suportado pelo multicast IP. O multicast IP compreende um conjunto de extens?es ao protocolo IP que o habilita na concretiza?o de comunica?

15、es multiponto Dee86. Este protocolo se caracteriza pela ausncia de garantias e pelo alto desempenho, especialmente em redes locais. Vrias s?o as aplica?es que utilizam multicast IP, principalmente nas reas de multimdia.Em 2001, como resposta a RFP, duas propostas foram submetidas a OMG: a primeira v

16、inha da Inprise (antiga Borland) e a outra foi desenvolvida por um conjunto de empresas e institui?es de pesquisa, dentre as quais destacam-se a Eternal Systems, IONA, Object Oriented Concepts e a University of California, Santa Barbara. Esta segunda proposta foi a vencedora e se tornou a base das e

17、specifica?es a serem homologadas pela OMG em meados de 2002. Como conseqncia destes esfor?os de padroniza?o, surgiu ent?o o MIOP (Multicast Inter-ORB Protocol) OMG01b, protocolo responsvel pelo mapeamento do GIOP sobre a pilha UDP/multicast IP. O MIOP o elemento chave para tornar disponvel um servi?

18、o de multicast n?o confivel em suportes CORBA de objetos distribudos.A introdu?o do paradigma de grupo em padr?es abertos tem sido alvo de vrios trabalhos de pesquisa e propostas de padroniza?o Dee85, Dee86, Mel90,Ren95,OMG01b, Mos01, Bar01. Prover suporte de grupo a aplica?es distribudas envolve um

19、a combina?o de protocolos que tratam do gerenciamento de grupo (membership), detec?o de falhas, transferncia de estado e comunica?o de grupo. Dentro da OMG, essas abstra?es est?o sendo padronizadas separadamente, os trs primeiros s?o tratados nas especifica?es FT-CORBA OMG00. Todavia, a OMG ainda n?

20、o tem publicado uma especifica?o para a comunica?o de grupo na arquitetura CORBA que atenda, por exemplo, diferentes nveis de garantias nas vrias vers?es possveis deste paradigma. A OMG est tratando deste problema em etapas. O primeiro passo foi a cria?o de um grupo de trabalho para definir a especi

21、fica?o do suporte para multicast n?o confivel o modelo menos restritivo de comunica?o de 1 entidade formada por mais de 1000 institui?es que visa promover a tecnologia de orienta?o a objetos.grupo. Essa iniciativa dever motivar a publica?o de outras RFPs, no sentido da concep?o de suportes a comunic

22、a?o de grupo que forne?am tambm garantias mais restritivas de acordo e ordena?o (por exemplo, multicast confivel, ordem FIFO, causal, total, etc) .O objetivo neste artigo apresentar as nossas experincias na integra?o do MIOP em um ORB que segue as especifica?es da OMG. O nosso modelo de integra?o di

23、scutido neste texto, evidenciando a conformidade de nossa abordagem com as especifica?es CORBA. Este trabalho parte do projeto GroupPac(www.lcmi.ufsc.br/grouppac) que corresponde a um conjunto de objetos de servi?o desenvolvidos com a finalidade de facilitar a implementa?o de aplica?es distribudas t

24、olerantes a faltas. No GroupPac devem conviver as duas pilhas de protocolos IIOP/TCP/IP e MIOP/UDP/multicast IP possibilitando um mais amplo espectro de suportes de protocolos aos modelos de comunica?o de objetos distribudos.No sentido de avaliar nossos trabalhos nesta integra?o, foram realizados vr

25、ios testes envolvendo aspectos de interoperabilidade, desempenho e escalabilidade em nossa implementa?o. Neste artigo, apresentamos um estudo comparativo que realizamos com o nosso servi?o de multicast n?o confivel, baseado na pilha MIOP/UDP/multicast IP, e o uso de sockets UDP para comunica?o multi

26、cast IP que prtica corrente em aplica?es de multimdia, por exemplo. Os resultados obtidos mostram que h uma perda de eficincia com o nosso modelo de integra?o, mas que compensada pelas vantagens da programa?o de objetos distribudos em aplica?es que antes se limitavam ao uso de sockets UDP e outras i

27、nterfaces de mais baixo nvel.O artigo apresenta na se?o 2 uma descri?o sucinta do multicast IP. Aspectos da especifica?o descrevendo o MIOP e as estruturas necessrias a nvel de ORB para suportar multicast n?o confivel s?o apresentados na seqncia, na se?o 3. Na se?o 4, introduzido o nosso modelo de i

28、ntegra?o do MIOP que procura preservar as duas pilhas de protocolos: uma para comunica?es ponto a ponto e outra multiponto. Detalhes de implementa?o do nosso servi?o de multicast n?o confivel e da integra?o do MIOP s?o descritos na se?o 5. Na se?o 6, s?o apresentados e discutidos alguns testes no no

29、sso ORB multicast. A se?o 7 cita alguns trabalhos relacionados e, finalmente, na se?o 8, s?o levantadas as conclus?es finais deste trabalho.2. Multicast IPO conjunto de extens?es adicionadas ao protocolo IP para o suporte comunica?o multiponto chamado de multicast IP (RFCs 966 Dee85 e 988 Dee86). A

30、partir deste servi?o possvel enviar um pacote IP a um conjunto de hosts, denominado de grupo. Cada grupo de hosts identificado por um endere?o IP (semelhante a um endere?o de host2). Quando o destino de um datagrama um grupo, feita uma tentativa de entrega a todos os hosts membros do mesmo, entretan

31、to, a exemplo do unicast IP n?o existe qualquer garantia a respeito desta entrega. Ou seja, este servi?o n?o confivel n?o fornece garantias quanto 2 Quanto ao endere?amento, o multicast IP define que cada grupo deve ser identificado por um endere?o IP classe D (que come?a com 1110 e vai de

32、 a 55) associado a ele, desta forma, para um emissor enviar um datagrama a um grupo, basta que ele defina o endere?o IP do grupo no campo destino do datagrama IP. Um outro ponto importante sobre o endere?amento de grupos a tradu?o de endere?os multicast IP para endere?os de enlace. Este

33、 servi?o, que executado pela camada de enlace, deve permitir em uma rede Ethernet, por exemplo, o mapeamento de endere?os multicast IP para endere?os multicast Ethernet. Para redes que n?o suportam multicast (em nvel de enlace) os endere?os multicast IP devem ser mapeados para endere?os de broadcast

34、 (atingindo todos os ns da rede local), com os descartes possveis nos hosts que n?o pertencerem ao grupo.entrega dos pacotes a todos os membros do grupo ou integridade dos pacotes; aspectos de ordem tambm n?o s?o garantidos.As especifica?es do multicast IP definem dois tipos de grupos: grupos perman

35、entes e grupos temporrios. Os grupos permanentes est?o sempre presentes e n?o precisam ser criados, j os grupos temporrios devem ser criados e duram enquanto houver processos pertencentes a estes. Os grupos definidos no multicast IP s?o grupos abertos no sentido que um emissor n?o pertencente ao gru

36、po pode enviar mensagens ao mesmo. Alm disso, n?o existem informa?es a respeito de quais s?o os membros de um grupo, no sentido global. Cada host sabe a que grupo pertence, porm desconhece os outros membros.O gerenciamento dos membros de um grupo feito de maneira dinamica, de tal forma que a associa

37、?o de endere?os IP a hosts seja bastante flexvel. Assim, um host pode pertencer a um ou mais grupos, ou a nenhum grupo em determinado momento. Esta associa?o dinamica realizada atravs das trs opera?es de gerenciamento, que o mdulo IP deve prover. Estas opera?es s?o mostradas na tabela 1. Note que n?

38、o existe opera?o para destrui?o de grupos. O que se justifica pelo fato de grupos permanentes n?o poderem ser destrudos e grupos temporrios s existirem enquanto seu nmero de membros maior que zero.As opera?es de gerenciamento s?o implementadas atravs do protocolo IGMP, Internet Group Management Prot

39、ocol Dee86, utilizado na comunica?o entre os hosts de uma rede local com o agente multicast. Toda rede que suporta multicast IP deve conter pelo menos um agente multicast ativo que, usualmente implementado no gateway da rede, a entidade responsvel pela cria?o e manuten?o de grupos bem como pela troc

40、a de mensagens no contexto da Internet. Cada agente multicast deve saber quais grupos tem membros em sua rede.3. Modelo de Objetos MIOP e o Suporte de Multicast N?o ConfivelO modelo atual de objetos CORBA (pilha IIOP/TCP/IP) especifica que uma referncia de objeto3 deve corresponder a uma nica implem

41、enta?o. Alm disso, a semantica de invoca?o do CORBA tem tratamento de erro que adiciona confiabilidade em rela?o entrega e, tambm, ordena?o FIFO de mensagens que podem ser definidas com ou sem espera de resposta.A entrega de mensagens GIOP via servi?o multicast n?o-confivel define um contexto de com

42、unica?o completamente diferente do citado acima. O objetivo nas especifica?es MIOP (Multicast Inter-ORB Protocol) prover mecanismos para o multicast n?o-confivel entre objetos distribudos. Estes mecanismos se reduzem necessidade de estruturas possibilitando o mapeamento de mensagens GIOP em pacotes

43、IP, e alguma forma de gest?o consistente de grupos em nvel de objetos distribudos.3Um identificador de objeto tambm chamado de referncia ou IOR (Interoperable Object Reference) pe?a fundamental na arquitetura CORBA. nico no espa?o do sistema e interopervel, atravessando diferentes implementa?es de O

44、RBs. Esta estrutura uma espcie de ponteiro que liga o stub cliente a implementa?o do objeto no servidor.Na gest?o em nvel de objetos, necessrio que se introduza a no?o de grupo e de seu correspondente identificador (referncia de grupo). Esta gest?o simplificada: como n?o existem requisitos de confia

45、bilidade no MIOP, n?o necessrio um servi?o de membership no sentido de se ter conhecimento de quantos e quem s?o os membros do grupo.Na verdade um grupo de objetos no MIOP consiste em informa?es sobre como acess-lo atravs da rede. Estas informa?es est?o contidas na estrutura UIPMC_ProfileBody, dispo

46、nvel a partir da referncia de grupo (figura 1). O perfil UIPMC difere do tradicional perfil IIOP presente em IORs de objetos simples nos seguintes pontos:? N?o existe chave de objeto4;? O endere?o IP do host do perfil IIOP substitudo no UIPMC por um campoque deve conter um endere?o de multicast IP,

47、ou um alias deste endere?o.A ausncia de chaves e endere?os de hosts de objetos neste perfil pertinente: este servi?o de comunica?o n?o confivel foi definido sob a premissa da n?o existncia de membership (n?o s?o conhecidos quantos e quem s?o os membros do grupo). Mesmo assim, possvel a partir do per

48、fil UIPMC chegar a um objeto membro do grupo nos POAs (Portable Object Adapter5) disponveis em hosts receptores da mensagem.Este cenrio bem mais complexo do que o dos perfis IIOP, que identificam unicamente uma implementa?o de interface. Alm de informa?es de vers?o do protocolo, do endere?o IP e a p

49、orta que o grupo atende, o perfil UIPMC contm tambm uma srie de componentes como, por exemplo, um perfil IIOP para envio de requisi?es que necessitam de resposta (o MIOP definido para requisi?es oneway) e uma estrutura, a TagGroupTaggedComponent, que contm informa?es como a vers?o do grupo, o id do

50、domnio e o id do grupo6. Este ltimo componente obrigatrio e deve sempre estar presentes nos perfis UIPMC.Alm do perfil UIPMC (obrigatrio), uma IOR de grupo pode possuir opcionalmente um ou mais perfis IIOP de gateways para serem utilizados por clientes que n?o suportam multicast IP.Uma IOR de grupo

51、usada ent?o, basicamente, em trs tipos de invoca?es:? A um gateway IIOP, nos casos em que o cliente, atravs de seu ORB, n?o capaz de realizar multicast;? A servidores que suportam o MIOP, implementam a mesma interface e pertencem ao mesmo grupo;? A um membro do grupo em servidor IIOP que deve respon

52、der a opera?es two-way.A figura 1 apresenta a estrutura completa de uma IOR de grupo, com os perfis UIPMC e IIOP de gateway e de objeto membro.Conforme j citado, o perfil UIPMC n?o define chaves de objetos para o acesso a membros de um grupo. Assim, um POA deve utilizar as informa?es associadas ao g

53、rupo (id, domnio e vers?o) definidas no perfil UIPMC para identificar os membros locais do grupo.4 A chave de um objeto (ObjectKey) o identificador do objeto dentro do ORB, ela utilizada, juntamente como endere?o IP e a porta do ORB, na localiza?o da implementa?o de um objeto.5 Componente do ORB res

54、ponsvel pelo registro e ativa?o de objetos, bem como pelo encaminhamento das mensagens recebidas a estes.6 A mesma fun?o do ObjectKey no IIOP desempenhada pelo id de grupo no perfil UIPMC.Esta associa?o entre grupos e implementa?es de membros locais requer uma nova tabela interna ao POA. Esta tabela

55、, chamada Mapa de Grupos Ativos, define para as informa?es de grupo de um UIPMC o conjunto de implementa?es correspondentes, acessveis a partir do adaptador. Desta forma, a inclus?o de membros a grupos feita sempre localmente atravs de chamadas aos POAs ativados no ORB. A fim de que o POA permita a

56、associa?o de implementa?es de objetos a referncias de grupo, as especifica?es do MIOP prevem quatro novas opera?es para a interface PortableObject:POA. Estas opera?es permitem associar e desassociar implementa?es registradas a referncias de grupos; bem como, listar que implementa?es pertencem a dete

57、rminado grupo no POA ?fornecendo com isto uma espcie de servi?o de membership local.O pequeno trecho de cdigo em Java da figura 2, mostra a associa?o de uma implementa?o de objeto a uma referncia de grupo.Figura 2 - Associa?o no POA de uma IOR de grupo com uma implementa?o de objeto.Nas linhas de 1

58、a 4 na figura 2, referncias ao ORB e ao POA s?o obtidas e ativadas.A seguir, nas linhas de 5 a 7, uma referncia a um grupo criada atravs de uma URL codificada no mecanismo corbaloc7. Esta URL define um perfil UIPMC para o grupo e um perfil IIOP para opera?es com resposta. Note que nesta URL est?o descritas informa?es a respeito dos endere?os a