CAPÍTULO 6 CORBA / DCOM

Transcrição

1 CAPÍTULO 6 CORBA / DCOM Após determinar quais objetos precisam ser implementados como locais e quais como distribuídos, é difícil optar por uma arquitetura de distribuição. Por exemplo, num caso hipotético, pode-se ter algumas das seguintes soluções (Schultz, 1997): Hardware CICS e sistema operacional OS/2 usando IBM s Distributed Object Model (DSOM). C usando Distributed Computing Environment (DCE). C++ usando Distributed Component Object Model (DCOM). Implementação baseada em uma solução CORBA usando, por exemplo, Iona s Orbix. Baseado em Web usando Java e HTML. Estas arquiteturas suportam o desenvolvimento de aplicações executando num ambiente heterogêneo e distribuído, e dispõem de serviços comuns às aplicações, tais como, comunicação entre cliente e servidor, isolamento das aplicações em relação às plataformas de hardware, sistemas operacionais, protocolos de rede e linguagens de implementação. Cada uma delas apresentará vantagens e desvantagens, isto é, uma melhor adequação para cada sistema em particular. Através de pesquisa bibliográfica, notou-se que as arquiteturas mais referenciadas são: o CORBA, o DCOM e o Java. Este capítulo enfoca a descrição dos resultados da comparação das arquiteturas de distribuição de objetos utilizadas pelo CORBA e DCOM (já descritas nos capítulos anteriores). 153

2 Posteriormente, é descrito o mecanismo utilizado pela linguagem de programação Java (que também permite a distribuição de objetos), porém, há diferenças entre a abordagem adotada pelo Java e a utilizada pelo CORBA e DCOM. 6.1 CORBA/DCOM Ambos, CORBA e DCOM, auxiliam a resolução de problemas surgidos quando se definem e implementam objetos num ambiente complexo. A meta dos sistemas distribuídos é permitir que códigos de programas e dados, armazenados em diferentes plataformas, trabalhem em conjunto. CORBA e DCOM provêem suporte similar para implementação de objetos acessíveis remotamente por aplicações. Esta capacidade simplifica a construção de sistemas distribuídos PADRONIZAÇÃO As organizações devem utilizar padrões como guias no desenvolvimento de sistemas porque tanto produtos podem ser comprados, como aplicações podem ser desenvolvidas com a confiança de que o hardware e o software trabalharão juntos por muitos anos. Os benefícios da padronização dos sistemas em ambientes distribuídos evidenciam-se na redução da complexidade do gerenciamento, no aumento do grau de interoperabilidade e usabilidade, assim como na redução dos custos de administração e suporte, pois estas se tornam mais especializadas (Nimer, 1998). Ao adotar um padrão, uma organização deve considerar a sua disponibilidade, maturidade, influência, estilo, precisão e propósito das suas especificações, assim como, produtos disponíveis, ferramentas de suporte ao desenvolvimento, 154

3 aceitação pelos desenvolvedores e referências de sucesso de implementações aderentes a esse padrão. Deve-se levar em conta também a plataforma de hardware (estações de trabalho, PCs, etc), o sistema operacional (UNIX, Windows, etc) e a rede disponível na organização, assim como, o nível de preparo da equipe (conhecimento de tecnologia de distribuição, padrões, conceitos de orientação a objeto, linguagens de programação orientadas a objeto, etc). Embora enfoquem diferentes aspectos, tanto o CORBA como o DCOM são padrões cujo propósito é atender a complexidade da distribuição de objetos. CORBA foi especificado para suprir os requisitos necessários à construção de um sistema distribuído. Surgiu como uma solução aos problemas enfrentados pelas organizações ao tentar integrar uma mescla de sistemas, mainframes, UNIX com várias arquiteturas de hardware, sistemas operacionais proprietários de minicomputadores, PCs Macintosh e IBM, etc. A meta foi combinar objetos e tecnologia de sistemas distribuídos dentro de uma arquitetura interoperável que pudesse resolver problemas de integração num empreendimento ( enterprise ). Desta forma, o foco principal do CORBA é definir uma estrutura que melhor solucione problemas de ambientes heterogêneos (Mowbray e Ruh, 1997) (Nicol et al, 1993) (Otte et al, 1996) (Tallman e Bradford, 1998). COM é uma infra-estrutura de integração usada para implementar componentes que interagem dentro de um espaço de endereçamento único ou entre processos num único host, enquanto o DCOM é uma extensão do COM que permite a interação entre objetos executando em hosts separados na rede. Assim, o foco principal do DCOM é suportar componentes executando em diferentes estações de trabalho (Grimes, 1997) (Mowbray e Ruh, 1997) (Tallman e Bradford, 1998). 155

4 6.1.2 MODELO DE OBJETO CORBA e DCOM apresentam nos seus modelos de objeto aspectos fundamentais concordantes. Por modelo de objeto entenda-se, basicamente, a forma com que uma arquitetura de distribuição resolve o problema da forte ligação existente entre a aplicação e os objetos a ela relacionados (Betz, 1994). Para minimizar esta ligação, tanto o CORBA como o DCOM, expressa seus modelos de objeto em termos de interface. O conceito de interface é utilizado para definir as funcionalidades de um objeto visto pelo seu cliente. Os detalhes da implementação do objeto são escondidos dos clientes que acessam o objeto somente pela invocação dos métodos definidos na interface os quais são atendidos somente por referência. As invocações remotas dos clientes são executadas no espaço de endereçamento ocupado pelo objeto. Este ocultamento da implementação ou encapsulamento reduz, a um mínimo, a ligação existente entre o cliente e a implementação de um objeto por ele utilizado, tornando possível suportar transparência de localização, plataforma e linguagem de programação. Também permite que programas selecionem a implementação do objeto a ser utilizada em tempo de execução, ao invés de em tempo de compilação ou link. Esta ligação dinâmica ( dynamic binding ) de código executável torna a atualização ( upgrade ) e o reuso da implementação mais fácil (Tallman e Bradford, 1998). Transparência é a possibilidade de esconder, do usuário, o ambiente distribuído. Ambos, CORBA e DCOM provêem: transparência de localização: clientes invocam serviços de objetos sem a preocupação de localizá-los. No DCOM, uma vez que o cliente adquire o ponteiro para a interface desejada de um objeto, ele pode iniciar o uso dos serviços providos por este objeto simplesmente invocando o método da interface. Para o cliente, invocar um método é 156

5 como invocar um procedimento ou função local. No CORBA, o ORB é que se encarrega de enviar a requisição do cliente aonde ela deva ser atendida, isto é, ele localiza o objeto bem como provê os serviços auxiliares necessários para a execução da requisição do cliente. transparência de plataforma: objetos podem ser executados, em diferentes hardwares ou sistemas operacionais, sem a preocupação de resolver as diferenças de representação dos dados existentes entre eles. No DCOM isto é possível através do protocolo Object RPC (ORPC), descrito no Capítulo 4. No CORBA através dos protocolos General inter-orb Protocol (GIOP) e Internet inter-orb Protocol (IIOP), descritos no Capítulo 5. transparência de linguagem de programação: objetos e clientes interagem entre si, apesar de serem implementados usando diferentes linguagens de programação. Tanto no CORBA como no DCOM isto é obtido através do uso de interfaces e linguagens de definição de interfaces (IDL), que serão melhor detalhadas adiante INTERFACE DE OBJETO Ambos, CORBA e DCOM, definem objetos da maneira convencional, isto é, uma coleção de métodos e dados. Os dois permitem acessar objetos através de interfaces específicas definidas por IDL, onde as particularidades das IDLs do CORBA e DCOM são descritas adiante. No DCOM, cada objeto apresenta duas ou mais interfaces a seu cliente que, comumente, possui múltiplos ponteiros de interfaces para o mesmo objeto COM (Betz, 1994) (Chappell, 1997) (Chung et al, 1998) (Grimes, 1997). Todos os objetos no DCOM suportam uma interface fundamental chamada lunknown. Esta interface suporta três métodos que provêem funcionalidades básicas para todos os objetos COM. Estes métodos são: QueryInterface que 157

6 permite ao cliente perguntar quais interfaces o objeto suporta; AddRef e Release que gerenciam o contador de referências para o objeto. O contador de referência para o objeto é um mecanismo que possibilita ao sistema rastrear quantos clientes possuem um ponteiro para uma ou mais interfaces do objeto. Quando este contador de referência alcançar zero, o sistema pode destruir o objeto. Adicionar funcionalidades em uma versão de um objeto COM é tornar disponível esta funcionalidade através de uma nova interface do objeto. As Interfaces existentes não devem ser alteradas para que seus antigos clientes não sejam afetados. Desta forma, eles nunca irão adquirir ponteiros para as novas interfaces. Apenas os novos clientes conhecerão as interfaces recémcriadas, ou seja, somente eles serão afetados pelas versões atualizadas de um objeto COM (Microsoft, 1998b). Por exemplo, suponha que exista um conjunto de ferramentas matemáticas implementado como um objeto COM suportando uma interface ICalculoTrigonometrico. Para acessar o serviço de cálculo trigonométrico, oferecido pelo objeto, uma determinada aplicação obtém, através do método QueryInterface da interface IUnknown, o ponteiro da interface ICalculoTrigonometrico. Como o objeto suporta essa interface ele retorna um ponteiro válido, caso contrário retornaria um ponteiro igual a NULL. Agora assuma que esse objeto, numa nova versão, suporta além do cálculo trigonométrico (interface ICalculoTrigonometrico) o cálculo logarítmico, onde a adição de uma nova funcionalidade implica na criação de um nova interface, no caso, ICalcLogaritmico. A aplicação que precisa do ponteiro da interface ICalculoTrigonometrico continua obtendo da forma como sempre fez e como desconhece a nova interface ICalcLogaritmico ela não irá buscar esse ponteiro. Agora, se uma nova aplicação utilizar, além de cálculos trigonométricos, cálculos logarítmicos ela poderá obter, através do método QueryInterface, o ponteiro de ambas as interfaces. Assim, atualizações no conjunto de 158

7 ferramentas matemáticas não implicam em atualizações nas aplicações que o utiliza. Essa forma de versionamento é dependente do método QueryInterface da interface IUnknown e da imutabilidade das interfaces suportadas por um objeto. Deve-se notar que não existe no COM nenhuma proteção que garanta esta imutabilidade. Esta é uma regra que deve ser obedecida pelos desenvolvedores. No CORBA, cada objeto apresenta uma única interface a seu cliente, o qual possui uma referência para o objeto como um todo. Clientes comunicam-se com objetos CORBA via ORB. No ORB, a interface do objeto é definida somente uma vez, assim ele não tem a necessidade da definição de uma interface diferente para cada tipo de interação possível com esse objeto. Cada objeto utiliza-se de um Adaptador de Objeto para conectar-se ao ORB. A maioria dos Adaptadores de Objeto são projetados para cobrir uma faixa larga de implementações, objetivando restringir o projeto de um novo adaptador somente quando uma implementação requeira um serviço ou uma interface muito diferente (Queiroz e Madeira, 1998) (Mowbray e Ruh, 1997). Para satisfazer diferentes tipos de requisições de clientes, um servidor de objeto pode utilizar, para conectar-se a um ORB, vários tipos de Adaptadores de Objetos. A OMG, para restringir os tipos de adaptadores, especificou o Adaptador de Objeto Básico ( Basic Object Adapter BOA) (Orfali et al, 1996). A implementação do BOA deve prover as seguintes funcionalidades básicas: gerar e interpretar referências de objetos, invocar métodos, garantir segurança, ativar e desativar objetos, mapear as referências dos objetos às suas correspondentes implementações e registrar implementações. 159

8 Para cobrir uma faixa larga de tipos de aplicações, o CORBA definiu quatro políticas de ativação de objetos que devem ser suportadas pelo BOA, sendo elas (Orfali et al, 1996): Servidor compartilhado: quando num servidor múltiplos objetos residem num mesmo processo (programa) o BOA ativa o servidor no primeiro pedido de requisição feito a qualquer um dos objetos nele implementado. O BOA só ativará outro servidor após o término do atendimento de todas as requisiçôes feitas ao servidor ativado anteriormente. Servidor não compartilhado: quando num servidor cada objeto reside em um processo diferente o BOA ativa o servidor no primeiro pedido de requisição feito ao objeto nele implementado. Caso uma requisição seja enviada a outro servidor o BOA o ativará mesmo que o anterior ainda esteja ativo. Servidor por método: o BOA ativa o servidor a cada pedido de requisição feito ao objeto nele implementado. O servidor executa somente durante o período necessário ao atendimento da requisição (tempo para execução do método). Servidor persistente: os servidores são ativados externamente ao BOA. O BOA envia o pedido de requisição a um scheduler que ativa o servidor correspondente. Após a ativação do servidor o BOA só ativará outro servidor após o término do atendimento de todas as requisiçôes feitas ao servidor ativado anteriormente. Em relação ao tratamente de versões de objetos CORBA encontra-se em estudo um Request for Proposal (RFP) para o desenvolvimento de um serviço de gerenciamento de alterações ( Change Management Service ). Esse serviço suportará a identificação e evolução dos objetos incluindo gerenciamento de configuração e versão (CORBAservices, 1998). 160

9 Novas funcionalidades no DCOM implicam em novas interfaces e no CORBA em um novo adaptador de objeto, assim, no DCOM o número de interfaces entre N objetos pode representar um problema de ordem (NxN) enquanto no CORBA, devido ao ORB, somente N interfaces são necessárias entre N objetos, como mostrado na Figura 6.1 (Queiroz e Madeira, 1998) (Mowbray e Ruh, 1997). A B A B C F C ORB - CORBA E D D E F Ordem (N x N) interfaces Ordem N interfaces Fig. 6.1 Número de interfaces necessárias para integração entre objetos FONTE: Mowbray e Ruh (1997, p.15) IDL Ambos, CORBA e DCOM, provêem IDL, mas elas apresentam diferenças fundamentais entre si. A IDL é considerada, na arquitetura CORBA, um item fundamental utilizado para definição das interfaces, e possui uma notação universalmente aplicável em APIs. A Figura 6.2 mostra o mapeamento entre a IDL CORBA e as linguagens de programação utilizadas para implementar objetos. Por mapeamento entenda-se a forma que possibilita aos desenvolvedores 161

10 acessar as funcionalidades do ORB utilizando a linguagem de programação escolhida para implementar os objetos (CORBA, 1998). Esse mapeamento cria uma definição abstrata adequada a cada linguagem de programação, isto é, cria uma estrutura que define como expressar os tipos de dados, as referências às constantes e objetos, as invocação de métodos (passagem de parâmetros, recebimento de resultados), os tratamentos de exceções e etc. da IDL na linguagem de programação utilizada para implementar o objeto. Este mapeamento é de responsabilidade do fornecedor do ORB (Mowbray e Ruh, 1997). A IDL CORBA possui declarações de tipo sintaticamente semelhantes a um subconjunto da linguagem C++. Ela não possui ponteiros, mas suporta tipos definidos e construídos pelo usuário. Possui exceções ( exception ) e o any pode representar qualquer tipo de dado válido para o IDL, por exemplo, inteiro, caracter, vetor, etc. A IDL CORBA possui uma descrição formal Backus-Naur Form (BNF) para várias linguagens de programação, tais como, Java, C, C++, Smalltalk, Cobol e Ada95. As interfaces para os serviços CORBA ( CORBAservices ) e facilidades CORBA ( CORBAfacilities ) são definidos em IDL (Nybroe e Bajers, 1998) (Mowbray e Ruh, 1997) (Otte et al, 1996) (Tallman e Bradford, 1998). 162

11 Definições IDL Mapeamento em C - Cabeçalho do cliente - Stub - Cabeçalho de implementação - Skeleton Compiladores IDL Mapeamento em C++ - Cabeçalho do cliente - Stub - Cabeçalho de implementação - Skeleton Mapeamento Smalltalk - Template de implementação Repositório de Interfaces Outros mapeamentos - Cobol - Ada83, Ada95 - Common Lisp - Outros Fig. 6.2 Mapeamento do IDL CORBA FONTE: Mowbray e Ruh (1997, p.73) No DCOM, qualquer linguagem de programação que possa criar estruturas de ponteiros e chamadas de funções implícitas ou explícitas, através desses ponteiros, pode ser utilizada para criar objetos COM e suas respectivas interfaces. Uma das maneiras de definir interfaces no DCOM é a utilização da ferramenta Microsoft Interface Definition Language (MIDL). O MIDL é uma extensão do DCE RPC IDL, que é baseado em C. Ela suporta todos os tipos de dados C, incluindo ponteiros e estruturas de dados baseados em ponteiros. O MIDL não define um conjunto comum de tipos de dados acessíveis a todas as linguagens de programação, isto é, nâo provê nenhuma 163

12 forma de mapeamento de linguagens de programação. Podem-se definir interfaces e tipos de dados em MIDL para C, C++ e Java, encontrando-se em desenvolvimento para Visual Basic e Ada (Grimes, 1997) (Tallman e Bradford, 1998) HERANÇA DE INTERFACE Em relação a objetos distribuídos se pode distinguir duas formas de herança, a saber: herança de implementação e herança de interface. Na herança de implementação, o objeto herda código de seu pai, isto é, quando um cliente de um objeto filho chama um dos métodos herdados por este objeto filho, o código realmente executado é o do objeto pai. Na herança de interface, o filho herda somente a definição dos métodos do pai, assim, quando o cliente de um objeto filho chama um destes métodos é o próprio filho que deve prover o código para lidar com a requisição do cliente. Herança de implementação é um mecanismo para reuso de código, enquanto a herança de interface é um mecanismo para reuso de especificação (é a definição dos métodos que o objeto suporta). A herança de interface permite definir uma nova interface herdada de uma já existente, garantindo, assim, que um objeto que suporta a nova interface possa ser tratado como um objeto que suporta a interface anterior (pai). Objetos COM suportam somente herança simples de interface. Não suportam herança de implementação mas, através de mecanismos de contenção e agregação, descritos no Capítulo 4, é possível obter o reuso de código. CORBA permite herança múltipla de interface. No CORBA um objeto possui somente uma interface, mas pode suportar múltiplas interfaces através do mecanismo de herança de interface. 164

13 A Figura 6.3 mostra a herança de interface utilizada pelo CORBA e DCOM. A B C IU IU D A A IU IU IU E F B C D E F Herança de Interface CORBA Herança de Interface DCOM Fig. 6.3 Herança de interface CORBA e DCOM FONTE: CORBA (1998, p.16.27) REPOSITÓRIO DE INTERFACES Tanto o CORBA com o DCOM suportam invocação de métodos de objetos de forma estática e dinâmica. Invocação estática é aquela que, para atender uma requisição, apresenta as definições exatas em tempo de compilação. Quando isso não acontece, deve haver uma maneira que permita descobrir, em tempo de execução, as definições necessárias para atender a requisição, e a este processo dá-se o nome de invocação dinâmica. Para atender a invocação dinâmica, CORBA define um repositório de interfaces ( Interface Repository ) que armazena definições de tipos de dados, informações de interface definidas em IDL, incluindo stubs, skeletons, rotinas para browse de interfaces e informações para depuração. A implementação fica a cargo do fornecedor do produto que implementa o ORB. 165

14 Os programas utilizam o repositório de interfaces, através da invocação dinâmica de interface ( Dynamic Invocation Interface DII), para procurar as interfaces que não foram encontradas em tempo de compilação (Chung et al, 1998) (Mowbray e Ruh, 1997) (Tallman e Bradford, 1998). No DCOM a invocação dinâmica torna-se disponível através da utilização da interface IDispatch e seus respectivos métodos Invoke, GetIDsOfNames, GetTypeInfo e GetTypeInfoCount já descritos anteriormente. Um objeto cujos métodos são dinamicamente invocados deve possuir entre suas interfaces a interface IDispatch. Esta interface consulta a biblioteca Type Library que descreve o objeto e provê dinamicamente suas interfaces e respectivos métodos. Esta biblioteca é acessada através da interface ITypeLib e as definições dos dados nela contidas sâo obtidas pela interface ITypeInfo (Grimes, 1997). Como os clientes não possuem instruções de compilação para invocar métodos de interfaces desconhecidas eles devem recorrer ao uso de interfaces de invocação dinâmica quando necessitarem invocar objetos cujas interfaces devam ser descobertas em tempo de execução. Depuradores ( debbugers ) são exemplos de aplicações que necessitam de invocação dinâmica, pois podem ser invocados, para depurar novos programas, por alguma operação descoberta em tempo de execução. No CORBA, usa-se o DII e no DCOM a interface IDispatch, que são maneiras diferentes de implementar a mesma funcionalidade CICLO DE VIDA DO OBJETO No DCOM, um cliente cria um objeto utilizando-se das funções da biblioteca COM. Além de outros parâmetros, especifica o identificador da classe (CLSID) do objeto que ele quer utilizar. Com isto o cliente obtém seu primeiro ponteiro 166

15 de interface para o novo objeto, como parte do processo de criação, e dele obterá qualquer outro ponteiro de que necessite, bastando perguntar, diretamente, ao objeto através do método QueryInterface da interface IUnknown. Quando o cliente terminar de fazer uso do ponteiro de interface obtido, ele passará esta informação ao objeto, através o método Release da interface IUnknown. Quando o cliente liberar todos os ponteiros de todas as interfaces do objeto, o objeto usualmente se destruirá (Chappell, 1997) (Chung et al, 1998) (Frankel e Guttman, 1998). Se for necessária a criação de vários objetos da mesma classe, o cliente poderá adquirir o ponteiro para a class factory da classe que possui esta função. A class factory, além de prover uma ligação entre o cliente e o objeto, permite que a aplicação do cliente mantenha o objeto na memória, mesmo não existindo contador de referência para qualquer interface do objeto. Sem esta facilidade, o objeto seria destruído assim que o contador de referência fosse zerado. Esta facilidade possibilita ao cliente decidir, por exemplo, manter o objeto na memória, uma vez que esteja motivado por razões de desempenho (Grimes, 1997). No CORBA, um objeto é criado tipicamente por um chamado ao ORB, utilizando para este fim o serviço de ciclo de vida. Este chamado gera uma referência de objeto única (um identificador de objeto) para o objeto recémcriado, sendo utilizada para rastrear o objeto durante todo o seu ciclo de vida. Essa referência de objeto é utilizada pelo serviço de nomeação para localizar o objeto, pelo serviço de persistência para armazenar o estado do objeto e é ela que permite ao cliente invocar seus métodos. A forma de implementação da referência de objeto não é definida pelo CORBA (Orfali et al, 1996). Quando um cliente invoca um método de um objeto ativo, isto é, de um objeto que possui seu dado e o código na memória, o ORB passa a ele a requisição recebida do cliente. Se o objeto alvo não estiver ativo, o ORB carrega os dados 167

16 e o código do objeto na memória e entrega a ele a requisição do cliente. Clientes não precisam informar ao objeto quando eles terminam de usá-lo e não é definido pelo padrão CORBA quando um objeto pára de executar. Produtos diferentes apresentam várias maneiras de tratar a destruição do objeto. No CORBA, diferentemente do DCOM, fazer com que um objeto deixe de ser ativo não é a mesma coisa que destruí-lo. CORBA requer que o cliente, explicitamente, diga ao ORB que um objeto deve ser destruído e, até que isto seja feito, o ORB é capaz de iniciar e parar o objeto quando necessário para atender uma requisição do cliente (Chappell, 1997) (Chung et al, 1998) (Frankel e Guttman, 1998). A Figura 6.4 mostra o ciclo de vida de um objeto CORBA. Objeto executando Objeto criado 3 Objeto destruído Objeto ativo Objeto desativado Fig. 6.4 Ciclo de vida de um objeto CORBA FONTE: Otte et al (1996, p.9-3) DCOM não tem o conceito de referência de objeto, mas através do mecanismo de persistência de nomeação ( moniker ) provê uma referência única aos métodos e dados de uma instância particular do objeto. Monikers encapsulam esquemas de implementação específicos baseados em nomes que passam a possuir a localização do objeto. 168

17 6.1.8 PROTOCOLO Tanto o CORBA como o DCOM provêem um protocolo para suportar a execução do cliente e objeto servidor em diferentes máquinas. CORBA não especifica um protocolo de comunicação interno entre o cliente e um objeto servidor executando num ORB, isto fica determinado pelo fornecedor. Entretanto, é especificado o protocolo General Inter-ORB Protocol (GIOP) de maneira a garantir a interoperabilidade entre diferentes implementações de ORBs. Quando a troca de mensagens é via conecções TCP/IP, utiliza-se o protocolo Internet Inter-ORB Protocol (IIOP). O IIOP especifica um novo padrão para formatação de mensagens conhecido como Common Data Representation (CDR). A principal vantagem deste protocolo é o baixo custo de tempo de execução obtido pelas seguintes características (Watson et al, 1998): ordenamento variável de bytes: não há necessidade de fazer troca de bytes quando o marshaling for em máquinas de mesmo endianess. Marshaling é o processo de empacotar, num formato padrão para transmissão, tanto os parâmetros de chamada de um método (no espaço de endereçamento do cliente) como o retorno do valor da execução deste método (obtido no espaço de endereçamento do objeto). tipos de primitivas alinhadas: permite tratamento eficiente de dados através do alinhamento de dados na memória. No CORBA, existe, também, o protocolo DCE Common InterORB (DCE- CIOP) que utiliza o formato de comunicação definido pelo DCE-RPC, com uma diferença, ao invés de representar os dados como, no DCE-RPC, utilizando o Network Data Representation (NDR) ele substitui esta representação pelo 169

18 Common Data Representation (CDR). O NDR oferece mais funcionalidades em relação ao CDR, mas carece de características relacionadas à minimização de custo de tempo de execução (Nybroe e Bajers, 1998). DCOM tem seu protocolo baseado nas especificações OSF DCE RPC (DCE, 1998) com poucas modificações. O protocolo DCOM estendeu o NDR definindo um novo tipo primitivo de dado que pode ser marshaled. Este tipo é a referência de interface para o objeto descrito como OBJREF que relaciona, de forma única, o objeto à sua interface (Brown e Kindel, 1998). Foi necessária esta extensão porque o RPC é apropriado para aplicações nas quais o cliente faz uma requisição e espera pela resposta antes de continuar seu processamento, assim, não é indicado para aplicações envolvendo objetos distribuídos ou programação orientada a objeto (Vondrak, 1998). DCOM incluiu também, nas suas especificações, um protocolo chamado de pinging que permite a execução de um garbage collect de objetos remotos. Pinging é o mecanismo pelo qual um processo envia um pequeno pacote de dados ( ping ) para outro processo indicando que ele está vivo e o processo receptor responde ao ping mostrando que ele também está vivo ( pong ). O ping é continuamente repetido num intervalo de tempo pré-determinado. A perda de um número pré-determinado de pings indica que o cliente terminou de forma anormal e o ponteiro para interface que o contém deve ser liberado (Grimes,1997). Apesar do ping enviar um pequeno pacote de dados, ele pode ser desligado para reduzir o tráfego na rede (Chung et al, 1998) ERROS E EXCEÇÕES CORBA garante que uma invocação feita por um cliente receba sempre um retorno indicando sucesso ou uma exceção. Isto simplifica, significamente, as complexidades da computação distribuída, pois pode reduzir a quantidade de código no lado cliente. Exceções representam também uma parte importante 170

19 das especificações de uma interface. Exceções definem os valores passados pela interface no caso de acontecer um erro. Os valores de exceções são declarados similarmente a tipos de estruturas na IDL. CORBA especifica uma extensa lista de exceções que se mapeiam naturalmente tanto em linguagens de programação que possuem tratamento de exceção nativo, como C++ e Java, como nas que não o possuem. Existem dois tipos de exceção: as definidas pelo padrão CORBA, estabelecidas no ORB ou na implementação do objeto, e as definidas pelo usuário estabelecidas na implementação do objeto (Chung et al, 1998) (Mowbray e Ruh, 1997) (Otte et al,1996). Para tratamento de exceções o DCOM estabelece padrões para valores de status e erros baseados no sistema de códigos de erros do Win32. Ele possui um tratamento padrão de erros através do retorno de um valor de 32 bits chamado HRESULT. O código de status possui 32 bits dos quais 16 bits são de status, 15 bits de facilidade ( facility ) e 1 bit indicador de sucesso. O bit mais significativo é o indicador de sucesso, ele determina se o código de status representa sucesso ou falha. Esse é o bit utilizado para teste pelas macros SUCCEED( ) e FAILED( ). Os 15 bits de facilidade descrevem onde o erro foi gerado; a combinação destes bits produzem um código de facilidade que pode ser definido pelo usuário ou provido pelo DCOM. Os 16 bits menos significativos são indicativos de status e especificam o erro ocorrido (Chung et al, 1998) (Grimes, 1997) (Mowbray e Ruh, 1997) PERSISTÊNCIA Ambos, DCOM e CORBA, utilizam-se de um armazenamento persistente para salvar o estado de um objeto que poderá vir a ser utilizado numa reativação futura. 171

20 No CORBA, o mecanismo de persistência é completamente transparente ao cliente que não possui meios de determinar onde e como o objeto foi armazenado. O cliente só obtém essa informação, caso exista um outro objeto responsável por conhecer os detalhes de armazenamento do objeto utilizado por ele. A implementação do mecanismo de persistência é de responsabilidade exclusiva do serviço de gerenciamento de persistência do ORB, tornando a ligação com o cliente restrita ao que foi definido nas interfaces do objeto (Otte et al, 1996) (Mowbray e Ruh, 1997) (Tallman e Bradford, 1998). No DCOM, o modelo de persistência requer que os objetos implementem uma interface que suporte persistência. Para essa finalidade, utiliza-se um ou vários meios de armazenamento como arquivos, streams, etc. Para reativar um objeto, o cliente indica, explicitamente, onde o estado do objeto está armazenado (tipicamente um arquivo) e requisita sua ativação. Isto é usualmente feito através de um file moniker. Todos os monikers são gerenciados pelo cliente SERVIÇOS Serviços permitem a interação, através da rede, de múltiplos processos executando em uma ou mais máquinas. DCOM e CORBA utilizam diferentes esquemas de serviços, dificultando, desta forma, algum tipo de comparação. A abordagem da Microsoft para desenvolver aplicativos distribuídos é chamada de Windows Distributed internet Applications (DNA). O Windows DNA não é um produto mas uma estratégia para escrever aplicativos utilizando as tecnologias e os produtos da Microsoft. O objetivo é fornecer, à plataforma (Windows), a tecnologia de componentes (COM/DCOM), a infraestrutura, os serviços de interoperabilidade e as ferramentas que os desenvolvedores necessitam para escrever aplicativos cliente/servidor de três camadas (Kirtland, 1999). 172

21 O coração do Windows DNA é o COM/DCOM e os padrões da Internet. Os serviços do Windows DNA obedecem a protocolos abertos como o Hypertext Transfer Protocol (HTTP) e Lightweight Directory Access Protocol (LDAP) permitindo assim interoperabilidade com outros sistemas. Ele suporta também vários protocolos de rede como o TCP/IP, o UDP/IP e o Internet Tunneling TCP/IP. O Windows DNA oferece um ambiente para desenvolvimento de aplicativos distribuídos integrado aos serviços do sistema operacional Windows e do COM. Esta integração provê uma flexibilidade crescente e um ambiente robusto para o desenvolvimento e execução de objetos. Mas, com isso, a portabilidade fica prejudicada, pois não se sabe exatamente quais, quando e como estes serviços estarão disponíveis em outras plataformas. A Figura 6.5 mostra a arquitetura Windwos DNA. Apresentação Cliente Rede Lógica da Aplicação Servidor Rede Dados Banco de Dados Fig. 6.5 Windows DNA FONTE: Adaptada de Microsoft (2000a, p.01) 173

22 Como mostrado na Figura 6.5, o DNA é composto de três camadas: camada de apresentação, camada da lógica da aplicação ( camada de negócio ) e camada de acesso aos dados. Estas camadas são descritas a seguir (Kirtland, 1999): Camada de Apresentação: Nesta camada o DNA suporta, isto é, existem produtos Microsoft que suportam vários tipos de interface da aplicação cliente com os usuários como o HTML, o Dynamic HTML (DHTML) e os aplicativos nativos Win32. Para clientes baseados em WEB existe o Internet Explorer suportando HTML, DHTML, applets Java, etc. Camada da Lógica da Aplicação: Para ajudar os desenvolvedores a escrever a lógica de negócio o DNA propõe um conjunto de serviços que integrados formam um middleware. Estes serviços, que fazem parte do pacote Windows NT Server incluem: 1. Serviços WEB oferecidos pelo Microsoft Internet Information Server - IIS. O IIS provê a tecnologia Active Server Page - ASP que ajuda os desenvolvedores a criar aplicativos Internet. 2. Serviços de Transação oferecidos pelo Microsoft Transaction Server MTS, descrito a seguir: O MTS provê uma infraestrutura padrão de serviços capaz de suportar aplicações distribuídas. Suas principais características são (Kirtland, 1999): Sincronizar o acesso de múltiplos clientes invocando um mesmo objeto de forma que nenhuma alteração seja perdida e que todos os clientes obtenham os resultados esperados. 174

23 Coordenar o acesso aos dados persistentes de modo que nenhuma alteração seja perdida e que os clientes não obtenham dados parcialmente atualizados. Assegurar que o acesso aos dados seja feito de forma segura, determinando quem pode ou não acessá-los. Gerenciar o compartilhamento dos recursos pelos clientes (processos, memória, conexões de banco de dados, etc). Fornecer ferramentas administrativas para ajudar a instalação/distribuição e a manutenção das aplicações. O MTS é a extensão do COM, mas a partir do Windows NT 5.0 COM e MTS se fundirão para formar o COM+ (Kirtland, 1999). O COM+ eliminará a distinção entre COM e MTS. Essa distinção surgiu porque o MTS foi implementado como um serviço executando por cima do COM, ao invés de ser parte integrante dele. 3. Serviços de comunicação assíncrona oferecidos pelo Microsoft Message Queue Server MSMQ, descrito a seguir: O MSMQ provê serviços assíncronos para aplicativos distribuídos, por exemplo, através dele uma aplicação pode enviar mensagens para outra aplicação sem a necessidade de esperar pela resposta. Estas mensagens são enviadas e armazenadas numa fila até que a aplicação receptora as remova. O MSMQ é um produto enfilerador de mensagens, fornecendo um infraestrutura para gerenciar filas e rotear mensagens entre filas localizadas em máquinas diferentes. Camada de Acesso aos Dados: A abordagem do Windows DNA para acessar dados é chamada de Universal Data Access (UDA). O UDA é uma estrutura baseada em COM projetada para fornecer acesso de alto desempenho para qualquer tipo de dado (estruturado, não estruturado, 175

24 relacional e não relacional armazenado em qualquer banco de dado) (Microsoft, 2000b). O CORBA provê serviços bem projetados e aderentes de forma consistente ao seu modelo (CORBAservices, 1998). São eles: serviço de ciclo de vida, serviço de nomeação, serviço de notificação de evento, serviço de persistência de objeto, serviço de transação, serviço de controle de concorrência, serviço de relacionamento, serviço de externalização, serviço de pedido de informação, serviço de licença, serviço de propriedade, serviço de temporização, serviço de segurança, serviço de negócios, serviço de coleção de objetos e serviço de inicialização de objetos. O problema é que nem todos os serviços já se encontram implementados pelos fornecedores de produtos baseados nas especificações CORBA, assim como, não existe um esquema de verificação de conformidade das implementações com as especificações (Queiroz e Madeira, 1998). Alguns produtos aliam à implementação das especificações CORBA características próprias que se utilizadas por um usuário poderá dificultar a interoperabilidade com outros produtos. Como ilustração, a seguir são descritas brevemente três famílias de produtos baseados nas especificações CORBA. Estes produtos oferecem o ORB ( middleware ), alguns serviços implementados respeitando as especificações CORBA, outros serviços específicos do produto e ferramentas para o desenvolvimento e distribuição ( deploy ) de uma aplicação CORBA. Visibroker 4.0 fornecido pela Inprise (Inprise, 2000). Algumas de suas características são: Suporta as especificações CORBA 2.3. Suporta as linguagens de programação Java e C++. Suporta a comunicação entre ORBs através do protocolo General Inter- ORB Protocol (GIOP). 176

25 Suporta a comunicação entre ORBs via Internet através do protocolo Internet Inter-ORB Protocol (IIOP). Suporta interfaces Remote Method Invocation (Java / RMI). RMI será discutido no próximo capítulo. Suporta serviço de nomeação e incorporado a este serviço existe o balanceamento de carga e tratamento de falhas. Suporta serviço de eventos. Suporta, opcionalmente, alguns serviços que não são oferecidos pela Inprise mas sim pela Prism Technologies (Prism Technologies, 2000), sendo eles: serviço de negócios, serviço de ciclo de vida, serviço de propriedade, serviço de coleção, serviço de concorrência, serviço de relacionamento e serviço de tempo. Suporta APIs de qualidade de serviço ( Quality of Service QoS) que permitem ao desenvolvedor customizar algumas das funções do ORB, isto é, configurar ou modificar o comportamento do ORB visando otimizar o desempenho da rede. Plataformas disponíveis: Microsoft Windows, Sun Solaris, Redhat Linux, HP-UX, IBM AIX, IBM OS/390 Mainframe. Orbix 3.0 fornecido pela IONA (Iona Technologies, 2000). Algumas de suas características são: Suporta as especificações CORBA 2.3. Suporta as linguagens de programação Java e C++. Suporta a comunicação entre ORBs via Internet através do protocolo Internet Inter-ORB Protocol (IIOP). Suporta serviço de nomeação e incorporado a este serviço existe o balanceamento de carga e tratamento de falhas. Suporta serviço de eventos. Suporta serviço de segurança. Suporta serviço de negócio. Suporta serviços de transação. 177

26 Suporta integração entre objetos CORBA e objetos COM, isto é, aplicações COM acessam objetos CORBA e vice-versa. Plataformas disponíveis: Windows NT 4.0, Solaris 2.6, Solaris 7.0, HP- UX 10.20, HP-UX 11, AIX 4.3.2, Tru 64 UNIX 4.0E (Digital UNIX), IRIX 6.5. Compaq NonStop fornecido pela Compaq (Compaq, 2000). Algumas de suas características são: Suporta as especificações CORBA 2.3. Suporta as linguagens de programação Java e C++. Suporta a comunicação entre ORBs via Internet através do protocolo Internet Inter-ORB Protocol (IIOP). Suporta serviço de nomeação, incorporado a este serviço existe o balanceamento de carga e tratamento de falhas. Suporta serviço de eventos. Suporta serviço de transação. Suporta mecanismos de acesso ( object wrappers ) para aplicações legadas não orientadas a objeto SEGURANÇA Aplicações distribuídas devem ser seguras. A segurança é obtida através da criptografia dos dados, garantindo a confidencialidade ou autenticação dos objetos que estão se comunicando, permitindo assim, a possibilidade de confirmar se um comando está sendo enviado realmente pelo objeto responsável por esta tarefa. O DCOM utiliza o conceito de segurança de ativação ( Activation Security ) e de chamada segura ( Call Security ), descritos no Capítulo 4, implementados pelo Security Server do pacote Windows NT Server disponível no sistema operacional Windows NT (SecurityServer, 2000). 178

27 O CORBA especifica serviços de segurança que provêem confidencialidade e autenticação (CORBAsecurity, 1998). 6.2 CLASSIFICAÇÃO Até aqui a comparação entre CORBA e DCOM baseou-se nos seus modelos de objeto, protocolos de comunicação, funcionalidades e abrangência, mas ambos podem também ser avaliados em relação a alguns critérios de qualidade de software. Através de pesquisa se verificou que os critérios de qualidade de software apropriados para avaliar tanto o CORBA quanto o DCOM são: escalabilidade, interoperabilidade, manutenabilidade, portabilidade e reusabilidade. Na avaliação destes critérios de qualidade de software, descritos a seguir, são levados em consideração somente alguns aspectos: Escalabilidade, entendendo-se como a facilidade com que um sistema ou componente pode ser modificado para ajustar-se a solução de problemas de uma determinada área (Sadoski, 1998). CORBA suporta o conceito de objeto de negócio. Objetos de negócios representam coisas que independem de aplicações, como por exemplo, clientes, pedidos, competidores, pacientes, etc. São objetos reconhecidos por usuários finais de um sistema. Eles são capazes mudar seus atributos de acordo com eventos do ambiente em que estão sendo utilizados, assim como, interagem com outros objetos de negócios para realizar uma tarefa. Como qualquer outro objeto CORBA ele expõe sua interface aos clientes via IDL e comunica-se com outros objetos através do ORB (Orfali et al, 1996). DCOM não implementa este conceito. Um objeto representa uma entidade que só faz sentido para um determinado sistema de informação e seu programador, não transcende, não é reconhecido por um usuário final de um sistema. 179

28 Interoperabilidade, entendendo-se como a habilidade que permite a, dois ou mais, sistemas ou componentes trocar informações de forma que elas possam ser utilizadas por eles (IEEE, 1990). CORBA suporta interoperabilidade através da utilizaçao dos protocolos GIOP e IIOP. DCOM suporta interoperabilidade através da utilizaçao do protocolo ORPC. Manutenabilidade, entendendo-se como a facilidade com que um sistema ou componente pode ser modificado para permitir correção de falhas, melhora de desempenho ou outros atributos, assim como, adaptar-se a mudanças de ambiente (IEEE, 1990). No CORBA e DCOM a utilização da interface separando a implementação do objeto do cliente que o utiliza permite que alterações no objeto sejam transparentes ao cliente. Portabilidade, entendendo-se com a facilidade com que um sistema ou componente pode ser transferido de um ambiente de hardware ou software a outro (IEEE, 1990). No CORBA a portabilidade é obtida através da utilização do ORB que se adapta ao sistema operacional e apartir daí toda a comunicação cliente/servidor é realizada através dele. DCOM, até o momento, é baseado no sistema operacional Microsoft Windows. Reusabilidade, entendendo-se como o grau com que um módulo de software pode ser utilizado em mais de um programa ou sistema de software (IEEE, 1990). No CORBA e DCOM a reusabilidade é possível devido a utilização do conceito de objeto distribuído, isto é, uma unidade independente de software que pode ser conectada e utilizada por aplicações em rede, independentemente de linguagens de programação e sistemas operacionais. 180

29 6.3 INTEROPERABILIDADE CORBA/DCOM Durante o desenvolvimento de uma aplicação distribuída pode haver a necessidade de integrar os ambiente CORBA e DCOM, por exemplo, um cliente, trabalhando no ambiente CORBA, necessita enxergar um objeto DCOM como um objeto CORBA e vice-versa. Apesar das similaridades cada um tem uma maneira diferente de descrever, utilizar e organizar os seus objetos. Para que a integração seja possivel é necessário que haja um gateway permitindo a objetos CORBA e DCOM comunicarem-se de forma transparente uns com os outros, como mostrado na Figura 6.6. Cliente DCOM Proxy do objeto DCOM Cliente CORBA Objeto CORBA Interface MIDL Interface IDL Gateway Fig. 6.6 Esquema geral de um gateway entre CORBA e DCOM FONTE: Kotopoulis e Miller (1997, p.69) Gateways provêem conversão de mensagens entre os objetos CORBA e DCOM permitindo assim a comunicação entre eles. Projetar e construir um gateway não é uma tarefa fácil. Ele deve suportar as seguintes funcionalidades (Kotopoulis e Miller, 1997): Transparência de chamada: um objeto chamador de um determinado tipo não sabe que está se comunicando com um objeto de outro tipo. 181

30 Transparência do cliente e servidor em relação ao gateway : tanto o código do cliente quanto o do servidor não devem conter nenhuma referência ou comandos de controle do gateway. Transparência do gateway em relação ao cliente e servidor: o código do gateway não deve conter qualquer informação sobre os clientes e servidores a ele conectados. Manuseio de interfaces de forma dinâmica: o acesso dinâmico para objetos, sem conhecimento prévio de suas interfaces, deve permitir manusear, eficientemente, aplicações tais como browsers. Cobertura de interface: o suporte para todas as funcionalidades da interface de comunicação deve assegurar a compatibilidade entre plataformas. Escalabilidade e desempenho do gateway : a invocação de objetos através do gateway deve ser equivalente a uma invocação direta e não pode haver diferença no número e tamanho dos objetos acessíveis pelo objeto original. A OMG, no Capítulo 15 ( Interworking Architecture ) da especificação The Common Objet Request Broker: Architecture and Specification (CORBA, 1998) especifica como obter a comunicação transparente entre objetos CORBA e COM. 6.4 CONSIDERAÇÕES FINAIS A seguir, na Tabela 6.1, serão apresentadas, resumidamente, as similaridades e diferenças entre o CORBA e o DCOM. 182

31 TABELA 6.1 SIMILARIDADES E DIFERENÇAS ENTRE CORBA E DCOM Padronização Disponibilidade de fornecedores de produtos DCOM Formal, gerenciado por Active Group e Open Group. Microsoft. Maturidade Windows NT lançado em 1996, mas produtos baseados em COM desde 1986, maioria de serviços e facilidades em construção. Plataformas Windows NT, suporte futuro para Windows em todas as versões, Macintosh, UNIX (vários) e MVS. Ferramentas (compiladores, depuradores, bibliotecas de Sim. classes, etc) Linguagens suportadas C, C++, Java, Visual Basic e Ada. Foco de aplicações Primeiro em estações de trabalho e segundo em empreendimentos ( enterprise ). (continua) CORBA Formal, gerenciado pelo Object Management Group. Vários, como ORBIX da IONA Technology, NEO da SunSoft, VisiBroker da Visi-Genic, PowerBroker da Expersoft, SmallTalkBroker da DNS Technologies, Object Director da Fujitsu, DSOM da IBM, DAIS da ICL, SORBET da Siemens Nixdorf e NonStop DOM da Tandem. Produtos existentes desde 1992 e vários serviços e facilidades em construção. MVS, UNIX (vários), Windows (todas as versões), Macintosh. Sim. C, C++, Smaltalk, Ada95, Java e COBOL. Primeiro em empreendimentos ( enterprise ) e segundo em estações de trabalho. 183

32 TABELA 6.1 Continuação Serviços Windows NT Server (serviços de filas e impressão, serviços Web, serviços aplicativos, serviços de gerenciamento, serviços de segurança, serviços de comunicação, serviços de mídia). Vários serviços incluindo filas, negócios, transações, assim como facilidades nas áreas de gerenciamento de informações e sistemas de gerenciamento. Atualmente serviços nas áreas de finança, simulação distribuída e computer integrated manufacturing. Segurança Segurança de ativação ( Activation Security ) e Serviço de segurança ( CORBA Security ). Chamada segura ( Call Security ). Modelo de Objeto Utiliza o conceito de objeto. Utiliza o conceito de objeto. Transparência de localização Obtida através de ponteiros para interface. Obtida através da utilização de ORBs. Transparência de plataforma Obtida através de protocolos de comunicação. Obtida através de protocolos de comunicação. Protocolos Object RPC (ORPC). General inter-orb Protocol (GIOP) e Internet inter-orb Protocol (IIOP). Transparência de linguagem Obtida através da utilização de IDL ( Interface Definition Language ). Obtida através da utilização de Interface Definition Language (IDL). Linguagem de Definição de Interface (IDL) Utiliza a Microsoft Interface Definition Language. Utiliza a Interface Definition Language especificada pelo CORBA. (continua) 184

33 Interfaces Interfaces (cont.) Interfaces (cont.) Interfaces (cont.) Interfaces (cont.) Interfaces (cont.) Interfaces (cont.) Interfaces (cont.) Interfaces (cont.) (continua) TABELA 6.1 Continuação Objetos suportam múltiplas interfaces. Suportam herança de interface simples. Todo objeto implementa a interface IUnknown, da qual todas as demais são herdeiras. A identificação de um objeto remoto é feita através de um ponteiro para interface. Utiliza o conceito de Identificador de Interface (IID) e Identificador de Classe (CLSID) mapeados num sistema de registro. O cliente pode utilizar a função CoCreateInstance( ) para instanciar um objeto. O cliente utiliza o ponteiro de interface para manipular o objeto. As informações sobre os métodos de um objeto estão armazenadas na Type Libray. Parâmetros podem ser passados entre cliente e objeto por valor ou referência, conforme especificados nas interfaces. Objetos suportam uma interface e adaptadores de objetos. Suportam herança de interface múltipla. Todas as interfaces são herdeiras de CORBA.Object. A identificação de um objeto remoto é feita através de uma referência de objeto (objref). Utiliza um nome para identificar uma interface e um nome para identificar a implementação do objeto que é mapeado no Repositório de Implementação. O cliente pode utilizar o serviço de nomeação para instanciar um objeto. O cliente utiliza a referência do objeto para manipular o objeto. As informações sobre os métodos de um objeto estão armazenadas no Repositório de Interface. Parâmetros, definidos na interface, são passados entre cliente e objeto por referência. Objetos e tipos de dados complexos são passados por valor. 185

34 Coletor de Lixo ( Garbage Collection ) Persistência de objetos Erros e Exceçôes TABELA 6.1 Conclusão O mecanismo de pinging permite deletar objetos que não estão sendo mais referenciados. O cliente determina onde os dados persistentes serão armazenados. Todo método pode retornar uma estrutura bem definida, chamada HRESULT, onde cada bit ou conjunto de bits, codifica um status de retorno do método. O CORBA requer que o cliente, explicitamente, diga ao ORB que um objeto deve ser destruído. É transparente para o cliente onde os dados persistentes serão armazenados. O tratamento de exceção é feito de forma transparente pelo ORB. Faz parte da IDL. De forma a complementar a comparação entre o CORBA e o DCOM é apresentado no Apêndice A um exemplo de aplicação utilizando estas duas arquiteturas de distribuição de objetos. Este exemplo é composto de arquivos que ilustram uma forma de: Definir interfaces escritas em IDL, Clientes invocarem métodos das interfaces através da aquisição de referências para o objeto servidor, Implementar um objeto servidor, Implementar um programa principal. 186