Gerenciando Dados de Aplicac¸o˜ es Colaborativas Distribu´ıdas em Ambientes Baseados na Arquitetura TEAM Luiz A. M. Pereira1 , Sean W. M. Siqueira1 , F´abio A. M. Porto2 , Rubens N. Melo1 1
Departamento de Inform´atica Pontif´ıcia Universidade Cat´olica do Rio de Janeiro (PUC-Rio) 2´
Ecole Polytechnique F´ed´erale de Lausanne - IC/LBD - Suisse
{lpereira,sean,rubens}@inf.puc-rio.br,
[email protected]
Abstract. In distributed collaborative applications, the use of centralized repositories to store shared data and programs compromises important characteristics of these applications, such as fault tolerance, scalability and local autonomy. In applications like Kazaa and Edutella, peer-to-peer (P2P) computing is being regarded as an interesting alternative to solve the problems aforementioned, without imposing the typical restrictions of centralized, mediator-based or heterogeneous distributed DBMS systems. In this paper we will present our architectural model called TEAM (Teamworksupport Environment Architectural Model), which is based on P2P computing, focusing the aspects of data, metadata and control information management in distributed collaborative applications. We also examine the strategy adopted to disseminate queries and messages throughout the peers in a TEAM-based network. We illustrate the employment of the architecture by applying it in an e-learning environment. Resumo. Em aplicac¸o˜ es colaborativas distribu´ıdas, o uso de reposit´orios centralizados para armazenamento dos dados e programas compartilhados compromete algumas caracter´ısticas importantes desse tipo de aplicac¸o˜ es, tais como tolerˆancia a falhas, escalabilidade e autonomia local. Em aplicac¸o˜ es como Kazaa e Edutella, a computac¸a˜ o ponto-a-ponto (P2P) tem se mostrado uma alternativa interessante na soluc¸a˜ o dos problemas apontados acima, sem impor as restric¸o˜ es t´ıpicas de sistemas centralizados, ou mesmo distribu´ıdos do tipo mediadores e SGBDHs. Nesse trabalho iremos apresentar nossa arquitetura chamada TEAM (Teamwork-support Environment Architectural Model), que se baseia em computac¸a˜ o P2P, enfocando os aspectos de gerˆencia dos dados, metadados e das informac¸o˜ es de controle de execuc¸a˜ o dos processos em aplicac¸o˜ es colaborativas distribu´ıdas. Exploramos, tamb´em, a estrat´egia adotada para disseminac¸a˜ o das consultas e mensagens encaminhadas aos pares da rede. Ilustraremos o emprego da arquitetura TEAM atrav´es de uma aplicac¸a˜ o em um ambiente de e-learning.
1. Introduc¸a˜ o Em aplicac¸o˜ es colaborativas distribu´ıdas, o uso de reposit´orios centralizados para armazenamento dos dados e programas compartilhados compromete algumas caracter´ısticas importantes desse tipo de aplicac¸o˜ es, tais como tolerˆancia a falhas, escalabilidade e autonomia local. A popularizac¸a˜ o dos sistemas de trocas de arquivos na Internet (e.g., Napster, Kazaa, Soulseek) e as redes de compartilhamento de recursos computacionais (grades),
evidenciaram quest˜oes importantes como garantia de QoS, replicac¸a˜ o de dados, gerˆencia distribu´ıda de cat´alogos e integrac¸a˜ o de esquemas. Com isso, a computac¸a˜ o ponto-aponto (ou par-a-par – peer-to-peer – P2P) tornou-se um t´opico relevante de pesquisa. O paradigma P2P introduz um princ´ıpio arquitetural que substitui o paradigma de computac¸a˜ o cliente-servidor, baseando-se no conceito de descentralizac¸a˜ o, compartilhamento de recursos e distribuic¸a˜ o de carga de trabalho em larga escala, sem impor as restric¸o˜ es t´ıpicas de sistemas centralizados, ou mesmo distribu´ıdos do tipo mediadores e SGBDHs. Por isso, computac¸a˜ o P2P e´ considerada pelos pesquisadores como uma alternativa interessante para soluc¸a˜ o dos problemas de tolerˆancia a falhas, escalabilidade e autonomia local. Uma aplicac¸a˜ o que apresenta essas caracter´ısticas e´ ensino eletrˆonico a distˆancia – e-learning – dentro do contexto do projeto PGL1 . Nessa aplicac¸a˜ o, grupos distribu´ıdos de aprendizes colaboram entre si e com seus instrutores na realizac¸a˜ o de programas de aprendizado. Adicionalmente, diferentes instituic¸o˜ es de ensino desenvolvem conte´udos de aprendizado, para aplicac¸a˜ o a distˆancia, que poderiam ser compartilhados com outras instituic¸o˜ es do projeto. Nesse contexto, os dados dos conte´udos de aprendizado e as atividades de ensino s˜ao tratados de forma distribu´ıda e colaborativa. Outras caracter´ısticas dessa aplicac¸a˜ o s˜ao autonomia local sobre esses dados, heterogeneidade dos esquemas locais de bancos de dados e um n´umero vari´avel, por´em acordado, de colaboradores. Do ponto de vista da aplicac¸a˜ o, os requisitos funcionais s˜ao os mesmos para todos os colaboradores. Identificamos, desta forma, a aplicabilidade da arquitetura P2P, na medida em que ela oferece escalabilidade ao ambiente, participac¸a˜ o colaborativa e, ao mesmo tempo, preserva a autonomia de seus participantes. Adicionalmente, a caracter´ıstica colaborativa e n˜ao estruturada da atividade de aprendizado aponta para a adoc¸a˜ o de t´ecnicas de workflow. Trabalhos como [Cesarini et al., 2004, Mehlecke and Tarouco, 2003, Santoro et al., 2003] fundamentam e corroboram, direta ou indiretamente, a validade de nossas conclus˜oes. Essas caracter´ısticas s˜ao compartilhadas por uma classe de aplicac¸o˜ es em outros contextos, como, por exemplo, em Business-To-Business – B2B. Nesse trabalho apresentamos uma arquitetura de prop´osito amplo baseada em ` essa computac¸a˜ o P2P e workflows, para aplicac¸o˜ es colaborativas e distribu´ıdas. A arquitetura demos o nome de TEAM (Teamwork-support Environment Architectural Model – Modelo Arquitetural para Ambientes de Suporte ao Trabalho em Equipe). TEAM provˆe a` s aplicac¸o˜ es uma vis˜ao uniforme e integrada de dados e metadados, expressa segundo o modelo XML, al´em de autonomia e flexibilidade dos participantes na realizac¸a˜ o de tarefas colaborativas. Embora as quest˜oes associadas ao armazenamento, replicac¸a˜ o, consistˆencia, confiabilidade, disponibilidade e consultas a dados, feitas em sistemas P2P, se assemelhem conceitualmente a` s de BDs distribu´ıdos, elas est˜ao em contraste, pelas ausˆencias de um esquema e de sua administrac¸a˜ o centralizados [Gribble et al., 2001]. Nesse trabalho enfocamos, al´em de como e quais dados s˜ao geridos, como seus cat´alogos s˜ao estruturados e como as consultas e mensagens s˜ao encaminhadas aos pares da rede em aplicac¸o˜ es baseadas na arquitetura TEAM. O restante deste trabalho encontra-se estruturado da seguinte forma: na sec¸a˜ o 2 iniciamos com uma breve apresentac¸a˜ o dos conceitos e definic¸o˜ es que ser˜ao usadas ao longo do artigo. Em seguida descreveremos a arquitetura e o ambiente operacional 1
Partnership in Global Learning – mais detalhes sobre o projeto podem ser encontrados em http://grove.ufl.edu/ pgl/index.html e em [Pereira and Melo, 2003].
TEAM. Na sec¸a˜ o 3 trataremos das quest˜oes relativas a` gerˆencia dos dados em ambientes TEAM, que s˜ao o foco desse trabalho. Na sec¸a˜ o 4 faremos a apresentac¸a˜ o das caracter´ısticas de nossa proposta de um ambiente para e-learning para o projeto PGL, a t´ıtulo de ilustrac¸a˜ o de um ambiente distribu´ıdo e colaborativo baseado na arquitetura. Finalmente, na sec¸a˜ o 5, faremos a conclus˜ao do trabalho.
2. O Ambiente e a Arquitetura TEAM 2.1. Conceitos e Definic¸o˜ es As duas principais tecnologias a` s quais fazemos referˆencias nesse trabalho s˜ao workflows e redes P2P, cujas caracter´ısticas principais descreveremos a seguir. 2.1.1. Workflows. Segundo a Workflow Management Coalition - WfMC [Hollingsworth, 1995], workflow e´ a automac¸a˜ o de um processo2 de neg´ocio, por inteiro ou por partes, durante o qual documentos, informac¸o˜ es e atividades s˜ao passadas de um participante para outro para que estes desenvolvam ac¸o˜ es respeitando um conjunto de regras procedimentais. Embora a WfMC considere a possibilidade de um workflow ser manualmente organizado, na pr´atica a maioria deles o e´ dentro do contexto de um sistema de TI, para prover suporte computadorizado a` s suas automac¸o˜ es procedimentais. As atividades podem ser executadas em seq¨ueˆ ncia ou simultaneamente, por diferentes indiv´ıduos, ou pela combinac¸a˜ o dos dois. Sistemas de Gerˆencia de Workflows – SGWs – s˜ao, em geral, ferramentas colaborativas e provˆeem a automac¸a˜ o procedimental de workflows, gerenciando a seq¨ueˆ ncia de atividades de trabalho, verificando dependˆencias entre tarefas, disponibilidade de recursos e chamando ou invocando esses recursos (humanos e/ou eletrˆonicos) que est˜ao ou s˜ao associados a` s v´arias atividades que comp˜oem o processo [Alonso and Schek, 1996]. SGWs definem, gerenciam e executam completamente workflows, atrav´es da execuc¸a˜ o de software baseada em uma representac¸a˜ o da l´ogica ou modelo (dados, operac¸o˜ es e regras) do workflow no computador. 2.1.2. Redes P2P. Comunicac¸a˜ o ponto-a-ponto, em sua forma mais simples, e´ usualmente estruturada como um sistema de comunicac¸a˜ o um-para-um intermediado por um mecanismo de comutac¸a˜ o. Schollmeier [Schollmeier, 2001] considera que uma arquitetura de rede distribu´ıda pode ser chamada de rede ponto-a-ponto (P-to-P, P2P,...) se os participantes (os chamados pares) compartilham parte de seus pr´oprios recursos de hardware (poder de processamento, capacidade de armazenamento, capacidade de comunicac¸a˜ o por rede, impressoras, etc.). Esses recursos compartilhados s˜ao necess´arios para provimento do servic¸o e do conte´udo oferecido pela rede (e.g. compartilhamento de arquivos ou contextos de trabalho para colaborac¸a˜ o). Esses recursos s˜ao acess´ıveis por outros pares diretamente, sem a intermediac¸a˜ o de outras entidades. Os participantes de uma rede como essa s˜ao provedores e consumidores dos recursos da rede (servic¸os e conte´udos). Schollmeier ainda menciona o termo ”servent”, que e´ a junc¸a˜ o de partes das palavras server e client, para expressar a fus˜ao dos conceitos a elas relacionados, conceitos esses que est˜ao associados aos pap´eis que os participantes desempenham em uma rede P2P 2
Baseados em [Lonchamp, 1993], entendemos que um processo e´ um conjunto definido de passos parcialmente ordenados para a consecuc¸a˜ o de um objetivo.
(pois s˜ao, ao mesmo tempo, clientes e servidores). Essa e´ a mais importante diferenc¸a entres sistemas P2P e sistemas cliente-servidor. S˜ao trˆes as caracter´ısticas importantes para os membros de um grupo de pares [Graham, 2001]: 1. Pares solicitam servic¸os e consomem recursos da rede mas, tamb´em, a ela prestam servic¸os e provˆeem recursos; 2. Devem possuir um esquema de enderec¸amento que independa de servic¸os de intermedi´arios (e.g. DNS); 3. Devem ser capazes de estabelecer conex˜oes nessas bases com um n´umero vari´avel de outros pares da rede. 2.2. O Ambiente TEAM O ambiente e´ formado por uma rede de instituic¸o˜ es parceiras que contribuem para a manutenc¸a˜ o de um reposit´orio distribu´ıdo de objetos de neg´ocio a serem compartilhados por todas as instituic¸o˜ es da rede. Os executores dos processos participar˜ao de forma cooperativa, guiados por um sistema de gerˆencia de workflow capaz de lidar, de forma transparente, com a distribuic¸a˜ o, autonomia e heterogeneidade tecnol´ogica dos reposit´orios de objetos que est˜ao sob dom´ınio dos parceiros. A unidade de processamento do ambiente e´ o par (ou peer), que opera como interface de acesso dos usu´arios ao ambiente, provˆe a autenticac¸a˜ o dos mesmos, o controle de interac¸a˜ o entre eles e o ambiente e a gerˆencia dos contextos de execuc¸a˜ o. Um s´ıtio (vide figura 2) e´ uma colec¸a˜ o l´ogica de pares que compartilham o mesmo contexto de neg´ocio. Cada usu´ario precisa estar associado a um par, ao qual chamamos de seu home peer. Um portal e´ uma das poss´ıveis URLs do s´ıtio que estabelece a associac¸a˜ o usu´ariohome peer para que este conduza o restante da interac¸a˜ o com aquele. O ambiente e´ dividido em dois escopos, interno e externo, de acordo com os pap´eis dos usu´arios. O escopo interno corresponde ao contexto de trabalho dos mantenedores do ambiente (i.e. suporte t´ecnico, desenvolvedores de aplicac¸o˜ es, administradores de bancos de dados e os desenvolvedores de objetos) e os participantes dos processos de neg´ocio associados a` s instituic¸o˜ es parceiras. Todos esses s˜ao os usu´arios internos. O escopo externo provˆe um ambiente para acesso por parte dos usu´arios que n˜ao tˆem responsabilidades espec´ıficas a um par. Usu´arios externos vˆeem o ambiente (distribu´ıdo) como uma s´o pec¸a, usando servic¸os, obtendo e fornecendo artefatos de/para o ambiente, transparentemente (independentemente) de onde est˜ao fisicamente armazenados ou para onde devem ser enviados. Os servic¸os de execuc¸a˜ o de workflows, um em cada par, provˆeem aos usu´ario externos essa vis˜ao transparente, obtendo, alocando e roteando recursos de/para os pares apropriados. A cada usu´ario e´ associado um conjunto de permiss˜oes que definem restric¸o˜ es de acesso aos objetos publicados no aˆ mbito de seus s´ıtios. Tipicamente usu´arios internos tˆem privil´egios de leitura e escrita sobre os objetos gerenciados em seus home peers (vis˜ao local) e somente privil´egio de leitura sobre os objetos de todos os demais pares. Usu´arios externos tˆem permiss˜oes de leitura sobre todos os objetos do s´ıtio e tˆem acesso transparente aos recursos dos s´ıtios nos quais seus home peers est˜ao inseridos (vis˜ao global). Outros privil´egios podem ser concedidos de acordo com as pol´ıticas de cada par.
Usuários Externos
Usuários Internos
Par 1 … Par 2 Par 4 Par 3
Usuários Internos
˜ Figura 1: Os escopos e visoes do ambiente distribu´ıdo de e-learning
A figura 1 ilustra o ambiente, mostrando os dois escopos (interno e externo) e as vis˜oes local – representada por uma associac¸a˜ o direta entre um usu´ario e um par – e global. A linha dupla cont´ınua define a fronteira entre os escopos externo e interno (provendo a vis˜ao global). A linha dupla tracejada define a vis˜ao global do ambiente, ou seja, conforme pode ser visto pelos usu´arios internos. Os reposit´orios de objetos em cada par comp˜oem uma federac¸a˜ o de bancos de ¨ dados semi-autˆonomos e fracamente acoplados [Ozsu and Valduriez, 2001]. N˜ao h´a nenhuma distinc¸a˜ o funcional entre os pares, embora admitamos que alguns pares possam servir de interfaces com grades computacionais, como descrito em [Pereira et al., 2004a, Pereira et al., 2004b]. Assumimos, tamb´em, que os pares poder˜ao adotar tecnologias diferentes para gerenciamento dos dados, assim como diferentes modelos de dados. A adic¸a˜ o de novos pares a` rede (escalabilidade) e´ poss´ıvel, bastando que um novo par se registre junto aos demais e proveja a mesma interface e as mesmas caracter´ısticas funcionais dos demais. Em nossa proposta, todos os pares participam de forma comprometida na rede no sentido de manter a estabilidade do ambiente, ou seja, n˜ao se trata de redes ad hoc. 2.3. A Arquitetura TEAM Projetamos uma arquitetura baseada no padr˜ao arquitetural cl´assico para integrac¸a˜ o de bancos de dados heterogˆeneos, consistindo de mediadores e adaptadores (wrappers) [Wiederhold, 1992]. Em uma vis˜ao conceitual macro, a arquitetura e´ composta de pares que se comunicam entre si usando infra-estrutura de comunicac¸a˜ o convencional. A figura 2 ilustra uma instˆancia simples da arquitetura formada pelos pares P1 a P7. Na figura, o sistema e´ composto de cinco s´ıtios (S´ıtio 1 a S´ıtio 5). E´ necess´ario que exista pelo menos um par operando em cada s´ıtio. Cada par e´ definido segundo uma pilha de trˆes camadas. A figura 3 ilustra um i-´esimo par gen´erico. Um navegador web ou uma aplicac¸a˜ o .NET, por exemplo, podem realizar a
Sítio 1 Sítio 4
P2
P3
P1
P7 P6 Sítio 5 Sítio 3 Sítio 2 P5
P4
˜ conceitual da arquitetura TEAM Figura 2: Visao
interface do usu´ario com o ambiente, que e´ formado por um conjunto de servic¸os web. A seta tracejada dupla representa uma poss´ıvel interface com o usu´ario realizada por uma aplicac¸a˜ o que n˜ao um navegador web. Aplicac¸o˜ es isoladas, funcionando como experts, ”tutores eletrˆonicos”, no caso de e-learning, ou agentes de software com qualquer objetivo, podem, tamb´em, interoperar com o ambiente. A linha tracejada dupla representa a interface do usu´ario com o ambiente. Se o acesso ao ambiente e´ feito via navegador, e´ usada uma camada intermedi´aria em JSP - Java Server Pages. A segunda camada corresponde ao n´ucleo operacional da arquitetura e e´ composta pelo servic¸o de execuc¸a˜ o do workflow provido pela(s) m´aquina(s) de workflow [Hollingsworth, 1995]. Cada m´aquina gerencia a porc¸a˜ o de uma instˆancia do workflow correspondente ao par em quest˜ao, processando regras e definindo conte´udos de mensagens e passos da interac¸a˜ o com os usu´arios. Os servic¸os de execuc¸a˜ o de workflows s˜ao exportados segundo um padr˜ao fac¸ade por um conjunto de servic¸os web, que formam a interface com a primeira camada, e por outro conjunto de servic¸os web, para aceitarem requisic¸o˜ es de m´aquinas de execuc¸a˜ o de outros pares da rede (interface 4, como definido pela WfMC em [Hollingsworth, 1995]). Al´em de disparar requisic¸o˜ es para outras m´aquinas de workflow atrav´es de seus servic¸os de execuc¸a˜ o, uma m´aquina pode, tamb´em, obter, e possivelmente armazenar temporariamente, objetos de outros reposit´orios na rede. As m´aquinas de workflow tamb´em s˜ao respons´aveis por sincronizar estados de execuc¸a˜ o de workflows [B¨osz¨ormenyi et al., 1999]. Conceitualmente, a camada de servic¸os de execuc¸a˜ o de workflows, al´em de ser um SGW, tamb´em atua como um ¨ mediador [Wiederhold, 1992, Ozsu and Valduriez, 2001], provendo a` camada acima a vis˜ao integrada do ambiente distribu´ıdo de execuc¸a˜ o. A camada de baixo da arquitetura provˆe persistˆencia para a camada dos servic¸os de execuc¸a˜ o de workflows. Essa camada tamb´em e´ acessada atrav´es de um conjunto de servic¸os web que fazem a interface, via JDBC, com as fontes de dados, implementadas com as tecnologias definidas para o par. Como j´a mencionamos, reposit´orios de um par podem ser acessados diretamente por m´aquinas de workflow de outros pares. A arquitetura e o ambiente s˜ao gen´ericos e podem ser instanciados para uma dada aplicac¸a˜ o como fizemos para e-learning (vide sec¸a˜ o 4).
Usuário associado ao par i
Browser Browser
Aplicação Aplicação
JSP JSP Serviços web Serviço de workflow
Serviços Serviços web web de de acesso acesso às às fontes fontes de de dados dados
Dados Metadados
Info. De controle
ˆ camadas do TEAM Figura 3: Arquitetura em tres
3. A Gerˆencia de Dados e Processamento das Consultas em TEAM 3.1. Classes de Dados Gerenciados A camada de persistˆencia (camada de baixo da figura 3) lida, a princ´ıpio, com trˆes classes de dados: metadados de objetos do neg´ocio, que s˜ao descritores em XML codificados segundo um padr˜ao escolhido (e.g. Dublin Core3 , IEEE–LOM [Learning Technology Standards Committee, 2002]), dados de objetos (e.g., formul´arios, DOCs, PDFs, Java applets) e as informac¸o˜ es de controle do workflow, compostas das definic¸o˜ es (modelos) dos workflows e dos estados de execuc¸a˜ o (ou contextos). Outras classes de dados podem ser adicionadas ao conjunto, como, por exemplo, dep´osito de ontologias objetivando a integrac¸a˜ o semˆantica entre reposit´orios de objetos de a´ reas de neg´ocios distintas. A padronizac¸a˜ o da forma de descric¸a˜ o dos objetos de neg´ocio tem especial importˆancia, pois est´a fortemente relacionada com a facilidade de pesquisa e recuperac¸a˜ o dos objetos e, por conseq¨ueˆ ncia, com a capacidade de re´uso dos mesmos. Al´em disso, a especificac¸a˜ o de um esquema conceitual comum e a implementac¸a˜ o desses metadados usando-se linguagens conhecidas (os chamados bindings), como XML, por exemplo, trar˜ao melhor grau de interoperabilidade e re´uso. O re´uso de objetos de neg´ocio tem um impacto favor´avel sobre os custos de desenvolvimento destes e, conseq¨uentemente, sobre os custos dos processos. 3.2. Gest˜ao dos Cat´alogos e Processamento das Consultas A estrat´egia de avaliac¸a˜ o de consultas feitas a um sistema P2P est´a fortemente associada a` forma como os dados est˜ao distribu´ıdos, se (e onde) h´a vis˜oes materializadas desses dados e a` forma como os cat´alogos (de metadados) s˜ao organizados. As alternativas adotadas quanto a` forma como os cat´alogos s˜ao organizados v˜ao da centralizac¸a˜ o do mesmo a` 3
Vide http://dublincore.org
manutenc¸a˜ o de diversos cat´alogos junto aos dados, ou seja, t˜ao distribu´ıdos quanto s˜ao os dados. Alternativas intermedi´arias e h´ıbridas s˜ao tamb´em poss´ıveis como, por exemplo, a clusterizac¸a˜ o ou o agrupamento em n´ıveis hier´arquicos, com e sem replicac¸a˜ o. Vantagens e desvantagens de cada uma dessas alternativas s˜ao discutidas em [Halevy et al., 2003, Madhavan and Halevy, 2003, Tatarinov et al., 2003]. Esse assunto e´ interessante e complexo, principalmente em se tratando de redes ad hoc, oferecendo muito espac¸o para pesquisas. Consideramos que um aprofundamento nessas quest˜oes n˜ao seja proveitoso nesse trabalho, na medida em que quatro das caracter´ısticas invariantes dos ambientes TEAM s˜ao (1) dizerem respeito a contextos bem definidos de neg´ocios, (2) os esquemas s˜ao os mesmos, (3) os metadados s˜ao codificados de forma padronizada e (4) e´ assumida a permanˆencia dos pares em rede, salvo em situac¸o˜ es de falhas. Em func¸a˜ o disso, nos ambientes TEAM, as buscas aos objetos s˜ao feitas sem a necessidade de traduc¸a˜ o e integrac¸a˜ o de esquemas. As consultas s˜ao iniciadas por uma dada m´aquina de workflow (uma nova instˆancia da m´aquina no par de origem) e os objetos s˜ao pesquisados atrav´es da replicac¸a˜ o das consultas feita de forma colaborativa, ou seja, cada par que recebe um pedido de consulta, al´em de execut´a-la em seu pr´oprio, replica o pedido para outros n pares (usamos n = 2) de sua lista de pares conectados, conforme veremos a seguir. Um par iniciador de consulta formula a consulta, d´a a ela um identificador u´ nico na rede (um seq¨uencial concatenado ao seu identificador de par – ver sec¸a˜ o 3.3), inicializa um vetor de respostas, que usa para verificar se o conjunto de respostas est´a completo, replica a consulta para os n pares para os quais aponta e processa a consulta em seus pr´oprios reposit´orios. Ao receber uma solicitac¸a˜ o de consulta, o servic¸o de execuc¸a˜ o de workflow do par divulgador instancia uma nova m´aquina de workflow que passa a consulta adiante, para outros n pares para os quais aponta, e a executa em seu pr´oprio reposit´orio. As consultas s˜ao feitas usando-se as bases de metadados locais, dispon´ıveis em cada reposit´orio, sendo que os resultados (referˆencias a objetos) s˜ao enviados diretamente ao par iniciador da consulta. Para que se garanta que nenhum par fique fora de uma consulta, deve existir em cada par uma c´opia da relac¸a˜ o de pares conectados a` rede, mantida atualizada e estruturada da mesma forma. Usamos uma a´ rvore n-´aria, como explicamos na sec¸a˜ o 3.3. J´a que as consultas podem ser originadas por um par qualquer da a´ rvore, as consultas que chegam a um par que n˜ao aponta para n pares (um par folha, por exemplo) devem ser replicadas para o par raiz (o primeiro par na lista). Consultas j´a processadas e replicadas (a verificac¸a˜ o e´ feita atrav´es de seus identificadores) s˜ao, obviamente, descartadas. 3.3. Manutenc¸a˜ o da Lista de Pares Pares s˜ao identificados na rede atrav´es de uma referˆencia do tipo portaIP@nomeHost. Uma relac¸a˜ o m´ınima dessas referˆencias (basta uma referˆencia) e´ mantida no arquivo de parˆametros de cada par que, ao ser inicializado, a usa para comunicar sua entrada na rede. Cada um desses pares trata de disseminar a entrada do novo par para outros n pares, e assim sucessivamente. Cada par que recebe um aviso de entrada de um novo par d´a ”as boas vindas” a esse novo par para que este possa compor sua pr´opria lista de pares ativos. Com isso, ao final desse processo, todos os pares ter˜ao a mesma relac¸a˜ o
M = 10 1021
1033
1103
1144
1145
1148
1201
1313
1318
1320
(a)
1021
1033
(b)
1103
1144
1313
1145
1318
1148
1201
1320
˜ das listas de pares conectados em um ambiente TEAM. Figura 4: Organizac¸ao (a) e´ o vetor de pares ativos, conforme armazenado e cada par e (b) e´ a ´ estrutura em arvore que ele representa.
de pares ativos. A sa´ıda volunt´aria de um par da rede tamb´em e´ comunicada a n outros pares que tratam de encaminhar essa informac¸a˜ o a outros n pares... Uma sa´ıda involunt´aria (situac¸a˜ o de falha), quando percebida por um outro par, e´ divulgada da mesma forma. Como j´a adiantamos, para que a propagac¸a˜ o de consultas atinja todos os pares da rede, e´ necess´ario que seja mantida em cada par uma relac¸a˜ o atualizada dos pares conectados. Como os pares repassam mensagens a n outros pares, conclu´ımos que uma forma eficiente de gerenciar essa relac¸a˜ o seria estrutur´a-la segundo uma a´ rvore n-´aria (4b) implementada como um vetor de identificadores de pares classificado ascendentemente (4-a). Nessa figura e´ ilustrada uma situac¸a˜ o em que n = 2 (omitimos, por quest˜oes de clareza, a segunda parte dos identificadores dos pares) e M (n´umero total de pares na rede) e´ igual a 10. Um dado par ao qual e´ solicitada uma consulta, conhecedor de sua posic¸a˜ o – suponhamos i – na relac¸a˜ o de M pares, determina o in´ıcio da lista dos n pares (posic¸a˜ o p(i) inicial na relac¸a˜ o), para os quais dever´a repassar a consulta (ou mensagem de uma forma geral), atrav´es da express˜ao: p(i) = 2 + (i − 1)n
(1)
Caso p(i) ou qualquer de seus sucessores seja maior que M , o par da posic¸a˜ o 1 (raiz) da relac¸a˜ o ser´a o par para o qual dever´a ser repassada a consulta. Por exemplo, e ainda nos referindo a` figura 4, o par 1144 (posic¸a˜ o i = 4 na lista) precisaria repassar uma consulta recebida aos n = 2 pares que iniciam na posic¸a˜ o p(4) = 2 + (4 − 1)2 = 8, ou seja, aos pares 1313 e 1318. Um par, ao receber um pedido de consulta, verifica se em sua lista de consultas processadas j´a consta o identificador da mesma, descartando o pedido caso positivo e processando e passando adiante, caso negativo.
Com isso distribu´ımos por todos os pares da rede os esforc¸os de disseminac¸a˜ o de consultas. 3.4. Fatos, Eventos e Suas Propagac¸o˜ es Quando um workflow e´ instanciado, o par que o instancia informa aos demais pares interessados que um processo se iniciou, anexando seu modelo4 na ´ıntegra. Isso provoca a criac¸a˜ o de uma nova m´aquina de execuc¸a˜ o de workflow em cada um desses pares, que permanece ativa at´e que o processo em quest˜ao chegue ao final. Cada par controla, atrav´es da m´aquina de execuc¸a˜ o criada para tal, a porc¸a˜ o do workflow que lhe diz respeito (pela qual e´ interessado), e isso e´ feito com base na relac¸a˜ o dos executores associados a` s atividades especificadas no modelo (lembrando que os executores s˜ao associados a seus home peers). Durante a execuc¸a˜ o das atividades em um dado par, ocorrem fatos (e.g. tarefas s˜ao cumpridas), ou seja, aos atributos das atividades e/ou de seus executores s˜ao associados (possivelmente novos) valores. Esses fatos correspondem a mudanc¸as de estados de execuc¸a˜ o do processo e, como tais, precisam ser informados aos demais pares interessados naquela instˆancia do workflow. Isso e´ feito atrav´es do mecanismo de divulgac¸a˜ o (seletiva) de eventos feita aos pares interessados com base na lista de pares. Em outras palavras, diferentemente da execuc¸a˜ o de consultas, nem todos os pares da rede s˜ao informados dos fatos; apenas o s˜ao aqueles que processam parte da mesma instˆancia do workflow.
4. O Ambiente de e-Learning para o Projeto PGL As caracter´ısticas do ambiente para e-learning que apresentamos a seguir dizem respeito a` proposta do grupo de banco de dados do TecBD (Laborat´orio de Tecnologia de Banco de Dados) da PUC-Rio para o projeto PGL. O ambiente ser´a formado por instituic¸o˜ es parceiras que instanciar˜ao pares, tantos quanto queiram, no sentido de contribu´ırem para a execuc¸a˜ o colaborativa de programas de ensino e de manterem um reposit´orio distribu´ıdo de conte´udo modular de aprendizado – objetos de aprendizado ou LOs [Pereira et al., 2003] – a serem compartilhados como componentes para a formac¸a˜ o, por agregac¸a˜ o, de novos conte´udos de aprendizado. Os LOs s˜ao descritos segundo o padr˜ao do IMS [IMS Global Learning Consortium, 2001]. Na agregac¸a˜ o, os objetos armazenados em outros pares s˜ao referenciados, e n˜ao replicados. LOs s˜ao estruturados em cinco n´ıveis hier´arquicos chamados de t´opico (n´ıvel mais elementar), aula, m´odulo, curso e programa. Estudantes e professores, realizando colaborativamente programas de ensino aos quais est˜ao vinculados, conforme modelos de workflow definidos a priori, acessam os LOs armazenados em qualquer par do reposit´orio distribu´ıdo, transparentemente quanto a` localizac¸a˜ o f´ısica dos mesmos. At´e o presente momento existem 31 funcionalidades relacionadas para o ambiente TEAM do PGL. Essas funcionalidades est˜ao agrupadas nas seguintes categorias: 1. Elaborac¸a˜ o de conte´udo instrucional, incluindo concepc¸a˜ o, busca, desenvolvimento, montagem, revis˜ao, aprovac¸a˜ o, registro e publicac¸a˜ o de LOs; 2. Modelagem da execuc¸a˜ o do conte´udo; 3. Execuc¸a˜ o dos conte´udos (entrega ou delivery) pelos alunos; 4
Modelos s˜ao definidos no TEAM com o uso de uma notac¸a˜ o declarativa baseada em predicados, para os quais s˜ao feitos mapeamentos para XML, visando ao armazenamento, divulgac¸a˜ o e execuc¸a˜ o.
4. Atividades ass´ıncronas e s´ıncronas tais como uso de correio eletrˆonico e v´ıdeoconferˆencia e, 5. Monitorac¸a˜ o da execuc¸a˜ o de conte´udos, atrav´es de estat´ısticas diversas, acompanhamento de freq¨ueˆ ncias de acesso e participac¸a˜ o no grupo, aplicac¸a˜ o de testes para avaliac¸o˜ es individuais e em grupo, etc. Ao ambiente sendo desenvolvido est˜ao sendo adicionados recursos como web mail, agenda pessoal (mantida pelo pr´oprio aluno e pelo ambiente, que informa dataslimite para execuc¸a˜ o das tarefas em curso), acesso a` lista de participantes correntemente logados no ambiente, sala de bate-papo e quadro de avisos.
5. Conclus˜oes Nesse artigo apresentamos a arquitetura TEAM, um modelo para desenvolvimento de ambientes para suporte a` aplicac¸o˜ es colaborativas e distribu´ıdas que est´a sendo desenvolvida na PUC-Rio. Enfocamos os aspectos de gest˜ao de dados nos ambientes baseados nessa arquitetura. Esses ambientes usam tecnologias de workflow, computac¸a˜ o peer-to-peer e infra-estrutura de comunicac¸a˜ o baseada em servic¸os web. Ambientes baseados nessa arquitetura provˆeem aos usu´arios uma vis˜ao integrada do ambiente, transparentemente quanto a` localizac¸a˜ o f´ısica dos demais usu´arios e dos objetos de neg´ocio. Atualmente estamos desenvolvendo um prot´otipo do ambiente para aplicac¸a˜ o em e-learning como nossa proposta ao projeto do PGL. Estamos, tamb´em, investigando o impacto sobre a estrat´egia de avaliac¸a˜ o de consultas nas situac¸o˜ es de eventuais falhas e n˜ao sincronismo das listas de pares da rede. Entendemos que nossa contribuic¸a˜ o com enfoque de banco de dados distribu´ıdos e autˆonomos a` a´ rea de CSCW consiste na possibilidade de criac¸a˜ o de ambientes para suporte a aplicac¸o˜ es colaborativas atrav´es de especializac¸o˜ es da arquitetura TEAM, combinando tecnologias de larga utilizac¸a˜ o hoje em dia. Especificamente para a a´ rea de e-learning, consideramos que tamb´em o uso de objetos de aprendizado representa uma contribuic¸a˜ o importante.
Referˆencias Alonso, G. and Schek, H.-J. (1996). Research issues in large workflow management systems. Technical Report 1996PA-as96-nsfws. B¨osz¨ormenyi, L., Groiss, H., and Eisner, R. (1999). Adding distribution to a workflow management system. 10th International Workshop on Database and Expert Systems Applications (DEXA). Cesarini, M., Monga, M., and Tedesco, R. (2004). Carrying on the e-learning process with a workflow management engine. In Proceedings of ACM Symposium on Applied Computing (SAC’2004) Track on Engineering e-Learning Systems (ELS), Nicosia, Cyprus. ACM. Graham, R. L. (2001). Peer-to-peer: Toward a definition. Some lecture notes in 2001 International Conference on Peer-to-Peer Computing (P2P2001). Gribble, S., Halevy, A., Ives, Z., Rodrig, M., and Suciu, D. (2001). What can databases do for peer-to-peer? Workshop on the Web and Databases, WebDB’2001.
Halevy, A. Y., Ives, Z. G., Mork, P., and Tatarinov, I. (2003). Piazza: data management infrastructure for semantic web applications. In Proceedings of the twelfth international conference on World Wide Web, pages 556–567. ACM Press. Hollingsworth, D. (1995). The workflow reference model. Technical Report TC00-1003, Workflow Management Coalition. IMS Global Learning Consortium (2001). IMS learning resource meta-data information model. Technical Report 1.2.1, IMS. Learning Technology Standards Committee (2002). Draft standard for learning object metadata. Technical Report IEEE P1484.12.1/D6.4, IEEE. Lonchamp, J. (1993). A structured conceptual and terminological framework for software process engineering. ICSP 2 – 2nd International Conference on Software Process. Madhavan, J. and Halevy, A. Y. (2003). Composing mappings among data sources. 29th International Conference on Very Large Data Bases (VLDB’2003), pages 572–583. Mehlecke, Q. T. C. and Tarouco, L. M. R. (2003). Ambientes de suporte para educac¸a˜ o a distˆancia: A mediac¸a˜ o para aprendizagem cooperativa. Novas Tecnologias na Educac¸a˜ o, 1(1). Pereira, L. A. M. and Melo, R. N. (2003). Um ambiente de banco de dados para ensino a distˆancia baseado em workflows e objetos de aprendizado. Monografias em Ciˆencia da Computac¸a˜ o, PUC-RioInf.MCC12/03. Pereira, L. A. M., Melo, R. N., Porto, F. A. M., and Schulze, B. (2004a). TEAM: Using the grid to enhance e-learning environments. II Workshop de Grade Computacional e Aplicac¸o˜ es – WGCA’2004. Pereira, L. A. M., Melo, R. N., Porto, F. A. M., and Schulze, B. (2004b). A workflowbased architecture for e-learning in the grid. The First International Workshop on Collaborative Learning Applications of Grid Technology – CLAG’2004. Pereira, L. A. M., Porto, F. A. M., and Melo, R. N. (2003). Objetos de aprendizado reutiliz´aveis (RLOs): Conceitos, padronizac¸a˜ o, uso e armazenamento. Monografias em Ciˆencia da Computac¸a˜ o, PUC-RioInf.MCC10/03. Santoro, F. M., Borges, M. R. S., and Santos, N. (2003). Learning through collaborative projects: The architecture of an environment. International Journal of Computer Applications in Technology (IJCAT). Schollmeier, R. (2001). A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications. First International Conference on Peer-toPeer Computing (P2P’01), page 101. Tatarinov, I., Ives, Z., Madhavan, J., Halevy, A., Suciu, D., Dalvi, N., Dong, X. L., Kadiyska, Y., Miklau, G., and Mork, P. (2003). The piazza peer data management project. SIGMOD Rec., 32(3):47–52. Wiederhold, G. (1992). Mediators in the architecture of future information systems. Computer, 25(3):38–49. ¨ Ozsu, M. T. and Valduriez, P. (2001). Princ´ıpios de Sistemas de Bancos de Dados Distribu´ıdos. Editora Campus, 2 edition.
