Return-Path: X-Original-To: apmail-airavata-dev-archive@www.apache.org Delivered-To: apmail-airavata-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6219F17F46 for ; Thu, 16 Oct 2014 23:06:41 +0000 (UTC) Received: (qmail 48176 invoked by uid 500); 16 Oct 2014 23:06:41 -0000 Delivered-To: apmail-airavata-dev-archive@airavata.apache.org Received: (qmail 48122 invoked by uid 500); 16 Oct 2014 23:06:41 -0000 Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@airavata.apache.org Delivered-To: mailing list dev@airavata.apache.org Received: (qmail 48095 invoked by uid 99); 16 Oct 2014 23:06:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Oct 2014 23:06:40 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [74.125.82.43] (HELO mail-wg0-f43.google.com) (74.125.82.43) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Oct 2014 23:06:37 +0000 Received: by mail-wg0-f43.google.com with SMTP id m15so4762071wgh.26 for ; Thu, 16 Oct 2014 16:06:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1as5yHURCfNi9+tZ8QZYOizajWEx2Nctuf97AQLpXOY=; b=G+N1QmJ58QXt/h1diFncCkT50xq8saPa0NI81T74RNwXS5KaZ+jRcvpzkMC2+7ti9z EgYGyIieRz5XTtbZKtJ6JLC60IJv/pfOqTEixsMOiSbUbDfmjU9FxVJY9GcamcPwrS6I 0LmiIAybu4pTpMllueTDx1HN/wqTbvYE7XB6JwYNJIRnTBh3xQqr1fzT0NtmtvNt5TNV 2yjEoZmQZR5LfbgWYEqLALVeIgVPMNcaFuHfzVD2+JQQW9iKH08P9FB1XqVW2h8slWiA 2x8Dtog0KQfHtBn4I5vw2vFNeBa1rNqRpPcd2j3v3nA4LOlAJeRh7/JwImHyfQcOFcVR VlTw== X-Gm-Message-State: ALoCoQmjft5W9yLIWJm3Otf02Y+aAHrPRufepNmvO1kbrwJzNPJbe4vZJ/71yt0fyWnu7JAcLc7F MIME-Version: 1.0 X-Received: by 10.180.12.11 with SMTP id u11mr9521494wib.32.1413500775343; Thu, 16 Oct 2014 16:06:15 -0700 (PDT) Received: by 10.194.45.197 with HTTP; Thu, 16 Oct 2014 16:06:15 -0700 (PDT) Received: by 10.194.45.197 with HTTP; Thu, 16 Oct 2014 16:06:15 -0700 (PDT) In-Reply-To: References: <4B3A58EE-54EF-4FE9-A3DA-8EE876299430@apache.org> Date: Thu, 16 Oct 2014 19:06:15 -0400 Message-ID: Subject: Re: Evaluate Suitable Scientific Workflow Language for Airavata. From: Nipurn Doshi To: Airavata Dev Cc: Suresh Marru , "architecture@airavata.apache.org" , "dev@oodt.apache.org" , "Alek Jones (Indiana)" Content-Type: multipart/alternative; boundary=001a11c244929ad9d60505924b23 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c244929ad9d60505924b23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 in previous projects I have worked on using Laravel. Although, it's in PHP. On 16-Oct-2014 6:47 pm, "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 > 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: >> >>> =E2=80=8BHi, >>> >>> First of all thanks everyone for giving valuable inputs. After doing >>> some background search and talking to different people in the Universit= y >>> 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 t= hey >>> asking for a sort of API which they can use to generate the workflows a= nd >>> 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, ins= tead >>> of XML. >>> >>> Airavata community already have started to implement web base GUI. Henc= e >>> 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 us= es >>>> 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 >>>> 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 a= s >>>>> 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_ru= ntime_for_eScience_workflows >>>>> [3] - >>>>> http://www.computer.org/csdl/proceedings/services/2010/4129/00/4129a3= 26.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 >>>>> > Reply-To: "architecture@airavata.apache.org" >>>>> > >>>>> > Date: Thursday, September 18, 2014 8:26 AM >>>>> > To: "architecture@airavata.apache.org" < >>>>> architecture@airavata.apache.org>, >>>>> > dev >>>>> > Subject: Evaluate Suitable Scientific Workflow Language for Airavat= a. >>>>> > >>>>> >> 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, ligh= t >>>>> weight >>>>> >> and real time monitoring support. As you can see above requirement= s >>>>> 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 wi= th >>>>> >> following three existing languages, >>>>> >> 1. YAWL >>>>> >> 2. WS-BPEL >>>>> >> =E2=80=8B3. SIDL >>>>> >> >>>>> >> >>>>> >> In my opinion SIDL is more familiar with scientific domain, >>>>> Radical-SAGA >>>>> >> also uses slightly modified version of SIDL. Other than above thre= e >>>>> >> 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. >>>>> >> >>>>> >> =E2=80=8B >>>>> >> >>>>> >> -- >>>>> >> 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/ > --001a11c244929ad9d60505924b23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

How about I suggest a third option where I have the current = code setup which has access to thrift classes, airavata interface classes a= nd a complete framework ( Laravel ) that supports rest apis to generate jso= n data that we are looking at?

I am suggesting this only because I have done this in previo= us projects I have worked on using Laravel.

Although, it's in PHP.

On 16-Oct-2014 6:47 pm, "Shameera Rathnayak= a" <shameerainfo@gmail.co= m> wrote:
Hi Sup= un,=C2=A0

<= /div>
Considering we = are going to provide web base GUI support and =C2=A0JavaScript is a well-kn= own client side language, I would select JavaScript over Python. I am not m= uch familiar with Python, so would like to know the advantages we get by se= lecting python here.=C2=A0


Thanks,= =C2=A0
Shameera= .

On T= hu, Oct 16, 2014 at 6:30 PM, Supun Kamburugamuva <supun06@gmail.com>= ; wrote:
Hi Shame= era,

Why you prefer JavaScript over a language like Pyth= on?

Thanks,
Supun..

On Thu, Oct 16, = 2014 at 6:25 PM, Shameera Rathnayaka <shameerainfo@gmail.com><= /span> wrote:
=E2=80=8BHi,=C2=A0

First of all thanks everyone for giv= ing valuable inputs. After doing some background search and talking to diff= erent 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 workflo= ws. Indirectly what they asking for a sort of API which they can use to gen= erate the workflows and run it. Correct me if i am wrong here.

As most of above replies depict, =C2= =A0if 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 bas= e GUI. Hence introducing a JSON base JavaScript API would be great help. WD= YT?=C2=A0

<= /div>
Thanks,=C2=A0
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 J= SON to describe what happens during workflow execution:=C2=A0https://www.ng.bluemix.net/docs/#services/workflow/index.html= #coewf002

HTH,

Alek
<= div class=3D"gmail_extra">

On Thu, = Sep 18, 2014 at 1:54 PM, Suresh Marru <smarru@apache.org> wr= ote:
Hi Chris,

Great to hear OODT community will be interested in adopting a JSON based wo= rkflow language and potentially a web based composer as well. Airavata prev= iously had BPEL support initially through a home grown implementation [1] b= y Alek Slominski and later through Apache ODE [2]. Also a white paper [3] b= y 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 f= low patterns in business workflows.

It will be great if we can all compile a list of potential candidates and h= ack them through.

Suresh
[1] - http://link.springer.com/chapter/10.1007%2F= 978-1-84628-757-2_14#page-1
[2] - http://www.acade= mia.edu/1485773/Experience_with_adapting_a_WS-BPEL_runtime_for_eScience_wor= kflows
[3] - http://www.computer.org/csdl/proceedin= gs/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 specifi= c
> 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<= br> > 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:=C2=A0 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 <d= ev@airavata.apache.org>
> Subject: Evaluate Suitable Scientific Workflow Language for Airavata.<= br> >
>> Hi All,
>>
>> As we all know Airavata has its own workflow language call XWF. Wh= en XWF
>> was introduced, main focus points are interoperability and convert= ibility.
>> But with years of experience it is convinced that above requiremen= ts 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 ind= ustry
>> and
>> find out pros and cons, at the end of this evaluation we need to c= ome up
>> with idea how we should improve Airavata workflow language, either= we can
>> improve existing XWF language, totally change to a new language av= ailable
>> in industry or write a new light weight language. Basic requiremen= ts that
>> we expect from new improvement are, high usability, flexible, ligh= t weight
>> and real time monitoring support. As you can see above requirement= s 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 wi= th
>> following three existing languages,
>> 1. YAWL <http://www.yawlfoundation.org/>
>> 2. WS-BPEL
>> =E2=80=8B3. SIDL
>> <http://computation.llnl.gov/casc/compone= nts/index.html#page=3Dhome>
>>
>> In my opinion SIDL is more familiar with scientific domain, Radica= l-SAGA
>> also uses slightly modified version of SIDL. Other than above thre= e
>> languages we can come up with simple workflow language base on jso= n(or
>> yaml) which support all our requirements for some extends.
>>
>> It would be grate if I can get more input regarding the $Subject f= orm the
>> airavata community. You all are more than welcome to provide any t= ype of
>> suggestions.
>>
>> Thanks,
>> Shameera.
>>
>> =E2=80=8B
>>
>> --
>> Best Regards,
>> Shameera Rathnayaka.
>>
>> email: shameera AT apache.org , shameerainfo AT gmail.com
>> Blog : http://shameerarathnayaka.blogspot.com/




--
The best way to predict the fut= ure is to invent it - Alan Kay



--
Best Regards= ,
Shameera= Rathnayaka.

email: shameera AT apache.org , shameerainfo AT gmail.com
Blog : http://shameerarat= hnayaka.blogspot.com/



<= /div>--
Supun Kamburugamuva
Member, Ap= ache Software Foundation; http://www.apache.org
E-mail: supun06@gmail.com; =C2=A0Mobile: +1 812 369 6= 762
Blog: h= ttp://supunk.blogspot.com




--
Best Regards= ,
Shameera= Rathnayaka.

email: shameera AT apache.org , shameerainfo AT gmail.com
Blog : http://shameerarat= hnayaka.blogspot.com/
--001a11c244929ad9d60505924b23--