CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO CEARÁ CEFET/CE CURSO DE ESPECIALIZAÇÃO EM TELEMÁTICA REDES DE COMPUTADORES

Transcrição

1 CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO CEARÁ CEFET/CE CURSO DE ESPECIALIZAÇÃO EM TELEMÁTICA REDES DE COMPUTADORES MIDDLEWARES PARA APLICAÇÕES MÓVEIS ELIAS TEODORO DA SILVA JÚNIOR DEZEMBRO 2003

2 ii ELIAS TEODORO DA SILVA JÚNIOR MIDDLEWARES PARA APLICAÇÕES MÓVEIS MONOGRAFIA APRESENTADA AO CURSO DE ESPECIALIZAÇÃO EM TELEMÁTICA REDES DE COMPUTADORES, DO CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO CEARÁ FORTALEZA, DEZEMBRO DE 2003

3 iii

4 iv RESUMO No desenvolvimento de aplicações distribuídas, os projetistas não devem se preocupar diretamente com os problemas relativos à distribuição, como heterogeneidade, escalabilidade, compartilhamento de recursos e a própria estrutura de comunicação. O middleware é construído sobre uma estrutura de sistema operacional de rede e coloca o projetista de aplicações em um nível de abstração que esconde a complexidade introduzida pela distribuição. A crescente disponibilidade de dispositivos computacionais móveis, como laptops, assistentes digitais pessoais (PDA), telefones celulares de terceira geração, smartcards e outros estimula a demanda por aplicações distribuídas, as quais trazem seus desafios específicos. Os requisitos para um sistema distribuído móvel incluem: adaptabilidade a mudanças na capacidade de execução e de comunicação, uso eficiente dos recursos de comunicação disponíveis e configuração dinâmica do sistema do usuário final, além de robustez, alta disponibilidade e de tolerância a falhas. Embora exista uma linha de middlewares desenvolvidos para os sistemas distribuídos tradicionais (CORBA, DCE, DCOM, J2EE), eles apresentam várias limitações quando o problema é a mobilidade. Esta realidade fez surgir uma série de outros middlewares especializados em computação móvel. Este trabalho apresenta o estado da arte em middlewares voltados para aplicações móveis, destacando os aspectos que distinguem as diversas soluções atualmente em desenvolvimento.

5 v ABSTRACT When developing distributed applications, designer shouldn t be directly worried about distribution problems, like heterogeneity, scalability, resource share and the communication structure itself. Middleware is implemented over network operating system structure and places the application developer at an abstraction level which hides the complexity caused by the distribution. The growing availability of mobile computational devices, like Laptops, Personal Digital Assistants (PDAs), third generation mobile phones, smartcards and others, encourages the demand for distributed applications, which bring their specific challenges. Mobile and distributed system requirements include: adaptability to changes in the execution and communicating capability, efficient use of available communication resources and dynamic configuration of the end user s system, besides robustness, dependability and fault tolerance. Although there is a set of middlewares developed for traditional distributed systems (CORBA, DCE, DCOM, J2EE), they have several limitations when the matter is mobility. This reality arose a series of other middlewares specialized in mobile computation. This work shows the state of the art in middlewares aimed at mobile applications, emphasizing the aspects that distinguish the various solutions under development nowadays.

6 vi SUMÁRIO INTRODUÇÃO... 1 CAPÍTULO 1. POR QUE E PARA QUE MIDDLEWARES? SISTEMAS DISTRIBUÍDOS O QUE SÃO MIDDLEWARES DCE CORBA DCOM JAVA (J2EE/J2ME) ALGUMAS APLICAÇÕES DO MIDDLEWARE...24 CAPÍTULO 2. MOBILIDADE TIPOS DE MOBILIDADE SISTEMA DE INFORMAÇÃO DISTRIBUÍDO E SEM FIO RESTRIÇÕES DA MOBILIDADE ADAPTABILIDADE...33 CAPÍTULO 3. MIDDLEWARES PARA COMPUTAÇÃO MÓVEL COMPUTAÇÃO MÓVEL AS IMPLEMENTAÇÕES JÁ DESENVOLVIDAS E SUAS CARACTERÍSTICAS CORBA, DCE, Java RMI e DCOM ISAM LIME MA Middleware Middlewares Reflexivos ALICE XMIDDLE RCSM...55 CONSIDERAÇÕES FINAIS BIBLIOGRAFIA... 62

7 vii LISTA DE FIGURAS E TABELAS Fig 1.1: Esquema da arquitetura cliente-servidor... 4 Fig 1.2: Esquema da arquitetura dois níveis... 5 Fig 1.3: Esquema da arquitetura três níveis... 5 Fig 1.4: Esquema de um sistema distribuído baseado em middleware... 6 Fig 1.5: O middleware e suas interfaces em um ambiente de aplicações distribuídas... 7 Fig 1.6: Modelo de referência ISO/OSI Fig 1.7: Arquitetura do DCE Fig 1.8: Uma requisição feita pelo cliente à implementação do objeto Fig 1.9: Estrutura do CORBA e suas interfaces Fig 1.10: Cliente acessando um objeto COM através de um ponteiro de interface (interface pointer) Fig 1.11: Três maneiras de acessar objetos COM Fig 1.12: Mecanismo COM de comunicação entre processos Fig 1.13: Aplicações JAVA multi-nível Fig 1.14: Comunicações com o servidor J2EE Fig 1.15: Nível Web e aplicações J2EE Fig 1.16: Níveis de negócios e EIS do J2EE Fig 2.1: Pesquisas em sistemas de computação distribuídos Fig 3.1: Arquitetura do ISAM Fig 3.2: Escopo de utilização do ISAM Fig 3.3: Espaço de tuplas compartilhado dá suporte a mobilidade física e lógica Fig 3.4: Arquitetura do middleware para mobilidade sobre a plataforma SOMA Fig 3.5: Abstrações de localidade adotadas no SOMA Fig 3.6: Estrutura de um perfil de aplicação... 50

8 viii Fig 3.7: Comunicações no ambiente ALICE Fig 3.8: Arquitetura de software do ALICE Fig 3.9: Pilha de protocolos para ambientes móveis usando o XMIDDLE Fig 3.10: Arquitetura do XMIDDLE Fig 3.11: Esquema geral da geração de um objeto sensível ao contexto no RCSM Fig 3.12: Componentes do RCSM Fig 3.13: Software-Hardware codesign do R-ORB Tabela 1.1: Aplicações Java multi-nível... 21

9 ix LISTA DE ABREVIATURAS API Application Programming Interface CLDC Connected Limited Device Configuration COM Component Object Model CORBA Common Object Request Broker Architecture DCE Distributed Computing Environment DCOM Distributed Component Object Model DOM Document Object Model EIS Enterprise Information System EJB Enterprise JavaBeans ERP Enterprise Resource Planning FPGA Field-Programmable Gate Array GNU General Public License GSM Global System for Mobile Communications HTML HyperText Markup Language HTTP HyperText Transfer Protocol IDL Interface Definition Language IP Internet Protocol J2EE Java 2 Enterprise Edition J2ME Java 2 Micro Edition

10 x J2SE Java 2 Standard Edition JSP JavaServer Pages JVM Java Virtual Machine LAN Local Area Network OLE Object Linking and Embedding OMA Object Management Architecture OMG Object Management Goup ORB Object Request Brokers OSF Open Systems Foundation PDA Personal Digital assistant QoS Quality of Service RMI Remote method Invocation RPC Remote Procedure Call SGBD Sistema de Gerenciamento de Banco de Dados SQL Structured Query Language TCP Transmission Control Protocol UDP User Datagram Protocol XML extensible Markup Language

11 1 INTRODUÇÃO Em um sistema distribuído, a complexidade introduzida pela distribuição de recursos se torna transparente para o programador das aplicações através do uso das tecnologias middleware. Assim, o que está abaixo da camada de aplicação é visto pelo desenvolvedor como uma caixa preta. As plataformas middleware (DCE [OSF 96], CORBA [OMG 01], DCOM [DCOM 97] e J2EE [Sun 03]), disponíveis já há um bom tempo, procuram ocultar do desenvolvedor de aplicações as características do sistema, tornando o desenvolvimento e a manutenção de aplicações distribuídas mais rápido e barato. Entretanto, estas plataformas foram originalmente desenvolvidas para uma rede fixa de comunicação, que pressupõe conexões permanentes e estações sem muitas limitações de recursos (memória, processador e outros). Nos dias de hoje tem aumentado significativamente a diversidade e a disponibilidade de dispositivos móveis como: laptops, assistentes digitais pessoais (PDA), telefones celulares de terceira geração, smartcards e outros. Tecnologias como WaveLAN (IEEE ), IrDA e Bluetooth [Bluetooth 99] estão disponíveis nos mais diversos dispositivos, facilitando a integração entre estes dispositivos e deles com uma rede fixa. Os preços dos dispositivos móveis têm se reduzido e a sua capacidade computacional tem se elevado. Estas facilidades vêm estimulando o desenvolvimento de aplicações para estes dispositivos, em especial aquelas que levam à integração destes dispositivos a redes que ofereçam serviços de troca de informações e compartilhamento de recursos. Estes mesmos dispositivos impõem alguns desafios/limitações para o desenvolvimento de aplicações. Em especial a memória disponível, a velocidade do processador e a potência da bateria são recursos limitados e devem ser usados eficientemente. E ainda, a conexão com a rede pode ser perdida eventualmente, além da largura de banda ser bem mais reduzida que em uma rede fixa. As propriedade dos sistemas móveis requerem do sistema distribuído um comportamento diferenciado em relação ao tradicional. Em um sistema móvel a desconexão é

12 2 a hipótese mais provável. Também não é raro que o cliente e o servidor não estejam conectados simultaneamente, ou seja, uma comunicação síncrona não é possível em muitas situações. Como a localização dos dispositivos varia continuamente e as condições do canal de comunicação são instáveis o serviço de localização dos elementos/estações do sistema se torna mais importante. Além disso, pode ser importante para a aplicação saber onde está a estação que a executa. Para prover os desenvolvedores de aplicações com uma plataforma middleware adequada às propriedades dos sistema móveis, uma boa variedade de projetos está em andamento em todo o mundo. Basicamente eles visam a atender dois tipos de sistemas móveis. Um grupo é chamado nômade e o outro ad hoc, sendo que este último não possui uma estrutura fixa à qual as estações se conectam. Esta monografia apresenta o estado da arte em middlewares voltados para aplicações móveis, destacando os aspectos que distinguem as diversas soluções atualmente em desenvolvimento. A intenção é ajudar aqueles interessados no estudo de middlewares a comparar e avaliar as vantagens e limitações de cada abordagem adotada na solução deste problema. O restante deste trabalho esta estruturado da seguinte forma: O capítulo 1 apresenta os sistemas distribuídos e descreve a função do middleware. Para exemplificar são mostradas as principais plataformas middleware para redes fixas. O capítulo 2 discute a computação móvel e suas propriedades. Nesta área pelo menos três termos vêem sendo usados com freqüência: computação nômade, computação ubíqua e computação pervasiva. As diferenças entre as três são apresentadas neste capítulo, bem como o seu impacto sobre o sistema distribuído. O capítulo 3 trás os principais middlewares para sistemas móveis em desenvolvimento em vários centros de pesquisa no mundo. As suas propriedades são discutidas e são feitas algumas comparações entre eles. Finalmente, algumas considerações finais são feitas em relação ao estado de desenvolvimento da área e as possibilidades de trabalhos futuros.

13 3 CAPÍTULO 1. POR QUE E PARA QUE MIDDLEWARES? 1.1. SISTEMAS DISTRIBUÍDOS O termo middleware é usado no contexto de desenvolvimento de aplicações distribuídas, ou sistemas distribuídos. Antes de se definir middleware deve-se entender o contexto de sistemas distribuídos. Em [Kirner 88] são apresentadas várias definições do conceito de sistemas distribuídos, processamento distribuído, computação distribuída e ainda processamento de dados distribuído. No final da década de 70 chegou-se a um entendimento que vários elementos de um sistema poderiam ser distribuídos (programas, dados, processadores e sistema operacional), mas que a descentralização do controle seria o principal diferencial em relação aos sistemas clássicos. É fundamental observar o software para que se identifique um sistema distribuído [Pardo 79]. A diferença básica entre uma rede de computadores e um sistema distribuído é o software. Em uma rede, a cooperação entre sistemas remotos limita-se aos serviços usuais já padronizados (transferência de arquivos, correio etc). Em um sistema distribuído, a cooperação entre sistemas remotos é bastante elaborada, uma vez que envolve a implementação de compartilhamento implícito de múltiplos recursos remotos. Diz-se que um compartilhamento é implícito se o acesso aos recursos remotos é feito automaticamente pelo sistema de forma transparente para o usuário. Sloman caracteriza um sistema de processamento distribuído como sendo aquele no qual alguns processadores autônomos, executando processos que suportam armazenamento de dados ou bases de dados, cooperam para atingir um objetivo comum [Sloman 87]. Os processos coordenam suas atividades e trocam informações através de uma rede de comunicações. Os seguintes atributos são requeridos de um sistema distribuído: número arbitrário de sub-sistemas e aplicações, arquitetura física modular, comunicação por passagem

14 4 de mensagens usando um sistema de comunicação compartilhado e algum controle que abranja todo o sistema. Uma aplicação distribuída [Albuquerque 00] pode fornecer melhor desempenho, confiabilidade (pelo menos algumas partes da aplicação podem ficar operando), segurança (camadas diferentes em máquinas diferentes) e escalabilidade (atualizações podem ser feitas por partes). Em contrapartida esta tecnologia apresenta maiores dificuldades no desenvolvimento de aplicações. Na área de aplicações distribuídas destaca-se atualmente a arquitetura cliente-servidor [Sadoski 97]. Este termo começou a ser usado na década de 80 em referência a uma rede de computadores pessoais. A seguir são apresentadas as tecnologias cliente-servidor mais comuns. As tecnologias precursoras, Mainframe e compartilhamento de arquivos, não são propriamente cliente-servidor. Fig 1.1: Esquema da arquitetura cliente-servidor A arquitetura cliente-servidor surge para superar as limitações da arquitetura de compartilhamento de arquivos. Usando um banco de dados relacional, as perguntas dos usuários podem ser respondidas diretamente. Ao invés de todo o arquivo ser transportado pela rede, somente a informação necessária é enviada. Desta forma, a arquitetura cliente-servidor reduz o tráfego na rede, já que utiliza o mecanismo de perguntas e respostas ao invés de transferir o arquivo inteiro. Na comunicação cliente-servidor é comum se usar uma linguagem

15 5 de consulta (SQL) ou chamada a processos remotos (RPC). A figura 1.1 apresenta um esquema desta comunicação indicando os níveis envolvidos e o sentido do fluxo de informações. Fig 1.2: Esquema da arquitetura dois níveis Fig 1.3: Esquema da arquitetura três níveis A arquitetura em dois níveis oferece bons resultados para um número reduzido de usuários (100, tipicamente). Conforme se vê na figura 1.2, uma camada (ou nível) é a interface com o usuário e a outra é o Sistema de Gerenciamento de Banco de Dados (SGBD). Além da limitação de clientes, a arquitetura em dois níveis tem problemas com a divisão da base de dados em mais de um servidor e com a escalabilidade da aplicação e dos dados.

16 6 Também tem problemas de dependência de determinado SGBD para o qual a aplicação foi desenvolvida. Para superar estas limitações surge a arquitetura 3-níveis (3-tier), ou multi-nível, apresentado na figura 1.3. Neste caso um nível intermediário é colocado entre a camada de interface com o usuário e o ambiente do servidor de banco de dados. Desta forma se consegue maior flexibilidade, transparência, escalabilidade e segurança no acesso aos dados. Esta camada intermediária é o que se costuma denominar de middleware. Fig 1.4: Esquema de um sistema distribuído baseado em middleware Middleware é um software de conectividade composto de um conjunto de serviços que permitem que múltiplos processos, sendo executados em um ou mais processadores, possam interagir através da rede [Bray 97]. Ele é um conjunto de softwares localizado entre as aplicações e o Sistema Operacional e a infra-estrutura de rede. As figuras 1.4 e 1.5 ilustram esta idéia. O papel do middleware é criar a ilusão de que todos os serviços aos quais a aplicação tem acesso estão em uma só máquina [Bernstein 93] [Orfali 96]. Do ponto de vista da aplicação, ele é visto como um conjunto de APIs (Application Programming Interface). Do ponto do vista do sistema operacional de redes ele é um solicitante de serviços. O middleware

17 7 deve apresentar as seguintes características: localização transparente através da rede, confiabilidade e disponibilidade, independência dos serviços da rede e escalabilidade sem perda de funções. A figura 1.4 apresenta um esquema geral de um sistema distribuído que ilustra bem a idéia do middleware como intermediário entre aplicações e infra-estrutura de comunicação. Embora a interação entre os componentes nas diversas estações pudesse ser feita diretamente através das primitivas do sistema operacional de rede, isto seria complexo para a maioria dos desenvolvedores de aplicações. Ao invés disto o middleware é colocado entre os componentes do sistema distribuído e os componentes do sistema operacional de rede. Sua missão é facilitar a interação entre os componentes das aplicações. O termo middleware é usado para descrever produtos separados que servem como cola entre duas aplicações, ou duas partes de uma aplicação. Entretanto, não é a mesma coisa que importar e/ou exportar dados. Fig 1.5: O middleware e suas interfaces em um ambiente de aplicações distribuídas tecnologias: Desde que foi criado, o middleware vem sendo implementado usando várias

18 8 Monitor de TP (Transaction Processing) - Trata os pedidos, define prioridades, chama múltiplos servidores. É usado em balanço de carga de servidores e no atendimento de grande número de cliente (milhares). Servidor de mensagens - MOM (Message-Oriented Middleware) - A diferença para o monitor de TP é que a inteligência é deslocada para os clientes ao invés de ser centralizada no nível intermediário. Servidor de aplicações - Procura colocar a maior parte da aplicação nos recursos compartilhados do sistema. Oferece maior escalabilidade. Utiliza RPC (Remote Procedure Call). Arquitetura ORB (Object Request Brokers) ou orientada a objetos - Para o desenvolvedor da aplicação no cliente, o ORB [Wallnau 97] é basicamente um conjunto de classes que está disponível. Estas classes implementam as ações de localização, ativação e estabelecimento da conexão com o objeto remoto (em outro processador ou em outra estação) como se este estivesse disponível localmente para o cliente. Mas o ORB também pode ser um processo rodando à parte ou ainda estar contido no Kernel do Sistema Operacional. CORBA e DCOM são as tecnologias em maior evidência. Empreendimento Colaborativo Distribuído (Distributed/Collaborative Enterprise Architecture) - é baseado em ORB, mas é diferente de CORBA (ver detalhes sobre CORBA na seção 1.2.2). Estas tecnologias de middleware foram construídas para esconder a distribuição tanto quanto possível, de maneira que o sistema se mostre como sendo um único recurso computacional integrado. Em outras palavras, que a distribuição se torne transparente. Os sistemas distribuídos tradicionais (fixos) foram a primeira forma de implementar aplicações distribuídas. As investigações em torno desta tecnologia começaram há aproximadamente 20 anos e muitos esforços e pesquisas foram empreendidos na solução de seus problemas. Neste tempo, várias plataformas middleware bem sucedidas foram projetadas e utilizadas. Embora o propósito do middleware seja prover conectividade entre aplicações, existem alguns problemas de interoperabilidade. Algumas implementações são proprietárias e, além disso, o desenvolvedor deve decidir qual parte da aplicação colocar no cliente ou no

19 9 servidor. Na sessão seguinte serão mostradas as plataformas middleware mais conhecidas e as suas características principais O QUE SÃO MIDDLEWARES Segundo [Raatikainen 01], middleware é uma das soluções propostas para melhorar o desempenho de sistemas distribuídos. Embora, o termo middleware seja largamente utilizado para representar uma camada de serviços localizada entre as aplicações distribuídas e a infraestrutura da rede de comunicação juntamente com o próprio sistema operacional, não há consenso na definição da linha divisória entre estes elementos [RFC2768]. Também não há consenso sobre o conjunto básico de serviços que todas as aplicações requerem do middleware. Aliás, a abordagem por camadas não é a ideal e por vezes produz mais confusão que compreensão. O melhor seria considerar o middleware como sendo uma coleção não estruturada de componentes (recursos e serviços) que poderiam ser utilizados individualmente ou em vários sub-conjuntos. A resposta à pergunta o que é Middleware? vai depender de quem a responde, de sua visão sobre o sistema no qual o middleware está inserido. Por exemplo, os desenvolvedores de aplicações vêem tudo que está abaixo da API como sendo middleware. Alguns profissionais de infra-estrutura de redes vêem o middleware como sendo tudo acima do IP. Já outros classificam os middlewares em upper middleware (específicos de algumas aplicações), middle middleware (genéricos) e lower middlewares (específicos para alguns recursos). Para a NGI (Next Generation Internet) Middleware pode ser visto como um conjunto de serviços e funções (reutilizáveis e expansíveis) que são comumente necessários a muitas aplicações para o bom funcionamento em um ambiente de rede. [Smith 97] Segundo Mascolo o middleware é desenvolvido sobre uma estrutura de sistema operacional de rede e coloca o projetista de aplicações em um nível de abstração que esconde a complexidade introduzida pela distribuição [Mascolo 02]. O middleware implementa as camadas de apresentação e de sessão do modelo de referência ISO/OSI, conforme ilustrado na figura 1.6. Sua função principal é habilitar a comunicação entre os componentes do sistema distribuído.

20 10 Em [Murphy 01] temos que o middleware surgiu como uma nova ferramenta de desenvolvimento que pode suprir os programadores com os benefícios de uma poderosa máquina virtual especializada e otimizada para tarefas comuns em um conjunto particular de aplicações, sem os grandes investimentos associados ao desenvolvimento e usando linguagens de sistemas específicos da aplicação. Fig 1.6: Modelo de referência ISO/OSI. Em resumo, existem muitas visões do que seja middleware. A maioria dos grupos atuantes nesta área prefere definir um conjunto de serviços para o seu middleware, ao invés de buscar uma definição completa do termo. Alguns dos middlewares mais conhecidos são o DCE, da OSF, o CORBA, da OMG, o DCOM da Microsoft e o J2EE da SUN. Os itens a seguir fornecem uma breve descrição de cada uma destes middlewares. Trata-se de plataformas de uso geral não orientadas a nenhum tipo de aplicação em particular. Aqui será dada uma visão geral de cada uma delas. As questões relacionadas ao emprego destas plataformas middleware em aplicações móveis serão discutidas no capítulo DCE DCE (Distributed Computing Environment) foi desenvolvido e mantido pela OSF (Open Systems Foundation) [OSF 96]. A OSF fornece uma implementação de referência

21 11 (código fonte) que é incorporada pelos fornecedores em seus produtos e na qual todos os produtos DCE estão baseados. Assim, os usuários finais compram o DCE já dentro do sistema de aplicação distribuída. É uma plataforma para construção de soluções que funciona independentemente do sistema operacional ou da infra-estrutura de rede. A arquitetura do DCE pode ser visualizada na figura 1.7 e seus serviços estão divididos em duas categorias [Vondrak 97]: Serviços distribuídos fundamentais Fornece as ferramentas para que os desenvolvedores possam criar os serviços para os usuários finais. Inclui RPC e serviços de diretório, tempo, segurança e Threads. Serviços de compartilhamento de dados Este serviço não requer programação por parte do usuário final e facilita um melhor uso da informação. Inclui sistema de arquivos distribuídos e suporte a diskless. DCE utiliza uma estrutura de células, compostas de nós, cada uma sendo gerenciada por uma autoridade. As comunicações dentro de uma célula são relativamente seguras e transparentes. Comunicações entre células diferentes, entretanto, são uma pouco mais complicadas. Fig 1.7: Arquitetura do DCE

22 12 O DCE foi escolhido para ser utilizado em uma série de aplicações científicas e de defesa americanas de grande porte. Isto pode indicar que terá uma boa base de apoio. A versão DCE 1.2.1, de março de 1996 (atualmente está disponível a versão 1.2.2), oferece suporte IDL para C++ e adaptação ao conceito de objetos, dentre outros recursos. O DCE ainda atende aos requisitos para uso da especificação CORBA através de um protocolo interorb específico, que está disponível, testado e em uso, diferente de um protocolo inter-orb geral. O grupo DCE (open group) também fornece uma especificação para desenvolvedores e um conjunto de testes usados para validar a conformidade com o padrão DCE. Muitos fornecedores oferecem as funções básicas do DCE junto com os recursos do sistema operacional. Para a segurança o DCE utiliza a tecnologia Kerberos, considerada de alta confiabilidade, além de ser um meio bastante conhecido de proteger a rede. Como limitações do DCE temos que ele não foi construído para ser completamente orientado a objetos. Também o padrão de interfaces usado pelo DCE é compatível somente com a linguagem C. Para aplicações que usem linguagem de programação orientada a objeto, como C++, o trabalho pode ser mais complexo, pouco produtivo e de difícil manutenção. Um grupo de grandes da informática (IBM, HP, Digital e outros) desenvolveu um projeto de DCE na Web para demonstrar a força dele em segurança e distribuição de nomes. A idéia é expandir as capacidades das tecnologias Web existentes. Mas o fato é que o DCE foi desenvolvido antes que a Internet ganhasse a importância que tem hoje. Em vista disto, não é fácil encontrar produtos que usem esta tecnologia em aplicações integradas à Web. Embora ele possa funcionar sobre o TCP/IP ele não tem suporte ao protocolo HTTP, principal protocolo de aplicação em uso na Internet. Finalmente, o DCE não está mais em desenvolvimento. Não está sendo aprimorado para atender a novas necessidades, nem está sendo mantido e nem existe suporte formal para algum sistema operacional. As principais referências ao DCE foram produzidas em torno de Algumas outras obras escritas no final dos anos 90 apontam estratégias de migração para outras tecnologias, como é o caso de [Jensen 01].

23 CORBA O CORBA (Common Object Request Broker Architecture) [OMG 01] é um padrão que foi definido pela OMG Object Management Goup, uma organização que reúne cerca de 800 empresas do mundo todo, como IBM, Digital, Oracle, Sun e Sybase. O padrão CORBA é um sistema que permite que aplicações distribuídas em uma rede (local ou mesmo na Internet) comuniquem-se entre si e troquem informações. Do ponto de vista da especificação CORBA, estas aplicações podem estar sendo executadas em diferentes plataformas de hardware (Intel, Sun, etc) e sistemas operacionais (Windows, Linux, Unix, etc) e podem ter sido construídas em diferentes linguagens de programação. Utilizando o padrão CORBA é possível ter aplicações completamente distribuídas, potencialmente com cada pedaço de software sendo executado em qualquer parte da rede e em qualquer plataforma, sem que o usuário perceba que isto está acontecendo e sem que o desenvolvedor precise se preocupar em criar soluções que resolvam os problemas de interoperabilidade entre os diferentes pedaços da aplicação. Atualmente, diversas ferramentas já suportam o padrão CORBA, como Delphi 4, JBuilder 2, Oracle 8i, Cold Fusion e C++ Builder. Uma grande vantagem de CORBA é ser um padrão que tem um bom suporte por empresas em todo o mundo e com dezenas de implementações disponíveis, incluindo algumas gratuitas. Teoricamente, essa padronização significa que o usuário não precisa ficar preso a determinados fornecedores, plataformas ou produtos, como acontece quando são escolhidas soluções proprietárias. Na prática, a interoperabilidade entre sistemas de diversos fornecedores ainda é uma coisa difícil de viabilizar. Cada fabricante tem liberdade para fazer implementações diferentes das demais em muitos detalhes, além de poder acrescentar recursos próprios. Existem várias implementações do padrão CORBA, como: ORBIX da IONA Technology, NEO da SunSoft, VisiBroker da VisiGenic, PowerBroker da Expersoft, SmallTalkBroker da DNS Technologies, Object Director da Fujitsu, DSOM da IBM, DAIS da ICL, SORBET da Siemens Nixdorf, and NonStop DOM da Tandem. Para cada sistema da rede, o CORBA permite definir uma interface neutra (independente de linguagem) chamada IDL, que descreve os serviços que estão sendo fornecidos. Assim, qualquer aplicação cliente é capaz de entender e acessar esses serviços, mesmo que cada sistema tenha sido implementado em uma linguagem e hardware diferentes.

24 14 Como o CORBA faz todo o trabalho de tradução, para a aplicação cliente não importa qual o tipo de servidor está sendo acessado (e vice-versa), nem faz diferença em qual linguagem cada um foi desenvolvido. IDL especifica a interface entre clientes e objetos. Os demais detalhes, como o comportamento de ambos, ficam transparentes. A figura 1.8 mostra como os stubs e skeletons servem como procuradores (proxies) para cliente e servidor respectivamente. Mas existe uma limitação: IDL é apenas uma espécie de denominador comum, não podendo explorar as potencialidades da linguagem para a qual está sendo mapeado, principalmente quanto a tipos abstratos de dados. Fig 1.8: Uma requisição feita pelo cliente à implementação do objeto. Além da IDL, o CORBA inclui também uma infra-estrutura de execução, fornecendo diversas funcionalidades básicas importantes como localização e ativação automática de serviços, comunicação, controle de transações e segurança. A principal revisão é a versão 2.0 de CORBA está inserido em um contexto mais amplo chamado OMA (Object Management Architecture), que é um conjunto maior de objetos de aplicação, o próprio ORB e os serviços e recursos CORBA. A figura 1.9 mostra os Componentes da especificação CORBA [Wallnau 97], que são: Núcleo do ORB - Sua interface não faz parte da especificação CORBA.