CAPÍTULO 5 CORBA 5.1 MODELO DE OBJETO

(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

(2)

outro (servidor) através da rede. CORBA acrescenta a este modelo as características descritas a seguir (Otte et al, 1996).

5.2.1 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).

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). Cliente Servidor Requisição Relacionamento cliente/servidor Servidor Cliente ORB

(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.

Fig. 5.2 – Múltiplos clientes e servidores com ORB FONTE: Otte et al (1996, p.1-9) Cliente Cliente Cliente ORB Servidor Servidor Servidor

(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.

5.2.2 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 .

5.2.3 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.

(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.

5.3.1 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.

(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.

5.3.2 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

(7)

111

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.

(8)

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 14750. IDL CORBA é uma linguagem

IDL

Interface foo {

void operation ( inout long param ) raises ( USER_EXCEPTION )

context ( LOCAL_SYSTEM_CONTEXT ); }

Parâmetro definido pelo usuário

1 ₂

1. “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) C typedef CORBA_Object foo;

void foo_operation ( foo o, long *param, Context col, Enviroment *ev );

(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.

Fig. 5.4 – Exemplo de uma definição de interface FONTE: Otte et al (1996, p.2-4)

Interface Empregado {

void promoção ( in char nova_colocação ); void demissão ( in Cod_Demissão razão,

in string descrição ); };

(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).

5.3.4 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.

(11)

Fig. 5.5 – Um cliente associado a uma implementação no servidor FONTE: Otte et al (1996, p.2-5) Aplicação Cliente Refência de Objeto do Empregado A Operação de Promoção Operação de Demissão Aplicação Servidora Implementação de Empregado Método Promoção Método 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); };

(12)

5.4 ARQUITETURA CORBA

A Figura 5.6 mostra a arquitetura CORBA.

Fig. 5.6 – Arquitetura CORBA

FONTE: Adaptada de CORBA (1998, p.2.3)

Cliente Implementação do objeto

Interface de Invocação Dinâmica Stubs _Interface ORB Core ORB Skeleton Estático Skeleton Dinâmico Adaptador de Objeto

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.

Repositório de

(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

(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 meta-dados 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.

(15)

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.

Aplicação Cliente ORB Aplicação Servidora Skeleton do Servidor Implementação de Empregado Método Promoção Método Demissão Refência de Objeto do EmpregadoA Operação de Promoção Operação de Demissão Stub do Cliente Adaptador de Objeto Invocação via Stub

Invocação Dinâmica Repositório de Interface 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 );

Usada para Gerar Associado a

Usada para Gerar

(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):

(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.

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

Implementação do objeto Skeleton dinânico Métodos da interface B Métodos da interface A Skeleton

interface A Skeletoninterface B

Core ORB

Interface do Adaptador

(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).

(19)

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

Definições

em IDL Implementaçãoinstalada

Repositório

de Interface Repositório deImplementação

Implementação do objeto Cliente

(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.

(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.

Fig. 5.10 – Relacionamento entre os protocolos inter-ORB FONTE: CORBA (1998, p.10-4) CORBA/IDL ESIOPs GIOP IIOP Outros mapeamentos GIOP Mandatórios para o CORBA

(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

(23)

facilidades CORBA (CORBAfacilities) e os domínios CORBA (CORBAdomains).

Fig. 5.11 – 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.

Objetos

Aplicativos DomíniosCORBA FacilidadesCORBA

ORB

(24)

5.7.1 SERVIÇOS DE GERENCIAMENTO DE INFORMAÇÃO

Os serviços de gerenciamento de informação são constituídos de:

5.7.1.1 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.

(25)

5.7.1.2 SERVIÇO DE RELACIONAMENTO

Objetos distribuídos são freqüentemente utilizados para modelar entidades do mundo real. Eles não estão isolados, mas relacionados uns aos outros. O serviço de relacionamento permite que estes objetos e seus relacionamentos sejam explicitamente representados. Para este fim ele utiliza-se de grafos (CORBAservices, 1998). O objeto utiliza-se do serviço de relacionamento para manter todas as referências dos objetos aos quais ele está relacionado.

O serviço de relacionamento define dois tipos de objetos: objetos relacionamentos (“relationships”) e objetos papéis (“role”). Um relacionamento entre dois ou mais objetos é definido por um conjunto de papéis. Por exemplo, numa relação empregatícia, uma empresa tem o papel de empregadora e uma pessoa o papel de empregada. Um objeto pode representar diferentes papéis em diferentes relacionamentos, por exemplo, uma determinada pessoa é empregada e também cantora. Um objeto relacionamento pode ter qualquer número de papéis e a cardinalidade, isto é, o número máximo de relacionamentos nos quais um papel está envolvido, pode ser especificado e controlado. A Figura 5.12 mostra que, para relacionar dois objetos, necessita-se de um objeto relacionamento especificando a operação que liga o empregador ao empregado e dois objetos papéis indicando respectivamente o papel do empregado e do empregador na relação empregatícia. Este serviço permite em tempo de execução a criação de novos relacionamentos entre objetos, sem que haja necessidade de alterar a implementação dos mesmos (Orfali et al, 1996), pois novos objetos relacionamentos e papéis podem ser ligados aos objetos aumentando o grafo. Caminhando no grafo obtém-se todos os relacionamentos em que um objeto está presente e quais seus respectivos papéis.

(26)

Fig. 5.12 – Exemplo de um Serviço de Relacionamento

FONTE: Adaptada de Mowbray e Ruh (1997, p.100)

5.7.1.3 SERVIÇO DE CONSULTA

O serviço de consulta (“query”) define interfaces genéricas que provêem operações realizadas em coleções de objetos, podendo obter como retorno também coleções de objetos. A consulta pode ser especificada usando uma derivação do SQL para objetos e/ou linguagens de consulta orientadas a objeto. O termo consulta (“query”) é utilizado para denotar operações gerais de

Objeto Empresa Objeto Pessoa Objeto Relacionamento (emprego) Objeto Papel (empregado) Objeto Papel (empregador) Objeto Conjunto Musical Objeto Relacionamento (hobby) Objeto Papel (propiciar o hobby) Objeto Papel (cantora)

(27)

manipulação que incluem seleção, inserção, atualização e “deleção” de uma coleção de objetos (CORBAservices, 1998).

Os serviços de consulta podem suportar consulta estática e dinâmica. Consulta estática são consultas representadas como extensão sintática da linguagem de programação, isto é, são “statements” escritos diretamente no software e conhecidos em tempo de compilação. Consultas dinâmicas são consultas geradas em tempo de execução (Mowbray e Ruh, 1998).

5.7.1.4 SERVIÇO DE “EXTERNALIZAÇÃO”

“Externalização” é o processo de converter estruturas de dados numa forma que possibilite armazená-las ou transmiti-las. Este processo envolve remoção de ponteiros e conversão de dados binários em uma representação que possa ser considerada um “stream” de bytes sem nenhuma estrutura interna adicional (Mowbray e Ruh, 1997).

“Externalização” faz parte também do processo de “marshaling” que ocorre quando um “stub” e “skeleton” estáticos convertem parâmetros definidos em linguagem de alto nível em informação comunicável através da rede. Quando um dado existe no estado externalizado, qualquer de suas estruturas de dados deve ser reconstituída antes de ser utilizada. Este processo é chamado de “internalização”.

(28)

5.7.1.5 SERVIÇO DE PERSISTÊNCIA DE OBJETO

O serviço de persistência provê interfaces comuns aos mecanismos responsáveis pelo armazenamento e gerenciamento dos objetos persistentes, sejam eles em arquivos, banco de dados relacional ou banco de dados orientado a objeto. A Figura 5.13 mostra os componentes deste serviço.

Fig. 5.13 – Exemplo de um Serviço de Persistência de Objeto FONTE: CORBAservices (1998, p.5.1)

Um objeto poderá estar em um dos dois estados: o primeiro é o estado dinâmico, o objeto está na memória e não é preservado se ocorrer uma falha no sistema. O segundo é o estado persistente, o objeto armazenado numa memória estável pode a partir dela reconstruir o seu estado dinâmico (CORBAservices, 1998).

O serviço de persistência permite ao objeto manter-se (“persist”) mesmo após a desativação da aplicação que o criou ou do cliente que o utilizou. O ciclo de

Cliente

Objeto

Estado Dinâmico

Serviço de Persistência de Objeto

Estado Persistente

(29)

vida de um objeto pode ser relativamente curto ou indefinido, assim esse serviço armazena o estado do objeto e o restaura quando necessário.

5.7.1.6 SERVIÇO DE COLEÇÃO

Serviço de coleção define interfaces que suportam operações de manipulação sobre um grupo de objetos. Filas, conjunto, mapas, etc. são tipos comuns de coleção. Como exemplo de operações suportadas pelas coleções tem-se: inserção de um novo elemento, teste se um elemento pertence à coleção, união, interseção, cardinalidade, teste de iqualdade, etc. (CORBAservices, 1998).

As operações de manipulação suportadas pelos objetos da coleçâo dependem da natureza do agrupamento realizado por um usuário. Por exemplo, coleções podem ser ordenadas para suportar acesso a um elemento na posição “i”, enquanto outras coleções podem suportar acesso a um elemento via uma chave. Em um tipo de coleção, um determinado elemento só pode ocorrer uma vez, enquanto em outros pode ocorrer múltiplas vezes. O usuário escolhe o tipo de coleção que melhor se adapte a sua aplicação.

(30)

5.7.2 SERVIÇOS DE GERENCIAMENTO DE TAREFAS

Os serviços de gerenciamento de tarefas são constituídos de:

5.7.2.1 SERVIÇO DE EVENTOS

O serviço de eventos define interfaces genéricas para passar informações entre múltiplos fornecedores e consumidores de eventos. Fornecedor é aquele que produz o evento, e consumidor é aquele que o processa. Os fornecedores e consumidores dos eventos não se conhecem diretamente. Este serviço desacopla os fornecedores dos consumidores dos eventos.

Este serviço provê mecanismos permitindo que múltiplos consumidores registrem seu interesse em receber algum evento. Existem duas abordagens para iniciar a comunicação dos eventos. A primeira é conhecida como “push model” e permite que o fornecedor de eventos inicie a transferência do mesmo para o consumidor. A segunda é conhecida como “pull model” e permite que o consumidor do evento requisite-o do fornecedor. No “push model” a iniciativa é tomada pelo fornecedor e no “pull model” é o consumidor que toma a iniciativa (CORBAservices, 1998).

5.7.2.2 SERVIÇO DE CONCORRÊNCIA

Serviço de concorrência é um serviço de propósito geral que assegura que o acesso a um objeto distribuído seja realizado de maneira atômica. Este serviço coordena o acesso concorrente a um objeto de tal forma que a sua consistência não seja comprometida. A coordenação de acesso detecta

(31)

quando múltiplos clientes concorrentes acessam um único objeto e, se este fato ocasionar qualquer situação conflitante, esta será harmonizada de forma a manter o estado do objeto consistente (CORBAservices, 1998).

O uso do objeto de forma concorrente é obtido através de bloqueios. Cada bloqueio é associado a um único objeto e a um único cliente. Assim, o cliente deve obter o bloqueio apropriado antes de acessar o objeto compartilhado. O serviço de concorrência provê modos de bloqueio (“lock modes”). Existem diferentes tipos de bloqueio como: bloqueio de leitura (“read lock”), bloqueio de escrita (“write lock”), bloqueio de atualização (“update lock”), intenção de bloquear para leitura (“intention read”), intenção de bloquear para escrita (“intention write”) (Mowbray e Ruh, 1997).

5.7.2.3 SERVIÇO DE TRANSAÇÃO

O serviço de transação suporta o conceito de transação. Esse conceito foi primeiramente utilizado na proteção das informações de banco de dados, sendo, recentemente estendida de forma a abranger a computação distribuída, permitindo a construção de aplicações distribuídas confiáveis (CORBAservices, 1998).

Uma transação é uma unidade de trabalho que possui as seguintes características (ACID):

• Uma transação é atômica (A), se interrompida por uma falha, todos os efeitos por ela gerados são desfeitos.

(32)

• Uma transação produz resultados consistentes (C), cujos efeitos preservam propriedades invariantes.

• Uma transação é isolada (I), os estados intermediários não são visíveis a outras transações. A execução de uma transação parece serial, mas ela é realizada de forma concorrente.

• Uma transação é durável (D), os efeitos de uma transação são persistentes. Só são perdidos quando acontece uma falha catastrófica.

O serviço de transação define interfaces que permitem a múltiplos objetos distribuídos cooperarem para prover atomicidade. Este serviço atende todos os tipos de aplicações baseadas em objeto que modificam o estado de múltiplos objetos num sistema distribuído (Mowbray e Ruh, 1998).

5.7.3 SERVIÇOS DE GERENCIAMENTO DE SISTEMA

Os serviços de gerenciamento de sistema são constituídos de:

5.7.3.1 SERVIÇO DE NOMEAÇÃO

O serviço de nomeação é um serviço genérico de diretório análogo a uma lista telefônica, isto é, se o cliente possui o nome do objeto, ele pode, através deste serviço, recuperar a referência do objeto (Mowbray e Ruh, 1998). Este serviço é utilizado para que objetos localizem outros objetos (Orfali et al, 1996).

Os objetos são identificados por nomes possíveis de serem lidos pelo homem, assim o serviço de nomeação mapeia estes nomes às referências de objeto. A associação nome-para-referência de objeto é chamada de nome de ligação

(33)

(“name binding”). O nome de ligação é sempre definido em relação a um nome de contexto (“name context”), que é um objeto contendo um conjunto de nomes de ligação, onde num determinado conjunto todos os nomes de ligação são únicos. O nome é sempre resolvido em relação a um nome de contexto, pois não existem nomes absolutos. Todo o objeto tem uma referência de objeto única, mas opcionalmente, pode-se associar a ela um ou mais nomes.

O serviço de nomeação cria hierarquias de nomes. Os clientes navegam por árvores de nomes de contexto (“naming graph”) para buscar o objeto desejado. Obtem-se a referência de um objeto CORBA através da sequência de nomes de contexto na árvore. Na Figura 5.14 cada nó é um nome de contexto. O nome do objeto consiste de uma sequência de nomes de contexto, onde o último nome, a folha da árvore, é o nome da instância do objeto (CORBAservices, 1998) (Orfali et al, 1996). Por exemplo, na Figura 5.14 o nome da instância de objeto “Playa Blanca” é obtido pela sequência dos nomes de contexto “Resorts” -> “México” -> “Club Med” .

As operações chaves do serviço de nomeação são de “ligar” (“bind”) e “resolver” (“resolve”). A operação de “ligar” é usada para adicionar um nome de objeto e sua referência de objeto no diretório do serviço, isto é, criar um nome de ligação num determinado nome de contexto. Na operação de “resolver” o cliente entra com um nome de objeto particular e recebe uma referência de objeto como valor de retorno ou uma exceção caso o nome não se encontre no diretório, isto é, determina o nome de ligação associado ao objeto num dado nome de contexto.

(34)

Fig. 5.14 – Exemplo de um gráfico de nomes FONTE: Orfali et al (1996, p.111)

Quando uma aplicação usa o serviço de nomeação ela precisa conhecer os nomes dos objetos registrados no diretório do serviço. Primeiro a aplicação tenta “resolver” o nome correspondente ao objeto. Uma vez obtida a referência do objeto ela pode invocar as operações no objeto.

rEResorts

México Greece Hawaii

Club Med

Playa Blanca Ixtapa Cancun

(35)

5.7.3.2 SERVIÇO DE CICLO DE VIDA

O serviço de ciclo de vida define os serviços e as convenções para criação, “deleção”, cópia e movimentação de objetos.

Esse serviço utiliza-se das fábricas de objetos (“Factory Objects”). Uma fábrica de objetos é um objeto CORBA que sabe como instânciar objetos, por exemplo, uma fábrica de objetos “funcionários” sabe como criar instâncias de objetos “funcionários”, isto é, objetos da classe funcionários. As fábricas de objeto gerenciam os objetos intanciados por ela (CORBAservices, 1998) (Mowbray e Ruh, 1997).

Para criar um determinado objeto um cliente deve encontrar a fábrica de objetos correspondente, emitir uma requisição de criação e receber como retorno a referência do objeto criado. Para que um cliente encontre a fábrica de objetos desejada o serviço de ciclo de vida define objetos localizadores de fábricas de objetos (“Factory Finder Objects”). Um objeto localizador de fábrica de objetos mantêm um diretório das várias fábricas de objetos existentes numa determinada localização da rede. A fábrica de objetos além de instânciar o objeto, registra e aloca recursos para ele, por exemplo, uma armazenagem persistente.

Para “deletar” um objeto, o cliente deve possuir a sua referência de objeto e fazer uma requisição de sua remoção (CORBAservices, 1998). A operação de remoção desaloca qualquer recurso que o objeto esteja utilizando. Após a remoção qualquer objeto que faça referência a esse objeto receberá como retorno uma execção.

(36)

A cópia de objetos executa uma operação onde o objeto e sua informação de estado são copiadas. As referências que este objeto faz à outros objetos também são copiadas, mas não os objetos referenciados. As cópias são feitas na localização onde o localizador de fábrica de objeto encontrou a fábrica de objetos correspondente.

A movimentação de objetos executa uma operação onde o objeto e sua informação de estado são copiadas. O objeto é movido para a nova localização onde o localizador de fábrica de objeto encontrou a fábrica de objetos correspondente. O objeto mantém a mesma referência de objeto para que o ORB, de forma transparente, seja capaz de enviar as requisições para este objeto na sua nova localização.

5.7.3.3 SERVIÇO DE LICENCIAMENTO

O serviço de licenciamento é um serviço de propósito geral que provê proteção à propriedade intelectual, isto é, controla o acesso e a utilização de uma aplicação (produto) (Mowbray e Ruh, 1997).

A licença de um produto tem as seguintes características (CORBAservices, 1998):

• Tempo (“time”): permite que as licenças tenham tempo de início, duração e expiração.

• Valor (“value mapping”): permite aos produtores implementar um esquema de licenciamento, isto é, que unidades usarão a licença, se o uso da licença será concorrente com outras unidades, se o tempo de

(37)

uso será fixo onde, por exemplo, o produto é utilizado como demonstração.

• Consumidor (“consumer”): permite que a licença seja reservada a uma entidade específica, por exemplo, uma licença para uma máquina em particular.

5.7.3.4 SERVIÇO DE NEGÓCIOS

O serviço de negócios (“trader”) facilita a oferta e descoberta de instâncias de um tipo de serviço particular. É um diretório similar às páginas amarelas da lista telefônica (Mowbray e Ruh, 1997).

O negociante é um objeto que suporta serviço de negócios de um objeto num ambiente distribuído. Ele pode ser visto como um objeto, através do qual outros objetos podem anunciar suas capacidades. A propaganda de uma capacidade ou o oferecimento de um serviço é chamado de exportação (“export”). O atendimento de uma necessidade ou a descoberta de um serviço é chamado de importação (“import”) (CORBAservices, 1998).

Para exportação, o objeto entrega ao negociante a descrição do seu serviço e a localização da interface onde o serviço está disponível. Para importação, o objeto pergunta ao negociante qual o serviço que possui certas características. O negociante verifica nas descrições que ele possui e responde à importação qual a localização das interfaces de serviços selecionados. A importação, então, é capaz de interagir como o serviço. Estas interações são mostradas na Figura 5.15.

(38)

Fig. 5.15 – Interação entre o negociante e seus clientes

FONTE: Adaptada de CORBAservices (1998, p.16.2)

5.7.4 SERVIÇOS DE INFRA-ESTRUTURA

Os serviços de infra-estrutura são constituídos de:

5.7.4.1 SERVIÇO DE TEMPO

O serviço de tempo suporta a recuperação e sincronização de relógios num sistema distribuído. É desejável possuir um padrão preciso de tempo para sincronizar atividades distribuídas porque, por exemplo, se um relógio de sincronização tem um passo a mais que o tempo de latência de transmissão de uma mensagem, é possível recebê-la com um carimbo de tempo anterior ao tempo local (Mowbray e Ruh, 1997).

O serviço de tempo permite ao usuário (CORBAservices, 1998): Negociante

Exportador Importador 3

1 ₂

Seqüência das interações:

1. Exportação 2. Importação

(39)

• Obter o tempo corrente e, associado a ele, o seu erro estimado. • Apurar a ordem de ocorrência dos eventos.

• Gerar eventos baseados em tempo ( temporizador (“timers”) e alarmes). • Calcular o intervalo de tempo entre dois eventos.

• Utilizar duas interfaces de serviços diferentes:

• Serviço de tempo: gerencia o Tempo Universal de Objetos (“Universal Time Objects” - UTOs) e Intervalo de Tempo de Objetos (“Time Interval Objects” – TIOs).

• Serviço de Temporizador de evento: gerencia o Manejador de Temporização de Evento ( “Timer Event Handler”).

5.7.4.2 SERVIÇO DE SEGURANÇA

O serviço de segurança possui características que endereçam questões de segurança muito importantes. Suas funcionalidades são descritas a seguir (CORBAservices, 1998):

• Identificação e autenticação: verificam se usuários humanos e objetos são quem eles dizem que são e que direitos possuem.

• Autorização e controle de acesso: decidem se um objeto pode ser acessado ou não, normalmente usando sua identificação e/ou um atributo de privilégio e um atributo de controle do objeto alvo.

• Auditoria de segurança: mecanismo de auditoria capaz de identificar o usuário corretamente, mesmo depois de uma cadeia de chamados através de vários objetos.

(40)

• Segurança de comunicação: permite estabeler uma comunicação confiável entre cliente e alvo, definindo uma autenticação do cliente pelos alvos e uma autenticação dos alvos pelo cliente. Define também uma proteção de integridade e proteção de confiabilidade das mensagens transmitidas entre os objetos.

• Não repúdio: provê mecanismos para detectar tentativas de rejeição errônea do recebimento ou envio de dados.

• Administração: administra a segurança da informação.

5.8 FACILIDADES CORBA

As facilidades CORBA são, por definição, coleções de objetos que proporcionam serviços para serem utilizados diretamente pelas aplicações, englobando funcionalidades mais ricas do que as dos serviços CORBA. Podem ser definidas como sendo especializações dos serviços CORBA, herdando as suas interfaces. Como exemplo de facilidades tem-se o correio eletrônico (“e-mail”) e os documentos compostos (“compound documents”). Elas são divididas em duas categorias (CORBAfacilities, 1998):

• Facilidades horizontais (“Horizontal Common Facilities”). • Facilidades verticais (“Vertical Market Facilities”).

(41)

5.8.1 FACILIDADES HORIZONTAIS

As facilidades horizontais são constituídas de:

5.8.1.1 FACILIDADE DE INTERFACE DE USUÁRIO

A facilidade de interface de usuário é utilizada para tornar um sistema de informação acessível aos usuários ajudando o atendimento de suas necessidades (CORBAfacilities, 1998). Esta facilidade define um padrão de interfaces gráficas para as aplicações (Queiroz e Madeira, 1998). A Tabela 5.1 relaciona algumas capacidades dessa facilidade.

TABELA 5.1 - CAPACIDADES DA FACILIDADE DE INTERFACE DE USUÁRIO

Facilidade de Interface de Usuário

Capacidades

Gerenciamento de apresentação Suporta apresentação de objetos, como impressão e exibição (“display”).

Gerenciamento de apresentação composta (“Compound

Presentation”)

Suporta apresentação, por exemplo, impressão e exibição em documentos compostos (“Compound Documents”). Facilidades de suporte ao usuário Mecanismo para armazenar e apresentar

informações de ajuda (“help”) da aplicação. Gerenciamento de “desktop” Provê facilidades para o usuário final de um

“desktop”.

Suporte a texto (“script”) Provê facilidades para criação interativa de textos de comandos.

(42)

O Capítulo 2 da especificação “Common Facilities Architecture” (CORBAfacilities, 1998) descreve esta facilidade de forma detalhada.

5.8.1.2 FACILIDADE DE GERENCIAMENTO DE INFORMAÇÃO

A facilidade de gerenciamento de informação cobre aspectos de modelagem, definição, armazenamento, gerenciamento e intercâmbio de informações entre aplicativos (CORBAfacilities, 1998). A Tabela 5.2 relaciona algumas capacidades dessa facilidade.

TABELA 5.2 - CAPACIDADES DA FACILIDADE DE GERENCIAMENTO DE INFORMAÇÃO

Facilidade de Gerenciamento de Informação

Capacidades

Modelamento de informação Suporta a criação de modelos e esquemas de informação.

Facilidade de armazenamento e recuperação de informações

Suporta armazenagem persistente da informação e sua recuperação.

Intercâmbio composto (“Compound Interchange”)

Suporta intercâmbio de dados em documentos compostos (“Compound Documents”).

Intercâmbio de dados Suporta intercâmbio de dados em geral. Troca de informações Suporta troca de informações.

Codificação e representação de dados

Suporta facilidades para codificar e traduzir dados formatados.

Operações de tempo Suporta facilidades para manipulação de calendário, hora e data.

(43)

5.8.1.3 FACILIDADE DE GERENCIAMENTO DE SISTEMA

A facilidade de gerenciamento de sistema define um conjunto de serviços para monitoração e gerência de sistemas distribuídos (Queiroz e Madeira, 1998). A Tabela 5.3 relaciona algumas capacidades dessa facilidade.

TABELA 5.3 - CAPACIDADES DA FACILIDADE DE GERENCIAMENTO DE SISTEMA

Facilidade de Gerenciamento de Sistema

Capacidades

Ferramentas de gerenciamento Suporta “interoperabilidade” entre diferentes ferramentas de gerenciamento de sistemas. Controle Suporta o controle dos recursos de um

sistema.

FONTE: CORBAfacilities (1998, p.1-7)

5.8.1.4 FACILIDADE DE GERENCIAMENTO DE TAREFA

A facilidade de gerenciamento de tarefa cobre o trabalho de automação incluindo a automação dos processos do usuário e a automação dos processos do sistema (CORBAfacilities, 1998). A Tabela 5.4 relaciona algumas capacidades dessa facilidade.

(44)

TABELA 5.4 - CAPACIDADES DA FACILIDADE DE GERENCIAMENTO DE TAREFA

Facilidade de Gerenciamento de Tarefa

Capacidades

Fluxo de trabalho (“Workflow”) Provê o gerenciamento e coordenação dos objetos que são parte do processo de trabalho.

Agentes Provê suporte para agentes estáticos e dinâmicos.

Regras de Gerenciamento Suporta aquisição e manutenção de

conhecimento. Suporta também a execução de objetos baseados em regras, tais como, os agentes inteligentes.

Automação Permite o acesso a funcionalidades de um objeto por outro.

5.8.2 FACILIDADES VERTICAIS

As facilidades verticais suportam tarefas de domínios específicos associados a segmentos de mercado (CORBAfacilities, 1998). Estas facilidades provêem interfaces definidas em IDL para segmentos especializados como área financeira, saúde, transportes, seguros, etc. (Queiroz e Madeira, 1998). A Tabela 5.5 relaciona algumas capacidades dessas facilidades.

(45)

TABELA 5.5 - CAPACIDADES DAS FACILIDADES VERTICAIS

Facilidade de Mercado Vertical Capacidades

Imagens Provê “interoperabilidade” entre objetos tipo imagens e imagens relacionadas à

informação.

Simulação distribuída Suporta a interação entre múltiplos objetos simulados num ambiente virtual.

Indústria de exploração e produção de óleo e gás

Suporta “interoperabilidade” no mercado de petróleo.

Contabilidade Suporta transações comerciais.

Desenvolvimento de aplicações Suporta “interoperabilidade” entre objetos de desenvolvimento de aplicações.

Planejamento Suporta “interoperabilidade” entre objetos de desenvolvimento de planejamento.

Atualmente, a OMG tem abordado praticamente todo o espectro de tópicos relacionados à computação distribuída, como sistemas de tempo real, Internet, telecomunicações, sistemas financeiros, sistemas C4I (Command, Control, Communication, Computer and Information), comércio eletrônico, segurança, análise e projeto orientados a objeto, linguagens de programação, entre outros (Queiroz e Madeira, 1998).

5.9 OMG

OMG é um consórcio, sem fins lucrativos, que opera usando processos bem definidos para tomada de decisão, sendo constituído por dois comitês técnicos.

(46)

O primeiro deles é o Comitê Técnico de Domínios, composto por forças tarefas que tratam de tecnologias orientadas para segmentos especializados como: financeiro, de negócios, de telecomunicações e médico. O segundo é o Comitê Técnico da Plataforma composto pelas forças tarefas com o propósito de acompanhar a evolução das especificações CORBA com novos mapeamentos para linguagens de programação, serviços de objetos e facilidades comuns.

Os temas abordados pelo OMG são discutidos através de listas de discussão e publicados através de RFPs (“Request for Proposals”) e RFCs (“Request for Comments”), disponíveis para os seus membros e, posteriormente, para o público.

5.10 CONSIDERAÇÕES FINAIS

CORBA é a uma especificação para integração de objetos distribuídos. Sua proposta vai além da simples interação transparente entre objetos. A idéia é complementar as funcionalidades do barramento CORBA, como “middleware”, e oferecer infra-estruturas (“frameworks”) para auxiliar a especificação e implementação de aplicações distribuídas (Pires, 1997). A colaboração entre objetos CORBA é definida no Modelo de Referência da Arquitetura de Gerência de Objetos (OMG, 1998), mostrado na Figura 5.16.

(47)

Fig. 5.16 – Arquitetura de Gerência de Objetos FONTE: Pires (1997, p.38)

Os objetos de negócio, na Figura 5.15, são componentes específicos para aplicações voltadas a um usuário final representando objetos reais do seu negócio (Orfali et al, 1996). Por exemplo, uma conta corrente com o seu número, titulares, saldo e lançamentos com operações de saque e crédito pode ser considerado um objeto de negócio. Os objetos de negócios são os componentes mais complexos que um ORB pode suportar.

Objetos de Negócios Serviços de

Objetos Barramento

CORBA Facilidades Comuns

(48)