On Tue, Sep 4, 2012 at 5:05 PM, Chathuri Wimalasena <[email protected]>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 > <[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 > > >>> > > > > > >
