3 / * * 2+ = ' 8+ 9 
+39/9:+3'9
*/9:8/(;±*59

Autor: Fernando Vieira Paulovich

(paulovic@dc.ufscar.br)
Índice Analítico
1 INTRODUÇÃO .................................................................................................................................1

2 SISTEMAS OPERACIONAIS DISTRIBUÍDOS ................................................................................. 1

3 SISTEMAS OPERACIONAIS DE REDE........................................................................................... 2

4 MIDDLEWARE.................................................................................................................................3

4.1 Middleware e Abertura ............................................................................................................................ 4

4.2 Paradigmas para a Construção de Middlewares ..................................................................................... 5

4.2.1 Transaction Processing Monitors (TPs)................................................................................................ 5
4.2.2 Message-Oriented Middlewares (MOMs) ............................................................................................ 6
4.2.3 Object Request Brokers (ORBs) .......................................................................................................... 7
4.2.4 Plataformas......................................................................................................................................... 8
4.2.4.1 DCOM............................................................................................................................................ 8
4.2.4.2 Java RMI ...................................................................................................................................... 11
4.2.4.3 Common Object Request Broker Architecture (CORBA) ............................................................... 14
4.2.4.3.1 Modelo de Referência ............................................................................................................. 14
4.2.4.3.2 Object Request Broker (ORB)................................................................................................. 15
4.2.4.3.3 Facilidades Comuns (CORBAfacilities) .................................................................................. 17
4.2.4.3.4 Domínio de Interfaces............................................................................................................. 17
4.2.4.3.5 Objetos de Serviços (CORBAservices).................................................................................... 17
4.2.4.4 Conclusões.................................................................................................................................... 19

REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................................................21

Índice de Figuras e Tabelas

TABELA 1 - COMPARAÇÃO ENTRE AS PLATAFORMAS.............................................................................................. 19

F IGURA 1- E STRUTURA GERAL DE UM SISTEMA OPERACIONAL DISTRIBUÍDO MULTIPROCESSADOR .............................. 2

F IGURA 2 – ESTRUTURA GERAL DE UM SISTEMA OPERACIONAL DISTRIBUÍDO MULTICOMPUTADOR ............................. 2
F IGURA 3 - E STRUTURA GERAL DE UM SISTEMA OPERACIONAL DE REDE ................................................................... 2
F IGURA 4 – ESTRUTURA GERAL DE UMA SISTEMA DISTRIBUÍDO QUE UTILIZA UM MIDDLEWARE ................................. 3
F IGURA 5 – USO DO MIDDLEWARE........................................................................................................................... 4
F IGURA 6 – EM SISTEMAS DISTRIBUÍDOS ABERTOS BASEADOS EM MIDDLEWARE OS PROTOCOLOS USADOS ................. 4
F IGURA 7 – TECNOLOGIA DE MONITOR DE TRANSAÇÃO DE PROCESSO ...................................................................... 5
F IGURA 8 – MIDDLEWARE ORIENTADO A MENSAGEM ............................................................................................... 6
F IGURA 9 – MIDDLEWARE OBJECT REQUEST BROKER.............................................................................................. 7
F IGURA 10 – INTERFACES DCOM ........................................................................................................................... 9
F IGURA 11 – S ERVIDORES NO MODELO DCOM...................................................................................................... 10
F IGURA 12 – ARQUITETURA DO MODELO RMI ....................................................................................................... 11
F IGURA 13 – ARQUITETURA DE UMA CHAMADA REMOTA DE MÉTODO (RMI) .......................................................... 13
F IGURA 14 – M ODELO DE REFERÊNCIA OMA ........................................................................................................ 15
F IGURA 15 – ESTRUTURA DE UMA ORB PADRÃO CORBA ..................................................................................... 15
Middlewares em Sistemas Distribuídos 1

1 INTRODUÇÃO
Quando se pensa na construção de sistemas distribuídos o hardware tem grande importância, mas na
verdade o software é largamente o fator determinante da aparência do sistema. Sistemas distribuídos
são muito parecidos aos sistemas operacionais tradicionais. Primeiro, eles atuam como gerenciadores
de recurso para o hardware, permitindo que múltiplos usuários e aplicações compartilhem recursos
como CPUs, memórias, periféricos, a rede, e dados de todos os tipos. Segundo, e provavelmente o mais
importante, é que sistemas distribuídos tentam esconder a natureza complexa e heterogênea do
hardware provendo uma máquina virtual na qual aplicações podem ser facilmente executadas.

Para entender a natureza dos sistemas distribuídos, nós iremos, portanto primeiro dar uma olhada nos
sistemas operacionais em relação aos sistemas distribuídos. Sistemas operacionais para computadores
distribuídos podem ser divididos em duas categorias: sistemas fortemente acoplados e sistemas
fracamente acoplados. Nos sistemas fortemente acoplados, o sistema operacional essencialmente tenta
manter uma única visão global dos recursos que ele gerencia. Já os sistemas fracamente acoplados
podem ser pensados como uma coleção de computadores cada qual rodando o seu próprio sistema
operacional. Porém, estes sistemas operacionais trabalhando junto para tornar seus próprios serviços e
recursos disponíveis para os outros sistemas.

Um sistema operacional fortemente acoplado é geralmente referido como um sistema operacional

distribuído (SOD), e é usado para gerenciar multiprocessadores e multicomputadores heterogêneos.
Como um sistema operacional uniprocessador tradicional, o principal objetivo de um SOD é esconder a
complexidade de gerenciamento do hardware de forma que ele possa ser compartilhado por múltiplos
processos.

O sistema operacional de rede (SOR) fracamente acoplado é usado para sistemas heterogêneos de
multicomputadores. Embora o gerenciamento do hardware seja um importante assunto para o SOR, a
distinção entre sistemas operacionais tradicionais vem do fato dos serviços locais serem tornados
disponíveis a clientes remotos. Para um SOR se tornar verdadeiramente um sistema distribuído
melhorias aos seus serviços são necessários de maneira que suporte para transparência de distribuição
seja provido. Estas melhorias levam ao que nós conhecemos de middleware, o que é o coração dos
sistemas distribuídos modernos.

A maioria desses middlewares é baseado em algum modelo, ou paradigma, para realizar a distribuição e
comunicação. Basicamente são quatro esses paradigmas: Transaction Processing Monitors (TPs), que
controlam aplicações de transações e executam computações de negócios e atualizações em bancos de
dados; Remote Procedure Calls (RPCs), que permitem que clientes de uma aplicação chamem funções
para acessar servidores em sistemas remotos; Message-Oriented Middlewares (MOMs), que residem em
ambas partes de uma arquitetura cliente/servidor e suportam chamadas assíncronas entre as aplicações;
e os Object Request Brokers (ORBs), que permitem que objetos que compõem uma aplicação sejam
distribuídos em redes heterogêneas.

Dentre os padrões de ORBs quatro se destacam sendo os mais difundidos, que são CORBA, DCOM e
Java/RMI. Cada um desses padrões, ou plataformas, apresenta suas características particulares que os
tornam mais apropriados a certas aplicações para construção de sistemas de objetos distribuídos.

Este trabalho se destina a apresentar noções sobre a utilização de middlewares na elaboração de

sistemas distribuídos, apresentando os paradigmas existentes de construção de middlewares,
detalhando o paradigma mais utilizado hoje em dia – Object Request Broker - apresentando as
plataformas mais utilizadas.

2 SISTEMAS OPERACIONAIS DISTRIBUÍDOS

Existem dois tipos de sistemas operacionais distribuídos. O primeiro, chamado de sistema operacional
multiprocessador, gerencia os recursos de um multiprocessador. O segundo, sistema operacional
multicomputador, é um sistema operacional que é desenvolvido para multicomputadores heterogêneos.
A funcionalidade dos sistemas operacionais distribuídos é essencialmente a mesma dos tradicionais
sistemas operacionais para sistema uniprocessadores, exceto pelo fato de que eles manipulam múltiplas
CPUs, assumindo que o hardware é homogêneo e deve ser gerenciado como se fosse um único
Middlewares em Sistemas Distribuídos 2

sistema. A Figura 1 mostra a configuração de um sistema operacional multiprocessador, e a Figura 2

mostra a configuração de um sistema operacional multicomputador.

Figura 1- Estrutura geral de um sistema operacional distribuído multiprocessador

Figura 2 – Estrutura geral de um sistema operacional distribuído multicomputador

3 SISTEMAS OPERACIONAIS DE REDE

Em contraste com os sistemas operacionais distribuídos, os sistemas operacionais de rede não
assumem que o hardware é homogêneo e que ele deve ser gerenciado com se fosse um único sistema.
Ao invés disso, eles são geralmente construídos a partir de uma coleção de sistemas uniprocessadores,
cada um com seu próprio sistema operacional, como mostrado na Figura 3. As máquinas e seus
sistemas operacionais podem ser diferentes, mas eles estão completamente conectados a cada outro
sistema operacional na rede. Também, sistemas operacionais de rede provêem facilidades para permitir
que usuários façam uso dos serviços disponíveis em uma máquina específica.

Figura 3 - Estrutura geral de um sistema operacional de rede

Middlewares em Sistemas Distribuídos 3

4 MIDDLEWARE
Para que um SOR se torne verdadeiramente um sistema distribuído melhorias aos seus serviços são
necessários de maneira que seja provido suporte para transparência de distribuição. A questão que vem
a mente nesse ponto é como isso pode ser feito. A solução é achada em adicionar uma camada de
software que é usada junto aos SOR para não só ocultar a heterogeneidade da coleção de plataformas,
mas também melhorar a distribuição de transparência. Muitos sistemas distribuídos modernos são
construídos por meio de uma camada adicional, que é chamada de middleware.

Essa camada adicional de software é colocada entre as aplicações e o sistema operacional de rede,
oferecendo um alto nível de abstração. Assim, tais aplicações não fazem uso direto da interface de
programação oferecida pelos SORs, como o caso do uso dos sockets, que permitem que processos em
diferentes máquinas troquem mensagens, ou do acesso ao sistema de arquivo local, o que aumenta a
transparência de distribuição. Na Figura 4 é mostrado o posicionamento do middleware.

Figura 4 – Estrutura geral de uma sistema distribuído que utiliza um middleware

Cada sistema local que forma parte do sistema operacional de rede provê gerenciamento local de
recursos além de ser um simples meio de comunicação para conectar os computadores. Em outras
palavras, middleware em si mesmo não gerencia individualmente o nó; isto é deixado para ser feito
inteiramente pelo sistema operacional local.

Um importante objetivo é esconder a heterogeneidade das plataformas das aplicações. Portanto, muitos
sistemas de middleware oferecem uma mais-ou-menos completa coleção de serviços e desencorajam a
utilização de qualquer outra interface que não seja a desses serviços. Em outras palavras, chamar
serviços de um SOR sem passar pela camada de middleware é freqüentemente visto com desagrado.

É interessante notar que o middleware não foi inventado como um exercício acadêmico na tentativa de
se atingir a transparência de distribuição. Após a introdução e difusão dos SOR, muitas organizações se
acharam com muitas aplicações de rede que não podiam ser facilmente integradas em um único
sistema. Neste ponto, produtores começaram a fazer em um alto nível, serviços independentes de
aplicação que poderiam ser usadas por várias aplicações distintas. Exemplos típicos incluem suporte
para transações distribuídas e recursos para comunicação avançada.

Dando uma definição mais precisa, podemos dizer que “um middleware é um software de conectividade
que consiste de um conjunto de serviços disponíveis que permite que múltiplos processos, executando
em uma ou mais máquinas, interajam através de uma rede”. Um middleware é essencialmente uma
migração das aplicações mainframe para aplicações cliente/servidor que provê comunicação através de
1
plataformas heterogêneas. Colocado de forma mais técnica, o middleware é uma API (Application
1
Uma API é uma lista de regras para a escrita de funções ou chamadas de sub-rotinas que acessam funções em uma biblioteca.
Programas que usam estas regras ou funções nas suas chamadas de API podem se comunicar com qualquer outro programa que
usa essa API, sem se importar com outras particularidades. APIs trabalham com um grande espectro de diálogos de aplicações
(isto é, esquemas de comunicação entre programas) para facilitar a troca de informação. Dessa forma, APIs também podem ser
consideradas como um tipo de middleware que provê o compartilhamento de dados através de diferentes plataformas; isto é uma
importante melhoria quando no desenvolvimento ou atualização de sistemas distribuídos.
Middlewares em Sistemas Distribuídos 4

Programming Interface) de fácil utilização que se localiza entre a aplicação e os recursos que a aplicação
necessita. A Figura 5 mostra o uso do middleware.

Figura 5 – Uso do middleware

4.1 Middleware e Abertura

Sistemas distribuídos modernos são geralmente construídos baseando-se na utilização de middlewares,
dessa forma tais sistemas acabam se tornando independentes do sistema operacional sendo utilizado.
Infelizmente, esta independência é freqüentemente trocada por uma grande dependência de
middlewares específicos. Tais problemas estão relacionados ao fato de que os middlewares são
freqüentemente menos abertos do que eles anunciam. Um sistema distribuído para ser verdadeiramente
aberto deve ser especificado através de interfaces completas. Completas significa que tudo que é
necessário para a implementação de um sistema seja realmente especificado. Definições incompletas da
interface conduzem a situação na qual desenvolvedores de sistemas podem ser forçados a adicionar
suas próprias interfaces. Conseqüentemente, isso pode resultar em uma situação na qual dois diferentes
times de desenvolvedores que seguem o mesmo padrão, mas middlewares diferentes, produzirem
aplicações que rodem sobre seus middlewares, mas que não podem ser portados facilmente para o
outro tipo de middleware.

Tão ruim quanto essa situação está à situação na qual a definição de interfaces não completas leva a
uma situação na qual duas implementações diferentes podem nunca interoperar, apesar do fato elas
implementarem exatamente a mesma lista de interfaces, mas diferentes protocolos de comunicação. Por
exemplo, se duas implementações diferentes de protocolos confiam em protocolos incompatíveis de
comunicação como disponíveis nos sistemas operacionais de rede, existe uma pequena esperança de
que a interoperabilidade seja facilmente alcançada. O que nós precisamos é que protocolos de
middleware e as interfaces para o middleware sejam as mesmas, como mostrado na Figura 6.

Figura 6 – Em sistemas distribuídos abertos baseados em middleware os protocolos usados

devem ser os mesmos, bem como as interfaces oferecidas

Um outro fator para assegurar a interoperabilidade entre diferentes implementações é a necessidade de

que entidades dentro de diferentes sistemas sejam referenciadas da mesma forma. Se entidades em um
sistema são referenciadas por meio de URLs, enquanto o outro sistema implementa referências usando
endereços de rede, é claro que referência cruzada será um problema. Neste caso, as definições de
interface devem prescrever precisamente o que e referência parece.
Middlewares em Sistemas Distribuídos 5

4.2 Paradigmas para a Construção de Middlewares

Para realizar a integração e o desenvolvimento de aplicações distribuídas o mais simples o possível, a
maioria dos middlewares é baseado em algum modelo, ou paradigma, para realizar a distribuição e
comunicação. Basicamente são quatro esses paradigmas: Transaction Processing Monitors (TPs), que
controlam aplicações de transações e executam computações de negócios e atualizações em bancos de
dados; Remote Procedure Calls (RPCs), que permitem que clientes de uma aplicação chamem funções
para acessar servidores em sistemas remotos; Message-Oriented Middlewares (MOMs), que residem em
ambas partes de uma arquitetura cliente/servidor e suportam chamadas assíncronas entre as aplicações;
e os Object Request Brokers (ORBs), que permitem que objetos que compõem uma aplicação sejam
distribuídos em redes heterogêneas. Nas próximas subseções serão explicados mais a fundo cada um
desses paradigmas, exceto o RPC.

4.2.1 Transaction Processing Monitors (TPs)

A tecnologia Transaction Processing (TP) Monitor provê ao ambiente cliente/servidor distribuído a
capacidade para desenvolver, rodar e gerenciar aplicações com transações de forma eficiente e
confiável.

A tecnologia TP monitor controla aplicações de transação e realiza computações de negócios e

atualizações em banco de dados. A tecnologia TP monitor surgiu há 25 anos atrás quando a Atlantic
Power and Light criou um ambiente de suporte online para compartilhar serviços de aplicações
concorrentes e recursos de informação através de um ambiente de sistemas operacionais. Tal tecnologia
é usada no gerenciamento de dados, acesso à rede, segurança de sistemas, entrega de pedidos de
processamento, reservas de aviões e atendimento ao cliente. O uso da tecnologia TP monitor é uma
alternativa com baixo custo para a atualização de sistemas de base de dados e recursos de plataformas
que prevêem a mesma funcionalidade.

A tecnologia TP monitor é um software que é considerado um middleware. Ela pode prover serviços de
aplicações para milhares de clientes em um ambiente cliente/servidor distribuído. Tal tecnologia realiza
isso através da multiplexação de pedidos de transações de clientes (por tipo) sobre um número
controlado de rotinas de processo que suportam serviços particulares. Estes eventos são mostrados na
Figura 7.

Client
Client

Client Processing
Routines
Transaction Services
Client Processing
Monitor

Client
Client

Figura 7 – Tecnologia de Monitor de transação de processo

A tecnologia TP monitor mapeia vários pedidos de clientes através de rotinas de serviços de aplicação
para melhorar a performance do sistema. Tal tecnologia (locada com um servidor) pode também realizar
as transições lógicas para o cliente. Isto reduz o número de atualizações requeridas por estas
plataformas de clientes. Além disso, essa tecnologia inclui várias características de gerenciamento, tais
como reinicio de processos falhos, balanceamento dinâmico de carga e obriga a consistência de dados
distribuídos. Essa tecnologia é escalável pela adição de mais servidores.

Tal tecnologia é independente de arquitetura de banco de dados. Ela suporta modelagem flexível e
robusta de negócios e encoraja procedimentos modulares e reusáveis. O projeto dessa tecnologia
Middlewares em Sistemas Distribuídos 6

permite que APIs suportem componentes tais como bibliotecas heterogêneas de clientes, banco de
dados e gerenciadores de recursos, e sistemas de aplicação do mesmo nível (peer-level).

Dentro de sistemas cliente/servidor distribuídos, cada cliente que é suportado adiciona overhead aos
recursos do sistema (tal como memória). Tal overhead pode ser reduzido através da adoção da
tecnologia TP monitor para multiplexar vários clientes sobre uma lista menor de rotinas de serviços de
aplicação. Essa tecnologia provê um sistema altamente ativo que inclui serviços para entrega de pedidos
de processamento, terminal e formas gerenciamento, gerenciamento de dados, acesso à rede,
autorização e segurança.

Tal tecnologia suporta um número de modelos de comunicação programa-a-programa, tal como store-
and-foward, assíncrono, RPC, e conversational. Isto melhora as interações entre componentes de
aplicação. A tecnologia TP monitor provê a capacidade para construir aplicações complexas de negócios
a partir de componentes funcionais modulares e bem definidos. Como esta tecnologia é bem conhecida
e bem definida ela pode reduzir os risco de programação associada a custo.

4.2.2 Message-Oriented Middlewares (MOMs)

Message-Oriented Middleware (MOM) é uma infraestrutura cliente/servidor que aumenta a
interoperabilidade, portabilidade e flexibilidade de uma aplicação, permitindo que tal aplicação seja
distribuída sobre múltiplas plataformas heterogêneas. Ela reduz a complexidade do desenvolvimento de
aplicações que funcionam sobre múltiplos sistemas operacionais e protocolos de rede através do
isolamento do desenvolvedor da aplicação de detalhes dos vários sistemas operacionais e interfaces
APIs de rede que são usados na construção do sistema.

O MOM, como mostrado na Figura 8, é um software que reside em ambas as partes da arquitetura
cliente/servidor e tipicamente suporta chamadas assíncronas entre o cliente e os servidores de
aplicações. Filas de mensagens provêem armazenamento temporário quando o programa destino está
ocupado ou não conectado. O MOM reduz o envolvimento dos desenvolvedores de aplicações com a
complexidade com a natureza mestre-escravo do mecanismo de cliente/servidor.

A T T A
P R R P
L MOM A A MOM L
I (com fila de N R R N (com fila de I
mensagem) S E E S mensagem) C
C
A P D D P A
Ç O E E O Ç
à R R Ã
O T T O
E E

Figura 8 – Middleware orientado a mensagem

O MOM aumenta a flexibilidade de uma arquitetura por habilitar que aplicações troquem mensagens com
outros programas sem ter de conhecer em qual plataforma ou processador a outra aplicação reside
dentro da rede. As mensagens acima mencionadas podem conter dados formatados, pedidos de ações,
ou ambos. Normalmente, o sistema MOM provê uma fila de mensagem entre os processos
interoperantes, assim se o processo destino estiver ocupado, a mensagem é armazenada
temporariamente até que ela possa ser processada. O MOM é tipicamente assíncrono e peer-to-peer,
mas muitas implementações suportam também passagem síncrona de mensagens.
Middlewares em Sistemas Distribuídos 7

4.2.3 Object Request Brokers (ORBs)

Object Request Broker, ou simplesmente ORB, é uma tecnologia que gerencia a comunicação e a troca
de dados entre objetos. Em outras palavras, o ORB provê interoperabilidade em sistemas de objetos
distribuídos. Ele permite a construção de sistemas pelo agrupamento de objetos que se comunicam
entre si através dele. Os detalhes da implementação do ORB geralmente não são importantes para os
desenvolvedores de sistemas distribuídos. Os desenvolvedores devem se preocupar apenas com os
detalhes da interface do objeto.

A tecnologia ORB permite a comunicação de objetos entre diferentes máquinas, diferentes softwares e
diferentes fornecedores. Um ORB provê um diretório de serviços e auxilia a estabelecer conexões entre
clientes e estes serviços. Esta definição pode ser ilustrada na Figura 9.

Um ORB deve suportar muitas funções com o objetivo de operar consistente e efetivamente, e, além
disso, muitas dessas funções são transparentes ao usuário do ORB. É de responsabilidade do ORB
fornecer a transparência de localidade, ou seja, fazer com que o objeto requisitado pareça local para o
cliente, enquanto que na realidade ele se localiza em um processo ou máquina diferentes. Portanto, um
ORB fornece um barramento para a comunicação entre objetos em diferentes sistemas. Este é o
primeiro passo para alcançar a interoperabilidade em sistemas de objetos distribuídos.

Figura 9 – Middleware Object Request Broker

O próximo passo é a comunicação de objetos entre plataformas. Um ORB permite aos objetos esconder
seus detalhes de implementação dos clientes. Isto inclui linguagens de programação, sistemas
operacionais, hardware, e localização de objetos. Cada um desses itens deve ser pensado como uma
transparência, e diferentes tecnologias de ORBs podem suportar diferentes transparências, fazendo com
que os benefícios da orientação a objetos entre plataformas e canais de comunicação sejam estendidos.

Um ORB pode ser implementado de diversas maneiras. As funções de um ORB podem, por exemplo,
estar compiladas dentro dos programas clientes; podem ser processos separados ou daemons; ou
podem ainda ser partes de um kernel de um sistema operacional.

Um ORB age como um intermediário para as requisições que os clientes enviam para os servidores. É
responsável por todos os mecanismos requeridos para encontrar a implementação de um objeto,
preparar a implementação para receber a requisição, e comunicar os dados na requisição.

Ele também utiliza as informações da requisição para determinar a melhor implementação que satisfaça
o pedido. Estas informações podem incluir: a operação que o cliente está requisitando, o tipo de objeto
que será executado, e qualquer informação adicional armazenada no contexto do objeto sendo
requisitado.

Os principais padrões para computação distribuída de hoje e que utilizam a tecnologia ORB são:

• Common Object Request Broker Architecture (CORBA);

• Distributed Component Object Model (DCOM);
• Java Remote Method Invocation (Java RMI);
Middlewares em Sistemas Distribuídos 8

4.2.4 Plataformas
Esta seção tem por objetivo descrever as três principais plataformas distribuídas. Mas é importante
ressaltar que, antes do surgimento delas, outras plataformas distribuídas já eram utilizadas de forma
expressiva e serviram de base para as especificações das plataformas atuais. Entre elas encontram-se:
DCE, e ODP.

DCE, ou Distributed Computing Environment, é um ambiente distribuído integrado que foi desenvolvido e
gerenciado pelo grupo OSF (Open Systems Foundation). O ambiente DCE é um conjunto de serviços de
sistema integrados que fornece um ambiente distribuído interoperável e flexível com o objetivo principal
de resolver problemas de interoperabilidade entre sistemas e em ambientes de rede heterogêneos. A
principal característica do DCE é que seu sistema de comunicação é baseado no modelo RPC.

A segunda plataforma, ODP, ou Open Distributed Processing, é um padrão para o processamento

distribuído desenvolvido pelo ISO (International Standard Organization). O modelo ODP descreve os
sistemas que suportam processamento distribuído e heterogêneo entre diversas organizações e
sistemas através do uso de um modelo comum de interação. O principal objetivo do ODP é a
portabilidade de aplicações entre plataformas heterogêneas além da transparência de distribuição dos
programas.

As subseções seguintes descrevem em detalhes as principais plataformas utilizadas hoje no meio

acadêmico e comercial: CORBA, DCOM, e Java RMI. Todas elas tiveram suas bases em plataformas
como ODP e DCE.

4.2.4.1 DCOM
DCOM, ou Distributed Component Object Model, é a resposta da Microsoft para a tecnologia CORBA de
middleware. Ela começou como uma tecnologia de estruturação de documentos chamada de Object
2
Linking and Embedding (OLE) , presente na maioria das aplicações Windows, e que mais tarde foi
transformada em uma tecnologia mais genérica e orientada a objetos chamada de Component Object
Model, ou COM. COM está longe de ser um middleware, pois não define um protocolo de
interoperabilidade, embora possua uma linguagem genérica de definição de interfaces. Dessa forma,
COM pode ser usada para definir interfaces comuns entre componentes de software, mas com a
restrição de que ela só pode vincular os componentes que residem na mesma máquina. Com o objetivo
de criar um produto middleware, em 1996, a Microsoft estendeu e aperfeiçoou COM resultando na
tecnologia DCOM. A idéia inicial era fornecer uma tecnologia para plataformas Windows e não-Windows,
mas apenas algumas implementações não-Windows apareceram. Em meados de 1990, a Microsoft criou
alguns produtos para fornecer serviços de middleware para a plataforma DCOM. Entre eles o Microsoft
Message Queue Server (MSMQ) para comunicação assíncrona, e o Microsoft Transaction Server (MTS),
um monitor de transações. Em 1997, a Microsoft novamente anunciou um novo modelo de componentes
conhecido como COM+. O modelo de componentes COM+ estende o modelo COM adicionando diversas
melhorias, entre elas o conceito de programação baseada em atributos, ou attribute-based programming.
Em meados do ano de 2000 foi anunciada uma nova estratégia para o desenvolvimento de sistemas
distribuídos, conhecida como Distributed interNetwork Architecture (DNA) que utiliza o modelo de
componentes COM+ e que está incorporada ao sistema operacional Windows 2000. Atualmente, a
Microsoft está migrando sua arquitetura DNA para incluir o framework .NET, uma nova especificação
para o desenvolvimento de aplicações distribuídas para Internet que possui fortes fundamentos em XML
3
e SOAP .

Numa visão bastante simples, pode-se encarar DCOM como a especificação de um ORB específico para
a plataforma Windows. Tal como CORBA, o padrão DCOM separa a interface de um objeto de sua
implementação e requer que todas as interfaces sejam declaradas utilizando uma IDL, que neste caso
denomina-se MIDL (Microsoft Interface Definition Language), que especifica os requisitos mínimos dos
objetos para que estes possam se comunicar através do barramento DCOM. A MIDL é baseada no
padrão DCE (Distributed Computing Environment) e, portanto, não é compatível com CORBA.

2
Uma maneira de criar documentos contendo objetos de outros programas. Por exemplo, você pode colocar um gráfico excel e um
slide Powerpoint dentro de um documento do Word.
3
SOAP, ou Simple Object Access Protocol, é um protocolo padronizado pelo W3C para comunicação distribuída na Web baseado
em XML.
Middlewares em Sistemas Distribuídos 9

Da mesma forma que CORBA, DCOM também provê invocação de métodos através de interfaces
estáticas e dinâmicas. O Type Library é uma versão do Repositório de Interfaces de CORBA. Os clientes
consultam o Type Library para localizar quais interfaces um objeto suporta e quais parâmetros são
necessários para invocar um método em particular. DCOM também oferece um registro e alguns
serviços de localização que são similares aos de CORBA.

Em DCOM, uma interface é simplesmente um conjunto de funções, métodos ou funções membros, que
serve como um contrato entre a aplicação cliente e o servidor de objetos, através do qual podem trocar
mensagens. Na interface, os métodos são definidos independentemente de sua implementação (e de
linguagem), numa API binária, acessível por qualquer linguagem de programação que suporte a
especificação. Para acessar uma interface, um cliente DCOM utiliza um ponteiro para uma tabela de
ponteiros conhecida como tabela virtual (vtable). As funções membros apontadas pela vtable são as
implementações dos métodos do objeto. Cada objeto DCOM possui uma ou mais vtables que definem o
contrato entre a implementação do objeto e seus clientes. A figura a seguir, mostra a tabela virtual e
seus ponteiros para as funções:

Figura 10 – Interfaces DCOM

No modelo, cada interface é identificada por um identificador único conhecido como IID (Interface
IDentifier), um número de 128 bits gerado pela API DCOM.

Um objeto DCOM – também conhecido como objeto ActiveX - é definido como um componente que
suporta uma ou mais interfaces definidas por sua classe. Uma interface DCOM refere-se a um grupo pré-
definido de funções relacionadas. Uma classe DCOM implementa sempre pelo menos uma interface e é
identificada por um número único de 128 bits, chamado de Class ID ou CLSID. Um objeto DCOM é uma
instância de uma classe. Um objeto implementará todas as funções definidas na interface que sua classe
suporta.

Os clientes sempre se comunicam com os objetos DCOM através de ponteiros para as interfaces; nunca
através de acesso direto. Os objetos DCOM não suportam identificadores únicos de objetos (ou
referências persistentes de objetos no modelo CORBA). No modelo, todas as classes devem
implementar, obrigatoriamente, a interface pré-definida IUnknown, que é responsável pela criação e
remoção dos objetos, além de permitir acesso aos demais membros da interface específica da classe.

Mas ao contrário do modelo CORBA, o modelo DCOM não suporta o conceito de identificador de objetos
(object ID). Os clientes obtêm um ponteiro para uma interface e não um ponteiro para um objeto com
estado. Um cliente DCOM não pode acessar exatamente o mesmo objeto posteriormente. Os clientes
possuem apenas ponteiros transientes para as interfaces. Em outras palavras, objetos DCOM não
mantêm o estado entre conexões ou acessos. E este pode se tornar um grande problema em ambientes
onde existem falhas de comunicação, como por exemplo a Internet.

Para contornar os problemas com persistência de objetos no ambiente distribuído, DCOM criou os
monikers. Um moniker DCOM é um objeto que age como um nome alternativo (alias) persistente para
outro objeto. Os monikers podem prover nomes alternativos, ou aliases, para sistemas de arquivos
distribuídos, consultas em bancos de dados, células de uma planilha eletrônica, computadores remotos,
entre outros. Um moniker, no entanto, é uma solução paliativa adotada para a falta de suporte de DCOM
para persistência de objetos.
Middlewares em Sistemas Distribuídos 10

Se o componente projetado se destinar a ser utilizado como um servidor (local ou remoto) de objetos,
deverá implementar também a interface IClassFactory, que fornece mecanismos para instanciar objetos.
No modelo, ao contrário de implementações como Java, por exemplo, que executam automática e
periodicamente o ″recolhimento de lixo″ (garbage collection) do sistema, DCOM obriga o servidor de
objetos a cooperar com o sistema, devolvendo a ele a memória não utilizada, tão logo o último cliente
deixe de referenciar um objeto. O padrão especifica servidores de objetos de três tipos diferentes:

a) Servidores in-process: executam no mesmo processo de seus clientes. No sistema operacional

Windows 9x e Windows NT/2000 estes servidores são implementados como bibliotecas do tipo DLL
(Dynamic Linked Library);
b) Servidores locais: executam em processos distintos de seus clientes, mas na mesma máquina. Os
clientes utilizam o mecanismo LRPC (Lightweigth Remote Procedure Call) para se comunicar com o
servidor local. São implementados como arquivos executáveis (.EXE);
c) Servidores remotos: executam em processos separados, residentes em máquinas remotas,
possivelmente com outro sistema operacional. Os clientes utilizam o mecanismo de RPC para se
comunicar com os servidores remotos.

Dessa forma, a especificação DCOM garante comunicação transparente entre a aplicação cliente e o
servidor de objetos, local ou remoto. Do ponto de vista do cliente, todo o acesso aos membros da classe
é feito através de ponteiros para os elementos da interface. Por definição, um ponteiro deve ser in-
process. Assim, a comunicação com um servidor in-process local é feita diretamente. Para a
comunicação out-of-process, local ou remota, o barramento DCOM gera um objeto de comunicação,
conhecido como proxy object, que recebe a chamada e converte numa chamada RPC apropriada,
enviando-a ao processo externo, local ou remoto. O elemento DCOM responsável pela localização dos
servidores e pela comunicação RPC entre clientes e servidores é chamado de Service Control Manager
(SCM) – ou simplesmente "Scum".

Na outra ponta da mensagem, o barramento DCOM gera um stub object, que recebe a chamada do
proxy object e a converte numa chamada local à interface solicitada. Assim, tudo se passa
transparentemente no barramento DCOM. Os clientes e os servidores sempre se comunicam utilizando
algum código local ou in-process. (Figura 11). Os objetos proxy e o mecanismo de stubs são muito
similares ao modo como CORBA implementa a transparência local/remota utilizando stubs estáticos no
cliente e interfaces de skeletons no servidor.

Figura 11 – Servidores no modelo DCOM

O modelo DCOM também provê facilidades de invocações dinâmicas e obtenção de metadados. Essas
facilidades são conhecidas como automatizações (automations). O Type Library de DCOM permite que
clientes descubram dinamicamente métodos e propriedades de um servidor DCOM. Para que um
servidor disponibilize metadados na Type Library, ele precisa ter suas interfaces descritas através da
ODL (Object Definition Language). DCOM ODL é um subconjunto da Microsoft IDL e é utilizada para se
definir metadados de uma classe. Um servidor automatizado é um objeto DCOM que implementa uma
interface específica chamada de IDispatch. Essa interface fornece mecanismos de late-binding através
dos quais um objeto expõe suas funções – incluindo seus métodos e propriedades. Essas funções de
Middlewares em Sistemas Distribuídos 11

late-binding são conhecidas como dispatch interfaces, ou simplesmente dispinterfaces (em CORBA são
equivalentes às dynamic skeleton interfaces). As interfaces, métodos, e propriedades dos servidores são
armazenadas em type libraries que agem como repositórios de execução.

Do mesmo modo que CORBA, DCOM não tem sido encontrado em larga escala. Pelo fato de ser uma
arquitetura dependente da plataforma Windows, poucas aplicações com caráter mais sério, utilizando
DCOM, estão sendo implementadas. Como descrito anteriormente, os objetos DCOM são ponteiros para
interfaces sem estado persistente e os monikers são uma solução alternativa. Além disso, DCOM requer
serviços adicionais como o Microsoft Transaction Server (MTS) para permitir alta escalabilidade no
servidor. Com o lançamento de novas tecnologias, como o framework .NET e tecnologias já existentes
como DNA e COM+, espera-se uma maior portabilidade em relação a DCOM e uma robustez
comparável a da arquitetura CORBA.

4.2.4.2 Java RMI

Java Remote Method Invocation, ou simplesmente Java RMI, é um modelo de objetos distribuídos para a
plataforma Java. A principal funcionalidade deste modelo é permitir a invocação de um método de uma
interface remota em um objeto remoto. A especificação Java RMI define objeto remoto como um objeto
no qual seus métodos podem ser invocados por outra Máquina Virtual Java (Virtual Machine),
geralmente localizada em uma máquina diferente. Um objeto deste tipo é descrito por uma ou mais
interfaces remotas, que são interfaces Java que declaram os métodos de objeto remoto. O mais
importante: uma invocação de um método de um objeto remoto possui a mesma sintaxe de uma
invocação de um método de um objeto local. Neste contexto, RMI é muito parecido com CORBA. Os
clientes RMI interagem com objetos remotos através de interfaces remotas bem definidas, nunca
diretamente com as classes que implementam as interfaces. O modelo RMI utiliza a serialização de
objetos para converter objetos em streams de bytes para a transmissão. Qualquer tipo de objeto pode
ser passado durante a invocação, incluindo tipos primitivos, classes básicas, classes definidas pelo
4
usuário, e JavaBeans . O modelo Java RMI pode ser descrito como uma evolução natural do modelo
RPC, adaptado para o paradigma da orientação a objetos. O modelo RMI pode ser pensado como um
ORB de modo que ele suporta invocações em objetos remotos. Ele torna o ORB quase totalmente
transparente para o cliente adicionando alguns requerimentos de implementação no servidor. Na
essência, o RMI é uma extensão da linguagem Java.

Os clientes RMI invocam os métodos remotos utilizando stubs específicos para cada serviço. Esses
stubs são gerados pelo compilador de stubs rmic e estendem as funções da classe RemoteStub. No lado
do servidor, as classes RMI precisam estender a classe UnicastRemoteObject. O modelo RMI envia e
recebe as chamadas dos clientes para os objetos remotos do servidor utilizando skeletons gerados pelo
compilador rmic. O compilador rmic implementa uma classe skeleton para casa interface definida no
servidor. A Figura 12 a seguir ilustra esse mecanismo:

Figura 12 – Arquitetura do modelo RMI

Diferentemente de uma chamada local em Java, uma invocação RMI utiliza a passagem de parâmetros
por cópia (pass-by-value) ao invés da passagem por referência (pass-by-reference), exceto com relação
a objetos remotos que são passados por referência ao invés de se copiar a implementação remota. O
modelo RMI fornece classes e interfaces que possibilitam a localização, o carregamento, e a execução
confiável de objetos remotos. Atualmente, o modelo RMI, provê um serviço bastante primitivo e não-
persistente, de nomeação. Ele também fornece um carregador de classes (class loader) que carrega

4
Componentes de programas escritos na linguagem Java.
Middlewares em Sistemas Distribuídos 12

stubs do servidor automaticamente. Um stub RMI funciona como um proxy no cliente para o objeto
remoto. Além disso, o modelo também provê mecanismos extras de segurança para garantir que estes
proxies tenham o comportamento esperado.

Em um sistema distribuído, um coletor de lixo deve ser apto a automaticamente remover objetos remotos
que não são mais referenciados por nenhum cliente. O modelo RMI utiliza um mecanismo de coleta de
lixo por contagem de referências que mantém um histórico de todas as referências externas ativas
dentro de uma máquina virtual. Neste contexto, uma referência externa ativa é apenas uma conexão
TCP/IP entre um cliente e um servidor. Cada vez que o cliente obtém uma referência, o contador de
referências daquele objeto é incrementado de 1; e é decrementado de 1 quando o cliente pára de
referenciar aquele objeto, ou seja, quando a conexão é finalizada. Quando o contador de referência
alcança zero, o RMI coloca o objeto servidor na lista de referências fracas (weak reference list). O coletor
de lixo pode então remover o objeto.

No modelo RMI, uma referência para um objeto remoto é "emprestada" (leased) por um período de
tempo para o cliente. O período de empréstimo se inicia quando a chamada remota é recebida. É de
responsabilidade do cliente renovar o período de empréstimo através de chamadas adicionais no
servidor antes que o prazo se expire.

Pelo fato do modelo RMI poder resolver dinamicamente invocações de métodos entre Máquinas Virtuais,
ele fornece um ambiente totalmente distribuído e orientado a objetos. Também pelo fato do modelo RMI
ser nativo da linguagem Java, os desenvolvedores trabalham dentro de um único modelo de objetos (o
modelo Java), ao invés de trabalhar com múltiplos modelos de objetos (Java, CORBA IDL, e outros). Isto
remove bastante a complexidade de programação. Diferente de modelos de objetos com linguagens
neutras, o RMI não requer mapeamento para linguagens de definição de interfaces, como a IDL.

Antes da invocação de um método em um objeto remoto, o cliente deve primeiro obter uma referência
para este objeto. Geralmente, o cliente obtém essa referência como retorno da invocação de um método.
O modelo RMI também fornece um serviço simples de nomeação, conhecido como RMI registry, ou
simplesmente registro RMI, que permite a obtenção das referências dos objetos através de nomes. O
RMI define o serviço de nomeação utilizando duas classes e uma interface. Tipicamente, o cliente
interage com a classe Naming para obter os serviços do registro do RMI. O registro RMI é definido pela
interface Registry. É importante notar que este registro é um objeto servidor remoto. Isto significa que se
pode acessar seus métodos através da rede utilizando invocações remotas. A classe LocateRegistry
auxilia na localização do registro RMI. A JavaSoft fornece uma implementação da interface Registry.
Esta implementação não-persistente apenas suporta nomes simples. Nesta implementação, os clientes
utilizam apenas os métodos lookup e invoke. Toda essa comunicação entre objetos é realizada através
do protocolo Java Remote Method Protocol (JRMP).

A Figura 13 ilustra uma chamada típica de um método remoto utilizando a arquitetura RMI. A figura
mostra o servidor registrando seus objetos no registro RMI e o cliente obtendo a referência do objeto
requisitado através do mesmo. Com a referência retornada, o cliente pode então realizar a invocação do
método remoto. Os dois servidores Web da figura funcionam como repositórios de classes e stubs. A
idéia principal é que os clientes, e mesmo os servidores, possam carregar dinamicamente classes e
stubs necessários para a aplicação e que não se encontram localmente. Esse procedimento é conhecido
como dynamic stub-loading. O registro RMI armazena, juntamente com a referência de cada objeto, a
URL que permite a localização das classes e stubs. É importante lembrar que sem os stubs apropriados,
um cliente não pode fazer uma invocação remota em um objeto. A localização das classes e stubs é
definida pela propriedade java.rmi.server.codebase informada para a Máquina Virtual na inicialização do
programa. Além de servidores Web, servidores FTP também podem ser utilizados como repositórios das
classes e dos stubs.
Middlewares em Sistemas Distribuídos 13

Figura 13 – Arquitetura de uma chamada remota de método (RMI)

Atualmente, há um esforço grande em especificar um modelo padrão entre RMI e CORBA. Duas
especificações estão em desenvolvimento, mas já podem ser encontradas para utilização:

a) RMI-over-IIOP: é uma versão do modelo RMI que funciona no topo do protocolo IIOP. O
protocolo IIOP provê alguns benefícios, entre eles: interoperabilidade com outros objetos escritos
em outras linguagens, e um padrão aberto para objetos distribuídos;
b) RMI/IDL: Através desse padrão é possível especificar interfaces CORBA utilizando a semântica
do RMI ao invés da IDL de CORBA. O compilador gera automaticamente CORBA IDL, stubs e
5
skeletons. Enterprise JavaBeans utiliza este subconjunto RMI/IDL.

Resumidamente, pode-se concluir que o modelo RMI oferece alguns dos elementos críticos de um
sistema de objetos distribuídos em Java pelo fato do RMI ser nativo da linguagem Java. Possui
facilidades de comunicação de objetos análogas ao protocolo IIOP de CORBA, e seu sistema de
serialização de objetos fornece uma maneira prática de se transferir ou requisitar uma instância de um
processo remoto para outro.

Além disso, também possui uma forte influência do modelo CORBA e pode ser definido como um novo
tipo de ORB construído no topo do modelo de objetos de Java. E como um ORB, RMI introduz cinco
inovações-chave:

a) Permite mover código ao invés de somente dados;

b) Garante a integridade do código carregado remotamente;
c) Permite a passagem de objetos por valor (objects-by-value);
d) Utiliza Java como uma linguagem para definição das interfaces e para a implementação dos
métodos;
e) Utiliza um mecanismo baseado em URLs para a nomeação dos objetos.
6
Além dessas inovações-chave, o modelo RMI implementado pela plataforma Java 2 introduz
características similares ao modelo CORBA, que tornam a implementação com o uso de RMI-over-IIOP
mais fácil e flexível. Entre elas: suporte para persistência em referências de objetos, suporte para
ativação remota de objetos, e suporte para sockets customizados.

O modelo RMI pode ser bem vantajoso para programadores Java. Ele torna o ORB transparente e
naturalmente estende o alcance das funcionalidades da linguagem Java. Com a utilização de RMI, não é
necessário utilizar a IDL de CORBA ou qualquer tipo de conversão Java/CORBA. Entretanto, utilizando
apenas RMI, perde-se o poder da infraestrutura do modelo CORBA. Para compensar esta deficiência,
pode-se utilizar RMI-over-IIOP, garantindo a união entre os dois modelos: RMI e CORBA.

5
A especificação EJB define um modelo de componentes-servidores para JavaBeans. Um EJB é um JavaBean especializado e
não-visual que é executado no servidor.
6
O nome "Java 2" é uma definição para as implementações JDK 1.2 e superiores, incluindo J2SE, J2EE e J2ME.
Middlewares em Sistemas Distribuídos 14

4.2.4.3 Common Object Request Broker Architecture (CORBA)

Padrões para a interoperabilidade entre objetos distribuídos, também chamados de modelos de
integração de objetos ou infra-estruturas de componentes de software, permitem que objetos escritos em
diferentes linguagens e compilados por diferentes compiladores comuniquem-se através de protocolos
padronizados de forma transparente. Nesta classe de padrões, um dos que tem tido maior destaque é o
padrão CORBA, por ser uma especificação aberta, independente de linguagem e fabricante. A
infraestrutura oferecida por CORBA gerencia todos os detalhes da interoperabilidade entre objetos,
assegurando a possibilidade de se desenvolver sistemas baseados em interação que incorporam
componentes de múltiplas origens.

CORBA começou a ser desenvolvido em 1989, quando um grupo de empresas reuniu-se em uma
organização, denominada OMG, com a finalidade de especificar uma arquitetura global e normas para
permitir o trabalho conjunto de componentes de diferentes origens. A idéia era aproveitar os benefícios
do paradigma da orientação a objeto, principalmente a noção de encapsulamento dos dados e da
implementação de um objeto através da sua interface.

A arquitetura definida para CORBA permite que objetos troquem mensagens de forma transparente
através de um “barramento de software”. Para isso, os objetos que interagem através desse barramento
têm a suas interfaces descritas em uma linguagem padrão, chamada de Interface Definition Language
(IDL), e implementação escrita em qualquer linguagem que possua o mapeamento para CORBA.

Para a integração entre aplicações, o OMG definiu uma arquitetura denominada OMA. Enquanto CORBA
permite a interoperabilidade entre objetos, a OMA agrupa um conjunto de objetos CORBA em serviços e
facilidades, que oferecem suporte para o desenvolvimento de aplicações que usam objetos CORBA.
Maiores detalhes e o modelo de referência para essa arquitetura são apresentados nas próximas
seções.

4.2.4.3.1 Modelo de Referência

A arquitetura OMA tem seus objetivos técnicos e terminologia descritas através do Object Mangement
Guide (OMAG). Este guia inclui O Modelo de Objeto OMG, que define a semântica comum para a
especificação das características externas visíveis dos objetos, independente de implementação, e o
Modelo de Referência OMA.

Através e um série de RFPs, a OMG está povoando o OMA com especificações detalhadas para cada
componente e categoria de interface no Modelo de Referência. Essas especificações incluem: CORBA,
CORBAservices, e CORBAfacilities.

O modelo de referência identifica e caracteriza os componentes, interfaces, e protocolos que compõem o

OMA. Ele inclui o componente Object Request Broker (ORB) que habilita clientes e objetos a se
comunicarem em um ambiente distribuído; há quatro categorias de interfaces de objetos:

- Objetos de Serviços (Object Services) são interfaces para serviços gerais que são
provavelmente usados em qualquer programa baseado em objetos distribuídos;
- Recursos Comuns (Common Facilities) são interfaces para facilidades horizontais orientadas
para usuário finais, aplicáveis a maioria dos domínios de aplicação;
- Interfaces de Domínio (Domain Interfaces) são interfaces de aplicações de um domínio
específico, e;
- Interfaces de Aplicação (Application Interfaces) são interfaces não padronizadas para
aplicações específicas.

Na Figura 14 esse modelo de Referência é apresentado.

Middlewares em Sistemas Distribuídos 15

Interfaces de Interfaces de Interfaces de

aplicações específicas aplicações de facilidades
não padronizadas domínios específicos horizontais

Interfaces de Interfaces de Facilidades

Aplicações Domínios Comuns

Object Request Broker (ORB)

Objetos de Serviços

Interfaces de serviços
gerais
Figura 14 – Modelo de referência OMA

Nas próximas subseções as partes do modelo de referência serão apresentadas em maiores detalhes.

4.2.4.3.2 Object Request Broker (ORB)

A CORBA define as interfaces de programação para o componente ORB OMA. Um ORB é um
mecanismo básico pelo qual objetos transparentemente fazem requisições para – e recebem respostas
de – cada outro objeto na mesma máquina ou através de uma rede. O cliente não precisa estar ciente do
mecanismo usado para comunicar ou ativar um objeto, ou como o objeto é implementado, nem onde o
objeto está localizado. Assim, a ORB forma a base para a construção de aplicações construídas com
objetos distribuídos, e para a interoperabilidade entre aplicações em ambientes homogêneos e
heterogêneos.

A OMG IDL provê um caminho padronizado para definir as interfaces dos objetos CORBA. A definição
IDL é o contrato entre o implementador de um objeto e o cliente. A IDL é uma linguagem declarativa
fortemente tipada que é independente de linguagem de programação. Mapeamentos de linguagem
habilitam objetos a serem implementados e enviar requisições na linguagem de programação do
desenvolvedor em uma forma que é natural para tal linguagem.

A figura a seguir mostra a arquitetura de uma ORB CORBA.

Figura 15 – Estrutura de uma ORB padrão CORBA

A figura acima mostra os dois lados de um ORB CORBA: o lado do cliente e o lado do servidor. A função
de cada componente é descrita abaixo:
Middlewares em Sistemas Distribuídos 16

a) Client IDL Stubs: provêem interfaces estáticas para os acessos aos objetos remotos. Estes stubs
pré-compilados definem como o cliente invoca serviços nos servidores. Do ponto de vista do
cliente, os stubs agem como um proxy para o objeto remoto do servidor. Os serviços são
definidos utilizando-se a IDL, e os stubs para os clientes e servidores são gerados pelo
compilador IDL. Um cliente deve possuir um stub para cada interface que ele utiliza no servidor.
Os stubs também incluem código para realizar o marshalling (codificação e decodificação dos
métodos e seus parâmetros em mensagens com formatos padrões). Ele também inclui código
para acesso a outras linguagens de alto nível como C, C++;
b) Dynamic Invocation Interface (DII): permite descobrir métodos de servidores remotos em tempo
de execução. CORBA define APIs para a localização de meta-dados que definem as interfaces
dos servidores, para a geração dos parâmetros, para invocação remota, e para o retorno dos
dados;
c) Interface Repository APIs (IR): permitem obter e modificar a descrição de todas as interfaces
dos componentes registrados, os métodos que eles suportam, e os parâmetros que eles utilizam.
O Repositório de Interfaces é uma base de dados distribuída que contém as definições das
interfaces no formato da IDL;
d) ORB Interface: consiste de algumas APIs para serviços locais que podem ser úteis para a
aplicação. Por exemplo, CORBA fornece serviços para converter uma referência de um objeto
em um string, e vice-versa.

O suporte para invocações estáticas e dinâmicas oferece um alto poder de programação para a
computação distribuída de CORBA. As invocações estáticas são mais fáceis de programar e possuem
uma performance melhor. As invocações dinâmicas fornecem uma alta flexibilidade, embora sejam mais
difíceis na programação; são muito úteis para se descobrir serviços em tempo de execução.

Os servidores não podem distinguir a diferença entre as invocações estáticas ou dinâmicas pois ambas
possuem a mesma semântica. Em ambos os casos, o ORB localiza o adaptador do objeto remoto,
transmite os parâmetros, e transfere o controle para a implementação do objeto através dos stubs do
servidor (skeletons). O lado do servidor:

a) Server IDL Stubs (Static Skeletons): fornecem interfaces estáticas para cada serviço exportado
pelo servidor. Esses stubs também são criados pelo compilador IDL.
b) Dynamic Skeleton Interface (DSI): foi introduzida com a versão CORBA 2.0 e fornece
mecanismos de ligação (binding) em tempo de execução para servidores que necessitam
manipular requisições de objetos que não possuem stubs nem skeletons compilados. O DSI do
servidor é equivalente ao DII do cliente.
c) Object Adapter: localiza-se no topo dos serviços de comunicação do ORB e recebe as
requisições dos serviços antes dos objetos do servidor. Ele provê um ambiente de execução
para a instanciação dos objetos dos servidores, para a passagem das requisições, e para a
atribuição de identificadores únicos para cada objeto (object references);
d) Implementation Repository (IR): fornece um repositório de informações sobre as classes que um
objeto suporta, os objetos que estão instanciados, e os identificadores únicos de cada um. É
utilizado também para armazenar informações adicionais associadas com as implementações de
cada ORB, entre elas: segurança, dados administrativos, entre outras;
e) ORB Interface: consiste de algumas APIs para serviços locais que são idênticas àquelas
fornecidas para o cliente.

Mas o grande trunfo de CORBA é a compatibilidade entre ORBs de fabricantes distintos, o que é
chamado de Arquitetura Inter-ORB. Essa arquitetura é composta por três protocolos básicos:

a) GIOP (General Inter-ORB Protocol): especifica um conjunto de formatos de mensagens e

representações comuns de dados para a comunicação entre ORBs. GIOP define sete formatos
de mensagens que cobrem todas as semânticas de requisições e respostas do ORB;
b) IIOP (Internet Inter-ORB Protocol): especifica como as mensagens GIOP são trocadas em uma
rede TCP/IP. Com isso pode-se utilizar a Internet como ponte de ligação entre ORBs distintos;
c) ESIOPs (Environment-Specific Inter-ORB Protocols): fornecem interoperabilidade para uma rede
específica, como um ambiente DCE, por exemplo. Os ESIOPs fornecem ambientes bastante
robustos.
Middlewares em Sistemas Distribuídos 17

4.2.4.3.3 Facilidades Comuns (CORBAfacilities)

As Facilidades Comuns (Common Facilities) são interfaces para recursos horizontais orientados a
usuários finais, aplicáveis para a maioria dos domínios de aplicação. As Facilidades Comuns OMG, são
chamadas de CORBAfacilities.

Uma especificação de uma Facilidade Comum ou de um Objeto de Serviço tipicamente inclui a lista de
definições de interface – expressas em OMG IDL – que objetos devem suportar de maneira a prover,
usar ou participar na facilidade ou serviço. Como em todas as especificações adotadas pela OMG,
facilidades e serviços são definidos em termos de interfaces e suas semânticas, e não em uma particular
implementação.

4.2.4.3.4 Domínio de Interfaces

O Domínio de Interface especifica interfaces de um domínio específico para domínios de aplicação como
Finanças, Saúde, Industrial, Telecomunicações, Comercio Eletrônico, e Transporte. A Figura 14 destaca
o fato de que as Interfaces de Domínio serão agrupadas pelo domínio de aplicação mostrando uma
possível lista de coleções de Interfaces de Domínio.

4.2.4.3.5 Objetos de Serviços (CORBAservices)

Os Objetos de Serviços são serviços de propósitos gerais, fundamentais para o desenvolvimento de
aplicações baseadas em CORBA. Esses serviços provêem uma base universal – independente do
domínio de aplicação – para a interoperabilidade de aplicações.

Os Objetos de Serviços são os blocos básicos para a construção de aplicações com objetos distribuídos.
Esses objetos podem ser combinados de várias maneiras diferentes e postos em diferentes aplicações.
7
Eles podem ser usados para construir facilidades de alto nível e frameworks de objetos que podem
interoperar através de múltiplos ambientes de plataformas.

Os Objetos de Serviços OMG adotados são coletivamente chamados de CORBAservices, abaixo é dada
uma descrição resumida de cada serviço.

• O Serviço de Nomeação (Naming Service) provê capacidade para ligar um nome a um objeto.
Resolver um nome é determinar o objeto associado a um determinado nome. Através do uso de
um modelo bem genérico, as implementações do Serviço de Nomeação podem ser aplicações
específicas ou serem baseadas em uma variedade de sistemas de nomeação atualmente
disponíveis.

• O Serviço de Evento (Event Service) provê capacidades básicas que podem ser configuradas
flexível e poderosamente. Esse serviço suporta eventos assíncronos (desacoplamento do
produtor e consumidor), e através de implementações apropriadas de canais de eventos oferece
uma entrega confiável dos eventos. Os modelos de entrega push e pull são suportados; isto é,
consumidores podem requisitar eventos ou serem notificados de eventos ocorridos.

• O Serviço de Ciclo de Vida (Life Cycle Service) define operações para cópia, movimentação, e
remoção de objetos de grafos de objetos relacionados, enquanto o Serviço de Relacionamento
(Relationship Service) permite que grafos de objetos relacionados sejam percorridos sem a
ativação dos objetos.

• O Serviço de Persistência de Objeto (Persistent Object Service – POS) provê uma lista de
interfaces comuns para retenção e gerenciamento do estado de persistência dos objetos. O
objeto em última instância tem a responsabilidade de gerenciar seu estado, mas pode usar ou
delegar para O Serviço de Persistência de Objeto o verdadeiro trabalho. A maior característica
do Serviço de Persistência de Objeto (e da arquitetura OMG) é seu openness. Isto significa que
pode haver uma variedade de diferentes clientes e implementações do Serviço de Persistência
de Objeto trabalhando juntos.

7
Frameworks de Objetos são coleções de objetos que incorporam um projeto abstrato para a solução de problemas relacionados
(categorizados dentro de um Domínio de Aplicação, Facilidade Comum e Objeto de Serviço).
Middlewares em Sistemas Distribuídos 18

• O Serviço de Transação (Transaction Service) suporta múltiplos modelos de transação,

incluindo o modelo flat (obrigatório na especificação) e o modelo nested (opcional). O Serviço de
Transação suporta interoperabilidade entre diferentes modelos de programação. Por exemplo,
alguns usuários querem adicionar implementações de objetos a aplicações procedimentais e
aumentar as implementações de objetos com código que usa o paradigma procedimental. Para
tal, o ambiente de transação requer que o objeto e o código procedimental compartilhem uma
única transação. Interoperabilidade através da rede também é suportada, desde que usuários
necessitem de comunicação entre diferentes sistemas, incluindo a habilidade de se ter um
serviço de transação interoperando com outro serviço de transação usando diferentes ORBs.

• O Serviço de Controle de Concorrência (Concurrency Control Service) capacita múltiplos

clientes a coordenarem seus acessos a recursos compartilhados. Coordenação de acesso a um
recurso significa que múltiplos acessos concorrentes de clientes a um único recurso são
conciliados, de forma que o recurso fique em um estado consistente.

• O Serviço de Relacionamento (Relationship Service) permite que entidades e relacionamentos

sejam explicitamente representados. Entidades são representadas como objetos CORBA. Esse
serviço define dois novos tipos de objetos: relacionamento e papel. Um papel representa um
objeto CORBA em uma relação. A interface do objeto relacionamento pode ser estendida para
adicionar atributos específicos de relacionamentos e operações. Assim, relacionamentos de
diferentes graus podem ser definidos. Similarmente, a interface do objeto papel pode ser
estendida para adicionar atributos de papéis específicos e operações. Tipos e restrições de
cardinalidade podem ser expressos e checados: exceções são lançadas quando uma restrição é
violada.

• O Serviço de Externalização (Externalization Service) define protocolos e convenções para

externalização e internalização de objetos. Externalizar um objeto é registrar o estado do objeto
em uma stream de dados (na memória, em um arquivo no disco, através da rede, e assim por
diante), para depois esse objeto ser internalizado em um novo objeto no mesmo ou em um
processo diferente. O objeto externalizado pode existir por um tempo arbitrário, ser transportado
para fora da ORB, e ser internalizado em uma ORB diferente. Para a portabilidade, clientes
podem requisitar que dados externalizados sejam armazenados em um arquivo cujo formato é
definido com a Especificação do Serviço de Externalização.

• O Serviço de Licenciamento (Licensing Service) provê um mecanismo para produtores

controlarem o uso de suas propriedades intelectuais. Produtores podem implementar o Serviço
de Licenciamento de acordo com suas próprias necessidades e as necessidades de seus
clientes, pois o Serviço de Licenciamento não impõe suas próprias políticas de comercialização
ou práticas.

• O Serviço de Consulta (Query Service) permite que usuários e objetos invoquem consultas em
coleções de outros objetos. As consultas são declarações com predicados e incluem habilidade
para especificar valores de atributos; para invocar operações arbitrárias; e para invocar outros
Objetos de Serviços.

• O Serviço de Propriedade (Property Service) provê a habilidade para dinamicamente associar

valores nomeados com objetos fora do sistema estático do tipo IDL. Ele define operações para
criar e manipular listas de tuplas contendo nome de valores ou modos de nomes de valores. Os
nomes são apenas strings IDL OMG. Os valores são do tipo any definido pela OMG. O uso do
tipo any é significativo para que uma implementação de uma propriedade de serviço negocie
com qualquer valor que possa ser representado em um sistema do tipo IDL OMG. O Serviço de
Propriedade foi projetado para ser o bloco básico de construção, robusto o suficiente para ser
aplicável para uma larga lista de aplicações.

• O Serviço de Segurança (Security Service) compreende:

o Identificação e autenticação de chefes (usuários humanos e objetos que necessitam
operar sobre seus próprios direitos) para verificar se eles são quem dizem ser;
o Autorização e controle de acesso – decidindo se um chefe pode acessar um objeto,
normalmente usando a identificação e/ou outro atributo de privilégio do chefe (tal como
Middlewares em Sistemas Distribuídos 19

papel, grupos, seguro de liberação) e os atributos de controle do objeto alvo (declarando

quais chefes, ou chefes com quais atributos) que podem acessá-lo;
o Exame de Segurança para fazer usuários responsáveis pela segurança das suas
ações;
o Segurança de Comunicação entre objetos, que está freqüentemente sobre camadas
baixas inseguras de comunicação. Ele provê segurança para a comunicação entre o
cliente e o alvo, que podem requerer autenticação de clientes para alvos e
autenticação de alvos para clientes, ou proteção de integridade e (opcionalmente)
proteção de confidencialidade de mensagens no trânsito entre objetos.
o Não-repudiação provê evidencia irrefutável de ações tais como prova da origem dos
dados para o destinatário, ou prova do recebimento dos pelo remetente, protegendo
contra falsas tentativas subseqüentes de negação do recebimento ou envio de dados.
o Administração de segurança de informação (por exemplo, política de segurança)
também é necessária.

• O Serviço de Tempo (Time Service) habilita o usuário a obter o tempo atual junto com uma
estimativa de erro associada a ele. Ele averigua a ordem na qual os eventos ocorrem e computa
o intervalo entre dois eventos. Ele é formado por duas interfaces: TimeService, que gerencia o
Tempo Universal dos Objetos (Univeral Time Objetos – UTOs) e o Intervalo de Tempo dos
Objetos (Time Interval Objects – TIOs), e; TimeEventService, que contém o Serviço de
Temporização de Eventos que gerencia o Manipulador de Objetos de Temporização de Eventos

• O Serviço de Coleção (Collections Service) provê um caminho uniforme para criar e manipular
as coleções mais comuns genericamente. Coleções são grupos de objetos que, como um grupo,
suportam algumas operações e exibem comportamentos específicos que estão relacionados
com a natureza da coleção, em vez de estarem relacionados ao tipo de objeto que eles contém.
Exemplos de coleções são listas, filas, pilhas, e árvores binárias.

• O Serviço de Negociação (Trading Service) possibilita a localização de objetos através dos

tipos de serviços oferecidos;

4.2.4.4 Conclusões
Com os três modelos de computação distribuída, descritos nas seções anteriores, pode-se discutir
algumas características comuns entre os modelos. A Tabela 1 mostra alguns dos itens comuns e
essenciais para a composição e o desenvolvimento de aplicações em um ambiente distribuído.

Tabela 1 - Comparação entre as plataformas.

Característica CORBA DCOM RMI

Persistência de Nomes Sim Não (exceto com o Não
uso de monikers)
Protocolo Padrão para o ORB Sim (IIOP) Não Não
Alta Escalabilidade Sim (federações de Não Não
ORBs)

Nomes baseados em URLs Sim (não volátil) Sim (via URL Sim (volátil)
monikers)

Referências Persistentes de Objetos Sim Não Sim (com Java 2)

Passagem de Objetos por Valor Sim (pass-by- Não Sim

value)

Localização Dinâmica Sim (via IR) Sim (via Type Não

Library)

Invocação Dinâmica Sim (via DII) Sim (via IDispatch) Não

Descrição das Interfaces Sim (via CORBA Sim (via MIDL) Sim (via Java
IDL) interfaces)
Middlewares em Sistemas Distribuídos 20

Entre as características mencionadas na tabela acima, algumas merecem especial destaque e são
explicadas a seguir.
8
a) Localização Dinâmica: apenas CORBA e DCOM possuem suporte para introspecção de
objetos. Ambos os ORBs permitem a descoberta dinâmica de interfaces de objetos. CORBA
também suporta Repositórios de Interfaces inter-ORBs. DCOM suporta apenas repositórios
locais para as Type Libraries.
b) Invocações Dinâmicas: apenas CORBA e DCOM suportam invocações dinâmicas. Esse
processo, conhecido também como late-binding, permite a construção de chamadas de métodos
em tempo de execução.
c) Referências Persistentes de Objetos: somente CORBA e RMI possuem objetos persistentes que
possuem referências persistentes. DCOM possui objetos transientes que se pode associar com
um contexto através dos monikers.
d) Nomes baseados em URLs: esta característica pode ser bastante útil em intranets e na Internet.
RMI e CORBA suportam esquemas de nomes baseados em URL que permitem associar um
objeto com uma URL. DCOM também suporta esta característica via monikers.

8
Introspecção é o processo de uma classe inspecionar outra classe para determinar quais propriedades, eventos e métodos esta
suporta.
Middlewares em Sistemas Distribuídos 21

REFERÊNCIAS BIBLIOGRÁFICAS
MIDDLEWARE
http://www.sei.cmu.edu/str/descriptions/middleware.html

[Bernstein 96] Bernstein, Philip A. "Middleware: A Model for Distributed Services." Communications of
the ACM 39, 2 (February 1996): 86-97.
[Client 95] "Middleware Can Mask the Complexity of your Distributed Environment." Client/Server
Economics Letter 2, 6 (June 1995): 1-5.
[Eckerson 95] Eckerson, Wayne W. "Three Tier Client/Server Architecture: Achieving Scalability,
Performance, and Efficiency in Client Server Applications." Open Information Systems 10,
1 (January 1995): 3(20).
[Schreiber 95] Schreiber, Richard. "Middleware Demystified." Datamation 41, 6 (April 1, 1995): 41-45.

TRANSACTION PROCESSING MONITOR TECHNOLOGY

http://www.sei.cmu.edu/str/descriptions/tpmt.html

[Dickman 95] Dickman, A. "Two-Tier Versus Three-Tier Apps." Informationweek 553 (November 13,
1995): 74-80.
[Hudson 94] Hudson, D. & Johnson, J. Client-Server Goes Business Critical. Dennis, MA: The Standish
Group International, 1994.
[Schussel 96] Schussel, George. Client/Server Past, Present, and Future [online]. Available WWW
<URL: http://www.dciexpo.com/geos/> (1995).
[TP 96] TP Lite vs. TP Heavy [online]. Available WWW
<URL: http://www.byte.com/art/9504/sec11/art4.htm> (1996).

MESSAGE-ORIENTED MIDDLEWARE
http://www.sei.cmu.edu/str/descriptions/momt.html

[Rao 95] Rao, B.R. "Making the Most of Middleware." Data Communications International 24, 12
(September 1995): 89-96.
[Steinke 95] Steinke, Steve. "Middleware Meets the Network." LAN: The Network Solutions Magazine 10,
13 (December 1995): 56.

OBJECT REQUEST BROKER

http://www.sei.cmu.edu/str/descriptions/orb.html

[Abowd 96] Abowd, Gregory, et al. "Architectural Analysis of ORBs." Object Magazine 6, 1 (March
1996): 44-51.
[Brown 96] Brown, A. & Wallnau, K. "A Framework for Evaluating Software Technology." IEEE Software
13, 5 (September 1996): 39-49.
[Cobb 95] Cobb, Edward E. "TP Monitors and ORBs: A Superior Client/Server Alternative." Object
Magazine 4, 9 (February 1995): 57-61.
[CORBA 96] The Common Object Request Broker: Architecture and Specification, Version 2.0.
Framingham, MA: Object Management Group, 1996. Also available [online] WWW
<URL: http://www.omg.org> (1996).
[Reddy 95] Reddy, Madhu. "ORBs and ODBMSs: Two Complementary Ways to Distribute Objects."
Object Magazine 5, 3 (June 1995): 24-30.
[RMI 97] Remote Method Invocation [online]. Avaliable WWW
<URL: http://java.sun.com/products/jdk/1.1/docs/guide/rmi> (1997).
[Steinke 95] Steinke, Steve. "Middleware Meets the Network." LAN: The Network Solutions Magazine
10, 13 (December 1995): 56.
Middlewares em Sistemas Distribuídos 22

[Tkach 94] Tkach, Daniel & Puttick, Richard. Object Technology in Application Development. Redwood
City, CA: Benjamin/Cummings Publishing Company, 1994.
[Wade 94] Wade, Andrew E. "Distributed Client-Server Databases." Object Magazine 4, 1 (April 1994):
47-52.
[Wallnau 96] Wallnau, Kurt & Wallace, Evan. "A Situated Evaluation of the Object Management Group's
(OMG) Object Management Architecture (OMA)," 168-178. Proceedings of the OOPSLA'96.
San Jose, CA, October 6-10, 1996. New York, NY: ACM, 1996. Presentation available
[online] FTP.
<URL: ftp://ftp.sei.cmu.edu/pub/corba/OOPSLA/present> (1996).

COMPONENT OBJECT MODEL (COM), DCOM, AND RELATED CAPABILITIES

http://www.sei.cmu.edu/str/descriptions/com.html

[Active 97] Active Group home page [online]. Available WWW

<URL: http://www.activex.org/> (1997).
[Brockschmidt 95] Brockschmidt, Kraig. Inside OLE, 2nd edition, Microsoft Press, 1995
[Chappell 96] Chappell, David. DCE and Objects [online]. Available WWW
<URL: http://www.osf.org/dce/3rd-party/ChapRpt1.html> (1996).
[COM 95] Microsoft Corporation. The Component Object Model Specification, Version 0.9,
October 24, 1995 [online]. Available WWW
<URL: http://www.microsoft.com/oledev/> (1995).
[DCOM 97] Microsoft Corporation. Distributed Component Object Model Protocol-DCOM/1.0, draft,
November 1996 [online]. Available WWW
<URL: http://www.microsoft.com/oledev/> (1996).
[Foody 96] Foody, M.A. "OLE and COM vs. CORBA." UNIX Review 14, 4. (April 1996): 43-45.
[Harmon 99] Harmon, Paul. Microsoft transaction Server. Component development Strategies Vol
IX No 3. Available WWW <URL: http://www.cutter.com/cds/1999toc.htm#mar > 1999
[Kirtland 97] Kirtland, Mary. "The COM+ Programming Model Makes it Easy to Write Components
in Any Language". Microsoft System Journal. Dec, 1997.
[Microsoft 96] Microsoft Corporation. Microsoft Authenticode Technology [online]. Available WWW
<URL: http://www.microsoft.com/security/tech/misf8.htm> (1996).
[MSCOM 97] Microsoft home page [online]. The site provides information about COM, DCOM and
OLE. Available WWW
<URL: http://www.microsoft.com/> (1997).
[OMG 97] Object Management Group home page [online]. The site provides information
comparing DCOM (ActiveX) to CORBA. Available WWW
<URL: http://www.omg.org/> (1997).
[VeriSign 97] Verisign home page [online]. Available WWW
<URL: http://www.verisign.com> (1997).

COMMON OBJECT REQUEST BROKER ARCHITECTURE

http://www.sei.cmu.edu/str/descriptions/corba.html

[Baker 94] Baker, S. "CORBA Implementation Issues." IEEE Colloquium on Distributed Object
Management Digest 1994 7 (January 1994): 24-25.
[Brando 96] Brando, T. "Comparing CORBA & DCE." Object Magazine 6, 1 (March 1996): 52-7.
[Brown 96] Brown, A. & Wallnau, K. "A Framework for Evaluating Software Technology." IEEE
Software 13, 5 (September 1996): 39-49.
[CORBA 96] The Common Object Request Broker: Architecture and Specification, Version 2.0.
Framingham, MA: Object Management Group, 1996. Also available [online] WWW
<URL: http://www.omg.org> (1996).
[CORBANet 96] Distributed Software Technology Center Home Page [online]. Available WWW
Middlewares em Sistemas Distribuídos 23

<URL: http://corbanet.dstc.edu.au> (1996).

[Deng 95] Deng, R.H., et al. "Integrating Security in CORBA-Based Object Architectures," 50-61.
Proceedings of the 1995 IEEE Symposium on Security and Privacy. Oakland, CA, May
8-10, 1995. Los Alamitos, CA: IEEE Computer Society Press, 1995.
[Foody 96] Foody, M.A. "OLE and COM vs. CORBA." UNIX Review 14, 4. (April 1996): 43-45.
[Jell 95] Jell, T. & Stal, M. "Comparing, Contrasting, and Interweaving CORBA and OLE," 140-
144. Object Expo Europe 1995. London, UK, September 25-29, 1995. Newdigate, UK:
SIGS Conferences, 1995.
[Kain 94] Kain, J.B. "An Overview of OMG's CORBA," 131-134. Proceedings of OBJECT EXPO
`94. New York, NY, June 6-10, 1994. New York, NY: SIGS Publications, 1994.
[Mowbray 93] Mowbray, T.J. & Brando, T. "Interoperability and CORBA-Based Open Systems." Object
Magazine 3, 3 (September/October 1993): 50-4.
[OMG 96] Object Management Group home page [online]. Available WWW
<URL: http://www.omg.org> (1996).
[Roy 95] Roy, Mark & Ewald, Alan. "Distributed Object Interoperability." Object Magazine 5, 1
(March/April 1995): 18.
[Steinke 95] Steinke, Steve. "Middleware Meets the Network." LAN: The Network Solutions Magazine
10, 13 (December 1995): 56.
[Tibbets 95] Tibbets, Fred. "CORBA: A Common Touch for Distributed Applications." Data Comm
Magazine 24, 7 (May 1995): 71-75.
[Wallace 96] Wallnau, Kurt & Wallace, Evan. "A Situated Evaluation of the Object Management
Group's (OMG) Object Management Architecture (OMA)," 168-178. Proceedings of the
OOPSLA'96. San Jose, CA, October 6-10, 1996. New York, NY: ACM, 1996.
Presentation available [online] FTP.
<URL: ftp://ftp.sei.cmu.edu/pub/corba/OOPSLA/present> (1996).
[Watson 96] Watson, A. "The OMG After CORBA 2." Object Magazine 6, 1 (March 1996): 58-60.

OBJECT MANAGEMENT GROUP

http://www.omg.org

DISTRIBUTED SYSTEMS: PRINCIPLES AND PARADIGMS

http://www.cs.vu.nl/~ast