Conforme dito anteriormente, nos ambientes cient´ıficos os dados intermedi´arios tˆem grande importˆancia e n˜ao devem ser descartados. Destaca-se ainda a importˆancia da proveniˆencia de dados, onde deve-se armazenar - al´em dos dados - as informa¸c˜oes de como os dados foram obtidos. Com o advento dos servi¸cos Web, tornou-se poss´ıvel utilizar programas cient´ıficos distribu´ıdos pela internet que, via compartilhamento de recursos
computacionais, permitiu maior colabora¸c˜ao entre os centros de pesquisa. Por´em, nesse cen´ario de distribui¸c˜ao de processamento, surge a quest˜ao: como gerenciar adequadamente o grande volume de dados intermedi´arios e finais produzidos pelas execu¸c˜oes dos Workflows? A literatura de banco de dados prop˜oe dois paradigmas para armazenamento de dados: centralizado e distribu´ıdo. Paradigmas estes que ser˜ao detalhados nas se¸c˜oes a seguir.
2.4.1 ARMAZENAMENTO CENTRALIZADO
No paradigma de armazenamento centralizado de dados, os dados produzidos durante a execu¸c˜ao dos workflows s˜ao armazenados num ´unico reposit´orio do ambiente. Esse reposit´orio pode estar hospedado no gerente de execu¸c˜ao, ou em qualquer servidor da arquitetura que possua grande capacidade de armazenamento. Desta forma, o dado produzido por cada tarefa de um workflow em execu¸c˜ao ´e enviado para o reposit´orio central, e deste para a tarefa subseq¨uente para dar continuidade `a execu¸c˜ao. A figura 2.2 ilustra o esquema de funcionamento centralizado.
FIG. 2.2: Esquema de armazenamento centralizado
Devido ao seu modo de funcionamento, o processo de armazenamento e recupera¸c˜ao dos dados gerados por cada tarefa, em m´ultiplas execu¸c˜oes de diversos workflows, pode apresentar baixo desempenho, prejudicando as execu¸c˜oes dos workflows. Num ambiente de workflows cient´ıficos, em que tipicamente os s´ıtios de processamento est˜ao dispersos geograficamente, a infra-estrutura de rede torna-se um ponto impactante na execu¸c˜ao do workflow, visto que os s´ıtios de processamento podem estar localizados em locais de acesso dificultado por parte do s´ıtio central de armazenamento.
FIG. 2.3: Armazenamento no s´ıtio produtor
2.4.2 ARMAZENAMENTO DISTRIBU´IDO
No paradigma de armazenamento distribu´ıdo de dados, v´arios reposit´orios de dados encontram-se dispon´ıveis no ambiente. Os dados produzidos pelas tarefas dos workflows que est˜ao em execu¸c˜ao podem ser armazenados em qualquer um dos reposit´orios de dados dispon´ıveis.
Considere uma instˆancia w’ de um workflow w composto por i tarefas t1, t2, ..., ti.
Considere um conjunto de n s´ıtios de processamento, onde ti,j significa que a tarefa
i est´a hospedada no s´ıtio j. Suponha que ti,p e ti+1,r, p 6= r represente um par de
tarefas subseq¨uentes em w’, hospedadas nos s´ıtios p e r, respectivamente. Suponha que o dado d produzido por ti,p seja consumido por ti+1,r. Considere que todos os s´ıtios de
processamento possuam reposit´orios de dados. Neste cen´ario, uma poss´ıvel estrat´egia de armazenamento seria persistir d sempre no s´ıtio de ti, neste caso o s´ıtio p, no intuito
de armazen´a-lo junto ao s´ıtio produtor, como ilustra a figura 2.3; outra estrat´egia seria sempre armazenar d no s´ıtio de ti+1, neste caso o s´ıtio r, buscando armazen´a-lo junto
ao processo consumidor, ilustrado na figura 2.4. Pode-se pensar ainda em armazenar d em um outro s´ıtio de armazenamento qualquer do ambiente, ilustrado na figura 2.5. No entanto, esta decis˜ao n˜ao ´e t˜ao simples, considerando que deve ser tomada para cada dado intermedi´ario produzido durante a execu¸c˜ao do workflow, e levando-se em conta restri¸c˜oes do ambiente que devem ser observadas, como limita¸c˜ao no espa¸co de armazenamento, pol´ıticas de administra¸c˜ao do s´ıtio remoto, autoriza¸c˜ao de acesso entre os s´ıtios, dentre outras.
Armazenar o dado intermedi´ario sempre no s´ıtio onde o mesmo foi produzido, ou consumido, pode n˜ao ser uma boa estrat´egia de armazenamento distribu´ıdo em todos os casos, visto que a comunica¸c˜ao entre os s´ıtios produtor e consumidor pode ser deficiente, causando lentid˜ao no armazenamento e transmiss˜ao de dados. Pode-se analisar
FIG. 2.4: Armazenamento no s´ıtio consumidor
FIG. 2.5: Armazenamento num s´ıtio qualquer do ambiente
ainda o aspecto de aproveitamento de dados produzidos por execu¸c˜oes anteriores de um workflow. Desta forma, o dado produzido por uma instˆancia w’ do workflow w poderia ser aproveitado em outra instˆancia w”. Sob esse prisma, deve-se escolher um reposit´orio de dados levando em conta a poss´ıvel utiliza¸c˜ao futura do mesmo.
O problema de armazenamento distribu´ıdo de dados ´e estudado, h´a bastante tempo, na ´area de sistemas de banco de dados distribu´ıdos. T´ecnicas de distribui¸c˜ao tˆem sido empregadas com sucesso no incremento de desempenho de aplica¸c˜oes que manipulam grandes volumes de dados. No cen´ario de workflows distribu´ıdos, as t´ecnicas de distribui¸c˜ao de dados possibilitam adequar o armazenamento dos dados intermedi´arios de acordo com a necessidade de processamento dos mesmos pelas instˆancias de tarefas durante a execu¸c˜ao de workflows cient´ıficos. Entretanto, o dom´ınio dos workflows acrescenta novos complicadores n˜ao tratados adequadamente por bancos de dados distribu´ıdos, como o encadeamento de execu¸c˜oes e a interdependˆencia de dados e tarefas. No dom´ınio de workflows - conforme j´a apresentado - as tarefas possuem regras de encadeamento, onde uma tarefa precisa do dado produzido pela sua antecessora para poder executar, esse aspecto ´e conhecido como interdependˆencia de dados e tarefas. Mas o dado produzido por uma tarefa pode tamb´em ser utilizado por diversas outras tarefas. Assim, um projeto de distribui¸c˜ao de dados intermedi´arios de workflows deve considerar
o aspecto de tarefas prov´aveis consumidoras. Como no paradigma de armazenamento distribu´ıdo os dados encontram-se dispersos nos v´arios reposit´orios do ambiente, h´a a necessidade de um mecanismo eficiente para identificar os dados no ambiente distribu´ıdo como um todo, a fim de viabilizar o seu armazenamento e recupera¸c˜ao durante a execu¸c˜ao dos workflows. Um mecanismo que tem sido adotado por sistemas cient´ıficos ´e o LSID (CLARK, 2004), que ser´a detalhado na subse¸c˜ao a seguir.
2.4.3 LSID
O LSID (Life Science Identifier) ´e um mecanismo de identifica¸c˜ao de dados baseado em URNs (Universal Resource Names) que faz parte da OMG (Object Management Group) desde 2004. A estrutura de um LSID ´e demonstrada a seguir:
< LSID >::=0 urn : lsid :0< AuthorityID >0:0< AuthorityN amespaceID >0:0< ObjectID > [0:0< RevisionID >]
Alguns exemplos de LSID s˜ao demonstrados a seguir: • URN:LSID:rcsb.org:PDB:1D4X:22
• urn:lsid:kepler-project.org:director:1:1
Observa-se que no formato do LSID, o AuthorityID ´e constitu´ıdo pelo dom´ınio do propriet´ario da informa¸c˜ao na internet. Esse mecanismo ´e utilizado para localiza¸c˜ao e recupera¸c˜ao da informa¸c˜ao. AuthorityNamespaceID destina-se a informa¸c˜oes complementares do propriet´ario do dado, no caso de URN:LSID:rcsb.org:PDB:1D4X:22 o AuthorityNamespaceID PDB refere-se ao nome do banco de dados. O ObjectID ´e um identificador para o dado, o RevisionID - parte opcional - ´e um identificador de versionamento da informa¸c˜ao.