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