airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Supun Nakandala <>
Subject Re: Clarification about Registry and Provenance packages in XBaya
Date Fri, 28 Feb 2014 19:03:07 GMT
Hi Saminda,

Thanks for explaining me the history and the current status of XBaya.

Previously by registry and provenance I was referring to the two packages
org.apache.airavata.xbaya.registry and
org.apache.airavata.xbaya.provernance. The main confusion I had previously
was understanding why there is a separate package for provernance data
instead of having only registry package because all these data is stored in
airavata registry.

But after reading the code in those two packages I understood that although
all the data is stored in the Airavata registry, in XBaya,
org.apache.airavata.xbaya.registry package deals only with saving and
retrieving workflows, and  org.apache.airavata.xbaya.provernance package
deals with saving node outputs, reading experiment data etc. What I
understood from this is even though at the bottom level all these data is
stored in the Airavata registry this package separation is done based on
the type of data. Correct me if I am wrong.

The other issue I had was understanding how these registry operations map
to new Airavata thrift API. By going through thrift data models [1] and
thrift API [2] I could understand that these operations does not have a one
to one mapping with the new API but can be achieved by using the data
models and the API calls.

Yet I cannot understand how to use this new thrift API to do the tasks like
add/edit host descriptors, add/edit service descriptors, add/edit workflows
etc which can be done in 0.11 XBaya using the 0.11 API.

Thank you

[1] -;a=blob_plain;f=airavata-api/thrift-interface-

[2] -;a=blob_plain;f=airavata-api/thrift-interface-descriptions/airavataAPI.thrift;hb=HEAD

On Fri, Feb 28, 2014 at 1:35 AM, Saminda Wijeratne <>wrote:

> Hi Supun,
> XBaya is a legacy library which contains both the XBaya UI code and the
> Workflow Interpreter code. Separating them out in to 2 different libraries
> has proven too much of work at the moment. There'll also be some stale
> classes which over the time has lost its use to the system but was not
> purged.
> *XBaya UI features*
> Create/register/edit/delete applications
> Compose/register/edit/delete workflows
> Run workflows
> Monitor workflow execution
> View registry tree
> Amazon tools
> Globus tools
> *Workflow Interpreter*
> Workflow model
> Workflow Interpreter
> Workflow interpreter configuration
> Workflow notification handling
> Component Invokers (dynamic/gfac)
> Utils to manage wsdls, xmls, strings, amazon tasks etc.
> Thus the classes/packages present in the XBaya does not limit to just
> registry or provenance. Infact these which you've spotted may just be sub
> package of a feature grouping (eg: Dialogs : registry login, component
> pallet: application service components). Please be specific on which
> package you meant.
> If you are looking for a starting point in XBaya, start by looking at
> org.apache.airavata.xbaya.XBaya.main(...) method.
> Regards,
> Saminda
> On Thu, Feb 27, 2014 at 3:44 AM, Supun Nakandala <
>> wrote:
>> Hi All,
>> I was trying to understand 0.11 XBaya implementation. There I found two
>> packages namely registry and provenance. According to my knowledge registry
>> is the place where all the persistence data is stored. But I don't
>> understand where provenance is fitting in the application.
>> I would appreciate if someone can provide me an insight on their usage
>> and how they will map to the proposed Airavata 0.12 API.
>> Also I found there are some packages like gfac, globus, modifier,
>> datadrive, interpreter etc which have no usage in other parts of the XBaya
>> application.
>> Thank you
>> -Supun Nakandala

Thank you
Supun Nakandala
Dept. Computer Science and Engineering
University of Moratuwa

View raw message