airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Wijeratne <samin...@gmail.com>
Subject Re: Data structure for Airavata registry data
Date Tue, 04 Sep 2012 22:46:53 GMT
On Tue, Sep 4, 2012 at 5:05 PM, Chathuri Wimalasena <kamalasini@gmail.com>wrote:

> Hi All,
>
> Following is the updated structure after the discussion we had regarding
> the $subject.
>
> gateway *
>   |- descriptors *
>   |- published workflows *
>   |- users *
>   |       |- workspace
>   |       |      |- workflows
>   |       |      |- projects *
>   |       |             |- experiments *
>   |       |
>   |
>   |
>   |
>   |
>   |- name
>   |- owner
>   |
>   |
>
> According to above structure, database table structure is also changed as
> below.
>
> Gateway
>   gateway_ID
>   gateway_name
>
> Users
>   user_ID
>   user_name
>   password
>
> Projects
>   project_ID
>   gateway_ID
>   project_name
>
> Published_Workflow
>   gateway_ID
>   workflow_name
>   version
>   content
>   published_date
>
> User_Workflow
>   project_ID
>   user_ID
>   workflow_name
>   last_update_date
>
> Host_Descriptor
>   gateway_ID
>   host_descriptor_ID
>   host_descriptor_xml
>
> Service_Descriptor
>   gateway_ID
>   service_descriptor_ID
>   service_descriptor_xml
>
> Application_Descriptor
>   gateway_ID
>   application_descriptor_ID
>   service_descriptor_ID
>   host_descriptor_ID
>   application_descriptor_xml
>
> Experiment
>   project_ID
>   user_ID
>   experiment_ID
>   submitted_date
>
> New Registry API was committed under r1380866 and the class name is
> AiravataRegistry2<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/AiravataRegistry2.java>[1]
 which implements four interfaces
> as DescriptorRegistry<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/DescriptorRegistry.java>[2],
> ProjectsRegistry<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/ProjectsRegistry.java>[3],
> PublishedWorkflowRegistry<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/PublishedWorkflowRegistry.java>[4]
> and UserWorkflowRegistry<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/UserWorkflowRegistry.java>[5].
>

Please give your suggestions and feedback.
>

This new API is up for a quick review. Each interface is responsible for
handling different part of the data. The
AiravataProvenanceRegistry<https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/AiravataProvenanceRegistry.java>[6]
interface will striaght-away extend AiravataRegistry2[1] (haven't done
it in the code yet though) since the experiment Id is unique throughout the
whole system.

1.
https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/AiravataRegistry2.java
2.
https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/DescriptorRegistry.java
3.
https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/ProjectsRegistry.java
4.
https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/PublishedWorkflowRegistry.java
5.
https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/UserWorkflowRegistry.java
6.
https://svn.apache.org/repos/asf/incubator/airavata/trunk/modules/commons/registry-api/src/main/java/org/apache/airavata/registry/api/AiravataProvenanceRegistry.java

>
> Thanks and Regards,
> Chathuri
>
>
>
> On Sat, Sep 1, 2012 at 11:08 AM, Amila Jayasekara
> <thejaka.amila@gmail.com>wrote:
>
> > On Sat, Sep 1, 2012 at 10:01 AM, Suresh Marru <smarru@apache.org> wrote:
> > > On Aug 31, 2012, at 5:23 PM, Amila Jayasekara <thejaka.amila@gmail.com
> >
> > wrote:
> > >
> > >> Hi Suresh,
> > >>
> > >> Could you please elaborate what you meant by "1 project owned by a
> > >> single user" ?
> > >> I am trying to figure out what sort of actions are allowed when a user
> > >> is an "owner" of a project.
> > >
> > > Hi Amila,
> > >
> > > The data privacy is a complex topic, thats one of the long term best
> > interests of Airavata to align and reuse the work done by projects like
> > OODT. In true short term, Airavata registry should suffice and keep the
> > focus on maturing the core features and bring them to a 1.0 state. Back
> on
> > the topic, by default users would like to keep data and metadata private
> > for a certain time. This window varies from use case to use case, but
> > roughly it will be 12 to 18 months. During this time, the user analyses
> the
> > data or publishes results. This also includes the recipe which was used
> to
> > generate the data, which in Airavata case is the Workflow and the inputs
> > and configurations. There is a growing push on depositing data and
> metadata
> > into public repositories. So summarizing, Airavata should by default make
> > the workflows, projects and experiments within it owned and accessible
> by a
> > single user or the owner of the data. At the same time, we should
> consider
> > capabilities to share these data (at experiment or project level) to a
> set
> > of users, or groups or make them public.
> > >
> > > Does this answer your question?
> >
> > Hi Suresh,
> >
> > Yes it answers my question.
> >
> > Also can we assume that descriptors (host, application etc ...) are
> > owned by a single user ? (In addition to workflows, projects and
> > experiments)
> >
> > Let me also explain how we thought about this.
> >
> > A gateway can have multiple projects. A project can have multiple
> > experiments. An experiment is equivalent to a workflow. So a user is
> > associated with a workflow. The associated user has read, write
> > capabilities to all workflows he/she designs.
> > If a workflow needs to be shared, then it goes to a new state called
> > "published". In published state other users can read the workflow but
> > cannot do any modifications to it.
> >
> > I guess with your answer we need to change the structure we originally
> > discussed.
> >
> > Thanks
> > Amila
> >
> >
> > >
> > > Suresh
> > >
> > >> Thanks
> > >> Amila
> > >>
> > >> On Fri, Aug 31, 2012 at 5:08 PM, Suresh Marru <smarru@apache.org>
> > wrote:
> > >>> Hi Chathuri,
> > >>>
> > >>> This is a very good list. Few suggestions, I think Descriptors and
> > published workflows should be moved outside and right within Gateways.
> Also
> > each user might have multiple projects and 1 project is owned by a single
> > user. So I think it should be Users and then multiple projects within it.
> > >>>
> > >>> Suresh
> > >>>
> > >>> On Aug 31, 2012, at 5:02 PM, Chathuri Wimalasena <
> kamalasini@gmail.com>
> > wrote:
> > >>>
> > >>>> Hi All,
> > >>>>
> > >>>> We had a discussion on how airavata registry data should be
> > categorized and
> > >>>> came up with the following structure.
> > >>>>
> > >>>> Gateway
> > >>>> |- Project1
> > >>>> |     |- Descriptors
> > >>>> |     |- Published workflows
> > >>>> |     |- User A
> > >>>> |           |- unpublished workflows
> > >>>> |           |- experiments
> > >>>> |                    |- workflow
> > >>>> |                           |- nodes
> > >>>> |
> > >>>> |
> > >>>> |
> > >>>> |
> > >>>> |- Project2
> > >>>> |       |- user A
> > >>>> |
> > >>>> |
> > >>>>
> > >>>> According to the above structure, below table structure was designed
> > for
> > >>>> the mysql database which will be replacing existing backend
> jackrabbit
> > >>>> database.
> > >>>>
> > >>>> Gateway
> > >>>> gateway_ID
> > >>>> gateway_name
> > >>>>
> > >>>> Projects
> > >>>> gateway_ID
> > >>>> project_ID
> > >>>>
> > >>>> Public_Workflow
> > >>>> project_ID
> > >>>> workflow_name
> > >>>> version
> > >>>> content
> > >>>> published_date
> > >>>>
> > >>>> User_Workflow
> > >>>> project_ID
> > >>>> user_ID
> > >>>> workflow_name
> > >>>> last_update_date
> > >>>>
> > >>>> Host_Descriptor
> > >>>> project_ID
> > >>>> host_descriptor_ID
> > >>>> host_descriptor_xml
> > >>>>
> > >>>> Service_Descriptor
> > >>>> project_ID
> > >>>> service_descriptor_ID
> > >>>> service_descriptor_xml
> > >>>>
> > >>>> Application_Descriptor
> > >>>> project_ID
> > >>>> service_descriptor_ID
> > >>>> host_descriptor_ID
> > >>>> application_descriptor_xml
> > >>>>
> > >>>> Experiment
> > >>>> project_ID
> > >>>> user_ID
> > >>>> experiment_ID
> > >>>> submitted_date
> > >>>>
> > >>>> All suggestions and feedbacks are most welcome.
> > >>>>
> > >>>> Thanks and Regards,
> > >>>> Chathuri
> > >>>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message