Heres Edison Valdivieso Tobar Neto DEFINIÇÃO DE UM MECANISMO DE COMUNICAÇÃO PARA AQUISIÇÃO DE MÍDIAS DISTRIBUÍDAS EM UMA REDE LOCAL

Heres Edison Valdivieso Tobar Neto DEFINIÇÃO DE UM MECANISMO DE COMUNICAÇÃO PARA AQUISIÇÃO DE MÍDIAS DISTRIBUÍDAS EM UMA REDE LOCAL Palmas 2003

Heres Edison Valdivieso Tobar Neto DEFINIÇÃO DE UM MECANISMO DE COMUNICAÇÃO PARA AQUISIÇÃO DE MÍDIAS DISTRIBUÍDAS EM UMA REDE LOCAL Monografia apresentada como requisito parcial da disciplina Prática de Sistemas de Informação I (Estágio) do curso de Sistemas de Informação, orientada pela Profª. M.Sc. Madianita Bogo e coorientada pelo Prof. M.Sc. Fabiano Fagundes Palmas 2003

HERES EDISON VALDIVIESO TOBAR NETO DEFINIÇÃO DE UM MECANISMO DE COMUNICAÇÃO PARA AQUISIÇÃO DE MÍDIAS DISTRIBUÍDAS EM UMA REDE LOCAL Monografia apresentada como requisito parcial da disciplina Prática de Sistemas de Informação I (Estágio) do curso de Sistemas de Informação, orientada pela Profª. M.Sc. Madianita Bogo e coorientada pelo Prof. M.Sc. Fabiano Fagundes Aprovado em Dezembro de 2003 BANCA EXAMINADORA Profª. M.Sc. Madianita Bogo Centro Universitário Luterano de Palmas Prof. M.Sc. Eduardo Kessler Piveta Centro Universitário Luterano de Palmas Prof. M.Sc. Fabiano Fagundes Centro Universitário Luterano de Palmas Palmas 2003

Há duas formas de passar pela vida: Uma é acreditar que não existe milagre. A outra é acreditar que todas as coisas são um milagre. (Albert Einstein)

AGRADECIMENTOS Agradeço única e exclusivamente a Deus pela minha vida e pela vida dos que de mim são próximos, pela força a mim concedida para que não desistisse nunca deste trabalho, embora quase o tenha feito. Agradeço principalmente por ter colocado na minha vida pessoas maravilhosas como meus pais e meus irmãos. Agradeço a Deus também, por permitir que eu conhecesse e contracenasse no palco da vida com pessoas como meu papito Fabiano, meu ex-papito Augusto e minha mamita Mádia, que muito me ensinaram sobre responsabilidade e perseverança, além de terem me dado muitíssimos e merecidos puxões de orelha. Também não posso deixar de agradecer a Deus, pelas outras pessoas, não menos importantes na minha vida, os meus amigos: Alessandro Pau Véi; Álvaro; Anderson; Aureliano; Bibiu; Brito; Chicão; Danilão; Devegili; Fran; Jansle; Jânio Jota-Erre; Kênia; Ludimila; Maikim; Marcus; Nalvinha (Minha namoradinha querida); Paraíso; Paulo; Pingas; Pivas; Polly; Tia Neida; Thilfa; Victor; Vivi; Xambioá; Zito, que de alguma forma direta ou indireta vieram a contribuir para a realização deste trabalho. Agradeço pelos bons professores e coordenadora do curso de Sistema de Informação, são eles responsáveis pelo altíssimo nível do curso e por grande parte dos meus conhecimentos adquiridos. E finalizando, agradeço a Deus também pelo término deste trabalho, pela minha aprovação e pela oportunidade de viver a cada dia um novo dia! Obrigado Senhor!

SUMÁRIO 1 INTRODUÇÃO... 10 2 REVISÃO DA LITERATURA... 12 2.1 APLICAÇÕES DISTRIBUÍDAS... 12 2.1.1 Java RMI (Remote Method Invocation)... 15 2.1.2 CORBA (Common Object Request Broker Architecture)... 17 2.1.3 DCOM (Distributed Common Object Model)... 19 2.2 SISTEMAS MULTIMÍDIA... 21 2.2.1 Características das mídias... 22 2.2.2 Tipos de Mídias... 25 2.2.2.1 Texto... 25 2.2.2.2 Gráficos... 25 2.2.2.3 Imagens... 26 2.2.2.4 Vídeos... 26 2.2.2.5 Áudio... 27 3 MATERIAL E MÉTODOS... 28 3.1 LOCAL E PERÍODO... 28 3.2 MATERIAIS... 28 3.2.1 Software... 28 3.2.2 Hardware... 29 3.2.3 Fontes Bibliográficas... 29 3.3 METODOLOGIA... 29 4 RESULTADOS E DISCUSSÃO... 30 4.1 DESCRIÇÃO DO PROJETO... 30 4.2 ARQUITETURA DO MECANISMO PROPOSTO... 30 4.3 TECNOLOGIA DO MECANISMO DE COMUNICAÇÃO... 32 4.4 FUNCIONAMENTO BÁSICO... 34 4.4.1 Cenários... 35

5 CONCLUSÕES... 38 5.1 CONSIDERAÇÕES FINAIS... 38 5.2 RECOMENDAÇÕES PARA TRABALHOS FUTUROS... 39 6 REFERÊNCIAS BIBLIOGRÁFICAS... 40

LISTA DE FIGURAS Figura 1: Arquitetura multicamadas dos sistemas distribuídos (RICCIONI, 2000).... 13 Figura 2: Arquitetura Java/RMI (RICCIONI, 2000)... 16 Figura 3: Principais elementos da arquitetura CORBA (TRINTA, 2000)... 17 Figura 4: Arquitetura de comunicação em CORBA (CARDOZO, 2002).... 19 Figura 5: Arquitetura de comunicação do DCOM (CARDOZO, 2002)... 20 Figura 6: Arquitetura de comunicação HTSPN Player/mídias.... 31 Figura 7: Banco de Dados de controle das mídias.... 35 Figura 8: Cenário de funcionamento do mecanismo de comunicação remota... 36

RESUMO Atualmente, presencia-se um crescimento na utilização de aplicações distribuídas e dos sistemas multimídia, juntamente com a popularização da Internet e das redes locais. Com as facilidades e mobilidade que as redes proporcionam e com as características de interação dos sistemas multimídia, surgiu uma nova fase de sistemas computacionais: a da utilização dos Sistemas Multimídia Distribuídos. O Laboratório de Multimídia e Hipermídia iniciou, no semestre de 2003/02, um projeto para um sistema de sincronização multimídia, no qual existe um módulo player, que possibilitará a exibição de arquivos multimídia distribuídos em uma rede. Para que o player possa copiar as mídias de máquinas remotas, é necessária a existência de um mecanismo de comunicação distribuída. Assim, esse trabalho apresenta a proposta de um mecanismo para a troca de mensagens remotas, descrevendo o seu funcionamento básico e os componentes a serem implementados. Além disso, serão apresentadas tecnologias para a comunicação remota entre esses componentes, sendo sugerida uma delas para a implementação do mecanismo proposto. Palavras chave: Sistemas Multimídia Distribuído, CORBA, JRMI, DCOM.

ABSTRACT Currently, is perceived an increase in use of distributed applications and the multimedia systems, together with the use of the Internet and local networks. With the easiness and mobility that the networks provide and the interaction characteristics of multimedia systems, appeared a new phase of computational systems: the use of Distributed Multimedia Systems. The Multimedia e Hypermedia Laboratory began, in 2003/2, a project of a multimedia synchronization system, it has a player component that will make possible the execution of distributed medias files in a network. So, the player component can copy the medias from remote machines, it needs to have a distributed communication mechanism. Thus, this work presents the proposal of a mechanism for the remote messages passing, describing its basic functioning and the components to will implemented. Moreover, this work presents technologies for remote communication between these components, being indicated one of them for the proposal mechanism implementation. Keywords: Distributed Multimedia Systems, CORBA, JRMI, DCOM.

10 1 INTRODUÇÃO As aplicações distribuídas vêm aumentando o número de adeptos a essa tecnologia, o que faz com que ela se torne uma área muito procurada pelas empresas de softwares no que se refere a pesquisas e desenvolvimento. Outra tecnologia que já vem ganhando espaço há algum tempo é a dos sistemas multimídia, devido as suas características de estímulo audiovisual, dinamismo de conteúdo e provimento de interação com o usuário final. Atualmente, vários sistemas utilizam essas duas tecnologias a fim de conseguir maior sucesso entre os usuários. Esses novos tipos de sistemas que, além de possibilitar a distribuição dos módulos em diversos computadores, permitem prover conteúdo multimídia, são chamados de Sistemas Multimídia Distribuídos. Como prova de que estão conseguindo atingir o usuário de informática, pode-se citar os comunicadores (bate-papos), ferramentas de videoconferência, trabalho em grupo e compartilhadores de arquivos. O Laboratório de Multimídia e Hipermídia do curso de Sistemas de Informação do Centro Universitário Luterano de Palmas, atualmente, está trabalhando em um projeto de edição e apresentação de mídias, denominado Editor e Player de Sistemas Multimídia Corretamente Sincronizados, que além de vários outros, contém um módulo chamado HTSPN Player, o qual é responsável por exibir conteúdo multimídia de forma sincronizada, utilizando para isso Redes de Petri. O módulo do player deve prover, num futuro próximo, possibilidade de exibição de conteúdo multimídia distribuída. Nesse ponto encontra-se a proposta do trabalho: definir um mecanismo de comunicação para a busca de mídias, distribuídas em várias máquinas em uma rede local, informando também qual a melhor tecnologia a ser utilizada para a troca de mensagens remotas, na implementação.

11 Para definir qual tecnologia seria utilizada na implementação do mecanismo, foram analisadas três muito utilizadas atualmente: JRMI, CORBA e DCOM. Um dos motivos para a escolha dessas três tecnologias foi o fato de trabalharem com orientação a objetos, já que o HTSPN Player será implementado com Java. Para a escolha da tecnologia a ser utilizada, foram analisados critérios como forma de transferência de dados, facilidade de implementação, disponibilidade de ferramentas e documentação, portabilidade, entre outras, em cada uma das tecnologias. Após a análise, de acordo com os critérios citados, a escolhida para a implementação foi o CORBA. Além da definição da tecnologia que será utilizada na implementação foi apresentado o funcionamento básico do mecanismo proposto e definidos os componentes básicos deste. Esses componentes são: Processo Cliente de Mídia, que fará a solicitação da mídia; Servidor de Mídia, que terá responsabilidade de envio de mídias a um processo cliente; Banco de Dados de Mídias Locais, cuja função será a de manter dados das mídias que se encontram na mesma maquina que ele; e o pacote ComunicaPlayer, responsável pelos métodos que serão utilizados pelo player para a comunicação com os outros componentes do sistema. O trabalho está dividido da seguinte maneira: a seção 2 apresenta os conceitos das tecnologias que poderiam ser usadas na implementação da comunicação remota, bem como outros conteúdos importantes para a definição do mecanismo de comunicação proposto; a seção 3 cita o material e os métodos utilizados para o desenvolvimento do trabalho; a seção 4 apresenta a descrição do mecanismo proposto, a tecnologia a ser utilizada para a implementação e um exemplo do funcionamento; a seção 5 apresenta as considerações finais e algumas propostas para a continuação do trabalho; e por fim, a seção 6 lista as bibliografias utilizadas como base nas pesquisas.

12 2 REVISÃO DA LITERATURA 2.1 Aplicações Distribuídas As aplicações distribuídas recebem esse nome pela forma com que seus objetos estão dispostos e realizam as suas tarefas. Esses módulos são distribuídos e podem executar em um mesmo computador ou estarem dispostos em computadores distintos em uma rede local ou em redes diferentes, como na Internet. Os módulos são ligados entre si por um mecanismo de comunicação que torna a distribuição transparente, isto é, o usuário não percebe que os módulos estão comunicando-se remotamente. Existem várias definições para aplicações distribuídas, uma delas é apresentada por RICCIONI (2000) que diz o seguinte: Aplicação distribuída é uma coleção de computadores autônomos ligados por uma rede, com software projetado para produzir uma facilidade de computação integrada. Atualmente, percebe-se um aumento considerável na utilização de sistemas distribuídos. Dentre algumas aplicações para esse tipo de sistemas, as que mais se destacam são: aplicações para comunicação entre pessoas como ICQ, MSN Messenger, AOL Messenger, Yahoo Messenger, entre outros; compartilhadores de arquivos ou P2P Peer to Peer, como Kazaa, Morpheus, imesh, entre outros; ferramentas para teleconferências, como Microsoft NetMeeting, MSN Messenger, entre outras; e trabalho cooperativo em grupo, como Habanero (2003) Macedo (1999). Segundo Trinta (2000), algumas características que tornam os sistemas distribuídos viáveis e implementáveis são as seguintes:

13 compartilhamento de recursos: os módulos são recursos que atendem a vários outros módulos. Nessa relação, cada módulo gerencia seu compartilhamento; abertura: a disponibilidade de interfaces públicas e bem definidas permite uma maior flexibilidade para eventuais mudanças nas aplicações, através da inserção ou retirada de módulos de um sistema distribuído; concorrência: as tarefas podem ser realizadas por vários módulos, concorrentemente, com objetivo de melhoria de desempenho; escalabilidade: diz respeito à capacidade que o sistema tem de adaptar-se facilmente a uma carga crescente de recursos e serviços, podendo ser alcançada através da replicação e distribuição de cargas entre os componentes de uma aplicação; tolerância à falhas: é a continuidade do funcionamento do sistema, mesmo ocorrendo alguma falha em um dos seus componentes. A redundância de alguns recursos pode ser utilizada, para que determinadas tarefas, essenciais à aplicação, possam ser realocadas entre os mesmos; transparência: a localização de módulos que compõem a aplicação, e a sua conseqüente distribuição, não são percebidas pelos usuários do sistema. A figura 1 apresenta a arquitetura multicamadas dos sistemas distribuídos segundo a visão de (RICCIONI, 2000). Figura 1: Arquitetura multicamadas dos sistemas distribuídos (RICCIONI, 2000).

14 Segundo RICCIONI (2000), as aplicações distribuídas possuem três camadas lógicas: camada de apresentação: geralmente centradas nas estações, embora na Web algumas de suas funções fiquem a cargo dos servidores de dados ou de aplicação; camada de aplicação: camada que se responsabiliza pelas regras do negócio e por gerir o fluxo de dados. Geralmente ficam instalados nos servidores de aplicação; camada de dados: tem responsabilidade de controle dos dados. Uma aplicação distribuída, para implementar a comunicação remota entre seus módulos, utiliza chamadas remotas ou interfaces comuns. Tais artifícios são capazes de reconhecer a localização dos respectivos objetos servidores e tratar da intercomunicação entre o objeto-cliente e objeto-servidor de um serviço (middleware) (VASCONCELOS, 2002). As chamadas remotas são tentativas de acessar funções ou métodos de outros objetos, componentes, programas ou módulos que não se encontram na mesma máquina da aplicação realizadora das chamadas. Uma chamada remota pode ser visualizada como um pedido de execução local de algo que não está localizado localmente. Esse pedido deverá chegar ao seu destino através de uma rede, utilizando para isso mecanismos RPC (Remote Procedure Call), que permitem a uma aplicação cliente fazer chamada a procedimentos em servidores remotos da mesma forma em que chamadas são feitas localmente (RICCIONI, 2000). Neste trabalho serão utilizadas técnicas de programação orientada a objetos para a implementação de aplicações distribuídas, devido às inúmeras vantagens desse paradigma em relação ao de programação estruturada (CAMARÃO & FIGUEIREDO, 2003) e também pela escolha da linguagem de implementação do HTSPN Player (PRESTES, 2003), o Java. Nas aplicações distribuídas orientadas a objetos, utilizam-se vários mecanismos para a comunicação entre seus objetos clientes e objetos servidores, e a evocação dos métodos remotos de um objeto servidor a partir de objetos cliente. Tais técnicas (ORB, RPC, DCE, Stubs, etc.) serão explicadas a seguir junto com as arquiteturas que as utilizam.

15 Dentre as arquiteturas que provêm formas de comunicação remota entre objetos distribuídos se destacam: CORBA, DCOM e JRMI. A seguir serão apresentados as principais características e o funcionamento básico dessas arquiteturas. 2.1.1 Java RMI (Remote Method Invocation) O JRMI é uma arquitetura criada pela Sun Microsystem para permitir a comunicação entre objetos, implementados em Java, distribuídos remotamente. Com o JRMI, um objeto pode ter seus métodos acessados por outro objeto Java localizado em outra máquina virtual através de uma rede. Para que tal comunicação seja possível, deve existir um ORB (Object Request Broker, ou Analisador de Requisições a Objetos), que é responsável pela transmissão dos pedidos entre objetos cliente e servidor (TRINTA, 2000). O ORB pode ser definido como um roteador de mensagens (requisições e respostas às requisições) entre os clientes e os objetos distribuídos. Segundo FRAGA (2001), ORB pode ser considerado como sendo o canal de comunicação entre os objetos que utilizam o modelo de iteração cliente/servidor. Um ORB tem como principal característica o fato de não deixar transparecer detalhes como: localização, implementação, estado de execução e mecanismos de comunicação com objetos (GOULARTE, 1998). A comunicação remota em RMI é intermediada por objetos proxy chamados stubs e skeletons, através dos quais as invocações a métodos remotos são feitas da mesma forma que para objetos locais. Esses objetos são gerados a partir de uma interface e contém os mesmos métodos que foram declarados nelas (GUIZZARDI, 2000). Os stubs do cliente são responsáveis por interceptar as chamadas a métodos remotos, recolher os valores de seus argumentos e direcioná-los através de mensagem ao stub do servidor (skeleton). Estes, por sua vez, executam a chamada ao método da mesma forma que uma requisição local, recebem o retorno e enviam-no de volta ao stub cliente, que se encarrega de repassar a resposta ao objeto requisitante do método remoto. A figura 2 representa a arquitetura de comunicação remota do JRMI.

16 Figura 2: Arquitetura Java/RMI (RICCIONI, 2000). Existem duas formas com as quais um objeto pode encontrar um objeto remoto: recebendo uma referência através do retorno da execução de um método, ou através do serviço registry (RMIregistry). Esse serviço pode ser utilizado por clientes e servidores RMI. Através desse serviço, os clientes obtêm referências para objetos remotos com nomes que identificam serviços prestados pelos objetos (ALBUQUERQUE, 2001). O RMIregistry deve ser implementado em um programa que fique rodando em todos os servidores que disponibilizam objetos. O protocolo utilizado para a comunicação entre os objetos é o JRMP (Java Remote Method Protocol) (TRINTA, 2000). Este protocolo baseia-se na serialização de objetos Java, isto é, os objetos utilizados como parâmetros podem ser transportados como um fluxo de dados, através de uma sessão TCP. As classes utilizadas na implementação de programas RMI encontram-se nos packages (pacotes): java.rmi e java.rmi.server. O processo de comunicação envolve, primeiramente, a localização do objeto, que é fornecida através de uma string que contém o nome do objeto e o endereço da máquina que o abriga (CEZE, 2001). O uso de um protocolo padrão facilita a implementação de RMI, porém pode provocar uma perda de desempenho, devido as mensagens de controle enviadas pelo TCP para garantir a entrega das mensagens.

17 2.1.2 CORBA (Common Object Request Broker Architecture) O CORBA é uma arquitetura criada pelo OMG (Object Management Group), que provê um suporte completo à comunicação remota entre objetos, implementados em diversas linguagens de programação e executando em diversas plataformas (GUIZZARDI, 2000). Essa comunicação dá-se de forma transparente, isto é, o usuário da aplicação não percebe que existe uma comunicação remota. Assim como no JRMI, para que se realize a comunicação entre os vários componentes de uma aplicação distribuída são utilizadas as chamadas remotas. Estas chegarão ao seu destino por intermédio de um ORB (Object Request Broker). As interfaces do ORB são definidas nas especificações do CORBA e atuam como camadas mascarando as diversas formas possíveis de implementação dos módulos (SIQUEIRA & FRAGA, 1996), permitindo que objetos interajam em ambientes homogêneos e heterogêneos. A figura 3 apresenta os quatro principais elementos que compõem a arquitetura CORBA. Figura 3: Principais elementos da arquitetura CORBA (TRINTA, 2000).

18 Os Objetos de Aplicação (ou, objetos distribuídos) acessam os serviços e as facilidades CORBA através de um ORB. Os serviços fornecem funções para utilização e implementação dos objetos, de forma que o programador não tenha que se preocupar com os serviços a nível de sistema. Dentre esses serviços, definidos pela OMG, estão: serviço de persistência; nome; ciclo de vida; notificação de eventos; controle de concorrência; transação; atomicidade; relacionamento; segurança; entre outros (RICCIONI, 2000). As facilidades CORBA são coleções de serviços utilizados pelas mais diversas aplicações (RICCIONI, 2000). São divididas em dois grupos: facilidades horizontais e facilidades verticais. Facilidades Horizontais são utilizadas por varias aplicações, independente da área de aplicação, e são subdivididas em: interface do usuário; gerenciamento de sistema; gerenciamento de informação e gerenciamento de tarefa. Facilidades Verticais são utilizadas em áreas de aplicação específicas, como medicina, contabilidade, simulação distribuída, entre outros. Como já foi citada anteriormente, no CORBA a comunicação entre os objetos distribuídos não depende da linguagem utilizada em sua implementação, podem ser usadas: C, C++, Java, Ada, COBOL e Smaltalk. A diferença existente entre elas é mascarada pelo CORBA através do mapeamento da IDL (Interface Definition Language) para a linguagem desejada. A IDL é uma linguagem neutra, puramente declarativa, que não dependente de sistemas operacionais e nem linguagem de programação (TRINTA, 2000). Sua sintaxe é baseada em C++, porém, após passar por um tradutor (compilador IDL), terá suas definições mapeadas para a linguagem de implementação do objeto que disponibilizará métodos remotamente. A exemplo do que acontece no JRMI, a compilação das interfaces (IDLs) também gera os stubs no cliente e os skeletons no servidor. Os stubs e skeletons no CORBA têm funcionamento similar a uma chamada de procedimento remoto (RPC), incluindo os processos de empacotamento (Marshalling) e desempacotamento (Unmarshalling) (GOULARTE, 1998). A figura 4 apresenta a arquitetura de comunicação no CORBA.

19 Figura 4: Arquitetura de comunicação em CORBA (CARDOZO, 2002). A comunicação no CORBA é, assim como no JRMI, através de TCP, ou seja, são transmitidos fluxos de bytes, sendo orientada a conexão. A transmissão de dados é feita através de uma sessão TCP (PRADO, 1997). Através da utilização de CORBA é possível criar aplicações distribuídas em que um módulo é implementado em Java e outro em C++, por exemplo. Mesmo que esses módulos estejam em sistemas operacionais diferentes, um em Windows e o outro em Unix, a comunicação dar-se-á de forma transparente e sem problemas de incompatibilidade. 2.1.3 DCOM (Distributed Common Object Model) O DCOM aplica às redes de computadores o funcionamento do COM, que utiliza uma estrutura especificada pela Microsoft para permitir a comunicação entre componentes escritos em linguagens diferentes (TRINTA, 2000), acrescentando a possibilidade de objetos locais poderem acessar métodos de objetos remotos de forma transparente. O Modelo de Objetos Componentes (COM) é a especificação e implementação de uma infra-estrutura criada pela Microsoft para prover a integração de componentes de software baseados em objetos (TRINTA, 2000). Através da utilização deste framework é possível implementar sistemas utilizando vários componentes de diversos distribuidores. Entende-se por componente um conjunto de funcionalidades prontas para serem acessadas por programas de computador, englobadas em um pacote.

20 Essa arquitetura baseia-se em um protocolo de comunicação chamado ORPC (Object Remote Procedure Call) (VASCONCELOS, 2002), que foi construído sobre o RPC da DCE (Distributed Computing Environment), uma arquitetura que fornece um ambiente para o tráfego de informações entre objeto requisitante e requisitado nas duas direções (RICCIONI, 2000). Essa arquitetura suporta a comunicação de objetos implementados em diversas linguagens diferentes, porém, o sistema operacional onde serão executados deve ser necessariamente o Windows (GUIZZARDI, 2000). Para que os objetos remotos se comuniquem é necessário que um ORB DCOM esteja instalado. Ele interceptará as chamadas aos métodos remotos e estabelecerá a comunicação com o ORB em que se localiza o objeto possuidor do método (LUCENA, 2001). Assim como no CORBA, o ORB é responsável por direcionar as requisições e respostas dos objetos que estão se comunicando remotamente. A figura 5 apresenta a arquitetura de comunicação utilizada no DCOM. Figura 5: Arquitetura de comunicação do DCOM (CARDOZO, 2002). Para que o acesso aos objetos DCOM seja possível, devem ser definidas suas interfaces (IDL), que são declaradas com o uso de uma linguagem chamada MIDL (Microsoft Interface Definition Language). Os clientes DCOM interagem entre si e com o sistema chamando funções definidas nestas interfaces.

21 Após a compilação da IDL são gerados os stubs que serão utilizados como um proxy para a invocação de métodos remotos (LUCENA, 2001). Esses stubs têm funcionalidade semelhante à dos stubs do JRMI e os do CORBA. Um cliente DCOM poderá chamar métodos de um servidor somente após a aquisição de uma referência a uma das interfaces deste objeto, ou seja, um ponteiro para um objeto em um determinado estado (TRINTA, 2000). Após isso, consegue-se informação sobre localização do objeto na rede. As chamadas aos métodos do servidor são feitas indiretamente aos métodos expostos pela API (Application Program Interface) do objeto (LUCENA, 2001). A API de um objeto possui os métodos que podem ser acessados por outros objetos. Os objetos DCOM não mantêm seu estado, isto é, ao final da conexão são destruídos, assim, várias interfaces devem ser definidas, cada uma representando um estado diferente do objeto (TRINTA, 2000). Não é possível que, após um encerramento de conexão, o objeto cliente se reconecte a uma instância de objeto igual ao de uma conexão anterior. Segundo RICCIONI (2000), o DCOM, além de oferecer a possibilidade de definir interfaces comuns aos objetos distribuídos, oferece outros recursos, como: Object Definition Language (ODL), que é a linguagem de definição de objetos utilizada para descrever metadados; e o Object Services, que são os serviços oferecidos pelos objetos (por exemplo: serviço de eventos, serviço de diretório local, mecanismo de licença entre outros). Estes recursos facilitam a programação e o acesso aos objetos distribuídos. O DCOM pode ser uma boa opção no que se refere à escolha da linguagem para implementação dos módulos, pois estes podem ser implementados em várias linguagens, incluindo C++, Java, entre outras. Porém o fato de suportarem apenas conexões UDP entre as aplicações distribuídas e a limitação no que diz respeito ao sistema operacional, dificulta a sua maior abrangência no campo de sistemas distribuídos. 2.2 Sistemas Multimídia Multimídia pode ser definida, no contexto computacional, como sendo a integração de duas ou mais mídias. Para definir sistemas multimídia os seguintes conceitos podem ser utilizados:

22... um sistema multimídia é um sistema ou aplicação que suporta o processamento integrado de vários tipos mídias (contínuas e discretas), com ao menos uma mídia contínua (PRESTES, 2003). A multimídia constitui uma tecnologia interdisciplinar que orienta aplicações que visam atender às necessidades multi-sensoriais da natureza humana. Sistemas multimídia tornam isso possível devido às novas alternativas de integração, manipulação, armazenamento, transmissão, exibição e interação de diferentes formatos de mídia (texto, gráfico, animação, áudio e vídeo) (GUIZZARDI, 2000). Sistemas multimídias em geral se caracterizam pela integração de diversos tipos de meios em uma única infra-estrutura computacional (PRADO, 1997). Podemos concluir então que sistemas multimídias são aqueles que conseguem gerenciar e prover conteúdo diversificado, isto é, vários tipos de mídias integradas, de forma a proporcionar maior interação com o usuário final. Essas mídias podem ser classificadas como mídias discretas e mídias contínuas. As mídias discretas podem ser: texto; gráfico e imagem, enquanto que as mídias continuas são representadas por: áudio e vídeo (DINIZ, 1998). 2.2.1 Características das mídias As principais vantagens identificadas na utilização de sistemas multimídias, sejam eles centralizados ou distribuídos, são o maior estímulo aos sentidos audiovisuais e maior sensação de realidade. Podemos citar como exemplos de sistemas multimídias bem difundidos e utilizados: videoconferências, fóruns, bate-papo, entre outros. Nos dias de hoje a multimídia vem sendo aplicada em áreas como: medicina, visualização de imagens de alta resolução, sistemas de videoconferência, sistemas de aprendizado à distância e em trabalhos em grupo (GOULARTE, 1998). Todo esse sucesso vem sendo alcançado devido ao grande avanço da tecnologia computacional no que se refere à velocidade de processamento, escoamento de dados, algoritmos de compressão de

23 sons e imagens, dentre outros avanços que promovem facilidades às implementações e disseminação dos sistemas multimídia. Algumas das principais características de um sistema multimídia podem ser vistas a seguir: acesso não-linear; interatividade; integração com programas aplicativos; emprego da animação; emprego do som; substituição de mídia convencional. O acesso não-linear se caracteriza pela possibilidade de vinculação de inúmeros pontos na mídia, como os links em uma página da Web. A interatividade é garantida pelo acesso a microfones, dinamismo do conteúdo das páginas Web e outros fatores que proporcionam ao usuário de um sistema multimídia a capacidade participar da execução direta das mídias envolvidas. O emprego de animações, sons e imagem aumentam, além da interatividade com o usuário, a possibilidade de substituir as mídias convencionais (radio, fita VHS, cartão de visita, etc.) pelas aplicadas a sistemas de computadores. Existem dois tipos de sistemas multimídia: SMC (Sistemas Multimídia Centralizados) e SMD (Sistemas Multimídia Distribuídos). Os SMC são sistemas que operam em uma máquina, sem ligações e separações de módulos em computadores distintos. Já os SMD são uma generalização dos SMC, porém, suas mídias encontram-se distribuídas e/ou seus módulos estão localizados em máquinas diferentes em uma rede de computadores (PRADO, 1997). Para a implementação de sistemas multimídia distribuídos existem inúmeras limitações, dentre elas, segundo VASCONCELOS (2002), estão: negociação de QoS (Quality of Services): dificuldade na implementação de QoS em algumas infra-estruturas de rede;