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:EXEMPLODEUMCALLOUTNAAPLICAÇÃ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
apresentaa 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ípicasjanelaspopupouaidentificaçã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 tornarse 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,semiestruturados
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 parttime – 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 webbased 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é5Mbdo
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ãousadoscallouts: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 callout 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 callout, o utilizador regressa à página onde se
encontravapreviamente,comamesmatransiçãosuavedeaparecimentodocallout.
62
Figura27:Exemplodeumcalloutnaaplicaçã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
dragndrop.
A operação de dragndrop 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çãodedragn
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 dragndrop 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.StandardECMA357.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,[email protected][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.StandarECMA334.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.RFC4287TheAtomSyndicationFormat.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:movingbeyondHTMLinWebbased
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!UseaWebProxyforCrossDomainXMLHttpRequestCalls.2008[citado
em200831‐05];Disponívelem:
http://developer.yahoo.com/javascript/howto‐proxy.html.
47. Mahemoff,M.,OnDemandJavaScript,inAjaxDesignPatterns.2006,O'Reilly.