airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suresh Marru (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (AIRAVATA-1006) Craft the Registry 1.0 CPI
Date Wed, 05 Feb 2014 17:54:11 GMT

    [ https://issues.apache.org/jira/browse/AIRAVATA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13892352#comment-13892352
] 

Suresh Marru edited comment on AIRAVATA-1006 at 2/5/14 5:53 PM:
----------------------------------------------------------------

Hi Chathuri,

This is indeed very intuitive. One a flip side we can look at critically and say its too abstract
and high level, but I find the abstraction very simple and neat. When data models change adding
removing fields, this CPI will almost require no changes what so ever. Now this will burden
all components to focus on airavata thrift data models and adapt to changes. But that may
anyway require and it alleviates form changes to registry cpi as well. Its also very clean
in the sense that internal organization of the data and the relations between them, whether
structured, unstructured or semi-structured is now a registry implementation detail. 

+ 1 for moving foreword.

How will the update work? lets say if there are some optional values filled in and a request
comes to update the object with a values for new parameters and for some previously set parameters,
will all of them be updated? 

How will the transactions be enforced when two non co-ordinating components are trying to
update the same obejct?

Suresh


was (Author: smarru):
Hi Chathuri,

This is indeed very intuitive. One a flip side we can look at critically and say its too abstract
and high level, but I find the abstraction very simple and near. This will almost require
no changes what so ever which changes to data models. Now all components only have to focus
on airavata thrift data models and adopt to changes in it and don't worry about registry cpi
changes. Its also very clean in the sense that internal organization of the data and the relations
between them, whether structured, unstructured or semi-structured is only a registry implementation
detail. + 1 for moving foreward with it.

How will the update work? lets say if there are some optional values filled in and a request
comes to update the object with a values for new parameters and for some previously set parameters,
will all of them be updated? 

How will the transactions be enforced when two non co-ordinating components are trying to
update the same obejct?

Suresh

> Craft the Registry 1.0 CPI
> --------------------------
>
>                 Key: AIRAVATA-1006
>                 URL: https://issues.apache.org/jira/browse/AIRAVATA-1006
>             Project: Airavata
>          Issue Type: Sub-task
>            Reporter: Suresh Marru
>             Fix For: 0.12
>
>
> As the Airavata API is evolving towards 1.0 version, we need to refine the currently
Registry API (and the current Airavata Client->Registry API) into a unified and well defined
Registry CPI. 
> This registry CPI is targeted to be invoked by the Airavata API functions and use of
Registry by all internal Airavata internal components like Orchestrator, Workflow Interpreter
and GFac.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message