Universidade de Aveiro 2008

Departamento de Electrónica, Telecomunicações e Informática

Pedro Jorge Pereira Lopes

Integração de serviços para extracção de conhecimento

Universidade de

Aveiro 2008

Departamento de Electrónica, Telecomunicações e Informática

Pedro Jorge Pereira Lopes

Integração de serviços para extracção de conhecimento

Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia de Computadores e Telemática, realizada sob a orientação científica do Professor Doutor José Luís Guimarães Oliveira, Professor Associado do Departamento de Electrónica, Telecomunicações e Informática da Universidade de Aveiro

Para a minha Mãe, a quem devo tudo, e para a Andreia, por algo que não posso exprimir em palavras.

o júri

presidente Doutor Joaquim Arnaldo Carvalho Martins Professor Catedrático da Universidade de Aveiro

Doutor Rui Pedro Sanches de Castro Lopes Professor Coordenador do Departamento de Informática e Comunicação da Escola Superior de Tecnologia e Gestão do Instituto Politécnico de Bragança

Doutor José Luís Oliveira Professor Associado da Universidade de Aveiro

agradecimentos

Ao Professor José Luís, pelos sábios conselhos e opiniões durante o trabalho; aos meus amigos e família, pela força dada para concluir mais esta etapa; aos colegas do grupo de Bioinformática, por me aceitarem na sua casa; e por último um agradecimento especial ao Joel Arrais, principal mentor deste projecto, pelo apoio, palavras, críticas e sugestões que tornaram possível o trabalho apresentado nesta dissertação.

palavras-chave

Web2.0, web, interface, base de dados, javascript, xml, xpath, xsl, internet, integração, extracção, ajax, serviços, css, html, workflow, informação, extracção, conhecimento, json, web services

resumo

Com a descoberta do genoma humano completa, uma enorme quantidade de dados foi gerada, criando grandes desafios na compreensão do valor de toda esta informação. Este cenário trouxe a necessidade de novas ferramentas para extracção automática de informação de bases de dados biológicas. Esta dissertação apresenta um sistema web baseado em princípios Web2.0 desenhado para agregar serviços e dados, melhorando a extracção de conhecimento de bases de dados biológicas. A arquitectura segue uma aproximação ágil e nova, usando fluxos de informação, que podem ser construidos dinamicamente pelo utilizador. O workflow permite a criação de protocolos de obtenção de informação específicos, permitindo que o utilizador aceda a recursos distribuídos numa interface única e centralizada.

keywords

Web2.0, interface, web, database, integration, extraction, javascript, xml, xsl, xpath, ajax, css, web services, html, services, workflow, information, extraction, knowledge, json

abstract

With the advent of human genome disclosure an enormous quantity of data was generated putting great challenges in understanding the value of all this data. This scenario has risen the necessity to have new tools for automatic extraction of knowledge from biological databases. This dissertation presents a web system based on web2.0 principles designed to aggregate services and data and to enhance knowledge extraction from biological databases. The architecture follows a new and agile solution using workflows which may be dynamically built by the user. The workflow allows building specific protocols for information retrieval enabling the user to access distributed resources in a centralized and unique interface.

1

Índice

ÍNDICE ............................................................................................................................................................................1ÍNDICEDETABELAS ..................................................................................................................................................3ÍNDICEDEFIGURAS ...................................................................................................................................................4LISTADEACRÓNIMOS ..............................................................................................................................................51INTRODUÇÃO ...........................................................................................................................................................71.1ENQUADRAMENTO ................................................................................................................................................................... 71.2OBJECTIVOS ............................................................................................................................................................................... 81.3ESTRUTURA............................................................................................................................................................................... 8

2INTEGRAÇÃODEDADOS....................................................................................................................................112.1APLICAÇÕESWEBPARAINTEGRAÇÃODEDADOS.............................................................................................................142.2WEB2.0 ...................................................................................................................................................................................152.2.1Origens............................................................................................................................................................................... 162.2.2Javascript.......................................................................................................................................................................... 172.2.3XML ..................................................................................................................................................................................... 182.2.4JSON .................................................................................................................................................................................... 202.2.5WebServices ................................................................................................................................................................... 212.2.6CSS ....................................................................................................................................................................................... 222.2.7AJAX .................................................................................................................................................................................... 23

2.3EXEMPLOSDEAPLICAÇÕESWEB2.0...................................................................................................................................272.3.1Folksonomy...................................................................................................................................................................... 272.3.2SocialBookmarking..................................................................................................................................................... 282.3.3SocialNetworking ........................................................................................................................................................ 292.3.4Wiki..................................................................................................................................................................................... 302.3.5Blogs ................................................................................................................................................................................... 322.3.6Feeds................................................................................................................................................................................... 332.3.7MediaSharing ................................................................................................................................................................ 342.3.8WebDesktops ................................................................................................................................................................. 35

2.4INTEGRAÇÃODEDADOSESERVIÇOSUSANDOFLUXOSDEINFORMAÇÃO........................................................................362.4.1AplicaçõesWeb2.0deGestãodeWorkflows.................................................................................................... 39

2.5SUMÁRIO..................................................................................................................................................................................413ARQUITECTURAWEB2.0PARAINTEGRAÇÃODEDADOSESERVIÇOSUSANDOFLUXOSDEINFORMAÇÃO............................................................................................................................................................433.1FUNCIONALIDADES................................................................................................................................................................ 443.2REQUISITOSTÉCNICOS ..........................................................................................................................................................453.2.1Generalidadedeserviços ........................................................................................................................................... 453.2.2Processamentodoladodocliente ......................................................................................................................... 453.2.3Integraçãodosserviçosdeutilizadornumaplataformaexistente ........................................................ 46

3.3MODELOEARQUITECTURA ..................................................................................................................................................463.3.1Componentes................................................................................................................................................................... 463.3.2Modelo ............................................................................................................................................................................... 473.3.3Arquitectura.................................................................................................................................................................... 48

3.4SUMÁRIO..................................................................................................................................................................................494DYNAMICFLOW.....................................................................................................................................................514.1ESTRATÉGIASDEDESENVOLVIMENTO................................................................................................................................524.2INTERFACEDEUTILIZADOR ..................................................................................................................................................574.3ARQUITECTURA ......................................................................................................................................................................674.3.1Diagramadabasededadosdaaplicação ......................................................................................................... 67

2

4.3.2DiagramadeClassesdaaplicação ........................................................................................................................ 694.3.3Fluxodeexecução ......................................................................................................................................................... 70

4.4PROBLEMAS.............................................................................................................................................................................724.4.1SameOriginPolicy ....................................................................................................................................................... 724.4.2Definiçãodanormadosmódulosdeprocessamento .................................................................................... 754.4.3Passagemdeinformaçãodosmódulosdeprocessamento ......................................................................... 764.4.4ProcessamentodoWorkflowdoladodoCliente............................................................................................. 78

4.5SUMÁRIO..................................................................................................................................................................................795CONCLUSÕESETRABALHOFUTURO.............................................................................................................816REFERÊNCIAS ........................................................................................................................................................83

3

ÍndicedeTabelas

TABELA1:APLICAÇÕESDESOCIALBOOKMARKING .......................................................................................................................28 TABELA2:APLICAÇÕESDESOCIALNETWORKING .........................................................................................................................30 TABELA3:APLICAÇÕESDEBLOGGING.............................................................................................................................................32 TABELA4:APLICAÇÕESDEMEDIASHARING...................................................................................................................................35 TABELA5:APLICAÇÕESWEBDESKTOP.........................................................................................................................................36 TABELA6:DESCRIÇÃODASCOMPONENTESDOSISTEMA.............................................................................................................38 TABELA7:LISTADEFUNCIONALIDADES ........................................................................................................................................44 TABELA8:ESPECIFICAÇÃODOSARGUMENTOSDEENTRADADOBIOPORTAL..........................................................................56 TABELA9:DESCRIÇÃODASRELAÇÕESDABASEDEDADOS........................................................................................................69 TABELA10:DESCRIÇÃODAESPECIFICAÇÃODOSMÓDULOSDEPROCESSAMENTO..................................................................75

4

ÍndicedeFiguras

FIGURA1:INTEGRAÇÃODEDADOSANÍVELDESGBD ...............................................................................................................12 FIGURA2:INTEGRAÇÃODEDADOSANÍVELDECÓDIGO ..............................................................................................................13 FIGURA3:INTEGRAÇÃODEDADOSANÍVELDAAPLICAÇÃO........................................................................................................14 FIGURA4:EXEMPLODECÓDIGOJAVASCRIPT ................................................................................................................................18 FIGURA5:EXTRACTODEUMFICHEIROXML ................................................................................................................................19 FIGURA6:EXEMPLODEOBJECTOEMJSON...................................................................................................................................21 FIGURA7:EXTRACTODEUMFICHEIROCSS..................................................................................................................................23 FIGURA8:INTERACÇÃOCLIENTE/SERVIDORAJAX .....................................................................................................................24 FIGURA9:ORGANIZAÇÃOMODULARDOAJAX..............................................................................................................................26 FIGURA10:HTTP://DEL.ICIO.US.....................................................................................................................................................29 FIGURA11:HTTP://WWW.HI5.COM..............................................................................................................................................30 FIGURA12:HTTP://WWW.WIKIPEDIA.ORG..................................................................................................................................31 FIGURA13:HTTP://WWW.BLOGGER.COM....................................................................................................................................33 FIGURA14:HTTP://MULTIMEDIA.RTP.PT.....................................................................................................................................34 FIGURA15:HTTP://WWW.YOUTUBE.COM....................................................................................................................................34 FIGURA16:HTTP://WWW.EYEOS.INFO.........................................................................................................................................35 FIGURA17:EXEMPLODEFLUXODEINFORMAÇÃOPERSONALIZADO.........................................................................................37 FIGURA18:DIAGRAMADOFLUXODEINFORMAÇÃO ....................................................................................................................38 FIGURA19:HTTP://WWW.POPFLY.COM .......................................................................................................................................40 FIGURA20:HTTP://PIPES.YAHOO.COM.........................................................................................................................................41 FIGURA21:MODELODAAPLICAÇÃO ..............................................................................................................................................48 FIGURA22:ARQUITECTURADAAPLICAÇÃO ..................................................................................................................................49 FIGURA23:ARQUITECTURADEAUTENTICAÇÃODAFRAMEWORK.NET..................................................................................54 FIGURA24:EXEMPLODEQUERYSTRINGDEACESSOAOBIOPORTAL ........................................................................................56 FIGURA25:ESQUEMADAÁREADETRABALHO.............................................................................................................................60 FIGURA26:INTERFACEDOMENUDAAPLICAÇÃO........................................................................................................................60 FIGURA27:EXEMPLODEUMCALL­OUTNAAPLICAÇÃO...............................................................................................................62 FIGURA28:EXTRACTODOFICHEIROXSLPARATRANSFORMAÇÃODOSMÓDULOSDEPROCESSAMENTO...........................63 FIGURA29:INTERFACEDALISTADEMÓDULOSEXPANDIDA ......................................................................................................64 FIGURA30:INTERFACEDELISTADEMÓDULOSPORDEFEITO....................................................................................................64 FIGURA31:EXEMPLODAINTERFACEDOSMÓDULODEPROCESSAMENTONAAPLICAÇÃONOWORKFLOW .........................65 FIGURA32:ESQUEMADABASEDEDADOS ...................................................................................................................................68 FIGURA33:DIAGRAMADECLASSESDAAPLICAÇÃO.....................................................................................................................70 FIGURA34:FLUXODEFUNCIONAMENTODOPROCESSAMENTODOWORKFLOW ....................................................................71 FIGURA35:FLUXODEFUNCIONAMENTODEFUNCIONALIDADESGERAISDAAPLICAÇÃO.......................................................72 FIGURA36:MODELOSDEFUNCIONAMENTODEPEDIDOSXMLHTTPREQUEST .......................................................................73 FIGURA37:EXTRACTODECÓDIGOJAVASCRIPTPARACRIAÇÃODEUMATAG"SCRIPT" .........................................................74 FIGURA38:EXTRACTODOFICHEIROXMLDEDESCRIÇÃODOSMÓDULOSDEPROCESSAMENTO..........................................76 FIGURA39:EXTRACTODOHTMLDEUMMÓDULODEPROCESSAMENTO................................................................................77

5

ListadeAcrónimos

AJAX AssynchronousJavascriptandXML

API ApplicationProgrammingInterface

CSS CascadeStyleSheet

DB Database

DBMS DataBaseManagementSystem

DOM DocumentObjectModel

FAQ FrequentlyAskedQuestions

FTP FileTransferProtocol

HTML HyperTextMarkupLanguage

HTTP HyperTextTransferProtocol

JSON JavaScriptObjectNotation

PDA PersonalDigitalAssitant

RSS ReallySimpleSindication

SGBD SistemadeGestãodeBasesdeDados

SOA ServiceOrientedArchitecture

SOAP SimpleObjectAccessProtocal

UDDI UniversalDescription,DiscoveryandIntegration

URL UniformResourceLocator

WSDL WebServicesDescriptionLanguage

XML eXtensibleMarkupLanguage

Xpath XMLPathLanguage

XSL eXtensibleStylesheetLanguage

6

7

1Introdução

1.1Enquadramento

AincessantesededeconhecimentodoHomemaliadaàevoluçãotecnológica,

levouàcriaçãodegrandesquantidadesdeinformação,quedevedeserarmazenada,

processadaedivulgadaaopúblico.Oarmazenamentodedadosdeformaestruturada

foianecessidadeseguinteequelevouàcriaçãodediversossistemasdetratamentoe

divulgaçãodedados.Estessistemaspodemseguirdiversosmodelosepermitemuma

disponibilizaçãorápidaeeficientedainformação.Umdossistemastradicionaispara

guardarainformaçãoéosistemadebasesdedados.DeentreosváriosSistemasde

GestãodeBasesdeDadosexistentes,temosdiversosesquemasdearmazenamentode

dados – tabelas, relações – diferentes e não relacionáveis entre si, mesmo que

pertençamaáreassemelhantesetenhamsidocriadosnomesmoSistemadeGestão

deBasesdeDados.

Estas diferenças não se prendem apenas ao nível da apresentação e

estruturação da informação, mas também ao nível das tecnologias usadas para

tratamento dos dados. No casomais comum, temos um acesso directo, através de

apenasumentreváriosmétodos,àinformaçãoguardadanasbasesdedados.Aceder

apenas aum localde armazenamentodedadosédemasiado restritivo, limitandoa

informação que podemos obter e processar. A integração de dados surge neste

contexto:énecessáriojuntarosdadosdistribuídospordiversasbasesdedadospara

queainformaçãoextraídasejaemmaiorquantidade,maiscoerente,maisconsistente

e,sobretudo,demelhorqualidade.Otrabalhoapresentadonestadissertaçãositua‐se

naáreadedesenvolvimentodasinterfacesdeutilizadorquepermitemousodetodas

as potencialidades inerentes à integração de dados e serviços. Aplicando conceitos

existentes e reutilizando algumas tecnologias, podemos criar interfaces com

mecanismos que permitam uma gestão melhorada do acesso aos dados e que

providenciam ao utilizador uma maior imersão no controlo da obtenção da

informaçãopretendida.

8

1.2Objectivos

Oprincipalobjectivodestetrabalhoconsistenaconstruçãodeumaaplicação

webqueforneçaumainterfaceinovadoraparagestãodefluxosdeinformação,coma

finalidade de extrair conhecimento através da integração de dados e serviços

dispersos.

Para atingir os objectivos, o utilizador da aplicaçãoweb tem de construir o

workflowdemodoaobtera informaçãodesejada.Umworkflow consistenuma lista

demódulosdeprocessamentoordenados, fechados e independentes entre si; estes

adaptadoresapenascomunicamaoreceberemcomodadosdeentrada,osdadosde

saídadoadaptadoranterior.Aaplicaçãodevedisponibilizarinformaçãosobretodas

asfuncionalidadespassíveisdeseremusadasnoworkflow.Outilizadordeverádepois

usarestasfuncionalidadespré‐definidasparaconstruirdinamicamenteumworkflow

que lhe permita obter a informação que necessita. Informação sobre os diversos

passosdo fluxode informaçãodeveser fornecidaaoutilizadoreaapresentaçãoda

informaçãodevevariardeacordocomotipodeinformaçãoasermostrada.

Sucintamente,osprincipaisobjectivosdadissertaçãoforamosseguintes:

• estudar os novos modelos de interfaces de aplicações de integração de

dadosexistentes;

• gerir dinamicamente o acesso a funcionalidades de diversas bases de

dados;

• criarumainterfacewebágilparacriaçãoemanutençãodemecanismosde

extracçãoeagregaçãodeinformação–workflows,procurando‐seoferecer

uma interacção semelhante à que pode ser dada por uma aplicação

Desktop.

1.3Estrutura

Estadissertaçãoencontra‐sedivididaemcincocapítulos.

No capítulo 2 é apresentado o estado da arte relativo a metodologias e

arquitecturasdeintegraçãodedadoseserviços.Ofocoédadoàcamadaaplicacional

deondefaráparteainterfacedequetrataadissertação.Nesteâmbitosãoreferidas

9

as novas aplicações Web2.0, as suas características e também as tecnologias que

permitem este novo tipo de aplicações e interfaces. São também referidos alguns

serviçoswebusamestas tecnologiasesebaseiamemworkflowspara integraçãode

dados.

Nocapítulo3éapresentadaaanálisederequisitos,amodelaçãodosistemae

umapropostaparaaarquitecturadaaplicação.

O quarto capítulo descreve a estrutura da aplicação criada, as escolhas

efectuadas para responder aos requisitos definidos e os problemas encontrados

durante o desenvolvimento da aplicação. É ainda feita uma contextualização da

aplicaçãodentrodaáreadabioinformática.

Nocapítulofinalfaz‐seumbalançodotrabalhorealizado,sãoapresentadasas

conclusõesdotrabalhoeapontadoscaminhosparaofuturodaarquitectura.

10

11

2Integraçãodedados

Aintegraçãodedadoséumaáreacadavezmaisimportantenotratamentoda

informação, principalmente devido ao facto desta se encontrar cada vez mais

dispersa. A informação encontra‐se distribuída das mais variadas maneiras e a

integraçãodestainformaçãonemsempreserevelaumatarefasimples.

Fontesdedadosheterogéneascausamproblemasnaintegraçãoa3níveis[1]:

• problemas no estrutura dos dados, pois podemos ter ficheiros, tabelas ou

outrosformatos,semqualquertipoderelaçãooumapeamentodirecto;

• problemas no esquema de armazenamento dos dados, isto porque, mesmo

comumaestruturasemelhante,conceitossemelhantespodemserguardados

com representações diferentes, representações semelhantes podemmodelar

conceitos diferentes e ainda porque existemdiversas formas de representar

ummesmoconceito.Esteproblematambémnãoéultrapassadomesmoquese

siga um esquema semelhante na estrutura de armazenamento – modelo

relacionalna3.ªformanormalporexemplo;

• problemas na instanciação dos dados, pois podemos ter o mesmo objecto

representadoemfontesdedadosdiferentesedemaneirasdistintas.Assim,a

integraçãopode ser feitadediversas formase envolvegeralmentemaisque

umacamadadeabstracçãonaarquitecturadeacessoaosdados.

Umdosmétodosdeacessoadados,brokerless,envolveapenasconfigurações

aoníveldonossoSistemadeGestãodeBasesdeDados (SGBD)(Figura1).OSGBD

usa geralmente a Structured Query Language (SQL) para permitir o acesso à

informação. Usando um SGBD, podemos configurá‐lo de forma a que o acesso a

diferentes bases de dados seja transparente para o utilizador desse SGBD. O

utilizador pode então efectuar as respectivas queries SQL e obter respostas de

variadas fontes de informação de uma forma simples e sem se preocupar com

12

problemasdeprogramação.OSGBDtemtodaacargadetrabalhosoquepodereduzir

aeficiênciadaaplicaçãodevidoàslatênciasqueoprocessamentodoSQLcausaria.

Figura1:IntegraçãodeDadosaníveldeSGBD

Nesta situação, há também que considerar todos os problemas inerentes ao

usodeBasesdeDadosdistribuídaseassuasimplicaçõesnaarquitecturadosistemaa

implementar,fazendocomqueestasoluçãosejausadapoucasvezes.

Osegundocasoparaintegraçãodedadosenvolveacriaçãoedesenvolvimento

deumbroker(Figura2).Estebrokerterádeserprogramadoparaforneceràcamada

deabstracçãosuperiorumacessotransparenteaosdados.

Tanto o acesso aos dados como o retorno de dados para a camada de

abstracçãosuperiorpodemserfeitosdediversasformas.

13

Figura2:IntegraçãodeDadosaníveldecódigo

Paraacederaosdadosexistentespodemosprogramaranossaaplicaçãopara

usarumadasváriasimplementaçõesdeSGBDexistentes,usandoassuasrespectivas

potencialidades. Podemos também aceder aos dados através de WebServices,

tecnologiacadavezmaisemvoganadisponibilizaçãodeacessoa informaçãoeque

oferecepotencialidadessemelhantesaumaarquitecturadistribuída.Muitasbasesde

dados de onde queremos extrair informação possuem Application Programming

Interfaces(APIs)próprias.Destemodo,temosdeadaptaronossobrokerparapoder

usarestasAPIs.OusodeAPIsouWebServiceséaopçãocadavezmaisusada,visto

limitar o acesso à informação existente, bem como esconder e preservarmuito do

trabalhofeitoemtermosdemodelaçãoeestruturaçãodabasededados.

No fornecimento de dados à camada aplicacional superior podemos seguir

diversos caminhos. Podemos usar estruturas de dados internas à nossa aplicação,

usávelcasoestejamosaconstruirumaaplicaçãoproprietáriaecasoonossocódigo

nãosejaalvodedivulgaçãopública.Emsituaçõesemquepretendemosqueoacesso

aoqueconstruímossejausadopormaisqueumaaplicação,tendoestasfinsdistintos

e arquitecturas distintas, é necessário optar pormétodos que facilitem o acesso à

informação que conseguimos obter. Tal como os proprietários das bases de dados,

podemos optar por criar e disponibilizarWeb Services que permitem o acesso à

informação,podemoscriarumaAPIprópriaparaacessoànossaestruturaouentão

disponibilizar osdadosnum formato específico. Escolhendo estaúltimahipótese, o

14

XMLsurgecomooformatoidealpelasuaampladivulgaçãoepelafacilidadecomque

outrasaplicaçõespodemacederaosdadosnesteformato.

Depois de resolvido o acesso aos dados é importante trabalhar sobre as

possibilidadesdetratamentoeapresentação.Énesteníveldeabstracçãoquesurgeo

trabalhoapresentadonestadissertação.Estenívelpodeserdesenvolvidodediversas

maneiras:podemosoptarporcriarumaaplicaçãotípicaDesktop,podemosconstruir

umaaplicaçãoparacorrernumPDA,podemosconstruirumaaplicaçãoparacorrer

num tipo de hardware específico ou podemos desenvolver ainda aplicações para

ambienteweb(Figura3).

Figura3:IntegraçãodeDadosaníveldaaplicação

2.1AplicaçõesWebparaIntegraçãodeDados

A integraçãodedados começaa surgir cadavezmaisassociadaaaplicações

Web e não só a aplicaçõesDesktop. Desde o turismo à saúde, do entretenimento à

educação,aintegraçãodedadoscomoacessoainformaçãopodeseraplicadaatodas

as áreas existentes e, apesar de ainda serem questionáveis pelosmais puristas, as

aplicações web surgem cada vez mais na linha da frente nas áreas em que a

digitalizaçãodainformaçãoéfulcral.

Sendoaintegraçãodedadosumdosprincipaispontosdotrabalhomostrado

nesta tese, importa referir o que já existe feito pelo grupo de Bioinformática da

15

UniversidadedeAveironumaáreasemelhanteàqueseráabordadanestadissertação.

A aplicação DiseaseCard é um “portal Web público que integra em tempo real

informação genómica e médica de bases de dados heterogéneas e distribuídas, e

apresenta­a num paradigma visual familiar” [2]. Esta aplicação permite recolher

informaçãoemtemporealdediversasfontesdedadosdisponíveisnaInternetacerca

deumdeterminadoitemdepesquisarelacionadocomdoençasraras.Estasfontesde

dados encontram‐se dispersas e são desconexas entre si, tornando a integração de

dados destas umproblema complexo e aliciante. O GeneBrowser, “um novo serviço

Web (...), que combina diversas fontes de dados e métodos de visualização para

melhorar a interpretação biológica e a extracção de conhecimento de um grupo de

genes” [3], envolve uma arquitectura de integração de dados semelhante ao

DiseaseCard.Estaaplicaçãoserviudeexemploedepontodepartidaparaopresente

trabalho.

2.2Web2.0

Actualmente, as aplicações Desktop dominam o mercado, principalmente

devidoao factode seremmuitomais ricas e interactivasqueas aplicaçõesweb. As

aplicações Desktop conseguem ser mais eficientes, mais rápidas e claramente

melhores na interacção com o utilizador uma vez que podem usar capacidades

avançadas do hardware, tanto a nível gráfico, como ao nível de capacidades de

armazenamento e memória, algo que nunca poderá ser igualado num browser.

Obviamente, a estrutura complexa das aplicações Desktop traz desvantagens: é

sempre necessária uma instalação, existe geralmente uma dependência do sistema

operativo,asactualizaçõespodemterdeserdespoletadospeloutilizadoreenvolvem

namaioriadasvezesumaligaçãoàInternet.

São estes problemas que as aplicações web tentam usar a seu favor para

conquistaroseuespaço.Umaaplicaçãowebpodesofreractualizaçõesinteligentese

mudanças profundas na arquitectura da aplicação de uma forma completamente

transparenteeinócuaparaoutilizador.Permitequesepoupetempoedinheiro,pois

não necessita de instalação, e, muitas vezes, ultrapassa as restrições impostas por

16

normasdeempresasquenãopermitemqueosseus funcionários instalemsoftware

nassuasmáquinas.Asaplicaçõeswebtêmtambémumagrandevantagememtermos

de alcance: as aplicaçõesdesenvolvidas seguindoparadigmaweb podem correr em

qualquer browser, em qualquer sistema operativo e a partir de qualquer parte do

globoemqualquerhoradodia.

Oprogramador,noiníciododesenvolvimentodasuaaplicação,terádeoptar

porumaaplicação“richorreach”[4],ouseja,porumaaplicaçãoDesktoptipicamente

mais rica a todos os níveis, ou por uma aplicação web em que o alcance de

utilizadores finais émuitomaior. A escolha é semdúvida complicada, pois existirá

sempreumafronteiraentreestesdoistiposdeaplicação.

É na diminuição das fronteiras entre as tecnologiasDesktop eWeb que têm

surgido conceitos inovadores: frameworks como o AJAX aliadas a um sustentado

desenvolvimentopermitemqueasaplicaçõeswebsejamtãoeficientesericasanível

gráfico comouma aplicaçãoDesktop,melhorando a interacção comoutilizador em

todososaspectos.

AWeb2.0“surgiu”comoformadedenominarosnovosconceitosdeinteracção

com o utilizador e a nova vaga de aplicaçõesweb cada vez mais semelhantes, em

todososníveis,dasaplicaçõesdesktop.

2.2.1Origens

O termo Web2.0 não é usado no contexto de mudança e/ou criação de

protocolosoulinguagensparamelhoraraformadecomunicarcomoutilizador.Ésim

umamudançanousoquesedáaessastecnologiase,acimadetudo,umamudançana

mentalidade de aproximação ao utilizador final. Web2.0 é um regresso às ideias

originaisdaInternet,emqueoconteúdodevesercriadoepartilhadoentretodosos

utilizadores.

Com a Web2.0 o poder é dado ao utilizador. O poder de criar, o poder de

alterareopoderdedestruirtambém.OconteúdonaInternetdeixoudeestarexposto

paraconsultaem sites fechadosemantidosporequipasde técnicosde informática,

parapassaraseracedido,criado,mantidoealteradoporutilizadorescomcadavez

17

menosconhecimentotécnicodecomoosdiversoselementostecnológicosdaInternet

seinterligam.

O termo Web2.0 foi introduzido por Tim O’Reilly na primeira conferência

sobreWeb2.0em2004[5].Nessaconferênciaforamdefendidososprincípiossobre

os quais assentava esta nova Internet: aWeb como uma plataforma, dados como

sendoomotordaInternet,facilidadedeadopçãodenovosutilizadoresemanutenção

dos antigos, novos modelos de negócio orientados ao conteúdo, uma arquitectura

participativa e o contínuo desenvolvimento de aplicações, estando estas

continuamentenumafasebeta.Desteúltimoaspectonasceuumadasmarcasgráficas

daWeb2.0:osímbolobetaomnipresentedurantelargosperíodosdetempoemtodos

os sites que se auto‐intitulam de Web2.0. Mas não foi só esta introdução que

propulsionouasmudançasnoaspectodaspáginas.Acrescentefacilidadedecriação

depáginasHTML,oCSS,oAJAXeapopularidadedediversossoftwaresdeediçãode

imagemlevaramaumaWebmaisapelativaeagradávelàvista.Acabaramaspáginas

comfundobranco,tipodeletraTimesNewRomanapretoeligaçõessimplesaazul.A

Web2.0 traz‐nosumbomgostoeumapreocupaçãoacrescidano lookn’ feelquese

transmiteaosutilizadores.

AWeb2.0nãotrouxeconsigoacriaçãodeumanovatecnologiarevolucionária.

Surgiuapenasumaredescobertadastecnologiasjáexistentes,associando‐asanovos

conceitos,oquepermitiuqueaWeb2.0crescessesemgrandesdesenvolvimentosa

níveldeprogramação.

2.2.2Javascript

Javascript (ECMAScript) [6] é a linguagemde scriptmais amplamenteusada

paraenriquecimentodeaplicaçõeswebnoladodocliente.Asuaprincipalconsistena

possibilidadedeserusadacomocomplementoaocódigoHTMLdeformaapermitir

umaumentodainteractividadeentreoutilizadoreapáginaweb.Istoacontecejáque

Javascript corre localmente no browser do utilizador, o que possibilita que as

aplicaçõeswebsejammaisinteractivas.

O poder do Javascript reside no facto de trabalhar directamente com o

DocumentObjectModel (DOM) [7] que compõeapáginaweb. Interagindo comeste

18

modelo, o Javascript consegue modificar o aspecto das páginas, alterando o seu

conteúdodeacordocomasespecificaçõesdaaplicação.Istoépossível,poisoacesso

aoDOMpermitetambémidentificaroperaçõesrealizadaspeloutilizadoredespoletar

acçõesdeacordocomessasoperações.

Astípicasjanelaspop­upouaidentificaçãodobrowseredosistemaoperativo

queestamosausarsãoalgumasdasfuncionalidadestípicasobtidaspeloJavascript.

Figura4:ExemplodecódigoJavascript

2.2.3XML

O formatoeXtensibleMarkupLanguage (XML) [8]éumametalinguagemque

nos possibilita definir as nossas própriasmarkup languages de forma estruturada.

Uma markup language é um mecanismo que permite identificar de uma forma

sintética as diversas partes de um documento, normalmente recorrendo ao uso de

tags.Podemos,comoXML,“criar”anossapróprialinguagemeguardarinformação

hierarquizada e complexa de uma forma legível, sem recorrer a qualquer software

específico.Aideiaprimordialparaodesenvolvimentodestestandard,foiacriaçãode

umanormaquepermitissequedocumentosespecificadosdeumaformaestruturada

pudessemserpartilhadosatravésdaInternet.

OsdocumentosXMLsãoestruturadoscomumprólogoseguidodeelementos.

Cada um destes elementos pode conter mais elementos e atributos dentro dele,

19

providenciandoumahierarquiaderegiõesbemdelimitadascadaumadelascomum

propósitoespecífico.

Figura5:ExtractodeumficheiroXML

OusodeXML trazdiversosbenefícios,deentreosquaisháquedestacaros

seguintes:

• o factodeser livree independentedeprogramasouplataformas,ouseja,

podemos manipular ficheiros XML em Mac OS X que serão igualmente

lidos e interpretados emWindows, caso a codificação dos ficheiros seja

compatível;

• oXMLé,comoonomeindica,extensível,ouseja,podemoscriarasnossas

próprias tags e fazer actualizações à nossa “linguagem” conforme

necessárioemantendoacompatibilidadecomversõesanteriores;

• arepresentaçãodosdadosestánormalizadaequasetodasaslinguagensde

programação já têm um suporte construído para leitura e escrita de

ficheiros XML, o programador não necessita, neste caso, de estar a

“redescobriraroda”;

• é legível para o utilizador comum, qualquer browser permite que sejam

abertosficheiros.xmleestespodemserlidosecompreendidosfacilmente.

Associado ao XML surgiram outras normas como a eXtensible Stylesheet

LanguageTransformations(XSLT)[9]eaXMLPathLanguage(XPath)[10].

20

A XPath é uma linguagem que permite a selecção de elementos de um

determinadodocumentoXMLdeacordocomumaexpressãoespecífica.AXPathlêo

documento XML comouma árvore de elementos e relações entre eles; destemodo

podemos, aceder ao conteúdo de qualquer elemento de um ficheiro XML comuma

simples expressão XPath. Atendendo ao exemplo de ficheiro XML apresentado

anteriormente (Figura 5), avaliando sobre ele a expressão XPath “persons/person”

obteremostodososelementos“person”quesãofilhosde“persons”.

AXPathservedebaseàsfuncionalidadestrazidaspelasXSLT.Estasegueuma

aproximação funcional na transformação de ficheiros XML.UsandoXPath podemos

fazerumaselecçãodeelementoseaplicar‐lhesastransformaçõesquepretendemos.

A associação destas duas normas permite‐nos efectuar uma transformação

parametrizadaepersonalizáveldedocumentosXMLnoutro tipodedocumentosou

numdocumentoXMLestruturadodemaneiradiferente.AsXSLTspermitemcapacitar

a interoperabilidade entre diversas aplicações: o mesmo ficheiro XML pode ser

transformado de formas diferentes de acordo com as necessidades da aplicação,

facultando que o mesmo formato de dados seja partilhado entre várias aplicações

comobjectivosdiferentes.

O XML “está rapidamente a tornar­se a norma para representação e troca de

dados. Fornece um formato comum para expressar tanto estruturas de dados como

conteúdos.Assim,podeajudarnaintegraçãodedadosestruturados,semi­estruturados

ounãoestruturadosnaWeb”[1].AlémdeserumformatoessencialnaWeb2.0,oXML

étambémumformatoimportantenaintegraçãodedadospois,atravésdele,podemos

definir normas e esquemas para facilitar a integração de dados e serviços,

principalmentenasaplicaçõesWeb.

2.2.4JSON

OJavascriptObjectNotation(JSON)[11]éumformatodetratamentodedados

bastante leve e cada vez mais usado na troca de informação entre aplicações.

EstabelecendoumacomparaçãodirectacomoXML,oJSONévantajosoemtermosde

tamanho e de overhead na estrutura de dados e também no facto de ser mais

21

facilmentegeradoetratadopelasaplicações.TalcomooXML,éumformatobaseado

emtexto.

AsestruturasdosobjectosemJSONsãouniversaisesuportadasportodasas

modernas linguagens de programação: temos pares chave – valor ou então listas

ordenadasdevalores.

No contexto deste trabalho, os objectos JSON podem ser considerados de

significativaimportância.Istoporque,talcomoonomeindica,oformatoJSONvemda

linguagemJavascript,alinguagemutilizadaparatratarosdadosdoladodoclienteea

sua integração nesta linguagem é natural e semproblemas: “nomuss or fuss” [11].

Esta integração com o Javascript é benéfica no que diz respeito à criação de

interfaces, pois podemos tratar o objecto JSON directamente, em vez de efectuar o

parsingdoXMLparaobterainformaçãopretendida.

Figura6:ExemplodeobjectoemJSON

Apesarde“WebServicesserempraticamentesinónimodeXML”[12],oformato

JSON está numa crescente conquista de espaço devido às suas principais

características:leveza,simplicidadeeintegraçãonaturalcomoJavascript.

2.2.5WebServices

UmWebService[13]émeramenteumainterfacedeprogramaçãodistribuída

sobre a web, o seu método de acesso é através da Internet e as operações são

executadasnumservidorremoto.WebServicessãoomaiscomumexemplodeService

OrientedArchitecture(SOA).

Os Web Services funcionam sobre HTML e XML, sendo o XML a base de

comunicaçãoentreoclienteeoservidor.Noentanto,asrespostasdoservidorpodem

estar estruturadas de acordo com diversos formatos: HTML, texto, JSON. As

22

mensagensXMLsãoformatadasdeacordocomanormaSimpleObjectAccessProtocol

(SOAP)[14]eosWebServices têmdeestardescritosdeacordocomaWebServices

DescriptionLanguage(WSDL) [15]eregistados(parapoderemserencontrados)de

acordo com a normaUniversal Description, Definition and Integration (UDDI) [16].

Estas três normas juntas (SOAP,WSDL e UDDI) permitem a fácil interacção entre

duas aplicações comunicando sobreHttp, ultrapassando asbarreiras trazidaspelos

proxiesepelasfirewalls.

Linguagens de programação como o C# [17] têm já uma implementação de

WebServicesdegrandequalidade.Nestalinguagem,asreferênciasaWebServicessão

tratadascomoqualqueroutrareferência local,possibilitandoqueaprogramaçãode

aplicações com C# que usem Web Services seja extremamente simples. O

programador não necessita de ter um conhecimento profundo de como os Web

Servicesfuncionamparapoderusá‐losnodesenvolvimentodassuasaplicações.

O uso de Web Services está a tornar‐se cada vez mais vulgar para quem

pretende fornecer uma API de acesso de alto nível a serviços que detém. OsWeb

Services são talvez uma das formasmais simples de integrar várias aplicaçõesweb

numaarquitecturadistribuída.UsandoWebServicespodemosestabelecerformasde

contacto entre diversas aplicações web sem que qualquer uma delas tenha

conhecimentodaestruturaoudoconteúdoprogramáticodaoutra.

2.2.6CSS

AsCascadingStyleSheets(CSS)folhasdeestilosãoum“ummecanismosimples

paraadicionarestilo(ex.:tiposdeletra,cores,espaçamento)adocumentosWeb”[18].

Usando folhas de estilo podemos personalizar a aparência da nossa aplicaçãoWeb

semtermosderecorreràespecificaçãoparticulardecadacomponente.

23

Figura7:ExtractodeumficheiroCSS

Ao associar as CSS à funcionalidade do Javascript, é‐nos oferecido um leque

maisalargadodepossibilidadesparaa criaçãode interfacesmaisapelativasqueas

tradicionais,umavezquealteraçõesdinâmicasaoestilodanossapáginapodemser

feitasenquantonavegamos.Estaspermitemumamelhor ilustraçãodedeterminada

funcionalidadeouoperaçãoexecutada.As folhasdeestilosãoumdoscomponentes

daaproximaçãoAJAX,descritadeseguida.

2.2.7AJAX

O Assynchronous Javascript and XML (AJAX) não é, por si só, uma nova

tecnologia,massim,talcomoonomeparcialmenteindica,umaaliançaformadaentre

tecnologiasjáexistentes:oJavascript,oXML,asCSSeoDOM.Sucintamente,oAJAX

consiste em usar Javascript e XML para efectuar pedidos a um servidor

dinamicamente e, com a resposta, mudar a aparência das páginas em tempo real.

Diferem das aplicações estáticas antigas no que diz respeito ao tratamento de

pedidos. Estas, ao efectuarem um pedido, obrigavam a uma limpeza da janela de

browsing seguida de um tempo de espera e só depois apareciam os resultados

requeridos. Com AJAX, podemos actualizar apenas as partes da página que

pretendemos e oferecer ao utilizador um novo tipo de experiência: mais eficiente,

maisrápida,maisusável,maisinteractivaemaisfuncionalnousodeaplicaçõesweb­

based.

24

O conceito essencial do AJAX é o seu assincronismo, possível devido aos

objectos XMLHttpRequest. O significado de assincronismo nesta área refere‐se ao

facto de serem efectuados pedidos ao servidor e as suas respostas serem tratadas

sem qualquer interferência visível para o utilizador: as trocas acontecem nos

“bastidores”. Para efectuar pedidos ao servidor é usado o objectoXMLHttpRequest.

Apósacriaçãoeconfiguraçãodestemesmoobjecto,pode‐seprocederaumachamada

aumapágina,bastadepoisdefiniroquefazercomosdadosobtidosparaqueestes

sejam tratados. O tipo de objectos devolvidos pode ser um documento XML, um

documentoHTML,umdocumentodetextosimplesouumobjectoJSON.

AFigura8representaumainteracçãoAJAXsimples.Ospassosdeumpedido

AJAX encontram‐se ordenados numericamente. Depois de carregada a página, o

Javascriptficaàescutadeumevento,comoocliquedoratoouapressãonumatecla.

A esse evento está associada uma função que será chamada aquando da sua

ocorrência (Figura 8 – 1). Nessa função é criado e configurado um objecto do tipo

XMLHttpRequest. De seguida, o objecto XMLHttpRequest executa um pedido ao

servidor(Figura8–2),estepedidoédepoisprocessadopeloservidorquedevolvea

resposta ao cliente (tal como um pedido Http normal) (Figura 8 – 3). Em caso de

sucessonaobtençãodeumaresposta,oXMLHttpRequestpassa‐aà funçãodesejada

quedepoisirátratá‐lacomopretendido,geralmentealterandoalgumapartedoDOM

nobrowser(Figura8–4).

Figura8:Interacçãocliente/servidorAJAX

25

Estetipodeinteracçãopermiteaexistênciadepequenasfuncionalidadesque

o utilizador comum não se apercebe,mas que envolvem alguma complexidade. De

entreessasfuncionalidadesháquedestacarasseguintes:

• formulários auto‐completáveis, em que os dados são automaticamente

preenchidosdeacordocomainformaçãodisponível;

• submissão parcial, em que dados de formulários são enviados e

processadospeloservidor;

• validaçãodedadosemtemporeal,osdadosdeformuláriosquerequerem

validaçãoporpartedoservidorpodemservalidadosseminterferênciado

utilizador;

• mashups, as páginas podem ter componentes provenientes de partes

distintasdaweb;

• pré‐carregamento de dados, as aplicações web podem basear‐se nos

eventos despoletados pelo cliente e numa previsão dos seus passos

seguintesparacarregardados,acelerandoodownloaddapágina;

• efeitosecontrolosdeinterfacemaisrápidosesofisticados.

Este tipode funcionalidades,possíveis comrecursoaAJAX,possibilitamaise

melhoresinteracçõescomosutilizadoresdasaplicaçõesWeb.Outilizadortemmais

controlosobreassuasacçõesnaaplicaçãoeaaplicaçãoémuitomaisricaefuncional,

aproximando‐sedasaplicaçõesDesktopedandoaoutilizador,totalcontrolosobrea

aplicação:umdosideaisWeb2.0.

AutilizaçãodeAJAXtemumaimportantevantagemqueconsistenaseparação

entredados,estilo,formataçãoefuncionalidade(Figura9).Pensandonautilizaçãodo

AJAX desde a primeira fase de concepção da aplicação, o desenvolvimento da

aplicação pode incluir uma separação funcional benéfica. Os dados podem ser

incluídos num formato próprio, num ficheiro XML, como simples texto ou tratá‐los

directamentenumformatopróprioparabasesdedados.Épossívelformatarapágina

HTMLdemodoaestarpreparadaparaasdiversaspossibilidadesdeinteracçãocomo

DOM.Pode‐seconfiguraroaspectodanossapáginacomrecursoaumaoumaisfolhas

deestiloCSS,quepermitemdefinir todososelementos intervenientesnaaparência

finaldanossapágina.

26

Figura9:OrganizaçãomodulardoAJAX

Claro que existe o reverso da medalha. A dependência do Javascript pode

revelar‐se problemática pois os diversos browsers existentes não suportam as

mesmasfuncionalidadesdalinguagemenemtratameventossemelhantesdamesma

forma.OAJAXconstituitambémumabarreiraparaaoptimizaçãoperantemotoresde

buscaeparaasferramentasdeanálisedesites.Istoporque,sendooconteúdogerado

quase na sua totalidade dinamicamente e dependendo do Javascript, os dados

mostrados não se encontram disponíveis através de um endereço particular e os

motoresdebuscanãoexecutaminstruçõesdeJavascript,porqueestasdependem,na

sua maioria, de eventos despoletados pelo utilizador. Existem também alguns

problemasnoquetocaàlatênciaprovocadapelosdiversospedidosaoservidor,que

podem levar a que o utilizador fique à espera que aconteça algo sem ter qualquer

feedback por parte da aplicação. Mas a grande desvantagem prende‐se com a

integraçãodoAJAXnobrowser.Sendoquasetodooconteúdocriadodinamicamente,

nãopodemosefectuarasimplesoperaçãode“retroceder”nobrowser,poisestenão

sabe o estado em que a aplicação se encontrava nem como chegar de novo a esse

estado. Esta característica também não permite a gestão de favoritos da aplicação,

umavezqueoqueseráguardadoéoURLdabarradeendereçodobrowserenãouma

representaçãodoestadoemqueaaplicaçãoseencontra.

Contudo, o desenvolvimento para colmatar estas falhas tem feito grandes

progressoseoAJAXcomeçaasercadavezmaisusadoemaplicaçõesWebdealguma

complexidade.

27

2.3ExemplosdeaplicaçõesWeb2.0

AWeb2.0trouxeumanovavagadeaplicações.Ovalorea funcionalidadeda

maioria destas aplicações pode ser questionado. No entanto, vieram modificar o

quotidianodosutilizadoresda Internet–anívelprofissionaloudeentretenimento,

mesmoqueestesnãoseapercebamdessefacto.

Deseguidaéfeitaumapequenaapresentaçãodasmaisrelevantesaplicações

queusamasideiastrazidaspelaweb2.0.

2.3.1Folksonomy

Agrandemudançanamaneiradepensara Internetsurgiucoma introdução

da denominada folksonomy. Sem qualquer tradução possível para Português, este

termoreflecteoaspectomais importantedanovaWeb:astags,ouetiquetas.Poder

categorizaroconteúdodonossotrabalho,dasnossasligações,dosnossosvídeos,dos

nossos artigos, permite um melhor acesso à informação e o aparecimento de

algoritmosdeprocuramuitomaiseficazesaextrairoquerealmentesepretendeao

carregarnobotão“Procurar”.

A grande vantagem no uso de tags prende‐se com o facto do papel da

categorizaçãoseratribuídoaoHomemenãoamáquinaseseusalgoritmos.Podemos

associarmelhorarespectivatag,ouconjuntodetags,aocontextodoqueestáaser

categorizado.Istoprovidenciamelhoresresultados,temposdepesquisamaisrápidos

e maior satisfação por parte do utilizador final. Como é óbvio existem problemas

inerentes ao uso de alguns vocábulos, palavras homónimas são omelhor exemplo

disso:“Banco”comoinstituiçãofinanceiraou“banco”parasentar?“Canto”decantar

ou“canto”dasala?Opróprioactodeatribuirastagspodenãosermuitoseguro,pois

as pessoas tendem a usar um conjunto restrito de significados, diminuindo a

pluralidadedoquepodeserditonummesmocontexto.

OusodefolksonomiespodelevaràtãodesejadaWebsemântica:cadapágina

com as suas tags permitiria uma precisão melhor dos motores de pesquisa. A

28

complicaçãoque surgeneste aspecto éna criaçãodeumanormaparadefiniçãode

tags.Oseugrandepoderétambémasuagrandeperda.Ofactodeseremcriadaspela

mãodoHomempodelevaramásintenções–spamcomtagsfalsas,porexemplo–ea

subjectividadeinerenteaomesmonuncapoderáserrecriadanoambientemecânico

daWeb.

Aumnívelmaistécnico,ousodefolksonomieslevouapequenasmudançasna

estruturadasaplicações.NaspáginasWeb,ousodeetiquetagemrevela‐secadavez

mais importante e as etiquetas podem ser declaras na sua própria tag dentro do

códigoHTMLdapágina.UmaaplicaçãoWebmaiscomplexa,quetrabalhecombases

dedadosporexemplo,teráapenasdeprevernasbasesdedadosumaestruturacom

tabelas e relações entre elas que suporte as várias tags e a ligação das tags como

restodoconteúdo.

2.3.2SocialBookmarking

Osocialbookmarkingconsiste,sucintamente,empartilharosnossosfavoritos

atravésda Internet.Ao invésdos favoritospermaneceremalojadosnobrowser, são

partilhadosatravésdediversasaplicaçõesWeb(Digg,Reddit,del.icio.us)comtodos

os outros utilizadores que visitam os mesmos sites. Este tipo de aplicações é tão

comumque, emdiversaspáginas, o botão “Adicionar aos Favoritos” foi substituído

porligaçõesquepermitempublicarapáginaemquestão,nestesserviços.Osfavoritos

ficamdisponíveisparaqualquerutilizadorseguiretambémguardar,sedesejar.Este

é um dos melhores exemplos do uso das já referidas folksonomies: etiquetando,

partilhamosmais eficazmenteos favoritos e, comnovosepoderosos algoritmosde

pesquisa,podemosobterresultadosmaisfiéis,deacordocomarelevânciadadapelos

utilizadoresedastagsdecadafavorito.

Tabela1:Aplicaçõesdesocialbookmarking

Descrição EndereçoDel.icio.us:agregadordefavoritos http://del.icio.us Digg:agregadordenotícias http://www.digg.com Reddit:agregadordefavoritos http://reddit.com

29

A Figura 10mostra a interface simples do site del.icio.us e na tabela temos

alguns exemplos de aplicações de social bookmarking bastante famosas naWorld

WideWeb.

Apesardeparecerumaaplicaçãobastantecomplexae terumvasto lequede

funcionalidades, a arquitectura do del.icio.us é relativamente simples e foi

desenvolvida – em part­time – por uma pessoa apenas. O essencial é ter uma

arquitecturadetaggingeficienteeumalgoritmodepesquisarápido,poisaestrutura

dabasededadosérelativamentesimples.

Figura10:http://del.icio.us

2.3.3SocialNetworking

Osocialnetworking–redessociais– tevetambémoseugrandeboomcoma

Web2.0.Redesdeamigoseconhecidossãocadavezmaisfrequenteseocupamcada

vez mais tempo e importância na vida e nas relações da juventude actual. Na

generalidade,estasaplicaçõesWebnãosãoapenasredesdecontactos,massimsites

com muitas funcionalidades, desde a partilha de ficheiros até à criação e

armazenamentodeálbunsdefotos.

30

O funcionamentodestas redesébastante simples, começa‐sepelo registode

umacontaedepoisbastapartilhar informaçãopessoaleadicionarcontactosàrede

deamigos.

Tabela2:Aplicaçõesdesocialnetworking

Descrição EndereçoHi5:redesocialbastantepopular http://www.hi5.com MySpace:redesocialdeartistas http://www.myspace.com Orkut:redesocialdoGoogle http://www.orkut.com

Aoníveltécnico,nocasodoHi5,oSGBDescolhidofoioPostgreSQL[19]com

recursoabasesdedadosespalhadaspordiversaszonasgeográficasde formaa ter

ummelhordesempenhonadisponibilizaçãodainformaçãoaocliente.OMySpaceusa

tambémváriasbasesdedados,dividindoainformaçãomaiscomumemaisacedida–

informaçãopessoal–embasesdedadosmaisrápidaseainformaçãomaispesadae

menosacedida–vídeosemúsicas–emservidoresdistintos.

Figura11:http://www.hi5.com

2.3.4Wiki

Aswikis vêm substituir as convencionais enciclopédias em papel. Umawiki

consistenumaglomeradodepáginas,cominformaçãoprovenientedasmaisdiversas

31

áreas, que podem ser criadas, editadas e apagadas pelos utilizadores. O conceito

surgiuem1995comaWikiWikiWeb.

A mais famosawiki é aWikipedia, uma verdadeira enciclopédia online com

informaçãosobrequasetodosos temas,mantidapelosutilizadoresedisponívelem

maisdeduascentenasdelínguas.Oconsórcioquemantémestawikimantémtambém

diversas outras relacionadas com outras áreas de influência como dicionários de

línguasouespéciesbiológicasexistentes.

Oalcancedaswikisestátambémamudar.Comoprocessodecriaçãodewikis

cada vez mais simplificado, quem produz pequenas aplicações opta por criar uma

wiki a servir de Frequently Asked Questions (FAQ), pois novos utilizadores podem

adicionarproblemasoueditarinformaçãojáexistente,melhorandoafuncionalidade

doprogramaeaqualidadedasuadocumentação.

Como seria de esperar, todo este poder dado ao utilizador vai trazer

problemas. Dados podem ser falsificados ou informação errada pode ser

disponibilizada deliberadamente. Para combater este problema, aWikipedia optou

por bloquear o acesso a algumas das páginas mais importantes, utilizadores mal

intencionadosnãopossamfazerprevalecerosseusactos.

Figura12:http://www.wikipedia.org

32

ParamanteraWikipediaafuncionar,aWikimediatemumsistemacomplexo

comumaarquitecturabaseLinux,Apache[20],MySQL[21],PHP[22](LAMP)onde

são adicionadosdiversosmódulos:GeoDNS [23]para localização, Lucene [24]para

pesquisa,Lighttpd[25]paraalojar imagensediversosmecanismosdecachingpara

melhorarodesempenhodaaplicação.

2.3.5Blogs

BlogésemdúvidasinónimodeWeb2.0,apesardeserumconceitoquesurgiu

hámaisde30anos,nosprimórdiosdaInternet.Oconceitodesimplesdiáriopessoal

onde podemos partilhar experiências, histórias ou opiniões, quer sejam reais ou

ficcionais,é,àpartida,bastanteapelativo.

Usados de início apenas para divulgação dentro demeios restritos, osblogs

cresceram e a sua influência estendeu‐se para os campos da política e

entretenimento.Osblogs tornaram‐seumadasformasmaissimplesdefazerpassar

uma mensagem em massa à juventude cada vez mais virada para as novas

tecnologias.

Tabela3:Aplicaçõesdeblogging

Descrição EndereçoBlogger:aplicaçãodoGoogle http://www.blogger.com Wordpress:aplicaçãoparajornalistas http://www.wordpress.com MovableType:plataformadepublicação http://www.movabletype.com

Aarquitecturadearmazenamentode informaçãodeumblogésemdúvidaa

mais simples que existe. É suficiente ter uma base de dados com uma tabela para

podermos ter um sistema de blogging a funcionar correctamente. Claro que

adicionando funcionalidades para aumentar as mais valias da aplicação a

complexidadeiráaumentar,masnuncaseráumsistemadeelevadacomplexidade.

33

Figura13:http://www.blogger.com

2.3.6Feeds

Osmecanismosdefeedsforamtambémmuitoimpulsionadospelaevoluçãoda

Web2.0. Estas novas normas para formatação de dados, como o Really Simple

Syndication (RSS) [26], facilitam a partilha de informação, seja ela texto, áudio ou

vídeo. O mecanismo é simples, o utilizador subscreve uma feed, de um blog por

exemplo, e ela é actualizada sempre que o conteúdo doblog sofre alterações. Uma

feedéassimumasintetizaçãodasúltimasentradasnumarquivodedadosespecífico,

como, por exemplo, um blog ou um arquivo áudio. Diversas aplicações, tantoweb

comoDesktop,usamfeedsparaacederemetrataremainformação.Exemplificando,as

maisrecentesaplicaçõesDesktop,usammecanismosde feedsparamanteraversão

instaladanumcomputadorsempreactualizadacomaúltimaversãodisponível.

34

Figura14:http://multimedia.rtp.pt

ARTPdisponibilizagrandepartedasuaprogramaçãoáudioevídeoatravésde

subscrição por feeds, o que permite que possamos acompanhar o nosso programa

preferidomesmoquenãooconsigamosouvirouveremdirecto.

A tecnologia de subscrição de feeds depende muito do formato XML (já

mencionado nesta dissertação). O formato RSS e o seu principal concorrentemais

recente,Atom[27],sãoambosespecificadosnumesquemaXMLparapermitiramais

fácilpartilhadeinformação.

2.3.7MediaSharing

Aplicações demedia sharing tambémapareceram comaWeb2.0.De ente as

diversasaplicaçõesexistentesháquedestacaroYouTube.

Figura15:http://www.youtube.com

35

Existem também aspectos nefastos na partilha de multimédia sendo o

principalapartilhadeficheiroscomdireitosdeautor.Asaplicaçõesdemediasharing

eas inovaçõesqueelas trouxeramemtermosdepartilhademultimédia–comoos

web media players – vieram aumentar a facilidade na partilha de ficheiros,

favorecendoapirataria.

Tabela4:Aplicaçõesdemediasharing

Descrição EndereçoYouTube:omaisfamosositedepartilha http://www.youtube.com SapoVídeos:ferramentadoSAPO http://videos.sapo.pt Twango:partilhadefotos,vídeoseáudio http://www.twango.com

AntesdasuaagregaçãoàredeGoogle,oYouTubeassentavanumaplataforma

LAMP(tal comoaWikimedia)àqual se juntavao interpretadordePython[28]eo

psyco[29],paracompilaçãodinâmicadePythonparalinguagemC.

2.3.8WebDesktops

Outras das aplicaçõesweb mais interessantes que surgiram com a Web2.0

foramosWebDesktops.Nestasaplicaçõesépossívelconfigurarumapáginawebpara

quetenhaumainterfaceemtudoidênticaàdonossoSistemaOperativo.

Figura16:http://www.eyeos.info

36

Estas aplicações contêm conjuntos de funcionalidades bastante completos:

desdejogosaprocessadoresdetexto,istoparaqueconsigamalcançaroobjectivode

conjugar,namesmapáginaWeb,tudooquesepodefazernoDesktopdeumSistema

Operativo. Devido à sua elevada compatibilidade – qualquer browser, qualquer

Sistema Operativo – e de serem facilmente e amplamente configuráveis, estas

aplicaçõesestãonumacrescentecurvadepopularidade.

Tabela5:AplicaçõesWebDesktop

Descrição EndereçoEyeOS http://www.eyeos.info DesktopTwo https://desktoptwo.com Netvibes http://www.netvibes.com

2.4Integraçãodedadoseserviçosusandofluxosdeinformação

Aprincipal ideiasubjacenteaotrabalhodescritonestadissertaçãoprende‐se

comacriaçãodeumainterfacequeproporcioneumaumentodafacilidadenoacesso

a informação e serviços fornecidos por diversas fontes. Perante este objectivo, foi

necessário escolher a metáfora ideal para a integração das fontes de dados e

funcionalidadesdispersas.

A solução encontrada consiste em dar ao utilizador a possibilidade de

construir um fluxo de informação – Workflow – que tem como entrada os dados

iniciaissubmetidospeloutilizador–Dataset–edevolve,nofinaldoprocessamento,a

informação pretendida. Como definido pela Workflow Management Coalition, um

Workflowéa “automatizaçãoou simplificação computorizadado todooudeuma só

partedeumprocesso” [30].Éprecisamenteestadefiniçãoessencialquesepretende

cobrirusandoumfluxodeinformaçãoemquediversosserviçossãoencadeados:“Um

aspecto chave no encadeamento de serviços é a possibilidade de usar directamente a

saídadeumserviçocomoentradaparaoutro”[31].Ouseja,oobjectivoéproporcionar

aoutilizadoraoportunidadedeacederadiversosserviçosfechados,heterogéneose

dispersos, de uma forma dinâmica, sequencial e personalizável. Cada um deste

37

serviçosérepresentadoporumwrapper(ouadaptador,designadonaarquitecturade

MódulodeProcessamento),queéapenas identificadopela localizaçãodoserviço,o

tipo de dados de entrada que aceita e o tipo de dados que devolve na saída. O

utilizadortemapossibilidadedeconstruiropercursoquepretendedaràinformação.

Estaaproximaçãodiferencia‐sedosmétodosdeintegraçãodeserviçosestáticos,em

queoworkfloweraconstruídoprogramaticamentenodesenvolvimentodaaplicação,

enãodavaaoutilizadorqualquertipodecontrolosobreomesmo.

Figura17:Exemplodefluxodeinformaçãopersonalizado

Oworkflowpodesercompostopordiversosadaptadoresquerepresentamo

acessoadiferentesserviçose fontesde informação(Figura17).Nestesmódulosde

processamento(Figura18),osdadosdeentradasãoprovenientesdosdadosdesaída

domóduloanterior.Cadaumdosadaptadorescorresponderáaumafuncionalidade

ou fonte de informação disponibilizada por entidades externas à nossa aplicação e

queestãodisponíveisatravésdeumendereçoWebpúblico.

38

Figura18:Diagramadofluxodeinformação

A Tabela 6 tem uma explicação sucinta dos elementosmais importantes da

aplicação.Foisobreestemétododeprocessamentoquefoidesenhadaearquitectada

aaplicaçãodescritanestadissertação.

Tabela6:Descriçãodascomponentesdosistema

Elemento Descrição

DatasetDadosiniciaisfornecidospeloutilizadorparainíciodoprocessamentodofluxodeinformação.ÉaentradadoprimeiromódulodeprocessamentodoWorkflow.

MódulodeProcessamento

Funçãotípica.Trabalhasobreosdadosquerecebeàentradademodoaproduzir dados de saída de acordo com o fornecido por uma entidadeexterna.Podemsermétodosde filtragemde informação,deprocuradeinformação,deagregaçãodeinformação.Ostiposdedadosdeentradaesaídapodemserdistintos.Completamente independentes da aplicação, são apenas fornecidas asconfigurações de entrada e saída, o que acontece dentro deles nãointerferecomofuncionamentodaaplicação.

WorkflowAgrupamento ordenado de módulos de processamento que pode sereditadopeloutilizadordeacordodemodoaobterainformaçãofinalquepretende.

Dataflow Conjuntodetrabalho:DataseteWorkflow.

Usando fluxos de informação é possível aceder a dados e funcionalidades

mantidos por diversas fontes de uma forma transparente. Com este método

consegue‐secriarumsistemagenérico:queroutilizador,queraaplicaçãoemsi,não

39

sabem o que acontece em cada passo do processamento, apenas necessitam de

construirofluxodeformaaqueacoerênciaentreosdadossejamantida.Esteaspecto

é sem dúvida um ponto a favor da aplicação, pois permite que sejam tornadas

públicasfuncionalidades–atravésdeWebServicesporexemplo–queescondemtudo

o que acontece do lado da entidade, salvaguardando, assim, trabalho e informação

privados. Este método permite também que um problema geral de alguma

complexidade, seja dividido em pequenos sub‐problemas, sendo cada um deles

resolvido num wrapper específico e através de uma estratégia de “dividir para

reinar”.Aliadoaestesfactores,surgeaindaofactode,atravésdeumpequenoDataset

comoinformaçãodeentrada,serpossívelextraireaumentaroconhecimento,como

processamentoorganizadodosdiferentesadaptadores.

2.4.1AplicaçõesWeb2.0deGestãodeWorkflows

UsandoasnovaspotencialidadesfomentadaspelaWeb2.0,surgiramonlineas

primeirasaplicaçõesdegestãodeworkflowsqueseguemprincípiossemelhantesao

quepretendemosalcançar.

Nesta área, énecessáriodarodevidodestaqueaduasdelas:Yahoo!Pipes e

Microsoft Popfly. Ambas fornecem um ambiente gráfico web­based que permite

construirfluxosdeinformaçãoatravésdeadaptadorespré‐definidosequesuportam

diversasfuncionalidades.

MicrosoftPopfly

APopfly [32],criadanos laboratóriosdaMicrosoft, forneceumapanópliade

siteseadaptadorespré‐definidossobreossepodetrabalhar.

Centrada numa perspectivas de trabalho sobre feeds, grande parte das

funcionalidades oferecidas por esta aplicação lidam com o manuseamento das

mesmas: existem sobretudométodos para agregação e filtragem de informação. A

maioria dos wrappers pré‐definidos encontra‐se associado a aplicações Web de

diversasáreasepoucasalteraçõespodemsofrer.

40

Figura19:http://www.popfly.com

A interfacedaaplicaçãobaseia‐seemcubosdaptadoresquese ligamatravés

de pontos de contacto. Esta de interface muito pouco usável e para alcançá‐la, a

PopflynecessitaqueoutilizadortenhainstaladoopluginSilverlightnoseubrowser,

umpontonegativonaavaliaçãodaaplicação.

Yahoo!Pipes

CriadapelaYahoo!,aPipes[33]éumaaplicaçãobastantemaisavançadaquea

Popfly. Os blocos de processamento são representados por caixas arrastáveis

interligados através de pontos de contacto em vez dos cubos da Popfly e

apresentandoumainterfacebastantemaislimpaeintuitiva.

Ao contrário da Popfly, a Pipes destina‐se a um público diferente. São

necessários alguns fundamentos gerais de programação e funcionamento da Web,

pois funciona aproximadamente como uma linguagem de programação: tem

operadores,ciclos,estruturascondicionaise tiposdedados.Nesteaspecto, também

temosmenosmódulosdeprocessamento jáconstruídoseédadaaoutilizadoruma

totalliberdadenapersonalizaçãodosmesmos.

41

Figura20:http://pipes.yahoo.com

2.5Sumário

Neste capítulo são apresentadas diversas tecnologias e formas de efectuar a

integração de dados e serviços e de disponibilizar a informação obtida. Há ainda

bastantetrabalhonosentidodemelhorarainteracçãodoutilizadorcomasbasesde

dados, principalmente para os utilizadores sem qualquer conhecimento técnico de

comoprocessarainformação.Umdosgrandesproblemasquesurgenestainteracção

éo factodeoutilizador estardependentedequeries pré‐definidaspara acesso aos

dados.Ouseja,o conjuntode informaçãoquepodeserextraídadeumconjuntode

bases de dados é, na generalidade, pré‐definido e depende daquilo que os

programadores e os donos das bases de dados fornecem. O utilizador final da

aplicação não pode definir qual o fluxo que a informação deve levar por forma a

conseguirobterosresultadospretendidos.Outilizadorestásemprepresoafunções,

amotoresdepesquisaeaworkflowsquejáexistemparaobterainformação,fazendo

com que nem sempre os resultados sejam os melhores e o utilizador tenha de

procederaumasegundaanáliserecorrendoaoutrasaplicaçõesouferramentas.

42

43

3 Arquitectura Web 2.0 para integração de dados e

serviçosusandofluxosdeinformação

Comomencionadopreviamente,aintegraçãodedadoscomeçaasercadavez

maiscomumemaplicaçõesWeb,principalmentedevidoàscaracterísticaseideiasda

Web2.0.

Neste capítulo pretende‐se definir uma arquitectura típica de aplicações

Web2.0 que suporte a integração de dados e serviços com base em fluxos de

informaçãopersonalizados.

O objectivo de permitir que o utilizador construa o seu próprio fluxo de

informaçãoeaparticularidadedaintegraçãodeserviços–nãosódedados–levamà

necessidadedeefectuarumestudorigorososobreaarquitectura.Osistematemde

serescaláveleflexíveltantoaníveldecomponentesqueusacomoaníveldeserviços

e fontes de dados que irá integrar. A complexidade da arquitectura é ainda

aumentada devido ao facto de se tratar de uma aplicaçãoWeb: não será instalada

num computador próprio para uso particular e terá de estar sempre online,

disponível a qualquermomento e a partir de qualquer local, funcionando com um

desempenhoaceitável.

A solução encontrada usando fluxos de informação levanta ainda diversos

requisitos muito específicos e que contribuem também para o aumento da

complexidadedaarquitectura.

Na primeira parte temos uma descrição das diversas funcionalidades

pretendidas. A esta descrição segue‐se uma secção com diagramas ilustrativos da

organizaçãodaaplicaçãoemfunçãodosrequisitosexistentes.

44

3.1Funcionalidades

As várias funcionalidades pretendidas encontram‐se organizadas em três

gruposdistintos:GestãodeUtilizador,GestãodoDataseteGestãodoWorkflow.

Na Tabela 7 encontra‐se uma lista do conjunto de funcionalidades da

aplicação.

Tabela7:Listadefuncionalidades

Nome DescriçãoGestãodeUtilizador

Registar

Utilizador regista‐se no sistema, para poder usufruir detodasaspotencialidadesdo sistema.O registoenvolveofornecimentodealgunsdadoseacriaçãodeumusernamecomumapasswordassociada.

LoginUtilizador entra no sistema, pode aceder a todas asfuncionalidades da aplicação, nomeadamente às queenvolvemumhistórico.

Logout Utilizadorsaidosistema.

AlterarPassword Utilizador pode alterar a sua password de acesso aosistema.

GestãodeDataset

NovoDataset Utilizador insereosdadosnecessáriosparaaconstruçãodeumnovoDataset.

VerDataset Utilizador visualiza a informação que tem numdeterminadoDataset.

EditarDataset UtilizadoreditaainformaçãodeumdeterminadoDataset.

ApagarDataset Utilizador remove um Dataset previamente guardado.Apenasparautilizadorregistados.

AbrirDataset Utilizador abre um Dataset previamente guardado.Apenasparautilizadoresregistados.

VerTodosDatasets Utilizador vê todos osDatasets que possui. Apenas parautilizadoresregistados.

GestãodeWorkflowNovoWorkflow UtilizadoriniciaaconstruçãodeumnovoWorkflow.EditarWorkflow UtilizadoralteraosdadosdeumWorkflow.

ApagarWorkflow Utilizador apaga um Workflow previamente guardado.Apenasparautilizadoresregistados.

AbrirWorkflow Utilizador abre um Workflow previamente guardado.Apenasparautilizadoresregistados.

VerTodosWorkflows UtilizadorvêtodososWorkflowsquepossui.Apenasparautilizadoresregistados.

AdicionarMódulodeProcessamento Utilizador adicionamódulo de processamento à posiçãopretendidanoWorkflow.

RemoverMódulodeProcessamento Utilizador remove o módulo de processamento quepretendedoWorkflow.

AlterarOrdemdeMódulodePocessamento

Utilizador altera a ordem do módulo de processamentopretendidonoWorkflow.

PartilharWorkflow UtilizadortornaoseuWorkflowpúblicoparaqueoutrosutilizadorespossamacedê‐lo.

ClonarWorkflow UtilizadorclonaoWorkflowpretendido.

45

3.2RequisitosTécnicos

Além das funcionalidades necessárias pelo utilizador, uma aplicação de

integração de dados e serviços destinada a ter as características que desejamos,

necessitadecumprirdiversosrequisitosdeníveltécnico.Éapartirdestesrequisitos

queseráestruturadoosistemadesuporteàaplicaçãoeàsfuncionalidadesdamesma.

3.2.1Generalidadedeserviços

Umdosprincipaisrequisitosdaarquitecturadaaplicaçãoéasuageneralidade

e,aliadaaesta,asuaflexibilidadeeescalabilidade.

Para alcançar a generalidade de serviços é necessário que os adaptadores

sejamcompletamenteindependentesentresiefuncionemdeacordocomumanorma

pré‐definida. Desde que haja respeito pela norma, o sistema terá de suportar um

workflowcomumqualquernúmeroeordemdewrappers.

Istoimplicaqueaimplementaçãodecadamódulotenhadeserindependente

daaplicação,ouseja,tudooqueacontecedentrodomódulonãoteráinterferênciada

aplicação,fornecendoestaapenasosdadosdeentradaerecebendoosdadosdesaída.

3.2.2Processamentodoladodocliente

Apesar doswrappers necessitarem de efectuar o acesso a um servidor para

obtençãodainformação,oprocessamentodofluxodeinformação–transferênciados

dadosdasaídadeumadaptadorparaaentradadoadaptadorseguinte–terádeser

feitodoladodocliente.

Este requisito implica que o tratamento da informação e a sua canalização

dentro do workflow seja tratado no browser do utilizador. Este método permite

pouparcargadesnecessárianoservidor libertando‐oparaummelhor fornecimento

daspáginasHTMLaocliente.

46

3.2.3Integraçãodosserviçosdeutilizadornumaplataformaexistente

O utilizador (e seus respectivos dados) terão de estar dependentes de um

serviçocentralizadodeautenticaçãoindependentedestaaplicação.

Este requisito implica que os métodos para tratar a área de Gestão de

Utilizador terão de trabalhar com APIs fornecidas por um sistema externo. Este

acesso ao serviço de autenticação pode ser efectuado de diversas formas: acesso

directoàbasededados,APIprogramadaouWebServices.Noentanto,énecessário

que a aplicação não seja dependente do tipo de acesso aos dados de utilizador

escolhido,porformaafacilitaramigraçãoparaoutroserviçodeutilizadores.

3.3ModeloeArquitectura

3.3.1Componentes

Numa aplicação Web, mais que nas tradicionais aplicações Desktop, os

recursosnecessáriosparaobomfuncionamentodaaplicaçãosãovariados.Tendoem

contaqueaaplicaçãoprecisade serescalável, flexíveleestaronline24hpordia, a

utilizaçãodediversascomponentesparaqueoserviçosejamaiscompleto, torna‐se

essencial.

ServidorWeb

OelementomaisimportantedaaplicaçãoésemdúvidaoservidorWeb.Éeste

recurso que irá receber os pedidos do cliente e tratá‐los de acordo com o

programado,porformaaforneceraoutilizadortodasasfuncionalidadesdaaplicação.

É também no servidor Web que estarão alojados os componentes

programáticosdaaplicação:aligaçãoentreasdiversasAPIs,asclassesquemapeiam

abasededadoseocódigonecessárioparaopré‐processamentodaspáginas.

47

SistemadeGestãodeBasesdeDados

Ainformaçãoaarmazenarporumaaplicaçãodeintegraçãodedadosésempre

bastante elevada. Juntando a esta os dados de suporte necessários às diversas

funcionalidades de gestão de Datasets e Workflows temos uma quantidade

consideráveldedadosaarmazenar.

Uma base de dados seguindo um tradicional modelo relacional é a melhor

opçãoparaguardarosdiversosdadoserelaçõesentreeles.

ServidordeUtilizadores

Talcomofoireferidoanteriormente,aGestãodeUtilizadoresfazpartedeum

sistema independente da aplicação onde esta terá de se integrar de forma

transparente.

Não sendo da competência da nossa aplicação manter este componente, é

necessário que esteja sempre operacional por forma a não comprometer o

funcionamentoglobaldanossaaplicação.

MódulosdeProcessamento

TalcomooServidordeUtilizadores,o funcionamentodoswrappers também

terádeserindependentedaaplicação.

Estes módulos devem ter uma funcionalidade fechada e, de forma a serem

inter‐operáveisentresi,seguirumanormapré‐definida.

3.3.2Modelo

Omodelodesuporteàaplicaçãorevela‐sesimpleseobjectivo.Mesmotendo

umextensonúmeroderequisitosacumprirerecursosausar,omodelotraduz‐seem

3camadasdistintas(Figura21).

48

Figura21:Modelodaaplicação

Começando pelo nível inferior, temos a primeira camada, de acesso aos

adaptadores,aoServiçodeUtilizadoreseaoSGBDdaaplicação.

Acima desta temos a camada de processamento. Nesta camada temos o

processamentodoladodoservidor,ondeétratadooconteúdodaspáginasamostrar

aoutilizadoreoprocessamentonocliente,ondeétratadoofluxodeinformaçãono

workflowconstruídopeloutilizadoreavisualizaçãodarespostaaalgumasoperações.

No topo, temos a camada do cliente, onde se encontra o browser que o

utilizadorusaparaacederàaplicação.

3.3.3Arquitectura

A arquitectura da aplicação é igualmente simples. A Figura 22 pretende

mostrarumavisãodaarquitecturadosistema.

49

Figura22:Arquitecturadaaplicação

Sucintamente,ofuncionamentodaaplicaçãosubdivide‐seemtrêscategorias.

Acessos do cliente ao Servidor Web: quando o utilizador abre o site e utiliza a

aplicação, os pedidos são efectuados directamente ao ServidorWeb e tratados por

este. Acessos do Servidor Web aos serviços externos: caso seja necessário para a

realização de uma determinada funcionalidade o Servidor Web tem de aceder ao

SGBD (Gestão deDatasets eWorkflows) ou ao Servidor deUtilizadores (Gestão de

Utilizadores).Aúltimacategoria,incluiasinteracçõesentreobrowserdoclienteeos

módulosdeprocessamento,istoduranteoprocessamentodofluxodeinformação.

3.4Sumário

Este capítulo apresenta uma primeira análise do sistema. Sãomostradas as

funcionalidadesdaaplicação,orecursosqueterádeusareosrequisitosqueteráde

cumprir.

No final é apresentadaumaproposta de arquitectura para cobrir damelhor

formatodasasáreasapresentadas.

50

51

4DynamicFlow

Actualmente, os grandes problemas da informação disponível na área da

biologiasão:agrandequantidadededadoseaheterogeneidadedasferramentasque

tratamedisponibilizamosmesmos[34].Aheterogeneidade–dedadoseferramentas

–éapalavrachavenacontextualizaçãoaquiapresentada.

Aheterogeneidadededados,distribuídospordiversasfontesearmazenados

emmúltiplosformatos,fomentamaintegraçãodedadosdemodoaconseguirobter

maisemelhorinformação,daformamaissimplesedirectapossível.

A heterogeneidade de serviços, ou seja, funcionalidades distribuídas por

diversasaplicaçõeseusandodadosemétodosdeexecuçãocompletamentedistintos,

fomentamousodefluxosdeinformaçãoorganizadosemmódulosdeprocessamento,

cadaumdelescomumserviçoautónomoenãorelacionadocomosoutros.

Para melhor perceber o problema partimos de uma questão biológica

específica:“Umgeneticistalocalizouumfactordeobesidadenumaregiãoaté5­Mbdo

cromossomahumano.Existemgenesnestaregiãoquetenhamhomólogosqueestejam

envolvidosnaregulaçãodometabolismodelípidosemqualquersistemamodelo?”[35].

Responderaestaquestãonãoétãosimplesquantopossapareceràprimeira

vista. Uma primeira solução passaria por realizar todo o trabalho de pesquisa “à

mão”,percorrendoas imensasbasesdedadosexistentese realizandoasoperações

necessáriasatéobtermosanossaresposta.Alternativamente,poder‐se‐iaprogramar

uma aplicação que respondesse a esta pergunta, fornecendo‐lhe tudo o que seria

necessárioparachegaraumaresposta.Estaalternativapareceválida,pelomenosaté

apareceroutraquestão,tornandonecessárioprogramaroutraaplicação.

Analisandooprocessoderesoluçãodoproblema,concluímosqueénecessário

dividir o problema em sub‐problemas mais pequenos e mais simples de resolver,

sendoque, para cadaumdestes sub‐problemas temosdepesquisar numa fonte de

dados ou usar um serviço disponibilizado online por alguma entidade. Tudo isto,

seguindoumadeterminadaordem,comosedeumaequaçãomatemáticasetratasse.

52

Oidealseriaterumaaplicaçãoquepermitisseresponderatodasasperguntas

semelhantes à citada, em que, introduzida a pergunta, o processo fosse

completamente autónomo até à obtenção da resposta. No entanto, a tecnologia

disponívelaindanãoétãoavançadaparapermitirumaaplicaçãodestegénero.Oque

é exequível, e este é o principal desafio lançado para a construção da aplicação

DynamicFlow, é uma aplicação que permita que o utilizador resolva os seus

problemas de forma modular, construindo um fluxo de informação personalizado

paracadaquestãoequepossibilite,dentrodomesmofluxodeinformação,oacessoa

serviçosdistintoseafontesdedadosdistintas.

Assim,nodesenvolvimentodaaplicaçãotentou‐seproporcionaraoutilizador

umaestratégiaderesoluçãodeproblemas“dividirparaconquistar”,comintegração

deinformaçãoeserviçosparaexpansãodeconhecimento,seguindolinhasWeb2.0.

4.1EstratégiasdeDesenvolvimento

Deformaaconseguirsatisfazertodososrequisitosfoinecessárioserbastante

criterioso nas escolhas dos componentes a utilizar. Tal como já foi referido, é

necessário teremcontaqueaaplicação temdeestardisponível24horaspordiae

com um desempenho aceitável para o máximo número de utilizadores possível.

Atingir estameta implica escolher asmelhores tecnologias disponíveis.Não existiu

umapreocupaçãopelousodesoftware livreapesardocódigo finaldaaplicaçãoser

disponibilizadosemqualquerrestrição.

Mesmo antes de começar a programar, a aplicação teve de ser planificada,

tendo‐seescolhidoas tecnologiasque seriamusadaspara responderaosobjectivos

propostos, cumprindo os requisitos traçados. As escolhas foram feitas para que a

aplicação se integrasse damelhor forma possível com o conjunto de aplicações do

grupojáexistentes,simplificandoaselecçãodealgunsdoscomponentes.

53

ServidorWeb

Ao considerar que Servidor Web deveria ser escolhido, as opções são: um

servidor livre – Apache (dentro de qualquer sistema operativo) ou um servidor

comercial–WindowsServer[36].

Atendendoaofactodeasaplicaçõesrealizadasdentrodogrupocorreremde

momentonumservidorWindowsServer2003ealinguagemdepré‐processamento

usadaserumacombinaçãodeASP.NET[37]comC#‐linguagemorientadaaobjectos,

umconceitoquesetentouutilizardesdeoiníciodaplanificaçãodosistema–optou‐

se por manter a coerência e seguir a estratégia de implementação de aplicações

existentenogrupo.Comestaescolha,osuporteaotrabalhodentrodoprópriogrupo

encontra‐sefacilitadopoistratam‐sedeáreasondeexisteexperiência.

OutracombinaçãopossívelseriausarumservidorApache(ouqualqueruma

dassuasramificações)eapostarnumaarquitecturabaseadana linguagemJava.Em

termos globais, os dois caminhos que podiam ter sido seguidos são semelhantes e

dariamosmesmoresultadosparaoutilizador.

Paraacomponentefinaldecontactocomoclientetemosoformatotípicodas

páginasWeb,oHTML,quepodeserpós‐processadoatravésdeJavascript.

SistemadeGestãodeBasedeDados

NaescolhadoSGBDausar,asopçõessãovariadas.Optandopelaaproximação

relacionalnoSGBD,foramconsideradasasseguinteshipóteses:MySQL,PostgreSQL,

Oracle[38]eMicrosoftSQLServer[39].

Aescolharecaiumaisumavezsobreaopçãomaiscoerentecomaspráticasdo

grupo: o Microsoft SQL Server. Este SGBD tem um grande desempenho e

escalabilidade.Comojáéousadopelasrestantesaplicaçõesdogrupo,oprocessode

configuraçãofoisimples.

NãoentrandoemdiscussãoretóricasobrequalomelhorSGBD,odesempenho

doMicrosoftSQLServerépúblicoepesounadecisão.AopçãoOraclefoidescartadaà

partidadevidoaofactodeenvolverumalicençadeutilizaçãoqueogruponãotem.As

outrasopções,MySQLePostgreSQLforamdescartadasdevidoaofactodenãoserem

usadasnosservidoresdogrupo.

54

No entanto, devido à arquitectura da aplicação, o SGBD é completamente

independentedarestanteaplicação.Istosignificaquepodeseralteradoemqualquer

altura,bastandoumasimples reconfiguraçãoda camadadeacessoaoSGBD,paraa

aplicaçãocontinuarcompletamentefuncional.

ServidordeUtilizadores

Sabendodeantemãoqueogrupopretendecentralizarnumserviçoúnicoas

áreasdeutilizadoresdassuasaplicaçõesequeusanestasaFramework.NET[40]da

Microsoft, a escolha para o serviço de utilizadores recaiu sobre o serviço de

autenticaçãofornecidoporestaarquitectura(Figura22).

Esteserviçoprovidenciagrandepartedasfuncionalidadesnecessáriasparao

manutenção de utilizadores e, usando‐o, cumpre‐se um dos requisitos traçados à

partida,relacionadocomofactodeoserviçodeutilizadoresterdeserindependente

deaplicaçãoeestepodersertrocadocomrelativafacilidade.

Uma descrição completa da arquitectura de autenticação (Figura 23) usada

não é do âmbitodesta dissertação, importano entanto referir os principais pontos

positivosdaarquitecturaescolhida.

Figura23:ArquitecturadeautenticaçãodaFramework.NET

55

Esta arquitectura implementa diversos serviços: além do tradicional serviço

de Membership de utilizadores existe um serviço de Roles para definição de

autorizações dentro das aplicações e podemos ter também distinções entre as

diversas aplicações do grupo. Esta arquitectura é bastante flexível e traz a grande

vantagemdeserde fácilutilizaçãodentrodoesquemadeaplicaçõesqueestamosa

usar:usandoASP.NETeMicrosoftSQLServer, todososmétodosnecessáriosparaa

Gestão de Utilizadores, deMemberships e deRoles, encontram‐se implementados e

bem documentados simplificando a tarefa de construir uma arquitectura de

autenticaçãocentralizadadelargaescala.

Maisumavez,oacessoaesteserviçodeautenticaçãocentralizadotambémse

encontradependentedeapenasumacamadadaaplicação,oque facilitaoprocesso

demigraçãoparaoutroesquemadeautenticaçãoemcasodenecessidade.

MódulosdeProcessamento

Como previsto no início do projecto, os componentesmais difíceis de obter

foramosadaptadores.Estadificuldadeprende‐sesobretudocomofactodeteremde

respeitar uma especificação criada de raiz de propósito para esta aplicação. Não

obstante esta dificuldade, uma aplicação de integração de dados do grupo de

Bioinformática–BioPortal– foimodificadapor formaaprovidenciarwrapperscom

tarefasindividuais.

OBioPortaléumaplataformadeintegraçãodedadosbiológicosheterogéneos,

tantoaníveldeformatodosdadoscomoaníveldasclassesdedadosarmazenados.

No BioPortal tenta‐se aproveitar as melhores características dos métodos de

integração de dados existentes. Assim, são combinadas as vantagens do data

warehousing, do uso de mediadores e da integração de ligações. O processo de

inserção de novas fontes de dados, usando de qualquer um dos métodos, foi

simplificadoenormalizado.Estaaproximaçãohíbridavisamelhorarodesempenhoe

sobretudoaescalabilidade,noacessoadadosbiológicosdispersos.OBioPortal jáé

usado numa aplicação bioinformática, o Genebrowser [3], e que serviu de base ao

presentetrabalho.

56

UsandooBioPortalcadamódulodeprocessamentocorrespondeaumpedido

aumendereçoWebespecífico,fornecendonaquerystringdopedidoosargumentos

deentrada.

Figura24:ExemplodequerystringdeacessoaoBioPortal

Aquery string possui argumentos bastantes específicos através dos quais se

diferenciamosdiversosadaptadores.ATabela8mostraosargumentosdisponíveise

asuafuncionalidade.

Tabela8:EspecificaçãodosargumentosdeentradadoBioPortal

Argumento Descrição

ssnEspécie.DefineaqueespéciepertenceainformaçãogenéticacontidanoDatasetparaqueosdadospossamsercorrectamenteprocessados.

retTypeFormatodedadosderetorno.Definequaloformatoemqueosdadosserãodevolvidos,podemserdevolvidosemformatoXMLouJSON.

objIdIdentificadordoobjecto.UsadoquandooformatoderetornodosdadoséJSONparaidentificaroobjectodevolvidocontendoainformação.

method Método.OmétododoBioPortalqueserviráparaefectuaraoperaçãoquepretendemos.

filterList Listadeelementos.Informaçãodeentradanomódulodeprocessamento.

filterCol Tipodeelementos.DefinequalotipodeelementosdeentradacontidosnafilterList.

limit Limitedesaída.Defineonúmeromáximodeelementosdesaídaquesãodevolvidospeloadaptador.

offset Defineooffsetaplicadoaoconjuntodedadosdesaída.

comp Compressãodedados.Defineseacompressãodedadosnasaídaestáactivaouinactiva.

Sabendoestainformação,opassoseguintepassouporforneceràaplicaçãoas

características de cada módulo de processamento. Sabendo que elementos fixos

compõemcadaumdesteswrappers,podemostorná‐lospartedofluxodeinformação

ajustandoasvariáveis–osdadosdeentrada(filterList)porexemplo–deacordocom

ainformaçãodoworkflow.

57

Orequisitoessencialdosadaptadores teremdeser independentesentresie

fornecer a sua funcionalidade de forma fechada restringiu as implementações

possíveis.Acrescentandoàlistaderequisitosexistentesofactodoprocessamentodo

workflow ter de ser feito nobrowser do cliente, as escolhas reduzem‐se amétodos

Web. Nestes métodos temos a solução escolhida, um pedido HTTP composto por

diversosargumentosouentãoefectuarpedidosatravésdeWebServices.Autilização

destes a partir de Javascript revelou‐se um processo complexo, pouco fiável e

dependentedebibliotecasexternas.Porseulado,ospedidosHTTPsãodirectosedão

aos programadores a liberdade de programar os módulos das mais variadas

maneiras, quer em termos de linguagem de programação, quer em termos de

argumentosdeentradaeconstruçãodaquerystring.

4.2Interfacedeutilizador

Ainterfacedaaplicaçãoéoprincipalpontodecontactoentreoutilizadorea

aplicação. É o principal elemento na complexa arquitectura pois é o que os

utilizadoresvêmeondeosutilizadorestrabalham.

Oprocessodecriaçãodeuma interfaceWeb2.0quepossibiliteorespeitode

todososrequisitosanalisados,ealieafuncionalidadeàusabilidade,foiumprocesso

moroso. Diversas opções foram tomadas de modo a proporcionar a melhor

experiência de utilização possível. A principal destas opções envolvia a escolha da

tecnologiaausarnainterfaceprincipalquetinhadeteremcontaesteidealWeb2.0,o

conjuntodefuncionalidadesqueiriamseroferecidasaoutilizadoreadinâmicafinal

daaplicação.Foramconsideradastrêstecnologias:AJAX,FlasheSilverlight.

Nas palavras da empresa Adobe, o Flash é “o plugin de cliente de alto

desempenho, leve e fortemente expressivo que fornece poderosas e consistentes

experiênciasdeutilizadoremqualquersistemaoperativo,browser,telemóvelououtro

dispositivo”[41].Defacto,atecnologiaFlashrevela‐semuitoapetecívelparaacriação

deinterfacesdinâmicaseinteractivasparaaplicaçõesWeb.Noentanto,acriaçãodas

interfacesécomplexaeaintegraçãocomaarquitecturaemutilizaçãopouconatural.

58

“MicrosoftSilverlightéumpluginparaqualquerbrowser,qualquerplataforma

equalquerdispositivopara fornecerapróximageraçãodeexperiênciasmultimédiae

aplicações para aWeb interactivamente ricas, baseadas em .NET” [42]. Tal como a

Adobe,aMicrosoftpublicitaasmesmascaracterísticasnasuatecnologiaconcorrente

aoFlash.Contudo,atecnologiaSilverlightdaMicrosoftéaindamuitorecenteedáde

momento os primeiros passos como alternativa na construção de interfaces

dinâmicas.Apesardograndepotencialedafácilintegraçãocomaarquitectura.NET

usadanaaplicação,ofactodeaindaestarinstáveleemdesenvolvimentosãofactores

contrabastantepesadosnaanálisedestatecnologia.

AstecnologiasFlasheSilverlighttêmumgrandepotencialesão,semsombra

dedúvida,asmaisusadasactualmentenasnovasaplicaçõesWebqueenvolvemum

grandeníveldeinteracçãocomoutilizador.Têmnoentantodeserdescartadaspara

a interface doDynamicFlow devido ao facto de necessitarem que o utilizador final

instaleumpluginnoseucomputadorparaquefuncionem.Estefactoésemdúvidao

maisimportantenaalturadeescolherquetecnologiausarnainterface.Istoporquea

aplicação é desenvolvida num ambiente científico e tem como utilizadores finais

elementosdeinstituiçõesouempresasquegeralmentenãopodeminstalarsoftware

nocomputadorqueusamparaefectuaroseutrabalho.

Restaojámencionado“aglomerado”detecnologiasAJAX,queservedemotor

aquasetodasasaplicaçõesWeb2.0eque,apesardasuacomplexidade,ultrapassaos

principaisproblemasexistentesnautilizaçãodeSilverlightouFlash.

É importante também mencionar que a interface encontra‐se sempre num

constante processo demelhoramentos, quer através de sugestões dos utilizadores,

quer através do melhoramento da interacção com o utilizador na execução de

algumasfuncionalidades.

Deseguidasãoapresentadasascomponentesmais importantesda interface.

Sãoconsideradascomosendoasmaisimportantes,poissãoaquelasqueserãousadas

maisvezeseterãomaisinfluênciaduranteotrabalhodoutilizadornaaplicação.

59

Áreadetrabalho

ComosetratadeumaaplicaçãoWebcompletaenãoumasimpleswebsite,há

quedaradevidaimportânciaàprincipaláreadetrabalhodoutilizadorfinal.

Énaáreade trabalhoqueéconstruídooWorkflow,oprincipalelementoda

aplicação.A construçãodoWorkflowé um conjuntode operações que se pretende

dinâmico, rápido e fácil. No entanto, é também necessário mostrar ao utilizador

diversasáreas: casooadaptador sejaum filtro, épreciso reservarumaáreaparao

utilizador inserir as característicasdo filtro, e énecessário reservarumaáreapara

uma pequena descrição dowrapper, caso o utilizador tenha dúvidas quanto à sua

funcionalidade.

Aáreadetrabalhoencontra‐sedivididaemduaszonasprincipais:azonados

módulosdeprocessamentoeazonadoWorkflow.

A zona dos módulos de processamento contém uma lista de todos os

adaptadores disponíveis, organizados segundo uma terminologia coerente com o

âmbitodabioinformática,ondeaaplicaçãoseinclui.

Na zona doWorkflow, existem 3 áreas distintas. Do lado esquerdo temos a

área de entradas de utilizador, onde são mostradas as opções que envolvem uma

escolhadoutilizadorparacontinuarofluxodeinformação.Nazonacentraltemoso

Workflowpropriamente dito, uma lista de blocos, cada umdeles correspondente a

um adaptador e com informação visual para realização de diversas operações. No

lado direito temos a área de descrição do módulo de processamento, sector

informativo onde o utilizador pode saber tudo o que necessita sobre determinado

adaptador.

60

Figura25:Esquemadaáreadetrabalho

Menus

SendoaaproximaçãodasaplicaçõesWebàsaplicaçõesDesktop tradicionais,

umadasideiassubjacentesàWeb2.0,oconceitodemenufoiadoptadoeajustadoàs

necessidadesdaaplicação.

Figura26:InterfacedoMenudaaplicação

61

O utilizador pode, na sua área de trabalho, aceder às funcionalidades

referentes ao Dataset e aoWorkflow navegando para o respectivomenu, tal como

faria numa aplicação Desktop. A figura 26 exemplifica a navegação para o opção

Workflow do menu, onde são mostradas as várias funcionalidades disponíveis

relacionadascomaGestãodoWorkflow.Acomposiçãodomenuvariadeacordocom

apáginaemvisitaedeacordocomotipodeutilizadoranavegarnapágina.

Orecursoaosmenus,permitequeoutilizadorsesintamaisfamiliarizadocom

a aplicação e que a aprendizagem das capacidades da aplicação se realize mais

depressa.

Call‐outs

Durante a utilização da aplicação DynamicFlow existe, naturalmente, uma

grandequantidadedeinformaçãoqueterádeserapresentadaaoutilizador.

ArealizaçãodeoperaçõestípicascomoAbrirDataset,EditarDatasetouAbrir

Workflownecessitade chamar a atençãodoutilizador,mas isto semque eleperca

noção do local onde se encontra na aplicação, do trabalho que está a fazer e sem

quebrar a experiência de utilização com elevados tempos de espera e páginas em

branco.Paraconseguiralcançarestesobjectivossãousadoscall­outs:painéisquese

sobrepõem suavemente sobre a página mostrada no browser e que podem conter

todaainformaçãonecessáriaàrealizaçãodealgumafuncionalidade.

A Figura 27mostra o funcionamento de um call­out na nossa aplicação. Ao

seguir uma ligação que executa uma funcionalidade que necessite de mostrar

informaçãoaoutilizador,aáreadetrabalhoésombreadaesurgedotopodapágina

uma nova área focada com uma nova página a mostrar ao utilizador. Ao realizar

alguma operação que feche o call­out, o utilizador regressa à página onde se

encontravapreviamente,comamesmatransiçãosuavedeaparecimentodocall­out.

62

Figura27:Exemplodeumcall­outnaaplicação

Listademódulosdeprocessamento

Umadasprincipaiszonasdaáreadetrabalhoéaquecontema listagemdos

adaptadoresdisponíveis.

Esta lista é carregadadinamicamente a partir do ficheiroXMLque guarda a

configuração dos módulos de processamento. Para criar esta componente da

interface, é utilizada uma folha de transformação XSL (Figura 28), que irá ler o

ficheiro de configuração XML e criar a interface da listagem completa

automaticamente.

63

Figura28:ExtractodoficheiroXSLparatransformaçãodosmódulosdeprocessamento

Como já foi mencionado, um dos aspectos a ter em conta na criação da

interface, foiaelevadaquantidadede informaçãoqueémostradaaoutilizador.Por

formaadiminuirestaquantidade,esabendoqueosdiversoswrappersseencontram

agrupadosporcategorias,optou‐seporusarummecanismoque,inicialmente,apenas

mostraonomedascategoriasexistentes.Outilizadorpodedepois,expandircomum

cliquecadaumadascategorias,paraqueosmódulosdeprocessamentopertencentes

àcategoriaseleccionadasejammostrados.Sedesejar,outilizadorpodedepoisvoltar

aesconderalistadeadaptadores,clicandodenovonacategoria(Figura29).

64

Figura29:Interfacedalistademódulosexpandida

Figura30:Interfacedelistademódulospordefeito

65

OperaçõessobreoWorkflow

Aprincipal característicadesta aplicação é, semdúvida, a construçãodeum

fluxode informação.Tendoemmenteesteaspecto,a interfaceparamanuseamento

doWorkflowtevedeserbastantetrabalhada.

Para construir um Workflow é necessário Adicionar Módulos de

Processamento, Remover Módulos de Processamento ou Alterar a Ordem dos

MódulosdeProcessamento.Porformaamelhorarausabilidadedaaplicação,foram

criadasduasformasderealizarestasoperações:atravésdeumcliqueouatravésde

drag­n­drop.

A operação de drag­n­drop traduz‐se numa melhor metáfora de utilização,

igual à usada nos Sistemas Operativos e aplicações Desktop. A sequência clicar,

arrastar, largar é familiar para o utilizador e, apesar de menos intuitiva nas

aplicaçõesWeb,revela‐semuitomaisfuncionalpoispermitecolocaroadaptadorna

posiçãoexacta.

Contudo,ocliqueéaoperaçãomaisefectuadanaspáginasWeb.Assim,através

de símbolos representativos das acções a efectuar, é possível efectuar todas as

operaçõespossíveissobreoswrappers.

Figura31:Exemplodainterfacedosmódulodeprocessamentonaaplicaçãonoworkflow

66

A Figura 31 mostra um exemplo de módulos de processamento, dentro do

Workflow, na interface da área de trabalho. Cada bloco é composto pelo nome do

adaptador,botõesparapassarparaaposiçãoanteriorouseguinte,botãoparavera

descriçãodo adaptador, botãopara removero adaptadordoWorkflowe, caso seja

um adaptador que necessite de entradas do utilizador, um botão para visualizar e

editarestasentradas.

Informaçãodaáreadetrabalho

Cada utilizador pode guardar uma multiplicidade de Datasets, Workflows e

combinações entre Datasets eWorkflows. Para que o utilizador saiba sempre com

queWorkfloweDatasetestáa trabalhar, foi incluídanaáreade trabalhoumazona

cominformaçãorelativaaoconjuntoactual.

EstaáreadeinformaçãocontémonomedoDataseteumaligaçãoparaeditar

osdadosdoDataset,onomedoWorkfloweopçãoparaalterá‐lo,informaçãosobrea

última data de acesso ao Workflow e ainda uma ligação para a funcionalidade

GuardarWorkflow.

AcessibilidadeWeb

“AcessibilidadeWebsignificaquepessoascomdeficiênciaspodemusaraWeb”

[43]. As aplicações Web têm um conjunto de características específicas que

aumentamacomplexidadedasuautilizaçãoporpartedepessoascomalgumtipode

handicap. É mais complicado para este tipo de pessoas compreender, navegar e

interagircomaexperiênciaWebnaturalparaosrestantesutilizadores.

AplicandoasboaspráticasrecomendadaspeloWorldWideWebConsortium

[44], a aplicação DynamicFlow torna‐se não só acessível para pessoas com

deficiências,mastambémmuitomaisacessíveleutilizávelpeloutilizadorcomumda

aplicação.

SeapenaspudéssemosconstruiroWorkflowatravésdaoperaçãodedrag­n­

drop estaríamos a reduzir a acessibilidade do site a utilizadores que não tivessem

possibilidadedeusarumqualquerdispositivoapontador.Paracolmatarestafalha,foi

67

criada a possibilidade de efectuar o clique numa hiperligação ou usar as teclas de

atalho disponíveis. A existência de teclas de atalho revela‐se tambémbastante útil,

especialmente no acesso ao menu da aplicação. O utilizador pode usar apenas o

tecladoparaefectuaratotalidadedasfuncionalidadesqueaaplicaçãooferece.

4.3Arquitectura

4.3.1Diagramadabasededadosdaaplicação

Para suportar o armazenamento da informação de Dataset e Workflows

pertencentesacadautilizador,foinecessárioelaborarumesquemadebasededados

seguindo o modelo relacional, que guardasse estes dados e permitisse um

desempenhoóptimonaexecuçãodasfuncionalidadesdaaplicação.

AFigura32esquematizaaestruturadabasededados,mostrandoasdiversas

tabelascriadaseostiposdedadosdecadacampo.

68

Figura32:EsquemadaBasedeDados

Como se pode comprovar, o esquema da base de dados é relativamente

simples. A Tabela 9 mostra uma pequena descrição dos elementos pertencentes a

cadatabela.

69

Tabela9:DescriçãodasrelaçõesdaBasedeDados

Tabela Elemento DescriçãoWorkflowID IdentificadorúnicodecadaWorkflowWorkflowName NomedadopeloutilizadoraoWorkflowCreation DatadecriaçãodoWorkflowLastUsed DatadaúltimamodificaçãodoWorkflow

Workflow

Utilizador ReferênciaparaoutilizadoraqueoWorkflowpertenceDatasetID IdentificadorúnicodecadaDatasetDatasetName NomedadopeloutilizadoraoDatasetSpecie EspécieaquepertencemosgenesdoDatasetCreation DatadecriaçãodoDatasetLastUsed DatadaúltimamodificaçãodoDataset

Dataset

Utilizador ReferênciaparaoutilizadoraqueoDatasetpertenceDataflowID IdentificadorúnicodecadaconjuntoDataseteWorkflowLastUsed DatadoúltimoacessoaoDataflowDataset ReferênciaparaoDatasetDataflow

Workflow ReferênciaparaoWorkflow

GeneID Identificador único de cada Gene, normalizado para oformatoEntrezGene

GeneName NomedecadaGeneDatasetGeneID IdentificadorúnicodecadarelaçãoentreDataseteGeneDataset ReferênciaparaoDatasetemqueoGeneéutilizadoGene ReferênciaparaoGeneDatasetGene

Enabled Marcadoractivo/inactivosobreousodoGenenoDataset

Element ElementID IdentificadorúnicodecadaelementodoWorkflow,igualaoXMLIDdecadamódulodeprocessamento

Workflow ReferênciaparaoWorkflowElement ReferênciaparaomódulodeprocessamentoWorkflow

ElementsPosition PosiçãodomódulodeprocessamentodentrodoWorkflow

4.3.2DiagramadeClassesdaaplicação

Aorganizaçãoporclassesdaaplicaçãoencontra‐seesquematizadanaFigura

33.

Deacordocomomodelado,oacessoàbasededadosrealiza‐senumacamada

únicasintetizadanaclasseDBAccess.Énestaclassequesãoimplementadostodosos

métodosdecomunicaçãocomasbasesdedados.Asrestantesclassesdemapeamento

da base de dados – Gene, Workflow, Datas(et) e Element – implementam apenas

métodosdeligaçãoàsimplementaçõesdaclasseDBAccess,queéinstanciadadentro

decadaumadasclasses.Estaestruturatentapôremprática,daformamaiscoerente

possível, omodelopropostona secção3.3.2.Opré‐processamentodaspáginasnão

70

usaa classeDBAccessdirectamente,massimuma instanciaçãodamesmapresente

emcadaumadasclassesquemapeiamoconteúdodabasededados.

Figura33:DiagramadeClassesdaaplicação

4.3.3Fluxodeexecução

Devidoàarquitecturaespecíficadestaaplicaçãoénecessáriorealçarofluxode

execuçãodealgunsmétodos.

OmétodomaisimportantedaaplicaçãoéoprocessamentodoWorkflow.Este

método envolve a comunicação entre o browser e diversos módulos de

processamentodispersos.

71

OprocessamentodoWorkflowéiniciadoapósacçãodoutilizador(Figura34–

1). Depois do processamento inicial no browser, é estabelecido contacto com o

servidordeadaptadoresiterativamente(Figura34–2).Esteprocessoédescritoem

mais detalhe no capítulo 4.4.4. No final, após obtida a informação do último

adaptador,oJavascriptdespoletaalteraçõesnoDOMdapágina,mudandoainterface

deutilizadorparamostrarosresultados(Figura34–3).

Figura34:FluxodefuncionamentodoprocessamentodoWorkflow

Ooutrofluxodeexecuçãotípicoéseguidopelasrestantesfuncionalidadesda

aplicação. As funcionalidades de Gestão de Dataset e de Workflow usam este

mecanismoparaexecução.

O contacto é iniciado pelo utilizador ao realizar uma acção, geralmente

chamando uma funcionalidade através do menu da aplicação (Figura 35 – 1). De

seguida, é executado ummétodo Javascript que entra em contacto com o Servidor

Webdaaplicação;estacomunicaçãopodeserumpedidoHttpsimplesouumpedido

deexecuçãodeumafunçãoespecífica(Figura35–2).Aaplicação,deacordocomo

pedidorecebido,devolveosdadospretendidos(Figura35–3).Apósprocessamento

peloJavascript,oresultadodafuncionalidadepretendidaémostradonainterfacede

utilizador(Figura35–4).

72

Figura35:Fluxodefuncionamentodefuncionalidadesgeraisdaaplicação

4.4Problemas

Comoseriadeesperar foramencontradosdiversosproblemasaocolocarem

prática toda a arquitectura que tinha sido planeada. Os principais problemas

encontradoseassoluçõesadoptadasbemcomoasalternativasexistentesencontram‐

sedetalhadosdeseguidanestasecção.

4.4.1SameOriginPolicy

ASameOriginPolicydiz‐nosqueapenasosobjectosprovenientesdamesma

origem que a nossa página podem interagir com a nossa aplicação: “objectos

provenientes damesma origem (isto é, domesmo host, usando omesmo protocolo e

porto)podeminteragirentresi.”[45](Figura36–Modelo1).

EstapolíticaéusadacomométododeprotecçãodeataquesaaplicaçõesWeb

portodososbrowsersdaactualidade.

Aoprojectarofuncionamentodosdiversosadaptadores,partimosdoprincípio

que a interacção apenas se daria entre o browser do cliente e o servidor que

implementao adaptador.Esta interacção, semprequeo servidordoadaptadornão

coincidecomodaaplicação,causaumaviolaçãoàSameOriginPolicy, levandoaque

73

nãopossaocorreratravésdosmétodostradicionaisdecomunicaçãoentrebrowsere

servidor(Figura36–Modelo2).

Umadasprimeirassoluçõestestadasconsistiaemutilizaronossoservidorda

aplicaçãocomoProxydoservidorqueimplementaosmódulosdeprocessamento[46]

(Figura36–Modelo3).

Figura36:ModelosdefuncionamentodepedidosXMLHttpRequest

Usarestasoluçãoiriaimplicarmudançasnaarquitecturamodeladaecausara

inserção de mais um intermediário entre o cliente e o módulo de processamento,

diminuindo o desempenho da aplicação e alterando a arquitectura projectada

originalmente.

74

Outra alternativa estudada consistia em usar um pequeno ficheiro com

tecnologia Flash para fazer o acesso aos servidores dos adaptadores. Além do já

mencionado problema em usar a tecnologia Flash, este método tem também o

problemadenecessitardeumficheirodeconfiguraçãoespecíficonoservidorondese

encontra o módulo de processamento a autorizar explicitamente que aceita os

pedidosdanossaaplicação.

A solução usada foi a última estudada: On Demand Javascript. Este método

implementa uma solução sem intermediários e com processamento no browser do

utilizador. “O carregamento inicial da página inclui código Javascript que, além de

outras coisas, contém o código necessário para descarregar mais Javascript” [47].

Explicando,anossapáginapodeconterpedaçosdecódigoJavascriptimplementando

funçõesquecarregamdinamicamenteoutrospedaçosdecódigoJavascript.

Partindo do princípio que os módulos de processamento devolvem código

Javascript,nonossocaso,objectoscodificadosatravésdeJSON–requisitosuportado

peloBioPortal, podemos realizarospedidosdinamicamente, carregandoa resposta

JSON dos módulos de processamento no browser e acedendo ao objecto que ela

contém.

Figura37:ExtractodecódigoJavascriptparacriaçãodeumatag"script"

OcarregamentodecódigoJavascriptemruntimenecessitaquesejaexecutado

um método de criação dinâmica de etiquetas “script”. Nas páginas HTML, a tag

“script” ‐ <script> ‐ serve para englobar o código Javscript que será carregado na

memória do browser e estará disponível para execução enquanto a página se

encontrar aberta. Esta marca pode englobar pedaços de código ou simplesmente

apontarparaumficheiroquecontenhaocódigoqueserácarregado.Oendereçodo

ficheiro que contem o código Javascript que será carregado é indiferente para o

75

browser, não sendo afectado pela Same Origin Policy. Tendo em conta estas

características, basta adicionar no processamento de cada elemento do fluxo de

informação,umanovatag“script”queaponteparaoendereçoconstruídoapartirda

descrição do adaptador, para que o valor de retorno do referido módulo seja

carregado dinamicamente em memória. A saída de um determinado módulo de

processamento fica, assim, disponível como entrada ao módulo de processamento

seguinte.

4.4.2Definiçãodanormadosmódulosdeprocessamento

Para garantir a independência e a interoperabilidade entre os diversos

adaptadores foi necessário definir uma norma que todos respeitassem, que

suportasseasdiversasdefiniçõesdeconfiguraçãodecadamóduloequefosseomais

completapossível.

Paratal,foiescolhidooformatoXMLparadefiniçãodoesquemadosdiversos

adaptadores. Os módulos encontram‐se definidos num ficheiro XML que passará

depois por uma folha de transformaçãoXSL de forma a obter a lista demódulos a

mostrarnaáreadosmódulosdeprocessamentodaáreadetrabalho.

ATabela10mostraosprincipaiselementospresentesnanormaXML.

Tabela10:Descriçãodaespecificaçãodosmódulosdeprocessamento

Elemento DescriçãoDisplayName Nomedomódulodeprocessamentoamostrarnainterfacedaaplicação.

DescriptionPequena descrição domódulo de processamento. O conteúdo deste elemento serámostrado na zona da área de trabalho referente à descrição de cada módulo deprocessamento.

Input Descriçãodotipodedadosdeentradadomódulodeprocessamento.Output Descriçãodotipodedadosdesaídadomódulodeprocessamento.UrlString Endereçoachamarparaexecutaromódulodeprocessamento.ObjectString DescriçãodoobjectoJavascriptdevolvidopelomódulodeprocessamento.

UserInput

Opcional.Apenaspresentequandoomódulodeprocessamentoenvolvea inserçãode dados pelo utilizador. Um exemplo é umMódulo de filtragem que necessita dainserção do filtro pelo utilizador. No XML, são descritas as características dasentradas:umasimplesTextBoxouoconjuntodevaloresdeumaDropDownList.

76

Nesta aplicação os diversos módulos de processamento encontram‐se

agrupadosemcategoriasde formaasimplificaroacessoaosmesmos,ouseja,cada

módulodeprocessamentovaipertenceraumacategoriapré‐definidadeacordocom

asuaáreadeaplicaçãonabioinformática.

AFigura38mostraumexemplodeummódulodeprocessamentodescritoem

XML.

Figura38:ExtractodoficheiroXMLdedescriçãodosmódulosdeprocessamento

Devido às vantagens do XML mencionadas no segundo capítulo desta

dissertação,estaopçãofoiaúnicaconsideradapararesolveroproblemaexistentena

definiçãodanormaqueosmódulosdeprocessamentoteriamdeseguir.

4.4.3Passagemdeinformaçãodosmódulosdeprocessamento

O requisito de atribuir a carga de processamento do workflow ao cliente

levantamaisumproblema:oarmazenamentodainformaçãorelativaacadamódulo

deprocessamento.

Como já foi referido, oswrappers sãomodelados através de um ficheiro de

configuraçãoescritoemXML.Osdadoscontidosnesteficheirosãoessenciaisparao

correcto funcionamento do fluxo de informação. No entanto, quando decorre o

processamento do Workflow, não temos acesso directo ao ficheiro XML de

configuraçãoatravésdoJavascript.

77

Para conseguir aceder a estes dados seria necessário carregar o ficheiro do

servidor, envolvendomais transferênciasdedados.Esta solução implicava também

umacessoaoficheiroXMLatravésdeJavascript,funcionalidadequenãoseencontra

normalizada,variandodebrowserparabrowser,oqueimplicaacriaçãodecódigoque

suporte osmais variados tipos de implementações de leitura e escrita de ficheiros

XML.Destemodo, alémde sermaisuma transferênciadedados (oque é sópor si

indesejável)edetermosumficheirodeconfiguraçãobastantegrande,temostambém

a dificuldade de acesso ao ficheiro. Pesando estes pontos negativos, a opção de

transferiroficheiroXMLparaoclientefoidescartada.

Paraultrapassarosproblemasdatransferênciadoficheiro,optou‐seporusar

a escalabilidade do formato HTML para armazenar dentro dos seus elementos a

informaçãoquenecessitamos.As diversas etiquetasHTMLpodempossuir diversos

atributos–pareschavevalor;estesatributossãousadospelobrowserparadistinguir

elementos,aplicarfolhasdeestilooudefinirpropriedadescaracterísticasdecadatag.

Avantagemdautilizaçãodestesatributoséqueobrowserapenasinterpretaaqueles

queconhece.Faceaestasituação,épossívelcriarosatributosnecessáriossemtrazer

qualquerproblemaaobrowsernoprocessamentodapáginaHTML.

Figura39:ExtractodoHTMLdeummódulodeprocessamento

É possível preencher uma tag “list item”, filha de uma “unordered list”, com

atributos que possibilitam o armazenamento da informação necessária ao

processamentodonossofluxodeinformação(Figura39).

Estemétodo, permite a definição de qualquer número e tipo de atributos –

desde que estes não entrem em conflito com os interpretados pelo browser. Os

atributos podem ser facilmente acedidos ou modificados pelo Javascript, tal como

78

qualqueroutroatributodanormaHTML,oquetornaestemétodoaopçãoidealpara

oarmazenamentodeinformação.

4.4.4ProcessamentodoWorkflowdoladodoCliente

Estando ultrapassadas as dificuldades levantadas pela Same Origin Policy e

pelanormalizaçãodosmódulosdeprocessamento,opassoseguintepassouportratar

oprocessamentoencadeadodestes.

O primeiro requisito a verificar é a consistência doWorkflow: é necessário

garantir que as entradas de cada adaptador são compatíveis com as saídas do

adaptador anterior. Para a prevenção deste erro de consistência, os módulos de

processamento que não poderem ser adicionados ao último módulo de

processamentodoworkflowsãodiferenciadosvisualmentedosrestanteseaopçãode

adiçãoaoWorkflowatravésdocliquepassaaestarindisponível.Casooutilizadoruse

o método de drag­n­drop para adicionar o adaptador ao workflow e este fique

inconsistente,aaplicaçãoinformaoerrodevidamente.

Deseguidaénecessáriocarregaremmemóriatodaainformaçãowrappersea

ordemporqueserãoexecutados.

AtravésdométododeOnDemandJavascriptdescritoanteriormenteéfeitoo

primeiropedido.OpedidoéconstruídodeacordocomoespecificadonoficheiroXML

dosmódulosdeprocessamento.Naresposta,acede‐seaoobjectodevolvidodeacordo

com a especificação do módulo de processamento contida no XML e é extraída a

informação necessária para construir o pedido seguinte. O processo repete‐se

iterativamenteatéestarcompletadoofluxodeinformação.

Outilizadoréinformadodotrajectodainformaçãoatravésdadisponibilização

dosdadosdesaídaobtidosemcadamódulo.

Ao terminar o fluxo de informação – temos a informação dada pelo último

elementodoWorkflow–outilizadorpodeiniciaroprocessodeanálisedainformação

através dos diversos métodos de visualização disponíveis. Estes métodos são

diferenciadosdeacordocomo tipodedadosaanalisar.Apesardavisualizaçãonão

fazer parte deste trabalho, é importante referir que os diversos métodos de

visualizaçãoencontram‐sedisponíveisdeacordocomotipodedadosavisualizareo

79

utilizador pode não só analisar os dados de saída finais,mas também os dados de

saídadecadamódulodeprocessamentoexecutadonoWorkflow.

4.5Sumário

Nestecapítulo foramapresentadasas soluçõesencontradasparasatisfazera

arquitectura planeada inicialmente e também alguns problemas encontrados ao

longododesenvolvimentodaaplicação.

Grande parte das escolhas feitas para componentes do sistema tiveram em

contaastecnologiasusadasnasrestantesaplicaçõesemdesenvolvimentopelogrupo,

isto de forma amelhorar a interligação para partilha de dados entre as aplicações

existenteseaindaemdesenvolvimento.Astecnologiasescolhidas,alémdeseremas

maisamplamenteusadaspelasaplicaçõesWeb2.0,sãotambémasquefornecemmais

garantiasdeescalabilidadeefuncionalidadefinaldaaplicação.

Os problemas encontrados no processo de desenvolvimento foram

proveitososparaverificarqueexistemsemprevariadassoluçõesequeaescolhafinal

nemsempreéfácileenvolveaanálisedediversosfactores.

A interface da aplicação prototipada, um dos principais objectos de estudo

desta dissertação, foi planeada criteriosamente para que, a aproximação de

integração de serviços através de fluxos de informação, resultasse e fosse o mais

usávelpossívelparaoutilizador.

Uma primeira versão experimental da aplicação encontra‐se disponível em

http://bioinformatics.ua.pt/geDynamicFlow.

80

81

5Conclusõesetrabalhofuturo

A evolução da Internet levou ao aparecimento de cada vezmais emelhores

aplicaçõesWeb. O fenómeno daWeb2.0 e as potencialidades por ele despoletadas,

tornaram possível a existência de aplicações Web tão boas ou melhores que as

tradicionaisaplicaçõesDesktop.Noentanto,aarquitecturadestasnovasaplicaçõesé

bastantemaiscomplexaqueassuaspredecessoras.

O que se pretende apresentar nesta dissertação é uma proposta de

arquitectura (e respectivas escolhas tecnológicas) para integração de serviços que

tenhaemcontaascaracterísticasdaWeb2.0eosrequisitostrazidosporumanovae

ágilaproximaçãocomfluxosdeinformaçãocontroladospeloutilizador.

Odesenhodaarquitecturaeaconstruçãodaaplicação levaramaumestudo

aprofundado de aplicações Web2.0 existentes e, dentro destas, as que usam uma

aproximação com workflows semelhante à que se pretendia implementar. Levou

tambémaoestudodasmaisvariadastecnologias‐HTML,DOM,XML,Javascript,CSS,

XSL, Xpath, C#, ASP.NET,Web Services – e aplicações / frameworks de trabalho –

VisualStudio,ASP.NETAJAX,MicrosoftSQLServer,MicrosoftWindowsServer.

Apesar da aplicação criada para testar a arquitectura estar ligada à área da

bioinformática, omodelo proposto pretende abranger qualquer área de trabalho e

servirdebaseàconstruçãodenovasaplicaçõeseinterfaces.Destemodo,aintegração

em diferentes áreas de trabalho encontra‐se facilitada e o processo de

desenvolvimento de novas aplicações sobre a arquitectura criada não deve ser

moroso.

O futurodaarquitecturaestádependentedoestudodeáreasondepossaser

inseridaeutilizadacomsucesso.Áreascomoamedicinaouafarmacologiapartilham

característicascomabioinformática,oquepossibilitaacriaçãodenovasaplicações

idênticasaoDynamicFlow.

Dentrodocontextodabioinformática,aaplicaçãoDynamicFlownecessitade

algumtrabalhoatéquepossaserconsideradacomofinalizada.Énecessáriopesquisar

eestudarmaisfontesdedadoseserviçosquepossamserusadoscomoadaptadores

82

naaplicação; istoparaqueonúmerodeproblemasresolvidospelaaplicaçãocresça

(de acordo com o crescimento dos adaptadores disponíveis). É tambémnecessário

promover a divulgação da aplicação junto dos utilizadores, para que possam ser

conhecidasquaisasfuncionalidadesgostariamdeverimplementadasnaaplicaçãoe

que soluções seriammais úteis para resolver possíveis problemas. Posteriormente,

restamelhorarainterface:nãoaníveldeformasdeinteracçãocomoutilizador,mas

aoníveldeaparênciadaspáginas.

Numquadromaisglobal,aintegraçãodaaplicaçãoDynamicFlownumpacote

de aplicações de análise de expressão genética, fomentaria o desenvolvimento de

diversas funcionalidades relacionadas com a partilha de informação entre

utilizadoreseentreaplicações,aproximandomaisaaplicaçãodoconceitoWeb2.0.

83

6Referências

1. Bertino,E.andE.Ferrari,XMLandDataIntegration.IEEEInternetComputing,

2001(November‐December2001):p.2.

2. Dias,G.,etal.IntegrationofGeneticandMedicalInformationThroughaWeb

CrawlerSystem.inBiologicalandMedicalDataAnalysis(ISBMDA'2005).2005.

Aveiro,Portugal.

3. Arrais,J.,etal.,GeneBrowser:anapproachforintegrationandfunctional

classificationofgenomicdata.JournalofIntegrativeBioinformatics,2007.

4. Whalin,D.andM.Gibss,ProfessionalASP.NET2.0AJAX.2007:Wrox.336.

5. O'Reilly,T.WhatIsWeb2.0:DesignPatternsandBusinessModelsfortheNext

GenerationofSoftware.2005[citadoem200831‐05].

6. ECMA.StandardECMA­357.2008[citadoem200831‐05];Disponívelem:

http://www.ecma‐international.org/publications/standards/Ecma‐357.htm.

7. W3C,W.W.W.C.W3CDocumentObjectModel.2008[citadoem200831‐05];

Disponívelem:http://www.w3.org/DOM.

8. W3C,W.W.W.C.ExtensibleMarkupLanguage(XML).200822‐05‐2008[citado

em200831‐05];Disponívelem:http://www.w3.org/XML.

9. W3C,W.W.W.C.ExtensibleStylesheetLanguage(XSL).2008[citadoem2008

31‐05];Disponívelem:http://www.w3.org/TR/xsl.

10. W3C,W.W.W.C.XMLPathLanguage(XPath).2008[citadoem200831‐05];

Disponívelem:http://www.w3.org/TR/xpath.

11. JSON.JSON.2008[citadoem200831‐05];Disponívelem:

http://www.json.org/json‐pt.html.

12. Rubio,D.AnIntroductiontoJSON.2007[citadoem200831‐05];Disponível

em:http://dev2dev.bea.com/pub/a/2007/02/introduction‐json.html.

13. W3C,W.W.W.C.WebServices@W3C.2008[citadoem200831‐05];

Disponívelem:http://www.w3.org/2002/ws.

84

14. W3C,W.W.W.C.SOAPSpecifications.2008[citadoem200831‐05];Disponível

em:http://www.w3.org/TR/soap.

15. W3C,W.W.W.C.WebServiceDefinitionLanguage(WSDL).2008[citadoem

200831‐05];Disponívelem:http://www.w3.org/TR/wsdl.

16. OASIS.UDDIVersion3.0.2.2008[citadoem200831‐05];Disponívelem:

http://www.uddi.org/pubs/uddi_v3.htm.

17. ECMA.StandarECMA­334.2006[citadoem200831‐05];Disponívelem:

http://www.ecma‐international.org/publications/standards/Ecma‐334.htm.

18. W3C,W.W.W.C.CascadingStyleSheets.2008[citadoem200831‐05];

Disponívelem:http://www.w3.org/Style/CSS.

19. PostgreSQL.PostegreSQL:Theworld'smostadvancedopensourcedatabase.

2008[citadoem200831‐05];Disponívelem:http://www.postgresql.org.

20. Apache,T.A.S.F.TheApacheSofttwareFoundation.2008[citadoem200831‐

05];Disponívelem:http://www.apache.org.

21. Sun,S.m.MySQL::Theworld'smostpopularopensourcedatabase.2008

[citadoem200831‐05];Disponívelem:http://www.mysql.com.

22. PHP.PHP:HypertextPreprocessor.2008[citadoem200831‐05];Disponível

em:http://www.php.net.

23. Carayatech.GeoDNS:BINDpatchtoaddgeographicalfilterstoviews.2008

[citadoem200831‐05];Disponívelem:http://www.caraytech.com/geodns.

24. Apache,T.A.S.F.ApacheLucene.2008[citadoem200831‐05];Disponívelem:

http://lucene.apache.org/java/docs/index.html.

25. Lighttpd.lighttpdflyflight.2008[citadoem200831‐05];Disponívelem:

http://www.lighttpd.net.

26. W3C,W.W.W.C.RSS2.0specification.2008[citadoem200831‐05];

Disponívelem:http://validator.w3.org/feed/docs/rss2.html.

27. IETF.RFC4287­TheAtomSyndicationFormat.2008[cited;Disponívelem:

http://tools.ietf.org/html/rfc4287.

28. Python.PythonProgrammingLanguage.2008[citadoem200831‐05];

Disponívelem:http://www.python.org.

29. Psyco.Psyco.200816‐01‐2008[citadoem200831‐05];Disponívelem:

http://psyco.sourceforge.net.

85

30. Hollingsworth,D.,TheWorkflowReferenceModel,W.M.Coalition,Editor.1995.

31. Gordon,P.M.andSensen,Seahawk:movingbeyondHTMLinWeb­based

bioinformaticsanalysis.BMCBioinformatics,2007.

32. Microsoft.MicrosoftPopfly.2008[citadoem200831‐05];Disponívelem:

http://www.popfly.com.

33. Yahoo!Pipes:Rewiretheweb.2008[citadoem200831‐05];Disponívelem:

http://pipes.yahoo.com/pipes.

34. Romano,P.,D.Marra,andL.Milanesi,Webservicesandworkflowmanagement

forbiologicalresources.BMCBioinformatics,2005.

35. Stein,L.D.,IntegratingBiologicalDatabases.NatureReviews‐Genetics,2003.

4(Maio2003):p.337‐345.

36. Microsoft.WindowsServer2008.2008[citadoem200831‐05];Disponível

em:http://www.microsoft.com/windowsserver2008/en/us/default.aspx.

37. Microsoft.TheOfficialMicrosoftASP.NETSite.2008[citadoem200831‐05];

Disponívelem:http://www.asp.net.

38. ORACLE.Oracle11g,Siebel,PeopleSoft|Oracle,ThwWorld'sLargestEnterprise

SoftwareCompany.2008[citadoem200831‐05];Disponívelem:

http://www.oracle.com/index.html.

39. Microsoft.MicrosoftSQLServer2005Home.2008[citadoem200831‐03];

Disponívelem:http://www.microsoft.com/SQL/default.mspx.

40. Microsoft..NETFrameworkDeveloperCenter.2008[citadoem200831‐05];

Disponívelem:http://msdn.microsoft.com/en‐

us/netframework/default.aspx.

41. Adobe.AdobeFlash.2008[citadoem200831‐05];Disponívelem:

http://www.adobe.com/products/flashplayer.

42. Microsoft.Silverlight.2008[citadoem200831‐05];Disponívelem:

http://silverlight.net.

43. W3C,W.W.W.C.WebAccessibilityInitiative(WAI).2006[citadoem200831‐

05];Disponívelem:http://www.w3.org/WAI.

44. W3C,W.W.W.C.WAIGuidelinesandTechniques.2006[citadoem200831‐05];

Disponívelem:http://www.w3.org/WAI/guid‐tech.html.

86

45. Holz,T.,S.Marechal,andF.Raynal,NewThreatsandAttacksontheWorldWide

Web.IEEESecurity&Privacy,2006:p.72‐75.

46. Yahoo!UseaWebProxyforCross­DomainXMLHttpRequestCalls.2008[citado

em200831‐05];Disponívelem:

http://developer.yahoo.com/javascript/howto‐proxy.html.

47. Mahemoff,M.,On­DemandJavaScript,inAjaxDesignPatterns.2006,O'Reilly.