CAPÍTULO 5 CORBA 5.1 MODELO DE OBJETO

Transcrição

1 CAPÍTULO 5 CORBA Um dos grandes problemas das empresas é, utilizando seus recursos de hardware e o software, integrar vários elementos de trabalho diferentes de maneira a resolver problemas de negócios atuais e futuros. Uma parcela significante deste problema é integrar aplicações existentes em mainframes com os novos ambientes de estações de trabalho. As soluções são caras e demoradas. O padrão Common Object Request Broker Architecture (CORBA) é uma das formas usadas para solucionar estes problemas. CORBA é baseado em orientação a objeto e no de modelo computação distribuída cliente/servidor. 5.1 MODELO DE OBJETO CORBA está fundamentado nos conceitos de orientação a objeto (objeto, classe, encapsulamento, herança e polimorfismo), assim, todas as aplicações num sistema CORBA são constituídas por coleções de objetos. Algumas vezes, existem diferenças na interpretação destes conceitos de orientação a objeto gerando diferentes implementações e possíveis conflitos. Por este motivo, foi definido pelo CORBA um modelo de objeto comum para implementações que seguem este padrão. Deste modo, evita-se que produtos fornecidos por diferentes empresas apresentem incompatibilidades entre si. O modelo de objeto CORBA define limites e significados, permitindo, assim, uma interpretação sem ambigüidades destes conceitos. 5.2 COMPUTAÇÃO DISTRIBUÍDA CORBA é baseado no modelo cliente/servidor. Na computação distribuída uma requisição de um serviço é feita de um componente de software (cliente) para 105

2 outro (servidor) através da rede. CORBA acrescenta a este modelo as características descritas a seguir (Otte et al, 1996) ADIÇÃO DE BROKER ENTRE CLIENTES E SERVIDORES CORBA adiciona ao modelo convencional um broker entre o cliente e o servidor, Figura 5.1. Este broker ( Object Request Broker - ORB) tem a função de reduzir a complexidade da implementação necessária para permitir a interação entre cliente e servidor (CORBA, 1998) (Mowbray e Ruh, 1997). Cliente Requisição Servidor Relacionamento cliente/servidor Cliente ORB Servidor Relacionamento cliente/servidor mais broker Fig. 5.1 Relacionamentos clientes e servidores FONTE: Adaptada de Otte et al (1996, p.1.7 e 1.8) A redução de complexidade é obtida primeiramente porque o ORB provê serviços comuns que incluem troca de mensagens (comunicação) entre cliente e servidor, serviços de diretório, descrição de meta-dados, serviços de segurança e transparência de localização. Ele também isola os objetos da aplicação das configurações específicas de um sistema, tais como, plataformas de hardware e sistemas operacionais, protocolos de rede e linguagens de programação (CORBA, 1998). 106

3 ORBs podem ser vistos como um meio ( hub ) de comunicação para todos os objetos/componentes num sistema distribuído, tendo uma função análoga a de um bus de hardware, isto é, provendo um caminho para o fluxo de toda a informação que flui entre os objetos. ORB se encarrega de enviar uma requisição aonde ela deva ser atendida bem como prover os serviços auxiliares necessários para realizá-la. A adição do ORB apresenta vantagens como (Otte et al, 1996): O cliente e o servidor CORBA não precisam se conhecer diretamente. O cliente e o servidor CORBA se encontram através do ORB. Desta forma, somente o ORB precisa conhecer a localização e as capacidades dos clientes e servidores CORBA da rede, assim, evita-se que clientes ou servidores contenham estas informações. CORBA não necessita que exista uma relação um para um entre clientes e servidores, como acontece no ambiente tradicional cliente/servidor, assim, com a adição do ORB múltiplos servidores podem trabalhar com um único cliente ou um único servidor pode trabalhar com múltiplos clientes, como mostrado na Figura 5.2. Cliente Servidor Cliente ORB Servidor Cliente Servidor Fig. 5.2 Múltiplos clientes e servidores com ORB FONTE: Otte et al (1996, p.1-9) 107

4 Clientes CORBA podem localizar e interagir com novos objetos e servidores em tempo de execução. No ambiente tradicional cliente/servidor a invocação de uma requisição, isto é, o envio de uma mensagem do cliente para o servidor pedindo para que ele execute uma operação é predefinido, existindo um conjunto de procedimentos que permitem ao cliente fazer requisições aos servidores. No CORBA os clientes podem enviar requisições dinamicamente em tempo de execução PROCESSOS SERVIDORES O cliente CORBA é tipicamente um processo único, mas o servidor CORBA pode ser: um processo único, um servidor intermediário que requisita a outros servidores que realizem as tarefas requisitadas pelos clientes ou um trecho de código compartilhado, como por exemplo, uma biblioteca carregada dinamicamente em tempo de execução SUPORTE À COMUNICAÇÃO SÍNCRONA E ASSÍNCRONA CORBA suporta tanto comunicação síncrona como assíncrona. A comunicação síncrona acontece quando um software envia uma mensagem a um outro software e espera pelo retorno, enquanto na comunicação assíncrona um software envia uma mensagem a um a outro software e continua executando aguardando um posterior retorno. No CORBA a comunicação assíncrona, chamada de deferred synchronous, constitui-se de um modelo de polling, isto é, o cliente pergunta se a operação foi completada. CORBA também define requisições do tipo one way, nas quais o cliente não precisa esperar pelo término da operação, neste caso não existe retorno. 108

5 5.3 CONCEITOS E TERMOS ASSOCIADOS AO CORBA Com a utilização do ORB os clientes e servidores são formalmente separados, assim, mudanças em um não afetam o outro. O cliente CORBA sabe somente pedir que algo seja realizado pelo servidor CORBA e esse sabe somente realizar a tarefa a ele requisitada. Isso significa que se pode mudar a forma com a qual um servidor executa uma tarefa sem afetar a maneira com que o cliente requisita a tarefa. Por exemplo, se pode evoluir e criar uma nova implementação de um servidor CORBA sem necessidade de alterar o cliente ou se pode criar novos clientes que façam uso de interfaces já existentes de servidores CORBA sem alterá-los REQUISIÇÕES No CORBA, cliente e servidor comunicam-se através de mensagens chamadas requisições. Toda a interação em um sistema CORBA é baseada num cliente enviando uma requisição ou num servidor respondendo a uma requisição. Uma requisição é um evento (algo que acontece num determinado espaço de tempo em particular). O processo de enviar uma requisição é chamado de invocação. Todas as requisições devem conter (Otte et al, 1996): A indicação de qual operação o servidor deverá realizar para atender a requisição do cliente, isto é, a indicação de qual método o objeto deverá executar. A referência a um objeto específico que realizará a operação. O mecanismo de retorno da informação de sucesso ou falha na execução de uma requisição. Essa informação é chamada de exceção ( exception ). O Capítulo 3 da especificação The Common Objet Request Broker: Architecture and Specification (CORBA, 1998) descreve os tipos de exceções possíveis. 109

6 Opcionalmente, a referência ao objeto de contexto. Essa referência contém informações adicionais propagadas pelo cliente ao servidor. Objetos de contexto armazenam suas informações como uma lista de propriedades, consistindo de um identificador e um string associado. Por exemplo, um objeto de contexto teria um identificador display para indicar o dispositivo de display que um usuário final está utilizando e associado a esse identificador o string PC. O servidor receberia junto a requisição a informação que um determinado usuário final está utilizando como display um PC. Os argumentos específicos, zero ou mais, da operação que está sendo requisitada. Assim, a informação associada a uma requisição consiste da identificação do objeto alvo, da identificação do serviço e dos parâmetros (zero ou mais) necessários para sua realização IDL Em qualquer aplicação distribuída o cliente e o servidor necessitam de algumas informações básicas para comunicarem-se; como exemplo, o cliente precisa conhecer quais operações e seus respectivos argumentos estão disponíveis para serem requisitadas. No CORBA essa informação é incluída na interface. A interface define as características e o comportamento de objetos, incluindo as operações que podem ser requisitadas a esses objetos. Usando a terminologia de orientação a objeto uma interface é similar a uma classe (Otte et al, 1996). Para definir interfaces, o CORBA utiliza a linguagem de definição de interfaces ( Interface Definition Language - IDL). IDL é uma linguagem puramente declarativa, isto é, ela declara o conjunto dos nomes dos métodos do objeto e seus respectivos parâmetros. IDL é uma linguagem de definição e não de 110

7 programação. A IDL é utilizada para definir interfaces e estruturas de dados e não para escrever algoritmos (Otte et al, 1996). Clientes e objetos podem ser implementados em qualquer linguagem de programação, pois os clientes, através da utilização das interfaces em IDL, possuem todas as informações necessárias para requisitar uma operação ao objeto. Clientes não precisam conhecer os detalhes da implementação do objeto (Orfali et al, 1996). Diferentes linguagens de programação, orientadas ou não a objetos, apresentam maneiras diferentes de acessar objetos CORBA. Para as linguagens orientadas a objeto, os objetos CORBA podem ser vistos como objetos da linguagem de programação utilizada, enquanto para linguagens não orientadas a objeto é interessante esconder referências a objetos, nomes de métodos, etc. Para conseguir estes diferentes tipos de acesso, faz-se um mapeamento da IDL para diferentes linguagens de programação. Este mapeamento, por exemplo, permite que tipos de dados específicos da linguagem de programação utilizada para desenvolver um cliente tenham uma correspondência em IDL. IDL suporta mapeamento para várias linguagens de programação, tais como: Java, C, C++, Smalltalk, Cobol e Ada95.. A Figura 5.3 mostra um exemplo da IDL CORBA mapeada para a linguagem de programação C. Os Capítulos de 19 a 24 da especificação The Common Objet Request Broker: Architecture and Specification (CORBA, 1998) descrevem os mapeamentos da IDL a várias linguagens de programação. 111

8 Parâmetro definido pelo usuário IDL Interface foo { void operation ( inout long param ) raises ( USER_EXCEPTION ) context ( LOCAL_SYSTEM_CONTEXT ); } Parâmetro definido pelo usuário C typedef CORBA_Object foo; void foo_operation ( foo o, long *param, Context col, Enviroment *ev ); Object Parameter (especifica a aplicação servidora) 2. Informação de contexto (informação adicional - opcional) 3. Informação de retorno de exceção (exceçôes padrão e definidas pelo usuário) Fig. 5.3 Exemplo de IDL CORBA mapeada para C FONTE: Mowbray e Ruh (1997, p.74) Na Figura 5.3 nota-se que o parâmetro definido pelo usuário é de entrada e saída (inout), isto porque, os parâmetros são identificados por três posições. Pode haver um parâmetro de entrada (in) onde o argumento é passado do cliente para o servidor; um parâmetro de saída (out) onde o argumento é passado do servidor para o cliente e um parâmetro de entrada ou saída (inout) onde um valor é passado para o servidor, possivelmente modificado para ser retornado para o cliente. Uma requisição também pode retornar um único valor como resultado ou o resultado pode estar armazenado num parâmetro de saída ou num parâmetro de entrada ou saída (CORBA, 1998). IDL é considerada, no padrão CORBA, como um item fundamental sendo também um padrão ISO de número IDL CORBA é uma linguagem 112

9 independente, possuindo características sintáticas e semânticas próprias. IDL obedece a algumas regras léxicas do C++ com novas palavras chaves para permitir o conceito de distribuição. Mantém todas as características de préprocessamento padrão do C++. A sua gramática é um subconjunto do padrão ANSI C++ com construções adicionais para suportar mecanismos de invocação. IDL CORBA se encontra descrita, de forma detalhada, no Capítulo 3 da especificação The Common Objet Request Broker: Architecture and Specification (CORBA, 1998). O arquivo escrito em IDL CORBA, Figura 5.4, define os tipos de dados, operações e objetos que o cliente pode utilizar para fazer suas requisições e que o servidor deve prover para a implementação de um dado objeto. Por exemplo, um arquivo IDL CORBA descreve uma interface Empregado que define as operações promoção e demissão, tipos de dados definidos pelo usuário e uma constante. A aplicação do cliente que utiliza esse arquivo deve ser capaz de requisitar as operações promoção e demissão, utilizar os tipos de dados especificados e a constante. O servidor que satisfará a requisição deste cliente deve ser capaz de realizar o trabalho associado as operações promoção e demissão, manipular os tipos de dados especificados e a constante. Interface Empregado { void promoção ( in char nova_colocação ); void demissão ( in Cod_Demissão razão, in string descrição ); }; Fig. 5.4 Exemplo de uma definição de interface FONTE: Otte et al (1996, p.2-4) 113

10 5.3.3 INSTÂNCIAS E REFERÊNCIAS DE OBJETOS Para identificar uma instância de objeto o CORBA utiliza uma referência de objeto para essa instância. Por exemplo, um cliente para requisitar uma operação de promoção num determinado objeto Empregado deverá identificar esse objeto especificando na requisição sua referência de objeto. A representação interna da referência de objeto depende da implementação do fornecedor do produto que segue as especificações CORBA, entretanto todas as referências de objetos tem a mesma representação externa para uma dada linguagem de programação (Orfali et al, 1996). Isso torna a aplicação portável entre diferentes produtos. O fato do CORBA passar a referência do objeto ao invés do objeto específico permite aos desenvolvedores usar linguagens de programação não orientadas a objeto, assim como, diferentes linguagens de programação para escrever aplicações clientes e servidoras (Otte et al, 1996) IMPLEMENTAÇÂO DE OBJETOS A implementação de um objeto é parte da aplicação servidora que realiza a requisição de uma operação num objeto específico. A implementação do objeto existe na aplicação servidora e contém um ou mais métodos, os quais são trechos de código que realizam o trabalho requisitado a ela. Por exemplo, se o cliente requisita a operação de promoção num Empregado específico, a implementação do objeto utiliza seus métodos para realizar a promoção desse Empregado. A Figura 5.5 ilustra um cliente associado e a uma implementação no servidor. 114

11 Aplicação Cliente Aplicação Servidora Refência de Objeto do Empregado A Operação de Promoção Operação de Demissão Definição de Interface Interface Empregado { void promoção (in char nova_colocação); void demissão (in Cod_Demissão razão, in string descrição); }; Implementação de Empregado Método Promoção Método Demissão Fig. 5.5 Um cliente associado a uma implementação no servidor FONTE: Otte et al (1996, p.2-5) 115

12 5.4 ARQUITETURA CORBA A Figura 5.6 mostra a arquitetura CORBA. Cliente Implementação do objeto Interface de Invocação Dinâmica Stubs Interface ORB Skeleton Estático Skeleton Dinâmico Adaptador de Objeto Core ORB Repositório de Interfaces Repositório de Implementação Interface idêntica para todas as implementações de ORB. Podem existir múltiplos adaptadores de objetos. Existem stubs e skeletons para cada tipo de objeto. Interface que depende do ORB. Fig. 5.6 Arquitetura CORBA FONTE: Adaptada de CORBA (1998, p.2.3) 116

13 No topo da Figura 5.6, fora do ORB, estão representados o cliente e a implementação do objeto. O restante na Figura 5.6 representa elementos pertencentes ao ORB. Abaixo na Figura 5.6 está o core (núcleo) do ORB, cujos detalhes não são controlados pela especificação CORBA. O core do ORB pode ser implementado da maneira que o seu fornecedor desejar (Mowbray e Ruh, 1998). Um cliente pode tomar um dos dois caminhos para fazer uma invocação ao objeto: via stubs ou através da Interface de Invocação Dinâmica. Utilizando stubs um cliente acessa um método de um objeto remoto da mesma maneira que acessaria um outro residindo no seu próprio espaço de endereçamento. As rotinas dos stubs são geradas, automaticamente, no momento da compilação do arquivo contendo a descrição em IDL da interface do objeto CORBA a ser invocado, devendo ser linkado com a aplicação do cliente. Os stubs acessam as referências do objeto e interagem com o ORB para realizar a invocação requisitada. Os stubs dependem do ORB, pois, utilizam-se de mecanismos otimizados para interagir com ele e do mapeamento da linguagem de programação do cliente em IDL. Diferentes fornecedores de ORB apresentam diferentes stubs. Quando utiliza stubs o CORBA suporta somente comunicação síncrona. Utilizando a Interface de Invocação Dinâmica ( Dynamic Invocation Interface - DII) um cliente, em tempo de execução, invoca um objeto CORBA sem o auxílio dos stubs. Para isto, é necessário especificar, na invocação dinâmica do objeto CORBA, o método a ser executado e o seu conjunto de parâmetros. Tal recurso é necessário quando não se tem acesso aos arquivos com os stubs criados em tempo de compilação. O Capítulo 5 da especificação The Common Objet Request Broker: Architecture and Specification (CORBA, 1998) descreve, de forma detalhada, esta interface. Essa interface é de especial interesse para certos tipos de aplicações que precisam ter acesso a objetos remotos em tempo de execução, porém necessita do auxílio do Repositório de Interfaces descrito a 117

14 seguir. CORBA suporta tanto comunicação síncrona quanto assíncrona quando utiliza DII. No CORBA para a implementação do objeto não existe diferença se a requisição feita pelo cliente utilizou stub ou DII (Mowbray e Ruh, 1997) (Orfali et al, 1996). O Repositório de Interfaces contém a descrição das interfaces dos objetos CORBA nele registrados, isto é, possuem o mesmo tipo de informação contido nos stubs. As suas APIs permitem o acesso, o registro e atualização destas informações, auxiliando a construção de invocações dinâmicas através da DII. Tais informações contidas no repositório podem ser consideradas como metadados dos objetos CORBA (Queiroz e Madeira, 1998). O Capítulo 8 da especificação The Common Objet Request Broker: Architecture and Specification (CORBA, 1998) descreve, de forma detalhada, este repositório. A Figura 5.7 mostra a invocação via stubs e DII. 118

15 Invocação via Stub Adaptador de Objeto Aplicação Cliente Aplicação Servidora Refência de Objeto do Empregado A Operação de Promoção Stub do Cliente ORB Skeleton do Servidor Implementação de Empregado Método Promoção Operação de Demissão Método Demissão Invocação Dinâmica Associado a Repositório de Interface Usada para Gerar Usada para Gerar Carregada no Definição de Interface Interface Empregado { void promoção ( in char nova_colocação ); void demissão ( in Cod_Demissão razão, in string descrição ); Fig. 5.7 Invocação via stubs e DII FONTE: Otte et al (1996, p.8.8) Um servidor é composto de uma aplicação servidora contendo uma ou mais implementações de um determinado objeto executando a requisição do cliente. 119

16 Quando o cliente envia uma requisição para o ORB, este seleciona a implementação que satisfaz a requisição e usa o Adaptador de Objeto ( Object Adapter - AO) para direcionar a requisição para a implementação correspondente. O Adaptador de Objeto utiliza dos skeletons para chamar os métodos na implementação. Skeletons estáticos são responsáveis por prover uma conexão entre os Adaptadores de Objeto e os métodos que executam as operações num objeto. Eles contêm as informações necessárias para mapear uma operação, num objeto, na implementação e método apropriados. São similares aos stubs do cliente, sendo gerados, automaticamente, no momento da compilação do arquivo contendo a descrição em IDL de cada método do objeto CORBA. São dependentes do Adaptador de Objeto. Caso objetos CORBA não possuam os correspondentes skeletons estáticos os skeletons dinâmicos serão responsáveis por oferecer um mecanismo de acesso a esses objetos. Tal recurso inspeciona os valores dos parâmetros da mensagem recebida para determinar o objeto destinatário e o correspondente método, ele pode utilizar para obter informações o Repositório de Interfaces (CORBA, 1998). O Capítulo 6, da especificação The Common Objet Request Broker: Architecture and Specification, (CORBA, 1998) descreve, de forma detalhada, esta interface. No CORBA, os clientes não sabem se a implementação utilizada pelo objeto está recebendo a sua requisição de forma estática ou dinâmica (Mowbray e Ruh, 1997) (Orfali et al, 1996). Um Adaptador de Objeto Básico ( Basic Object Adapter BOA), mostrado na Figura 5.8, é responsável por (CORBA, 1998) (Orfali et al, 1996): Gerar e interpretar referências de objetos. 120

17 Invocar métodos. Garantir segurança. Ativar e desativar objetos. Mapear as referências dos objetos às suas correspondentes implementações. Registrar implementações. Implementação do objeto Métodos da interface A Métodos da interface B Skeleton dinânico Skeleton interface A Skeleton interface B Interface do Adaptador de Objeto Core ORB Fig. 5.8 Estrutura típica do Adaptador de Objeto FONTE: CORBA (1998, p.2.14) Podem existir vários adaptadores de objeto, mas como a interface do Adaptador de Objeto é algo que depende da implementação do objeto é interessante que não existam diferentes tipos de adaptadores para a mesma implementação. A maioria dos Adaptadores de Objeto são projetados para cobrir uma faixa larga de implementações, objetivando restringir o projeto de um novo adaptador. Isto ocorrerá somente quando uma implementação requeira um serviço ou uma interface muito diferente. O Adaptador de Objeto Portável ( Portable Object Adapter POA) foi especificado de forma a prover 121

18 um Adaptador de Objeto que possa ser usado em múltiplos ORBs, isto é, um Adaptador de Objeto que, com um mínimo de alteração, possa interagir com diferentes ORBs. O Capítulo 9 da especificação The Common Objet Request Broker: Architecture and Specification (CORBA, 1998) descreve o POA de forma detalhada (projeto, modelo abstrato, interfaces, etc.). O Repositório de Implementação contém informações que permite ao ORB localizar e ativar implementações de objetos. CORBA usa esse repositório para associar referências de objetos à implementações, assim como, ele usa o Repositório de Interface para associar referências de objetos à suas interfaces. O Adaptador de Objeto utiliza as informações sobre as implementações nele contidas, mas a maior parte da informação é específica de um determinado fornecedor de ORB, como por exemplo, implementações utilizadas para instalar ou administrar o servidor. CORBA não apresenta especificações rígidas para o Repositório de Implementação. A Figura 5.9 mostra como as informações das interfaces e das implementações do objeto se relacionam. A interface é definida em IDL e/ou está presente no Repositório de Interface. A definição é usada para gerar os stubs do cliente e os skeletons da implementação do objeto. A informação das possíveis implementações do objeto são providas em tempo de instalação, estando armazenadas no Repositório de Implementação para uso durante o envio de uma requisição (CORBA, 1998). 122

19 Definições em IDL Implementação instalada Repositório de Interface Stubs Skeletons Repositório de Implementação Cliente Implementação do objeto Fig. 5.9 Relacionamento entre Repositórios de Interface e Implementação FONTE: CORBA (1998, p.2.6) Finalizando, tem-se a Interface ORB. Esta interface não depende de nenhum Adaptador de Objeto. Suas operações são as mesmas para todos os ORBs podendo atender tanto clientes como implementações de objetos. São operações implementadas pelo próprio ORB, como exemplo, operaçôes com referências de objetos, inicialização do ORB, etc. O Capítulo 4 da especificação The Common Objet Request Broker: Architecture and Specification (CORBA, 1998) descreve, de forma detalhada, esta interface. 5.5 INTEROPERABILIDADE CORBA As especificações CORBA possibilitam a comunicação ORB a ORB, isto é, a interoperabilidade entre ORBs ( interorbability ). Um ORB, como já descrito, provê mecanismos pelos quais objetos, de forma transparente, enviam requisições e recebem respostas. Um ORB permite interoperabilidade entre 123

20 aplicaçôes executando em diferentes máquinas em ambientes distribuídos heterogêneos. A interoperabilidade entre ORBs estende esta definição para o caso em que o cliente e o objeto servidor estejam em diferentes ORBs, isto é, de forma transparente, objetos enviam requisições e recebem respostas. CORBA especifica uma abordagem detalhada e flexível para dar suporte a objetos distribuídos, através de redes, gerenciados por ORBs heterogêneos. Esta abordagem permite que seus elementos possam ser combinados de várias maneiras a satisfazer uma ampla faixa de necessidades (CORBA, 1998) (Stone et al, 1998). Alguns dos elementos de possibilitam interoperabilidade são (CORBA, 1998): Protocolo Geral inter-orb ( General inter-orb Protocol GIOP): especifica uma sintaxe padrão de transferência (representação de dados em baixo nível) e um conjunto de formatos de mensagens para comunicação entre ORBs. GIOP é construído especificamente para interações entre ORBs e projetado para trabalhar diretamente sobre qualquer protocolo de transporte orientado a conecção. Este protocolo não requer o uso de mecanismos RPC nem se baseia nele. Ele é relativamente simples, pode ser ampliado e facilmente implementado. O Capítulo 13 da especificação The Common Objet Request Broker: Architecture and Specification (CORBA, 1998) descreve de forma detalhada este protocolo. Protocolo Internet inter-orb ( Internet inter-orb Protocol - IIOP): especifica como as mensagens GIOP são trocadas usando conecções TCP/IP. IIOP especifica um protocolo de interoperabilidade padrão para Internet, provendo uma caixa de saída (uma forma de conecção) para interoperabilização com outros ORBs compatíveis baseados neste meio de transporte. O Capítulo 13 da especificação The Common Objet Request Broker: Architecture and Specification (CORBA, 1998) descreve de forma detalhada este protocolo. 124

21 Protocolo de Ambiente Específico Inter-ORB ( environment-specific inter-orb protocol - ESIOP): este protocolo é usado como uma caixa de saída para interoperabilização com usuários que se utilizam de uma rede particular ou uma infra-estrutura de distribuição computacional diferente, por exemplo, o ambiente DCE (DCE ESIOP). O Capítulo 14 da especificação The Common Objet Request Broker: Architecture and Specification (CORBA, 1998) descreve de forma detalhada este protocolo. A Figura 5.10 mostra o relacionamento entre os protocolos inter-orb. CORBA/IDL Mandatórios para o CORBA GIOP ESIOPs IIOP Outros mapeamentos GIOP Fig Relacionamento entre os protocolos inter-orb FONTE: CORBA (1998, p.10-4) 125

22 5.6 OBJECT MANAGEMENT ARCHITECTURE O nível mais alto das especificações CORBA é a Arquitetura de Gerenciamento de Objeto ( Object Management Architecture - OMA). Ela constitui-se de (Otte et al, 1996) (Mowbray e Ruh, 1997): Serviços CORBA: são objetos que provêm um conjunto padrão de funções para a criação e controle de acesso aos objetos, rastreamento de objetos e referências de objetos, etc. Estes serviços são essencialmente um conjunto de funções criados para facilitar o desenvolvimento de aplicações, assim, o desenvolvedor pode chamar estas funções ao invés de criar as suas próprias. Como exemplo tem-se: serviço de identificação de objetos por nomes utilizados para localizar objetos, serviços de eventos utilizados para comunicação entre objetos, serviço de ciclo de vida utilizado para controle da criação de objetos, serviço de persistência utilizado para armazenagem de objetos, etc. Facilidades CORBA: são coleções de objetos que provêm um conjunto de funções de alto nível de propósito geral para serem utilizadas em diferentes aplicações, tais como, facilidades para gerenciar a composição de documentos, acessar banco de dados, imprimir arquivos, gerenciar a temporização em um ambiente distribuído, etc. Domínios CORBA: suportam tarefas de domínios específicos associados a segmentos de mercado como manufatura, finanças e telecomunicações. Objetos aplicativos: provêm um conjunto de objetos que executam tarefas específicas para usuários finais. São essencialmente aplicações orientadas a objeto desenvolvidas para prover capacidades de negócios ( bussiness capabilities ). A OMG não padroniza estes objetos. A Figura 5.11 mostra a arquitetura OMA, onde o ORB possui o papel de roteador das requisições entre os serviços CORBA (CORBAservice), as 126

23 facilidades CORBA (CORBAfacilities) e os domínios CORBA (CORBAdomains). Objetos Aplicativos Domínios CORBA Facilidades CORBA ORB Serviços CORBA Fig Arquitetura de Gerenciamento de Objeto (OMA) FONTE: Mowbray e Ruh (1997, p.9) 5.7 SERVIÇOS CORBA Os serviços CORBA são fundamentais e globalmente aceitos. São úteis a todos os tipos de aplicação e independentes do domínio da aplicação. Os serviços CORBA compreendem quatro categorias (Mowbray e Ruh, 1997): Serviços de gerenciamento de informação. Serviços de gerenciamento de tarefas. Serviços de gerenciamento de sistema. Serviços de infra-estrutura. 127

24 5.7.1 SERVIÇOS DE GERENCIAMENTO DE INFORMAÇÃO Os serviços de gerenciamento de informação são constituídos de: SERVIÇO DE PROPRIEDADE Uma propriedade é similar a um atributo. Propriedades são conjuntos de valores que podem ser associados dinamicamente a objetos. Como exemplos de propriedade (CORBAservices, 1998): Propriedade de classificação de objeto: por exemplo, um documento pode ser classificado como sendo importante e deve ser lido ao final do dia. Outro documento pode ser classificado como menos importante e será lido somente ao final do mês, enquanto um outro pode ser classificado como não importante. A classificação dos documentos é arbitrada pelo usuário, não fazendo parte do tipo do documento, entretanto, por se tratar de uma propriedade, pode-se utilizar utilitários para manusea-las, como por exemplo, encontrar todos os documentos considerados importantes. Propriedade que contém um contador de uso do objeto: um utilitário incrementa um contador toda vez que um objeto é utilizado pelo usuário. Esta informação é associada ao objeto, mas não faz parte do tipo do objeto. O Capítulo 13 da especificação CORBAservices: Common Object Services Specification (CORBAservices, 1998) descreve este serviço de forma detalhada. 128