You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by "Suresh Marru (JIRA)" <ji...@apache.org> on 2014/02/05 18:54:11 UTC

[jira] [Comment Edited] (AIRAVATA-1006) Craft the Registry 1.0 CPI

    [ 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)