The content of FRAND licenses

A OMA (Object Management Architecture), descreve os objetivos técnicos e terminologias da OMG e provê a infraestrutura conceitual em que as especificações de suporte estão baseadas. A OMA inclui o modelo de objetos OMG, que foi apresentado anteriormente, e define a semântica comum para especificar as características externamente visíveis de objetos em um modo padrão de implementação, e também seu modelo de referência.

O modelo de referência identifica e caracteriza os componentes, interfaces e protocolos que compõem a OMA. Este modelo inclui o ORB, que habilita os clientes e objetos a se comunicarem em um ambiente distribuído, e quatro categorias de interfaces de objetos: os objetos de serviço, as facilidades comuns, as interfaces de domínio e os objetos de aplicação (OMG, 1996). A arquitetura do modelo de referência OMA com seus respectivos componentes pode ser vista da Figura 14 (OMG, 1996).

Object Request Broker

Object Request Broker

Interfaces de Aplicação Interfaces de Domínio Facilidades Comuns

Objetos de Serviço

Figura 14 – Modelo de referência OMA. Estrutura do ORB

O ORB é responsável por todo o mecanismo de localização da implementação do objeto para uma determinada requisição. Ele prepara a implementação do objeto para receber a requisição do cliente. O cliente enxerga a interface completamente independente de onde o objeto está localizado, qual linguagem de programação foi implementado e outros aspectos que não refletem na interface do objeto (OMG, 2002). A Figura 15 (OMG, 2002) mostra a estrutura do ORB.

As interfaces dos objetos podem ser definidas de duas formas. Estaticamente, através de uma linguagem de definição de interfaces chamada de OMG Interface

Definition Language (OMG IDL). Esta linguagem define os atributos e operações que o

objeto pode executar. Dinamicamente, através de “repositórios de interfaces”. Este serviço representa os componentes de uma interface com o objeto, permitindo o acesso destes componentes em tempo de execução. Na implementação do ORB, tanto a IDL quanto o repositório de interfaces têm equivalente poder de expressão (OMG, 2002).

Para invocações estáticas, quando um cliente faz uma requisição, esta é transformada em uma mensagem através de stubs particulares do CORBA (gerados por um compilador de linguagem IDL). A mensagem serializada (marshalling) é transmitida na rede, usando as estruturas do ORB que localiza o objeto servidor e transporta os dados de

Capítulo 3 – Tecnologias Utilizadas 75

acordo com a sintaxe de transferência. No servidor, a mensagem que chega passa o controle para o Adaptador de Objetos Portável (Portable Object Adaptor - POA) que, por sua vez, tem a responsabilidade de ativar a implementação de objeto correspondente. Os processos de deserialização (unmarshalling), e a conseqüente chamada de método de implementação do objeto, são realizados através do correspondente skeleton do objeto servidor (LUNG, 2001).

Para invocações dinâmicas, as interfaces de objetos CORBA devem estar disponíveis, armazenadas no repositório de interfaces. Uma invocação dinâmica permite ao cliente dinamicamente construir e invocar métodos do servidor usando interfaces DII22. Este tipo de chamada oferece uma grande flexibilidade para sistemas altamente dinâmicos.

O repositório de interfaces contém informações de interfaces IDL em uma forma disponível em tempo de execução para invocação dinâmica. Usando a informação disponível no repositório, é possível a um programa encontrar um objeto remoto mesmo desconhecendo sua interface, seus métodos, parâmetros e forma de ativação (LUNG, 2001).

Núcleo do ORBNúcleo do ORB

Adaptador de ObjetosAdaptador de Objetos Stub IDL Interface de Invocação Dinâmica Interface de Invocação Dinâmica Interface de Esqueleto Dinâmico Interface de Esqueleto Dinâmico Esqueleto IDL Interface do ORB Interface do ORB

Implementação do ObjetoImplementação do Objeto ClienteCliente

Figura 15 – Arquitetura CORBA. Objetos de Serviço

Objetos de serviço são serviços de propósito geral, que têm fundamental importância para o desenvolvimento de implementações baseadas em CORBA, compostas de objetos distribuídos, ou que provê uma base universal, independente do domínio da aplicação, para interoperabilidade entre aplicações (OMG, 1996).

Os objetos de serviço, chamados de CORBAservice, formam uma coleção de serviços (interfaces e objetos) que são padronizados pela OMG dentro da arquitetura OMA. Múltiplos objetos de serviço podem cooperar no sistema. Por exemplo, um serviço de suporte a grupos pode utilizar o serviço de recuperação de erros para restabelecer objetos servidores após uma falha. Além de estar de acordo com a norma CORBA, um serviço é muito mais fácil de ser padronizado do que uma extensão ao ORB, ou até mesmo um novo adaptador de objetos.

A OMG tem vários serviços definidos, tais como: serviço de nomes, serviço de notificação de eventos, serviço de ciclo de vida, serviço de persistência, serviço de relacionamento, serviço de externalização, serviço de transação, serviço de controle de concorrência, serviço de autorização, serviço de segurança e serviço de tempo.

Facilidades Comuns

As facilidades comuns, também chamadas CORBAfacilities, são coleções de interfaces aplicáveis a um grande número de domínios de aplicações. As facilidades comuns são divididas segundo dois aspectos: as facilidades comuns horizontais e as facilidades comuns verticais (OMG, 1996, LUNG, 2001). As facilidades horizontais podem ser utilizadas por diferentes aplicações, independente de seu domínio. São divididas segundo quatro categorias: interface de usuário, gerenciamento de informação, gerenciamento de sistema e gerenciamento de tarefa. As facilidades verticais são utilizadas em áreas de aplicação específicas, ou seja, domínios específicos. Como exemplo tem-se: gerenciamento e controle de imagens, supervias de informação, manufatura integrada por computador, simulação distribuída, etc.

Interfaces de Domínio

Interfaces de domínio são interfaces para domínios específicos de aplicações, tais como: financeira, saúde, telecomunicações, comércio eletrônico e transporte. O seu propósito é separar o modelo conceitual da representação de objetos, e também prover o máximo de independência possível entre os objetos envolvidos. Estas interfaces são projetadas de uma forma genérica para cobrir as necessidades típicas de um determinado domínio de aplicação. O termo genérico significa que as interfaces não são baseadas em objetos específicos de uma única aplicação, suas definições IDL são completamente independentes de qualquer sistema em particular.

Capítulo 3 – Tecnologias Utilizadas 77

Objetos de Aplicação

Os objetos de aplicação são objetos não padronizados utilizados em aplicações específicas. Portanto, são produtos de um único grupo de desenvolvedores que controla suas interfaces. Objetos de aplicação correspondem à noção tradicional de aplicações, portanto, não são padronizados pela OMG. Entretanto, os objetos de aplicação constituem a camada superior do modelo de referência.