UNIVERSIDADE FEDERAL DE UBERLÂNDIA FACULDADE DE ENGENHARIA ELÉTRICA PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA

UNIVERSIDADE FEDERAL DE UBERLÂNDIA FACULDADE DE ENGENHARIA ELÉTRICA PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA ARQUITETURA PARA DISTRIBUIÇÃO DE AMBIENTES VIRTUAIS MULTIDISCIPLINARES ORIENTADOR: EDGARD LAMOUNIER JÚNIOR, PhD CO-ORIENTADOR: ALEXANDRE CARDOSO, Dr ORIENTANDO: MARCOS WAGNER DE SOUZA RIBEIRO JANEIRO 2006

UNIVERSIDADE FEDERAL DE UBERLÂNDIA FACULDADE DE ENGENHARIA ELÉTRICA PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA ARQUITETURA PARA DISTRIBUIÇÃO DE AMBIENTES VIRTUAIS MULTIDISCIPLINARES Tese apresentada por Marcos Wagner de Souza Ribeiro à Universidade Federal de Uberlândia para obtenção do título de Doutor em Ciências. Professor Edgard Lamounier Jr., PhD (Orientador) Professor Alexandre Cardoso, Dr (Co-Orientador) Professor Cláudio Kirner, Dr Professor Luciano Vieira Lima, Dr Professor Paulo Roberto Guardieiro, Dr Professor Djamel Sadok, PhD ii Uberlândia, 30 de janeiro de 2006.

ARQUITETURA PARA DISTRIBUIÇÃO DE AMBIENTES VIRTUAIS MULTIDISCIPLINARES MARCOS WAGNER DE SOUZA RIBEIRO Tese apresentada por Marcos Wagner de Souza Ribeiro à Universidade Federal de Uberlândia como parte dos requisitos para obtenção do título de Doutor em Ciências. Profº Edgard Lamounier Júnior Orientador Profº. Darizon Alves Andrade Coordenador do Curso de Pós-Graduação iii

DEDICATÓRIA À minha esposa, Eliane À minha filha, Stefani Ao meu irmão, Dioni Aos meus pais José Ribeiro e Odília iv

AGRADECIMENTOS Agradeço primeiramente a Deus, que permitiu a finalização de uma mais uma etapa em minha vida. Ao professor e amigo Edgard Lamounier, orientador deste trabalho, pela valiosa orientação e por me mostrar sempre o caminho a seguir. Ao professor Alexandre Cardoso pelo apoio e amizade na co-orientação deste trabalho. E, a todos aqueles que contribuíram de forma direta ou indireta para a realização deste trabalho. v

RESUMO RIBEIRO, Marcos Wagner de Souza. Arquitetura para Distribuição de Ambientes Virtuais Multidisciplinares, Uberlândia, Faculdade de Engenharia Elétrica - UFU, 2005, 176p. Esta tese apresenta uma arquitetura para distribuição de ambientes virtuais como ferramenta de apoio a projetos multidisciplinares de ensino. Para tanto, diferentes plataformas de distribuição foram avaliadas com o objetivo de identificar aquela que com mais eficiência permita que interações ocorridas em um ambiente altere o comportamento de outros, mesmo que estes sejam relacionados a outras áreas do conhecimento. Protótipos construídos sobre a plataforma escolhida para a distribuição, seguindo uma mesma metodologia (onde aspectos do modelo de dados foram alterados) e ainda, tendo a latência, escalabilidade e extensibilidade como parâmetros de comparação demonstraram qual a melhor abordagem para construção de ambientes virtuais multidisciplinares. Cada protótipo foi construído com base em algoritmos de distribuição que permitiram ao sistema funcionar corretamente em situações passíveis de erros. Ambientes Virtuais de Biologia (paisagem com plantas, água, luz e terra) e Química (membrana de uma folha) foram utilizados tendo o fenômeno da fotossíntese como estudo de caso e relação entre os dois ambientes. O sistema foi avaliado por professores e alunos e os resultados alcançados permitiram concluir que o mesmo é eficaz e aplicável. Palavras-Chave: Ambientes Virtuais Distribuídos, CORBA, Multidisciplinaridade, Realidade Virtual vi

ABSTRACT RIBEIRO, Marcos Wagner de Souza. Architecture To Support Multidisciplinary Learning Through Virtual Environment Distribution, Uberlândia, Faculty of Electrical Engineering - UFU, 2005, 176p. This thesis presents a study of architecture for virtual environment distribution as support tool for learning multidisciplinary projects. Different distribution platforms have been evaluated with the objective to identify the one that with more efficiency allowed exactly that occurred alterations in an environment modify the behavior of others, that these are related to other areas of the knowledge. Building prototypes under the platform chosen for the distribution, following same methodology (modifying aspects of the data model) and having the latency, scalability and extensibility as method of comparison had demonstrated to which the best choice for building multidisciplinary virtual environment. Each prototype was constructed on the basis of distribution algorithms that had allowed the system to function correctly in possible situations of errors. Virtual environments of Biology (landscape with plants, water, light and land) and Chemistry (membrane and molecules) had been used having the phenomenon of the photosynthesis as study of case and relation between two environments. The system was evaluated by professors and students and the reached results had allowed concluding that it is efficient and applicable. Keywords: CORBA, Distributed Virtual Environments, Multidisciplinary, Virtual Reality vii

PUBLICAÇÕES A seguir são apresentadas as publicações resultantes desse trabalho: RIBEIRO, Marcos Wagner de Souza; LAMOUNIER, Edgard Jr.; CARDOSO, Alexandre. Uso de CORBA na Distribuição de Ambientes Virtuais para Suportar Multidisciplinaridade no Processo da Educação. SVR 2004 VII Symposium on Virtual Reality, 7, 2004, São Paulo. Proceedings São Paulo: SENAC, 2004, p.356-358. RIBEIRO, Marcos Wagner de Souza; LAMOUNIER, Edgard Jr.; CARDOSO, Alexandre. Uso de CORBA na Distribuição de Ambientes Virtuais. Práxis, Canoas-RS, n. 5, p43-52, ago/dez, 2004. RIBEIRO, Marcos Wagner de Souza; LAMOUNIER, Edgard Jr.; CARDOSO, Alexandre. A Study of Distinct Virtual Environments Distribution. Práxis, Canoas-RS, n. 6, p49-56, jan/jul, 2005. RIBEIRO, Marcos Wagner de Souza; LAMOUNIER, Edgard Jr.; CARDOSO, Alexandre. A Proposed Architecture To Support Multidisciplinary Learning Through Virtual Environment Distribution. IASTED International Conference, 17, 2005, Phoenix, AZ, USA. Proceedings on Parallel and Distributed Computing And Systems PDCS 2005, Phoenix: IASTED, 2005. p.56-61. RIBEIRO, Marcos Wagner de Souza; LAMOUNIER, Edgard Jr.; CARDOSO, Alexandre. Uma Proposta de Arquitetura na Distribuição de Ambientes Virtuais Muldisciplinares. Workshop de Aplicações de Realidade Virtual, 1, 2005, Uberlândia. Anais... Uberlândia-MG: UFU, 2005. 1 CD-ROM. viii

SIQUEIRA, Luiz Leonardo, RIBEIRO, Marcos Wagner de Souza; LAMOUNIER, Edgard Jr.; CARDOSO, Alexandre. Estudo Comparativo Entre Plataformas de Suporte a Ambientes Virtuais Distribuídos. Workshop de Aplicações de Realidade Virtual, 1, 2005, Uberlândia. Anais... Uberlândia-MG: UFU, 2005. 1 CD-ROM. RIBEIRO, Marcos Wagner de Souza; LAMOUNIER, Edgard Jr.; CARDOSO, Alexandre. A Proposed Architecture to Support Multidisciplinary Learning through Virtual Environment Distribution. IEEE Transactions Parallel and Distributed Systems. Submetido em novembro de 2005. ix

SUMÁRIO 1. INTRODUÇÃO... 1 1.1. OBJETIVO... 2 1.2. AMBIENTES VIRTUAIS DISTRIBUÍDOS... 4 1.3. CONTRIBUIÇÃO DO TRABALHO... 5 1.4. ORGANIZAÇÃO DA TESE... 6 2. SISTEMAS DISTRIBUÍDOS... 8 2.1. INTRODUÇÃO... 8 2.2. O QUE É DISTRIBUIÇÃO?... 8 2.2.1 Middleware... 11 2.3. PLATAFORMAS DE DISTRIBUIÇÃO DE SOFTWARE... 12 2.3.1 CORBA... 12 2.3.1.1. Histórico...13 2.3.1.2. Características...13 2.3.2 DCOM... 14 2.3.3 JAVA/RMI... 15 2.4. COMPARAÇÃO ENTRE PLATAFORMAS DE DISTRIBUIÇÃO... 16 2.4.1 Uma Aplicação... 16 2.4.1.1. A interface IDL...17 2.4.1.2. Objeto Cliente...19 2.4.1.3. Objeto Servidor...19 2.4.1.5. Conclusão...21 2.5. ESCOLHA DA ARQUITETURA... 27 2.5.1. Objetos Distribuídos e Processamento Distribuído... 28 2.5.2. Objetos Interoperáveis... 31 2.5.3. ORB Object Request Broker... 32 2.5.4. O Cliente ORB... 34 2.5.5. O servidor ORB... 36 2.5.6. Arquitetura OMA... 37 2.6. IMPLEMENTAÇÕES CORBA... 39 2.6.1. O Inter-Language Unification (ILU)... 39 2.6.2. ORBIX da IONA... 40 2.6.3. Visibroker... 40 2.6.3.1. OSAgent...40 2.7. CONSIDERAÇÕES FINAIS... 41 3. AMBIENTES VIRTUAIS... 42 3.1. INTRODUÇÃO... 42 3.2. REALIDADE VIRTUAL... 42 3.2.1. Ambientes Virtuais... 44 3.2.2. Tipos de Sistemas de Realidade Virtual... 46 3.2.3. Aplicações de Realidade Virtual... 47 3.3. AMBIENTES VIRTUAIS DISTRIBUÍDOS... 48 3.3.1. Conceituação e Caracterização... 48 3.3.2. Componentes de um AVD... 52 3.3.3. Comunicação em Rede... 53 3.3.3.1. Largura de Banda...53 3.3.3.2. Latência...53 3.3.3.3. Confiabilidade da Rede...54 3.3.3.4. Esquemas de Comunicação...54 3.3.4. Visões do Usuário de um AVD... 55 3.3.5. Modelos de Dados... 56 3.3.6. Gerenciamento da Computação... 57 x

3.3.7. Comportamento dos Objetos... 58 3.4. PRINCIPAIS AMBIENTES VIRTUAIS DISTRIBUÍDOS... 59 3.4.1. AVDs avaliados... 60 3.5. CONSIDERAÇÕES FINAIS... 68 4. ARQUITETURA DO SISTEMA... 69 4.1. INTRODUÇÃO... 69 4.2. TECNOLOGIAS DE APOIO... 69 4.2.1. OpenGL... 70 4.2.2. CORBA... 71 4.2.3. Visibroker... 72 4.3. ARQUITETURA DO SISTEMA... 72 4.3.1. Interface Gráfica com o Usuário - GUI... 76 4.4. CONSIDERAÇÕES FINAIS... 79 5. IMPLEMENTAÇÃO DO SISTEMA... 80 5.1. INTRODUÇÃO... 80 5.2. DESENVOLVIMENTO DO AMBIENTE VIRTUAL DA BIOLOGIA... 80 5.3. DESENVOLVIMENTO DO AMBIENTE VIRTUAL DA QUÍMICA... 82 5.4. IMPLEMENTAÇÃO DOS PROTÓTIPOS... 84 5.4.1. Protótipo 1 (Espelho)... 85 5.4.2. Protótipo 2 (Dedicado)... 88 5.4.3. Protótipo 3 (Encadeado)... 90 5.4.4. Protótipo 4 (Dividido)... 92 5.4.5. Pré-requisitos... 94 5.5. COMUNICAÇÃO E DISTRIBUIÇÃO DOS AMBIENTES VIRTUAIS... 96 5.5.1. Características Gerais... 104 5.6. CONSIDERAÇÕES FINAIS... 106 6. FUNCIONAMENTO DO SISTEMA... 107 6.1. INTRODUÇÃO... 107 6.2. ESTUDO DE CASO - PROCESSO DA FOTOSSÍNTESE... 107 6.3. FUNCIONAMENTO DO SISTEMA... 109 6.4. DISTRIBUIÇÃO DA INFORMAÇÃO... 112 6.5. CONSIDERAÇÕES FINAIS... 113 7. COMPARAÇÃO DOS PROTÓTIPOS E ANÁLISE DOS RESULTADOS... 115 7.1 INTRODUÇÃO... 115 7.2 AMBIENTE EXPERIMENTAL... 115 7.3. ANÁLISE DOS RESULTADOS OBTIDOS... 116 7.3.1. Latência da Comunicação... 116 7.3.2. Escalabilidade... 118 7.3.3. Extensibilidade... 122 7.3.4. Análise da Geração de Imagens... 123 7.3.5. Comparação com outros AVDs... 124 7.4. AVALIAÇÃO DO SISTEMA... 126 7.5. CONSIDERAÇÕES FINAIS... 131 8. CONCLUSÕES E TRABALHOS FUTUROS... 133 8.1 INTRODUÇÃO... 133 8.2 CONCLUSÕES... 133 8.2.1. Contribuições do Trabalho... 134 8.3 TRABALHOS FUTUROS... 136 xi

LISTA DE FIGURAS Figura 2.1. Latência dos protótipos (SIQUEIRA, 2005).... 27 Figura 2.2. Requisição por meio do ORB... 34 Figura 2.3. Arquitetura CORBA... 38 Figura 2.4. Modelo de Referência (OMG, 2004).... 39 Figura 3.1. Seis graus de liberdade... 45 Figura 4.1. Versão simplificada do pipeline OpenGL (WOO, 1999)... 71 Figura 4.2. Arquitetura proposta para o sistema... 72 Figura 4.3. Modelo Proposto em Camadas.... 74 Figura 4.4. Arquitetura CORBA (OMG, 2004)... 75 Figura 4.5. Arquitetura CORBA adaptada para este trabalho... 76 Figura 4.6. Ambiente Virtual de Biologia... 77 Figura 4.7. Ambiente Virtual de Química... 77 Figura 4.8. Barra de navegação.... 78 Figura 5.1. Visão parcial do arquivo da modelagem do ambiente de Biologia.... 81 Figura 5.2. Ambiente de Biologia... 82 Figura 5.3. Visão parcial do arquivo de modelagem do ambiente de Química.... 83 Figura 5.4. Ambiente de Química... 84 Figura 5.5. Esquema de distribuição dos ambientes virtuais (protótipo 1).... 85 Figura 5.6. Algoritmo de ativação de servidores e conexão de clientes.... 86 Figura 5.7. Esquema de distribuição dos ambientes virtuais (protótipo 2).... 88 Figura 5.8. Algoritmo de ativação de servidores e conexão de clientes.... 89 Figura 5.9. Esquema de distribuição dos ambientes virtuais (protótipo 3).... 90 Figura 5.10. Algoritmo de ativação de servidores e conexão de clientes.... 91 xii

Figura 5.11. Esquema de distribuição dos ambientes virtuais (protótipo 4).... 92 Figura 5.12. Algoritmo de ativação de servidores e conexão de clientes.... 93 Figura 5.13. Arquitetura CORBA (TEIXEIRA, 2002).... 97 Figura 5.14. Adaptação da arquitetura CORBA cliente/servidor para os protótipos 1 e 3... 99 Figura 5.15. Visão dos arquivos Biologia.idl e Química.idl.... 101 Figura 5.16. Visão parcial dos arquivos de interface.... 101 Figura 5.17. Visão parcial dos arquivos stub.... 102 Figura 5.18. Visão parcial dos arquivos skeleton... 103 Figura 5.19. Visão parcial dos arquivos de implementação.... 104 Figura 6.1. Esquema geral da fotofosforilação acíclica (LINHARES, 2000).... 108 Figura 6.2. Estágio inicial dos ambientes virtuais... 110 Figura 6.3. Ambientes virtuais após a interação do usuário no mundo virtual da Biologia. 111 Figura 6.4. Ambiente Virtual de Biologia e Ambiente Virtual de Química no estágio final. 112 Figura 7.1. Latência para 100 mensagens... 117 Figura 7.2. Estimativa da Escalabilidade do Protótipo 1.... 119 Figura 7.3. Estimativa da Escalabilidade do Protótipo 2.... 119 Figura 7.4. Estimativa da Escalabilidade do Protótipo 3.... 120 Figura 7.5. Estimativa da Escalabilidade do Protótipo 4.... 120 Figura 7.6. Comparação da Escalabilidade entre os Protótipos... 121 Figura 7.7. Latência de Comunicação com cinco clientes e apenas um ambiente... 122 Figura 7.8. Estimativa da Extensibilidade dos Protótipos com cinco clientes... 123 Figura 7.9. Análise quanto a finalidade.... 126 Figura 7.10. Análise quanto a Interface.... 127 Figura 7.11. Análise quanto a facilidade de uso... 128 xiii

Figura 7.12. Análise quanto a multidisciplinaridade... 129 Figura 7.13. Análise quanto aos recursos do programa.... 129 Figura 7.14. Análise dos aspectos de avaliação para softwares educacionais... 130 Figura 8.1. Evolução do trabalho.... 135 xiv

LISTA DE TABELAS TABELA 2.1.(A) DIFERENÇAS ENTRE DCOM, CORBA E JAVA/RMI (RAJ, 2004)... 21 TABELA 2.1.(B) DIFERENÇAS ENTRE DCOM, CORBA E JAVA/RMI (RAJ, 2004).... 22 TABELA 2.1.(C) DIFERENÇAS ENTRE DCOM, CORBA E JAVA/RMI (RAJ, 2004)... 23 TABELA 2.1.(D) DIFERENÇAS ENTRE DCOM, CORBA E JAVA/RMI (RAJ, 2004)... 24 TABELA 2.1.(E) DIFERENÇAS ENTRE DCOM, CORBA E JAVA/RMI (RAJ, 2004).... 25 TABELA 2.2. COMPARAÇÃO ENTRE PLATAFORMAS DE DISTRIBUIÇÃO... 26 TABELA 2.3. COMPARAÇÃO ENTRE PLATAFORMAS DE DISTRIBUIÇÃO... 28 TABELA 3.1. PRINCIPAIS CARACTERÍSTICAS DOS AVDS AVALIADOS.... 67 TABELA 5.1. PRINCIPAIS CARACTERÍSTICAS DOS PROTÓTIPOS PROPOSTOS... 96 TABELA 7.1. COMPARAÇÃO COM OUTROS AVDS... 125 TABELA 8.1. QUESTÕES LEVANTADAS NO DECORRER DO TRABALHO.... 136 TABELA 8.2. QUESTÕES LEVANTADAS NO DECORRER DO TRABALHO.... 137 xv

LISTA DE ABREVIATURAS E SIGLAS 2D 3D API AV AVD BOA COM CORBA COSS DCE DIVE GUI HMD IDL IIOP ILU ISO ms OMA OMG OpenGl ORB OSF Bidimensional Tridimensional Application Programming Interface Ambiente Virtual Ambiente Virtual Distribuído Basic Object Adapter Common Object Model Common Object Request Broker Architecture Common Object Service Specifications Distributed Computing Environment Distributed Interactive Virtual Environment Graphics User Interface Head Mounted Display Interface Definition Language Internet Inter-OBR Protocol Inter-Language Unification International Standards Organization Milissegundo Object Management Architecture Object Management Group Open Graphics Library Object Request Broker Open Software Foundation xvi

OSI RPC TCP UDP VR VRML Open System Interconnect Remote Procedure Call Transfer Communication Protocol User Datagram Protocol Virtual Reality Virtual Reality Modeling Language xvii

CAPÍTULO I 1. INTRODUÇÃO Realidade Virtual (RV) é considerada uma tecnologia revolucionária, pois possibilita a simulação de mundos reais e imaginários na tela do computador ou em outros dispositivos, criando no usuário a sensação de presença em um mundo virtual (CRUZ-NEIRA, 1992; CARLSON, 1993). As pesquisas em RV vêm crescendo consideravelmente, por meio de vários grupos de pesquisa, ligados à indústria, ao entretenimento e à educação (AUKSTAKALNIS 1992; CODDELA, 1993 apud NUNES, 2002). Além disso, existem muitos estudos, soluções e implementações para possibilitar que mais de uma pessoa faça parte de um Ambiente Virtual (AV) (SNOWDON, 1994; GARCIA, 2002; KOTZIAMPASIS, 2003; ALIMA, 2004; YARDI, 2005, JING, 2005). Os sistemas distribuídos em parceria com sistemas RV possibilitaram a criação dos Ambientes Virtuais Distribuídos (AVDs), definidos como ambientes virtuais que permitem a participação de diversos usuários ao mesmo tempo. Nesse contexto, as principais pesquisas concentram-se na melhoria do processo de comunicação entre as cópias de um ambiente (SEMENTILLE, 1999). Porém, dependendo da aplicação, nem sempre a preocupação será com a comunicação entre cópias de um ambiente, mas também com a comunicação entre ambientes virtuais distintos, que não fazem parte do mesmo contexto, embora possuam relação de dependência (SIQUEIRA, 2005). Na área da Educação, é comum, pesquisadores estudarem detalhadamente as relações entre conteúdos ou disciplinas com a finalidade de demonstrar que não é possível entender a 1

complexidade 1 do todo, sem entender separadamente os conteúdos envolvidos. Pode-se denominar esse tipo de pesquisa, de acordo com a especificidade de cada um, como Interdisciplinaridade 2, Transdisciplinaridade 3 ou Multidisciplinaridade. Piaget (1972) define Multidisciplinaridade quando há necessidade de obter informações de duas ou mais ciências ou setores do conhecimento sem que as disciplinas envolvidas no processo sejam elas mesmas modificadas ou enriquecidas. Sendo assim, técnicas de distribuição de ambientes virtuais multidisciplinares devem ser pesquisadas para possibilitar novas formas de interação (influenciar uma realidade participando de outra), quando existem conteúdos diferentes que se relacionam. 1.1. Objetivo Esta tese tem por objetivo identificar uma abordagem computacional/algorítmica que seja suficiente para suportar uma distribuição de ambientes virtuais multidisciplinares. Para atingir este objetivo, as seguintes metas foram definidas: a) Identificar uma arquitetura de distribuição que apresente eficácia na distribuição de ambientes virtuais. b) Escolher uma metodologia para o desenvolvimento de ambientes virtuais distribuídos, associada a um conjunto de algoritmos que aperfeiçoem esta distribuição. c) Realizar a implementação de protótipos, segundo a metodologia elaborada no 1 Do latim plexus que significa entrelaçado ou que possuem inter-relações. 2 Interdisciplinaridade: é a interação entre duas ou mais disciplinas, transferindo métodos de uma disciplina à outra. Por exemplo, quando os métodos da física nuclear são transferidos para a medicina, resultam no aparecimento de novos tratamentos de câncer. Outro exemplo de interdisciplinaridade se, ao estudar a pintura, relacionássemos o contexto histórico do Renascimento com os temas usados pelos artistas de então e sobre as técnicas empregadas por eles (GIRARDELLI, 2005). 3 Transdisciplinaridade: é a interação entre duas ou várias disciplinas proporcionando a criação de um corpo de elementos que compõem uma disciplina original, pois engloba e transcende o que passa por todas as disciplinas, reconhecendo o desconhecido e o inesgotável que estão presentes em todas elas, buscando encontrar seus pontos de interseção. Um bom exemplo de transdisciplinaridade são as grandes teorias explicativas do funcionamento das sociedades (GIRARDELLI, 2005). 2

item anterior, visando a sua validação. d) Comparar os protótipos, consolidando o melhor modelo para criação de um AVD multidisciplinar. e) Verificar a aplicabilidade do AVD desenvolvido. Durante o desenvolvimento deste trabalho, as seguintes estratégias foram adotadas, norteando a consolidação do objeto e metas propostas: a) Modelar dois ambientes virtuais relacionados a duas áreas distintas do conhecimento. Propõe-se como estudo de caso o Processo da Fotossíntese (Biologia e Química). b) Implementar protótipo com comunicação entre os dois ambientes, seguindo as etapas: 1) Comunicação unidirecional - apenas um ambiente interferindo no outro, com uma cópia de cada ambiente. 2) Comunicação bidirecional - cada ambiente interfere no outro, com uma cópia de cada ambiente. 3) Comunicação bidirecional - com um ambiente e n cópias de outro, possibilitando além da interferência de um em outro, também a replicação das informações nas cópias existentes. 4) Comunicação bidirecional - com n cópias de um ambiente e m cópias de outro. c) Por meio de comparação, justificar a escolha pela arquitetura de distribuição. d) Pesquisar as principais características dos AVDs (Ambientes Virtuais Distribuídos) avaliados para este trabalho. e) Implementar outros protótipos, comparando-os por meio de aspectos como a 3

latência de comunicação, escalabilidade e extensibilidade para medir o desempenho de cada um. f) Aplicar o sistema no ensino (estudantes, professores e pesquisadores), avaliando suas principais características de acordo com normas de qualidade de software educacional. 1.2. Ambientes Virtuais Distribuídos A Realidade Virtual pode empregar várias técnicas para reproduzir o mundo real e imaginário e possibilitar a manipulação e visualização de informações no computador como se fosse no mundo real. A complexidade desses ambientes virtuais aumenta na medida em que essas informações tornam-se comuns a uma série de usuários, ou seja, esses ambientes são distribuídos. Dessa forma, a Realidade Virtual possibilita interação entre usuários dispersos por meio do uso de ambientes virtuais distribuídos. Existem diversas plataformas que proporcionam essa distribuição como CORBA, RPC, Java/RMI (RAJ, 2004) e, para a modelagem do ambiente, também existem diversas linguagens em que se podem construir modelos virtuais como VRML, JAVA3D, OPENGL 4. Um AVD pode ser definido de forma simplificada como um sistema que permite vários usuários interagirem tanto com o ambiente quanto entre eles em tempo real, mesmo que estes estejam em diferentes localidades geográficas. Existem bibliografias que classificam os AVDs em dois tipos, considerando a dimensão do ambiente (OST, 2004): Espaços amplos e abertos, que simulam áreas relativamente grandes como cidades e desertos; Espaços pequenos, que se concentram na criação de modelos como salas ou edifícios. 4 OPENGL é uma biblioteca de rotinas gráficas e de modelagem 2D e 3D (WOO, 1999). 4

As primeiras experiências com ambientes virtuais distribuídos estão associadas a aplicações de simulações de batalhas militares feitas por universidades e órgãos governamentais dos Estados Unidos, como o Exército, a Marinha e o Departamento de Defesa (MACEDONIA, 2005). A área de aplicação dos AVD's é muito abrangente - treinamento (pilotos, militar), pesquisa, ensino à distância, comércio, cultura, engenharia. O computador apresenta um grande potencial como ferramenta de apoio ao ensino, que aliada às técnicas de Realidade Virtual e colaboração, pode enriquecer e valorizar a informação transmitida, simulando realidades, muitas vezes, fora do alcance dos alunos. Existe até mesmo um consenso entre os educadores/pesquisadores de que a RV oferece aos educadores uma nova maneira de ensinar e, aos alunos, uma forte motivação (DIZERO, 2004). A razão mais óbvia é que a RV é uma maneira diferente que habilita as pessoas a fazerem coisas, às quais não teriam acesso no mundo físico (KALAWSKY, 1993). 1.3. Contribuição do Trabalho Existem várias pesquisas na área de distribuição de ambientes virtuais, que vão desde pequenos ambientes que usam de simples replicação a técnicas de particionamento, métodos conhecidos como dead-reckoning que analisam o comportamento do objeto, a ambientes virtuais de grande escala, como é o caso do sistema de treinamento de guerra NPSNET (MACEDONIA, 2005), em que técnicas de gerenciamento de recursos apresentam maior importância. Todos estes ambientes e outros que serão apresentados neste estudo, simulam ou oferecem apenas um tipo de mundo (unidisciplinar) ou apenas uma área do conhecimento é explorada. Em alguns casos, há a existência de ambientes diferentes, porém dentro de um mesmo contexto. 5

Este trabalho pretende contribuir com a descrição de uma abordagem (arquitetura) que possibilite a distribuição de ambientes virtuais que simulem diferentes realidades. Além disso, essa arquitetura deve permitir que alterações feitas na realidade de um ambiente virtual possam ser propagadas, de tal maneira que altere a realidade de outros ambientes relacionados e vice-versa. No entanto, sistemas com estas características podem ser construídos de diversas formas ou metodologias (algoritmos). Para tanto, este trabalho contribuirá também com outras abordagens. No entanto, um AVD tem como requisito principal na avaliação de sua qualidade, a quantidade de clientes interagindo entre si ao mesmo tempo (escalabilidade). Portanto, este trabalho destacará a abordagem que melhor atenda a este requisito. 1.4. Organização da Tese O trabalho está dividido em oito capítulos, descritos resumidamente a seguir: O Capítulo 2 apresenta a caracterização dos Sistemas Distribuídos (software distribuído), plataformas mais conhecidas, visão geral e comparação de cada uma delas e definição da plataforma escolhida para uso neste trabalho. Ao final do capítulo, são abordadas características da arquitetura escolhida e a implementação usada, comparando-a com a especificação original. O Capítulo 3 apresenta a caracterização e metodologia de classificação de Ambientes Virtuais Distribuídos, relatando os AVDs mais importantes atualmente. No Capítulo 4, é descrita a arquitetura usada na distribuição dos Ambientes Virtuais. A implementação dos protótipos, criados para validar a arquitetura, é apresentada no Capítulo 5. O Capítulo 6 descreve o funcionamento do sistema, detalhando o estudo de caso multidisciplinar (Processo da Fotossíntese) O Capítulo 7 mostra uma análise dos protótipos desenvolvidos, avaliando-se os 6

aspectos representativos em seu desempenho. O Capítulo 8 apresenta as conclusões obtidas neste trabalho e as sugestões para trabalhos futuros que poderão ser desenvolvidos. Por último têm-se as referências bibliográficas aqui utilizadas. 7

CAPÍTULO II 2. SISTEMAS DISTRIBUÍDOS 2.1. Introdução Este capítulo apresenta as principais características dos sistemas computacionais distribuídos e detalha as plataformas de distribuição de software existentes no mercado e as diferenças entre elas. Neste capítulo, também é discutida a metodologia proposta nesta tese para utilização de uma arquitetura como suporte para as aplicações distribuídas e detalha a implementação escolhida. 2.2. O que é distribuição? Segundo Tanenbaum (1990), um sistema distribuído é uma coleção de computadores independentes que aparecem para os usuários do sistema como um único computador. Outra definição seria um sistema em que componentes de hardware e software localizados em computadores de uma rede se comunicam por meio de mensagens (COULOURIS, 2005). Portanto, um "Sistema Distribuído é aquele que roda em um conjunto de máquinas sem memória compartilhada, aparecendo como um único computador para seus usuários" (LAMPORT, 2003). 8

Havendo essa interação entre computadores, uma aplicação pode ser dividida em diferentes partes que se comunicam e cada parte pode ser processada em um sistema independente. Segundo Jalote (1994), sistema distribuído cria a sensação de que toda rede de computadores é um único sistema de tempo compartilhado (time-sharing), em vez de um grupo de máquinas independentes. Um sistema distribuído, segundo Eckhouse Jr. (1978), é formado por um conjunto de módulos, compostos pelo menos por processador-memória, interligados frouxamente por meio de um subsistema de comunicação de topologia arbitrária. Esse hardware deve oferecer facilidades de comunicação entre processadores e entre processos, os quais, cooperando sob um controle descentralizado, possibilitam a execução de programas de aplicação. A definição de sistema distribuído não implica a distribuição geográfica dos computadores que o compõem, pois a conexão fraca pode existir em ambientes confinados ou espalhados (KIRNER, 2005). Características de um sistema distribuído (SPECTOR, 1981 apud KIRNER, 1988): a) Multiplicidade de nós de processamento para permitir aumento no desempenho, tolerância a falhas (presença de defeitos ou interferências indevidas, que aparecem tanto em nível de hardware quanto de software), disponibilidade do sistema e/ou uso de dados geograficamente dispersos. b) Mecanismos de comunicação para suportar comunicações entre os componentes do sistema distribuído. c) Isolação entre componentes para suportar controle de diferentes entidades administrativas, tolerância a falhas e disponibilidade. 9

d) Possibilidade de expansão para permitir crescimento incremental. e) Mecanismos de detecção de erros para obter disponibilidade e tolerância a falhas. f) Redundância para obter disponibilidade e tolerância a falhas, pois, uma vez que os erros tenham sidos detectados, a redundância é que permitirá a recuperação. g) Dispersão geográfica para permitir que os recursos sejam separados geograficamente. O sistema deve possuir, obrigatoriamente, as características a e b mencionadas acima, e excepcionalmente, algumas das outras características. Outra caracterização de sistema distribuído define outros ingredientes básicos (ENSLOW JR, 1974 apud KIRNER, 1988): a) Multiplicidade de recursos de uso geral (físicos e lógicos), cuja concessão a tarefas específicas deve ocorrer de forma dinâmica. b) Distribuição física desses recursos, interagindo por meio de uma rede de comunicação. c) Existência de um sistema operacional de alto nível que unifica e integra o controle dos componentes distribuídos. Uma outra forma de caracterizar os sistemas distribuídos baseia-se em três itens (PARDO, 1979 apud KIRNER, 1988): a) O hardware básico de um sistema distribuído consistirá de uma rede de computadores. b) A arquitetura física do sistema de comunicação apresenta pouca importância do ponto de vista lógico, podendo impor maior impacto em questões como desempenho. 10

c) Software é a palavra-chave em sistemas distribuídos. 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. Aspectos de Tolerância a Falhas Pelo fato de sistemas distribuídos possuírem múltiplas partes de hardware e de software funcionando conjuntamente, as chances de alguma dessas partes falhar é bem maior do que num sistema simples (KIRNER, 1988). Um sistema distribuído pode apresentar diversos tipos de falhas provenientes de vários fatores. Para propiciar confiabilidade a um sistema distribuído é necessário que apresente tolerância a falhas. Em sistemas tolerantes a falhas, as interferências indevidas podem ser superadas por meio de redundâncias (SIEWIOREK, 1984). A redundância pode ser temporal e/ou física. A redundância física consiste em ter-se elementos repetidos capazes de executar a mesma operação. A redundância temporal corresponde à determinação de um resultado por meio de execuções repetidas de uma mesma operação pelo mesmo elemento, usando eventualmente métodos diferentes (KIRNER, 1988). 2.2.1 Middleware Middleware é um termo que implica uma camada de software que proporciona uma abstração e assim esconde a heterogeneidade da rede, hardware, sistema operacional e linguagens de programação usadas. Seu principal objetivo é facilitar o desenvolvimento de aplicações e sistemas distribuídos e o seu beneficio é ocultar do programador diferenças entre: - Plataformas de hardware de sistemas operacionais. 11

- Bibliotecas de comunicação. - Protocolos de comunicação. - Formatação de dados. - Linguagens de programação. - Modelos de programação. O Middleware possui a seguintes características: Tem de estar disponível em diversas máquinas. As transferências têm de ser fiáveis, ou seja, tem de existir garantia de entrega e recebimento. A diversidade das estruturas de comunicação, ou seja, uma aplicação pode se comunicar com outra aplicação ou enviar uma única mensagem para vários destinos. 2.3. Plataformas de distribuição de software Três dos mais populares paradigmas de objetos distribuídos são (RAJ, 2004): - Common Object Request Broker Architecture CORBA da OMG. - Java/Remote Method Invocation - Java/RMI da JavaSoft. - Distributed Object Component Model DCOM da Microsoft. 2.3.1 CORBA CORBA é a especificação de uma arquitetura para objetos distribuídos e heterogêneos. O padrão CORBA é uma solução aberta de objetos distribuídos desenvolvido pela OMG (Object Management Group) para se tornar um padrão no mercado. Recebe destaque por ser independente de linguagem e fabricante, possibilitando que objetos de sistemas distribuídos troquem mensagens entre si de forma transparente, não importando onde eles estejam, em que plataforma ou sistema operacional estejam rodando, em que linguagem 12

de programação foram implementados e até mesmo qual protocolo de comunicação utilizam (LIMA, 2004). 2.3.1.1. Histórico CORBA começou a ser desenvolvido em 1989, quando um grupo de empresas reuniu-se em uma organização (OMG), com o objetivo de especificar uma arquitetura global e normas para permitir o trabalho conjunto de componentes de diferentes origens. A idéia era aproveitar os benefícios do paradigma da orientação a objeto, principalmente a noção de encapsulamento dos dados e da implementação de um objeto por meio da sua interface. O CORBA 1.1 foi inicialmente implementado em 1991, como um modelo que permite a ativação de métodos de objetos por meio de um elemento intermediário chamado ORB (Object Request Broker), situado entre o objeto (que se encontra na camada de aplicação do modelo Open System Interconnection OSI) e o sistema operacional, com a possibilidade de comunicar-se em uma rede. Em 1994, foi desenvolvido o CORBA 2.0, ao qual foi adicionado o Internet Inter-ORB Protocol (IIOP). O IIOP permitiu que objetos fossem desenvolvidos em implementações diferentes, e assim, CORBA se tornou uma solução para adquirir a interoperabilidade entre objetos que não ficam presos a um padrão específico (OMG, 2004). 2.3.1.2. Características A arquitetura definida para CORBA possui um alto nível de abstração, permitindo que a implementação do cliente e do servidor possa ser feita em qualquer linguagem e que os objetos se comuniquem de forma totalmente transparente por meio de um barramento de software. Isso só é possível porque os objetos têm suas interfaces descritas em uma 13

linguagem padrão, chamada de Interface Definition Language (IDL). A função da IDL é descrever as interfaces das implementações de objetos, que são acessadas por seus clientes. Foi definida pela OMG uma arquitetura denominada OMA (Object Management Architecture) para realizar a integração entre aplicações. Enquanto CORBA permite a interoperabilidade entre objetos, a OMA agrupa um conjunto de objetos CORBA em serviços e facilidades, que oferecem suporte para o desenvolvimento de aplicações que usam objetos CORBA (PAULOVICH, 2004). Tudo na arquitetura CORBA depende de um Object Request Broker (ORB). O ORB atua como um Object Bus central sobre cada objeto CORBA, interagindo transparentemente com outros objetos localizados no mesmo computador ou remotamente. Cada objeto servidor CORBA tem uma interface e expõe um grupo de métodos. Para solicitar um serviço, um cliente adquire uma referência de objeto para o objeto servidor CORBA. O cliente pode fazer pedidos de métodos na referência de objeto como se o objeto servidor residisse no espaço de endereço do cliente. O ORB é responsável por achar a implementação de objetos CORBA, preparando-a para receber e enviar pedidos e carregar a resposta de volta ao cliente. Uma vez que CORBA é somente uma especificação, pode ser usada em diversas plataformas de sistemas operacionais de mainframes a UNIX, de máquinas Windows a aparelhos handheld, desde que haja uma implementação ORB para aquela plataforma (NEVES JÚNIOR, 2004). 2.3.2 DCOM DCOM, freqüentemente chamado COM no fio, suporta objetos remotos rodando em um protocolo chamado Object Remote Procedure Call (ORPC). Essa camada ORPC é 14

construída no topo do DCEs RPC 5 e interage com serviços em tempo de execução do COM. Um servidor DCOM é um corpo de códigos que é capaz de servir objetos de um tipo particular em tempo de execução. Cada objeto servidor DCOM pode suportar múltiplas interfaces, cada uma representando um comportamento diferente do objeto. Um cliente DCOM faz requisições por meio dos métodos expostos em um servidor DCOM, adquirindo um ponteiro para uma das interfaces do objeto servidor. O objeto cliente então começa a chamar os métodos expostos do objeto servidor, por meio de um ponteiro de interface adquirida como se o objeto servidor residisse no espaço de endereço do cliente. Já que a especificação COM está no nível binário, permite que componentes servidores DCOM sejam escritos em diversas linguagens de programação como C++, Java, Object Pascal (Delphi), Visual Basic e até COBOL. Desde que a plataforma sustente serviços COM, DCOM pode ser usado nesta plataforma. 2.3.3 JAVA/RMI Java/RMI depende de um protocolo chamado Java Remote Method Protocol (JRMP). Java depende muito da Serialização de Objetos, que permite aos objetos serem reunidos (ou transmitidos) como uma fila. Como Java Object Serialization é específica para Java, ambos os objetos servidores Java/RMI e os objetos cliente têm que ser escritos em Java. Cada objeto servidor Java/RMI define uma interface, que pode ser usada para acessar os objetos servidores de fora da atual Java Virtual Machine (JVM) e em outras máquinas JVM. A interface expõe um grupo de métodos, que são indício dos serviços oferecidos pelo objeto servidor. Para um cliente localizar um objeto servidor pela primeira vez, RMI depende de um mecanismo chamado RMIRegistry, que roda na máquina servidora e armazena informações 5 DCE (Distributed Computing Environment) e RPC (Remote Procedure Call): são tecnologias de computação distribuída (RICCIONI, 2000). 15

sobre objetos servidores disponíveis. Um cliente Java/RMI adquire uma referência de objeto para um objeto servidor Java/RMI, fazendo um lookup para uma referência de Objeto Servidor e invoca métodos no Objeto Servidor como se o objeto servidor Java/RMI residisse no espaço de endereço do cliente. Objetos servidores Java/RMI são chamados usando URLs, e para um cliente adquirir uma referência de objeto servidor deveria especificar a URL do objeto servidor, como é feito com a URL para uma página HTML. Já que Java/RMI depende de Java, pode ser usada em diversas plataformas de sistemas operacionais de mainframes a UNIX, de máquinas Windows a aparelhos handheld, desde que haja uma implementação de Java Virtual Machine (JVM) para aquela plataforma. Além de JavaSoft e Microsoft, muitas outras companhias têm anunciado portas de Java Virtual Machine. 2.4. Comparação entre plataformas de distribuição De acordo com Raj (2004), é necessário implementar alguma aplicação para comparar plataformas de distribuição, pois as principais diferenças estão no desempenho, na portabilidade, na facilidade de construção dos objetos e nos resultados obtidos por meio de testes. 2.4.1 Uma Aplicação Para construir uma aplicação distribuída é necessário fazer um planejamento que segue o modelo tradicional de projeto definido dentro da Engenharia de Software 6. Porém, a partir da extração de dados (engenharia de requisitos), alguns aspectos são agregados. Na camada Arquitetura é necessária uma definição do meio em que o sistema irá funcionar, apesar de o meio suportar heterogeneidade de software e hardware. Na camada Projeto, os itens mais importantes a serem adicionados são: 6 Métodos e técnicas para construção de um software (LOPES, 2002). 16

- Função da aplicação cliente. - Função da aplicação servidora. - Definição da interface a ser usada entre cliente e servidor. Para prover resultados na avaliação das três plataformas citadas anteriormente, serão considerados os mecanismos de implementação de Interfaces (IDL), modelo de cliente e modelo de servidor. 2.4.1.1. A interface IDL Toda vez que o cliente precisa de algum serviço de um objeto distribuído remoto, ele invoca um método implementado pelo objeto remoto. O serviço que o objeto distribuído remoto (servidor) oferece é encapsulado como um objeto e a interface do objeto remoto são escritos em uma Linguagem de Definição de Interface (IDL). As interfaces especificadas no arquivo IDL servem como um contrato entre um objeto servidor remoto e seus clientes. O cliente pode, dessa forma, interagir com esses objetos servidores remotos, invocando métodos definidos na IDL. DCOM O arquivo IDL DCOM mostra que o servidor DCOM implementa interface dupla. COM sustenta invocação estática e dinâmica de objetos. É um pouco diferente de como CORBA faz por meio da sua Interface de Invocação Dinâmica (DII) ou Java faz com Reflection. Para a invocação estática funcionar, o compilador Microsoft IDL (MIDL) cria a procuração e o código stub, quando roda no arquivo IDL. Eles são gravados no registro do sistema para permitir melhor flexibilidade do seu uso. Esse é o método fundamental (vtable) de invocação de objetos. Para a invocação dinâmica funcionar, objetos COM implementam uma interface chamada IDispatch. Assim como CORBA ou Java/RMI, para permitir invocação dinâmica é necessário existir algum caminho para descrever os métodos de objetos e seus parâmetros. Type Libraries são arquivos que descrevem o objeto, e 17

COM fornece interfaces, obtidas por meio da interface IDispatch para questionar uma type library do Objeto. Tanto CORBA como Java/RMI sustentam herança múltipla em nível de IDL ou de interface. Uma diferença entre IDLs CORBA (e Java/RMI) e IDLs COM é que CORBA (e Java/RMI) podem especificar exceções nas IDLs, enquanto que DCOM não pode. Em CORBA, o compilador IDL gera tipo de informação (type information) para cada método em uma interface e a armazena no Repositório de Interface Interface Repository (IR). Um cliente pode, dessa forma, questionar o IR para pegar informação em tempo de execução sobre uma interface particular e, então, usar aquela informação para criar e invocar um método no objeto servidor remoto CORBA dinamicamente, por meio da Interface de Invocação Dinâmica (DII). Similarmente, do lado do servidor, a Interface Reduzida Dinâmica (DSI) permite a um cliente invocar uma operação de um objeto servidor remoto CORBA, que não tem nenhum conhecimento em tempo de compilação do tipo de objeto que está implementando. Java/RMI Note que, ao contrário dos outros dois, Java/RMI usa um arquivo.java para definir sua interface remota. Essa interface vai garantir consistência de tipo entre o cliente Java/RMI e o objeto servidor Java/RMI. Todo objeto servidor remoto em Java/RMI tem que estender a classe java.rmi.remote. Similarmente, qualquer método que possa ser remotamente invocado em Java/RMI projeta uma java.rmi.remoteexception, que é uma superclasse das muitas classes específicas de exceções RMI. Para invocar um método remoto, o cliente faz uma chamada para o cliente proxy (procurador). O cliente do lado proxy coloca os parâmetros da chamada dentro de uma mensagem de pedido e invoca um protocolo conectado (wire) como IIOP (em CORBA) ou ORPC (em DCOM) ou JRMP (em Java/RMI) para despachar a mensagem para o servidor. No lado servidor, o protocolo wire entrega a 18

mensagem para o lado servidor stub. O lado servidor stub então desfaz a mensagem e chama o método atual no objeto. Tanto em CORBA como em Java/RMI, o cliente stub é chamado de stub ou proxy e o servidor stub é chamado skeleton. Em DCOM, o cliente stub é referido como proxy e o servidor stub é referido como stub. 2.4.1.2. Objeto Cliente Cliente DCOM O cliente DCOM primeiramente cria um ponteiro para o objeto servidor. A palavra-chave new aqui instancia o objeto servidor DCOM. Isto leva o Microsoft JVM a usar o CLSID para fazer a chamada CoCreateInstance ( ). Cliente CORBA O cliente CORBA vai primeiramente ter que iniciar o CORBA ORB fazendo uma chamada para ORB.init( ). Ele então instancia um objeto servidor CORBA, unindo com uma referência remota ao objeto servidor. Tanto o Visibroker da Inprise quanto o Orbix da Iona, têm um método bind( ) para unir e obter uma referência de objeto servidor. Cliente Java/RMI O cliente Java/RMI primeiro instala um administrador de proteção, antes de fazer qualquer chamada remota. Isto é feito por uma chamada para System.setSecurityManager( ). O RMISecurityManager provido pelo JavaSoft é uma tentativa do JavaSoft de escrever sua própria implementação. Entretanto, JavaSoft não força o uso do RMISecurityManager pode-se escrever um próprio administrador de proteção e instalá-lo quando quiser. 2.4.1.3. Objeto Servidor Servidor DCOM Todas as classes, que são requeridas para Java/COM, são definidas no pacote com.ms.com. As classes e os métodos são declarados como public para que eles possam ser acessíveis de fora do pacote. 19

Também note que o CLSID é especificado e declarado como private. É usado pelo COM para instanciar o objeto por meio do CoCreateInstance ( ), quando o cliente DCOM faz um novo remotamente. Servidor CORBA Todas as classes que são requeridas para CORBA são definidas no pacote org.omg.corba. O objeto servidor CORBA estende uma classe skeleton gerada pelo nosso compilador IDL CORBA. As classes e os métodos são declarados como public para que eles possam ser acessíveis de fora do pacote. Servidor Java/RMI Todas as classes que são requeridas para Java/RMI são definidas no pacote java.rmi. O objeto servidor Java/RMI mostrado estende a classe UnicastRemoteObject, que tem todos os métodos remotos definidos do Java/RMI. 2.4.1.4. Principais programas do servidor Servidor Principal CORBA A primeira coisa a ser feita pelo programa principal é iniciar o ORB CORBA usando ORB.init( ). Um Object Adapter (OA) está no topo do ORB e é responsável por conectar a implementação do objeto servidor CORBA com o ORB CORBA. Adaptadores de Objeto fornecem serviços como geração e interpretação das referências de objeto, invocação de método, ativação e desativação de objeto, e mapeamento de referências de objetos para implementações. É necessário iniciar Basic Object Adapter (BOA Adaptador de Objeto Básico) ou o Portable Object Adapter (POA Adaptador de Objeto Portável), dependendo do que o ORB sustenta. Servidor Principal Java/RMI O cliente Java/RMI terá primeiramente que instalar um administrador de segurança, antes de fazer qualquer chamada remota. Isso é feito com uma chamada para System.setSecurityManager( ). Então, o objeto servidor Java/RMI com o código a seguir permanece até parar de funcionar (desligar). 20

Servidor Principal DCOM Não é fornecido um programa principal para a implementação do servidor DCOM. O apoio sobre Java no Internet Explorer roda como um servidor in-process (em processo) e servidores in-process não podem normalmente ser remotos, usando o Windows NT 4.0 COM Distribuído (DCOM). 2.4.1.5. Conclusão As arquiteturas CORBA, DCOM e JAVA/RMI oferecem mecanismos para uma transparente invocação e acesso a objetos remotos distribuídos. Embora os mecanismos que eles empregam para conseguir possam ser diferentes, a aproximação que cada um deles leva é mais ou menos similar. As tabelas, a seguir (RAJ, 2004), demonstram que muitas características são similares ou se equivalem. Isso retrata que vários aspectos da comparação são iguais e, portanto, a escolha de uma plataforma para distribuição restringe muitas vezes a especificidade do projeto. As Tabelas 2.1.(a), 2.1.(b), 2.1.(c), 2.1.(d) e 2.1.(e) apresenta as principais diferenças entre DCOM, CORBA e JAVA/RMI. Cabe novamente ressaltar que, muitas características são iguais. Características Suporte a múltiplas heranças Tabela 2.1.(a) Diferenças entre DCOM, CORBA e JAVA/RMI (RAJ, 2004). Plataformas de Distribuição DCOM CORBA JAVA/RMI Suporta múltiplas Suporta múltiplas Suporta múltiplas interfaces para objetos heranças no nível de heranças no nível de e usa o método interface (não é interface. QueryInterface ( ) necessário recompilar para navegar entre um projeto para interfaces. Isto acrescentar alguma significa que um funcionalidade). Cliente Proxy carrega dinamicamente stubs de servidor múltiplo na camada remota dependendo do número de interfaces. 21

Tabela 2.1.(b) Diferenças entre DCOM, CORBA e JAVA/RMI (RAJ, 2004). Características Objeto Global Plataformas de Distribuição DCOM CORBA JAVA/RMI Todo objeto Toda interface é Toda objeto servidor implementa herdada de implementa IUnknown. CORBA.Object. java.rmi.remote Localizador de objetos Localizador de Interfaces Referência ao Objeto Servidor Registro de Objetos Exclusivamente identifica um objeto servidor remoto por meio de seu ponteiro de interface, que serve como alça do objeto em tempo de execução. Exclusivamente identifica uma interface usando o conceito de Interface IDs (IID) e identifica uma implementação nomeada do objeto servidor usando o conceito de Classe IDs (CLSID), o mapa do qual é achado no registro. A geração da referência do objeto servidor remoto é executada no protocolo wire pelo Exportador de Objeto. Tarefas como registro de objeto, skeleton instantiation etc, são executadas explicitamente pelo programa servidor ou dinamicamente dirigidas pelo sistema COM em tempo de execução. Exclusivamente identifica objetos servidores remotos por meio de referências de objeto (objref), que servem como alça do objeto em tempo de execução. Exclusivamente identifica uma interface usando o nome de interface e identifica uma implementação nomeada do objeto de servidor pelo seu mapeamento para um nome no Repositório de Implementação (Implementation Repository). A geração da referência do objeto servidor remoto é executada no protocolo wire pelo Exportador de Objeto. O construtor implicitamente executa tarefas comuns como registro de objeto, skeleton instantiation, etc. Exclusivamente identifica objetos servidores remotos com o ObjID, que serve como alça do objeto em tempo de execução. Exclusivamente identifica uma interface usando o nome de interface e identifica uma implementação nomeada do objeto servidor pelo seu mapa para uma URL no Registro. A geração da referência do objeto servidor remoto é executada pela chamada ao método UnicastRemoteObject. ExportObject. O RMIRegistry executa tarefas comuns como registro de objeto por meio da classe Naming. 22