airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shameera Rathnayaka <shameerai...@gmail.com>
Subject Re: Evaluate Suitable Scientific Workflow Language for Airavata.
Date Thu, 16 Oct 2014 22:46:36 GMT
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 <supun06@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 <
> shameerainfo@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) <
>> alekny7@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 <smarru@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.mattmann@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.mattmann@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 <shameerainfo@gmail.com>
>>>> > Reply-To: "architecture@airavata.apache.org"
>>>> > <architecture@airavata.apache.org>
>>>> > Date: Thursday, September 18, 2014 8:26 AM
>>>> > To: "architecture@airavata.apache.org" <
>>>> architecture@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: supun06@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/

Mime
View raw message