Figura 1. Arquitetura de Gerenciamento de Objetos (OMA).
Obs. A maior parte desse texto faz parte da minha monografia de exame de qualificação. Citações devem se referenciar a:
[Montez 97] C. Montez, Um Modelo de Programação para Aplicações de Tempo Real em Sistemas Abertos, Monografia do Exame de Qualificação de Doutorado, DAS, UFSC, Julho de 1997.
Sugestões e criticas são bem aceitas. Última alteração dessa pagina: Agosto de 1998
CORBA
1. Motivação
A rápida disseminação de microcomputadores e estações de trabalho, o aumento nas suas capacidades de processamento, e o surgimento de redes de comunicação com grande largura de banda, têm levado a desenvolvimento cada vez maior de aplicações distribuídas. A importância de sistemas distribuídos também tem se tornado cada vez maior devido principalmente a tendências organizacionais tais como downsizing, que demandam o intercâmbio de informação dentro da própria organização e entre organizações cooperantes.
Os sistemas distribuídos apresentam vantagens advindas da distribuição tais como disponibilidade, desempenho, otimização de custos, dentre outras. Entretanto, apresentam também as seguintes características [ISO10746-1 93]: afastamento, concorrência, falta de estado global, ocorrência de falhas parciais, assincronismo, heterogeneidade, autonomia, evolução e mobilidade.
Diversos modelos e arquiteturas distribuídas têm sido desenvolvidos com o objetivo de oferecerem conceitos que ajudem a lidar com as características de distribuição citadas acima. A característica de heterogeneidade impõe a necessidade de especificações abertas, com interfaces padronizadas e públicas, levando ao desenvolvimento de middlewares abertos.
Um middleware é uma camada de software, residente acima do sistema operacional e do substrato de comunicação, que oferece abstrações de alto nível, com objetivo de facilitar a programação distribuída. As abstrações oferecidas fornecem uma visão uniforme na utilização de recursos heterogêneos existentes nas camadas de sistema operacional e redes.
O conceito de sistemas abertos aborda um significante leque de tecnologias e especificações, envolvendo a questão de interoperabilidade de uma variedade de sistemas baseados em padrões formais ou de facto. De forma diversa aos ambientes proprietários, ambientes de sistemas abertos permitem aos usuários escolherem de um vasto grupo de computadores e tecnologias, quais se adequam a suas necessidades. Esses sistemas oferecem também uma crescente interoperabilidade, escalabilidade e portabilidade, permitindo sistemas diferentes conviverem juntos, e software desenvolvido em uma plataforma poder executar em outra com adaptações mínimas.
Entretanto, apesar de inúmeras vantagens na sua utilização, o advento de sistemas abertos torna mais complexo o processo de se desenvolver uma nova tecnologia e aderir as especificações abertas. A superação dessas dificuldades e a preservação das vantagens da computação heterogênea tem levado ao surgimento de diversas organizações e consórcios tais como OMG, X/OPEN e OSF. Além do surgimento dessas novas organizações, algumas já existentes, como a ISO e ITU-T, preocuparam-se também em estabelecer especificações e recomendações que se cristalizaram no Modelo de Referência ODP. Diversos sistemas, como o ANSA e o TINA, utilizam o Modelo de Referência ODP para descreverem suas arquiteturas.
A organização OMG estabeleceu a arquitetura CORBA (Common Object Request Broker Architecture) [OMG 95] como uma forma de especificar um middleware aberto composto de objetos distribuídos. CORBA define um tipo de "barramento de software" que permite que componentes de software sejam conectados juntos formando um sistema coeso. Os conceitos utilizados nos componentes de software são similares aos dos componentes de hardware, e são adotados no CORBA utilizando-se a orientação a objetos.
O Modelo de Referência ODP (RM-ODP) [ISO10746-1 95], é outro exemplo de esforço conjunto de organizações (ISO e ITU-T), numa tentativa de oferecer um framework genérico para o desenvolvimento de padrões (arquiteturas distribuídas, por exemplo) que ocultem as conseqüências da distribuição. Algumas arquiteturas distribuídas, como TINA (Telecommunications Information Networking Architecture) [Chapman 95] e ANSA (Advanced Networked System Architecture) [Herbert 94], se utilizam dos conceitos oferecidos pelo RM-ODP para descreverem suas arquiteturas. CORBA também compartilha alguns conceitos e definições com RM-ODP, tal como o serviço de comércio (trading service).
2. Objetos Distribuídos
Um objeto distribuído é essencialmente um componente, uma peça de software com inteligência auto-contida, que pode interoperar com outros objetos distribuídos através de sistemas operacionais, redes, linguagens, aplicações, ferramentas e equipamentos diversos. Existe recentemente uma tendência de se construir sistemas computacionais abertos utilizando objetos distribuídos. Esses sistemas possuem diversas vantagens sobre os sistemas tradicionais sob diversos ponto de vistas, conforme ressaltado em [Orfali 96]. Os usuários recebem suas aplicações personalizadas, somente com os recursos necessários, evitando, assim, o denominado fatware; projetistas podem montar sistemas rapidamente utilizando "objetos de prateleira" existentes; e distribuidores podem vender aplicações com recursos específicos para determinado tipo de mercado, por exemplo, editores de texto para advogados.
Além disso, esses objetos distribuídos possuem as mesmas características principais dos objetos das linguagens de programação: encapsulamento, polimorfismo e herança, tendo, dessa forma, as mesmas principais vantagens: fácil reusabilidade, manutenção e depuração, só para citar algumas.
Em [Herbert 94b] são ressaltados diversos benefícios da utilização de objetos em sistemas distribuídos. Por exemplo, sua utilização ajuda a lidar com a heterogeneidade de alguns sistemas, pois os serviços fornecidos são separados de suas implementações. Observa-se também que o encapsulamento é adequado para implementar unidades de distribuição (que migram de forma independente), unidades de falha e unidades de segurança.
Entretanto, no mesmo texto são discutidas algumas dificuldades para implementar herança em sistemas distribuídos. A herança permite diferentes objetos compartilharem código (implementação de outro objeto) o que oferece benefícios óbvios de redução de duplicação de código. Porém, em sistemas distribuídos, não é possível o compartilhamento de código de objetos em nós separados.
Um outro benefício da utilização de objetos distribuídos que se aplica especificamente em sistemas de tempo real é o polimorfismo de performance (ou polimorfismo temporal). Esse mecanismo permite que uma interface possua várias implementações diferentes do mesmo método, cada uma com um tempo de execução diferente. Dependendo de determinados aspectos temporais, o método que puder atender aos requisitos temporais especificados pelo cliente naquele momento, será executado.
Cada objeto distribuído não opera sozinho. A princípio ele é construído para trabalhar com outros objetos e, para isso, precisa de uma espécie de "barramento". Tais "barramentos" fornecem infra-estrutura para os objetos, adicionando novos serviços que podem ser herdados durante a construção do objeto, ou mesmo em tempo de execução para alcançar altos níveis de colaboração com outros objetos independentes. CORBA é um exemplo de "barramento" que será visto a seguir.
3. Arquitetura CORBA
A arquitetura CORBA (Commom Object Request Broker Architecture) começou a ser definida pelo OMG em 1989 [OMG 97]. A OMG (Object Management Group) é uma organização internacional suportada por centenas de membros, abrangendo um grande espectro de interesses: desde usuários até projetistas de sistemas. A carta de princípios da organização inclui o estabelecimento de diretrizes na indústria e especificações de gerenciamento de objetos para fornecer um estrutura comum para desenvolvimento de aplicações. O objetivo primário é se alcançar sistemas baseados em objetos em ambientes distribuídos heterogêneos com características de reusabilidade, portabilidade e interoperabilidade.
Em 1990, a OMG criou o OMA (Object Management Architecture) com o objetivo de fomentar o crescimento de tecnologias baseadas em objetos e fornecer uma infra-estrutura conceitual para todas especificações OMG. O OMA é composto por quatro elementos principais:
Figura 1. Arquitetura de Gerenciamento de Objetos (OMA).
O ORB é o elemento principal desse modelo de referência, pois fornece os mecanismos básicos de envio e de recebimento de chamadas entre objetos e, dessa forma, será descrito com mais detalhes adiante.
3.1. Modelo de objetos CORBA
Para compreender melhor a arquitetura CORBA é necessário conhecer a descrição do modelo de objetos [OMG 95] que fornece conceitos e terminologias de objetos usados pela arquitetura CORBA.
Um conceito básico é o de sistema de objetos que é composto por entidades denominadas objetos. Um objeto é uma entidade que fornece serviços aos clientes. Um cliente de um serviço é qualquer entidade capaz de requisitar serviços através de eventos denominados requisições. Uma requisição possui informação associada que consiste basicamente da operação, do objeto destino, dos parâmetros e do contexto da requisição.
Um valor é uma instância de um tipo de dados definido no OMG IDL (que será visto mais adiante) que pode ser usado como parâmetro em uma requisição. Um valor que identifica um objeto é denominado nome de objeto, e uma referência de objeto é um nome de objeto que denota um objeto em particular.
Uma requisição pode ter parâmetros que podem ser de entrada, saída, ou de entrada e saída, e que são identificados pelas suas posições na requisição. Ela pode ter também um contexto (context) que fornece informação adicional sobre a própria requisição. Uma requisição pode retornar um valor de resultado para os clientes, além de retornar os parâmetros de saída. Entretanto, se uma condição anormal ocorrer, uma exceção é gerada.
Objetos CORBA podem ser criados e destruídos através de determinadas requisições. O resultado de uma criação de objeto é revelada ao cliente na forma de uma referência de objeto que denota o novo objeto.
Uma interface é uma descrição de um possível conjunto de operações que um cliente pode requisitar de um objeto. Diz-se que um objeto satisfaz uma interface se ele pode ser especificado como objeto destino em cada operação descrita pela interface. Uma herança de interface fornece o mecanismo de composição para permitir um objeto suportar interfaces múltiplas.
Uma operação é uma entidade que denota um serviço que pode ser requisitado. Uma operação possui uma assinatura que, de um modo geral, descreve os valores válidos dos parâmetros, dos resultados retornados da requisição, a exceção definida pelo usuário que pode ser sinalizada para terminar uma requisição de operação, e a informação de contexto que será fornecida à implementação do objeto. A assinatura descreve também, a semântica de execução da operação no caso de falhas, que pode ser "melhor esforço" ou "no máximo uma vez".
Na implementação de objeto, um método é o código que é executado para fornecer o serviço e a execução de um método é denominada ativação do método.
3.2. ORB
Objetos clientes requisitam serviços às implementações de objetos através de um ORB (Figura 2). O ORB é responsável por todos os mecanismos requeridos para encontrar o objeto, preparar a implementação de objeto para receber a requisição, e executar a requisição. O cliente vê a requisição de forma independente de onde o objeto está localizado, qual linguagem de programação ele foi implementado, ou qualquer outro aspecto que não está refletido na interface do objeto.
Figura 2. Cliente enviando requisição através do ORB.
CORBA utiliza a OMG IDL (Interface Definition Language) como uma forma de descrever interfaces, isto é, de especificar um contrato entre os objetos. OMG IDL é uma linguagem puramente declarativa baseada em C++. Isso garante que os componentes em CORBA sejam auto-documentáveis, permitindo que diferentes objetos, escritos em diferentes linguagens, possam interoperar através das redes e de sistemas operacionais (Figura 3) [Orfali 96].
Figura 3. IDL provê independência de linguagem de programação entre os objetos.
Uma definição de interface escrita em OMG IDL define completamente a interface e especifica cada parâmetro da operação. É importante ressaltar que os objetos não são escritos em OMG IDL, que é uma linguagem puramente descritiva. Eles são escritos em linguagens que possuem mapeamentos definidos dos conceitos existentes em OMG IDL. Em [OMG 95] são descritos mapeamentos para C, C++ e Smalltalk, e existem estudos para se adicionar outras linguagens nas futuras versões de CORBA.
3.2.1. Estrutura do ORB
A Figura 4 mostra a estrutura de um ORB, com as setas indicando o fluxo de chamadas que podem ocorrer de clientes para o ORB, e do ORB para as implementações de objetos.
Figura 4. Estrutura básica de um ORB.
Para fazer uma requisição, um cliente pode usar a Interface de Invocação Dinâmica (DII - Dynamic Invocation Interface) ou um Stub de IDL. Para algumas poucas e determinadas funções, um cliente pode interagir diretamente com a interface do ORB. A interface o ORB oferece funções que são independentes do adaptador de objetos utilizado, como, por exemplo, funções que executam algumas operações sobre referências de objetos.
O fato de permitir tanto a invocação dinâmica quanto a estática, torna CORBA bastante flexível. A invocação estática, que utiliza Stubs de IDL que podem ser gerados automaticamente através de pré-compiladores, possui uma série de vantagens sobre a invocação dinâmica [Orfali 96]: é mais fácil de programar, faz verificação de tipos mais robusta, executa mais rápido e é auto-documentável. Já a invocação dinâmica permite a adição de novos serviços às implementações de objetos sem alterações nos clientes. Dessa forma, os clientes podem descobrir em tempo de execução quais são os serviços oferecidos.
A invocação dinâmica é possível através dos serviços do Repositório de Interfaces. Um Repositório de Interfaces é uma base de dados que contém interfaces OMG IDL, e seus serviços basicamente permitem o acesso, armazenagem e atualização dessas interfaces.
É importante ressaltar que do ponto de vista da implementação de objetos (ou um servant), uma requisição feita estaticamente é indistigüível da feita de forma dinâmica, já que ambas respeitam a mesma semântica da requisição. Uma requisição consiste de uma referência de objeto, uma operação e uma lista de parâmetros.
Ao receber uma requisição, o ORB localiza o código da implementação transmite parâmetros e transfere o controle para a implementação do objeto (servant). Quando a requisição é completada, o controle e os valores de saída são retornados ao cliente.
De forma parecida ao que ocorre na requisição de um cliente, o ORB pode invocar a implementação de objeto através de um Esqueleto de IDL Estático ou Dinâmico. A Interface de Esqueleto de IDL Dinâmica (DSI - Dynamic Skeleton Interface) é uma forma de se enviar requisições de um ORB para uma implementação de objetos que não possui informações sobre a implementação do objeto em tempo de compilação. O cliente que invoca um objeto, não pode determinar se a implementação está usando um esqueleto de um tipo específico ou DSI para conectar a implementação ao ORB. DSI é útil em soluções de interoperabilidade implementando pontes entre diferentes ORBs, e para suportar linguagens de tipos dinâmicos, como LISP.
Para executar a requisição, a implementação de objeto pode obter alguns serviços do ORB através do Adaptador de Objetos. O Adaptador de Objetos se situa no topo dos serviços de comunicação do Núcleo de ORB. Ele fornece o ambiente para instanciar objetos, atribui-los referências de objetos, e passar requisições a eles. Com um adaptador de objetos, é possível a uma implementação de objeto ter acesso a um serviço independentemente se ele está implementado no Núcleo de ORB — se o Núcleo de ORB oferecer o serviço, o adaptador simplesmente fornece uma interface para ele; caso contrário, o adaptador deve implementá-lo no topo do Núcleo de ORB.
O conceito de adaptador de objetos é necessário para permitir que CORBA suporte uma grande diversidade de aplicações, com variados tipos e estilos de implementações de objeto. Se os serviços do adaptador de objetos fossem oferecidos diretamente pelo núcleo do ORB, seria necessária a existência de uma gama muito grande de métodos na interface do ORB para atender todas as demandas dos variados tipos de servants existentes.
Não é necessário que todos adaptadores de objetos ofereçam a mesma interface ou funcionalidade. Algumas implementações de objeto podem ter requisitos especiais, exigindo adaptadores de objetos específicos. Dessa forma, a implementação do objeto pode escolher qual adaptador de objetos utilizar dependendo de quais tipos de serviços ele requer. Entretanto, com o objetivo de tentar conter uma proliferação interminável de tipos de adaptadores de objetos, [OMG 95] recentemente definiu o Adaptador de Objetos Portável (POA - Portable Object Adapter). A especificação do POA define um adaptador de objetos que pode ser usado pela maioria de objetos que possuem implementações convencionais.
Para localizar e ativar implementações de objetos, um ORB se utiliza de Repositórios de Implementações. Esses repositórios servem adicionalmente para armazenar informações adicionais associadas com implementações de ORBs, tais como, informações de depuração, controles administrativos, segurança, dentre outras.
3.2.2. Interoperabilidade entre ORBs
A especificação de interfaces de objetos obrigatoriamente em OMG IDL, garante a portabilidade dos objetos através de diferentes linguagens, ferramentas, sistemas operacionais e redes. Entretanto, a característica de interoperabilidade entre objetos só foi coberta na versão 2.0 do CORBA, introduzida em dezembro de 1994. Isso se deu através da especificação de uma arquitetura de interoperabilidade, um suporte para pontes entre ORBs, um protocolo para comunicação entre ORBs genérico e um protocolo para comunicação entre ORBs para Internet.
A arquitetura de interoperabilidade do CORBA identifica claramente a regra de diferentes tipos de domínios para informação específica de ORBs. Tais domínios podem incluir domínios de referências de objeto, domínios de tipos, domínios de segurança, dentre outros. Quando dois ORBs estão no mesmo domínio, eles podem se comunicar diretamente. Entretanto, quando a informação em uma invocação deve deixar seu domínio, a invocação deve atravessar uma ponte.
A regra de uma ponte deve assegurar que o conteúdo e a semântica são mapeados adequadamente de um ORB para outro. O suporte para ponte entre ORBs pode também ser usado para prover interoperabilidade com outros sistemas não CORBA.
O protocolo entre ORBs genérico (GIOP - Generic Inter-ORB Protocol) especifica uma sintaxe de transferência padrão e um conjunto de formatos de mensagens para comunicação entre ORBs. O protocolo entre ORBs para Internet (IIOP - Internet Inter-ORB Protocol) especifica como mensagens GIOP são trocadas usando conexões TCP/IP. Ele especifica um protocolo de interoperabilidade padrão para Internet.
O relacionamento entre GIOP e IIOP é similar ao mapeamento existente entre o OMG IDL e uma linguagem específica: o GIOP pode ser mapeado em diferentes protocolos de transportes, e especifica os elementos de protocolo que são comuns a todos os mapeamentos. Entretanto, o GIOP não fornece uma completa interoperabilidade, da mesma forma que IDL não pode ser usado para se construir programas completos. O IIOP, e outros mapeamentos similares para diferentes protocolos de transportes, são realizações concretas das definições abstratas de GIOP (Figura 5).
Figura 5.Relacionamentos de protocolos entre ORBs.
Os protocolos entre ORBs para ambientes específicos (ESIOP - Environment-Specific Inter-ORB Protocol) devem ser usados para interoperar em locais onde uma rede ou infra-estrutura de computação distribuída já esteja em uso. Apesar de cada ESIOP poder ser otimizado para um ambiente em particular, toda especificação ESIOP deve estar conforme as convenções da arquitetura de interoperabilidade para facilitar o uso de pontes, se necessário. O suporte de pontes entre ORBs habilita às pontes serem construídas entre domínios de ORBs que usam IIOP e domínios que usam um ESIOP particular.
3.3. Serviços CORBA
O ORB, por si só, não executa todas as tarefas necessárias para os objetos interoperarem. Ele só fornece os mecanismos básicos. Outros serviços necessários são oferecidos por objetos com interface IDL, que a OMG vem padronizando para os objetos de aplicação poderem utilizar.
Sistemas distribuídos assumem cada vez mais um grau maior de importância, devido, principalmente, ao surgimento de novas tecnologias (por exemplo, redes de comunicação de alta velocidade e estações de trabalho com grande poder de processamento) que têm servido como base de desenvolvimento de aplicações distribuídas.
O escopo de execução das aplicações distribuídas tem ultrapassado o ambiente local, cruzando fronteiras administrativas e tecnológicas, provocando uma demanda nas características de interoperabilidade e portabilidade.
A heterogeneidade existente de equipamentos, de sistemas operacionais e de autoridade tem levando ao surgimento de especificações abertas, devido à necessidade de padronização desses sistemas. Essa mesma heterogeneidade, também leva à necessidade de fornecer às aplicações uma série de mecanismos de transparências de distribuição.
Sistemas distribuídos costumam ser construídos em modelos cliente/servidor utilizando mecanismos de chamada de procedimento remoto. Recentemente, o paradigma de orientação a objetos, se estendeu aos sistemas distribuídos, com diversas vantagens sobre o tradicional: melhor reusabilidade, manutenção e depuração, só para citar algumas.
O OMG, um consórcio formado por empresas e instituições de pesquisa, foi criado com o intuito de estabelecer uma padronização de arquitetura para o mundo de objetos distribuídos. Essa padronização, denominada CORBA, é constituída de especificações abertas, facilitando portabilidade e possui preocupações com aspectos de interoperabilidade através da padronização de protocolos de comunicação entre seus componentes.
A especificação da arquitetura CORBA está viva e em ebulição. Novos mapeamentos de IDL para outras linguagens, novas facilidades, extensões para linguagem IDL, são algumas áreas de interesse recente da OMG [OMG 97]. Também, novos serviços que vêm atender a requisitos específicos de determinados domínios de aplicações. Por exemplo, aspectos de tempo real estão sendo abordados recentemente na OMG através, principalmente de dois grupos de trabalho: o de tempo real (RT PSIG) e o de telecomunicações (Telecom DTF).
5. Referências
[Chapman 95] Martin Chapman, Stefano Montesi, Overall Concepts and Principles of TINA, TINA-C Documentation, Document No. TB_MDC.018_1.0_94, TINA-C, http://www.tinac.com/, Feb. 1995.
[Herbert 94] A. Herbert, An ANSA Overview, IEEE Network, Jan./Feb. 1994, pp. 18-23.
[Herbert 94b] A. Herbert, Distributed Objects, In Distributed Open Systems Edited by F. M. T. Brazier and D. Johansen, IEEE Computer Society Press, 1994, pp. 123-133.
[ISO10746-1 95] Reference Model of Open Distributed Processing - Part 1. Overview, May 1995.
[OMG 95] OMG, The Common Object Request Broker: Architecture and Specification, Revision 2.0, Jul. 1995.
[OMG 97] URL: http://www.omg.org/
[Orfali 96] R. Orfali, D. Hankey, J. Edwards, The Essential Distributeds
Objects — Survival Guide, John Wiley & Sons, Inc. 1996.