airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Re: Gateway portal - Airavata client integration
Date Thu, 29 Aug 2013 13:25:11 GMT
Hi Shahbaz,

XBaya as it stands is for gateway developers who would like to test the various aspects of
the Airavata services. I will about to start a discussion on various client interactions and
looks like your questions raise good use cases for these. Lets discuss all these possibilities
and knock them off within next couple of months.

Suresh

On Aug 29, 2013, at 7:37 AM, Shahbaz Memon <m.memon@fz-juelich.de> wrote:

> Thanks for your reply. 
> 
> > The Gateway Developer needs to know how the security works and provides the required
deployment information (like Unicore BES EPR) and associated security (for instance, for XSEDE,
registers the OA4MP token).
> 
> That means gateway developers have to change the interaction characteristics with the
framework if any new provider has special requirements and attributes.
> 
> In the link you mentioned the End user can use GUI and CL to communicate her request
to Airavata. Is XBaya the GUI intended here? and what CL client you are using? Are both or
any of these client interfaces supporting all the capabilities of Airavata's supported providers?
> 
> Thanks.
> 
> Shahbaz
> 
> 
> 
> 
> 
> 
> On Wed, Aug 28, 2013 at 6:13 PM, Suresh Marru <smarru@apache.org> wrote:
> Hi Shahbaz,
> 
> Good question. I think to better understand this problem lets look at it from the perspective
of the three classes of airavata stake holders [1], end users, gateway developers and core
developers.
> 
> The core framework developer adds a provider to GFac, adds the associated security handling
details to Credential Store and ensures the Airavata API has the required mechanisms to pass
the security details.
> 
> The Gateway Developer needs to know how the security works and provides the required
deployment information (like Unicore BES EPR) and associated security (for instance, for XSEDE,
registers the OA4MP token).
> 
> The end users should not change anything and just specify the new resources enabled by
the provider added.
> 
> Does this answer your question?
> 
> Suresh
> 
> [1] - http://airavata.apache.org/architecture/airavata-stakeholders.html
> 
> On Aug 28, 2013, at 10:30 AM, Shahbaz Memon <m.memon@fz-juelich.de> wrote:
> 
> > Hi Devs,
> >
> > Consider a scenario of a science gateway portal that is already using Airavata to
submit remote jobs. Supposedly Airavata (GFac) introduces a new provider say middleware A
and the gateway portal decides to use that provider, does this portal require any changes
in their client code (used to talk to Airavata)? or will it work without any changes as Airavata
abstracts provider related details? how do you deal with provider specific resource and security
requirements?
> >
> > Thanks.
> >
> > Shahbaz
> >
> >
> > ------------------------------------------------------------------------------------------------
> > ------------------------------------------------------------------------------------------------
> > 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
> > ------------------------------------------------------------------------------------------------
> > ------------------------------------------------------------------------------------------------
> >
> > Das Forschungszentrum oeffnet seine Tueren am Sonntag, 29. September, von 10:00
bis 17:00 Uhr: http://www.tagderneugier.de
> 
> 


Mime
View raw message