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 which implements four interfaces as DescriptorRegistry, ProjectsRegistry, PublishedWorkflowRegistry and UserWorkflowRegistry. Please give your suggestions and feedback. Thanks and Regards, Chathuri On Sat, Sep 1, 2012 at 11:08 AM, Amila Jayasekara <[email protected]>wrote: > On Sat, Sep 1, 2012 at 10:01 AM, Suresh Marru <[email protected]> wrote: > > On Aug 31, 2012, at 5:23 PM, Amila Jayasekara <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 > >>> > > >
