On the Support of Scientific Workflows over Pub/Sub Brokers
Identifieur interne : 000573 ( Pmc/Corpus ); précédent : 000572; suivant : 000574On the Support of Scientific Workflows over Pub/Sub Brokers
Auteurs : Augusto Morales ; Tomas Robles ; Ramon Alcarria ; Edwin Cede OSource :
- Sensors (Basel, Switzerland) [ 1424-8220 ] ; 2013.
Abstract
The execution of scientific workflows is gaining importance as more computing resources are available in the form of grid environments. The Publish/Subscribe paradigm offers well-proven solutions for sustaining distributed scenarios while maintaining the high level of task decoupling required by scientific workflows. In this paper, we propose a new model for supporting scientific workflows that improves the dissemination of control events. The proposed solution is based on the mapping of workflow tasks to the underlying Pub/Sub event layer, and the definition of interfaces and procedures for execution on brokers. In this paper we also analyze the strengths and weaknesses of current solutions that are based on existing message exchange models for scientific workflows. Finally, we explain how our model improves the information dissemination, event filtering, task decoupling and the monitoring of scientific workflows.
Url:
DOI: 10.3390/s130810954
PubMed: 23966191
PubMed Central: 3812637
Links to Exploration step
PMC:3812637Le document en format XML
<record><TEI><teiHeader><fileDesc><titleStmt><title xml:lang="en">On the Support of Scientific Workflows over Pub/Sub Brokers</title><author><name sortKey="Morales, Augusto" sort="Morales, Augusto" uniqKey="Morales A" first="Augusto" last="Morales">Augusto Morales</name></author><author><name sortKey="Robles, Tomas" sort="Robles, Tomas" uniqKey="Robles T" first="Tomas" last="Robles">Tomas Robles</name></author><author><name sortKey="Alcarria, Ramon" sort="Alcarria, Ramon" uniqKey="Alcarria R" first="Ramon" last="Alcarria">Ramon Alcarria</name></author><author><name sortKey="Cede O, Edwin" sort="Cede O, Edwin" uniqKey="Cede O E" first="Edwin" last="Cede O">Edwin Cede O</name></author></titleStmt><publicationStmt><idno type="wicri:source">PMC</idno><idno type="pmid">23966191</idno><idno type="pmc">3812637</idno><idno type="url">http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3812637</idno><idno type="RBID">PMC:3812637</idno><idno type="doi">10.3390/s130810954</idno><date when="2013">2013</date><idno type="wicri:Area/Pmc/Corpus">000573</idno><idno type="wicri:explorRef" wicri:stream="Pmc" wicri:step="Corpus" wicri:corpus="PMC">000573</idno></publicationStmt><sourceDesc><biblStruct><analytic><title xml:lang="en" level="a" type="main">On the Support of Scientific Workflows over Pub/Sub Brokers</title><author><name sortKey="Morales, Augusto" sort="Morales, Augusto" uniqKey="Morales A" first="Augusto" last="Morales">Augusto Morales</name></author><author><name sortKey="Robles, Tomas" sort="Robles, Tomas" uniqKey="Robles T" first="Tomas" last="Robles">Tomas Robles</name></author><author><name sortKey="Alcarria, Ramon" sort="Alcarria, Ramon" uniqKey="Alcarria R" first="Ramon" last="Alcarria">Ramon Alcarria</name></author><author><name sortKey="Cede O, Edwin" sort="Cede O, Edwin" uniqKey="Cede O E" first="Edwin" last="Cede O">Edwin Cede O</name></author></analytic><series><title level="j">Sensors (Basel, Switzerland)</title><idno type="eISSN">1424-8220</idno><imprint><date when="2013">2013</date></imprint></series></biblStruct></sourceDesc></fileDesc><profileDesc><textClass></textClass></profileDesc></teiHeader><front><div type="abstract" xml:lang="en"><p>The execution of scientific workflows is gaining importance as more computing resources are available in the form of grid environments. The Publish/Subscribe paradigm offers well-proven solutions for sustaining distributed scenarios while maintaining the high level of task decoupling required by scientific workflows. In this paper, we propose a new model for supporting scientific workflows that improves the dissemination of control events. The proposed solution is based on the mapping of workflow tasks to the underlying Pub/Sub event layer, and the definition of interfaces and procedures for execution on brokers. In this paper we also analyze the strengths and weaknesses of current solutions that are based on existing message exchange models for scientific workflows. Finally, we explain how our model improves the information dissemination, event filtering, task decoupling and the monitoring of scientific workflows.</p></div></front><back><div1 type="bibliography"><listBibl><biblStruct><analytic><author><name sortKey="Barker, A" uniqKey="Barker A">A. Barker</name></author><author><name sortKey="Van Hemert, J" uniqKey="Van Hemert J">J. Van Hemert</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Grefen, P" uniqKey="Grefen P">P. Grefen</name></author><author><name sortKey="De Vries, R" uniqKey="De Vries R">R. de Vries</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Lin, C" uniqKey="Lin C">C. Lin</name></author><author><name sortKey="Lu, S" uniqKey="Lu S">S. Lu</name></author><author><name sortKey="Fei, X" uniqKey="Fei X">X. Fei</name></author><author><name sortKey="Chebotko, A" uniqKey="Chebotko A">A. Chebotko</name></author><author><name sortKey="Pai, D" uniqKey="Pai D">D. Pai</name></author><author><name sortKey="Lai, Z" uniqKey="Lai Z">Z. Lai</name></author><author><name sortKey="Fotouhi, F" uniqKey="Fotouhi F">F. Fotouhi</name></author><author><name sortKey="Hua, J" uniqKey="Hua J">J. Hua</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Yildiz, U" uniqKey="Yildiz U">U. Yildiz</name></author><author><name sortKey="Guabtni, A" uniqKey="Guabtni A">A. Guabtni</name></author><author><name sortKey="Ngu, A" uniqKey="Ngu A">A. Ngu</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Liu, X" uniqKey="Liu X">X. Liu</name></author><author><name sortKey="Dou, W" uniqKey="Dou W">W. Dou</name></author><author><name sortKey="Fan, S" uniqKey="Fan S">S. Fan</name></author><author><name sortKey="Cai, S" uniqKey="Cai S">S. Cai</name></author></analytic></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct><analytic><author><name sortKey="Ludasher, B" uniqKey="Ludasher B">B. Ludasher</name></author><author><name sortKey="Altintas, I" uniqKey="Altintas I">I. Altintas</name></author><author><name sortKey="Berkley, C" uniqKey="Berkley C">C. Berkley</name></author><author><name sortKey="Higgins, D" uniqKey="Higgins D">D. Higgins</name></author><author><name sortKey="Jaeger, E" uniqKey="Jaeger E">E. Jaeger</name></author><author><name sortKey="Jones, M" uniqKey="Jones M">M. Jones</name></author><author><name sortKey="Lee, E" uniqKey="Lee E">E. Lee</name></author><author><name sortKey="Tao, J" uniqKey="Tao J">J. Tao</name></author><author><name sortKey="Zhao, Z" uniqKey="Zhao Z">Z. Zhao</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Balis, B" uniqKey="Balis B">B. Balis</name></author><author><name sortKey="Bubak, M" uniqKey="Bubak M">M. Bubak</name></author></analytic></biblStruct><biblStruct></biblStruct><biblStruct><analytic><author><name sortKey="Deelman, E" uniqKey="Deelman E">E. Deelman</name></author><author><name sortKey="Blythe, J" uniqKey="Blythe J">J. Blythe</name></author><author><name sortKey="Gil, Y" uniqKey="Gil Y">Y. Gil</name></author><author><name sortKey="Kesselman, C" uniqKey="Kesselman C">C. Kesselman</name></author><author><name sortKey="Mehta, G" uniqKey="Mehta G">G. Mehta</name></author><author><name sortKey="Patil, S" uniqKey="Patil S">S. Patil</name></author><author><name sortKey="Su, M H" uniqKey="Su M">M.-H. Su</name></author><author><name sortKey="Vahi, K" uniqKey="Vahi K">K. Vahi</name></author><author><name sortKey="Livny, M" uniqKey="Livny M">M. Livny</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Missier, P" uniqKey="Missier P">P. Missier</name></author><author><name sortKey="Soiland Reyes, S" uniqKey="Soiland Reyes S">S. Soiland-Reyes</name></author><author><name sortKey="Owen, S" uniqKey="Owen S">S. Owen</name></author><author><name sortKey="Tan, W" uniqKey="Tan W">W. Tan</name></author><author><name sortKey="Nenadic, A" uniqKey="Nenadic A">A. Nenadic</name></author><author><name sortKey="Dunlop, I" uniqKey="Dunlop I">I. Dunlop</name></author><author><name sortKey="Williams, A" uniqKey="Williams A">A. Williams</name></author><author><name sortKey="Oinn, T" uniqKey="Oinn T">T. Oinn</name></author><author><name sortKey="Goble, C" uniqKey="Goble C">C. Goble</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Bethel, E W" uniqKey="Bethel E">E.W. Bethel</name></author><author><name sortKey="Shalf, J" uniqKey="Shalf J">J. Shalf</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Johnson, D" uniqKey="Johnson D">D. Johnson</name></author><author><name sortKey="Meacham, K" uniqKey="Meacham K">K. Meacham</name></author><author><name sortKey="Kornmayer, H" uniqKey="Kornmayer H">H. Kornmayer</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Li, G" uniqKey="Li G">G. Li</name></author><author><name sortKey="Muthusamy, V" uniqKey="Muthusamy V">V. Muthusamy</name></author><author><name sortKey="Jacobsen, H A" uniqKey="Jacobsen H">H.-A. Jacobsen</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Yu, J" uniqKey="Yu J">J. Yu</name></author><author><name sortKey="Buyya, R" uniqKey="Buyya R">R. Buyya</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Fleuren, T" uniqKey="Fleuren T">T. Fleuren</name></author><author><name sortKey="Gotze, J" uniqKey="Gotze J">J. Gotze</name></author><author><name sortKey="Muller, P" uniqKey="Muller P">P. Muller</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Van Der Aalst, W" uniqKey="Van Der Aalst W">W. Van Der Aalst</name></author><author><name sortKey="Ter Hofstede, A" uniqKey="Ter Hofstede A">A. Ter Hofstede</name></author><author><name sortKey="Kiepuszewski, B" uniqKey="Kiepuszewski B">B. Kiepuszewski</name></author><author><name sortKey="Barros, A" uniqKey="Barros A">A. Barros</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Alcarria, R" uniqKey="Alcarria R">R. Alcarria</name></author><author><name sortKey="Robles, T" uniqKey="Robles T">T. Robles</name></author><author><name sortKey="Dominguez, A" uniqKey="Dominguez A">A. Dominguez</name></author><author><name sortKey="Cede O, E" uniqKey="Cede O E">E. Cedeño</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Morales, A" uniqKey="Morales A">A. Morales</name></author><author><name sortKey="Alcarria, R" uniqKey="Alcarria R">R. Alcarria</name></author><author><name sortKey="Robles, T" uniqKey="Robles T">T. Robles</name></author><author><name sortKey="Cede O, E" uniqKey="Cede O E">E. Cedeño</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Ranjan, R" uniqKey="Ranjan R">R. Ranjan</name></author><author><name sortKey="Rahman, M" uniqKey="Rahman M">M. Rahman</name></author><author><name sortKey="Buyya, R" uniqKey="Buyya R">R. Buyya</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Eugster, P" uniqKey="Eugster P">P. Eugster</name></author><author><name sortKey="Felber, P" uniqKey="Felber P">P. Felber</name></author><author><name sortKey="Guerraqui, R" uniqKey="Guerraqui R">R. Guerraqui</name></author><author><name sortKey="Kermarrec, A M" uniqKey="Kermarrec A">A.-M. Kermarrec</name></author></analytic></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct><analytic><author><name sortKey="Perez Castillo, R" uniqKey="Perez Castillo R">R. Pérez-Castillo</name></author><author><name sortKey="Weber, B" uniqKey="Weber B">B. Weber</name></author><author><name sortKey="Garcia Rodriguez De Guzman, I" uniqKey="Garcia Rodriguez De Guzman I">I. García-Rodríguez de Guzmán</name></author><author><name sortKey="Piattini, M" uniqKey="Piattini M">M. Piattini</name></author><author><name sortKey="Pinggera, J" uniqKey="Pinggera J">J. Pinggera</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Morales Dominguez, A" uniqKey="Morales Dominguez A">A. Morales Dominguez</name></author><author><name sortKey="Robles, T" uniqKey="Robles T">T. Robles</name></author><author><name sortKey="Alcarria, R" uniqKey="Alcarria R">R. Alcarria</name></author><author><name sortKey="Cede O, E" uniqKey="Cede O E">E. Cedeño</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Campos, F" uniqKey="Campos F">F. Campos</name></author><author><name sortKey="Pereira, J" uniqKey="Pereira J">J. Pereira</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Song, W" uniqKey="Song W">W. Song</name></author><author><name sortKey="Jiang, D" uniqKey="Jiang D">D. Jiang</name></author><author><name sortKey="Chi, C H" uniqKey="Chi C">C-H Chi</name></author><author><name sortKey="Jia, P" uniqKey="Jia P">P. Jia</name></author><author><name sortKey="Zhou, X" uniqKey="Zhou X">X. Zhou</name></author><author><name sortKey="Zou, G" uniqKey="Zou G">G. Zou</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Bradley, D" uniqKey="Bradley D">D. Bradley</name></author><author><name sortKey="Sfiligoi, I" uniqKey="Sfiligoi I">I. Sfiligoi</name></author><author><name sortKey="Padhi, S" uniqKey="Padhi S">S. Padhi</name></author><author><name sortKey="Frey, J" uniqKey="Frey J">J. Frey</name></author><author><name sortKey="Tannenbaum, T" uniqKey="Tannenbaum T">T. Tannenbaum</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Cao, J" uniqKey="Cao J">J. Cao</name></author><author><name sortKey="Javis, S A" uniqKey="Javis S">S.A. Javis</name></author><author><name sortKey="Saini, S" uniqKey="Saini S">S. Saini</name></author><author><name sortKey="Nudd, G" uniqKey="Nudd G">G. Nudd</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Perera, S" uniqKey="Perera S">S. Perera</name></author><author><name sortKey="Gannon, D" uniqKey="Gannon D">D. Gannon</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Ogasawara, E" uniqKey="Ogasawara E">E. Ogasawara</name></author><author><name sortKey="Dias, J" uniqKey="Dias J">J. Dias</name></author><author><name sortKey="Oliveira, D" uniqKey="Oliveira D">D. Oliveira</name></author><author><name sortKey="Rodrigues, C" uniqKey="Rodrigues C">C. Rodrigues</name></author><author><name sortKey="Pivotto, C" uniqKey="Pivotto C">C. Pivotto</name></author><author><name sortKey="Antas, R" uniqKey="Antas R">R. Antas</name></author><author><name sortKey="Braganholo, V" uniqKey="Braganholo V">V. Braganholo</name></author><author><name sortKey="Valduriez, P" uniqKey="Valduriez P">P. Valduriez</name></author><author><name sortKey="Mattoso, M" uniqKey="Mattoso M">M. Mattoso</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Hu, Y" uniqKey="Hu Y">Y. Hu</name></author><author><name sortKey="Bhuyan, L N" uniqKey="Bhuyan L">L.N. Bhuyan</name></author><author><name sortKey="Feng, M" uniqKey="Feng M">M. Feng</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Yang, Y" uniqKey="Yang Y">Y. Yang</name></author><author><name sortKey="Liu, K" uniqKey="Liu K">K. Liu</name></author><author><name sortKey="Chen, J" uniqKey="Chen J">J. Chen</name></author><author><name sortKey="Lignier, J" uniqKey="Lignier J">J. Lignier</name></author><author><name sortKey="Jin, H" uniqKey="Jin H">H. Jin</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Medjahed, B" uniqKey="Medjahed B">B. Medjahed</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Mann, H B" uniqKey="Mann H">H.B. Mann</name></author><author><name sortKey="Whitney, D R" uniqKey="Whitney D">D.R. Whitney</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Curcin, V" uniqKey="Curcin V">V. Curcin</name></author><author><name sortKey="Ghanem, M" uniqKey="Ghanem M">M. Ghanem</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Sun, S X" uniqKey="Sun S">S.X. Sun</name></author><author><name sortKey="Zeng, Q" uniqKey="Zeng Q">Q. Zeng</name></author><author><name sortKey="Wang, H" uniqKey="Wang H">H. Wang</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Tsai, Y" uniqKey="Tsai Y">Y. Tsai</name></author><author><name sortKey="Huang, K" uniqKey="Huang K">K. Huang</name></author><author><name sortKey="Chang, H" uniqKey="Chang H">H. Chang</name></author><author><name sortKey="Ko, J" uniqKey="Ko J">J. Ko</name></author><author><name sortKey="Wang, E" uniqKey="Wang E">E. Wang</name></author><author><name sortKey="Hsu, C" uniqKey="Hsu C">C. Hsu</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Wang, X" uniqKey="Wang X">X. Wang</name></author><author><name sortKey="Kuster, U" uniqKey="Kuster U">U. Kuster</name></author><author><name sortKey="Resch, M" uniqKey="Resch M">M. Resch</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Issarny, V" uniqKey="Issarny V">V. Issarny</name></author><author><name sortKey="Tartanoglu, F" uniqKey="Tartanoglu F">F. Tartanoglu</name></author><author><name sortKey="Romanovsky, A" uniqKey="Romanovsky A">A. Romanovsky</name></author><author><name sortKey="Levy, N" uniqKey="Levy N">N. Levy</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Bhiri, S" uniqKey="Bhiri S">S. Bhiri</name></author><author><name sortKey="Perrin, O" uniqKey="Perrin O">O. Perrin</name></author><author><name sortKey="Godart, C" uniqKey="Godart C">C. Godart</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Li, W" uniqKey="Li W">W. Li</name></author><author><name sortKey="Vuong, S" uniqKey="Vuong S">S. Vuong</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Li, G" uniqKey="Li G">G. Li</name></author><author><name sortKey="Muthusamy, V" uniqKey="Muthusamy V">V. Muthusamy</name></author><author><name sortKey="Jacobsen, H A" uniqKey="Jacobsen H">H.-A. Jacobsen</name></author><author><name sortKey="Mankovsky, S" uniqKey="Mankovsky S">S. Mankovsky</name></author></analytic></biblStruct><biblStruct><analytic><author><name sortKey="Alqaoud, A" uniqKey="Alqaoud A">A. Alqaoud</name></author><author><name sortKey="Taylor, I" uniqKey="Taylor I">I. Taylor</name></author><author><name sortKey="Jones, A" uniqKey="Jones A">A. Jones</name></author></analytic></biblStruct></listBibl></div1></back></TEI><pmc article-type="research-article"><pmc-dir>properties open_access</pmc-dir>
<front><journal-meta><journal-id journal-id-type="nlm-ta">Sensors (Basel)</journal-id><journal-id journal-id-type="iso-abbrev">Sensors (Basel)</journal-id><journal-title-group><journal-title>Sensors (Basel, Switzerland)</journal-title></journal-title-group><issn pub-type="epub">1424-8220</issn><publisher><publisher-name>Molecular Diversity Preservation International (MDPI)</publisher-name></publisher></journal-meta><article-meta><article-id pub-id-type="pmid">23966191</article-id><article-id pub-id-type="pmc">3812637</article-id><article-id pub-id-type="doi">10.3390/s130810954</article-id><article-id pub-id-type="publisher-id">sensors-13-10954</article-id><article-categories><subj-group subj-group-type="heading"><subject>Article</subject></subj-group></article-categories><title-group><article-title>On the Support of Scientific Workflows over Pub/Sub Brokers</article-title></title-group><contrib-group><contrib contrib-type="author"><name><surname>Morales</surname><given-names>Augusto</given-names></name><xref rid="c1-sensors-13-10954" ref-type="corresp"><sup>*</sup></xref></contrib><contrib contrib-type="author"><name><surname>Robles</surname><given-names>Tomas</given-names></name></contrib><contrib contrib-type="author"><name><surname>Alcarria</surname><given-names>Ramon</given-names></name></contrib><contrib contrib-type="author"><name><surname>Cedeño</surname><given-names>Edwin</given-names></name></contrib><aff id="af1-sensors-13-10954">Department of Telematics Engineering, Technical University of Madrid, Av. Complutense 30, Ciudad Universitaria, 28040 Madrid, Spain; E-Mails:<email>trobles@dit.upm.es</email> (T.R.);<email>ralcarria@dit.upm.es</email> (R.A.);<email>edwinc@dit.upm.es</email> (E.C.)</aff></contrib-group><author-notes><corresp id="c1-sensors-13-10954"><label>*</label>Author to whom correspondence should be addressed; E-Mail: <email>amorales@dit.upm.es</email>; Tel.: +34-915-495-700 (ext. 3035). Fax: +34-915-439-652.</corresp></author-notes><pub-date pub-type="collection"><month>8</month><year>2013</year></pub-date><pub-date pub-type="epub"><day>20</day><month>8</month><year>2013</year></pub-date><volume>13</volume><issue>8</issue><fpage>10954</fpage><lpage>10980</lpage><history><date date-type="received"><day>09</day><month>7</month><year>2013</year></date><date date-type="rev-recd"><day>07</day><month>8</month><year>2013</year></date><date date-type="accepted"><day>14</day><month>8</month><year>2013</year></date></history><permissions><copyright-statement>© 2013 by the authors; licensee MDPI, Basel, Switzerland.</copyright-statement><copyright-year>2013</copyright-year><license><license-p><pmc-comment>CREATIVE COMMONS</pmc-comment>This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (<ext-link ext-link-type="uri" xlink:href="http://creativecommons.org/licenses/by/3.0/">http://creativecommons.org/licenses/by/3.0/</ext-link>).</license-p></license></permissions><abstract><p>The execution of scientific workflows is gaining importance as more computing resources are available in the form of grid environments. The Publish/Subscribe paradigm offers well-proven solutions for sustaining distributed scenarios while maintaining the high level of task decoupling required by scientific workflows. In this paper, we propose a new model for supporting scientific workflows that improves the dissemination of control events. The proposed solution is based on the mapping of workflow tasks to the underlying Pub/Sub event layer, and the definition of interfaces and procedures for execution on brokers. In this paper we also analyze the strengths and weaknesses of current solutions that are based on existing message exchange models for scientific workflows. Finally, we explain how our model improves the information dissemination, event filtering, task decoupling and the monitoring of scientific workflows.</p></abstract><kwd-group><kwd>scientific workflow</kwd><kwd>publish/subscribe</kwd><kwd>distributed execution models</kwd><kwd>brokers</kwd><kwd>logic gates</kwd><kwd>workflow patterns</kwd></kwd-group></article-meta></front><body><sec><label>1.</label><title>Introduction</title><p>A workflow management system (WfMS) is a piece of software that provides the infrastructure to setup, execute, and monitor workflows. These systems enable the “extraction” of process management from the application software, in order to achieve communication, system integration, process optimization and control. Nowadays, WfMS are very popular in business environments where workflows are well determined, ordered and tightly coupled with the computing resources that support them. WfMS are based on well-known business standards such as the Business Process Execution Language (BPEL) and Business Process Model and Notation (BPMN). These standards allow different entities to coordinate tasks by exchanging information in a simple and almost pervasive way—through web services.</p><p>A Scientific Workflow (SWf) is a special type of workflow that solves a complex scientific problem that is supported by a special WfMS called Scientific WfMS. As business workflows, SWfs are composed of several tasks that are coordinated by a global task scheduling system running in the SWfMS. The SWf's execution is divided into two layers. The <italic>data plane</italic> exchanges the execution information of an activity (e.g., a sensor output, the results of an image or weather analysis, or a cell-behavior). The <italic>control plane</italic> exchanges the activation or de-activation orders that allows the synchronization in the execution process of activities (e.g., to initialize a simulation). Thus, the control plane directly supports the global task scheduling as it decides where, when and how to execute tasks. Scientific workflows share some of the characteristics of business workflows [<xref rid="b1-sensors-13-10954" ref-type="bibr">1</xref>] such as information filtering, process monitoring, and the necessity of a logical ordering of tasks that have to be carried out. Nevertheless, it has been proven that current business-oriented WfMS [<xref rid="b2-sensors-13-10954" ref-type="bibr">2</xref>], and communication models barely support [<xref rid="b3-sensors-13-10954" ref-type="bibr">3</xref>–<xref rid="b5-sensors-13-10954" ref-type="bibr">5</xref>] the requirements of SWfs in terms of event dissemination, task decoupling, flexibility and scalability. SWfs are expected to be a more dynamic series of ordered tasks, changing inputs/outputs, and fluctuations of the logical relationships between participants. They also targets distributed environments with heterogeneous entities executing tasks with a high level of time, space and synchronization decoupling. As an example, initiatives such as DATAGRID [<xref rid="b6-sensors-13-10954" ref-type="bibr">6</xref>], Open Science Grid [<xref rid="b7-sensors-13-10954" ref-type="bibr">7</xref>], and XSEDE [<xref rid="b8-sensors-13-10954" ref-type="bibr">8</xref>] provide systems and guidelines for executing SWfs and exploit the benefits of grid environments.</p><p>As communication over grid environments involves many challenges [<xref rid="b9-sensors-13-10954" ref-type="bibr">9</xref>,<xref rid="b10-sensors-13-10954" ref-type="bibr">10</xref>], one of the key issues in SWf research is the coordination of distributed workflows for a more efficient message exchange Thus, in order to improve this exchange it is necessary to take into account the runtime communication needs of a workflow, the logical relationships between its participants, and the type of tasks they execute. In addition, there are still challenges regarding how to improve the execution of SWfs by taking advantage of all the knowledge obtained from previous business-workflow research, and communication models that target loosely coupled systems. Hence, it has been proven that large-scale SWfs require models capable of providing an improved set of communication capabilities not only in parties that execute tasks, but also in entities bounding them. As an example, SWf platforms such as Taverna [<xref rid="b11-sensors-13-10954" ref-type="bibr">11</xref>] and Pegasus [<xref rid="b12-sensors-13-10954" ref-type="bibr">12</xref>], make use of grid infrastructures where workflow participants are heterogeneous in terms of location, processing power and network capabilities; however, little effort has been put into research on how the logical relationships between workflows' fragments influence the message exchange and the underlying protocols. Taverna also takes advantage of a Web Service Infrastructure [<xref rid="b13-sensors-13-10954" ref-type="bibr">13</xref>] in order to improve its extensibility and compatibility with Web-based services.</p><p>Besides the multiple open-issues [<xref rid="b9-sensors-13-10954" ref-type="bibr">9</xref>] in the SWfs area, we tackle the problem of supporting SWfs over grid-based environment in order to improve the event dissemination in the control layer. Therefore, we define key elements that enable the execution of SWf over the Publish/Subscribe (Pub/Sub) event layer. In our model we take as inputs two aspects: the message exchange in the control plane and the logical relationships between tasks. Even if the message exchanging of SWfs has been tackled with web-based technologies, it is has been proven that in highly distributed environments, using centralized solutions (at the event dissemination level) offers a low level of parallelism, communication decoupling and independence among participants.</p><p>The solution proposed in this paper exploits the logical relationships between fragments of a SWf and exposes abstract solutions, instead of directly tackling the message exchange aspect in the data plane with new protocols [<xref rid="b14-sensors-13-10954" ref-type="bibr">14</xref>] or middlewares [<xref rid="b15-sensors-13-10954" ref-type="bibr">15</xref>]. For this purpose, we use the Publish/Subscribe paradigm as the core communication model of our proposals. In addition, as one of the main requirements of SWf is the monitoring and failure recovery [<xref rid="b16-sensors-13-10954" ref-type="bibr">16</xref>], we also define self-healing mechanisms for the proposed models in runtime, so our solutions maintain loosely coupled communications and fulfill the level of abstraction and dynamism required by SWf.</p><p>The structure of the paper is as follows: Section 2 describes the characteristics of scientific workflow models and presents the Pub/Sub-based model we use throughout the whole article. Section 3 presents the initialization process of a SWf, the broker reference architecture we have defined in order to improve the message exchange in the control plane, and procedures for recovering bindings in SWfs. In Section 4 we justify the qualitative advantages of our model by firstly grouping existing models, systems and implementations, into common categories based their communication solutions; and then analyzing their trade-offs in terms of event dissemination, workflow patterns and other communication needs in runtime. In Section 5 we analyze related works and finally in Section 6, we end with conclusions and suggestions for future works.</p></sec><sec><label>2.</label><title>Scientific Workflow Modeling</title><p>Scientific workflows management systems (SWfMS) consist of several long-running data transformation steps while processing large amounts of data, coordinating and controlling the global workflow scheduling and monitoring underlying sub-tasks. In this process of decoupling the control and data planes from the task execution, the details of its invocation are hidden from the scientist. The high degree of dynamism inherent to these systems is not easily modeled or scaled [<xref rid="b17-sensors-13-10954" ref-type="bibr">17</xref>] by a business WfMS, which provides orchestration with a centralized scheduling environments which also usually implement centralized messages in the control plane. On the other hand, a simple choreography approach cannot be used as it is difficult to keep track of all the task instances and workflow activities at any given time [<xref rid="b18-sensors-13-10954" ref-type="bibr">18</xref>]. Hence, in order to support the previous characteristics, we use a Pub/Sub model for delivering these control messages in the whole SWf execution. Pub/Sub systems are composed of three main components: publishers, which are the content producers, subscribers, that express their willingness to consume specific content; and finally brokers, that put publishers and subscribers in contact by storing and forwarding information.</p><sec><label>2.1.</label><title>Overall SWf Scenario</title><p>SWfs share the same well-known workflow design patterns [<xref rid="b19-sensors-13-10954" ref-type="bibr">19</xref>] as business workflows, as they are also composed by a set of logically connected tasks, therefore, as a continuation of previous works [<xref rid="b20-sensors-13-10954" ref-type="bibr">20</xref>,<xref rid="b21-sensors-13-10954" ref-type="bibr">21</xref>], we extended our workflow modeling, from the message exchange perspective, provide abstract model for supporting six workflow patterns over a Pub/Sub broker and present their advantages in comparison with other approaches in terms of information delivery and task decoupling.</p><p>In this paper, we consider a SWf scenario with complex interactions between tasks (e.g., change the running conditions, stop and re-initialize) over a grid scenario and following a direct acyclic graph execution. In these interactions, processing and communication resources must be dynamically shared between task instances as nodes are working at full capacity and can go off-line due to changes in the network topology. We also consider that parallel tasks may fail, so failure handling and compensation mechanisms are needed. Usually, WfMS' provide a single centralized workflow scheduler with a centralized networking model (e.g., web-server to clients), which is not the ideal solution for executing a scientific workflow as its network layer has to deal with a high rate of control messages. Thus, even if only control messages are exchanged, it can become a bottleneck and misuse the network capabilities offered by the grid. In our scenario, nodes exchange data by following a choreography perspective, whereas control flow is set up using a special component we call Coordinator. The use of this kind of solutions is already present in previous works [<xref rid="b10-sensors-13-10954" ref-type="bibr">10</xref>], where Coordinators monitor the performance of the SWf and bind the inputs/outputs of tasks with the underlying Pub/Sub network and identifiers.</p></sec><sec><label>2.2.</label><title>Workflow Model of SWf</title><p>We define a workflow model based on tasks and activities that are allocated in local or remote nodes and mapped to the underlying Pub/Sub event layer. This SWf model evolves from our previous work [<xref rid="b20-sensors-13-10954" ref-type="bibr">20</xref>], its service foundations and concepts of tasks and activities. A workflow consists of the set of logical tasks and the communication channels between them, which are supported by a processing infrastructure on top of the event layer. Workflows are executed in a distributed way and logical relationships among tasks, which represent their internal behavior, are arranged in the fragmentation or partitioning process [<xref rid="b22-sensors-13-10954" ref-type="bibr">22</xref>]. The fragmentation process covers the actions of computing, initializing and distributing a set of tasks. Tasks are logical fragments of the workflow executed in local or remote nodes. In the SWf execution aspects such as elastic scalability, lifecycle management, security must be considered, but they are beyond the scope of this paper. In order to focus on our models, we assume that mechanisms exist to place and create tasks instances, so tasks are executed by a module called Orchestrator [<xref rid="b20-sensors-13-10954" ref-type="bibr">20</xref>], which is present in each node that participates in the SWf execution and an underlying middleware [<xref rid="b15-sensors-13-10954" ref-type="bibr">15</xref>] that provides Pub/Sub protocol support. A task is composed of at least one Activity. An <italic>Activity</italic> is an atomic unit of a task that has inputs and outputs. It manages the communication with an object that can be physical or digital, in order to perform an operation. For example an activity can be the action of requesting a local database value, or a remote notification of a finished job. Activities can trigger control events <italic>(ev)</italic> and consume those ones produced by activities running over different tasks. Therefore, from the communication perspective they trigger the <italic>publish(ev)</italic>, <italic>subscribe(ev), and un-subscribe(ev)</italic> primitives of the Pub/Sub network and are <italic>notified(ev)</italic> by brokers. We define <italic>Limit Activity (A<sub>L</sub>)</italic> as any activity that communicates with other activity contained in a remote task, so <italic>A<sub>L</sub></italic> can act, in runtime, as a producer, consumer or both. A control event is the action of transmitting a control message (e.g., to start the <italic>A<sub>L</sub></italic> execution); however, we use them as similar term when referring to our communication model.</p><p>We use logic gates to enable communication between tasks, in the control plane. These logic gates follow the patterns model, defined by Van Der Aalst <italic>et al.</italic> [<xref rid="b19-sensors-13-10954" ref-type="bibr">19</xref>], corresponding to basic control flow patterns, advanced branching and merging. Thus, hereinafter we use workflow pattern and logic gate as the same concept. <xref rid="f1-sensors-13-10954" ref-type="fig">Figure 1</xref> illustrates the two different planes that our model targets, from the global scheduling perspective of the SWf. It also shows how control messages are mapped to Pub/Sub primitives and events and later disseminated over a distributed broker scenario. Limit activities are linked by logic gates, which in turn trigger control messages that activate subsequent ones.</p></sec></sec><sec><label>3.</label><title>Supporting the Scientific Workflow</title><p>The following sections explain the models we propose to support a decentralized SWf execution as well as the workflow messaging. Hence, our objective is to improve the workflow coordination, at the event level, by leveraging the complexity of the dissemination of control events to brokers, and transfer to them the interactions among remote <italic>A<sub>L</sub>s</italic>. At the end of this section, we provide an example regarding the support of our SWf model including the initialization and runtime over the Pub/Sub layer.</p><sec><label>3.1.</label><title>Supporting the SWf</title><p>The proposed model is composed of the definition of a task interoperability reference model, the mapping of workflow activities to Pub/Sub topics, the interfaces that allow setting up the Pub/Sub layer, the broker reference architecture, and finally the procedures for dealing with binding recovery between activities in runtime.</p><sec><label>3.1.1.</label><title>Task Interoperability</title><p>Conceptually, tasks must agree on the control messages their <italic>A<sub>L</sub>s</italic> generate or require, and how they are mapped to control events in the Pub/Sub layer. Therefore, brokers have to filter and only deliver those ones that match subscription requests. To do this we use a topic-based Pub/Sub language [<xref rid="b23-sensors-13-10954" ref-type="bibr">23</xref>]. Messages are published using “topics” that identify <italic>A<sub>L</sub></italic>s' outputs and subscriber <italic>A<sub>L</sub></italic>s subscribe to topics representing their triggering condition or inputs.</p><p>In order to define a common hierarchy of topics, we use a topic domain shared by all tasks and divided into namespaces. Topics are published in namespaces in order to receive control messages in the appropriate language and ensure that only compatible events are pushed by brokers. Each topic in a topic namespace (<italic>tns</italic>) can have zero or more child topics and a child topic can itself contain further child topics. A topic without a parent is termed a root topic. We use the forward slash (/) character to indicate a “child of” relationship. For example, the <italic>tns1:monitor/exception</italic> refers to the subtopic exception, subset of the parent topic monitor, in the namespace <italic>tns1</italic>.</p><p>This approach supports transformation and aggregation of topics. It is possible to construct configurations (using intermediary brokers) where the topic, an interested “subscribes to” differs from the topic under an entity “publishes”. Thus, the broker, acting in line with administratively-defined rules, receives the control messages from the publisher, matches and notifies the corresponding subscriber. For example, a subscriber to the topic <italic>tns1:monitor</italic> also receives notifications from topic <italic>tns1:monitor/exception</italic>. It is possible for participants of the SWf to define additional topics based on existing topics without requiring coordination with the participant responsible of creating the topics that are being built on. Our solution is compatible with the WS-Topics OASIS standard [<xref rid="b24-sensors-13-10954" ref-type="bibr">24</xref>], which presents a set of “items of interest for subscription” in Web service environments, and it has been extended to be aligned to a non-WS environment.</p><p>An example of a topic hierarchy for a generic SWf is shown in <xref rid="f2-sensors-13-10954" ref-type="fig">Figure 2</xref>. This <italic>tns</italic> corresponds to the English language, to avoid language incompatibilities. To prevent correlation problems, a root node has been added, so it contains the identifiers of the task instances that are being executed.</p></sec><sec><label>3.1.2.</label><title>SWf Initialization</title><p>The workflow initialization over the Pub/Sub events requires an interface between the Coordinator and brokers. This interface implies the loading of Web Service Description Language (WSDL), which is defined in this section. Thus, prior to the execution of the SWf over participants, it is necessary to link the logical interest of an <italic>A<sub>L</sub></italic> (<italic>input or output</italic>) to the communication primitive that will support it: <italic>subscribe(ev)</italic> or <italic>publish(ev)</italic>. In other words, it is necessary to bind the SWf plane with the Pub/Sub layer and comply with the logical gates that join tasks and their <italic>A<sub>L</sub></italic>. The initialization process refers to mechanisms that support the binding of an action of a predecessor <italic>A<sub>L</sub></italic> with a Pub/Sub event, the associated logic gate, and a subsequent reaction of a successor <italic>A<sub>L</sub></italic>. Therefore, as the Orchestrator of each participant detects the <italic>A<sub>L</sub></italic> s that makes up part of the task instance, the topics for each input and output <italic>A<sub>L</sub></italic> must be designated. For this task, we use the Coordinator function. From here onwards, the Coordinator registers the references of predecessor and successor of every <italic>A<sub>L</sub></italic> of the SWf and generates the topics identifiers by following the namespace previously proposed. In this process we assume that the Coordinator have already received the initial SWf structure and logical relationships between activities from a global SWf scheduler or a workflow composer (e.g., the database created by the Trident SWf composer [<xref rid="b25-sensors-13-10954" ref-type="bibr">25</xref>]). Brokers inform the Coordinator about the network capabilities they support, such as supported protocols, and the set of logic gates they can instantiate. Hence, the coordinator can know, in advance, which of the brokers can instantiate a logic gate and link corresponding <italic>A<sub>L</sub></italic>s. Then, as each <italic>A<sub>L</sub></italic> has its own topic the Coordinator can group these activities using the initial SWf structure. The Coordinator sends to brokers the information regarding <italic>A<sub>L</sub>s</italic> that produce events (predecessors) and the <italic>A<sub>L</sub></italic> that are triggered by these events (successors) over the same SWf instance. This information also includes the callback addresses of Orchestrators that are executing the corresponding tasks. Afterwards, brokers use this information to internally group subscriptions using the model explained in Section 3.3. In order to maintain a generic and flexible coordination interface between brokers and the Coordinator we define the WSDL shown in <xref rid="f3-sensors-13-10954" ref-type="fig">Figure 3</xref>, which follows the same concepts of current SWf systems such as Trident [<xref rid="b25-sensors-13-10954" ref-type="bibr">25</xref>].</p><p>The WSDL describes the logic gates (or patterns) types, and relationships between <italic>A<sub>L</sub>s</italic> they enclose. The <italic>SetCapability</italic> field is used by the Broker to express its capabilities to the Coordinator, whereas the Coordinator makes use of the corresponding response to set the predecessors and successor <italic>A<sub>L</sub></italic> in the workflow initialization. <italic>SetNewCapability</italic> messages are sent, by the Coordinator, to brokers with the objective of grouping logic gates and <italic>A<sub>L</sub></italic>s.</p><p>The Coordinator groups activities depending on the predecessor and successor relationships between <italic>A<sub>L</sub></italic>, so it puts them, by default, in the same broker. In the case this process is unfeasible (e.g., due a network constrain or a request of the SWf manager), the Coordinator can set a successor activity in a different broker than its predecessor. This one of the cases we show in <xref rid="f1-sensors-13-10954" ref-type="fig">Figure 1</xref>, where <italic>A<sub>L</sub>-4</italic> and <italic>A<sub>L</sub>-9</italic> are predecessor and successor, respectively, and are set in different brokers. In this situation, the Coordinator marks the predecessor callback string as “<italic>remote</italic>”. Then, it attaches in the <italic>predecessor</italic> field of the message specified by the WSDL, the network address of the broker that supports its predecessor <italic>A<sub>L</sub></italic> followed by the topic that identifies it (e.g., <italic>remote,http://</italic><<italic>x.x.x.x</italic>>,/<italic>task/activity1</italic>). Therefore, the broker of the successor <italic>A<sub>L</sub></italic> subscribes to the broker of the predecessor <italic>A<sub>L</sub></italic>., and gets ready for receiving control messages that target the successor <italic>A<sub>L</sub></italic>. This type of recursive subscription has been well-proven over the Internet and many Pub/Sub protocols supports them (e.g., PubSubHubbub [<xref rid="b26-sensors-13-10954" ref-type="bibr">26</xref>]), so our solution can be considered independent from any specific implementation and remains compatible with our previous research [<xref rid="b21-sensors-13-10954" ref-type="bibr">21</xref>] focused on simple and scalable gossip-based interactions. Our model is also independent from the specific protocol used to communicate brokers and the Coordinator, as long as the WSDL interface is used.</p></sec><sec><label>3.1.3.</label><title>Binding Control Events in Brokers</title><p>As previously mentioned, our objective is to delegate to brokers the complexity of communication between <italic>A<sub>L</sub></italic>s and logic gates. The broker reference architecture used to support workflow patterns is similar to standard topic-based brokers. The broker registers subscriptions from clients, matches control events and disseminates these events to subscribers or other brokers. Workflows are supported using a pluggable matching model which works on top of standard broker processes. Hence, while standard topic-based brokers match incoming events and notify the right subscribers based on their interest, our broker firstly filters the control events that fulfill the logic gates and later notifies subscribers. So, even if successor <italic>A<sub>L</sub></italic>s subscribe to a task and their predecessor subscriptions publish a control event, the broker dynamically holds the notification of this event until the logic gate is satisfied. The notification is dynamic because the broker can react to changes in the relationships between activities which were extracted from the WSDL as we explain in Section 3.1.4. Our broker enforces the patterns following the models described below. Having this architecture, our broker is capable of decoupling <italic>A<sub>L</sub></italic>s, their role and actions they can trigger in other workflow branches or tasks executed in parallel (e.g., an activity that calibrates time). The matching model performs as a pluggable component as it only needs to internally receive all the published events from every <italic>A<sub>L</sub></italic> of the WSDL, in order to correlate and notify the correct event. It can work on top of standard topic-matching functions without any disturbance or special synchronization. <xref rid="f4-sensors-13-10954" ref-type="fig">Figure 4</xref> shows the reference broker architecture.</p><p>We use the term internal binding (B<sub>I</sub>) to describe how we model the relationships between <italic>A<sub>L</sub></italic> and logic gates inside the broker. LG represents the process of enforcing these gates in runtime. We consider our model a composite binding of two internal bindings. We apply the term external subscriptions (S<sub>E</sub>) to describe the relationship between a topic, which represents the interest on the LG fulfilling a control event, and a callback address of the Orchestrator that runs the <italic>A<sub>L</sub></italic>. In our model, as the S<sub>E</sub> implicitly fulfill the two bindings a standard event notified to a subscriber is defined as: <italic>s.ev'</italic>=<italic>f(s.ev,S<sub>E</sub>)</italic>. When we add the logic gate component, this event is defined as follows:
<disp-formula id="FD1"><label>(1)</label><mml:math id="mm1"><mml:mrow><mml:mi>e</mml:mi><mml:mi>v</mml:mi><mml:mo>'</mml:mo><mml:mo>=</mml:mo><mml:mi>f</mml:mi><mml:mo stretchy="false">(</mml:mo><mml:munderover><mml:mo>∑</mml:mo><mml:mi>i</mml:mi><mml:mi>k</mml:mi></mml:munderover><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mtext mathvariant="italic">IPk</mml:mtext></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo><mml:mo>,</mml:mo><mml:munderover><mml:mo>∑</mml:mo><mml:mi>i</mml:mi><mml:mi>k</mml:mi></mml:munderover><mml:mrow><mml:msub><mml:mi>B</mml:mi><mml:mrow><mml:mtext mathvariant="italic">ISk</mml:mtext></mml:mrow></mml:msub></mml:mrow><mml:mo>,</mml:mo><mml:mi>L</mml:mi><mml:mi>G</mml:mi><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></disp-formula> where B<sub>IP</sub> and B<sub>IS</sub> define bindings with predecessor and successor (S<sub>E</sub>) respectively. Being B<sub>IPT</sub> and B<sub>IST</sub> the whole set of predecessor and successor subscriptions: <italic>B<sub>IPK</sub></italic> ⊆ <italic>B<sub>IPT</sub></italic> and <italic>B<sub>ISK</sub></italic> ⊆ <italic>B<sub>IST</sub></italic>, where B<sub>IPT</sub> and B<sub>IST</sub> are the binding spaces for a given task instance. Then, the difference between matching an event using standard matching and our matching model is enforced at this point. Whenever a <italic>A<sub>L</sub></italic> generates a control message that is published to the brokers, in the case of standard matching, the evaluation and notification of the event is straightforward since the broker only ensures that the event's topic corresponds with the existing S<sub>E</sub>. Nevertheless, in our model, whenever a similar control message arrives to the broker, it broker performs (depending on the pattern) the latter performs the steps described in the following paragraph. <xref rid="f4-sensors-13-10954" ref-type="fig">Figure 4</xref> depicts the broker reference architecture.</p><p>In runtime, a predecessor binding is an instance, inside the broker, subscribed to a control event an <italic>A<sub>L</sub></italic> triggers. In the case that this event fulfills this binding; the broker evaluates the Logic Gate (LG) where B<sub>IP</sub> belongs and triggers an internal event (<italic>i.ev</italic>). Then, the broker matches this event with the successor bindings which contain the real subscribers' callbacks of the logic gate, and <italic>notifies(ev)</italic> them. Retaking <xref rid="f1-sensors-13-10954" ref-type="fig">Figure 1</xref>, the input of <italic>A<sub>L</sub></italic>-9 is represented by a B<sub>IST</sub>, and the output of <italic>A<sub>L</sub></italic>-4 by B<sub>IP</sub>; so in order to modify/activate the execution of <italic>A<sub>L</sub></italic>-9, the broker evaluates if there is a B<sub>IP</sub> interested in the output event produced by <italic>A<sub>L</sub></italic>-4. Next, as it is true and a Sequence flag is active, it generates an internal event captured by B<sub>IST</sub>, which represents the interest of <italic>A<sub>L</sub></italic>-9; then, the broker pushes the control message to the callback address of the Orchestrator. As we already mentioned, in our model we support six workflow patterns, which are the basic control-flow patterns that are used to build workflows. The implementation mechanism proposed in this paper focuses on the six selected workflow patterns, as they are the most elementary of the entire existing workflow pattern and are used for building more complex SWF. Following this approach, now we explain how we support each case assuming that each of the activities we mention are limit ones.</p><p><italic>Sequence (SEQ)</italic>: it is the pattern we used to explain our model right before. In this pattern, a single activity is enabled after the completion of the preceding activity. Thus, brokers establish a one-to-one relationship between B<sub>IP</sub> and B<sub>IS</sub>; so, B<sub>IP</sub> always triggers an <italic>i.ev</italic> that leads to the real subscriber and its activity.</p><p><italic>Parallel split (ANDs)</italic>: in this pattern, a set of activities are enabled after the completion of the preceding activities. Brokers establish a one-to-many relationship with B<sub>IP</sub> and many B<sub>IS</sub>. Bindings that represent the successor activities are triggered by the same <italic>i.ev</italic>, however, unlike the sequence pattern; the broker matches the <italic>i.ev</italic> with the successor bindings they are interested in. This operating mode is due to B<sub>IP</sub> and B<sub>IS</sub> can be part of other patterns, so keeping an internal reference among them, allows decoupling the particular activation of the LG instance from other relationships or interests internal bindings can have.</p><p><italic>Exclusive choice (XORs)</italic>: having a set of candidate activities to be enabled; only one is enabled after the completion of a prior activity. In this pattern, brokers also establish a one-to-many relationship with B<sub>IP</sub> and B<sub>IS</sub>s. The pattern depends on the control event that defines which activity must be enabled, so, we model this event as: <italic>c.ev</italic> = <italic>f(B<sub>LG</sub>, ev)</italic>. As we are using a topic-based language, this event contains the topic of the B<sub>IS</sub> that follows the workflow.</p><p><italic>Simple merge (XORj)</italic>: this pattern defines the convergence of two or more activities into a subsequent activity. The broker establishes a many-to-one relationship with B<sub>IP</sub>s and B<sub>IS</sub> respectively. Since no synchronization is needed, whenever the first B<sub>IP</sub> is matched with a control event, the LG lets this event reach the B<sub>IS</sub> as an <italic>i.ev</italic>. This process is available for any of the B<sub>IP</sub>. After each process, the LG is re-initialized in order to support new matched events arriving from the same B<sub>IP</sub> or new ones.</p><p><italic>Synchronization (ANDj)</italic>: this pattern defines the convergence of two or more synchronized activities into a new activity. In other words, in order to enable the subsequent activity, all the previous activities must be enabled. This pattern is modeled as a many-to-one relationship with B<sub>IP</sub>s and B<sub>IS</sub>. In this pattern we do not take into consideration correlation issues [<xref rid="b27-sensors-13-10954" ref-type="bibr">27</xref>], because we assume that brokers can implement buffers, timestamps or any other mechanism to address them. We start from the fact that brokers receive the correct events. Hence, every time the broker enforces the sync pattern, it links each predecessor activity to an open lock, so every time an event satisfies a B<sub>IP</sub>, the broker closes its lock. Next, in the case that all the activities are locked, the <italic>i.ev</italic> is triggered and the broker verifies the covered B<sub>IS</sub>, so then, it informs the corresponding task's <italic>A<sub>L</sub></italic>.</p><p><italic>Multi-choice (ORj):</italic> this pattern describes the divergence of an enabled activity into one or more activities, so the execution of the successive activities is enforced using a dynamic condition. The way LG supports a dynamic condition is through the same control event of the exclusive choice pattern. Thus, once the LG is enforced the broker triggers an <italic>i.ev</italic> that reaches the B<sub>IS</sub> and activates the corresponding activity. At this point, the challenge consists of how to allow different B<sub>IS</sub> to only consume <italic>i.ev</italic> under the conditions determined by the received control events. Assuming that these conditions include the identifiers of each subsequent activity, our solution consists of letting B<sub>IS</sub> to internally subscribe to their same instances. Then, <italic>i.ev</italic> messages targeting these identifiers will be created and the matching process will be ready to verify if the event satisfies only the enabled B<sub>IS</sub>. This strategy is feasible using topic-based languages (because the same topics can be used as identifiers) and non-distributed subscriptions (as the cost of producing events is lower).</p></sec><sec><label>3.1.4.</label><title>Workflow Recovery Support</title><p>In our model brokers are capable of updating internal subscriptions in order to avoid unreachable states or inconsistences in the SWf execution. The sequential pattern is the most elementary supported logic gate. Remaining logic gates can be modeled as a sequential pattern in the case of having only one predecessor and one successor activity. A distributed workflow (using many different logic gates) can experience this kind of situation because of on-demand actions or due to runtime inconsistences. In order to support these actions and prevent inconsistences and deadlocks, we propose the pseudocode shown in <xref rid="f5-sensors-13-10954" ref-type="fig">Figure 5</xref>. It recovers and reconnects predecessors and successors bindings that trigger the real events pushed to limit activities. This method is feasible because brokers previously received all the relationships between activities with the WSDL. It is compatible with alternative limit activities that could appear in runtime because each time an un-subscription (unsub.event) occurs the broker recovers the same relationships that are employed in the matching.</p><p>As an example a SWf is composed of instances of tasks A, B and C which are linked by sequential activities in the same order. Hence, task C consumes events produced by task B and the latter from task A. The pseudocode uses as input, every un-subscription event received by the broker. This un-subscription represents a changing state in tasks and therefore in its <italic>A<sub>L</sub></italic>s. The un-subscription can be triggered by on-demand actions of the SWf scheduler, or by an event of unexpected disconnections in implementations that are based on ping-based interactions (e.g., WebSockets ping). Step 2 checks if there are still successor bindings (in this case inputs targeting tasks B) interested on the events produced by task A's activities. In the case the un-subscription event corresponds with the last remaining successor binding that is interested on events received from task A, the algorithm recovers (Step 3) the successor binding. Next, the algorithm iterates (Step 4) each of the existing predecessors bindings and then compares if the callback address of B<sub>IS</sub> corresponds with any callback address that has published under the identifier of <italic>B<sub>Pi</sub></italic>. In this process the topic can be used as this identifier, as we maintain a strict hierarchy, but it is still compatible with other mechanisms. Afterwards, Step 6 searches for every successor binding, which represents in our case the input for the activity of task C, willing to consume the activation events <italic>(i.ev)</italic> resulting from the gate's enforcing. This step can be compared with a membership test which is well-supported using fast matching techniques (e.g., through Bloom Filters [<xref rid="b28-sensors-13-10954" ref-type="bibr">28</xref>]). At this point the remaining step consists on recovering (Step 7) each one of the successor bindings and set them with a new interest that will be at the end, the triggering input of the successor activity of tasks B.</p><p>The algorithm targets subscriptions that are being supported in the same broker, nevertheless in the case the broker ends its execution and no new interests are set, being the distributed nature of the SWf, it can execute a mechanism [<xref rid="b29-sensors-13-10954" ref-type="bibr">29</xref>,<xref rid="b30-sensors-13-10954" ref-type="bibr">30</xref>] to disseminate these disconnection events. In the case of synchronizing patterns it contributes to the self-healing characteristics of a SWf as tasks depend on the correct scheduling of every one of the previous branches tasks and their <italic>A<sub>L</sub>s</italic>. As a final point, the pseudocode takes as triggering points the un-subscription actions that enclose successor binding instead of predecessor bindings and this characteristic is because it targets SWf based on directed acyclic graphs.</p></sec></sec><sec><label>3.2.</label><title>Workflow Messaging</title><p>In this section we explain how our SWf model behaves in the Pub/Sub layer in initialization and runtime, as it requires some primitives in the event layer <italic>(publish,subscribe,notify,un-subscribe)</italic> in order to bind tasks and their limit activities. <xref rid="f6-sensors-13-10954" ref-type="fig">Figure 6</xref> shows an overview of the workflow messaging message exchange among tasks A,B and C, one serving brokers and their Coordinator. In the global schedule model, these tasks carry on the <italic>A<sub>L</sub>s</italic> we showed in <xref rid="f1-sensors-13-10954" ref-type="fig">Figure 1</xref>. Tasks A, execute <italic>A<sub>L</sub>-5</italic> and <italic>A<sub>L</sub>-10</italic>. Task B executes <italic>A<sub>L</sub>-7</italic> and <italic>A<sub>L</sub>-8</italic>. Task C executes <italic>A<sub>L</sub>-6</italic>.</p><p>In the first step the broker that will support the SWf participants sends (a) to the Coordinator its capabilities using the WSDL description presented in Section 3.1.2 Workflows' participants subscribe (b.1,2,3) to the broker and wait until topics corresponding inputs and outputs of <italic>A<sub>L</sub></italic> are assigned. Once the Coordinator initializes the topic identifiers of each <italic>A<sub>L</sub></italic>, it pushes this information to the broker (c), which matches the correct workflows participants using the client identifier it has received from the Coordinator. At this point the broker creates the internal bindings, by arranging predecessor and successor activities, and uses the callback information to notify (d.1,2,3) tasks A, B, and C with the topics identifiers that represent these <italic>A<sub>L</sub></italic>s.</p><p>The first step towards the global execution of the SWf is to inform each one of participants regarding the topic identifiers. Once tasks subscribe (e.1,2,3) to the broker, it registers these subscribers as successors and gets ready to notify control messages. We developed logic gate cases of the <italic>ANDs</italic> and the <italic>ANDj</italic> as they encompass, in terms of message exchange, the remaining gates. These two cases involve many-to-many communication and control messages that trigger activation of branches activities. In the <italic>ANDs</italic> case, <italic>A<sub>L</sub></italic>-7 and <italic>A<sub>L</sub></italic>-6 are the successors; so whenever tasks A reaches <italic>A<sub>L</sub>-5</italic>, it publishes an event (f.1), using <italic>tns:pattern/parallel/cevent</italic>, and the broker notifies (f.2,3) them. Following the SWF execution, activities <italic>A<sub>L</sub></italic>-8 and <italic>A<sub>L</sub></italic>-6 are the workflow predecessors and <italic>A<sub>L</sub></italic>-10 the successor. They are connected through an <italic>ANDj</italic> pattern, so it requires that all the predecessor activities must be completed before the execution of the successor one. Following the binding model of Section 3.1.3, the broker implements the LG and marks <italic>A<sub>L</sub>-6</italic> and <italic>A<sub>L</sub>-8</italic> as B<sub>IP</sub>s, and <italic>A<sub>L</sub>-10</italic> as B<sub>IS</sub>, so the broker will only trigger the <italic>i.ev</italic> if both B<sub>IP</sub> are satisfied. After the execution of <italic>A<sub>L</sub>-6</italic>, it publishes an event (g.1) that matches the first B<sub>IP</sub>. At this point, the LG conditions are partially fulfilled as the broker retains the event that triggers the B<sub>IS</sub> and the activation of <italic>A<sub>L</sub>-10</italic> until Participant <italic>A<sub>L</sub>-8</italic> publishes (g.2) the corresponding remaining event that will match the remaining B<sub>IP</sub>. After any given time, if Task B disconnects from the broker (e.g., due to a planned action or an unexpected situation such as a network failure), the latter updates the predecessor binding registry for this LG. Hence, in the case <italic>A<sub>L</sub>-6</italic> generates a new event; the broker directly matches the only existing successor binding and triggers the control event targeting <italic>A<sub>L</sub>-10</italic>, as there is no need to wait any other predecessor binding. Participants can also un-subscribe to topics, by issuing the primitive unsubscribe (topic) and the broker will enforce the process explained in Section 3.1.4.</p><p>In the case of a broker failure the Orchestrators use a pre-configured backup broker and publish the network properties of the failing broker using the topic: <italic>monitor/exception/broker</italic>. Therefore, as the Coordinator is already subscribed to this topic, it will receive this information. Afterwards, it confirms the broker status by issuing the SOAP request shown in <xref rid="f7-sensors-13-10954" ref-type="fig">Figure 7</xref>. Both negative and positive responses will be informed to the overall SWf Scheduler. In the negative case, it will be caused by a connectivity issue between the participant and its broker. The second one represents a total failure of the broker, so the SWf will need a reallocation of participants to an available broker. Specific network recovery model and re-scheduling mechanisms are out of the scope of this paper, so we assume that Coordinator can always reinitialize the SWf using the process explained in Section 3.1.2.</p></sec></sec><sec><label>4.</label><title>Communication Model and Application Scope</title><p>As we stated, our model is based on the principle that workflow patterns are supported in brokers, rather than in nodes. Therefore, we have reviewed in the literature existing systems that support the execution of SWf, and then we have classified them into three communication solutions based on how they support the control message exchange. Then, the objective of this section is to analyze the expected requirements of SWf execution in the context of workflow patterns and in-runtime message exchange. Later, we use this analysis to extract the advantages of our proposal in comparison with the other three communication solutions. These requirements are: information dissemination, info dispatching and filtering, task decoupling through workflow patterns, flexibility over workflow changes, scalability of events and workflow monitoring and failure handling.</p><p>In this section we demonstrate that offering workflow pattern support, at the message exchange level, offers more global advantages to SWf participants in terms of information delivery, task decoupling and so on. Afterwards, we provide a quantitative evaluation of the solutions. <xref rid="f8-sensors-13-10954" ref-type="fig">Figure 8</xref> shows the relationships between the workflow patterns, participants and control events.</p><p>The first solution is based on a semi-centralized messaging (SCM) in the SWf scheduling; in this solution, workflow patterns that connect tasks are supported over centralized schedulers or a pool [<xref rid="b31-sensors-13-10954" ref-type="bibr">31</xref>] of decentralized ones under the same SWfMS. Therefore, we can assume that communication between different tasks is supported by establishing channels between tasks and schedulers, no matter the underlying characteristics of the dissemination layer (e.g., a tailored grid [<xref rid="b6-sensors-13-10954" ref-type="bibr">6</xref>,<xref rid="b7-sensors-13-10954" ref-type="bibr">7</xref>,<xref rid="b11-sensors-13-10954" ref-type="bibr">11</xref>,<xref rid="b32-sensors-13-10954" ref-type="bibr">32</xref>] or web-based messaging [<xref rid="b33-sensors-13-10954" ref-type="bibr">33</xref>]); this characteristic is because the workflow scheduling of tasks is still linked to control events triggered by schedulers in response to the workflow patterns. Hence, from the underlying communication perspective, these control events are stored and forwarded by only one entity (e.g., a built-in or a remote message broker).</p><p>The second solution is a distributed scheduling messaging (DM) between tasks. Tasks are scheduled [<xref rid="b34-sensors-13-10954" ref-type="bibr">34</xref>] to run in a distributed table over a P2P-based scenario, which is shared among participants, rather than in a cluster or a pool of schedulers. Triggered events are decoupled from schedulers and the running conditions (which also depend on workflow patterns) reside in the same table in the form of states (pending, running and finished).</p><p>We call the third solution Pub/Sub with channel optimization messaging (COM). It is based on our previous research [<xref rid="b20-sensors-13-10954" ref-type="bibr">20</xref>] and inherits its mechanisms for establishing channels associated to task and the support of workflow pattern in the same nodes that execute these tasks. Therefore, nodes running tasks are loosely coupled from schedulers in execution, at expenses of dependency in space. Finally, we name our whole solution model as Bounded patterns over Pub/Sub (BPoPS). A summary of the comparison is depicted in <xref rid="t1-sensors-13-10954" ref-type="table">Table 1</xref>.</p><sec><label>4.1.</label><title>Qualitative Comparison</title><p><italic>Information dissemination</italic> refers to the mechanisms that allow tasks to gain access to the branch conditions via control messages. In the SCM solution Orchestrators executing tasks are always coupled to other Orchestrators in terms of location of the target tasks (space coupling) and the flow interaction dependencies among them (synchronization decoupling). This fact is a disadvantage for the SWf as its execution is dependent to this coupling no matter the message exchange pattern: many-to-one (e.g., <italic>ANDj</italic>) and one-to-many (e.g., <italic>ANDs</italic>). The DM solution provides a well-proven information dissemination environment as tasks can be fully-decoupled from the scheduling systems. However, maintaining a shared, synchronized and consistent information space between a wide range of SWf participants, and their intermediary patterns [<xref rid="b35-sensors-13-10954" ref-type="bibr">35</xref>], leads to networking overhead and complex scheduling datasets in comparison with the COM and BPoPS solutions.</p><p>In BPoPS we leverage to brokers the scheduling order and the triggering conditions generated by activities bindings in runtime; so tasks remain agnostic of the other tasks with which they have no runtime relationship. Regarding sync decoupling, as brokers carry on the message storage and forward functions, participants are set to be straightforward and lightweight (from the dissemination stack perspective). Hence, this model offers better capabilities as tasks get control messages <italic>over a fully asynchronous and decoupled communication model</italic>, while the global SWf scheduling <italic>remains compatible with event dissemination mechanisms</italic> (e.g., Gossip-based [<xref rid="b21-sensors-13-10954" ref-type="bibr">21</xref>]) targeting distributed networks and grids.</p><p><italic>Message dispatching and filtering</italic> refers to the mechanisms for creating, dispatching and later filtering of control messages. In the SCM messages directly reach the right participants' Orchestrators. Whenever a scheduler jumps from one task to another, the Scheduler decides which of the task participants it needs to trigger based on the workflow patterns. The process of pushing messages is carried out at the Application Level, as the global scheduler is aware of the network location and information models of the successor activities. This mechanisms offer advantages for centralized SWfs, because no overlay or intermediary functions are needed, however, it is proven that a centralized information delivery is not the best method [<xref rid="b17-sensors-13-10954" ref-type="bibr">17</xref>] for delivering messages in SWfs.</p><p>In the DM solution, the overlay network filters workflow control conditions. Depending on the network topology (e.g., pure and hybrid P2P), the schedulers can directly coordinate the execution (point-to-point). Tasks are registered to predecessors and successors tasks using recursive P2P-based searches that act as message filters between them. These kinds of methods require [<xref rid="b36-sensors-13-10954" ref-type="bibr">36</xref>] complex scheduling mechanisms in order to balance the load and delivery messages in contrast with our BPoPS solution were <italic>messages can be filtered at the nearest point</italic> such as the tasks' broker.</p><p>In the COM solution messages are filtered and forwarded to participants that execute tasks, however, it produces a high level of long-lived subscriptions between nodes and schedulers, which makes this solution unfeasible for complex and distributed SWfs. In the BPoPS solution, brokers maintain the forwarding and event filtering level because they filter the events using topics that represent bindings under administratively-defined rules. The BPoPS solution <italic>enhances the event interoperability with SWf task instances that could be added in runtime</italic> (e.g., a new set of optical sensors) as brokers enforce an Event-level filtering based only on topics which are independent from the information models used by activities.</p><p><italic>Task decoupling through workflow patterns</italic> is a characteristic that allows SWf participants to maintain decoupled the relationships between tasks. Synchronized communication provides limited task decoupling, which is non-expected characteristics for distributed SWfs [<xref rid="b3-sensors-13-10954" ref-type="bibr">3</xref>]. In the asynchronous SCM case the SWf execution is dependent on the blocking conditions and synchronization generated by scheduler as it is the only capable of retrieving successor activities in the whole SWfMS. This limitation applies no matter what state the task is in or the pattern that joints its activities.</p><p>In the COM solution tasks acting as publishers and subscribers are partially decoupled. This is because the <italic>XORj</italic> and <italic>ANDj</italic> patterns obligate successor activities to subscribe to each one of the predecessor activities. In addition, as each one of the subscription to these activities establishes a single and tailored channel (that can be compared with a network address), this solution breaks the principle of Pub/Sub communication regarding space decoupling.</p><p>The BPoPS solution is the most complete one, as it fully supports tasks decoupling since A<sub>L</sub>s can subscribe to other ones using the same topics, regardless of their binding pattern. Our proposal is also compatible with the process of adding and removing A<sub>L</sub>s (using the WSDL) by schedulers and allows other related tasks to continue their execution without disturbance in the case of SWf changes; for example by executing the pseudocode presented in <xref rid="f6-sensors-13-10954" ref-type="fig">Figure 6</xref>. It is not illustrated how the DM based model can afford the task decoupling thought workflows patterns.</p><p><italic>Flexibility</italic> is the ability to adapt to SWf changes. In the SCM case the flexibility is limited by the amount of activities-to-activities bindings; so schedulers must be capable of re-ordering the SWf execution in the case of changes in the execution order. In the SCM solution, schedulers must contact each one of the SWf tasks, so it limits the workflow to a centralized point of failure and decreases the SWf flexibility. The DM offers high flexibility over network changes as it depends on single links between schedulers and tasks participants. The COM solution embodies similar flaws than the SCM solution in the case of <italic>XORj</italic> and <italic>ANDj</italic> patterns since the successor activity must be aware of the state of its predecessor <italic>A<sub>L</sub>s</italic>. Therefore, this scenario obligates tasks to be subscribed to all of these outputs, which increases the messaging and the implementation complexity of the Orchestrator of the predecessor activity. In our solution as the entire branch conditions pass through brokers, <italic>they can implement mechanisms to recover the workflow bindings and dissemination protocols (</italic>e.g., <italic>gossip-based) that complement the network flexibility and participants' simplicity</italic>. Depending on nodes, the workflow scheduling and the scenario where it runs (e.g., structured SWf topology and lightweight participants), our solution offer suits more qualitative advantages as we state in Section 4.2.</p><p>In our context, <italic>scalability of events</italic> is the increase in the number of total connections among <italic>A<sub>L</sub>s</italic>, so the less connections the SWf execution requires the more scalable it will be. In the case of the SCM solution connections grow in proportion to the number of <italic>A<sub>L</sub>s</italic> added to the SWf, which makes this solution costly in terms of networking resources. In the DM solution tasks fetch the execution stages from shared information, so they can directly communicate with other tasks. Therefore, scalability depends on the number of participants being part of the SWf rather than the running conditions. As SWfs can be very dynamic in runtime the DM solution offer less advantages that our proposal in static networks. The COM case uses Pub/Sub communication, which has been proven its good scalability [<xref rid="b3-sensors-13-10954" ref-type="bibr">3</xref>,<xref rid="b37-sensors-13-10954" ref-type="bibr">37</xref>] delivering control messages in workflows. Nevertheless, in the case of having a SWf with a large number of events and joint-based patterns (e.g., <italic>XORj)</italic>, as these brokers are agnostics in terms of patterns, the task (and its successor <italic>A<sub>L</sub></italic>) must be subscribed to every one of predecessor <italic>A<sub>L</sub></italic>. So, unnecessary messages will reach tasks and decrease the scalability level of the whole SWfMS. In our solution <italic>connections grow with changes in the workflow running conditions, which required requires less messaging because no unnecessary control messages will be pushed to tasks</italic>.</p><p><italic>Workflow monitoring</italic> refers to the process of verifying that the workflow execution conveys with the messaging that leads to the correct ordering of <italic>A<sub>L</sub></italic> execution and no errors, deadlocks or inconsistences occur. In the SCM solution if the number of participants increases, having a centralized communication (e.g., from tasks to schedulers) offers a lower decentralization level in comparison with other communication solutions [<xref rid="b3-sensors-13-10954" ref-type="bibr">3</xref>], and bottlenecks may occur as well. This disadvantage is because schedulers have to keep track of every state the whole workflow has gone through, in order to handle a failure by for example informing the right successor <italic>A<sub>L</sub></italic>, or re-scheduling tasks' <italic>A<sub>L</sub></italic>s. We consider that the DM solution offers higher monitoring capabilities as the state of task is distributed in a shared space and inconsistences are accessible by schedulers.</p><p>The COM solution introduces the same limitation inherited by the scalability of events. The BPoPS solution allows the monitoring system <italic>to save network and processing resources</italic>. Brokers act as the monitoring entities of tasks, because they already serve them and control their bindings with other tasks' <italic>A<sub>L</sub></italic>. They can properly deal with failures (e.g., by applying the algorithm of Section 3.1.4.) and inform schedulers about the state of tasks using the topic hierarchy presented in Section 3.1.1.</p></sec><sec><label>4.2.</label><title>Evaluation of Communication Solutions</title><p>In this section, we describe a validation scenario for the qualitative evaluation of communication solutions described in Section 4.1. This validation scenario presents a realistic situation of the implementations of the proposed solutions according to the use that is made today of the Internet applications and services. It has been designed for supporting the runtime behavior of the SWf described in Section 2.1. Building this scenario we provide an integral evaluation of the communication solutions including a quantitative comparison based on the performance of each communication solution this scenario. Henceforth, we use the same SWf showed in <xref rid="f1-sensors-13-10954" ref-type="fig">Figure 1</xref> as the input for all the implementations.</p><p>The validation scenario of this SWf consists on a set of A<sub>L</sub> deployed over the Internet in a distributed manner and well-defined and structured administrative domains where: IP multicast is not available, predecessor and successor A<sub>L</sub>s are supported by a Orchestrator node and communicate with the SWf Scheduler/Monitor (in our case the Trident Workflow Workbench) using a Virtual Private Network (VPN) channel, A<sub>L</sub>s bindings and their message exchange are maintained in a private domain and finally, A<sub>L</sub>s are set to be in a static local area network with low addressing movement. Brokers communicate with Orchestrators and the SWf Scheduler and Monitor. <xref rid="f9-sensors-13-10954" ref-type="fig">Figure 9</xref> shows the network topology of the evaluation scenario.</p><p>As we analyzed in Section 4.1, DM-based solutions are suitable for scenarios where SWfs have a high level of re-scheduling, parallelism and dynamic peer topologies. In the evaluation scenario, there are static relationships between peers, in terms of network addressing, and a low level of re-scheduling; therefore: (i) a DM-based solution offers qualitative characteristics that are barely applicable to the evaluation scenario but increase the complexity of SWf management and its implementation. In addition, (ii) the evaluation scenario comprehends administratively-defined and controlled domains that are difficult to maintain and support using a purely distributed P2P approach in current SWf frameworks. Concerning the relationships between predecessor and successor A<sub>L</sub>, DM-based solutions concentrate on delivering data to peers (through P2P paths) and resolving connectivity issues in an unstructured network. The evaluation scenario is set to be in a private and structured network domain, in terms of exposed interfaces, addressing and notification of control events that realize the bindings among predecessor and successor A<sub>L</sub>. Therefore, (iii) even with secure path selection and routing mechanisms, a DM-based solution is less suitable for the evaluation scenario and overheads the communication stack of nodes supporting Orchestrators. In the context of the evaluation scenario and taking into account these three implementation drawbacks of a DM-based solution, we clearly state that its implementation offers disadvantageous qualitative aspects in comparison with the other solutions analyzed in this article: SCM, COM and BPoPS. Therefore, we have focused our efforts into providing a quantitative comparison among SCM, COM and BPoPS implementations, which share the same qualitative characteristics expected for this evaluation scenario.</p><p>In order to normalize the comparison and overcome the differences that can be originated by different implementations and communication models, we set up a common layer for the three implementations. This layer is based on SOAP-HTTP. As we analyze the runtime behavior, we assume that the SWf was previously initialized including the information regarding A<sub>L</sub>' bindings, predecessor/successor A<sub>L</sub>, broker addresses and logic gates.</p><p>We used the Trident Workflow Workbench [<xref rid="b25-sensors-13-10954" ref-type="bibr">25</xref>] as the main framework to <italic>compose, schedule</italic> and <italic>monitor</italic> the SWf execution. It ran over a workstation with a Core i7 1.6 GHz CPU, with 4 GB of RAM, and the 64 bits Windows 7 OS. We started from the fact that A<sub>L</sub>s were already deployed over Orchestrators. We emulated their milestones in terms of inputs/outputs of control events. For this task, we used servers with these characteristics: Core i5 2.0 GHz CPU, 8 GB of RAM and 64 bits Windows 7. Activities' interfaces were implemented in C#. Then, we converted them into Internet Information Service (IIS) Applications; so all the Activities' inputs were bound to SOAP-HTTP bindings and implement the notify SOAP operation. Activities' outputs triggered web actions in brokers. We developed brokers in C# and use similar bindings. Primitives publish, subscribe, un-subscribe were also implemented as SOAP operations.</p><p>The node running Trident was deployed over the Internet as well as brokers and nodes running activities. Brokers and A<sub>L</sub>s were grouped according to the SWf of <xref rid="f1-sensors-13-10954" ref-type="fig">Figure 1</xref>. For implementation purposes A<sub>L</sub>s under the same Local Area Network were executed by the same Orchestrator node, but they continued to use the Web interface to exchange control messages. Concerning the execution, in the SCM implementation, Trident started the execution of each one of the A<sub>L</sub> using the scheduling mechanisms offered by the framework; so there was no broker participation. In the COM implementation, LG were implemented just before the successor A<sub>L</sub>s, and the Trident node only started the execution of A<sub>L</sub>-1 as well as in our solution. In the BPoPS solution we used a recursive subscription to implement the message forwarding between brokers. It was also based on SOAP-HTTP bindings. <xref rid="t2-sensors-13-10954" ref-type="table">Table 2</xref> compares the tree SCM, COM and BPoPS implementations in terms of completion time of the SWf execution, message SOAP payload, memory footprint and CPU utilization. We contemplated in all the solutions the mean, median and standard deviation, except for the message SOAP payload field, because we were using a fixed payload for this test.</p><p>The Completion time of the SWF execution and the Message SOAP payload correspond with the term Information dissemination that we introduced in Section 4.1. In this section, we described the mechanisms that allowed task gaining access to the activation of an A<sub>L</sub> after a control message arrives to SWf participant. The message SOAP payload of line 2 represents the total message payload generated towards the complete execution of the SWf, including the subscription messages needed by COM and BPoPS. Trident is always taken as the reference point for all the measures. It starts the execution in AL-1 and receives the completion message from AL-11 in all the cases.</p><p>We use the Memory and CPU consumption of the SWf, gathered from the Trident, as quantitative metrics. This metrics corresponds with the Workflow monitoring characteristic mentioned in Section 4.1</p><p>From this table we extract the following conclusions:
<list list-type="simple"><list-item><label>-</label><p>Regarding the Completion time of the SWf execution, BPoPS gives an average of 88,234 milliseconds, while the closer solution, the SCM, shows an average of 15,814 milliseconds. As we had different samples for this test, we applied the Mann-Whitney U test [<xref rid="b38-sensors-13-10954" ref-type="bibr">38</xref>] for measuring the Completion time of the SWf execution. The results of this test supported the previous finding (P < 0.01). The P-values indicate that the test result is significant, so we can conclude that BPoPS offers the best performance values for this evaluation scenario.</p></list-item><list-item><label>-</label><p>Concerning the Message SOAP Payload, even if BPoPS requires a higher quantity of messages, this indicator does not affect the overall SWf performance often carried out using local area networks, with low latency and stable MTU, and broadband Internet connections.</p></list-item><list-item><label>-</label><p>Regarding Memory and CPU, due to the simplicity of the connection between the Trident Workflow Monitor and brokers, the BPoPS solution offers a better Memory footprint in the Monitor, an average of 104.550 MB. In terms of CPU consumption our solutions show similar values than the other solutions.</p></list-item></list></p><p>Summarizing, we analyzed the qualitative advantages of the BPoPS in comparison with the DM-based ones. In the evaluation scenario, we demonstrated that the BPoPS implementation offers similar CPU utilization than SCM and COM implementations and ≈10% improvement in the memory footprint. Finally, the test also determined that the BPoPS improves by ≈41% the completion time of the SWf execution.</p></sec></sec><sec><label>5.</label><title>Related Works</title><p>The problem of distributed execution of workflows is an open topic today. Some works [<xref rid="b3-sensors-13-10954" ref-type="bibr">3</xref>] highlight the importance of SWfMS coordination models, not only by their nature (orchestration, choreography or mixed models) but also by the task distribution, delegation algorithms and optimizations over inter-task communication. Other works [<xref rid="b39-sensors-13-10954" ref-type="bibr">39</xref>] compare existing SWf systems, extract the differences between the data and control planes and highly the importance of the control structures and their execution. These control structures are realized by workflow patterns.</p><p>Related to the nature of the workflow, a centralized SWfMS is often not the best solution for executing workflows as large amounts of data are routed through a centralized point which makes the workflow difficult to scale. Some approaches propose decentralized SWfMS which optimize communication by placing each orchestration engine as close as possible to the component service it manages [<xref rid="b18-sensors-13-10954" ref-type="bibr">18</xref>], so, our work targets these kinds of systems.</p><p>For an efficient and scalable distribution of tasks some researches state that a SWf should be divided into different planes, so the participants of the workflow have to deal with different communication methods for data and control. Concerning optimization of distributed workflows, some authors [<xref rid="b40-sensors-13-10954" ref-type="bibr">40</xref>] propose the application of data mining techniques, by carrying out a deep analysis of temporal behavior and then extracting the best way to fragment tasks depending on availability of resources. Other works [<xref rid="b36-sensors-13-10954" ref-type="bibr">36</xref>] resolve task distribution from the perspective of workflow scheduling by elaborating P2P communication models between participants and then finding the efficient mapping of tasks. Our work differs from these approaches as it tackles the message exchange in runtime, rather than the fragmentation process while participants remain decoupled from each other. A hybrid approach for scheduling of workflows is proposed in [<xref rid="b41-sensors-13-10954" ref-type="bibr">41</xref>], by deploying two phases. The first phase is based on clustering and grouping tasks according data links between tasks. The second phase applies a list-based heuristic to fit the allocation of task groups, according to the available resources. This approach reduces the inter-task communication costs and therefore improves the performance of the workflow execution. Nevertheless, our work focuses on how to decouple the control messages depending on the workflow relationships between parties, as we assume that data messages will be delivered using other mechanisms.</p><p>Most of the research marks grid environments as suitable scenarios for SWf execution [<xref rid="b5-sensors-13-10954" ref-type="bibr">5</xref>], and addresses the importance of intermediate communication elements, which in our case are the brokers. Works such as [<xref rid="b42-sensors-13-10954" ref-type="bibr">42</xref>] review the importance of the control plane of workflows and their realization using abstract languages. On this topic workflow patterns have been used [<xref rid="b5-sensors-13-10954" ref-type="bibr">5</xref>] as the source for modeling and monitoring of workflows. Our works goes further and applies the same patterns to enhance the communication between tasks by not only monitoring, but also delivering control events.</p><p>Failures in activities can create deadlocks in workflows, so dependence between activities requires recovery methods in WfMS. In this context of Web Services recovery [<xref rid="b43-sensors-13-10954" ref-type="bibr">43</xref>], Issarny <italic>et al.</italic> proposed the concept of Web Service Composition Action, which allows multiple choices to be selected based on pre-established specifications. Other works such as [<xref rid="b44-sensors-13-10954" ref-type="bibr">44</xref>] define transaction behaviors to compensate for failures based on the workflow skeleton. In our work we also defined recovering mechanisms based on the fact that brokers manage task relationships; so it could be possible to enhance our brokers with these mechanisms. Therefore, depending on the expected runtime conditions, the amount of participants and their communication needs of the SWf, these methods could be plugged-in into our brokers.</p><p>Concerning the communication model, some works [<xref rid="b33-sensors-13-10954" ref-type="bibr">33</xref>] develop web-based mechanisms adapted to SWfs, however, as we presented in previous sections, the communication layer can be improved by a close relationship between messaging and tasks bindings. Balis, <italic>et al.</italic> [<xref rid="b10-sensors-13-10954" ref-type="bibr">10</xref>] propose a taxonomy for monitoring events, based on structured identifiers similar to our topic hierarchy. These events are managed over a Distributed Hash Table infrastructure. We consider our solution complementary [<xref rid="b45-sensors-13-10954" ref-type="bibr">45</xref>] with this kind of infrastructure as our broker enhancements are independent from the underlying network.</p><p>The Publish/Subscribe paradigm has been applied to many scenarios such as scientific workflow interoperability [<xref rid="b46-sensors-13-10954" ref-type="bibr">46</xref>] and recently in M2M communications [<xref rid="b28-sensors-13-10954" ref-type="bibr">28</xref>]. Regarding the event dissemination, Alqaoud <italic>et al.</italic> [<xref rid="b47-sensors-13-10954" ref-type="bibr">47</xref>] demonstrated that a topic-based Pub/Sub model, together with Web-based protocols, improves the SWf interoperability while maintains the expected loosely coupled characteristic required by highly distributed tasks. Our model shares similar characteristics and enhances this interoperability by delegating the complexity of the patterns instantiations to brokers rather than nodes running tasks.</p></sec><sec><label>6.</label><title>Conclusions and Future Works</title><p>In this paper, we have addressed the problem of disseminating control events in the context of scientific workflows. For this purpose, we have proposed a model that uses workflow patterns' foundations and defined the key elements that are needed for the execution of SWf. Our model is complemented with a task interoperability reference model that allows the hierarchical organization of tasks' inputs/output while maintaining the simplicity and portability of a topic-based Pub/Sub language. We have also presented a WSDL definition that allows the configuration of brokers' interfaces, task bindings and the event layer that supports the SWf execution. A reference broker model is also provided as well as procedures brokers can carry out in order to recover relationships between tasks, inside the SWf.</p><p>The proposed model is qualitatively analyzed and compared with current SWf solutions in Section 4, where advantages of the new model are stated. Thus, existing implementation are categorized according to their communication mechanisms and interactions among tasks and schedulers. The qualitative areas were evaluated from the workflow pattern perspective, their triggering conditions and control events generated and disseminated. Therefore, we showed that our model offer the strongest qualitative advantages in terms of information dissemination, tasks decoupling and filtering of control events. We performed an evaluation of a realistic SWf scenario using the Trident Workflow Workbench and demonstrated that our model offered better quantitative advantages in terms of completion time of the SWf execution, maintained a lower memory footprint and similar CPU utilization.</p><p>In future research we will be working on workflow fragmentation issues and mechanisms for supporting patterns that head to directed cyclic graphs. We will work on brokers capable of supporting patterns by employing auto-installable and auto-configurable libraries. Finally, we will also investigate the characterization of workflow internal structures and their optimal instantiation and execution using adapted gossip algorithms and protocols.</p></sec></body><back><ack><p>This work is support by the Ministry of Economy and Competitiveness of Spain, project CALISTA TEC2012-32457. We would like to thank to Diego Martin de Andres for his statistical advice.</p></ack><notes><title>Conflicts of Interest</title><p>The authors declare no conflict of interest.</p></notes><ref-list><title>References</title><ref id="b1-sensors-13-10954"><label>1.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Barker</surname><given-names>A.</given-names></name><name><surname>Van Hemert</surname><given-names>J.</given-names></name></person-group><article-title>Scientific Workflow: A Survey and Research Directions</article-title><conf-name>Proceedings of the 7th International Conference on Parallel Processing and Applied Mathematics, PPAM'07</conf-name><conf-loc>Gdansk, Poland</conf-loc><conf-date>9–12 September 2007</conf-date><fpage>746</fpage><lpage>753</lpage></element-citation></ref><ref id="b2-sensors-13-10954"><label>2.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Grefen</surname><given-names>P.</given-names></name><name><surname>de Vries</surname><given-names>R.</given-names></name></person-group><article-title>A reference architecture for workflow management systems</article-title><source>J. Data Knowledge Eng.</source><year>1998</year><volume>27</volume><fpage>31</fpage><lpage>57</lpage></element-citation></ref><ref id="b3-sensors-13-10954"><label>3.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Lin</surname><given-names>C.</given-names></name><name><surname>Lu</surname><given-names>S.</given-names></name><name><surname>Fei</surname><given-names>X.</given-names></name><name><surname>Chebotko</surname><given-names>A.</given-names></name><name><surname>Pai</surname><given-names>D.</given-names></name><name><surname>Lai</surname><given-names>Z.</given-names></name><name><surname>Fotouhi</surname><given-names>F.</given-names></name><name><surname>Hua</surname><given-names>J.</given-names></name></person-group><article-title>A reference architecture for scientific workflow management systems and the VIEW SOA solution</article-title><source>IEEE Trans. Serv. Comput.</source><year>2009</year><volume>2</volume><fpage>79</fpage><lpage>92</lpage></element-citation></ref><ref id="b4-sensors-13-10954"><label>4.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Yildiz</surname><given-names>U.</given-names></name><name><surname>Guabtni</surname><given-names>A.</given-names></name><name><surname>Ngu</surname><given-names>A.</given-names></name></person-group><article-title>Business versus Scientific Workflows: A Comparative Study</article-title><conf-name>Proceedings of the Congress on Services–I, (SERVICES'09)</conf-name><conf-loc>Bangalore, India</conf-loc><conf-date>21–25 September 2009</conf-date><fpage>340</fpage><lpage>343</lpage></element-citation></ref><ref id="b5-sensors-13-10954"><label>5.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Liu</surname><given-names>X.</given-names></name><name><surname>Dou</surname><given-names>W.</given-names></name><name><surname>Fan</surname><given-names>S.</given-names></name><name><surname>Cai</surname><given-names>S.</given-names></name></person-group><article-title>The Problem-Based Scientific Workflow Design and Performance in Grid Environments</article-title><conf-name>Proceedings of the Fifth International Conference on Grid and Cooperative Computing Workshops (GCCW'06)</conf-name><conf-loc>Washington, DC, USA</conf-loc><conf-date>21–23 October 2006</conf-date><fpage>267</fpage><lpage>274</lpage></element-citation></ref><ref id="b6-sensors-13-10954"><label>6.</label><element-citation publication-type="webpage"><article-title>Data Grid Project</article-title><comment>Available online: <ext-link ext-link-type="uri" xlink:href="http://eu-datagrid.web.cern.ch/eu-datagrid/">http://eu-datagrid.web.cern.ch/eu-datagrid/</ext-link></comment><date-in-citation>(on accessed 10 March 2013)</date-in-citation></element-citation></ref><ref id="b7-sensors-13-10954"><label>7.</label><element-citation publication-type="webpage"><article-title>The Open Science Grid</article-title><comment>Available online: <ext-link ext-link-type="uri" xlink:href="https://www.opensciencegrid.org">https://www.opensciencegrid.org</ext-link></comment><date-in-citation>(on accessed 19 March 2013)</date-in-citation></element-citation></ref><ref id="b8-sensors-13-10954"><label>8.</label><element-citation publication-type="webpage"><article-title>Extreme Science and Engineering Discovery Environment</article-title><comment>Available online: <ext-link ext-link-type="uri" xlink:href="https://www.xsede.org/">https://www.xsede.org/</ext-link></comment><date-in-citation>(on accessed 12 March 2013)</date-in-citation></element-citation></ref><ref id="b9-sensors-13-10954"><label>9.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Ludasher</surname><given-names>B.</given-names></name><name><surname>Altintas</surname><given-names>I.</given-names></name><name><surname>Berkley</surname><given-names>C.</given-names></name><name><surname>Higgins</surname><given-names>D.</given-names></name><name><surname>Jaeger</surname><given-names>E.</given-names></name><name><surname>Jones</surname><given-names>M.</given-names></name><name><surname>Lee</surname><given-names>E.</given-names></name><name><surname>Tao</surname><given-names>J.</given-names></name><name><surname>Zhao</surname><given-names>Z.</given-names></name></person-group><article-title>Scientific workflow management and the Kepler system: Research Articles</article-title><source>Concurr. Comp. Pract. E.</source><year>2006</year><volume>18</volume><fpage>1039</fpage><lpage>1065</lpage></element-citation></ref><ref id="b10-sensors-13-10954"><label>10.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Balis</surname><given-names>B.</given-names></name><name><surname>Bubak</surname><given-names>M.</given-names></name></person-group><article-title>Monitoring infrastructure for Grid scientific workflows</article-title><conf-name>Proceedings of Third Workshop on Workflows in Support of Large-Scale Science (WORKS 2008)</conf-name><conf-loc>Austin, TX, USA</conf-loc><conf-date>17 November 2008</conf-date><fpage>1</fpage><lpage>10</lpage></element-citation></ref><ref id="b11-sensors-13-10954"><label>11.</label><element-citation publication-type="webpage"><article-title>Taverna WfMS</article-title><comment>Available online: <ext-link ext-link-type="uri" xlink:href="http://www.taverna.org.uk/">http://www.taverna.org.uk/</ext-link></comment><date-in-citation>(on accessed 14 March 2013)</date-in-citation></element-citation></ref><ref id="b12-sensors-13-10954"><label>12.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Deelman</surname><given-names>E.</given-names></name><name><surname>Blythe</surname><given-names>J.</given-names></name><name><surname>Gil</surname><given-names>Y.</given-names></name><name><surname>Kesselman</surname><given-names>C.</given-names></name><name><surname>Mehta</surname><given-names>G.</given-names></name><name><surname>Patil</surname><given-names>S.</given-names></name><name><surname>Su</surname><given-names>M.-H.</given-names></name><name><surname>Vahi</surname><given-names>K.</given-names></name><name><surname>Livny</surname><given-names>M.</given-names></name></person-group><article-title>Pegasus: Mapping scientific workflows onto the grid</article-title><source>Lect. Notes Comput. Sci.</source><year>2004</year><volume>3165</volume><fpage>11</fpage><lpage>20</lpage></element-citation></ref><ref id="b13-sensors-13-10954"><label>13.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Missier</surname><given-names>P.</given-names></name><name><surname>Soiland-Reyes</surname><given-names>S.</given-names></name><name><surname>Owen</surname><given-names>S.</given-names></name><name><surname>Tan</surname><given-names>W.</given-names></name><name><surname>Nenadic</surname><given-names>A.</given-names></name><name><surname>Dunlop</surname><given-names>I.</given-names></name><name><surname>Williams</surname><given-names>A.</given-names></name><name><surname>Oinn</surname><given-names>T.</given-names></name><name><surname>Goble</surname><given-names>C.</given-names></name></person-group><article-title>Taverna, Reloaded</article-title><conf-name>Proceedings of the 22nd International Conference on Scientific and Statistical Database Management, (SSDBM'10)</conf-name><conf-loc>Crete, Greece</conf-loc><conf-date>30 June–2 July 2010</conf-date><fpage>471</fpage><lpage>481</lpage></element-citation></ref><ref id="b14-sensors-13-10954"><label>14.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Bethel</surname><given-names>E.W.</given-names></name><name><surname>Shalf</surname><given-names>J.</given-names></name></person-group><article-title>Grid-distributed visualizations using connectionless protocols</article-title><source>IEEE Comput. Graphic. Appl.</source><year>2003</year><volume>23</volume><fpage>51</fpage><lpage>59</lpage></element-citation></ref><ref id="b15-sensors-13-10954"><label>15.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Johnson</surname><given-names>D.</given-names></name><name><surname>Meacham</surname><given-names>K.</given-names></name><name><surname>Kornmayer</surname><given-names>H.</given-names></name></person-group><article-title>A Middleware Independent Grid Workflow Builder for Scientific Applications</article-title><conf-name>Proceedings of the 5th IEEE International Conference on E-Science Workshops</conf-name><conf-loc>Oxford, UK</conf-loc><conf-date>9–11 December 2009</conf-date><fpage>86</fpage><lpage>91</lpage></element-citation></ref><ref id="b16-sensors-13-10954"><label>16.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Li</surname><given-names>G.</given-names></name><name><surname>Muthusamy</surname><given-names>V.</given-names></name><name><surname>Jacobsen</surname><given-names>H.-A.</given-names></name></person-group><article-title>A distributed service-oriented architecture for business process execution</article-title><source>ACM Trans. Web</source><year>2010</year><volume>4</volume><fpage>1</fpage><lpage>33</lpage></element-citation></ref><ref id="b17-sensors-13-10954"><label>17.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Yu</surname><given-names>J.</given-names></name><name><surname>Buyya</surname><given-names>R.</given-names></name></person-group><article-title>A taxonomy of workflow management systems for grid computing</article-title><source>J. Grid Comput</source><year>2005</year><volume>3</volume><fpage>171</fpage><lpage>200</lpage></element-citation></ref><ref id="b18-sensors-13-10954"><label>18.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Fleuren</surname><given-names>T.</given-names></name><name><surname>Gotze</surname><given-names>J.</given-names></name><name><surname>Muller</surname><given-names>P.</given-names></name></person-group><article-title>Workflow Skeletons: Increasing Scalability of Scientific Workflows by Combining Orchestration and Choreography</article-title><conf-name>Proceedings of the Ninth IEEE European Conference on Web Services (ECOWS)</conf-name><conf-loc>Lugano, Switzerland</conf-loc><conf-date>14–16 September 2011</conf-date><fpage>99</fpage><lpage>106</lpage></element-citation></ref><ref id="b19-sensors-13-10954"><label>19.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Van Der Aalst</surname><given-names>W.</given-names></name><name><surname>Ter Hofstede</surname><given-names>A.</given-names></name><name><surname>Kiepuszewski</surname><given-names>B.</given-names></name><name><surname>Barros</surname><given-names>A.</given-names></name></person-group><article-title>Workflow patterns</article-title><source>J. Distrib. Parallel. Datab.</source><year>2003</year><volume>14</volume><fpage>5</fpage><lpage>51</lpage></element-citation></ref><ref id="b20-sensors-13-10954"><label>20.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Alcarria</surname><given-names>R.</given-names></name><name><surname>Robles</surname><given-names>T.</given-names></name><name><surname>Dominguez</surname><given-names>A.</given-names></name><name><surname>Cedeño</surname><given-names>E.</given-names></name></person-group><article-title>Resolving Coordination Challenges in Cooperative Mobile Services</article-title><conf-name>Proceedings of the Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS)</conf-name><conf-loc>Palermo, Italy</conf-loc><conf-date>4–6 July 2012</conf-date><fpage>823</fpage><lpage>828</lpage></element-citation></ref><ref id="b21-sensors-13-10954"><label>21.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Morales</surname><given-names>A.</given-names></name><name><surname>Alcarria</surname><given-names>R.</given-names></name><name><surname>Robles</surname><given-names>T.</given-names></name><name><surname>Cedeño</surname><given-names>E.</given-names></name></person-group><article-title>Improving Cooperativity in a Workflow Coordination Model over a Pub/Sub Network</article-title><conf-name>Proceedings of the 6th International Conference on Ubiquitous Computing and Ambient Intelligence, (UCAmI'12)</conf-name><conf-date>3–5 December 2012</conf-date><fpage>216</fpage><lpage>223</lpage></element-citation></ref><ref id="b22-sensors-13-10954"><label>22.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Ranjan</surname><given-names>R.</given-names></name><name><surname>Rahman</surname><given-names>M.</given-names></name><name><surname>Buyya</surname><given-names>R.</given-names></name></person-group><article-title>A Decentralized and Cooperative Workflow Scheduling Algorithm</article-title><conf-name>Proceedings of the Eighth IEEE International Symposium on Cluster Computing and the Grid (CCGRID)</conf-name><conf-loc>Lyon, France</conf-loc><conf-date>19–22 May 2008</conf-date><fpage>1</fpage><lpage>8</lpage></element-citation></ref><ref id="b23-sensors-13-10954"><label>23.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Eugster</surname><given-names>P.</given-names></name><name><surname>Felber</surname><given-names>P.</given-names></name><name><surname>Guerraqui</surname><given-names>R.</given-names></name><name><surname>Kermarrec</surname><given-names>A.-M.</given-names></name></person-group><article-title>The many faces of publish/subscribe</article-title><source>ACM Comput. Survey (CSUR)</source><year>2003</year><volume>35</volume><fpage>114</fpage><lpage>131</lpage></element-citation></ref><ref id="b24-sensors-13-10954"><label>24.</label><element-citation publication-type="webpage"><article-title>WS-Topics 1.3 OASIS Standard</article-title><comment>Available online: <ext-link ext-link-type="uri" xlink:href="http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-spec-os.pdf">http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-spec-os.pdf</ext-link></comment><date-in-citation>(on accessed 15 March 2013)</date-in-citation></element-citation></ref><ref id="b25-sensors-13-10954"><label>25.</label><element-citation publication-type="webpage"><person-group person-group-type="author"><collab>Project Trident</collab></person-group><article-title>A Scientific Workflow Workbench</article-title><comment>Available online: <ext-link ext-link-type="uri" xlink:href="http://tridentworkflow./codeplex.com/documentation">http://tridentworkflow./codeplex.com/documentation</ext-link></comment><date-in-citation>(on accessed 15 June 2013)</date-in-citation></element-citation></ref><ref id="b26-sensors-13-10954"><label>26.</label><element-citation publication-type="webpage"><article-title>Pubsubhubbub</article-title><comment>Available online: <ext-link ext-link-type="uri" xlink:href="https://code.google.com/p/pubsubhubbub/">https://code.google.com/p/pubsubhubbub/</ext-link></comment><date-in-citation>(on accessed 15 June 2013)</date-in-citation></element-citation></ref><ref id="b27-sensors-13-10954"><label>27.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Pérez-Castillo</surname><given-names>R.</given-names></name><name><surname>Weber</surname><given-names>B.</given-names></name><name><surname>García-Rodríguez de Guzmán</surname><given-names>I.</given-names></name><name><surname>Piattini</surname><given-names>M.</given-names></name><name><surname>Pinggera</surname><given-names>J.</given-names></name></person-group><article-title>Assessing event correlation in non-process-aware information systems</article-title><source>Soft. Syst. Model</source><year>2012</year><pub-id pub-id-type="doi">10.1007/s10270-012-0285-5</pub-id></element-citation></ref><ref id="b28-sensors-13-10954"><label>28.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Morales Dominguez</surname><given-names>A.</given-names></name><name><surname>Robles</surname><given-names>T.</given-names></name><name><surname>Alcarria</surname><given-names>R.</given-names></name><name><surname>Cedeño</surname><given-names>E.</given-names></name></person-group><article-title>A Rendezvous Mobile Broker for Pub/Sub Networks</article-title><conf-name>Proceedings of LNICST, Second International Conference (GreeNets 2012)</conf-name><conf-loc>Gandia, Spain</conf-loc><conf-date>25–26 October 2012</conf-date><fpage>16</fpage><lpage>27</lpage></element-citation></ref><ref id="b29-sensors-13-10954"><label>29.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Campos</surname><given-names>F.</given-names></name><name><surname>Pereira</surname><given-names>J.</given-names></name></person-group><article-title>Gossip-Based Service Coordination for Scalability and Resilience</article-title><conf-name>Proceedings of the ACM Workshop on Middleware for Service Oriented Computing, (MW4SOC)</conf-name><conf-loc>New York, NY, USA</conf-loc><conf-date>1–5 December 2008</conf-date><fpage>55</fpage><lpage>60</lpage></element-citation></ref><ref id="b30-sensors-13-10954"><label>30.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Song</surname><given-names>W.</given-names></name><name><surname>Jiang</surname><given-names>D.</given-names></name><name><surname>Chi</surname><given-names>C-H</given-names></name><name><surname>Jia</surname><given-names>P.</given-names></name><name><surname>Zhou</surname><given-names>X.</given-names></name><name><surname>Zou</surname><given-names>G.</given-names></name></person-group><article-title>Gossip-Based Workload Prediction and Process Model for Composite Workflow Service</article-title><conf-name>Proceedings of World Conference on Services-I</conf-name><conf-loc>Los Angeles, CA, USA</conf-loc><conf-date>6–10 July 2009</conf-date><fpage>607</fpage><lpage>614</lpage></element-citation></ref><ref id="b31-sensors-13-10954"><label>31.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Bradley</surname><given-names>D.</given-names></name><name><surname>Sfiligoi</surname><given-names>I.</given-names></name><name><surname>Padhi</surname><given-names>S.</given-names></name><name><surname>Frey</surname><given-names>J.</given-names></name><name><surname>Tannenbaum</surname><given-names>T.</given-names></name></person-group><article-title>Scalability and interoperability within glide in WMS</article-title><source>J. Phys. Conf. Ser.</source><year>2009</year><volume>219</volume><fpage>062036</fpage></element-citation></ref><ref id="b32-sensors-13-10954"><label>32.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Cao</surname><given-names>J.</given-names></name><name><surname>Javis</surname><given-names>S.A.</given-names></name><name><surname>Saini</surname><given-names>S.</given-names></name><name><surname>Nudd</surname><given-names>G.</given-names></name></person-group><article-title>GridFlow: WorkFlow Management for Grid Computing</article-title><conf-name>Proceedings of the 3rd IEEE /ACM International Symposium on Cluster Computing and the Grid (CCGRID'03)</conf-name><conf-loc>Tokyo, Japan</conf-loc><conf-date>12–15 May 2003</conf-date><fpage>198</fpage><lpage>205</lpage></element-citation></ref><ref id="b33-sensors-13-10954"><label>33.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Perera</surname><given-names>S.</given-names></name><name><surname>Gannon</surname><given-names>D.</given-names></name></person-group><article-title>Enabling Web Service Extensions for Scientific Workflows</article-title><conf-name>Proceedings of Workshop on Workflows in Support of Large-Scale Science, (WORKS'06)</conf-name><conf-loc>Paris, France</conf-loc><conf-date>19–23 June 2006</conf-date><fpage>1</fpage><lpage>10</lpage></element-citation></ref><ref id="b34-sensors-13-10954"><label>34.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Ogasawara</surname><given-names>E.</given-names></name><name><surname>Dias</surname><given-names>J.</given-names></name><name><surname>Oliveira</surname><given-names>D.</given-names></name><name><surname>Rodrigues</surname><given-names>C.</given-names></name><name><surname>Pivotto</surname><given-names>C.</given-names></name><name><surname>Antas</surname><given-names>R.</given-names></name><name><surname>Braganholo</surname><given-names>V.</given-names></name><name><surname>Valduriez</surname><given-names>P.</given-names></name><name><surname>Mattoso</surname><given-names>M.</given-names></name></person-group><article-title>A P2P Approach to Many Tasks Computing for Scientific Workflows</article-title><conf-name>Proceedings of the 9th International Conference on High Performance Computing for Computational Science, (VECPAR'10)</conf-name><conf-loc>Berkeley, CA, USA</conf-loc><conf-date>22–15 June 2010</conf-date><fpage>331</fpage><lpage>339</lpage></element-citation></ref><ref id="b35-sensors-13-10954"><label>35.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Hu</surname><given-names>Y.</given-names></name><name><surname>Bhuyan</surname><given-names>L.N.</given-names></name><name><surname>Feng</surname><given-names>M.</given-names></name></person-group><article-title>Maintaining data consistency in structured P2P systems</article-title><source>IEEE Trans. Paral. Distribut. Syst.</source><year>2012</year><volume>23</volume><fpage>2125</fpage><lpage>2137</lpage></element-citation></ref><ref id="b36-sensors-13-10954"><label>36.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Yang</surname><given-names>Y.</given-names></name><name><surname>Liu</surname><given-names>K.</given-names></name><name><surname>Chen</surname><given-names>J.</given-names></name><name><surname>Lignier</surname><given-names>J.</given-names></name><name><surname>Jin</surname><given-names>H.</given-names></name></person-group><article-title>Peer-to-Peer Based Grid Workflow Runtime Environment of SwinDeW-G</article-title><conf-name>Proceedings of IEEE International Conference on e-Science and Grid Computing</conf-name><conf-loc>Bangalore, India</conf-loc><conf-date>10–13 December 2007</conf-date><fpage>51</fpage><lpage>58</lpage></element-citation></ref><ref id="b37-sensors-13-10954"><label>37.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Medjahed</surname><given-names>B.</given-names></name></person-group><article-title>Dissemination protocols for event-based service-oriented architectures</article-title><source>IEEE Trans. Serv. Comput.</source><year>2008</year><volume>1</volume><fpage>155</fpage><lpage>168</lpage></element-citation></ref><ref id="b38-sensors-13-10954"><label>38.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Mann</surname><given-names>H.B.</given-names></name><name><surname>Whitney</surname><given-names>D.R.</given-names></name></person-group><article-title>On a test of whether one of two random variables is stochastically larger than the other</article-title><source>Ann. Math. Stat.</source><year>1947</year><volume>18</volume><fpage>50</fpage><lpage>60</lpage></element-citation></ref><ref id="b39-sensors-13-10954"><label>39.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Curcin</surname><given-names>V.</given-names></name><name><surname>Ghanem</surname><given-names>M.</given-names></name></person-group><article-title>Scientific Workflow Systems—Can One Size Fit all?</article-title><conf-name>Proceedings of Cairo International Biomedical Engineering Conference, (CIBEC 2008)</conf-name><conf-loc>Cairo, Egypt</conf-loc><conf-date>16–18 December 2008</conf-date><fpage>1</fpage><lpage>9</lpage></element-citation></ref><ref id="b40-sensors-13-10954"><label>40.</label><element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Sun</surname><given-names>S.X.</given-names></name><name><surname>Zeng</surname><given-names>Q.</given-names></name><name><surname>Wang</surname><given-names>H.</given-names></name></person-group><article-title>Process-mining-based workflow model fragmentation for distributed execution</article-title><source>IEEE Trans. Syst. Man Cyber. Part A: Syst. Human</source><year>2011</year><volume>41</volume><fpage>294</fpage><lpage>310</lpage></element-citation></ref><ref id="b41-sensors-13-10954"><label>41.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Tsai</surname><given-names>Y.</given-names></name><name><surname>Huang</surname><given-names>K.</given-names></name><name><surname>Chang</surname><given-names>H.</given-names></name><name><surname>Ko</surname><given-names>J.</given-names></name><name><surname>Wang</surname><given-names>E.</given-names></name><name><surname>Hsu</surname><given-names>C.</given-names></name></person-group><article-title>Scheduling Multiple Scientific and Engineering Workflows through Task Clustering and Best-Fit Allocation</article-title><conf-name>Proceedings of the IEEE Eighth World Congress on Services</conf-name><conf-loc>Honolulu, HI, USA</conf-loc><conf-date>24–29 June 2012</conf-date><fpage>1</fpage><lpage>8</lpage></element-citation></ref><ref id="b42-sensors-13-10954"><label>42.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Wang</surname><given-names>X.</given-names></name><name><surname>Kuster</surname><given-names>U.</given-names></name><name><surname>Resch</surname><given-names>M.</given-names></name></person-group><article-title>A Low-level SDL-based Framework for Efficient Executions of Large-scale Scientific Workflows</article-title><conf-name>Proceedings of the 14th IEEE International Conference on Computational Science and Engineering</conf-name><conf-loc>Dalian, China</conf-loc><conf-date>24–26 August 2011</conf-date><fpage>639</fpage><lpage>644</lpage></element-citation></ref><ref id="b43-sensors-13-10954"><label>43.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Issarny</surname><given-names>V.</given-names></name><name><surname>Tartanoglu</surname><given-names>F.</given-names></name><name><surname>Romanovsky</surname><given-names>A.</given-names></name><name><surname>Levy</surname><given-names>N.</given-names></name></person-group><article-title>Coordinated Forward Error Recovery for Composite Web Services</article-title><conf-name>Proceedings of the 22nd International Symposium on Reliable Distributed Systems</conf-name><conf-loc>Florence, Italy</conf-loc><conf-date>6–18 October 2003</conf-date><fpage>167</fpage><lpage>176</lpage></element-citation></ref><ref id="b44-sensors-13-10954"><label>44.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Bhiri</surname><given-names>S.</given-names></name><name><surname>Perrin</surname><given-names>O.</given-names></name><name><surname>Godart</surname><given-names>C.</given-names></name></person-group><article-title>Ensuring required failure atomicity of composite Web services</article-title><conf-name>Proceedings of the 14th International Conference on World Wide Web, (WWW'05)</conf-name><conf-loc>Chiba, Japan</conf-loc><conf-date>10–15 May 2005</conf-date><fpage>138</fpage><lpage>147</lpage></element-citation></ref><ref id="b45-sensors-13-10954"><label>45.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Li</surname><given-names>W.</given-names></name><name><surname>Vuong</surname><given-names>S.</given-names></name></person-group><article-title>Towards a Scalable Content-Based Publish/Subscribe Service over DHT</article-title><conf-name>Proceedings of IEEE Global Telecommunications Conference, (GLOBECOM 2010)</conf-name><conf-loc>Miami, FL, USA</conf-loc><conf-date>6–10 December 2010</conf-date><fpage>1</fpage><lpage>6</lpage></element-citation></ref><ref id="b46-sensors-13-10954"><label>46.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Li</surname><given-names>G.</given-names></name><name><surname>Muthusamy</surname><given-names>V.</given-names></name><name><surname>Jacobsen</surname><given-names>H.-A.</given-names></name><name><surname>Mankovsky</surname><given-names>S.</given-names></name></person-group><article-title>Decentralized Execution of Event-Driven Scientific Workflows</article-title><conf-name>Proceedings of IEEE Services Computing Workshops (SCW'06)</conf-name><conf-loc>Washington, DC, USA</conf-loc><conf-date>18–22 September 2006</conf-date><fpage>73</fpage><lpage>82</lpage></element-citation></ref><ref id="b47-sensors-13-10954"><label>47.</label><element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Alqaoud</surname><given-names>A.</given-names></name><name><surname>Taylor</surname><given-names>I.</given-names></name><name><surname>Jones</surname><given-names>A.</given-names></name></person-group><article-title>Publish/Subscribe as a Model for Scientific Workflow Interoperability</article-title><conf-name>Proceedings of the 4th Workshop on Workflows in Support of Large-Scale Science, (WORKS'09)</conf-name><conf-loc>Portland, OR, USA</conf-loc><conf-date>16 November 2009</conf-date></element-citation></ref></ref-list></back><floats-group><fig id="f1-sensors-13-10954" position="float"><label>Figure 1.</label><caption><p>Workflow-to-Pub/Sub mapping.</p></caption><graphic xlink:href="sensors-13-10954f1"></graphic></fig><fig id="f2-sensors-13-10954" position="float"><label>Figure 2.</label><caption><p>Topic Hierarchy.</p></caption><graphic xlink:href="sensors-13-10954f2"></graphic></fig><fig id="f3-sensors-13-10954" position="float"><label>Figure 3.</label><caption><p>WSDL interface.</p></caption><graphic xlink:href="sensors-13-10954f3"></graphic></fig><fig id="f4-sensors-13-10954" position="float"><label>Figure 4.</label><caption><p>Reference Broker Architecture.</p></caption><graphic xlink:href="sensors-13-10954f4"></graphic></fig><fig id="f5-sensors-13-10954" position="float"><label>Figure 5.</label><caption><p>Binding recovery pseudocode.</p></caption><graphic xlink:href="sensors-13-10954f5"></graphic></fig><fig id="f6-sensors-13-10954" position="float"><label>Figure 6.</label><caption><p>Workflow messaging.</p></caption><graphic xlink:href="sensors-13-10954f6"></graphic></fig><fig id="f7-sensors-13-10954" position="float"><label>Figure 7.</label><caption><p>Example of SOAP request and response.</p></caption><graphic xlink:href="sensors-13-10954f7"></graphic></fig><fig id="f8-sensors-13-10954" position="float"><label>Figure 8.</label><caption><p>Relationship between patterns, participants and events.</p></caption><graphic xlink:href="sensors-13-10954f8"></graphic></fig><fig id="f9-sensors-13-10954" position="float"><label>Figure 9.</label><caption><p>Network topology of the evaluation scenario.</p></caption><graphic xlink:href="sensors-13-10954f9"></graphic></fig><table-wrap id="t1-sensors-13-10954" position="float"><label>Table 1.</label><caption><p>SWf execution requirements and communication solutions.</p></caption><table frame="hsides" rules="groups"><thead><tr><th align="center" valign="middle" rowspan="1" colspan="1"></th><th align="center" valign="middle" rowspan="1" colspan="1"><bold>Semi-Centralized MesSaging (SCM)</bold></th><th align="center" valign="middle" rowspan="1" colspan="1"><bold>Distributed Messaging ExChange (DM)</bold></th><th align="center" valign="middle" rowspan="1" colspan="1"><bold>Pub/Sub with Channel Optimization Messaging (COM)</bold></th><th align="center" valign="middle" rowspan="1" colspan="1"><bold>Bounded Patterns over Pub/Sub (BPoPS)</bold></th></tr></thead><tbody><tr><td align="left" valign="top" rowspan="1" colspan="1"><bold>Information dissemination</bold></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Sync messaging Async Messaging</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Request-response Async Messaging</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Partial Asynchronous</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Fully Asynchronous</italic></td></tr><tr><td align="left" valign="top" rowspan="1" colspan="1"><bold>Information dispatching and filtering</bold></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Application Level</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Application Level</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Event level</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Event Level</italic></td></tr><tr><td align="left" valign="top" rowspan="1" colspan="1"><bold>Tasks decoupling through workflow patterns</bold></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Partial</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Partial</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Partial</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Complete</italic></td></tr><tr><td align="left" valign="top" rowspan="1" colspan="1"><bold>Flexibility over workflow changes</bold></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Depending on activity-to-activity links</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Depending on Single links</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Depending on number of activities</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Workflow dependent</italic></td></tr><tr><td align="left" valign="top" rowspan="1" colspan="1"><bold>Scalability of events</bold></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Depending on number of activities</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Node dependent</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Pattern dependent</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Topology dependent</italic></td></tr><tr><td align="left" valign="top" rowspan="1" colspan="1"><bold>Workflow monitoring and failure handling</bold></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Semi-centralized</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Shared space</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Distributed – task level</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>Distributed – broker level</italic></td></tr></tbody></table></table-wrap><table-wrap id="t2-sensors-13-10954" position="float"><label>Table 2.</label><caption><p>Quantitative evaluation of the evaluation scenario.</p></caption><table frame="hsides" rules="groups"><thead><tr><th align="center" valign="middle" rowspan="3" colspan="1"></th><th colspan="3" align="center" valign="middle" rowspan="1"><bold>Semi-Centralized Messaging (SCM)</bold></th><th colspan="3" align="center" valign="middle" rowspan="1"><bold>Pub/Sub with Channel Optimization Messaging (COM)</bold></th><th colspan="3" align="center" valign="middle" rowspan="1"><bold>Bounded Patterns over Pub/Sub (BPoPS)</bold></th></tr><tr><th colspan="9" valign="bottom" rowspan="1"><hr></hr></th></tr><tr><th align="center" valign="bottom" rowspan="1" colspan="1">Mean</th><th align="center" valign="bottom" rowspan="1" colspan="1">Median</th><th align="center" valign="bottom" rowspan="1" colspan="1">SD</th><th align="center" valign="bottom" rowspan="1" colspan="1">Mean</th><th align="center" valign="bottom" rowspan="1" colspan="1">Median</th><th align="center" valign="bottom" rowspan="1" colspan="1">SD</th><th align="center" valign="bottom" rowspan="1" colspan="1">Mean</th><th align="center" valign="bottom" rowspan="1" colspan="1">Median</th><th align="center" valign="bottom" rowspan="1" colspan="1">SD</th></tr></thead><tbody><tr><td align="left" valign="top" rowspan="1" colspan="1"><bold>(1) Completion time of the SWf execution (ms)</bold></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>15,181</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>10,537</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>202</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>15,182</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>10,538</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>202</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>8,823</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>8778</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>162</italic></td></tr><tr><td align="left" valign="top" rowspan="1" colspan="1"><bold>(2) Message SOAP payload (bytes)</bold></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>8,041</italic></td><td align="center" valign="middle" rowspan="1" colspan="1">-</td><td align="center" valign="middle" rowspan="1" colspan="1">-</td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>16,510</italic></td><td align="center" valign="middle" rowspan="1" colspan="1">-</td><td align="center" valign="middle" rowspan="1" colspan="1">-</td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>21982</italic></td><td align="center" valign="middle" rowspan="1" colspan="1">-</td><td align="center" valign="middle" rowspan="1" colspan="1">-</td></tr><tr><td align="left" valign="top" rowspan="1" colspan="1"><bold>(3) Memory footprint (MB)</bold></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>117.124</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>117.718</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>3.234</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>119.582</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>119.652</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>1.3976</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>104.550</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>104.773</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>2.740</italic></td></tr><tr><td align="left" valign="top" rowspan="1" colspan="1"><bold>(4) CPU utilization (%)</bold></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>15.069</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>14.739</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>3.941</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>14.993</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>14.965</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>5.729</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>15.538</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>16.102</italic></td><td align="center" valign="middle" rowspan="1" colspan="1"><italic>3.978</italic></td></tr></tbody></table></table-wrap></floats-group></pmc></record>Pour manipuler ce document sous Unix (Dilib)
EXPLOR_STEP=$WICRI_ROOT/Ticri/CIDE/explor/TelematiV1/Data/Pmc/Corpus
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 000573 | SxmlIndent | more
Ou
HfdSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd -nk 000573 | SxmlIndent | more
Pour mettre un lien sur cette page dans le réseau Wicri
{{Explor lien
|wiki= Ticri/CIDE
|area= TelematiV1
|flux= Pmc
|étape= Corpus
|type= RBID
|clé= PMC:3812637
|texte= On the Support of Scientific Workflows over Pub/Sub Brokers
}}
Pour générer des pages wiki
HfdIndexSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/RBID.i -Sk "pubmed:23966191" \
| HfdSelect -Kh $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd \
| NlmPubMed2Wicri -a TelematiV1
| This area was generated with Dilib version V0.6.31. |  |