airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Supun Kamburugamuva <supu...@gmail.com>
Subject Re: Evaluate Suitable Scientific Workflow Language for Airavata.
Date Thu, 16 Oct 2014 22:30:53 GMT
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

Mime
View raw message