Can you make a copy of your IEEE article available without the paywall? Thanks.
Bruce B. On Thu, Sep 18, 2014 at 2:54 PM, Lavanya Ramakrishnan <[email protected] > wrote: > Here is my 2c - > > I think it is important to try and understand what your users are going to > do with workflow and what kind of language they are used to > (domain-specific, functional, etc). They are processes called user-centered > design processes you can use to do this or do at a minimum an informal > study. > > A couple of years ago, we did an introspection on why all the existing > workflow tools didn't have the uptake we had assumed it would. I have been > part of a half dozen different tools over my career. We have since launched > a project called Tigres - http://tigres.lbl.gov/ where we have learned a > lot due to using a user-centered design approach. We have an IEEE eScience > paper on our initial work - which you might find interesting. I am also > happy to share more details on Tigres and/or the process. > > Lavanya > > > > > > On Thu, Sep 18, 2014 at 10:53 AM, BW <[email protected]> wrote: > > > Is there a list of graphical BEL workflow tools? > > > > On Thursday, September 18, 2014, Mattmann, Chris A (3980) < > > [email protected]> wrote: > > > > > Hi Guys, > > > > > > I've been interested in this too - we don't per have a specific > > > OODT workflow language, but we specific workflows using XML, and > > > other configuration (we are also thinking of moving to JSON for > > > this). > > > > > > In the past I've also looked at YAWL and BPEL - both seem complex > > > to me. > > > > > > I wonder at the end of the day if we should adopt something more > > > modern like PIG or some other data flow type of language (PIG > > > is really neat). > > > > > > Cheers, > > > Chris > > > > > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > Chris Mattmann, Ph.D. > > > Chief Architect > > > Instrument Software and Science Data Systems Section (398) > > > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > > Office: 168-519, Mailstop: 168-527 > > > Email: [email protected] <javascript:;> > > > WWW: http://sunset.usc.edu/~mattmann/ > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > Adjunct Associate Professor, Computer Science Department > > > University of Southern California, Los Angeles, CA 90089 USA > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Shameera Rathnayaka <[email protected] <javascript:;>> > > > Reply-To: "[email protected] <javascript:;>" > > > <[email protected] <javascript:;>> > > > Date: Thursday, September 18, 2014 8:26 AM > > > To: "[email protected] <javascript:;>" < > > > [email protected] <javascript:;>>, > > > dev <[email protected] <javascript:;>> > > > Subject: Evaluate Suitable Scientific Workflow Language for Airavata. > > > > > > >Hi All, > > > > > > > >As we all know Airavata has its own workflow language call XWF. When > XWF > > > >was introduced, main focus points are interoperability and > > convertibility. > > > >But with years of experience it is convinced that above requirements > are > > > >not really useful when we come to real world use cases. And XWF is XML > > > >based bulky language where we attache WSDLs and Workflow image it > self. > > > >But > > > >with the recent changes WSDL part is being removed from XWF. > > > > > > > >It is worth to evaluate handy Scientific workflow languages in > industry > > > >and > > > >find out pros and cons, at the end of this evaluation we need to come > up > > > >with idea how we should improve Airavata workflow language, either we > > can > > > >improve existing XWF language, totally change to a new language > > available > > > >in industry or write a new light weight language. Basic requirements > > that > > > >we expect from new improvement are, high usability, flexible, light > > weight > > > >and real time monitoring support. As you can see above requirements > are > > > >not > > > >direct comes with workflow languages but we need workflow language > which > > > >help to support above requirements. > > > > > > > >After reading few papers and googling, initially i have come up with > > > >following three existing languages, > > > >1. YAWL <http://www.yawlfoundation.org/> > > > >2. WS-BPEL > > > >3. SIDL > > > ><http://computation.llnl.gov/casc/components/index.html#page=home> > > > > > > > >In my opinion SIDL is more familiar with scientific domain, > Radical-SAGA > > > >also uses slightly modified version of SIDL. Other than above three > > > >languages we can come up with simple workflow language base on json(or > > > >yaml) which support all our requirements for some extends. > > > > > > > >It would be grate if I can get more input regarding the $Subject form > > the > > > >airavata community. You all are more than welcome to provide any type > of > > > >suggestions. > > > > > > > >Thanks, > > > >Shameera. > > > > > > > > > > > > > > > >-- > > > >Best Regards, > > > >Shameera Rathnayaka. > > > > > > > >email: shameera AT apache.org , shameerainfo AT gmail.com > > > >Blog : http://shameerarathnayaka.blogspot.com/ > > > > > > > > >
