I prefer python myself, but if the API is clean, it should be usable from a large number of languages on the client side.
On Thu, Oct 16, 2014 at 06:46:36PM -0400, Shameera Rathnayaka wrote: > Hi Supun, > > Considering we are going to provide web base GUI support and JavaScript is > a well-known client side language, I would select JavaScript over Python. I > am not much familiar with Python, so would like to know the advantages we > get by selecting python here. > > > Thanks, > Shameera. > > On Thu, Oct 16, 2014 at 6:30 PM, Supun Kamburugamuva <supu...@gmail.com> > wrote: > > > Hi Shameera, > > > > Why you prefer JavaScript over a language like Python? > > > > Thanks, > > Supun.. > > > > On Thu, Oct 16, 2014 at 6:25 PM, Shameera Rathnayaka < > > shameerai...@gmail.com> wrote: > > > >> ​Hi, > >> > >> First of all thanks everyone for giving valuable inputs. After doing some > >> background search and talking to different people in the University who has > >> used different workflow languages, I myself convinced that introducing an > >> another workflow language is not what actually they need. By changing > >> exiting workflow language to another will not solve problems. What they > >> asking is a easy way to construct the workflows. Indirectly what they > >> asking for a sort of API which they can use to generate the workflows and > >> run it. Correct me if i am wrong here. > >> > >> As most of above replies depict, if we can get a simple API, as an > >> example, for a web based application, JavaScript API would be a good > >> solution, and probably JSON would be a good candidate for language, instead > >> of XML. > >> > >> Airavata community already have started to implement web base GUI. Hence > >> introducing a JSON base JavaScript API would be great help. WDYT? > >> > >> Thanks, > >> Shameera. > >> > >> > >> On Fri, Sep 19, 2014 at 5:01 PM, Aleksander Slominski (NY) < > >> alek...@gmail.com> wrote: > >> > >>> Hi, > >>> > >>> it is not dataflow instead focused on orchestrating REST services but > >>> you may find it useful datapoint - we created worfklow service that uses > >>> natively JavaScript and JSON to describe what happens during workflow > >>> execution: > >>> https://www.ng.bluemix.net/docs/#services/workflow/index.html#coewf002 > >>> > >>> HTH, > >>> > >>> Alek > >>> > >>> On Thu, Sep 18, 2014 at 1:54 PM, Suresh Marru <sma...@apache.org> wrote: > >>> > >>>> Hi Chris, > >>>> > >>>> Great to hear OODT community will be interested in adopting a JSON > >>>> based workflow language and potentially a web based composer as well. > >>>> Airavata previously had BPEL support initially through a home grown > >>>> implementation [1] by Alek Slominski and later through Apache ODE [2]. > >>>> Also > >>>> a white paper [3] by Alek on this topic is an interesting read. > >>>> > >>>> I am of the same opinion that we should adopt something more modern as > >>>> the challenges from scientific workflows seems to be converging with the > >>>> data flow patterns in business workflows. > >>>> > >>>> It will be great if we can all compile a list of potential candidates > >>>> and hack them through. > >>>> > >>>> Suresh > >>>> [1] - > >>>> http://link.springer.com/chapter/10.1007%2F978-1-84628-757-2_14#page-1 > >>>> [2] - > >>>> http://www.academia.edu/1485773/Experience_with_adapting_a_WS-BPEL_runtime_for_eScience_workflows > >>>> [3] - > >>>> http://www.computer.org/csdl/proceedings/services/2010/4129/00/4129a326.pdf > >>>> > >>>> > >>>> On Sep 18, 2014, at 1:15 PM, Mattmann, Chris A (3980) < > >>>> chris.a.mattm...@jpl.nasa.gov> 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: chris.a.mattm...@nasa.gov > >>>> > 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 <shameerai...@gmail.com> > >>>> > Reply-To: "architect...@airavata.apache.org" > >>>> > <architect...@airavata.apache.org> > >>>> > Date: Thursday, September 18, 2014 8:26 AM > >>>> > To: "architect...@airavata.apache.org" < > >>>> architect...@airavata.apache.org>, > >>>> > dev <dev@airavata.apache.org> > >>>> > 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/ > >>>> > >>>> > >>> > >>> > >>> -- > >>> The best way to predict the future is to invent it - Alan Kay > >>> > >> > >> > >> > >> -- > >> Best Regards, > >> Shameera Rathnayaka. > >> > >> email: shameera AT apache.org , shameerainfo AT gmail.com > >> Blog : http://shameerarathnayaka.blogspot.com/ > >> > > > > > > > > -- > > Supun Kamburugamuva > > Member, Apache Software Foundation; http://www.apache.org > > E-mail: supu...@gmail.com; Mobile: +1 812 369 6762 > > Blog: http://supunk.blogspot.com > > > > > > > -- > Best Regards, > Shameera Rathnayaka. > > email: shameera AT apache.org , shameerainfo AT gmail.com > Blog : http://shameerarathnayaka.blogspot.com/
