Have you guys considered using JCC [1] as a means to expose the workflow API currently in Java as a Python API?
We are exploring its use in OODT, and we have already created a Tika [2] JCC-based python API. Cheers, Chris [1] http://lucene.apache.org/pylucene/jcc/ [2] http://github.com/chrismattmann/tika-python/ ------------------------ Chris Mattmann chris.mattm...@gmail.com -----Original Message----- From: Supun Kamburugamuva <supu...@gmail.com> Reply-To: <d...@oodt.apache.org> Date: Thursday, October 16, 2014 at 3:43 PM 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 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 >Python will full fill of Airavata requirements. > >There are many benefits in using a Python library as the API for >controlling Airavata workflows. > >1. It is a library, gives the ultimate control over the execution and it >can be simpler than any domain specific language that we can come with >like >XML, JSON etc >2. Most people use python and can learn it easily than any Domain specific >language >3. You can easily create a Python library for Airavata because all the >APIs >are thrift based. >4. If you design the constructs correctly you can plug an XBaya. > >Any thoughts? > >Thanks, >Supun.. > > >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_run >>>>>time_for_eScience_workflows >>>>> [3] - >>>>> >>>>>http://www.computer.org/csdl/proceedings/services/2010/4129/00/4129a32 >>>>>6.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 >> >> > > >-- >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
