Autor: Nelson Naoki Umeda

DCOM (COMPONENT OBJECT MODEL) X DSOM (SYSTEM OBJECT MODEL)

Objetos Distribuídos:

Distribuir aplicativos nessa era de software de componentes consiste em distribuir objetos. Para as arquiteturas de objetos há duas opções: DCOM e Corba. O primeiro, o Distributed Component Object Model, da Microsoft é construído sobre as tecnologias Active X e OLE. O DCOM funciona com o Windows NT Server, mas ainda não com o UNIX (disponível versão em beta). A Lotus e o Netscape seguiram o caminho aberto com o Common Object Request Broker Architecture, que oferece uma arquitetura de objetos mais completa que o DCOM. Especificado pelo Object Management Group (OMG), o Corba promete uma forma de implementar objetos para serem compartilhados entre máquinas, mesmo quando elas rodam em diferentes sistemas operacionais.

Os pontos fortes do Corba são sua independência de plataforma e a provisão para processamento de transações como parte de sua especificação. O DCOM é atualmente uma solução de plataforma única e os serviços de transações da Microsoft são construídos sobre ele. Conta com uma base instalada de mais de 50 milhões de usuários e uma estreita integração com o Windows. A Netscape não está sozinha ao considerar o DCOM uma arquitetura proprietária, mas a Microsoft argumenta que enquanto o DCOM é um ambiente completo para aplicativos, o Corba é simplesmente uma mistura de especificações montadas a partir das idéias de muitos fornecedores de software sobre como interpretar e implementar objetos distribuídos. Se o passado for uma indicação, uma tecnologia de ponte entre DCOM e Corba evoluirá e o debate esfriará. Por enquanto, podemos esperar ouvir muito barulho sobre os benefícios de cada um. (Bytes Brazil, Agosto de 1997).

Vários "players" da indústria, exceto Microsoft, suportam o Common Object Request Broker Architecture (CORBA) como um padrão aberto para a interação de componentes entre plataformas. A IBM está lançando o OpenDoc, que é baseado na implementação CORBA da IBM, chamada System Object Model (SOM), que garante que partes do OpenDoc irá interagir com outros componentes CORBA-complient da OMG (Object Management Group) através de uma Rede. A Microsoft, por sua vez, está confiando no COM (Component Object Model ) e DCOM (Network-OLE) e espera que outros fabricantes passem a ser DCOM-complient. A Microsoft também está tornando o DCOM CORBA-complient. Assim na batalha DCOM versus DSOM, no fim os dois podem coexistir, OpenDoc pode ter embutido componentes OLE e vice-versa.

OpenDoc:

O real poder da tecnologia de componentes se manifestará quando applets inteligentes, independentes de plataforma, começarem a interagir através das LANs e WANs. A IBM disponibilizou uma parte chave deste quebra-cabeça com o lançamento da segunda versão beta do OpenDoc toolkit para Windows 95 e NT. Via componentes reusáveis, OpenDoc economiza tempo e esforço. Por exemplo: não precisa escrever um editor de texto para a sua aplicação, simplesmente inclui-se um objeto texto (chamado part) no documento, e o OpenDoc garante todas as chamadas para invocar o editor de texto instalado. O programador só precisa, por exemplo, baixar os componentes OpenDoc WebPak e Multimídia PartPak em sua aplicação para suportar HTML, Java applets e Netscape plug-ins. Com os componentes multimídia, uma aplicação ganha suporte para vários arquivos multimídia.

Por enquanto o OpenDoc está disponível para OS/2 Warp, Mac OS, AIX, Windows 95, NT e Mainframe (OS/390). Equipes de programação corporativa poderão estar particularmente atraídas pelo OpenDoc como uma estratégia para construção de partes reusáveis e especializadas e disponibilizá-las por toda a empresa (tem versão Mainframe OS/390). OpenDoc pode revolucionar a indústria pela disponibilização de uma verdadeira arquitetura de componentes para aplicações corporativas (DSOM-Distributed System Object Model).

Quatro pesos pesados da indústria - IBM, Sun, Oracle e Netscape - empreenderam recentemente uma iniciativa no sentido de tornar seus produtos corporativos de software e networking mais compatíveis. Ela está centrada no padrão middleware baseado em objetos Common Object Request Architecture (CORBA), que permite que componentes, aplicativos e banco de dados se comuniquem facilmente entre si. Se os fabricantes cumprirem o prometido, os gerentes de informática não terão que se preocupar com compatibilidade na hora de comprar sistemas, nem gastar muito dinheiro em treinamento. Também vão perder menos tempo conectando produtos de fornecedores. (Computerworld EUA).

Para iniciarmos o assunto acerca de objetos (DOM-Distributed Object Model), temos que começar com Common Object Request Broker Architecture (Corba) criado pelo Object Management Group (OMG).

Como o seu nome sugere, um "object request broker" ajuda objetos a encontrar um outro em uma rede. Corba 2.0 adotado em dezembro de 1994, possibilita "object request brokers" de diferentes vendedores a trabalharem juntos. Infelizmente o nível de aceitação tem sido razoavelmente baixo. Como resultado ele não é vastamente aceito como padrão para distribuição de objetos. O Object Management Architecture do Corba (OMA) define um modelo de 4 níveis. Desde que objetos só podem ser conhecidos e manipulados através de suas interfaces, a OMG idealizou uma Interface Definition Language (IDL) que trabalha em todos os níveis. A idéia é que qualquer objeto cuja interface esteja de conformidade com a IDL possa ser portado através de sistemas operacionais, redes, linguagens e ferramentas.

A base da pilha OMA é o ORB por si, o qual funciona como uma espécie de "bus" que permite a objetos se comunicarem quando eles estão em rede. O Distributed System Object Model (DSOM) da IBM e Neo da Sun Microsystems Inc. são, ambos, ORBs Corba-compliant. Como tal, eles usam o Internet Inter ORB Protocol (IIOP) para todas as comunicações interobjetos. É importante esclarecer que o Distributed Common Object Model (DCOM) da Microsoft Corp. também é um ORB, exceto que o DCOM não é Corba-compliant (ainda).

A próxima pilha acima é o "object services layer", que torna possível criar, nomear e gerenciar objetos. Este é a camada de middleware do OMA. ORBs Corba-compliant podem usar serviços fornecidos por Corba, quando eles estiverem disponíveis.

O "common facilities layer" propor-ciona os serviços usados diretamente pelos objetos da aplicação. OpenDoc da Component Integration Laboratories (IBM?) e Object Linking and Embedding (OLE) da Microsoft residem neste nível, embora OLE como parte do DCOM, não seja Corba-complient.

No topo dos níveis do OMA estão os objetos da aplicação, muitas vezes chamados de "business objects", desde que idealmente eles modelam os processos do negócio. Este é o nível onde applets Java e ActiveX residem.

DCOM-Distributed Component Object Model:

O DCOM (Distributed Component Object Model) é um protocolo que possibilita componentes de software a comunicar diretamente sobre uma rede em uma maneira confiável, segura e eficiente. Anteriormente chamado "Network OLE", DCOM é designado para uso em múltiplos protocolos de transporte de rede, incluindo protocolos de Internet tais como HTTP. DCOM é baseado na especificação DCE-RPC da Open Software Foundation e trabalhará com applets Java e componentes ActiveX através do uso do Component Object Model (COM). Por exemplo, um programador poderia usar Java para construir uma applet que roda em um Web Browser que calcula o valor de alguma coisa, usando DCOM comunica o valor encontrado para o applet em tempo real sobre a Internet.

DCOM foi desenvolvido pela Microsoft Corporation e está correntemente em beta sendo testado no sistema operacional NT4.0 da Microsoft. Tem planos para lançar a versão do DCOM mais tarde neste ano (97), para Windows NT e Windows 95, e começará os teste beta em Macintosh.

DCOM: baseado no COM (Component Object Model) que é a base da tecnologia do Microsoft Transaction Server (MTS), que permite rodar um objeto COM em outras máquinas na rede, permitindo o uso de arquitetura "3-tier" em sistemas operacionais da Microsoft (Windows 95 e Windows NT). Para entender melhor vamos fazer uma analogia com DLLs. Uma DLL é um conjunto de funções em um formato padrão do sistema operacional Windows. As DLLs são códigos compilados e "linkeditados", prontos para uso: o sistema operacional pode carregá-las e executá-las a qualquer momento. O COM é uma versão OOP (Programação orientada a objeto) da DLL, um padrão a ser utilizado para criar objetos executáveis. Sobre este padrão foram construídos outros como OLE e ActiveX. O Padrão COM baseia-se nas DLLs, mas usa um modelo de objeto extensível e reusável. Os objetos COM estão ficando mais importantes com o passar do tempo. Têm as seguintes vantagens: a) Permitem a criação de objetos executáveis, independentes da linguagem usada no desenvolvimento. b) São usados pelos controles ActiveX .

Software AG e Digital Equipment Corporation estão portando o DCOM para outros sistemas operacionais, incluindo as múltiplas implementações do UNIX. O Object Management Group está trabalhando na especificação para que aplicações DCOM possam comunicar diretamente com CORBA-compliant object request brokers.

Para os usuários, foi uma glória quando a Microsoft anunciou que iria linkar sua arquitetura de objetos Distributed Component Object (DCOM) só Windows com o CORBA e adaptá-la para funcionar em outras plataformas. Segundo analistas e usuários, a grande rivalidade do COM e do DCOM da Microsoft tem sido um forte motivo para a baixa aceitação do CORBA no mercado. O DCOM, um subproduto de rede da arquitetura desktop OLE da Microsoft, só roda no Windows. A conexão com o CORBA e a promessa de compatibilidade multiplataformas representam um grande alívio para usuários que se apoiam intensamente em desktops Microsoft. (Computerworld EUA).

Componentes:

Componentes - pequenos e simples blocos de construção que podem ser montados em um sistema complexo, têm se tornado um "approach" padrão em construção de sistemas baseados em PC, e peças de sistemas baseados em Windows de grandes corporações. A arquitetura Component Object Model (COM) da Microsoft tem desempenhado um papel importante na aceitação desta estratégia de componentes, embutindo-o no Visual Basic e padrão ActiveX e Controle OCX que dirige o sistema Windows. Podemos mudar de aplicações enormes, monolíticas para pequenos e mais versáteis blocos de código de programa que possibilitam a criação de aplicações que são um pacote de componentes: uma combinação de componentes construídos na empresa, novos componentes em desenvolvimento ou componentes comprados de terceiros. Este novo paradigma de desenvolvimento de aplicações dá a flexibilidade necessária para escolher o melhor "approach" para cada aplicação. Com a liberação do NT4.0 (Um controle ActiveX é um objeto com uma interface de usuário que você pode programaticamente manipular com uma aplicação, embora você possa criar um programa inteiro como um controle ActiveX, faz mais sentido usar controles como objetos e então usar estes objetos dentro de uma aplicação. A intenção é ter controles ActiveX como componentes não como aplicações), uma dimensão poderosa em programação de componentes emergiu. Distributed COM (DCOM) permite objetos em diferentes computadores a comunicar-se através de protocolos comuns, incluindo protocolos baseados em Internet e Web.

Software AG, trabalhando em conjunto com a equipe de desenvolvedores do Windows NT, tem estendido a riqueza deste poderoso modelo de desenvolvimento de objetos. Agora com a disponibilidade do DCOM for the Enterprise (DCOM-FTE), comunicação entre componentes podem se espalhar por todos os sistemas da organização, do PC a UNIX a Mainframe. DOM (Distributed Object Model) pode ter um impacto enorme em quatro áreas chaves de "networking": eficiência no processamento, administração de usuários, gerenciamento de rede e segurança. A grande sacada da tecnologia de objetos é a sua simplicidade. Um objeto não é nada mais do que uma pequena quantidade de código que realiza uma tarefa específica. A chave aqui é que objetos são atômicos (significa que eles podem ser divididos em pequenas peças). Que podem ser tratados como uma caixa preta. É importante saber o quê um objeto faz, não como ele faz.

Em um ambiente de processamento corporativo como o da Celepar, cuja base de dados e suas aplicações de missão crítica estão centralizados no Mainframe, esta tecnologia pode se tornar a grande solução para o nosso ambiente Cliente/Servidor. Estão chamando esta tecnologia de Network Centric Computing Solution. Atualmente, estamos utilizando o DBGateway da Sybase através de uma rotina genérica desenvolvida na Celepar para acessar bases de dados Adabas no Mainframe. Assim, o objetivo desta matéria é mostrar as potencialidades em termos de conectividade entre plataformas heterogêneas desta tecnologia baseada em componentes:

• Via Corba: A IBM tem o SOM/DSOM disponível no ambiente OS/390, OS/2, AIX, WIN95 e NT.
• Via DCOM: A Microsoft está disponibilizando o MTS (Microsoft Transaction Server - codinome VIPER) que a grosso modo atuaria como um monitor de transação a partir do qual podemos executar componentes no Mainframe (ex: acessar Adabas).

A Software AG está implementando o DCOM no ambiente Mainframe (OS/390) e em UNIXs diversos (ex. do Win95 podemos executar componentes no UNIX e Mainframe). Na linha de produtos da Software AG temos o Net-Work/Broker como o seu Middleware, como vai ser? Teremos uma solução baseada em DCOM à parte ? No site da Software AG diz: "And now we’ve developed ActiveX support into our ENTIRE niddleware to ease your migration to DCOM technology. Today you can take existing mainframe applications that have been written without the use of object oriented technology and integrate them with newer, object oriented applications". Resumindo: suas aplicações podem fazer parte de um ambiente de objetos independentemente do fato de que eles não foram escritos usando a tecnologia de objetos.

Não sabemos ainda como estas implementações funcionarão, principalmente as soluções em plataformas não Windows (que é uma incógnita e é a que mais nos interessa) que estão sendo desenvolvidas pela Software AG (fabricante do Adabas/Natural e Net-Work/Broker). Porém, vale ressaltar que esta tecnologia é para o futuro, a maioria dos produtos/plataformas estão em beta ou não estão disponíveis. Os produtos liberados, por serem novidades ainda não são dominados. O que precisamos é pesquisar, testar, testar ... (prospectar) para quando a tecnologia se firmar não estarmos um passo atrás.

Obs:

1. SEAGATE adere ao DCOM: Versão 7.0 do Backup Exec, utilitário para armaze-namento e gerenciamento de dados na plataforma Windows NT, será baseado no DCOM.
2. Excel opta pelo DCOM: Excel Econômico escolhe o DCOM para acelerar a produção de aplicativos e a manutenção dos sistemas mais antigos. Com a solução será possível queimar etapas para colocar em prática vários projetos, como o sistema de Home e Office Banking...

Referências Bibliográficas:

Fontes:

Revistas:

Byte Brazil ComputerWorld

The Club

Byte

Visual Basic

www:

www.microsoft.com

www.sagus.com