Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@airavata.apache.org
Received-SPF: pass (athena.apache.org: domain of glahiru@gmail.com designates
 209.85.212.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAZ-arACw3_tQWx1JrfnsoJMh139pfJkhLnN7G5a_T1QYdw1Aw@mail.gmail.com>
References: <CD46609D.B66BD%chris.a.mattmann@jpl.nasa.gov>
	<1B3C10EB-FFB0-46F0-B773-6A8D816C489E@apache.org>
	<CAJEo2dHdiKveCO0WHKNuGv3JPonA9=Dyn3D5m4K=Q0PymLRNUg@mail.gmail.com>
	<CAKq9_6L84WtQn3tutNaUa4WoJUV-GYD_FQtKQhzoLeAtTgmHUw@mail.gmail.com>
	<CAAZ-arACw3_tQWx1JrfnsoJMh139pfJkhLnN7G5a_T1QYdw1Aw@mail.gmail.com>
Date: Tue, 19 Feb 2013 09:10:46 -0500
Message-ID: 
 <CAKq9_6+jqs0FS+f8LhNX4GLSA246SAeEVKOSZyUVJt9xEMD3kA@mail.gmail.com>
Subject: Re: Proposal To Use Apache OODT products as input to Apache Airavata
 Workflows and staging product files into node where execution happens
From: Lahiru Gunathilake <glahiru@gmail.com>
To: dev@airavata.apache.org
Cc: "dev@oodt.apache.org" <dev@oodt.apache.org>
Content-Type: multipart/alternative; boundary=089e012280fc72ecc904d6146877

--089e012280fc72ecc904d6146877
Content-Type: text/plain; charset=ISO-8859-1

Hi Shabhaz,

Yes, I am about to do that, I just have one more task to finish this work,
once I am done, will remove the old code from trunk.

Regards
Lahiru

On Tue, Feb 19, 2013 at 6:28 AM, Shahbaz Memon <m.memon@fz-juelich.de>wrote:

> > If you want to understand the new architecture by looking in to the code,
> > please just refer the package org.apache.airavata.gfac, do not refer any
> of
> > the classes in org.apache.airavata.core.gfac.
>
> IMHO the unused or outdated code should be moved to any temporary
> branch, so that people checking-out trunk would get the actual/latest
> source of the architecture realization. In that sense it will not be a
> problem for devs if later the outdated code is reused.
>
> Cheers,
>
> Shahbaz
>
> On Mon, Feb 18, 2013 at 8:59 PM, Lahiru Gunathilake <glahiru@gmail.com>
> wrote:
> > Hi Sanjaya,
> >
> > If you want to understand the new architecture by looking in to the code,
> > please just refer the package org.apache.airavata.gfac, do not refer any
> of
> > the classes in org.apache.airavata.core.gfac.
> >
> > Best place to start with is referring is from test classes
> > (LocalProviderTest,GramProviderTest), from tehre you can start looking in
> > to GFacAPI class and see how to execution is flawing.
> >
> > if you have further questions please post on the list and more than happy
> > to help. I will be doing some documentation about the architecture, once
> I
> > am done, will post in to the list. And we will be having an architecture
> > review this week, so please watch the mailing list, if possible please
> try
> > to join us.
> >
> > Regards
> > Lahiru
> >
> > On Mon, Feb 18, 2013 at 1:25 PM, Sanjaya Medonsa <sanjayamrt@gmail.com
> >wrote:
> >
> >> Thanks Suresh and Chris! It seems I am moving on the correct path. I
> have
> >> followed the email thread on improved GFac architecture. Though I am not
> >> entirely clear on the improved GFac architecture, proposed integration
> with
> >> OODT is primarily based on the GFac extension, PreExecustionChain, which
> >> has not been modified with the Architecture improvements (As per one of
> the
> >> replies from Lahiru, output extension is supported with new
> Architecture. I
> >> assume input extension is also supported).
> >>
> >> I have looked into provenance manager and related implementation. Still
> I
> >> am unclear how Airavata support provenance aware work flow processing.
> >>
> >> Best Regards,
> >> Sanjaya
> >>
> >> On Mon, Feb 18, 2013 at 6:35 AM, Suresh Marru <smarru@apache.org>
> wrote:
> >>
> >> > Hi Sanjaya,
> >> >
> >> > This sounds very exciting. Both Airavata and OODT projects have good
> >> > synergies and have been long looking for volunteers who can bridge
> them
> >> > both. Please do not hesitate to ask any questions to either or both
> the
> >> dev
> >> > lists. The more engaged you are, you will find use cases and feedback
> >> which
> >> > should help your MSc project.
> >> >
> >> > Your plan sounds good. If you are following dev list, you may have
> >> > noticed, the GFac architecture has been improved to properly support
> this
> >> > kind of handler architecture.
> >> >
> >> > You may also want to look at Airavata Registry API which has
> organically
> >> > emerged with the need, but can greatly benefit for OODT's provenance
> >> > capabilities.
> >> >
> >> > Suresh
> >> >
> >> > On Feb 17, 2013, at 1:25 PM, "Mattmann, Chris A (388J)" <
> >> > chris.a.mattmann@jpl.nasa.gov> wrote:
> >> >
> >> > > +1, sounds like a great idea Sanjaya!
> >> > >
> >> > > I'm copying dev@oodt so they can be in the conversation too.
> >> > >
> >> > > Cheers,
> >> > > Chris
> >> > >
> >> > > On 2/17/13 10:22 AM, "Sanjaya Medonsa" <sanjayamrt@gmail.com>
> wrote:
> >> > >
> >> > >> Hi Dev Team,
> >> > >> As I have posted previously, I am working on a Apache Airavata +
> >> Apache
> >> > >> OODT integration as my MSc project. Following is one of the
> possible
> >> > >> integration to leverage Apache OODT file management capability into
> >> > Apache
> >> > >> Airavata. Please review the proposal and let me know your feedback.
> >> > >>
> >> > >> Proposal To Use Apache OODT products as input to Apache Airavata
> >> > Workflows
> >> > >> and staging product files into node where execution happens
> >> > >>
> >> >
> >>
> ==========================================================================
> >> > >> ==============================
> >> > >> 1. Introduce "Apache OODT Product" as a new GFacParameterType. New
> >> > "Apache
> >> > >> OODT Product" input type can sepcify "Product ID" or "File Path to
> >> > >> Product"
> >> > >> as an input to Apache Airavata workflows.
> >> > >> 2. Introduce new PreExecuteChain to retrieve Apache OODT Products
> from
> >> > >> File
> >> > >> Manager Server managed using Apache OODT.
> >> > >> 1. Using Apache OODT File Manager componenet transfer Product from
> >> > Server
> >> > >> to input directory of the application as configured using XBaya-GUI
> >> > under
> >> > >> advanced configuration. (Here the assumption is that Products are
> >> > >> accesible
> >> > >> through Apache OODT File Manager server)
> >> > >> 2. Finally reset the input value to local file path. I think we can
> >> > remove
> >> > >> the OODT Product parameter from invocation context and add new file
> >> > >> parameter with value set to 'local path of the transferred
> product'. I
> >> > am
> >> > >> not quite sure what are the implications of changing input
> parameter
> >> > type
> >> > >> during the execution.
> >> > >>
> >> > >> Similar approach has been implemented for GridFTP and HTTP.
> >> > >>
> >> > >> Best Regards,
> >> > >> Sanjaya
> >> > >
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > System Analyst Programmer
> > PTI Lab
> > Indiana University
>
>
>
> ------------------------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> Prof. Dr. Sebastian M. Schmidt
>
> ------------------------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------------------------
>


-- 
System Analyst Programmer
PTI Lab
Indiana University

--089e012280fc72ecc904d6146877--