Utilizando CCM no Suporte a Sessões Cooperativas Síncronas

Texto

(1)UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Utilizando CCM no Suporte a Sessões Cooperativas Síncronas Por. Cláudia Brito Lyra Nunes da Silva Dissertação de Mestrado. Recife, Fevereiro 2004.

(2) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Cláudia Brito Lyra Nunes da Silva. Utilizando CCM no Suporte a Sessões Cooperativas Síncronas. Dissertação submetida à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. Orientador: Carlos André Guimarães Ferraz. Recife, Fevereiro 2004.

(3) Aos meus pais e irmãos, iii. ao meu noivo Rossam e à minha amiga Jeísa..

(4) Agradecimentos. Agradeço a Deus por estar sempre ao meu lado, abençoando-me e dando-me força e coragem para enfrentar os obstáculos da vida. A meus pais, irmãos, sobrinhos e cunhados pelo amor, carinho e proteção, por me apoiarem em todas as minhas decisões e por fazerem parte da minha vida, tornando-a mais simples de ser vivida. Ao amor da minha vida, Rossam, por preencher minha vida de amor, alegria e sonhos, pelo companheirismo e amizade e por estar sempre ao meu lado, acolhendo-me em seus braços nos momentos de tristeza e angústia. A minha amiga Jeísa pela grande e sincera amizade, pelos conselhos e por compartilhar minhas alegrias, tristezas, dúvidas e angústias, ajudando-me a superar os problemas e a concretizar mais uma etapa da minha vida. A todos os meus amigos, em especial a Luiz Eugênio (left), Klissiomara Dias e Márcio Cornélio por me apoiarem e por estarem sempre dispostos a me ajudar na solução dos problemas enfrentados durante a realização deste trabalho. A Nelson Rosa, cujas sugestões foram essenciais para o direcionamento e conclusão desta dissertação de mestrado.. iv.

(5) Resumo. A área de trabalho cooperativo apoiado por computador (CSCW - Computer Supported Cooperative Work ) estuda como as pessoas podem cooperar para a solução de problemas e como tais cooperações podem ser estabelecidas e desenvolvidas utilizando-se recursos computacionais. As aplicações cooperativas síncronas provêem funcionalidades que permitem a interação síncrona entre os membros de um grupo, estando estes em um mesmo local ou dispersos geograficamente. Tais aplicações necessitam de mecanismos de controle que possibilitem o gerenciamento dos usuários que fazem parte das sessões cooperativas, e permitam que os participantes acessem, de forma compartilhada, os recursos disponíveis durante a sessão. Dentre as tecnologias utilizadas na implementação de soluções de suporte a sessões cooperativas síncronas, CORBA (Common Object Request Broker Architecture) mostra-se de grande valor ao prover interoperabilidade entre aplicações implementadas em diferentes linguagens, independentemente de plataforma, protocolos e tecnologias de rede. O CCM (CORBA Component Model ) representa o modelo de componente para a arquitetura CORBA, cujo objetivo principal é facilitar o desenvolvimento de aplicações que utilizam CORBA como plataforma de distribuição. Dessa forma, o objetivo deste trabalho é prover um serviço de suporte a sessões cooperativas síncronas (CSMS - Cooperative Session Management Service), utilizando a tecnologia de componentes proposta pelo CCM. Os principais aspectos abordados por esse serviço são o gerenciamento de usuários que fazem parte da sessão e o mecanismo de controle utilizado no acesso aos recursos compartilhados durante a sessão.. Palavras-chave: CSCW, Sessões Cooperativas Síncronas, CCM. v.

(6) Abstract. The Computer Supported Cooperative Work (CSCW) is concerned with investigating how people cooperate to solve problems and how that cooperation can be supported using computer resources. Synchronous cooperative applications provide functionalities that allow synchronous interaction among members of a group, who may be in the same place or geographically separated. Those applications need control mechanisms wich enable managing the session participants and allow them to access shared resources during the session. Amongst the technologies used to deploy synchronous session support solutions, CORBA (Common Object Request Broker Architecture) is quite important for providing interoperability among applications implemented in different languages, independent from platform, protocols and network technologies. CCM (CORBA Component Model) aims to facilitate applications deployment using CORBA as distribution platform. Therefore, the purpose of this work it providing a synchronous cooperative session management service (CSMS) using the CCM’s component technology. The main aspects treated by this service are the management of the session participants and the control mechanism used to supervise accessing shared resources during the session.. Keywords: CSCW, Synchronous Cooperative Sessions, CCM. vi.

(7) Sumário 1 Introdução. 1. 1.1. Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.3. Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 2 Aplicações Cooperativas Distribuídas Síncronas. 6. 2.1. CSCW e Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 2.2. Aplicações Cooperativas Síncronas . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 2.2.1. Gerenciamento de Sessão . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11. 2.2.2. Controle de Palavra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 2.3. Aplicações Cooperativas Baseadas em Componentes . . . . . . . . . . . . . . . .. 13. 2.4. Suporte ao Desenvolvimento de Groupware. . . . . . . . . . . . . . . . . . . . . .. 15. 2.5. Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16. 3 Desenvolvendo Aplicações Distribuídas Utilizando CCM 3.1. 18. Elementos da Arquitetura CORBA . . . . . . . . . . . . . . . . . . . . . . . . . .. 19. 3.1.1. ORB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21. 3.1.2. IDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21. 3.1.3. Stub e Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22. 3.1.4. Adaptador de Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22. 3.1.5. DII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. 3.1.6. DSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. vii.

(8) 3.2. Visão Geral do CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 24. 3.3. Desenvolvendo Componentes CCM . . . . . . . . . . . . . . . . . . . . . . . . . .. 26. 3.3.1. Definindo Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27. 3.3.2. Implementando Componentes . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 3.3.3. Empacotando Componentes . . . . . . . . . . . . . . . . . . . . . . . . . .. 37. 3.3.4. Instalando Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38. 3.3.5. Executando Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 3.4. Utilizando Componentes CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 41. 3.5. Discutindo o CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 41. 3.6. Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 43. 4 CSMS: Um Serviço de Suporte a Sessões Cooperativas Síncronas. 44. 4.1. Requisitos para o Gerenciamento de Sessões Cooperativas . . . . . . . . . . . . .. 44. 4.2. CSMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 46. 4.2.1. Características do CSMS . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 47. 4.2.2. Componentes do CSMS . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 48. Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 54. 4.3. 5 Estudo de Caso: Um Cenário de Segunda Opinião Médica. 56. 5.1. Cenário de uma Sessão Cooperativa Síncrona . . . . . . . . . . . . . . . . . . . .. 56. 5.2. Utilizando o CSMS no Cenário da Segunda Opinião Médica . . . . . . . . . . . .. 58. 5.3. Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 67. 6 Conclusão. 68. 6.1. Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 68. 6.2. Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 69. viii.

(9) Lista de Figuras 2.1. Classificação Tempo-Espaço das Aplicações Groupware. . . . . . . . . . . . . . . .. 8. 3.1. Middleware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 19. 3.2. Processo de Desenvolvimento de uma Aplicação CORBA. . . . . . . . . . . . . .. 20. 3.3. Componentes do Modelo de Referência CORBA [1]. . . . . . . . . . . . . . . . . .. 21. 3.4. Processo de Desenvolvimento de um Componente CCM. . . . . . . . . . . . . . .. 27. 3.5. Portas de Comunicação de um Componente CCM. . . . . . . . . . . . . . . . . .. 28. 3.6. Declaração Simples de um Componente em IDL3 e seu Mapeamento para IDL2. .. 29. 3.7. Declaração de um Componente que Suporta Interfaces. . . . . . . . . . . . . . . .. 29. 3.8. Declaração de Herança entre Componentes. . . . . . . . . . . . . . . . . . . . . .. 29. 3.9. Declaração Conjunta de Herança e de Suporte a Interfaces. . . . . . . . . . . . .. 30. 3.10 Definição de uma Faceta em IDL3 e seu Mapeamento para IDL2. . . . . . . . . .. 30. 3.11 Definição de um Receptáculo Simples em IDL3 e seu Mapeamento para IDL2. . .. 31. 3.12 Definição de um Receptáculo Múltiplo em IDL3 e seu Mapeamento para IDL2. .. 31. 3.13 Definição de um Publisher em IDL3 e seu Mapeamento para IDL2. . . . . . . . .. 33. 3.14 Definição de um Emitter em IDL3 e seu Mapeamento para IDL2. . . . . . . . . .. 33. 3.15 Definição de um Consumidor de Eventos em IDL3 e seu Mapeamento para IDL2.. 34. 3.16 Declaração de uma Home sem Chave Primária. . . . . . . . . . . . . . . . . . . .. 35. 3.17 Declaração de uma Home com Chave Primária. . . . . . . . . . . . . . . . . . . .. 35. 3.18 Declaração de uma Composição. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 37. 3.19 Container CCM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 40. 4.1. 49. Conexão entre os Componentes CSession e Participant. ix. . . . . . . . . . . . . . ..

(10) 4.2. Declaração do Componente CSession em IDL3. . . . . . . . . . . . . . . . . . . .. 49. 4.3. Declaração da Interface SessionControl em IDL3. . . . . . . . . . . . . . . . . . .. 50. 4.4. Declaração da Interface FloorControl em IDL3. . . . . . . . . . . . . . . . . . . .. 51. 4.5. Declaração do Evento SessionEvent em IDL3. . . . . . . . . . . . . . . . . . . . .. 52. 4.6. Declaração da Home SessionManager em IDL3. . . . . . . . . . . . . . . . . . . .. 53. 4.7. Declaração do Componente Participant em IDL3. . . . . . . . . . . . . . . . . . .. 54. 4.8. Declaração da Home ParticipantHome em IDL3. . . . . . . . . . . . . . . . . . .. 54. 5.1. Diagrama de Atividades para a Entrada de um Médico na Sessão. . . . . . . . . .. 59. 5.2. Diagrama de Atividades para a Saída de um Médico da Sessão. . . . . . . . . . .. 60. 5.3. Diagrama de Atividades para a Expulsão de um Participante. . . . . . . . . . . .. 61. 5.4. Diagrama de Atividades para a Mudança do Líder da Sessão. . . . . . . . . . . .. 62. 5.5. Diagrama de Atividades para o Encerramento da Sessão. . . . . . . . . . . . . . .. 63. 5.6. Diagrama de Atividades para a Requisição do Floor. . . . . . . . . . . . . . . . .. 64. 5.7. Diagrama de Atividades para a Liberação do Floor. . . . . . . . . . . . . . . . . .. 65. x.

(11) Capítulo 1. Introdução Devido à complexidade e ao porte das atividades do mundo atual, torna-se cada vez mais necessária a interação entre as pessoas. Uma área de intensa pesquisa na Ciência da Computação é a que estuda o trabalho cooperativo apoiado por computador (CSCW - Computer Supported Cooperative Work ) [2], buscando tecnologias que possibilitem uma maior interação entre as pessoas através de recursos computacionais. As soluções desenvolvidas no campo de pesquisa de CSCW são comumente designadas de groupware. Tais soluções possuem um papel fundamental, permitindo que um grupo de indivíduos possa interagir de forma cooperativa, com a finalidade de atingir um objetivo comum, independentemente dos limites de tempo e espaço. Os sistemas de correio-eletrônico, teleconferências, suporte a decisão e editores de texto colaborativos são exemplos de groupware, uma vez que promovem a comunicação entre os membros de um grupo de trabalho, contribuindo assim para que o resultado seja maior que a soma das contribuições individuais de cada membro do grupo [3]. As aplicações de groupware são utilizadas em diversas áreas, como educação, pesquisa e engenharia de software. Na área da educação, os sistemas de mensagens e de conferência síncrona e assíncrona são muito utilizados entre alunos e professores para esclarecer dúvidas, distribuir e recolher exercícios, trabalhos e avisos. Na área da pesquisa, grande parte dos projetos envolve a participação de pesquisadores que muitas vezes pertencem a organizações e a países diferentes. Dessa forma, os sistemas 1.

(12) de co-autoria têm sido utilizados por grupos de pesquisa, como ferramenta para permitir o compartilhamento de objetos de interesse do projeto, quer seja um texto, documento ou protótipo em desenvolvimento. Na área da engenharia de software, em cada uma das cinco fases do ciclo de vida clássico de um software (análise, projeto, implementação, verificação e manutenção), desempenha-se atividades em grupo, cujo produto é conhecido como artefato de software. Assim, a utilização das tecnologias de CSCW contribui para melhorar a produtividade deste grupo e a qualidade dos artefatos de software resultantes.. 1.1. Motivação. Nas aplicações cooperativas, a interação entre os membros de um grupo pode ocorrer de diversas formas, dependendo principalmente da localização dos mesmos e do momento em que a interação ocorre. Desse modo, há aplicações cooperativas (aplicações de groupware) síncronas e assíncronas, nas quais os participantes encontram-se em um mesmo local ou dispersos geograficamente. Há diversas situações nas quais um determinado problema precisa ser resolvido por um grupo de pessoas que estão situadas em diferentes locais. Na maioria das vezes, estas situações requerem urgência, não sendo viável a utilização de meios de comunicação assíncronos. Dessa forma, as aplicações cooperativas síncronas e distribuídas foram escolhidas como objeto de estudo desse trabalho, uma vez que fornecem meios que possibilitam a interação síncrona entre os integrantes de um grupo, estando estes situados em diferentes locais. Duas propriedades desejáveis a um sistema de groupware são: a capacidade de adicionar novas funções sem interferir nas funções existentes e a capacidade de compor uma função selecionando e combinando outras funções básicas [4]. Dessa forma, nos últimos anos, a construção de aplicações cooperativas tem sido direcionada à utilização da abordagem de desenvolvimento de software baseado em componentes [5], uma vez que um componente provê funcionalidades que podem ser usadas separadamente ou em composição com as funcionalidades providas por outros componentes. Dentre as funcionalidades que os componentes podem oferecer à construção de aplicações. 2.

(13) cooperativas síncronas, estão aquelas relacionadas aos mecanismos de controle. Tais mecanismos possibilitam o gerenciamento das sessões cooperativas e permitem aos participantes acessarem, de forma compartilhada, os recursos disponíveis durante a sessão. Desse modo, encapsular tais mecanismos em funcionalidades providas por componentes permite que os mesmos possam ser utilizados em diversas aplicações. Para permitir a interação entre indivíduos localizados em diferentes regiões (possivelmente usuários de plataformas de software/hardware diversas), as aplicações cooperativas tendem a utilizar alguma plataforma de distribuição que forneça suporte necessário a essa interação. Dentre as plataformas existentes, CORBA (Common Object Request Broker Architecture) [6] é padronizada pela OMG (Object Management Group) [7] e bastante utilizada no desenvolvimento de aplicações distribuídas, por permitir que estas sejam implementadas em diversas linguagens de programação e plataformas (sistemas operacionais) distintas. Também desenvolvido pela OMG, o CCM (CORBA Component Model ) [8] é o modelo de componentes que utiliza CORBA como infra-estrutura, permitindo assim que aplicações distribuídas que utilizam CORBA como plataforma de distribução possam ser desenvolvidas utilizando-se a tecnologia de software baseada em componentes. Dessa forma, uma vez que o desenvolvimento de aplicações cooperativas está sendo direcionado à utilização de componentes de software e pelo fato de CORBA ser uma arquitetura largamente empregada na construção de aplicações distribuídas, CCM apresenta-se como um modelo de componentes adequado para ser utilizado no suporte à construção de aplicações cooperativas distribuídas.. 1.2. Objetivos. O objetivo desse trabalho é desenvolver um serviço, o CSMS (Cooperative Session Management Service), para o controle de sessões cooperativas síncronas e distribuídas, utilizando a tecnologia de componentes proposta pelo CCM. Os principais aspectos abordados por esse serviço são o gerenciamento de usuários que fazem parte da sessão e o mecanismo de controle utilizado no acesso aos recursos compartilhados durante a sessão.. 3.

(14) Desse modo, o CSMS será responsável por implementar as seguintes funcionalidades: • Gerenciamento de sessão: responsável pela administração e coordenação das sessões e dos membros que fazem parte delas. • Controle de palavra: permite que os participantes utilizem e compartilhem os recursos disponíveis sem que haja conflitos de acesso. Encapsular tais aspectos em funcionalidades providas por componentes de software permite que o serviço possa ser utilizado em diversas aplicações. Através da composição inerente aos componentes, o mesmo serviço poderá ser utilizado para compor aplicações baseadas em componentes que necessitam das funcionalidades providas por ele. Visando uma maior interoperabilidade e dando preferência a tecnologias abertas, o CSMS utiliza o modelo de componentes CORBA (CCM), por ser um padrão aberto, independente de linguagem e plataforma. Dessa forma, um outro objetivo do trabalho é apresentar uma aplicação prática do CCM, uma vez que, por ser um modelo recente (a sua especificação foi lançada em Junho de 2002), há uma carência de aplicações nas quais possa ser verificada e analisada a sua usabilidade em uma situação real, como é o caso das aplicações de groupware.. 1.3. Estrutura da Dissertação. O restante desta dissertação encontra-se organizado conforme descrito abaixo. No Capítulo 2, uma visão geral sobre CSCW é apresentada, evidenciando o uso de aplicações cooperativas distribuídas síncronas como soluções de groupware. Também são descritos os mecanismos necessários para gerenciamento e controle de tais aplicações, e plataformas de suporte ao desenvolvimento de groupware. O Capítulo 3 apresenta uma visão geral da arquitetura CORBA e introduz o CCM, mostrando as principais características e funcionalidades deste modelo de componente que utiliza CORBA como infra-estrutura, além de descrever o processo de desenvolvimento de um componente CCM. O Capítulo 4 descreve o CSMS, um serviço proposto (implementado usando CCM) com o objetivo de prover suporte a sessões cooperativas, fornecendo os mecanismos básicos de controle 4.

(15) e gerenciamento. O Capítulo 5 apresenta um cenário real de uma segunda opinião médica, que corresponde ao estudo de caso utilizado para validar o CSMS. Finalmente, as conclusões, incluindo as contribuições e os possíveis trabalhos futuros, são apresentadas no Capítulo 6.. 5.

(16) Capítulo 2. Aplicações Cooperativas Distribuídas Síncronas As aplicações cooperativas permitem que um grupo de pessoas trabalhem em conjunto, cooperando entre si, com a finalidade de atingirem um mesmo objetivo. A forma através da qual os membros de um grupo interagem pode variar, dependendo da localização dos mesmos e do momento em que a interação entre eles ocorre. Desse modo, verifica-se a existência de aplicações cooperativas síncronas (os participantes interagem ao mesmo tempo) e assíncronas (os participantes interagem em tempos diferentes), nas quais os participantes localizamse em um mesmo recinto ou dispersos geograficamente. Dentre os tipos de aplicações citadas acima, serão abordadas nesse capítulo as aplicações cooperativas distribuídas síncronas. Sendo assim, o capítulo está organizado da seguinte forma: a Seção 2.1 apresenta uma visão geral sobre CSCW e Groupware; a Seção 2.2 descreve as aplicações de groupware síncronas, que serão abordadas nessa dissertação de mestrado; a Seção 2.3 discorre sobre o desenvolvimento de aplicações cooperativas baseadas em componentes; a Seção 2.4 apresenta algumas plataformas de suporte ao desenvolvimento de aplicações cooperativas; e a Seção 2.5 apresenta as considerações finais relacionadas a esse capítulo.. 6.

(17) 2.1. CSCW e Groupware. A área de trabalho cooperativo apoiado por computador (CSCW - Computer Supported Cooperative Work ) estuda como as interações entre as pessoas podem ser estabelecidas e desenvolvidas utilizando-se recursos computacionais. Groupware costuma ser usado quase como sinônimo de CSCW, no entanto, alguns autores estabelecem uma diferença na utilização desses termos. Segundo eles, CSCW representa a pesquisa na área do trabalho em grupo e como os computadores podem apoiá-lo, enquanto groupware tem sido utilizado para designar a tecnologia (hardware e software) gerada pela pesquisa em CSCW [3]. Dessa forma, groupware pode ser definido como sistemas baseados em computador que provêem suporte a grupos de pessoas engajadas em uma tarefa ou objetivo comum e que fornecem uma interface para um ambiente compartilhado [9]. Um software de apoio ao trabalho em grupo (groupware) objetiva, principalmente, aumentar o potencial do grupo, fazendo com que o resultado seja maior do que a soma das contribuições individuais de cada membro do grupo [3]. Para isto, busca resolver problemas e aumentar a capacidade de comunicação, colaboração e coordenação dos grupos que estão realizando um trabalho conjunto. Três funções genéricas e importantes a serem fornecidas por um groupware são [10]: • Comunicação: característica fundamental que permite que a informação seja compartilhada ou enviada para os outros participantes do grupo; • Colaboração: visa apoiar os participantes do grupo na solução de problemas, no entendimento da tarefa e na sua realização; • Coordenação: com a finalidade de assegurar que o grupo trabalhe de forma efetiva e seja capaz de atingir as suas metas. Há várias classificações para as aplicações de groupware, sendo a classificação Tempo-Espaço [9] a mais citada na literatura. De acordo com essa classificação, as aplicações estão divididas em quatro categorias, levando-se em consideração dois aspectos: o momento em que os participantes interagem (síncrono ou assíncrono) e a localização dos mesmos durante a interação (local ou remoto). 7.

(18) Como pode ser observado na Figura 2.1, as quatro categorias são as seguintes: • Interação Face a Face: nas aplicações que suportam esse tipo de interação, os participantes encontram-se ao mesmo tempo e no mesmo local; • Interação Assíncrona: os participantes, nesse caso, apesar de estarem no mesmo local, interagem uns com os outros em tempos diferentes; • Interação Síncrona Distribuída: nas aplicações que suportam esse tipo de interação, os participantes encontram-se distribuídos em diferentes locais, no entanto, a interação entre eles ocorre ao mesmo tempo; • Interação Assíncrona Distribuída: nesse último caso, os participantes encontram-se em ambientes distribuídos e interagem uns com os outros em tempos diferentes.. Mesmo Tempo. Tempos Diferentes. Mesmo Local. Interação Face a face. Interação Assíncrona. Locais Diferentes. Interação Síncrona Distribuída. Interação Assíncrona Distribuída. Figura 2.1: Classificação Tempo-Espaço das Aplicações Groupware.. Uma outra forma de classificar as aplicações de groupware é segundo o nível de funcionalidade que as mesmas oferecem. Aquelas que apresentam características e funcionalidades similares são agrupadas sob uma mesma categoria. Em [9] é apresentada uma classificação desse tipo, onde as aplicações groupware podem ser classsificadas em um dos seguintes tipos: • Sistemas de Mensagens: exemplo mais comum de groupware, cuja característica é suportar a troca assíncrona de mensagens entre os membros de um grupo; • Sistemas de Editoração Multi-usuários (Co-Autoria): podem ser utilizados pelos membros de um grupo para compor e editar um documento conjuntamente; 8.

(19) • Sistemas de Suporte a Decisão: também conhecidos como GDSS(Group Decision Support Systems), são sistemas interativos baseados em computador que facilitam a solução fornecida por um grupo de pessoas para problemas não estruturados [11]; • Sistemas de Conferência via Computador : podem ser classificados em síncronos, assíncronos e sistemas de teleconferência; • Sistemas de Coordenação: permitem que os indivíduos vejam suas ações, bem como as ações relevantes dos outros membros do grupo, dentro do contexto de um mesmo objetivo a ser atingido. Dentre os vários tipos de aplicações de groupware existentes, será abordada, nesse trabalho, aquela que apresenta como característica principal a interação síncrona entre os membros de um grupo. Dessa forma, serão descritas na Seção 2.2 as aplicações cooperativas síncronas.. 2.2. Aplicações Cooperativas Síncronas. As aplicações cooperativas síncronas provêem funcionalidades que permitem a interação síncrona entre os membros de um grupo, estando estes em um mesmo local ou dispersos geograficamente. Essa interação ocorre durante sessões cooperativas, as quais podem possuir as seguintes características: • aberta: nesse tipo de sessão, todos os usuários são bem vindos, ou seja, ninguém pode ser expulso. Dessa forma, não é necessária a utilização de listas de controle de acesso. • fechada: ao contrário das sessões abertas, as sessões fechadas permitem apenas a entrada de usuários previamente convidados. Nesse caso, a sessão possui uma lista de controle de acesso, que contém a identificação dos usuários que têm o direito de participar dela. • fracamente acoplada: as sessões fracamente acopladas caracterizam-se por não requererem um mecanismo explícito de gerenciamento de sessão e controle de acesso aos recursos compartilhados.. 9.

(20) • fortemente acoplada: as sessões fortemente acopladas, ao contrário das fracamente acopladas, requerem um mecanismo explícito de controle de sessão e controle de palavra (isto é, controle utilizado no acesso aos recursos compartilhados). Há diversos tipos de aplicações cooperativas síncronas distribuídas, cada um deles com funcionalidades e objetivos específicos. A característica comum presente nessas aplicações é a interação síncrona entre os participantes de um grupo que encontram-se distribuídos em diferentes locais. Dentre as aplicações existentes, podem ser citadas [12]: • Vídeo Conferências: permitem a comunicação remota com recursos de áudio e vídeo. São de grande utilidade na redução de custos de deslocamento e tempo despendido no trabalho de uma equipe globalmente distribuída. Além disso, permitem a realização de teleconferências e cursos à distância. • Chats: possibilitam a interação síncrona, através da troca de frases, expressões de idéias e sentimentos, ou até gestos, dependendo dos recursos disponíveis em cada implementação. Para conversar com pessoas em um chat, todos os usuários devem estar conectados à internet ao mesmo tempo. • Editores Cooperativos: podem ser usados por um grupo de pessoas para compor e editar gráficos ou textos conjuntamente, ou seja, há uma área de trabalho comum na qual todos atuam e podem visualizar o que é feito. Existem editores síncronos, que permitem a um usuário editar a frase de um parágrafo, enquanto outro está atualizando a frase seguinte, sendo possível que ambos visualizem o que cada um está fazendo. Nas aplicações cooperativas síncronas cujas sessões são fortemente acopladas, é necessário a utilização de mecanismos de controle que possibilitem o gerenciamento das sessões cooperativas e que permitam aos participantes acessarem, de forma compartilhada, os recursos disponíveis durante a sessão. Tais mecanismos serão apresentados a seguir.. 10.

(21) 2.2.1. Gerenciamento de Sessão. A característica primária de aplicações cooperativas é que elas por definição envolvem a interação de múltiplos usuários. Uma sessão pode ser definida como uma agregação on-line de participantes que trabalham cooperativamente e de forma síncrona em recursos compartilhados. A maneira como esses usuários reunem-se em uma sessão cooperativa é determinada pelo mecanismo de gerenciamento de sessão utilizado pela aplicação. O mecanismo de gerenciamento de sessão é responsável pela administração e coordenação das sessões e dos membros que fazem parte delas. Ele provê funcionalidades que possibilitam ao usuário criar e encerrar sessões, assim como entrar, sair e convidar outros membros para fazerem parte delas. Modelos de Gerenciamento de Sessão De acordo com [13], há dois modelos de gerenciamento de sessão: explícito - que requer ação explícita dos próprios usuários para criar a sessão e se conectar a ela - e ímplicito - no qual o próprio serviço de gerenciamento de sessão detecta possíveis situações de colaboração e toma as devidas providências para que os usuários envolvidos possam trabalhar de forma cooperativa. Essas situações podem ser detectadas a partir do momento em que múltiplos usuários estão trabalhando em um mesmo objeto. O gerenciamento explícito é o mais utilizado pelas aplicações cooperativas, sendo as abordagens descritas a seguir os exemplos mais comuns dessa forma de gerenciamento: • Initiator-based : algum usuário inicia a sessão e explicitamente convida outros membros para participarem dela. Essa abordagem permite notificar os usuários sobre a existência da sessão, bem como prover meios para os mesmos conectarem-se a ela. • Joiner-based : um usuário inicia a sessão, no entanto, ao contrário da abordagem anterior, os demais membros não são convidados a participarem da sessão. Eles escolhem, dentre uma lista de sessões disponíveis, aquela da qual eles querem participar. Essa abordagem, apesar de prover meios para os usuários se conectarem à sessão, requer outros meios que notifiquem os usuários sobre a existência da mesma. 11.

(22) No serviço desenvolvido neste trabalho, o gerenciamento explícito Initiator-based é utilizado por garantir que os participantes serão notificados sobre a existência da sessão.. 2.2.2. Controle de Palavra. Geralmente, ambientes cooperativos possuem recursos compartilhados, tornando-se necessário, em alguns casos, controlar o acesso a tais recursos. Dessa forma, devem haver mecanismos que permitam aos participantes utilizarem e compartilharem os recursos disponíveis sem que haja conflitos de acesso. Tais mecanismos são denominados mecanismos de controle de palavra, também conhecidos como mecanismos de floor control [14]. Através dos mecanismos de floor control, direitos de acesso e manipulação aos recursos compartilhados são fornecidos aos participantes da sessão durante um certo intervalo de tempo. De acordo com Crowley et al. [15], há uma distinção entre políticas e mecanismos de controle de palavra. Segundo eles, as políticas descrevem como o controle é requerido por um membro da conferência e como esse controle é concedido a quem o requisitou, enquanto os mecanismos provêem funcionalidades de baixo-nível para a implementação do controle de palavra. Políticas de Controle de Palavra Na literatura podem ser encontrados diversos tipos de políticas de floor control. Dentre eles, destacam-se [16]: • Sem controle: cada membro pode acessar os recursos compartilhados sem que haja nenhum controle. Portanto, evitar conflitos durante o acesso a um recurso compartilhado depende unicamente da boa vontade e do bom senso dos membros do grupo. • Controle implícito: nesse tipo de política, o controle é concedido implicitamente a um participante assim que ele começa a usar um determinado recurso. Esse recurso é então bloqueado para que os demais participantes não possam acessá-lo. Decorrido um certo intervalo de tempo, após o participante ter finalizado o acesso ao recurso, o controle é automaticamente liberado. Caso o participante que esteja com o controle permaneça com. 12.

(23) ele depois de um certo intervalo de tempo, o mesmo será então notificado de que outros usuários estão requerendo o controle sobre o recurso. • Controle explícito: nesse caso, o controle é concedido a um participante ou liberado por ele apenas quando o mesmo solicita. As requisições de outros participantes, enquanto o recurso estiver bloqueado, devem ser colocadas em uma fila e exibidas ao grupo. Assim que o membro que estiver de posse do controle liberá-lo, o controle é concedido ao participante que está no começo da fila. • Controle pelo líder : nesse tipo de controle, o líder do grupo tem o direito de conceder e retirar o controle sobre determinado recurso a qualquer hora. Os pedidos pendentes de acesso ao recurso, recebidos pelo líder, devem ser colocados em uma fila e monitorados por ele. Dommel et al. [14] apresenta, dentre outras, uma classificação para as políticas de floor control, baseada na utilização ou não de filas para armazenar as requisições de controle sobre o recurso. Nesse caso, as políticas podem ser de dois tipos: enfileiradas - as requisições são armazenadas em um fila - ou não-enfileiradas - as requisições são atendidas imediatamente. Neste trabalho foram utilizados dois tipos de políticas: com controle explícito e com controle pelo líder. A política de controle explícito foi escolhida por possibilitar aos participantes (através da exibição da fila de requisitantes) um melhor acompanhamento da utilização dos recursos da sessão. Já a política de controle pelo líder foi escolhida para evitar que o participante ao obter o controle, retenha-o por muito tempo.. 2.3. Aplicações Cooperativas Baseadas em Componentes. No final da década de 90, o estudo de aplicações cooperativas baseadas em componentes surgiu como uma nova área de pesquisa em CSCW. Essa área de pesquisa visa a construção de sistemas de groupware através da junção de componentes de software pré-fabricados, configuráveis e que evoluem de forma independente.[17].. 13.

(24) Componentes são blocos de construção binários, auto-contidos e reusáveis provendo um serviço que pode ser usado tanto individualmente quanto em composição com o serviço provido por outro componente [5]. O desenvolvimento de sistemas de groupware requer o uso de diferentes aplicações para enfrentar diferentes situações de trabalho. Cada aplicação impõe seus requisitos particulares e a integração dessas aplicações separadas em um único sistema de groupware consiste em uma tarefa complicada. Groupwares baseados em componentes tentam resolver alguns dos problemas enfrentados pelos desenvolvedores de groupware provendo plataformas de suporte e um conjunto de componentes ou serviços que podem ser utilizados e combinados para formar sistemas de groupware. Em um sistema de groupware é desejável que o desenvolvedor seja capaz de adicionar novas funções sem interferir nas funções existentes e de compor uma função selecionando e combinando outras funções básicas. A utilização de componentes para prover estas características tem sido bastante estudada [18, 19, 20, 21]. Portanto, o desenvolvimento de sistemas de groupware utilizando componentes apresenta como vantagem o reuso de funcionalidades, além da facilidade de instalação e dessas propriedades associadas aos componentes. Dentre as tecnologias utilizadas na implementação de soluções de suporte a groupware, CORBA (Common Object Request Broker Architecture) mostra-se de grande valor ao prover interoperabilidade entre aplicações implementadas em diferentes linguagens, independentemente de plataforma. CCM [8], modelo de componentes desenvolvido pela OMG, utiliza CORBA como infraestrutura. Assim, uma vez que o desenvolvimento de aplicações cooperativas está sendo direcionado à utilização de componentes de software e pelo fato de CORBA ser uma arquitetura largamente empregada na construção de aplicações distribuídas, CCM apresenta-se como um modelo de componentes adequado para ser utilizado no suporte a construção de aplicações cooperativas distribuídas.. 14.

(25) 2.4. Suporte ao Desenvolvimento de Groupware. Na literatura podem ser encontrados trabalhos relacionados a ferramentas, plataformas e ambientes de suporte ao desenvolvimento de groupware. Comum a todos eles, há a preocupação em fornecer meios que facilitem o desenvolvimento de aplicações cooperativas. A seguir são descritos os de maior relevância. GroupKit [22] é uma plataforma utilizada no desenvolvimento de sistemas de conferência síncronos e distribuídos. A sua infra-estrutura de execução é composta por três processos principais: • Registrar : primeiro processo criado em uma sessão GroupKit. Este processo mantém uma lista de todas as conferências e dos usuários que fazem parte delas, atuando como um ponto de contato para localizar conferências existentes; • Session Manager : processo replicado (um por participante) que permite o usuário criar, remover, monitorar, entrar e sair de conferências. Este processo provê uma interface de usuário e uma política que determina como as conferências são criadas e removidas, como os usuários entram e saem das conferências e como o status da conferência é apresentado; • Conference Application: programa GroupKit criado pelo desenvolvedor da aplicação. É uma ferramenta de groupware, assim como um editor cooperativo, chat etc. COAST (COoperative Application Systems Toolkit) [23] é uma plataforma baseada em objetos utilizada no desenvolvimento de aplicações de groupware síncronas. Ela utiliza uma abordagem de arquitetura replicada na qual cada aplicação local atua em uma cópia do documento compartilhado. A arquitetura COAST é composta pelos seguintes componentes: • Session Object: coordena o acesso dos usuários a um documento compartilhado (ou a partes desse documento); • View : utilizado para visualizar o documento em uma janela; • Controller : responsável por processar as entradas do usuário realizadas através da janela; 15.

(26) • Session Manager : permite o usuário criar, entrar ou sair das sessões; • User Objects: representam os usuários concorrentes do documento e são utilizados pelos session objects para manter a lista dos seus usuários; • Transaction Manager : garante a integridade dos objetos compartilhados; • Replication Manager : responsável pela sincronização dos objetos replicados. EVOLVE [24, 25] é uma plataforma baseada em componentes cujo objetivo é prover um ambiente de execução na internet para instalação de groupware. Ela adota uma arquitetura cliente-servidor e os componentes EVOLVE são implementados utilizando Flexibeans, uma extensão do modelo de componentes JavaBeans. Flexibeans estende JavaBeans com conceitos de named ports, shared objects e remote interactions. DISCIPLE (DIstributed System for Collaborative Information Processing and LEarning) [26, 27] é um framework que possibilita o compartilhamento de aplicações JavaBeans em um ambiente de trabalho em grupo síncrono e em tempo-real. DISCIPLE apresenta uma arquitetura cliente-servidor cujo objetivo é fornecer um conjunto de ferramentas para o desenvolvimento de aplicações cooperativas de propósito especial e um framework para o compartilhamento de aplicações monousuário existentes. DyCE (Dynamic Collaboration Environment) [28] é um framework Java baseado em componentes que possibilita o desenvolvimento de componentes colaborativos (componentes de groupware). Os componentes desenvolvidos através deste framework podem ser distribuídos através da internet, usados colaborativamente e combinados com outros componentes para construir novos ambientes de suporte à colaboração.. 2.5. Considerações Finais. Nesse capítulo foram apresentadas as características e os principais conceitos relacionados às aplicações cooperativas síncronas distribuídas. Inicialmente, foi realizada uma visão geral sobre as aplicações cooperativas (groupware) e a área que estuda tais aplicações (CSCW). Funções genéricas que devem ser fornecidas por 16.

(27) groupwares e duas possíveis classificações para esse tipo de aplicação foram apresentadas. Em seguida, foram descritas aplicações cooperativas síncronas, que permitem a interação de usuários através de sessões cooperativas. Também foram descritos os mecanismos necessários para o gerenciamento das sessões e para o controle do acesso aos recursos compartilhados pelos participantes da sessão. Posteriormente, as aplicações cooperativas baseadas em componentes foram apresentadas, seguidas do uso de CCM na implementação de soluções de suporte a groupware. Finalmente, foram apresentadas algumas plataformas de suporte ao desenvolvimento de aplicações cooperativas. O próximo capítulo apresenta uma visão geral sobre o modelo CCM, além de descrever o processo de desenvolvimento de um componente CCM.. 17.

(28) Capítulo 3. Desenvolvendo Aplicações Distribuídas Utilizando CCM O CCM (CORBA Component Model ) [8] representa um modelo de componente do lado do servidor, cuja finalidade é facilitar o desenvolvimento e a instalação de aplicações distribuídas compostas por componentes heterogêneos. Ele foi desenvolvido pela OMG (Object Management Group) [7] com o objetivo de suprir as limitações presentes no modelo de objeto CORBA (Common Object Request Broker Architecture) [6], tais como: falta de um mecanismo padrão para implantação dos objetos; suporte limitado à programação de servidores CORBA; falta de flexibilidade para estender as funcionalidades dos objetos; falta de um gerenciamento padrão do ciclo de vida dos objetos. Este capítulo apresenta o CCM, descrevendo suas principais características e funcionalidades. Por ser uma versão bem resumida da especificação, seu objetivo principal é situar o leitor no contexto do CCM, apresentando de forma simplificada a potencialidade desse modelo de componente. O capítulo está organizado da seguinte forma: a Seção 3.1 apresenta a arquitetura CORBA, descrevendo seus principais elementos; a Seção 3.2 apresenta uma visão geral do CCM; a Seção 3.3 descreve o processo de desenvolvimento de um componente CCM; a Seção 3.4 explica como um componente é acessado pelo cliente; a Seção 3.5 apresenta uma breve comparação entre o modelo de objetos do CORBA e o CCM, além de citar algumas das implementações do CCM 18.

(29) existentes; e a Seção 3.6 apresenta as considerações finais relacionadas a esse capítulo.. 3.1. Elementos da Arquitetura CORBA. Grande parte dos ambientes de computação distribuída são heterogêneos, sendo compostos por diferentes plataformas de hardware, sistemas operacionais, tecnologias de rede e linguagens de programação. A necessidade de promover a interoperabilidade entre as diversas aplicações construídas utilizando esses ambientes ocasionou o surgimento do middleware. Como pode ser visualizado na Figura 3.1, middleware é uma camada de software localizada entre o sistema operacional e a aplicação. Responsável por gerenciar a complexidade e a heterogeneidade existente, o middleware fornece serviços que facilitam o desenvolvimento de aplicações distribuídas [29]. Ele provê transparência de localização e independência dos detalhes de protocolos de comunicação, sistemas operacionais e plataformas de hardware. Host 1. Host 2 Aplicação Distribuída. Aplicação Distribuída. Middleware. Middleware. Sistema Operacional. Sistema Operacional. Rede. Figura 3.1: Middleware.. CORBA é um middleware que apresenta independência de linguagem e de plataforma, permitindo a comunicação entre aplicações distintas, não importando a linguagem em que foram implementadas e o sistema operacional no qual estão sendo executadas. Além disso, com o surgimento cada vez maior de novas tecnologias, as grandes empresas necessitam de mecanismos que promovam a integração entre os diversos sistemas legados e aqueles construídos utilizando novas plataformas de desenvolvimento. CORBA surge como uma solução para proporcionar essa integração.. 19.

(30) A Figura 3.2 apresenta o processo de desenvolvimento de uma aplicação CORBA utilizando a estratégia estática. Como pode ser observado, primeiramente define-se em IDL(Interface Definition Language) a interface do objeto CORBA. Em seguida, essa definição é submetida ao compilador IDL, a partir do qual são gerados os stubs e os skeletons da aplicação. Os stubs, juntamente com o código que implementa o cliente, são submetidos ao compilador da linguagem na qual foram implementados. Da mesma forma, os skeletons, assim como o código que implementa as funcionalidades do objeto servidor, são submetidos ao compilador da linguagem em que foram implementados. Como resultado final, obtém-se o programa cliente e o programa servidor. É necessário, entretanto, que o servidor seja iniciado, para a partir de então receber as requisições do cliente. Arquivo IDL. Compilador IDL. Código do Cliente. Stubs. Skeletons. Código do Servidor. Compilador da Linguagem de Programação. Compilador da Linguagem de Programação. Programa Cliente. Programa Servidor. Figura 3.2: Processo de Desenvolvimento de uma Aplicação CORBA.. A Figura 3.3 apresenta os elementos que compõem o modelo de referência CORBA. Eles são responsáveis por garantir características fundamentais ao desenvolvimento de aplicações distribuídas, como portabilidade, interoperabilidade e transparência [1].. 20.

(31) Aplicação Cliente. Stub. DII. Implementação do Objeto Servidor. Interface do ORB. Interface do ORB. Skeleton. DSI. Adaptador de Objeto. Núcleo do ORB Servidor. Núcleo do ORB Cliente. Rede. Figura 3.3: Componentes do Modelo de Referência CORBA [1].. A seguir serão descritos cada um dos elementos que fazem parte do modelo de referência CORBA ilustrado na Figura 3.3.. 3.1.1. ORB. O ORB (Object Request Broker ) é o elemento principal da arquitetura CORBA, responsável por mediar a comunicação entre o cliente e o servidor. Sua função é interceptar a requisição realizada pelo cliente e repassá-la ao objeto que implementa o serviço solicitado. Uma das características do ORB é permitir que as requisições sejam realizadas de forma transparente. Isso significa que independente da localização do objeto, da linguagem e do sistema operacional no qual ele foi desenvolvido, o cliente é capaz de acessar os métodos do objeto servidor.. 3.1.2. IDL. A IDL (Interface Definition Language) é a linguagem utilizada para descrever a interface dos objetos CORBA, permitindo especificar os métodos (serviços) oferecidos, além dos parâmetros usados na invocação dos mesmos. Devido ao fato de ser uma linguagem apenas descritiva, é necessário que as descrições em IDL sejam mapeadas em alguma linguagem de programação. Este mapeamento consiste no mapemaneto dos tipos IDL nos tipos correspondentes da linguagem de programação utilizada. Atualmente, existe o mapeamento de IDL para Ada, C, C++, COBOL,. 21.

(32) CORBA Scripting Language, Java, Lisp, PL/1, Python, Smalltalk, entre outras. Com a separação entre interface e implementação, é possível a comunicação entre objetos implementados nas diversas linguagens citadas acima.. 3.1.3. Stub e Skeleton. O stub e o skeleton são estruturas geradas pelo compilador IDL a partir das descrições das interfaces dos objetos CORBA. O stub localiza-se no cliente e tem como característica criar e enviar as requisições realizadas pelo cliente ao servidor. Enquanto o skeleton localiza-se no servidor e tem como função repassar as requisições para a implementação do objeto (servant) de forma que possam ser processadas. Durante o processo de criação e envio, o stub converte as operações juntamente com os parâmetros em um formato de mensagem que possa ser enviado ao servidor (marshalling). No servidor, o skeleton realiza o processo inverso, ou seja, reconstrói, a partir da mensagem recebida, a requisição realizada pelo cliente (unmarshalling) e repassa-a para o servant. Vale ressaltar que os stubs e skeletons são estruturas utilizadas quando as aplicações CORBA são desenvolvidas utilizando-se a estratégia estática.. 3.1.4. Adaptador de Objeto. O adaptador de objeto trabalha em conjunto com o ORB, direcionando a requisição do cliente para o servant que implementa o serviço requisitado. O POA (Portable Object Adapter ) é um tipo de adaptador de objeto, especificado pela OMG com o objetivo de prover portabilidade entre ORBs de diferentes fabricantes. Dentre as funcionalidades do adaptador de objetos, podem ser citadas [1]: • Gerar referências a objetos - o adaptador de objeto é responsável pela criação do objeto CORBA, associando a ele uma referência que os clientes utilizam para realizar as requisições. Esta referência contém informações sobre endereçamento, possibilitando assim a localização do objeto.. 22.

(33) • Mapear referências a objetos nos seus respectivos servants - dentre as informações contidas na referência gerada pelo POA, há um identificador (ObjectID) que determina a qual servant o objeto está associado. Ao receber a requisição, o POA utiliza o ObjectID para localizar o servant correspondente. • Colaborar com os skeletons para invocar operações nos servants - após localizar o servant, o adaptador, auxiliado pelos skeletons, transfere para ele a chamada ao método. • Ativar e desativar servants - o adaptador de objeto tem a função de ativar objetos CORBA para que possam atender as requisições dos clientes. Da mesma forma, são responsáveis por desativá-los quando não são mais necessários, economizando, assim, recursos de memória.. 3.1.5. DII. O ORB, como pode ser visto na Figura 3.3, é um barramento de software que possibilita a comunicação entre o cliente e o servidor. O cliente requisita um serviço, sendo de responsabilidade do ORB redirecionar a requisição para o servidor. A requisição pode ser realizada estaticamente, através dos stubs, ou utilizando interfaces dinâmicas (DII - Dynamic Invocation Interface). O mecanismo de DII permite que os clientes acessem um objeto CORBA sem que conheçam a interface dele em tempo de compilação. Nesse caso, o cliente obtém uma referência para o objeto e realiza as chamadas aos métodos construindo as requisições dinamicamente.. 3.1.6. DSI. A partir do momento em que o ORB intercepta a requisição, é sua função localizar o objeto que implementa o serviço solicitado. Através da referência utilizada pelo cliente, o ORB identifica o POA que gerencia o objeto cujo método foi invocado. O POA, por sua vez, é responsável por identificar e transferir a chamada do método para o servant. Essa transferência pode ocorrer de duas maneiras: através dos skeletons, gerados a partir das descrições em IDL, ou através de DSI (Dynamic Skeleton Interface). Utilizando DSI, as operações que o objeto CORBA provê podem ser implementadas sem que a sua interface seja conhecida em tempo de compilação. 23.

(34) 3.2. Visão Geral do CCM. Como descrito na seção anterior, a arquitetura CORBA é composta por diversos elementos responsáveis por garantir características fundamentais ao desenvolvimento de aplicações distribuídas. Contudo, o modelo de objetos CORBA apresenta limitações, dentre as quais podem ser citadas [30]: • Falta de um mecanismo padrão para implantação dos objetos: as versões anteriores da especificação CORBA não definem um mecanismo padrão para a implantação das implementações dos objetos; • Suporte limitado à programação de servidores CORBA: um exemplo é o caso do POA. Grande parte das aplicações utilizam apenas um pequeno subconjunto das funcionalidades que o POA fornece, entretanto, o desenvolvedor deve conhecer muitas de suas políticas para desenvolver tais aplicações; • Falta de flexibilidade para estender as funcionalidades dos objetos: no modelo de objetos CORBA, os objetos só podem ser estendidos através de herança. Assim, para prover novas interfaces, deve-se definir uma nova interface para o objeto (que herda todas as interfaces requeridas), em seguida implementá-la e, por fim, implantar a sua implementação nos servidores; • Falta de um gerenciamento padrão do ciclo de vida dos objetos: apesar do CORBA Object Service definir um serviço para o gerenciamento do ciclo de vida dos objetos, seu uso não é obrigatório, fazendo com que os clientes geralmente gerenciem o ciclo de vida dos objetos explicitamente. Com a finalidade de suprir essas limitações, a OMG definiu o modelo de componente CCM, que faz parte da versão 3.0 da especificação CORBA lançada em 2002. O CCM estende o modelo de objeto CORBA, definindo características e serviços que permitem aos desenvolvedores implementar, gerenciar, configurar e instalar componentes - que integram serviços comumente usados, como transação, segurança e persistência - em um ambiente padronizado [30]. O CCM é dividido em dois níveis de componentes: 24.

(35) • componentes básicos - provêem uma forma simples de transformar um objeto CORBA em componente; • componentes estendidos - fornecem um conjunto maior de funcionalidades, como as portas de comunicação, que representam pontos de conexão entre os componentes. A especificação do CCM é estruturada em cinco modelos, descritos a seguir. Modelo Abstrato O modelo abstrato provê mecanismos para definição de componentes, permitindo especificar através da IDL seus atributos e suas portas de comunicação. Além disso, o modelo abstrato também permite definir as homes, responsáveis por gerenciar o ciclo de vida das instâncias dos componentes. A IDL através da qual os componentes são definidos corresponde a uma extensão da IDL do CORBA 2.x, criada de forma a abranger conceitos relacionados a componentes, como portas, homes etc. Para um melhor entendimento do texto, de agora em diante será utilizada a seguinte terminologia: IDL3 corresponde à IDL estendida; IDL2 representa a IDL do CORBA 2.x. Modelo de Programação Este modelo é composto por dois elementos principais: CIDL (Component Implementation Definition Language) e CIF (Component Implementation Framework ). CIDL é uma linguagem utilizada para descrever a estrutura de implementação do componente. Estas descrições são utilizadas pelo CIF para gerar, por exemplo, o código referente aos requisitos não-funcionais da aplicação, como: (des)ativação, gerenciamento de estado, gerenciamento do ciclo de vida do componente etc. Outra funcionalidade do CIF é possibilitar a cooperação entre a parte funcional da aplicação, implementada pelo desenvolvedor, e a parte não-funcional gerada pelo framework a partir das descrições em IDL3 e em CIDL.. 25.

(36) Modelo de Empacotamento O modelo de empacotamento especifica como os componentes e suas implementações devem ser empacotados. Estes pacotes são arquivos ZIP contendo as implementações do componente e os descritores (ver Seção 3.3.3) utilizados na fase de instalação da aplicação. Modelo de Instalação Este modelo define um mecanismo padrão para a instalação de aplicações. A instalação é realizada através de pacotes que contêm os descritores e as implementações do componente. Modelo de Execução O modelo de execução define o ambiente de execução - container - para as instâncias do componente. O container simplifica o desenvolvimento, a instanciação e a execução dos componentes, e é responsável por: ativar e desativar componentes; gerenciar os aspectos não-funcionais da aplicação; gerenciar o POA associado ao componente etc.. 3.3. Desenvolvendo Componentes CCM. A Figura 3.4 apresenta o processo de produção de um componente CCM. Primeiramente são realizadas as descrições em IDL3 e em CIDL. As descrições em IDL3 são mapeadas para IDL2 e, em seguida, submetidas ao compilador IDL, responsável por gerar os stubs e os skeletons. O compilador CIDL recebe como entrada as declarações em CIDL e em IDL3 e, a partir delas, gera os skeletons (que automatizam muitos dos comportamentos básicos do componente) e o descritor do componente. Em seguida, os desenvolvedores acrescentam o código do componente. Esse código, juntamente com os skeletons gerados, são submetidos ao compilador da linguagem na qual o componente está sendo implementado, obtendo-se, dessa forma, uma implementação do componente. A implementação e o descritor gerados são colocados em um pacote de software, e a partir desse momento o componente está pronto para ser distribuído e instalado.. 26.

(37) Arquivo CIDL. Arquivo IDL3. Compilador CIDL. Compilador IDL. Skeleton do Componente. Código do Componente. Skeleton do Servidor. Compilador da Linguagem de Programação. Descritor do Componente. Implementação do Componente. Pacote. Figura 3.4: Processo de Desenvolvimento de um Componente CCM.. A seguir, serão descritas as fases envolvidas no processo de criação de um componente CCM, abrangendo desde a definição do componente até a sua execução, englobando as etapas de implementação, empacotamento e instalação.. 3.3.1. Definindo Componentes. Como mencionado na Seção 3.2 (Modelo Abstrato), um componente é definido utilizando-se a IDL3. A fim de se obter a implementação de um componente, é necessário que as definições em IDL3 sejam mapeadas em IDL2 para, então, serem gerados os skeletons da aplicação. Dessa forma, cada construção em IDL3 tem sua regra de mapeamento para IDL2. A definição de um componente agrupa a definição de suas interfaces (portas) e dos atributos utilizados para configurá-lo. Como pode ser observado na Figura 3.5, as portas, utilizadas durante a instalação e em tempo de execução para conectar os componentes da aplicação, podem ser de quatro tipos: • facetas: correspondem às interfaces oferecidas pelo componente para acesso aos seus serviços; • receptáculos: representam referências para outros objetos com os quais o componente in27.

(38) terage, e através dessas referências o componente pode invocar operações; • produtores de eventos: utilizados pelo componente para produzir eventos de um determinado tipo; • consumidores de eventos: utilizados pelo componente para consumir eventos de um tipo específico.. Figura 3.5: Portas de Comunicação de um Componente CCM.. Como citado anteriormente (ver Seção 3.2), um componente básico é utilizado para transformar um objeto CORBA em um componente. No entanto, componentes básicos não suportam o conceito de portas, apenas definições de atributos. As definições de facetas, receptáculos, produtores e consumidores de eventos são possíveis apenas nos componentes estendidos. A cada definição de componente em IDL3 está associada uma interface equivalente em IDL2, que expõe as funcionalidades do componente aos clientes. O componente é identificado por uma referência que suporta a sua interface equivalente. Essa referência é então utilizada pelos clientes para acessar as funcionalidades expostas pelo componente. A seguir, será apresentado como cada um dos elementos que compõem a definição de um componente é descrito em IDL3 e o mapeamento dessas descrições para a interface equivalente em IDL2.. 28.

(39) Componente Um componente é definido utilizando-se a palavra-chave component. Na definição de um componente pode-se estabelecer que o mesmo herda de um outro componente e que suporta determinadas interfaces. Vale ressaltar que componentes básicos não suportam herança, apenas componentes estendidos possuem essa característica. A Figura 3.6 apresenta a declaração simples de um componente, bem como a interface equivalente resultante do mapeamento para IDL2. IDL3: component <nomeComponente>{...} IDL2: interface <nomeComponente>:Components::CCMObject{...}. Figura 3.6: Declaração Simples de um Componente em IDL3 e seu Mapeamento para IDL2.. Em sua definição, o componente pode declarar o suporte a determinadas interfaces. Nesse caso, a implementação do componente deve prover as implementações das operações contidas nessas interfaces. Esse tipo de declaração possui a sintaxe ilustrada na Figura 3.7. IDL3: component <nomeComponente> supports <interface1>, <interface2>{...} IDL2: interface <nomeComponente>:Components::CCMObject, <interface1>, <interface2>{...}. Figura 3.7: Declaração de um Componente que Suporta Interfaces.. Um componente pode herdar funcionalidades de um outro componente. Isso é determinado através da declaração apresentada na Figura 3.8. IDL3: component <nomeComponente>:<componenteBase>{...} IDL2: interface <nomeComponente>:<componenteBase>{...}. Figura 3.8: Declaração de Herança entre Componentes.. Há uma outra declaração através da qual o componente herda de um outro componente e 29.

(40) suporta determinadas interfaces. Essa declaração é apresentada na Figura 3.9. IDL3: component <nomeComponente>:<componenteBase> supports <interface1>, <interface2>{...} IDL2: interface <nomeComponente>:<componenteBase>, <interface1>, <interface2>{...}. Figura 3.9: Declaração Conjunta de Herança e de Suporte a Interfaces.. Faceta A faceta corresponde a um determinado serviço fornecido pelo componente. Através das facetas, o componente pode apresentar vários comportamentos, estando cada comportamento relacionado a uma faceta. A declaração de uma faceta é realizada através da palavra-chave provides e possui a sintaxe apresentada na Figura 3.10. IDL3: provides <tipoInterface> <nomeFaceta> IDL2: <tipoInterface> provide_<nomeFaceta>(). Figura 3.10: Definição de uma Faceta em IDL3 e seu Mapeamento para IDL2.. Como pode ser observado na Figura 3.10, a seguinte operação é definida na interface equivalente do componente, como resultado do mapeamento. • provide_<nomeFaceta>: retorna a referência da faceta correspondente. Receptáculo Os receptáculos representam pontos de conexão entre os componentes. Eles permitem que um componente aceite uma referência - seja a referência para uma faceta, para um componente ou até mesmo para um objeto CORBA - de forma a utilizar as operações que a mesma provê. Quando um componente aceita uma referência dessa maneira, o relacionamento entre o componente e a referência é denominado conexão. 30.

(41) Os receptáculos podem ser de dois tipos: simples - apenas uma referência conectada por vez; múltiplos - várias referências podem estar conectadas ao mesmo tempo. Um receptáculo é declarado utilizando-se a palavra-chave uses e sua declaração pode ser de dois tipos, dependendo do tipo do receptáculo. IDL3: uses <tipoInterface> <nomeReceptaculo> IDL2: void connect_<nomeReceptaculo>(in <tipoInterface> conexao) raises(Components::AlreadyConnected, Components::InvalidConnection) <tipoInterface> disconnect_<nomeReceptaculo>() raises(Componnets::NoConnection) <tipoInterface> get_connection_<nomeReceptaculo>(). Figura 3.11: Definição de um Receptáculo Simples em IDL3 e seu Mapeamento para IDL2.. IDL3: uses multiple <tipoInterface> <nomeReceptaculo> IDL2: Components::Cookie connect_<nomeReceptaculo>(in <tipoInterface> conexao) raises(Components::ExceededConnectionLimit, Components::InvalidConnection) <tipoInterface> disconnect_<nomeReceptaculo>(in Components::Cookie ck) raises(Componnets::InvalidConnection) <nomeReceptaculo>Connections get_connections_<nomeReceptaculo>(). Figura 3.12: Definição de um Receptáculo Múltiplo em IDL3 e seu Mapeamento para IDL2.. A Figura 3.11 e a Figura 3.12 apresentam, respectivamente, a sintaxe da declaração de um receptáculo simples e de um receptáculo múltiplo. As seguintes operações são definidas na interface equivalente do componente, como resultado do mapeamento da declaração de um receptáculo em IDL3. • connect_<nomeReceptaculo>: conecta o componente à referência passada como parâmetro. Caso o receptáculo seja múltiplo, essa operação retorna um cookie que identifica a conexão e que é utilizado posteriormente para desfazer a conexão estabelecida. • disconnect_<nomeReceptaculo>: desconecta o componente da referência a qual ele está conectado. Caso o receptáculo seja múltiplo, o cookie que identifica a conexão deve ser 31.