I. BÖLÜM
5. Alt Problem: Balanced Scorecard uygulaması ile gerçekleştirilen performans
No sistema de uxo de trabalho ientí o proposto, os uxos de trabalho dos
usuáriossãodes ritos omografosdire ionados,mapeadosparapipelinesdoAnthill,
tal omo do Anthill, o usuário pode des rever quais são os seus ltros e omo eles
omuni amum om o outro.
Basi amente o sistema é omposto de três omponentes: o Gerente de Metada-
dos dos Fluxos de Trabalho (GMFT), o Gerente de Armazenamento de Dados em
Memória(GADM) eo Gerente de Armazenamento Persistente (GAP). O GMFT é
responsável por monitorar e geren iar os dados re ebidos e riados pelos uxos de
trabalho dos usuários. O GADM armazena em memória tanto dados de entrada e
saída quantointermediários. E, por m, oGAP provêum armazenamentoe geren-
iamentodos dados persistentes.
Antes de exe utar o uxo de trabalho, o usuário deve armazenar sua base de
dadosini ial noGAP, omobases de dados XML,utilizandouma API (Appli ation
Programming Interfa e) provida. A base de dados ini ial é onsiderada omo uma
oleçãodedo umentos, omaqualousuáriopodeasso iardes riçõesde metadados.
Esses do umentos serão distribuídos nos vários nodos de armazenamento rodando
servidoresGAP.Porexemplo,todasasimagensqueserãopro essadaspelaapli ação
biomédi a de análise de imagens serão armazenadas em um ban o de dados XML
distribuído em diferentes nodos, e metadados omo nome, tamanhoe dimensão da
imagem,podem ser asso iados a ada uma delas.
Umaabstraçãoparaleituradedados,desenvolvidaemoutrotrabalho[TTF
+
06℄,
e baseada em onsultas (queries)à base de dados ini ial, retornado umentospara
as instân ias do primeiro ltro no pipeline assim que eles estiverem prontos para
pro essar dados. Desta forma, os usuários que desenvolvem apli ações para serem
exe utadas pelo sistema não se preo upam om a leitura de dados. As apli ações
devem ser desenvolvidas de talformaqueo primeiro ltro dopipelineleiadados de
umstream deentradaassim omoosdemais ltros,eosistemaéque aresponsável
por retornar do umentos do GAP paraele.
Todos os dados de entrada e saída, assim omo as mensagens intermediárias
tro adasnopipelinesãode nidosporesquemasXML,esão hamadosnestetrabalho
dedo umentos. Autilizaçãodonomedo umentoemvez de mensagem foidevidoao
tamanhoqueeles podemal ançar, podendoser daordemde entenas demegabytes,
por exemplo. Os do umentos intermediários são armazenados nos servidores GAP
para serem disponibilizadospara inspeção oupara servirem omo entrada para ou-
tros uxos de trabalho. Esse armazenamento é realizado durante a omuni ação
entreos ltrosdopipeline,e adaum dostrêsgerentespossuitarefasespe í asque
serão des ritas nas próximas três seções..
Utilizar as próprias ara terísti as (fun ionalidades) dos sistemas de uxo de
disponíveis é uma ótima idéia. Elas introduzem menos overhead e, se forem aper-
feiçoadas, podem melhorar o desempenho das próprias fun ionalidades desses sis-
temas. Em parti ular,os dadosintermediáriosdaexe ução dos uxos serão utiliza-
dos omobase parare uperar osistemadepoisde uma falha. Para essa razão éque
foi riado o Gerente de Armazenamentode Dadosem Memória (GADM). Eleatua
omo um repositório de dados em memória,o qualprovê osdados ne essários para
os uxos de trabalho e também uida do armazenamento dos dados intermediários
e de saída na memória primária. Uma das suas ara terísti as mais importantes é
queele não introduz nenhum sin ronizaçãoentre aexe ução dos uxos de trabalho
e o pro esso de armazenamento de dados intermediários. Em outras palavras, os
uxos de trabalho podem exe utar, não havendo ne essidade de parar durante o
armazenamentodos dados.
A gura 4.1 mostra a arquitetura do sistema om os seus três omponentes
prin ipais. A seguir,as fu ionalidadesde ada um deles, assim omo osseus papéis
no me anismo para aumentar a disponibilidade do sistema, serão apresentados em
mais detalhes.
Figura 4.1: Organização dos Componentes do Sistema de Fluxo de Trabalho Cien-
tí o.
4.2.1 Gerente de Metadados do Fluxos de Trabalho
(GMFT)
Esse omponenteédesenvolvido omoum ltroAnthilleéresponsávelpelomoni-
toramentoegeren iamentodos do umentos re ebidose riados,sob demanda,pelos
úni oe tambémsabeondeele estáarmazenado, qualinstân iade ltroo pro essou
ou riou. Ele provê um proto olo para, basi amente, a essar, riar e atualizar os
metadados durantea exe ução.
Para aumentar adisponibilidade do sistema, dois outros metadados são ontro-
ladosporesse omponente. Oprimeiroéadependên iade dados (des rita naseção
2.1.1). Ele se mantém informado de todas asdependên ias entre osdo umentosdo
sistema. Osegundo éoestadodosdo umentos. Osdo umentos,duranteaexe ução
dos uxos de trabalho, podemassumir três estados diferentes:
•
Não Pro essado: Todo do umento na base de dados ini ial é onsiderado não pro essado noini iodaexe uçãodo uxo de trabalho. Issosigni aqueeles estão disponíveispara serem pro essados.
•
Pro essando: Odo umentoestánoestadopro essandoquandoum ltrono uxode trabalhoopegaparapro essar. Todososdo umentos riadosdurantea exe ução dos ltros dos uxos de trabalho são onsiderados pro essando,
uma vez que eles foram riados eenviados para outro ltro para pro essar.
•
Pro essado: Um do umento é onsiderado pro essado quando o sistema re onhe er quenão haverá ne essidade de repro essá-lona o orrên ia de umafalha. Para queesse re onhe imentosejafeito,osistema ontrola dependên ia
entre os do umentos.
Comofoides ritoem[TTF
+
06℄,quandoum uxodetrabalho omeçaaexe utar,
oGMFTde idequaisdo umentosserãoenviadosparaasinstân iasdeseus ltros. O
es alonamentoérealizadosob demandaetrabalhadeformamestre-es ravo: sempre
que os es ravos (instân ias dos ltros do uxo) estão disponíveis para pro essar,
eles pedem por do umentos para o mestre (o sistema, em parti ular o Gerente de
MetadadosdosFluxosdeTrabalho)quevaide idirquaisdo umentosserãoenviados.
Essa de isão é baseada em quais do umentos estão disponíveis para pro essar, e
ondeseráopro essamento. Se,porexemplo,existirumGerentede Armazenamento
Persistente rodando no mesmo nodo que uma instân ia do ltro, um do umento
não pro essado armazenadonesse nodo será es olhido.
4.2.2 Gerente de Armazenamento de Dados em Memória
(GADM)
Esse omponenteé desenvolvido omo um ltro Anthille trabalha omo um elo
(GAP). Ele basi amente provê alguns me anismos para ler/es rever do umentos
do/parao GAP.
Esse omponente, na ini ialização do sistema, é instan iado em vários nodos
do ambiente distribuído. Cada uma de suas instân ias possui seu próprio limite
de espaço de memória, o qual signi a a quantidade máxima de memória que eles
podem utilizar para armazenar os do umentos. Quando o uxo de trabalho do
usuárioéini iado,asinstân iasde seus ltrossão ligadas àsinstân ias doGADM,
utilizandootipode omuni açãolabeledstream doAnthill. Essaligaçãoéfeitadetal
formaqueuma instân iado GADM a responsávelporum onjuntode instân ias
dos ltros do usuário. Por exemplo: ela a responsável pelas instân ias que estão
sendo exe utadas nomesmo nodoque ela.
Naexe ução dos uxos de trabalho,quando umainstân iade um ltro requisita
um do umentopara pro essar, essa requisiçãoé enviada à instân ia do Gerente de
ArmazenamentodeDadosemMemória(GADM)aqualestá responsávelporaquela
instân ia. Parasaberqualdo umentodeveserlido,oGADMperguntaaoGerentede
Metadados dosFluxos de Trabalho(GMFT).Baseadanos metadadosprovidospelo
GMFT,elerealizaaleituranoGerentedeArmazenamentoPersistentedodo umento
ne essário,armazena-oemmemória,eenvia-oparaainstân iado ltrodaapli ação.
Esse omponente também armazena tanto os do umentos intermediários enviados
atravésdosstreams do uxo detrabalhoquantoosdesaída. Éinteressanteobservar
que as instân ias do GADM também foram ligadas a instân ias do GMFT de tal
formaque uma instân iado GMFT a responsável porum onjunto de instân ias
doGADM.
Todos osdo umentos armazenadosnesse omponentepossuemum identi ador
úni o riado pelo Gerente de Metadados dos Fluxos de Trabalho. Então, sempre
que eles forem removidos ou tiverem suas informações atualizadas, isso é realizado
baseado nesse identi ador. Quando não há mais espaço para armazenar os do u-
mentosemuma instân iadoGADM, ela omeça a enviaresses do umentos para o
GerentedeArmazenamentoPersistenteearemovê-los,utilizandoumapolíti aFIFO
(FirstInFirstOut). Tantoparaosdo umentosdesaídaquantoparaosdo umentos
intermediários no pipeline, ele é responsável por riar uma base de dados XML no
Gerente de Armazenamento Persistente que vai armazenaresses do umentos.
4.2.3 Gerente de Armazenamento Persistente (GAP)
OGerentedeArmazenamentoPersistenteé onstruídosobreoMobius,emparti-
de armazenamentos distribuídos existentes. Ele ontrola múltiplas bases de dados
distribuídas em múltiplos nodos.
Esse omponente é utilizado para armazenar tanto os do umentos de entrada
e saída quanto os do umentos intermediários dos uxos de trabalho nos vários no-
dos. Esses do umentos são armazenadosembases de dados distribuídas ede nidos
através de esquemas XML. Quando as instân ias dos ltros dos uxos de trabalho
riamumdo umentoeoenviaatravésdosstreams,esse do umentoéprimeiramente
enviado para o Gerente de Armazenamento de Dados em Memória que realiza os
uidadosne essáriosparaarmazenaressedo umentonoGerentedeArmazenamento
Persistente. Basesde dadosdistribuídassão riadassobdemanda nesse omponente
para armazenar os estados intermediários. Uma base é riada para ada stream de
saída.
O Mobius disponibiliza uma interfa e grá a na qual as informações dos do u-
mentosarmazenadosnas basesde dados podem ser vistas. Umadessas informações
é onde o do umento está armazenado. Dessa forma, quando os usuários desejam
fazer a inspeção dos do umentos intermediários, eles veri am essa informação e
abrem osdo umentos para seremexaminados.