JORGE OLIVEIRA DE SOUZA

GERENCIAMENTO DE REDES USANDO CORBA

Belm Par Universidade da Amaznia UNAMA 1999

GERENCIAMENTO DE REDES USANDO CORBA

JORGE OLIVEIRA DE SOUZA

Monografia apresentada ao II Curso de Especializao em Redes de Computadores da Universidade da Amaznia como requisito para obteno do ttulo de especialista.

Belm Par Universidade da Amaznia UNAMA

1999 GERENCIAMENTO DE REDES USANDO CORBA

JORGE OLIVEIRA DE SOUZA

Avaliada por : _______________________________________

Data : _______/______/________

Belm Par Universidade da Amaznia UNAMA

1999

RESUMO
A crescente complexidade e heterogeneidade das redes de comunicao atuais esto empurrando a pesquisa e a indstria para a busca de novas formas de gerenciamento dessas redes. Observa-se que os trabalhos nessa rea apresentam um conjunto de caractersticas comuns que norteiam essa busca: flexibilidade; simplicidade; interoperabilidade com os sistema legados; modelo nico para operao e gerenciamento; padronizao. Alm disso, a tendncia cada vez maior da distribuio dos sistemas computacionais associada a adoo dos modelos dos sistemas distribudos orientados a objetos tambm tm influenciado grandemente os novos mtodos de gerenciamento de redes. Nesse panorama, a arquitetura CORBA tem se colocado particularmente numa posio de destaque. Nos trabalhos atuais, a principal discusso em foco a forma de como fazer os mapeamentos de sistemas legados (SNMP e CMIP) promovendo sua convivncia com a arquitetura CORBA, e, considerando o mtodo usado para esse mapeamento, pode-se classificar os trabalhos que usam CORBA para o gerenciamento de redes em duas categorias: 1) Mapeamento esttico : aqueles cujo enfoque est voltado para a traduo esttica do GDMO/ASN.1 para gerar o cdigo que ser includo pelo gerente de aplicaes e que portanto saber, em tempo de compilao, a extenso de classes que podero ser manuseadas. Estes trabalhos esto fundamentados basicamente nos modelos propostos pelo XoJIJM; 2) Mapeamento dinmico: aqueles que esto livres da dependncia de saber, no momento da compilao, a extenso das classes que sero tratadas, uma vez que eles fazem uso de cadeias de caracteres (strings) ou de metadados. Estes esto fundamentados basicamente pelas pesquisas desenvolvidas na Universidade de Zrich (Generic Object Model GOM) e Universidade de Berne (CORBA-Liaison). Neste trabalho sero abordadas as principais caractersticas das arquiteturas envolvidas e como se faz a interao entre os modelos propostos com os sistemas legados. Assim sendo, ser apresentado um panorama geral dos principais trabalhos nesta rea e identificar as vantagens e desvantagens das vrias propostas comparativamente umas com as outras.

LISTA DE FIGURAS

2.1.1. Elementos do OMA........................................................... 2.1.2. Viso geral da Arquitetura CORBA................................... 2.1.3. Esquema de envio de requisies pelo ORB...................... 2.1.4. Estrutura bsica do ORB.................................................... 2.1.5. Relacionamento de protocolos entre ORBs........................

13 15 15 16 19

2.2.1. Paradigma gerente-agente Modelo OSI........................... 21 2.2.2. Exemplo de ASN.1............................................................. 23 2.2.3. Exemplo de GDMO............................................................ 25 2.3.1. Macro ASN.1...................................................................... 27 2.4.1 Elementos da Arquitetura Yasmin....................................... 29 3.2.1. XoJIDM Specification Translation..................................... 3.2.2. Arquitetura do Interaction Translation do XoJIDM.......... 3.2.3. Gateway CORBA->SNMP................................................. 3.2.4. Gateway SNMP->CORBA................................................. 34 35 37 39

3.3.1. Generic Object Model......................................................... 40 3.3.2. Arquitetura GOM................................................................ 41 3.3.3. Plataforma de execuo GOMscript................................... 43 3.4.1. Liaison e Java/C++............................................................. 3.4.2. Interfacer CL para CMIP e SNMP..................................... 3.4.3. Interface DSOMInformation.............................................. 3.4.4. Uso da interface DSOM...................................................... 3.4.5. GOMscript.......................................................................... 44 46 47 48 50

SUMRIO

1. INTRODUO..................................................................................... 04 1.1.Motivao........................................................................................ 04 1.2.Definies e consideraes afins..................................................... 06 2. VISO GERAL DAS ARQUITETURAS CONSIDERADAS............. 11 2.1. CORBA............................................................................................ 11 2.2. Modelo de gerncia OSI (CMIP)..................................................... 21 2.3. Modelo de gerncia SNMP.............................................................. 26 2.4. A Arquitetura Yasmin...................................................................... 28 3. USANDO CORBA NO GERENCIAMENTO DE REDES................... 33 3.1. Gerenciamento Interdomnios.......................................................... 33 3.2. Propostas do XoJIDM...................................................................... 34 3.3. Generic Object Model GOM........................................................ 39 3.4. CORBA-Liaison.............................................................................. 44 4. CONSIDERAES FINAIS................................................................. 51 BIBLIOGRAFIA CONSULTADA........................................................... 53

1. INTRODUO 1.1. Motivao Antes do anos 70 os sistemas computacionais estavam baseados principalmente em mainframes com sistemas operacionais proprietrios com administrao e gerncia centralizadas. Com o crescimento dos sistemas operacionais UNIX no final dos anos 70 e o aparecimento dos computadores pessoais (Personal Computers - PCs) iniciou-se um processo de descentralizao da capacidade de processamento e se comeou a interconectar os vrios computadores na forma de redes locais ( Local Area Networks - LANs) e redes de longas distncias ( Wide Area Networks - WANs). Paralelamente a descentralizao dos recursos computacionais ocorreu tambm a descentralizao do modo de gerenciamento. Em 1978, a International Standards Organization (ISO) iniciou um esforo para desenvolver padres para o gerenciamento de redes. A inteno era criar um padro de gerenciamento de redes em cima do seu prprio modelo Open Systems Interconnection (OSI) sob a forma de um protocolo comum de gerenciamento, o Common Management Information Protocol (CMIP). Por conta da lentido dos processos de padronizao, a complexidade inerente a proposta apresentada como padro pela ISO e a necessidade urgente de ferramentas de gerenciamento, a comunidade de padronizao da Arquitetura TCP/IP props o Simple Network Management Protocol (SNMP). Inicialmente o SNMP foi considerado como um meio temporrio de gerenciamento at que o padro OSI fosse consolidado. Porm o que se verificou nos anos seguintes foi que o SNMP acabou se tornando um padro de-facto por causa da sua grande disseminao, conseqncia, em grande parte, de sua simplicidade. Hoje, apesar do SNMP ser vastamente utilizado, ele est comeando a se tornar limitado para as tarefas que lhe so exigidas. Por causa dessas novas exigncias uma nova verso foi desenvolvida, o SNMPv2.

Apesar da nova verso contemplar uma srie de exigncias para o gerenciamento de redes, sua aceitao no mercado no tem sido to rpida quanto foi a adoo da primeira verso. Por razes at histricas sempre houve uma diviso entre as ferramentas para o ambiente operacional ( por exemplo RPC, XDR, DNS, etc.) e as ferramentas para o ambiente de gerenciamento (por exemplo SNMP e CMIP) dos sistemas conectados em rede. Com o advento dos modelos de sistemas computacionais distribudos orientados a objetos ( por exemplo CORBA, ANSA, Java e DCOM), esforos de unificao esto sendo feitos para que se possa gerenciar e operacionalizar os sistemas ligados em rede utilizando-se o mesmo modelo. Alm do mais, as tarefas de gerenciamento de sistemas distribudos no podem ser centralizadas por conta do prprio modelo distribudo. Existem fortes indicaes de que CORBA tende a se tornar uma importante tecnologia para implementao tanto de entidades que gerenciam como de entidades gerenciadas. Genilloud apud Ban(1997) argumenta que "os objetos distribudos constituem portanto o paradigma que permitir ao gerenciamento de sistemas convergir para uma nica, homognea e global arquitetura de gerenciamento". Apesar de todo esse panorama orientado a objetos se desenhando no horizonte no se pode esquecer que no mundo real existe uma variedade de sistemas legados na rea de gerenciamento de redes. Em particular, as companhias envolvidas com telecomunicaes investiram quantias significativas nos padres de gerenciamento OSI e dificilmente migrariam para uma nova tecnologia, CORBA por exemplo, sem uma garantia de preservar seus investimentos j realizados. Alm disso, muito improvvel que algum dia venha a existir um modelo nico de gerenciamento. Isto significa que as companhias tero que conviver com o gerenciamento de um ambiente heterogneo no qual os recursos podero estar representados por diferentes modelos de objetos.

Assumindo que CORBA atingir um lugar de destaque no mundo de gerenciamento de redes e sistemas de comunicao, sem entretanto domin-lo totalmente, deve-se observar ao longo do prazo de sua consolidao o surgimento de tradutores sintticos e semnticos (tambm conhecindos como gateways) entre CORBA e outros modelos com o propsito de se gerenciar os sistemas legados a partir da CORBA ou ainda acessar a CORBA a partir de sistemas legados.
O objetivo deste trabalho fazer uma abordagem das principais propostas que visam a integrao dos mundos CORBA, SNMP e CMIP.

1.2 Definies e consideraes afins.

Ao se referir a gerenciamento de redes em ambientes computacionais distribudos forosamente ter que se fazer uso de definies e consideraes sobre protocolos, interfaces, modelos orientados a objetos, objetos propriamente ditos dentre outras definies afins. Assim sendo, a seguir sero apresentadas algumas definies e consideraes pertinentes que devem nortear os tpicos que sero abordados neste trabalho. 1.2.1. Gateways

Gateways so sinttica e semanticamente tradutores que permitem que aplicaes em um determinado modelo possam ter acesso a outro modelo como se tratasse de um nico modelo ocultando as diferenas entre eles.

1.2.2. Sistemas Distribudos Comparativamente aos sistemas no distribudos, os sistemas distribudos normalmente oferecem uma melhor relao custo - beneficio; integram-se melhor a aplicaes essencialmente distribudas; permitem a implementao, confiabilidade e flexibilidade maior e ainda podem crescer gradualmente de acordo com as necessidades das organizaes. Porm os sistemas distribudos apresentam aspectos que merecem ateno especial: O software naturalmente mais complexo; Eventuais gargalos nas comunicaes podem causar degradao no sistema; Existe sempre uma predisposio a problemas relacionados segurana.
6

Nos sistemas distribudos um ponto chave a ser considerado o conceito de transparncia que consiste na tcnica de esconder a distribuio do sistema tanto dos usurios quanto dos programas de aplicao.

1.2.3. Objetos Um objeto uma unidade computacional que tem um comportamento bem definido e atributos compartilhados. Esses atributos do sustentao ao efeito do comportamento. Requisies feitas a um objeto so chamadas de mensagens ou mtodos. Objetos podem suportar mais de um mtodo. A poro visvel de um objeto chamada de interface. Uma interface para um objeto o protocolo ( de mensagens ) usada para se solicitar seus servios. As interfaces coletivamente definem o comportamento do objeto. Uma interface de um objeto consiste do nome do objeto e o seu conjunto de mtodos vlidos. Mtodos consistem de duas partes : a assinatura e a implementao. Uma assinatura consiste de: um nome para o mtodo (operao), nomes e tipos dos seus parmetros juntamente com os valores de retorno e excees. Uma implementao de um mtodo o cdigo que executado para produzir a operao desejada.

1.2.4. Protocolos e Interfaces A viso que um cliente tem de um sistema distribudo pode ser em nvel de protocolo (CMIP, SNMP) ou o protocolo pode ficar oculto e apenas as interfaces dos objetos estarem visveis aos clientes. As ltimas investigaes nessa rea definem objetos sem levar em considerao o protocolo de suporte ficando a cargo do construtor definir um protocolo que os clientes efetivamente usaro na comunicao. claro que um cliente interagindo com um objeto remoto atravs de sua interface far uso de um protocolo para requisies mas esse fato deve ficar oculto do cliente proporcionando dessa

forma um alto nvel de abstrao, e a abstrao uma grande ferramenta para se reduzir a complexidade na resoluo de problemas. O software em ambientes distribudos ( e consequentemente seu desenvolvimento tambm ) se torna mais e mais complexo e nesse contexto a habilidade de se poder trabalhar com nveis de abstrao cada vez maiores se torna cada vez mais importante.

1.2.5. Modelo Orientado a Objetos

A programao procedural ( ou estruturada) faz uma clara separao entre a lgica do programa ( funcionalidade, cdigo) e estado ( estrutura, dados ). Com o advento da programao orientada a objetos esta separao foi eliminada e dados e cdigo passaram a ser encapsulados para formar uma unidade computacional (objetos). As principais caractersticas da programao orientada a objetos so :

Encapsulao : dados e cdigo esto juntos em uma mesma unidade computacional;

Herana : novos objetos podem ser criados a partir de objetos j definidos herdando seus dados e cdigo acrescentando novos dados e operaes.

Polimorfismo : dependendo do tipo de objeto a mesma mensagem pode produzir diferentes comportamentos.

1.2.6. Interfaces e Implementaes As linguagens utilizadas na construo sistemas computacionais distribudos orientados a objetos podem ser classificadas em duas categorias principais : aquelas que so puramente linguagens de descrio de interfaces e linguagens que permitem tanto a descrio quanto a implementao de sistemas distribudos. As linguagens de descrio de interface tipicamente especificam um sistema pela definio do nmero de classes e servios que oferecem (operaes) e suas variveis de cada instncia (com um determinado tipo). Estas linguagens no so, do ponto de vista computacional,

completas pois no se pode efetivamente implementar as especificaes feitas nelas. Forosamente, uma especificao escrita numa linguagem de especificao ter que traduzida para uma linguagem de implementao para poder ser efetivamente implementada. A principal vantagem de se usar uma linguagem de especificao pura que se pode criar especificaes independentes da linguagem na qual ela ser implementada, isto , qualquer linguagem poder ser usada na implementao. Outro ponto que conta a favor dessas linguagens o fato de permitirem projetos mais enxutos sem a necessidade de se considerar nesse momento detalhes de implementao. Uma desvantagem que fatalmente tero que ser mapeadas para uma linguagem de implementao o que acarreta algum tipo de converso e isto propicia perda de informao. Exemplos de linguagens de especificao so Remote Procedure Call Language (RPCL), CORBA Interface Definition Language (IDL), GDMO e ASN.1. Uma linguagem de implementao completa do ponto de vista computacional pois pode ser usada tanto para a especificao como para a implementao de sistemas. Como exemplos temos Smaltalk, C++ e Java. Muitos modelos de objetos para sistemas distribudos so baseados em linguagens de especificao para definir as interfaces do sistema e depois se faz o mapeamento para uma linguagem de implementao.

1.2.7. Componentes de software. Os estudos relativos a componentes de software constituem ainda um campo bastante novo e ainda no atingiu a maturidade necessria. Alguns problemas advm do fato de ainda no existir uma definio nica para o termo componentes de software. A mais abrangente a de Deri(1997) que define componentes como sendo uma entidade de software com abstrao esttica com plugues bidirecionais. A palavra esttica reala o fato de que componentes so entidades de vida longa que podem ser armazenados numa base de dados de software

independente das aplicaes que proventura os usam. A abstrao significa a que o componente protege o software do mundo exterior que ele encapsula atravs da colocao um limite obscuro em volta dele. Os plugues so os canais de comunicao do componente com o mundo exterior ( mensagens, portas, etc.). O termo bidirecional enfatiza o fato de que um componente pode se comunicar com outros componentes e vice-versa. Se a condio bidirecional no for verificada ento trata-se de um mero plug-in e no de um componente. De acordo com a definio de Deri(1997), um componente pode ser desde uma classe interativa ou at mesmo um gerenciador de dados de um recurso multimdia. Portanto para melhor se especificar e comparar diferentes componentes necessrio classific-los de acordo com a sua granulometria. Essa classificao se d em dois tipos: componentes de granulometria fina e componentes de granulometria grossa. A linha divisria dessas duas categorias de componentes diz respeito as propriedades desses componentes. Um componente dito de granulometria fina se apresenta uma das seguintes propriedades : O componente precisa de outro componente para se tornar utilizvel; Supondo que o componente est codificado em uma linguagem compilada, ento ele tem que ser distribudo em forma de cdigo fonte para poder ser utilizvel. Um componente que no satisfaz pelo menos uma das duas propriedades acima chamado de componente de granulometria grossa.

1.2.8. Droplets Um droplet um componente de software que tem as seguintes caractersticas: Ele carregado em tempo de execuo e no ligado estaticamente aplicao; Ele pode ser substitudo ( isto , uma nova verso de um droplet pode entrar no lugar de uma mais antiga) em tempo de execuo sem a necessidade de se parar a aplicao. Como

10

os droplets podem ser substitudos em tempo de execuo, eles so os responsveis pelo armazenamento e recuperao das informaes persistentes mantidas por eles. Ele tem uma interface bem definida que faz com que seja possvel a comunicao com outros droplets independente do tipo de servio que disponibiliza. Ele reentrante, ou seja, pode processar requisies de forma concorrete. A implementao desta caracterstica total responsabilidade do desenvolvedor que deve sempre garantir que o cdigo do droplet seja reentrante.

2. VISO GERAL DAS ARQUITETURAS CONSIDERADAS.

2.1. CORBA A heterogeneidade inerente aos sistemas distribudos , em tese, a forma de se obter a melhor combinao possvel entre software e hardware que melhor se ajusta a cada uma das diversas partes de uma corporao. Quando os padres certos para a interoperabilidade e a portabilidade entre os vrios componentes esto disponveis, a integrao desses componentes gera um sistema computacional coerente e altamente operacional. Alm da heterogeneidade, uma outro aspecto de peso nos sistemas distribudos o uso de modelos orientados a objetos. Infelizmente lidar com heterogeneidade em sistemas computacionais distribudos raramente uma tarefa fcil. Em particular, o desenvolvimento de software adequado para fazer uso eficiente de sistemas computacionais distribudos ainda um desafio grande. Existem muitas interfaces de programao e pacotes disponveis que facilitam o desenvolvimento para plataformas nicas e homogneas no entanto poucas existem para lidar com ambientes heterogneos distribudos.

11

Para buscar solues nessa rea, foi criado em 1989 o Object Mangement Group (OMG) com o intuito de fomentar, desenvolver, adotar e promover padres para o desenvolvimento e disponibilizao de aplicaes em ambientes distribudos. O OMG desenvolveu um modelo conceitual chamado de Object Magement Architecture (OMA) sobre o qual aplicaes podem ser construdas. O ncleo do OMA o Object Request Broker que um barramento comum de comunicao para os objetos. A tecnologia adotada na especificao dos ORBs conhecida como Common Object Request Broker Architecture (CORBA) que especifica a infra-estrutura para a comunicao transparente entre os objetos das aplicaes. A CORBA foi a primeira especificao adotada pelo OMG. A ltima verso conhecida como CORBA2 e foi adotada no final de 1994.

2.1.1. Object Management Architecture - OMA O OMA composto por quatro elementos principais: ORB (Object Request Broker), permite aos objetos enviarem e receberem requisies e, da mesma maneira, receberem respostas a suas requisies, de forma transparente em um sistema distribudo. O ORB a fundao para se construir aplicaes, utilizando objetos distribudos, com caractersticas de

interoperabilidade entre aplicaes em ambientes heterogneos ou homogneos; Servios de Objetos (Object Services), uma coleo de servios (interfaces e objetos) que suportam funes bsicas para usar e implementar objetos; Facilidades Comuns (Common Facilities), uma coleo de servios que muitas aplicaes podem compartilhar, mas que no so to fundamentais como os servios de objetos. Interfaces de domnios (Domain Interfaces) o elemento que faz um papel similar aos Servios de Objetos e s Facilidades Comuns porm so orientados a um
12

domnio especfico. Por exemplo, domnio das telecomunicaes, medicina, financeiro, etc. Podem existir vrios domnios de aplicaes separados Interfaces de Aplicaes (Application Interfaces), correspondem noo tradicional de aplicaes de usurios que, por esse motivo, no so padronizados pelo OMG. O OMG no desenvolve aplicaes, apenas especificaes. A Figura 2.1.1 d uma idia geral da estrutura e dos elementos que compe o OMA.

Figura 2.1.1 - Elementos do OMA

2.1.2. Object Request Broker - ORB Objetos clientes requisitam servios s implementaes de objetos atravs de um ORB (Figura 2.2.1). O ORB responsvel por todos os mecanismos requeridos para encontrar o objeto, preparar a implementao de objeto para receber a requisio, e executar a requisio. O cliente v a requisio de forma independente de onde o objeto est localizado, em qual linguagem de programao ele foi implementado, ou qualquer outro aspecto que no est refletido na interface do objeto.
13

CORBA utiliza a OMG IDL (Interface Definition Language) como uma forma de descrever interfaces, isto , de especificar um contrato entre os objetos (Figura 2.1.2). OMG IDL uma linguagem puramente declarativa baseada em C++. Isso garante que os componentes em CORBA sejam auto-documentveis, permitindo que diferentes objetos, escritos em diferentes linguagens, possam interoperar atravs das redes e de sistemas operacionais (Figura 2.1.3). Uma definio de interface escrita em OMG IDL define completamente a interface e especifica cada parmetro da operao. importante ressaltar que os objetos no so escritos em OMG IDL, que uma linguagem puramente descritiva. Eles so escritos em linguagens que possuem mapeamentos definidos dos conceitos existentes em OMG IDL. O OMG especificou os mapeamentos para C, C++ e Smalltalk, e existem estudos para se adicionar outras linguagens nas futuras verses de CORBA.

Figura 2.1.2. Viso geral da Arquitetura CORBA

14

Figura 2.1.3. Esquema de envio de requisio atravs do ORB.

A Figura 2.1.4 mostra a estrutura de um ORB, com as setas indicando o fluxo de chamadas que podem ocorrer de clientes para o ORB, e do ORB para as implementaes de objetos. Para fazer uma requisio, um cliente pode usar a Interface de Invocao Dinmica (DII Dynamic Invocation Interface) ou um Stub de IDL. Para algumas poucas e determinadas funes, um cliente pode interagir diretamente com a interface do ORB. A interface do ORB oferece funes que so independentes do adaptador de objetos utilizado, como, por exemplo, funes que executam algumas operaes sobre referncias de objetos. O fato de permitir tanto a invocao dinmica quanto a esttica, torna CORBA bastante flexvel. Orfali apud Montez(1997) argumenta que invocao esttica, que utiliza Stubs de IDL que podem ser gerados automaticamente atravs de pr-compiladores, possui uma srie de vantagens sobre a invocao dinmica : mais fcil de programar, faz verificao de tipos mais robusta, executa mais rpido e auto-documentvel. J a invocao dinmica permite a adio de novos servios s implementaes de objetos sem alteraes nos clientes. Dessa forma, os clientes podem descobrir em tempo de execuo quais so os servios oferecidos. A invocao dinmica possvel atravs dos servios do Repositrio de Interfaces. Um Repositrio de Interfaces uma base de dados que contm interfaces OMG IDL, e seus servios basicamente permitem o acesso, armazenamento e atualizao dessas interfaces.

15

Figura 2.1.4 . Estrutura Bsica do ORB

importante ressaltar que do ponto de vista da implementao de objetos, no se pode fazer distino entre uma requisio feita estaticamente e a feita de forma dinmica, j que ambas respeitam a mesma semntica da requisio. Uma requisio consiste de uma referncia de objeto, uma operao e uma lista de parmetros. Ao receber uma requisio, o ORB localiza o cdigo da implementao transmite parmetros e transfere o controle para a implementao do objeto. Quando a requisio completada, o controle e os valores de sada so retornados ao cliente. De forma parecida ao que ocorre na requisio de um cliente, o ORB pode invocar a implementao de objeto atravs de um Esqueleto de IDL Esttico ou Dinmico. A Interface de Esqueleto de IDL Dinmica (DSI - Dynamic Skeleton Interface) uma forma de se enviar requisies de um ORB para uma implementao de objetos que no possui informaes sobre a implementao do objeto em tempo de compilao. O cliente que invoca um objeto, no pode determinar se a implementao est usando um esqueleto de um tipo especfico ou DSI para conectar a implementao ao ORB. DSI til em solues de interoperabilidade implementando pontes entre diferentes ORBs, e para suportar linguagens de tipos dinmicos, como LISP.

16

Para executar a requisio, a implementao de objeto pode obter alguns servios do ORB atravs do Adaptador de Objetos. O Adaptador de Objetos se situa no topo dos servios de comunicao do Ncleo de ORB. Ele fornece o ambiente para instnciar objetos, atribu-los referncias de objetos, e passar requisies a eles. Com um adaptador de objetos, possvel a uma implementao de objeto ter acesso a um servio independente de ele estar implementado no Ncleo do ORB. Se o Ncleo de ORB oferecer o servio ento o adaptador simplesmente fornece uma interface para ele, caso contrrio, o adaptador deve implement-lo no topo do Ncleo de ORB. O conceito de adaptador de objetos necessrio para permitir que CORBA suporte uma grande diversidade de aplicaes, com variados tipos e estilos de implementaes de objeto. Se os servios do adaptador de objetos fossem oferecidos diretamente pelo ncleo do ORB, seria necessria a existncia de uma gama muito grande de mtodos na interface do ORB para atender todas as demandas dos variados tipos de servios existentes. No necessrio que todos adaptadores de objetos ofeream a mesma interface ou funcionalidade. Algumas implementaes de objeto podem ter requisitos especiais, exigindo adaptadores de objetos especficos. Dessa forma, a implementao do objeto pode escolher qual adaptador de objetos utilizar dependendo de quais tipos de servios ele requer. Entretanto, com o objetivo de tentar conter uma proliferao interminvel de tipos de adaptadores de objetos, o OMG definiu o Adaptador de Objetos Porttil (POA - Portable Object Adapter). A especificao do POA define um adaptador de objetos que pode ser usado pela maioria de objetos que possuem implementaes convencionais. Para localizar e ativar implementaes de objetos, um ORB se utiliza de Repositrios de Implementaes. Esses repositrios servem para armazenar informaes adicionais associadas com implementaes de ORBs, tais como, informaes de depurao, controles administrativos, segurana, dentre outras.

17

A especificao de interfaces de objetos obrigatoriamente em OMG IDL, garante a portabilidade dos objetos atravs de diferentes linguagens, ferramentas, sistemas operacionais e redes. Entretanto, a caracterstica de interoperabilidade entre objetos s foi coberta na verso 2.0 do CORBA, introduzida em dezembro de 1994. Isso se deu atravs da especificao de uma arquitetura de interoperabilidade, um suporte para pontes entre ORBs, um protocolo para comunicao entre ORBs genrico e um protocolo para comunicao entre ORBs para Internet. A arquitetura de interoperabilidade do CORBA identifica claramente a regra de diferentes tipos de domnios para informao especfica de ORBs. Tais domnios podem incluir domnios de referncias de objeto, domnios de tipos, domnios de segurana, dentre outros. Quando dois ORBs esto no mesmo domnio, eles podem se comunicar diretamente. Entretanto, quando a informao em uma invocao deve deixar seu domnio, a invocao deve atravessar uma ponte. A regra de uma ponte deve assegurar que o contedo e a semntica sejam mapeados adequadamente de um ORB para outro. O suporte para ponte entre ORBs pode tambm ser usado para prover interoperabilidade com outros sistemas no CORBA. O protocolo entre ORBs genrico (GIOP - Generic Inter-ORB Protocol) especifica uma sintaxe de transferncia padro e um conjunto de formatos de mensagens para comunicao entre ORBs. O protocolo entre ORBs para Internet (IIOP - Internet Inter-ORB Protocol) especifica como mensagens GIOP so trocadas usando conexes TCP/IP. Ele especifica um protocolo de interoperabilidade padro para Internet. O relacionamento entre GIOP e IIOP similar ao mapeamento existente entre o OMG IDL e uma linguagem especfica: o GIOP pode ser mapeado em diferentes protocolos e transportes, e especifica os elementos de protocolo que so comuns a todos os mapeamentos. Entretanto, o GIOP no fornece uma completa interoperabilidade, da mesma forma que IDL no pode ser usada para se construir programas completos. O IIOP, e outros mapeamentos similares para

18

diferentes protocolos de transportes, so realizaes concretas das definies abstratas de GIOP (Figura 2.1.5). Porm o GIOP pode no ser o protocolo mais adequado para determinados propsitos, por exemplo para a comunicao envolvendo outro sistema distribudos no CORBA. Para esses propsitos foram especificados a famlia de protocolos ESIOP (Environment Specific Inter-ORB Protocols). O primeiro ESIOP especificado baseado no DCE ( Distribuited Computing Environment) e denominado de DCE-CIOP (DCE Common Inter-ORB Protocol).

Figura 5. Relacionamentos de protocolos entre ORBs.

2.1.2. Servios CORBA O ORB, por si s, no executa todas as tarefas necessrias para os objetos interoperarem. Ele s fornece os mecanismos bsicos. Outros servios necessrios so oferecidos por objetos com interface IDL, que a OMG vem padronizando para os objetos de aplicao poderem utilizar.

Servio de nomes: basicamente um servio de localizao de objetos, que permite um objeto descobrir outros objetos atravs de identificadores, ou nomes.

Servio de controle de concorrncia: fornece um gerente de "locks" que coordena mltiplos acessos a recursos compartilhados, permitindo resoluo de conflitos de acesso.

19

Servio de eventos: permite que objetos registrem dinamicamente seus interesses em determinados eventos. Possibilitando uma forma de comunicao pouco acoplada e assncrona entre objetos. Eventos so enviados e recebidos atravs de um canal de eventos.

Servio de tempo: especifica uma interface de servio de tempo que permite, basicamente, os objetos das aplicaes obterem o tempo atual e executarem comparaes com o tempo. Servio de tempo tambm estende o servio de eventos, especificando uma interface de servios de eventos temporizados. Esse novo servio gerencia objetos manipuladores de eventos temporizados. Um cenrio tpico de utilizao desses servios um usurio criar um canal de eventos e registr-lo como destino dos eventos gerados por um manipulador de eventos temporizados. Dessa forma, o usurio pode usar o objeto manipulador de eventos temporizados para criar eventos temporizados quando desejar. Basicamente, o servio de eventos temporizados permite que um objeto possa "ligar" o tempo para disparo do evento (indicando inclusive que esse disparo pode ser peridico). Permite tambm que um objeto que recebeu a notificao de um evento, possa determinar o tempo em que o evento ocorreu.

2.2. Modelo de gerncia OSI ( CMIP )

2.2.1. Arquitetura O modelo de gerenciamento de redes OSI foi definido num esforo conjunto da ISO e ITU-T que resultou na srie de padres X.7xx. O enfoque proposto nesses padres consiste em colocar um agente prximo a fonte de informaes relevantes a serem

monitoradas/gerenciadas.

20

Um agente mantm informaes ( na forma de instncias de objetos gerenciados) sobre o estado de uma particular parte da rede pela qual ele responsvel. Consultas ou mudanas no estado da rede pelo gerente tm que ser enviadas apenas para o agente e no diretamente para os objetos (Figura 2.2.1).

Figura 2.2.1. Paradigma gerente-agente - Modelo OSI O protocolo usado para interagir com o agente o Common Management Information Protocol (CMIP). Um gerente pode enviar mensagens e receber respostas utilizando este protocolo para se comunicar com os agentes. Um agente pode tambm enviar informaes no solicitadas de forma assncrona para o gerente, isto , para notific-lo de algum problema no caso da ocorrncia de alguma falha ou situao de exceo. O Common Management Information Service Entity (CMISE) especifica 7 tipos requisies que definem a interao entre gerente e agente : M-CREATE - usada para adicionar informaes de gerenciamento para serem mantidas/monitoradas pelo agente: M-DELETE : remove informaes de gerenciamento do agente; M-SET : muda informaes no agente; M-GET : recupera informaes do agente; M-CANCEL-GET : cancela o envio de informaes do agente para o gerente solicitadas com o M-GET;
21

M-ACTION : permite especificar operaes nos objetos gerenciados que no podem ser realizadas atravs das semnticas mais simples do M-GET e M-SET.

M-EVENT-REPORT : permite aos agentes enviarem mensagens no solicitadas pelos gerentes quando alguma situao anormal ocorrer no objeto gerenciado.

2.2.2. Modelo de Objetos As informaes a serem gerenciadas por um agente so modeladas como objetos gerenciados. Um objeto gerenciado ( Managed Objetct - MO) pode ser tanto um recurso lgico como a conta de um usurio ou ainda um recurso real do tipo um chaveador ATM. Um recurso pode ser mapeado em muitos objetos gerenciados e muitos recursos podem ser mapeados para um nico objeto. Um objeto gerenciado contm atributos, aes e notificaes. Um atributo modela alguns estados de um recurso ( por exemplo, o nmero IP de uma interface de um roteador ou ainda o endereo de um cliente). Uma ao pode, por exemplo, ser a adio de uma nova entrada na tabela de rotas (atributo) de um determinado objeto gerenciado que nesse caso seria um roteador. Notificaes so mensagens que podem ser enviadas de um objeto gerenciado para seu agente que por sua vez as repassa para algum gerente interessado nelas. As requisies CMIP enviadas para um agente so mapeadas diretamente para mtodos aplicados aos objetos gerenciados que o agente contm. Quando, por exemplo, uma requisio M-GET enviada para um agente, esse agente primeiro encontrar o objeto gerenciado para o qual a requisio est direcionada, ento ele recupera as informaes do objeto gerenciado e finalmente as retorna para o solicitante (gerente).

2.2.3. Linguagem de especificao

Os objetos gerenciados so definidos usando-se duas linguagens de especificao:

Abstract Syntax Notation One (ASN.1) : usada para definir os tipos de dados;

22

Guidelines for the Definition of Managed Objects (GDMO) : usada para definir os objetos gerenciados.

Os tipos de atributos e os parmetros das operaes contidos em um objeto gerenciado so definidos usando ASN.1, que define tipos atmicos tais como inteiro, real ou string e agrega tipos como listas, estruturas e unies. Um exemplo de ASN.1 mostrado na figura 2.2.2.
BaseManagedObject ::= SEQUENCE { BaseManagedObjectClass ObjectClass, BaseManagedObjectInstance ObjectInstance} ObjectClass ::= GlobalForm NonSpecificForm ObjectInstance ::= DistinguishedName NonSpecificForm EnumerateForm CHOICE { [0] IMPLICIT OBJECT IDENTIFIER, [1] IMPLICIT INTEGER} CHOICE [2] IMPLICIT DistinguishedName, [3] IMPLICIT OCTET STRING, [4] IMPLICIT INTEGER}

Figura 2.2.2- Exemplo de ASN.1 O exemplo define 3 tipos : BaseManagedObject uma estrutura que contm 2 membros, isto , um ObjectClass ( outro tipo definido em ASN.1 logo abaixo) chamado BaseManagedObjectClass e um ObjectInstance. Um ObjectClass uma unio com os membros GlobalForm, que do tipo OBJECT IDENTIFIER, e

NonSpecificForm que do tipo INTEGER. Um ObjectInstance tambm uma unio de trs membros. Os tipos ASN.1 so associados a atributos dentro dos objetos gerenciados. Os objetos gerenciados so definidos usando-se a notao GDMO. Um exemplo de GDMO dado na figura 2.2.3. Cada classe de objeto gerenciado derivada de pelo menos uma outra classe ( possvel mltipla herana) e contm um nmero de pacotes mandatrios e outros condicionais. Um pacote contm atributos, aes e notificaes. O tipo de um atributo no definido em GDMO diretamente, mas a clusula ATTRIBUTE sempre se refere a um tipo ASN.1 definido em algum arquivo ASN.1. Um pacote mandatrio (e portanto seus atributos, aes e notificaes) precisa estar presente em uma instncia de uma classe de um objeto gerenciado, ao passo que a presena de pacotes condicionais determinada em tempo
23

de execuo dependendo do comportamento especificado. Isto implica que, apesar de serem da mesma classe, as duas instncias podem no ter o mesmo nmero de atributos, aes e notificaes. No exemplo mostrado na figura 2.2.3, a classe do objeto gerenciado Customer derivada de top, definida em outro lugar. Tem-se os pacotes mandatrios CustomerPkg, ContactListPkg, e os pacotes condicionais OpNetworkListPkg,

ServiceListPkg, TypeTextPkg e UserLabelPackage . O pacote CustomerPkg define os atributos CustomerID e CustomerTitle. CustomerID definido em seguida derivado do atributo systemId, que por sua vez definido em algum outro arquivo GDMO, o prprio systemId ter seu tipo definido em outro lugar.

Customer MANAGED OBJECT CLASS DERIVED FROM top; CHARACTERIZED BY CustomerPkg, ContactListPkg, CONDITIONAL PACKAGES CustomerTypesPkg PRESENT IF ! na instance supports it !, OpNetworkListPkg PRESENT IF ! an instance supports it !, ServiceListPkg PRESENT IF ! an instance supports it !, TypeTextPkg PRESENT IF ! an instance supports it !, UserLabelPackage PRESENT IF ! an instance supports i!; REGISTERED AS {iso member-body(2) 124 forum(360501) 3 46}; CustomerPkg PACKAGE BEHAVIOUR customerPkgDefinition, customerPkgBehaviour, CommonCreationBehaviour; ATTRIBUTES CustomerID PERMITTED VALUES FORUM-ASN1-1.SystemIdRange GET, CustomerTitle GET;; CustomerID ATTRIBUTE DERIVED FROM "CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992":systemId; MATCHES FOR EQUALITY; BEHAVIOUR customerIDBehaviour; REGISTERED AS {iso member-body(2) 124 forum(360501) attribute(1) 228};

Figura 2.2.3. - Exemplo de GDMO

24

2.2.4. Nomes Instncias de objetos gerenciados podem conter outras instncias e elas mesmas podem estar contidas em outras instncias. A estrutura resultante chamada de rvore recipiente. Cada instncia dentro da rvore recipiente tem um nome relativo distinto (relative distringuished name - RDN ), o qual consiste do atributo de nome da intncia e seu valor, por exemplo, CustomerID=( name IBM). A concatenao de todos os RDNs da raiz at a instncia chamado de nome distinto (distinguished name - DN), por exemplo, NetID=TelcoNet; CustomerID=(name IBM). Um DN identifica de maneira nica uma instncia dentro do contexto do seu agente. Uma instncia dentro de uma rvore recipiente pode por exemplo ser acessada a qualquer momento atravs do seu DN. Ao contrrio da referncia a objetos na CORBA, DNs no identificam instncias de maneira confivel visto que podem ser reusados quando a instncia tiver sido eliminada para fazer referncia a uma instncia diferente.

2.3. Modelo de gerncia SNMP

2.3.1. Arquitetura O Simple Netwok Management Protocol ( SNMP) um padro amplamente difundido na rea de gerencia de redes, principalmente por causa da sua simplicidade e rapidez na disseminao. Sua arquitetura conceitualmente similar arquitetura de gerencia OSI. Um gerente comunica-se com um agente usando o protocolo SNMP transportado no protocolo UDP (User Datatagram Protocol) da camada de transporte da Arquitetura TCP/IP. O SNMP permite ao gerente fazer requisies ( GET, GET-NEXT, SET) e receber as respostas. O agente efetua as requisies enviadas pelo gerente e adicionalmente pode enviar uma

25

requisio TRAP para o gerente. Uma requisio TRAP usada quando necessrio enviar ao gerente uma notificao de algum problema que ocorreu do lado do agente. Diferente do CMIP, o protocolo SNMP no define operaes que podem ser executadas em variveis. Chamadas a operaes tem que simuladas pelo gerente atravs da modificao de certas variveis no agente. Gerente e agente tm que concordar que com a modificao de determinadas variveis implicaro na realizao das operaes correspondestes.

2.3.2. Modelo O SNMP no um modelo orientado a objetos pois ele no tm a noo de classes. Ele apenas conhece o conceito de variveis. As variveis que representam as informaes na base de informaes de gerenciamento (Management Information Base - MIB) e podem ser acessadas com o uso de um identificador de objeto nico. Um identificador de objeto um n na rvore global de nomes cuja estrutura administrada conjuntamente pelo ISO e pelo ITUT. Novos identificadores de objetos (para novas MIBs) podem ser adicionadas s folhas da rvore de uma maneira padronizada. Identificadores de objetos podem ser conceitualmente comparados ao DNs da ISO e a referncias a objetos da arquitetura CORBA, visto que eles identificam univocamente uma varivel e objeto, respectivamente. Uma varivel tem um tipo predefinido usando macros ASN.1. O SNMP tem apenas um pequeno nmero de tipos disponveis para a descrio das informaes, os quais so os tipos simples INTEGER, OCTET STRING, OBJETCT IDENTIFIER (OID), NULL e uns poucos tipos predefinidos tais como Gauge e TimeTick definidos na RFC 1065. Um mecanismo adicional de estruturao so ( conceitualmente) as tabelas que permitem armazenar qualquer nmero de variveis sob o nome de uma dada varivel. As requisies GET e GET-NEXT permitem percorrer tais tabelas.

26

2.3.3. Linguagem de especificao A linguagem de especificao do SNMP (macros ASN.1) usada para dois propsitos a saber, a criao de MIBs e a definio de variveis de um certo tipo. Uma criao de uma nova MIB feita pelo definio de um nmero de variveis numa determinada posio na rvore global de nomes. Estes variveis ento representam a informao que um agente SNMP ir disponibilizar. Cada varivel de um determinado tipo que definido usando ASN.1. Um exemplo mostrado na figura 2.3.1. Este exemplo define a varivel que alocada sob system ( que um n dentro da rvore de nomes). A varivel do tipo OCTET STRING e de somente - leitura, ou seja, no pode ser modificada. Ao se ter acesso MIB de um agente SNMP, possvel saber a estrutura da MIB, ou seja, a parte da rvore global de nomes que o agente disponibiliza e os tipos de suas variveis.
SsysDescr OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory ::= { system 1 }

Figura 2.3.1 - Macro ASN.1

2.4. Arquitetura Yasmin Yasmin uma arquitetura desenhada para possibilitar a construo de aplicaes combinadas. Isto , aplicaes que implementam suas funcionalidades atravs da cooperao com outras aplicaes e disponibilizando servios para a prpria aplicao assim como para outras. Yasmin est baseada no conceito de colaborao. As aplicaes contrudas de forma monoltca implementam elas mesmas os servios de que faro uso. Em outras palavras, um visualizador (browser) suportanto HTTP, FTP, GOPHER implementa todas esses servios, por causa disso um desenvolvedor que pretenda escrever um novo visualizador WWW ou queira incluir alguns servios GOPHER na sua aplicao no pode fazer uso desses servios j implementados. Supondo que seja possvel ter acesso ao cdigo fonte do visualizador,
27

provavelmente veremos que esses trs servios lgicos so usados pelo visualizador mas no esto acessveis para outras aplicaes. Esta mudana de perspectiva tem um impacto significante em como a aplicao est escrita. Na verdade, uma aplicao no mais deve ser um bloco monoltico mas sim parte de um bloco maior os quais juntos fazem a aplicao. Este enfoque permite se escrever aplicaes menores porque elas podem reutilizar servios j oferecidos e dessa forma distribuir mais facilmente inteligncia na rede. Para que seja possvel a cooperao, alguns protocolos de comunicao tm que ser definidos como servios de diretrios usados na localizao de aplicaes.
A idia central de Yasmin a cooperao. Uma determinada atividade pode ser executada por entidades especiais que esto capacitadas para faz-lo adequada e eficientemente melhor que se tiverem sido implementadas internamente na aplicao. Este conceito no novo visto que ele j foi aplicado em certas aplicaes mas no utilizado em larga escala de forma genrica ainda. Por exemplo, no mundo Unix existem algumas ferramentas do tipo grep ou sed que so usadas por outras aplicaes. Olhando por esse ngulo, uma shell-script que chama um punhado desses comandos pode ser vista como um integrador mas ela apenas uma maneira: ela usa servios mas no prov nenhum servio para as ferramentas. Portanto cooperao significa no apenas usar servios de alguem mas tambm prov servios para a comunidade. A figura abaixo ilustra os componentes da arquitetura Yasmin.

Figura 2.4.1. Elementos da Arquitetura Yasmin

Os User Services so implementados usando droplets os quais mudam de aplicao para aplicao. Kernel Services, por sua vez, so parte da cada aplicao baseada na Yasmin e prov servios e funcionalidades sobre os quais os droplets operam. A seguir veremos uma breve explanao dos componentes do kernel. Personality Layer : Os servios do kernel so desenhados para rodar em diferentes sistemas operacionais. Por essa razo necessrio abstrair o sistema operacional atravs de uma fina camada chamada de Personality Layer. Esta camada prov as abstraes necessrias para os servios de mais baixo nvel a cargo do sistema operacional da mquina. Alguns desses servios so :

Execuo concorrente (threads); Primitivas de sincronismo (semforos);

28

Carga/Remoo de bibliotecas e informao de metadados; Comunicao interprocessos.

Droplet Manager : O Droplet Manager (DM) responsvel pelo manuseio de droplets, ou seja: Carrega/descarrega droplets de acordo com a necessidade; Detectar novas verses de droplets assim como droplets adicionados em tempo de execuo da aplicao; Interagir com o Service Manager informando-o da existncia de novos servios disponibilizados; Uma aplicao baseada na arquitetura Yasmin armazena droplets num diretrio pr-definido (normalmente chamado Droplets/). Para se fazer a atualizao deles necessrios somente a sua substituio no diretrio de droplets. Durante a inicializao da aplicao o DM consulta um arquivo chamado index o qual contem o nome dos droplets e os servios que eles implementam. O arquivo de ndices automaticamente reconstrudo quando feita alguma alterao nos droplets. Event Manager : Eventos so por natureza assncronos e normalmente indicam que alguma coisa relevante ocorreu. O Event Manager (EM) responsvel por: Entrega dos eventos para os vrios componentes; Tratamento de eventos atrasados; Permitir a cooperao e interao de diferentes droplets e servios atravs da troca de eventos entre eles. Yasmin define um conjunto bsico de tipos de eventos e permite que os droplets definam seus prprios tipos os quais so especificados internamente dentro do prprio droplet. Sempre que um novo droplet carregado/descarregado, o DM notifica o EM sobre os novos tipos de eventos que tero que ser manuseados ou no esto mais disponveis.
29

Service Manager : O Service Manager (SM) interage com o DM para manusear os servios disponibilizados pelos droplets. Quando um droplet carregado, o DM notifica o SM dos servios disponibilizados pelo droplet os quais so disponibilizados para o sistema inteiro. Quando um droplet descarregado, o DM informa o SM dos servios que no mais esto disponveis. Toda vez que o SM recebe uma requisio para um determinado servio, ele solicita ao DM para retornar a referncia para o servio solicitado. O DM, de acordo com as informaes contidas no arquivo de ndices, identifica o droplet que implementa o servio, carrega o tal droplet se necessrio e retorna a referncia do droplet para o SM. Quando no existe nenhum droplet que implemente o servio requisitado, a requisio rejeitada pelo SM. Os servios, identificados por uma string nica, podem ser de dois tipos : locais ou remotos. Um servio local pode ser usado apenas localmente enquanto que um servio remoto pode ser usado tanto local quanto remotamente com a utilizao dos Communication Services (CS). A principal diferena entre servios locais e remotos que para servios remotos os parmetros de entrada/sada so ambos strings enquanto que nos servios locais pode-se usar qualquer tipo. Resource Manager : O Resource Manager (RM) coopera com os outros gerenciadores para fazer uso dos recursos eficientemente. Tais recursos incluem (mas no esto limitados somente a isso) memria, sockets de comunicao e droplets. O RM garante que os resurcos do sistema no sejam desperdiados e libera recursos alocados que no esto sendo mais efetivamente utilizados. Suas tarefas so: Informar o DM quando o tipo de vida de um droplet expirar para ele poder ser descarregado; Garantir que os threads estejam sendo usados eficientemente evitando que o nmero excessivo de threads degradem o desempenho da aplicao;

30

sua responsabilidade liberar memria e outros recursos do sistema (incluindo os droplets) periodicamente.

Apesar do RM ser um componente oculto, ele muito importante pois ele permite que o sistema rode com recursos bastante limitados evitando o desperdcio deles. Collaboration Services : Os Collaboration Services (CBS) habilitam a comunicao e cooperao entre os droplets e os servios para que seja realizada uma determinada tarefa. O CBS, tirando partido do SM e EM, possibilita que uma tarefa seja dividida em vrias subtarefas pequenas cooperativas. Esta soluo melhora o desempenho pois essas sub-tarefas podem ser realizadas concorrentemente. Isto ajuda a manter o nvel de complexidade mais baixo pois cada sub-tarefa mais simples que a tarefa original. CBS fornece facilidades para: Envio de requisies no modo multicast/broadcast e coleta dos resultados; Sincronizao de tarefas atravs de eventos.

importante notar que Yasmin implementa colaborao tanto atravs do CBS como do SM. Na verdade os droplets colaboram com o resto do sistema fornecendo servios que podem ser de interesse geral. Isto evita a replicao de servios que consequentemente poupa tempo de desenvolvimento e mantem o sistema enxuto e eficiente.

Communication Services : Os Communication Services (CS) permitem que as aplicaes baseadas na arquitetura Yasmin se comuniquem com entidades remotas (comunicaes locais so realizadas atravs de eventos). Como a Yasmin foi desenhada tendo a portabilidade em mente, as comunicaes externas devem ser baseadas em protocolos largamente utilizados tais como TCP/IP or HTTP. Os CS so usados pelo desenvolvedores para: Cadastrar/descasdratar sockets de comunicao; Notificar quando os dados esto disponveis; Emitir requisies e recuperar os resultados.

CS so tambm usados internamente por outros componentes da arquitetura tais como SM que o usa para transparentemente enviar requisies de servios remotos e receber as respostas. Uma importante caracterstica do CS que eles permitem que sejam enviados
31

dados de uma maneira confivel e manusear transparentemente socket e erros dos protocolos protegendo os droplets das diferenas entre as implementaes dos sockets disponveis nas vrias plataformas.

3. USANDO CORBA NO GERENCIAMENTO DE REDES

3.1. Gerenciamento Interdomnios O termo Gerenciamento Interdomnios (Inter-Domain Management -IDM) usado aqui no sentido de gerenciamento abrangendo mais de uma arquitetura de gerenciamento. Exemplos de domnios so CORBA, CMIP (X.700) e SNMP. Sendo assim um modelo de gerenciamento envolvendo mais de um domnio corresponderia a um Gerenciamento Interdomnios, ou seja, utilizando-se um domnio para gerenciar e um outro para ser gerenciado diferente do primeiro, por exemplo, o gerenciamento de um agente OSI atravs de um gerente CORBA. De maneira similar, um Gerenciamento Multidomnio refere-se ao gerenciamento de alguns domnios atravs de um nico domnio diferente dos primeiros. Verifica-se que no gerenciamento interdomnio existe uma relao binria entre o domnio que gerencia e o domnio gerenciado ao passo que no gerenciamente multidomnio essa relao de 1 para M (M = nmero de domnio gerenciados).
Grande parte dos trabalhos referente s atividades de gerenciamento interdomnio esto focadas nos seguintes tpicos:

Gerenciamento de agentes OSI usando clientes CORBA; Gerenciamento de agentes SNMP usando clientes CORBA; Gerenciamento de agentes CORBA usando gerentes OSI; Gerenciamento de agentes CORBA usando agentes SNMP.

3.2. Propostas do XoJIDM

32

O fora tarefa do Network Management Forum - X/Open Joint Inter-Domain Management (XoJIDM) tem como objetivo a integrao da arquitetura CORBA no mundo de gerenciamento de redes. Esta fora tarefa lida com publicaes voltadas para como CORBA pode ser usada na construo de aplicaes de gerencia de redes ( clientes, agentes e gerentes).

3.2.1. Domnio de gerenciamento = CORBA ; Domnio Gerenciado = CMIP Os trabalhos nessa rea esto voltados para como agentes CMIP podem ser gerenciados por gerentes CORBA. Esta abordagem envolve a traduo da especificao de um agente OSI (GDMO/ASN.1) para documentos IDL CORBA (Specification Translation ) e subseqente converso em tempo de execuo das requisies CORBA para CMIP e vice-versa (Interaction Translation ). O Specification Translation do XoJIDM define um mepamento de GDMO/ASN.1 para IDL, conforme mostrado na tabela abaixo:

Moldes GDMO

Pacotes GDMO Atributos GDMO Acesso a Atributos GDMO Aes GDMO Operaes GDMO Notificaes GDMO Operaes GDMO Parmetros GDMO Tipos IDL Tipos ASN.1 Tipos IDL Tabela 3.2.1. XoJIDM Specification Translation

Interfaces IDL (at 3:classe, notificao e respostas mltiplas) Elementos da Interface IDL Tipos / Interfaces IDL Operaes IDL ( get_X() , set_X() )

Os moldes GDMO podem ser mapeados para at 3 interfaces IDL: uma interface CORBA default, uma interface para notificaes e uma para lidar com respostas mltiplas. Os pacotes GDMO no tm correspondentes no cdigo traduzido mas todos os elementos (atributos,
33

aes e notificaes) tanto dos pacotes mandatrios como dos condicionais so adicionados a interface IDL resultante. Informao sobre pacotes condicionais est presente apenas na forma de comentrio. Existe uma grande possibilidade de se obter grandes interfaces IDL a partir desse algoritmo contendo todos os elementos dos pacotes condicionais mesmo quando apenas poucos pacotes condicionais esto presentes no objeto gerenciado resultante. Atributos dos moldes GDMO so mapeados de ASN.1 para os seus correspondentes tipos IDL e so criadas variveis associadas na interface IDL resultante. Os tipos ASN.1 so traduzidos para os tipos IDL correspondes, ou seja, um OCTET STRING mapeado para uma string, uma SEQUENCE para uma struct, etc. O Interaction Translation especifica o mecanismo de converso em tempo de execuo e os pontos de encaixe do esquema proposto com a arquitetura CORBA, como mostrado na figura 3.2.1.

Figura 3.2.2. Arquitetura do Interaction Translation do XoJIDM

Os documentos GDMO/ASN.1 que definem a MIB do agente traduzida para IDL de acordo com as regras do Specification Translation . O cdigo IDL resultante posteriormente traduzido tanto para stubs clientes como implementaes de esqueletos servidores (stubs servidores) da linguagem destino desejada ( C++ por exemplo).
34

A traduo anterior de GDMO/ASN.1 para IDL proporciona no apenas interfaces IDL, mas tambm cdigo (comportamento) para a implementao dos stubs servidores, o qual converte requisies CORBA em PDUs CMIP usando, por exemplo XOM/XMP. Os stubs servidores junto com o cdigo da implementao do stub gerado representam proxies funcionais completos para os objetos gerenciados e residem num CORBA CMIP object adapter (CMIP AO). Uma aplicao de gerenciamento pode ento incluir os stubs clientes gerados nos pontos de ligao feitos na linguagem desejada ( C++ ou Smaltak, por exemplo). Uma requisio invocada num stub cliente ser repassado transparentemente para o servidor de objetos no CMIP AO, que usar XOM/XMP para despach-lo para um agente usando o protocolo CMIP. A resposta do agente posteriormente convertida para CORBA e retornada para o cliente. O Telecomunication Special Interest Group do OMG publicou um artigo descrevendo como usar CORBA no campo das telecomunicaes. O principal ponto desse trabalho concentra-se na disponibilizao de Servios CORBA direcionados para as necessidades do domnio das telecomunicaes. Na proposta os recursos fsicos e lgicos so representados por Intefaces CORBA. O acesso aos sistemas gerenciados OSI e SNMP devem fazer uso do trabalho feito pelo XoJIDM.

3.2.2. Domnio de gerenciamento = CORBA ; Domnio Gerenciado = SNMP Este campo do IDM lida com o gerenciamento de agentes SNMP a partir de um domnio de gerenciamento baseado em CORBA permitindo dessa forma um gerenciamento de dispositivos SNMP por gerentes CORBA de forma transparente, ou seja, sem se ter que lidar diretamente com o protocolo SNMP.

35

O XoJIDM definiu um algoritmo de traduo que faz o mapeamento de IDL CORBA para SNMP. Existem trabalhos especificando como traduzir as MIBs do SNMP para CORBA IDL. DSI ( Dynamic Skeleton Interface) e DIR (Dynamic Implementation Routine) so usados em tempo de execuo no lado do servidor para converter requisies CORBA entrantes para PDUs SNMP e ainda respostas SNMP para valores CORBA. O Telecomunication Special Interest Group do OMG props um esquema descrevendo como dispositivos SNMP podem ser gerenciados a partir de aplicaes baseadas em CORBA.

Figura 3.2.3. Gateway CORBA->SNMP

A figura 3.2.2 ilustra a interao entre um gerente baseado em CORBA e um agente existente SNMP usando um gateway CORBA-> SNMP. Este gateway converte as operaes get/set baseadas numa interface IDL usando referncias a objetos para mensagens de requisio SNMP, e ainda converte a resultado da mensagem SNMP como valor de retorno da operao. A maneira como as operaes sero mapeadas para mensagens SNMP vai depender da implementao. O gateway CORBA->SNMP tambm monitora a porta SNMP de Trap/Notificao e converte as mensagens entrantes de notificao do SNMP para o Servio de Notificao definido pelo OMG.

36

3.2.3. Domnio de gerenciamento = CMIP ; Domnio Gerenciado = CORBA O enfoque dessa rea concentra-se em como um gerente CMIP pode gerenciar objetos do domnio CORBA. A fora tarefa XoJIDM considera na sua proposta o uso de um agente procurador (proxy agent) para receber as requisies CMIP e despach-las para os objetos CORBA usando a DII. Existe tambm um MIBserver que grava os nomes OSI (DN) e as referncias aos objetos CORBA numa tabela. Esta tabela pode ser consultada para traduzir nomes OSI para referncias a objetos CORBA e vice versa. Esta proposta faz uso do documento Specification Translation de abril de 1997 do XoJIDM que define o mapeamento entre IDL e GDMO/ASN.1.

3.2.4. Domnio de gerenciamento = SNMP ; Domnio Gerenciado = CORBA Os trabalhos nessa rea visam a possibilitar que gerentes SNMP possam gerenciar objetos CORBA. O documento Specification Translation do XoJIDM de abril de 1997 define um mapeamento de SNMP para OMG IDL. Existem esforos de implementao fazendo uso dessas definies. Estes mapeamentos consistem em um agente CORBA que age como um agente SNMP ( usando uma biblioteca SNMP da Carnegie Mellon University). Os PDUs do SNMP que entram so convertidos para requisies CORBA e os eventos CORBA so mapeados para traps SNMP.

Figura 3.2.4. Gateway SNMP -> CORBA

37

A figura 3.2.3 descreve a interao entre um j existente gerente SNMP e a implementao de uma MIB SNMP baseada em CORBA usando um gateway SNMP-> CORBA. O gateway mapeia mensagens SNMP para operaes CORBA-IDL. Quando o agente SNMP baseado em CORBA recebe um PDU SNMP da pilha do protocolo SNMP, ele converte a mensagem para um tipo IDL para interagir com Servidor de Objetos baseado em CORBA. Como uma mensagem SNMP pode especificar mais de uma varivel que pode gerar mltiplas tabelas ou colunas, cada PDU SNMP pode potencialmente gerar mais de uma operao get/set. O gateway tambm mapeia as notificaes (eventos) gerados pelos objetos do agente baseado em CORBA para notificaes SNMP. As principais tarefas do gateway SNMP->CORBA so as seguintes: Mapear nomes de variveis para a combinao de referncia a objetos e nomes de atributos, e vice e versa; Mapear as mensagens de notificao do SNMP para Servio de Eventos CORBA.

3.3. Generic Object Model - GOM As limitaes dos mapeamentos estticos CMIP/SNMP -> CORBA e sua grande complexidade tem sido a principal razo que tem impulsionado a pesquisa na direo de uma abordagem mais dinmica do problema de gerenciamento interdomnios. O Generic Object Model (GOM) idealizado por Ban(1997) uma proposta nesse sentido. Dentre as caractersticas que o GOM oferece esto : modelagem da programao orientada a objetos; acesso transparente a instncias de outros modelos de objetos; tipos e mtodos agregados em tempo de execuo; e consequentemente, maior flexibilidade. A arquitetura do GOM est mostrada na figura 3.3.1 .

38

O GOM est estruturado para o gerenciamento de instncias de mltiplos modelos de objetos tais como CORBA, CMIP e SNMP.

Figura 3.3.1. Generic Object Model No cerne do GOM est o Repositrio de Meta-dados (metadata repository MR) que contem informaes sobre a estrutura das classes dos vrios modelos de interesse. Ele se faz necessrio para as requisies de checagem de tipos dos argumentos em tempo de execuo e para converter valores entre o GOM e os modelos de interesse. Como o GOM no possui nenhum conhecimento sobre as classes disponveis nos modelos em jogo pelo fato deles no serem includos em tempo de compilao, ele tem que se basear totalmente nos metadados para manipulao das instncias. Um outro componente importante da arquitetura GOM o modelo genrico de objetos (generic object model). Ele empacota instncias dos sistemas alvo de uma maneira bastante genrica e oferece-os como instncias procuradoras (proxy instances) para as aplicaes clientes. As instncias procuradores podem ser manipuladas pelas aplicaes como de fossem instncias normais, mas em vez de manterem funcionalidades delas prprias, as operaes invocadas nelas sero processadas pelo GOM, o
39

qual realiza a checagem dos tipos, converses, despacho para a instncias correspondente no sistema alvo e converso do valor de retorno. Todas essas tarefas so de fato realizadas pelos adaptadores (adapters). Um adaptador uma ponte entre o modelo genrico de objetos e um pr-determinado modelo alvo. Ele encarregado de checar tipos, converter e despachar as requisies entre eles. Cada instncia procuradora ter uma referncia para um adaptador para o qual ela repassar todas as requisies que recebe. O modelo de objetos do GOM definido atravs de um nmero de classes (interfaces IDL) com os atributos e as operaes e ainda as interaes entre eles. Essas classes fornecem uma camada de abstrao homognea para os clientes resguardando-os das diferenas assim como nivelando essas diferenas entre os vrios sistemas alvos tais como CORBA, CMIP e SNMP.

Figura 3.3.2. Arquitetura GOM A abordagem do GOM coletar meta-informaes a partir do GDMO/ASN.1 e IDL para construir um Banco de Dados de Meta-Informaes (Meta-Information Database-MID) e acessar as instncias em um agente X.700 (OSI) ou um servidor CORBA usando essas metainformaes ao invs de inclu-las nos arquivos de cabealhos gerados. Isto faz com que o cliente fique independente do servidor visto que o contrato (o conjunto de servios oferecidos por uma classe) recuperado dinamicamente em tempo de execuo a partir do MID ao invs de ser recuperado em tempo de compilao a partir dos arquivos de cabealhos.
40

Um gerente GOM cria uma instncia proxy no seu espao de endereo para cada instncia remota em um servidor CORBA ou agente X.700. Requisies enviadas para o proxy so repassadas para a instncia remota usando conversores adequados que fazem uso das metainformaes extradas do MID. Um conversor traduz as informaes de um lado para outro entre o GOM e o modelo de objetos especfico. No caso de um conversor CORBA, as informaes do GOM so inicialmente convertidas para CORBA na forma de requisies DII. O resultado ento convertido de volta para GOM. Instncias do GOM so manipuladas atravs de interfaces oferecidas por uma classe bsica abstrata. Instncias X.700 ou CORBA so criadas a partir de classes derivadas da classe bsica abstrata. Usando o mecanismo de envio de mtodo virtual do C++, o usurio nem precisa saber se est acessando uma instncia X.700 ou CORBA. As informaes no MID so criadas por compiladores GDMO/ASN.1 e IDL. De fato, para lidar com instncias do GOM, um interpretador baseado em C++ (C++-like) foi escrito possibilitando ao usurio criar, acessar e eliminar instncias tanto interativamente como atravs da construo de scripts . Este interpretador, denominado de GOMscript, tem os valores simples tais como nmeros, booleanos, cadeias de caracteres e valores agregados tais como estruturas, unies e listas. Tem ainda os comandos de controle de repetio usuais (for, while) e condicionais (if,else). O GOMscript orientado a objetos no sentido de que ele implementa herana (simples), polimorfirsmo e encapsulao. Seu ncleo muito pequeno e pode ser estendido (funes e classes adicionais, por exemplo) atravs da insero de componentes escritos pelo usurio, extenses estas que ficam localizadas em bibliotecas compartilhadas. GOMscript pode ser inicializado no modo de daemon ficando dessa forma espera de clientes (potencialmente remotos) enviarem scripts para serem executados. Isto permite a implementao de agentes simples nmades os quais so essencialmente scripts que se movem de uma mquina para outra levando consigo seu estado. Esta arquitetura mostrada na figura 3.3.3.

41

Figura 3.3.3. Plataforma de execuo GOMscript

Em qualquer momento de sua execuo, um script pode decidir migrar para uma mquina diferente. Para faz-lo basta simplesmente chamar a funo GOMscript que tinha como parmetros o nome do host destino e nmero da porta. Isto vai empacotar o script que est rodando junto com o seu estado (um dump da sua tabela de smbolos) dentro de uma mensagem TCP que em seguida ser enviada para a mquina destino. L chegando, um outro interpretador receber a mensagem, configurar seu estado inicial a partir do dump feito antes e inicia a execuo do script num processo separado. Como as referncias aos objetos CORBA so valores dentro da tabela de smbolos que podem ser acomodados tambm num fluxo de dados, possvel para os agentes nmades terem acesso a alguma instncia global CORBA para a qual eles podem fazer referncia durante suas viagens.

3.4. CORBA - Liaison Liaison um software de aplicao que permite gerenciar recursos CMIP/SNMP atravs da Web (HTTP). O elemento ncleo do Liaison o servidor proxy que baseado num tipo especial de componentes de software chamados droplets que tm a habilidade de poderem ser substitudos ou adicionados em tempo de execuo permitindo dinamicamente modificar e/ou
42

estender o comportamento da aplicao que os contm. Dentre os droplets que fazem parte da configurao padro de Liaison, existem alguns que podem ser usados para permitir que aplicaes Java/C++ sejam usadas para gerenciamento de redes atravs do Liaison. Em linha gerais, Liaison fornece algumas classes Java/C++, chamadas de amarraes externas, as quais so ligadas a uma aplicao C++ ou a um applet Java . Esta ligao permitir que as operaes de gerenciamento sejam realizadas. A aplicao de gerenciamento usa as amarraes externas como classes normais, invocando mtodos e criando/eliminando instncias. De maneira transparente, as amarraes externas comunicam-se com o servidor proxy usando o protocolo HTTP, o qual usado extensivamente na Internet pela WWW.

Figura 3.4.1. Liaison e Java/C++

Toda vez que um mtodo de uma amarrao externa que realiza uma determinada operao de gerenciamento (um M-SET do CMIP, por exemplo) chamado, uma requisio HTTP enviada ao proxy. Desse modo a requisio HTTP conter todos os parmetros necessrios para efetivar a requisio de gerenciamento. O proxy efetiva a requisio de gerenciamento, recebe a(s) respostas(s) e trata todos os possveis erros. Uma vez que a operao tenha sido concluda, um resposta HTTP com o resultado da operao enviada de volta para a aplicao. Este mecanismo permite que aplicaes externas gerenciem redes de uma forma

43

simples e eficaz utilizando-se de Liaison e sem ter que lidar com a complexidade dos protocolos de gerenciamento. Na verdade, as amarraes externas lidam somente com conceitos orientados a objetos abstraindo completamente a complexidade dos protocolos de gerenciamento.
Baseadas nas amarraes externas, algumas interfaces CORBA -> CMIP/SNMP tem sido definidas. Uma importante escolha feita nessa abordagem foi de no mapear cada objeto CMIP ou SNMP para um objeto CORBA como se tem visto em outros mtodos de traduo, mas, mapear os protocolos CMIP e SNMP para CORBA de uma maneira muito genrica. Esta abordagem foi motivada pelas seguintes razes:

Possibilidade para suporta totalmente CMIP e SNMP em CORBA; Baixa complexidade e flexibilidade uma vez que no existe a necessidade de gerar novas classes CORBA para novos objetos CMIP/SNMP que necessitem ser suportados;

Nvel de abstrao definido pelo usurio : os usurios podem definir classes CORBA adicionais baseadas naquelas bsicas dependo de suas necessidades sem ter que pagar pela complexidade de ter que definir uma classe CORBA para cada objeto CMIP/SNMP ainda que nem todos eles sejam correntemente usados.

As interfaces CORBA-Liaison (CL) para CMIP/SNMP, definidas usando a linguagem IDL (Interface Definition Language), tm sido implementadas usando DSOM, um ORB (Object Request Broker) da IBM em conformidade com a CORBA. Como no foi feita nenhuma amarrao especfica a qualquer caracterstica prpria do DSOM, consideraes similares podem ser feitas para qualquer outra implementao da arquitetura CORBA. Os tipos de dados ASN.1, tais como os tipos de dados das amarraes externas, foram mapeados para uma cadeia de caracteres, ou seja, para a tipo string da IDL. As interfaces CL representando objetos CMIP e SNMP, definidos de um modo muito similar s amarraes externas de Liaison, esto representada na figura 3.4.2.

44

Figura 3.4.2. Interfaces CL para CMIP e SNMP

A interface DSOMInformation contm as informaes relativas s requisies e s respostas. Internamente os valores so armazenados numa tabela de disperso (hash table) onde o identificador do atributo constitui a chave e o valor do atributo corresponde ao valor de cada entrada da tabela. O uso da tabela associada com o mapeamento dos valores para cadeias de caracteres permite o manuseio de objetos independente de suas classes e complexidades. No caso do CMIP, a camada de apresentao ou uma fina camada no topo da pilha, converte os valores dos atributos para cadeias de caracteres e vice-versa, ao passo que no caso do SNMP o proxy que lida com a converso.
Interface DSOMInformation: SOMObject { Void SetAttribute(in string name, in string value); // Stores a value into the table String GetAttribute(in string name); // Retrieves a value Void RemoveAttribute(in string name); // Remove an attribute from the table Sequence <string> GetAttributes(); // Returns all the attribute values Sequence <string> GetAttributeKeys(); // Returns all the attribute keys Void RemoveAllAttributes(); // Table clean up [...]

Figura 3.4.3. Interface DSOMInformation Sendo DSOMInformation (figura 3.4.3) construdo sobre uma tabela de disperso, possvel recuperar e armazenar eficientemente os elementos e ainda ter apenas uns poucos mtodos para lidar com todas as situaes. Por motivos de simplificao a manipulao de atributos, as classes DSOMSNMPObj e DSOMCMIPObj foram definidas. Essas classes
45

simplificam o acesso ao DSOMInformation pela definio de algumas macros tais como DSOMCMIPObj ::GetObjectInstance() as quais so mapeadas em chamadas para os mtodos DSOMInformation (neste caso DSOMInformation:: GetAttribute

("ObjectInstance")). Os mtodos em C++ de CL so definidos quase da mesma maneira que aqueles definidos na parte da classe correspondente das amarraes externas por isso a implementao do stub se torna bastante direta. A similaridade entre essas interfaces e as classes correspondentes (parte das amarraes externas) tm a vantagem de que os desenvolvedores podem usar tanto DSOM como as amarraes externas, tendo que aprender apenas um modelo de objetos. Adicionalmente, o cdigo pode ser escrito uma nica vez e ento, com pequenas modificaes, pode-se usar tanto amarraes externas C++/Java como amarraes das linguagens C++/Java das interfaces DSOM. Isto possvel somente porque mtodos e classes tm os mesmos nomes e parmetros. O exemplo seguinte mostra como um programa simples baseado em amarraes externas pode fazer uso das interfaces DSOM simplesmente adicionando o cdigo em negrito. O fragmento de cdigo da figura 3.4.4 abaixo l o valor de um atributo systemTitle de uma instncia genericNetworkId Net1@systemId= (name Telco) usando o protocolo CMIP.
Environment ev; SOM_InitEnvironment(&ev); SOMD_Init(&ev); /* Initialization */ try { Liaison_DSOMCMIPObj *cmip = new Liaison_DSOMCMIPObj(&ev); Cmip->UseProxy(&ev, "adl.zurich.ibm.com); /* Uses the Proxy server running on host adl */ Cmip->SetAgentAET(&ev, p, "MIBCTL" /* CMIP Agent AE-Title */); Cmip->SetObjectClass(&ev, "system"); Cmip->SetObjectInstance(&ev, "genericNetworkId=Net1@systemId=(name Telco)"); Cmip->SetAttribute(&ev, "systemTitle", ""); Cmip->CMIPGetAttributes(&ev); // Issue the CMIP M-GET request if(somExceptionId(&ev) == NO_EXCEPTION) printf(systemTitle is: %s\n, cmip->GetAttribute(&ev, systemTitle)); delete cmip; } catch(char *exc) { printf(Caught exception: %s, exc); } SOMD_Uninit(&ev); SOM_UninitEnvironment(&ev); /* Termination */

Figura 3.4.4 - Uso da Interface DSOM.

46

Basicamente, o nico cdigo que teve que ser adicionado est relacionado a :

Inicializao/terminao do DSOM; Parmetro Environment necessrio em cada chamada de um mtdo DSOM; Tratamento de excees. Dessa forma o DSOM usa o parmetro Environment para tratar as condies de erros.

A escolha de implementar os stubs DSOM usando as amarraes externas em vez de empacotar todo o Proxy dentro de um objeto DSOM tem as seguintes vantagens: Como as amarraes externas so bastantes leves, a implementao das interfaces DSOM muito leve tambm ( menos de 70Kb); DSOM tem que ser instalado apenas naqueles usurios que necessitam ter acesso ao Proxy usando DSOM, ou seja, as aplicaes baseadas nas amarraes externas no necessitam ter o DSOM instalado para rodar; DSOM permite que se crie objetos nos hosts onde o Proxy no est instalado, fazendo uso de um Proxy remoto, sem a necessidade de ter o DSOM instalado no host onde tal Proxy roda ( a comunicao DSOM servidor/proxy baseado no protocolo HTTP); Dependendo da situao, os usurios podem decidir acessar servios fornecidos pelo Proxy usando HTTP, DSOM ou ambos (se o Proxy tiver que ser empacotado num objeto CORBA ento os usurios podero necessitar do DSOM para ter acesso ao Proxy); possvel gerenciar hosts do lado de fora dos firewalls usando o Proxy local e as interfaces DSOM visto que so baseadas em HTTP (o DSOM no pode atravessar firewalls, o HTTP pode). O que pesa contra esta soluo o fato de que cada vez que se precise disparar uma operao de gerenciamento existe uma comunicao entre o cliente DSOM, o servidor DSOM e o Proxy o que no acontece quando se tem o Proxy empacotado dentro do servidor DSOM.
47

Considerando as muitas vantagens da soluo no que diz respeito a integrao usando DSOM, a sobrecarga passa a ser aceitvel ou quase imperceptvel quando as aplicaes clientes podem disparar operaes concorrentemente (multithread). Deri(1997) prope o uso de GOMscript para manipular CL interfaces interativamente ou na forma de scripts, permitindo dessa forma a automatizao de tarefas simples de gerenciamento. O GOMscript pode fazer uso das interfaces CORBA Liaison para implementar agentes nmades para as tarefas de gerenciamento. Agentes podem, por exemplo, ser enviados para diferentes locais para realizar a coleta de dados e tarefas de filtragem cujos resultados so periodicamente enviados de volta para a interface CORBA central. A ttulo de mostrar como essa abordagem facilita o desenvolvimento de rotinas de gerenciamento, um exemplo de um script mostrado figura 3.4.5. Primeiramente o script enviado para um conjunto determinado de mquinas definadas em hosts . No momento em que fica garantido que a lista no est vazia, o script propagar uma cpia de si mesmo (e seu estado corrente) para o prximo membro da lista. Tendo feito isto, o trabalho especificado pode ser iniciado. Um objeto SNMP criado e um valor recuperado (ifOutRequests.0). O valor ento enviado para uma instncia CORBA central onde ele pode ser acessado por outros clientes que assim o desejarem. Uma vez que os valores podem ser resumidos, correlacionados ou filtrados pelo agente antes de serem enviados para a instncia CORBA global, uma srie de mecanismos de filtragem podero ser facilmente implementados. Uma vez que diferentes conjuntos de classes e funes podem estar disponveis nas vrias mquinas da rede, GOMscript permite checar a existncia de classes e funes antes de us-la. E mais ainda, como GOMscript baseado em GOM, possvel descobrir dinamicamente que classes esto disponveis em um determinado sistema e fazer uso de seus servios.

48

If(hosts == NULL) Hosts=#("adl", "saz", "mut", "kis"); // list of hosts to visit if(collector == NULL) { collector=new Obj("CORBA", "Collector", "adl"); // "adl" is central } if(hosts.Length() > 0) { target_host=hosts.At(0); hosts.Delete(0); // otherwise we loop since the script is always to the same location ! SendAgent(target_host, 10000, "", ""); // will know 'hosts' and // 'collector' at target location } /* Now start the assigned task */ snmp_obj=new Obj("", "::Liaison::DSOMSNMPObj", ""); // create local obj snmp_obj.SetSnmpAgentAddress("", 160); // local snmpd is used hostname=GetHostname(); while(true) { out_requests=snmp_obj.GetAttribute("ifOutRequests.0"); // get more interesting data ... collector.UpdateAttr(hostname, // primary key "ifOutRequests.0", // secondary out_requests); // data Sleep(60); // sleep 1 minute }

loc.

// sent

snmp

key

Figura 3.4.5. GOMscript

4. CONSIDERAES FINAIS A tabela 4.1 a seguir lista algumas das principais diferenas entre as vrias abordagens. A abordagem feita pela interface CORBA Liaison (CL) completamente independente dos tipos dos dados a serem manuseados uma vez que todos os tipos so mapeados para string. A converso entre string e o tipo de dado desejado da linguagem usada tem que ser feita pelo programador. Isto pode ser uma tarefa fcil para tipos simples tais como cadeia de caracteres ou nmeros, mas a complexidade cresce muito quando se tiver que lidar com tipos agregados tais como estruturas ou seqncias. Existe ainda um aumento da probabilidade de introduo de erros nas converses escritas pelos usurios. Estes pontos negativos podem se tornar aceitveis considerando que o principal objetivo do CL a criao de modelo leves para gerenciamento de redes e que deveriam ser flexveis (sem amarraes em tempo de compilao) e ainda que pudesse se integrar ao mundo WWW (HTTP) que tem como string seu principal tipo de dado. Alm do mais, o gerenciamento de redes hoje em dia
49

predominantemente baseado em SNMP que usa principalmente tipos atmicos de dados tais como string e integer. Os tipos especificados pelo programador na sintaxe baseada em string sero checados em tempo de execuo pelo Proxy no caso do SNMP, ou pela pilha OSI no caso do CMIP. Comparado aos enfoque estticos com sua forte amarrao aos tipos em tempo de compilao, o GOM fora o casamento dos tipos somente em tempo de execuo usando metadados. Ao contrrio do CL que conhece apenas o tipo string, O GOM tem tipos para representao de classes (GenObj), atributos (Attribute) e valores (Val, Integer, String, Struct, Sequence, etc.). Enquanto CL mapeia todos os tipos para string, GOM mapeia-os para uma instncia desse conjunto de tipos fixos, e o enfoque esttico mapeia cada tipo para um tipo IDL correspondente.

Tipo de Mapeamento Tipos Checagem de tipos

CORBA-Liaison Dinmico Sem amarrao de tipos

GOM (Ban) Semi-dinmico Checagem em tempo de execuo Em tempo de execuo (usando metadados) Mdio (Precisa de um repositrio de metadados)

XoJIDM Esttico Tipos fortemente amarrados Em tempo de compilao

Em tempo de execuo (Pelo Proxy e a pilha OSI) Tamanho da Pequeno ( < 70 Kb implementa independente do o tipo/nmero de objetos gerenciados Mapeamento Todos os tipos de dados de tipos so mapeados para uma ASN.1/CORB string A CMIP/SNMP: N:1 CORBA Classes Suporte ao CMIP Suporte ao SNMP Sim

Grande (Inclui uma massa de tipos/mtodos gerados) Os tipos de dados so Cada uma dos tipos de mapeados para um dados so mapeados pequeno conjunto de para um tipo CORBA tipos GOM (15) equivalente ( algumas vezes mais de um) N:15 N:M (N<=M) Sim ( exceto para MEVENT-REPORT e M-ACTION) No (no existe nenhum adaptador SNMP disponvel) Sim Sim

Sim

50

Tabela 4.1. Aspectos dos modelos abordados

51

BIBLIOGRAFIA CONSULTADA.
Ban, Bela. Towards a Object-Oriented Framework for Multi-Domain Management, IBM Zurich Research Laboratory, December 1995. Ban, Bela. A Generic Management Model for CORBA, CMIP and SNMP, Thesis for Ph.D. in University of Zurich, December, 1997. Deri, Luca. Surfin Network Management Resources Across the Web, Proceedings of 2nd Intl. IEEE Workshop on Systems and Network Management, Toronto, June 1996. Deri, Luca e Ban, Bela. Static vs. Dynamic CMIP/SNMP Nerwork Management Using CORBA. In Intelligence in Services and Networks: Technology for Coorperative Competition, ed. by Mullery et al., Springer, Berlin, 1997. Mazumbar, Subrata. Inter-Domain Management between CORBA and SNMP : WEB-based Management-CORBA/SNMP Gateway Approach. DSOM'96, L Aquila, Italy, October, 1996. Mazumbar, Subrata. Mapping of Common Management Information Services to CORBA Object Services Specification, March, 1997. Montez, C. Um Modelo de Programao para Aplicaes de Tempo Real em Sistemas Abertos, Monografia do Exame de Qualificao de Doutorado, DAS,UFSC, Julho de 1997. OMG, The Common Object Request Broker: Architecture and Specification, Revision 2.2, February 1998 Pope, Alan. The Object : CORBA Basics ( Turorial ), Quantitative Data Systems, Inc. December, 1997. Vinoski, Steve. CORBA: Integranting Diverse Applications Within Distribuited heterogeneous Environments, IEEE Communications Magazine, Vol. 35, No. 2, February, 1997.

52