dev@airavata.apache.org
Cc: Alek Jones (Indiana) alek...@gmail.com, Suresh Marru
sma...@apache.org, architect...@airavata.apache.org
architect...@airavata.apache.org, d...@oodt.apache.org
d...@oodt.apache.org
Subject: Re: Evaluate Suitable Scientific Workflow Language
...@oodt.apache.org
d...@oodt.apache.org
Subject: Re: Evaluate Suitable Scientific Workflow Language for
Airavata.
Once we had an offline discussion about the Airavata Workflow
language
(with Milinda, Saliya and Shameera). In that discussion one thing
came
out
was why we need
Subject: Re: Evaluate Suitable Scientific Workflow Language for
Airavata.
Once we had an offline discussion about the Airavata Workflow
language
(with Milinda, Saliya and Shameera). In that discussion one
thing came
out
was why we need to invent a different language when a simple
To: dev dev@airavata.apache.org
Cc: Alek Jones (Indiana) alek...@gmail.com, Suresh Marru
sma...@apache.org, architect...@airavata.apache.org
architect...@airavata.apache.org, d...@oodt.apache.org
d...@oodt.apache.org
Subject: Re: Evaluate Suitable Scientific Workflow
...@airavata.apache.org, d...@oodt.apache.org
d...@oodt.apache.org
Subject: Re: Evaluate Suitable Scientific Workflow Language for
Airavata.
Once we had an offline discussion about the Airavata Workflow
language
(with Milinda, Saliya and Shameera). In that discussion one thing
Subject: Re: Evaluate Suitable Scientific Workflow Language for Airavata.
Once we had an offline discussion about the Airavata Workflow language
(with Milinda, Saliya and Shameera). In that discussion one thing came
out
was why we need to invent a different language when a simple library
like
...@airavata.apache.org
architect...@airavata.apache.org, d...@oodt.apache.org
d...@oodt.apache.org
Subject: Re: Evaluate Suitable Scientific Workflow Language for
Airavata.
Once we had an offline discussion about the Airavata Workflow language
(with Milinda, Saliya and Shameera
@airavata.apache.org
Cc: Alek Jones (Indiana) alek...@gmail.com, Suresh Marru
sma...@apache.org, architect...@airavata.apache.org
architect...@airavata.apache.org, d...@oodt.apache.org
d...@oodt.apache.org
Subject: Re: Evaluate Suitable Scientific Workflow Language for Airavata.
Once we had
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
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
Once we had an offline discussion about the Airavata Workflow language
(with Milinda, Saliya and Shameera). In that discussion one thing came out
was why we need to invent a different language when a simple library like
Python will full fill of Airavata requirements.
There are many benefits in
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,
Hi,
How about I suggest a third option where I have the current code setup
which has access to thrift classes, airavata interface classes and a
complete framework ( Laravel ) that supports rest apis to generate json
data that we are looking at?
I am suggesting this only because I have done this
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
...@gmail.com, Suresh Marru
sma...@apache.org, architect...@airavata.apache.org
architect...@airavata.apache.org, d...@oodt.apache.org
d...@oodt.apache.org
Subject: Re: Evaluate Suitable Scientific Workflow Language for Airavata.
Once we had an offline discussion about the Airavata Workflow language
One factor that should be included in the group's deliberations
on adding a workflow language to the other things in OODT
is the impact on long-term maintenance. While there's a lot
of enthusiasm in the developer community right now, we need
to think about what happens when development turns into
to start.
Mark
From: Bruce Barkstrom [mailto:brbarkst...@gmail.com]
Sent: Friday, September 19, 2014 9:29 AM
To: d...@oodt.apache.org
Cc: architect...@airavata.apache.org; dev
Subject: Re: Evaluate Suitable Scientific Workflow Language for Airavata.
One factor that should be included in the group's
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:
Hi Shameera,
This is a very good discussion. Just a quick comment that you do not need to
restrict to scientific languages. I think we should also look into workflow
languages used by workflow tools in big data and cloud worlds.
Suresh
On Sep 18, 2014, at 11:26 AM, Shameera Rathnayaka
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
Is there a list of graphical BEL workflow tools?
On Thursday, September 18, 2014, 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
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
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
23 matches
Mail list logo
