Hi Shameera, To create a web based UI I don't see an immediate advantage of using JavaScript over a Python API. Because Airavata's API is Thrift (not any language based API) you can generate code for any language (including JavaScript). Anyway most probably you will not use direct Airavata API calls for creating a web UI. I'm also not sure what you exactly mean by JavaScript language as well. If you explain in more detail that would be really helpful.
If you just give a Python API to create workflows, you really don't even need XBaya to create/run workflows. You can create them as scripts and run them from command line. You can debug your workflows written in Python using normal python debuggers. You can generate the XBaya workflow by using the structure you create in Python as well. Then you can use XBaya to monitor the workflow. These things are hard to do with an JavaScript API. As a language also I would pick Python over JavaScript. Thanks, Supun.. On Thu, Oct 16, 2014 at 6:46 PM, Shameera Rathnayaka <shameerai...@gmail.com > 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/ > -- 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
