You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 32 Next »

Introduction

Although the PoC will only implement a few of the possible Java API methods it is important to have a good detailed view of the structure and naming of this interface going forward and document it.

Acceptance Criteria for Proposed Java Interface:

  1. Should follow ONAP or wider best practice
  2. Documented on ONAP Wiki
  3. Discussed and agreed within CPS Team
  4. Discussed and agreed with wider community


Currently we are considering 3 'separated' Java APIs or 'groups' of methods:

  1. Models (add, list)
  2. Data (CRUD)
  3. Queries

Jira Ticket:

CCSDK-2871 - Getting issue details... STATUS

Jira Backlog:

https://jira.onap.org/secure/RapidBoard.jspa?rapidView=223&view=planning.nodetail&selectedIssue=CCSDK-2912&issueLimit=100

Gerrit Review

https://gerrit.nordix.org/#/c/onap/ccsdk/features/+/6477/

External Resources

https://wiki.onap.org/display/DW/Data+Representation

https://wiki.onap.org/display/DW/Interface+style

Open Issues/Decisions

#

Description

Details

Decisions

1Should the java interface take in one (JSON) objects (like REST interface) or a few individual fields in a signature? 
  • for Node attributes (Fragments) in our DB we will use a 'glorified' Map to store these and pass them on through the layers as a single object
  • For API methods that require 2-4 parameters there is no need to create separate objects

TBC

2Input streams and/or files to take in large amounts of data like yang models?
  • Input streams are more generic
  • Overloading of API to support both leads bloated interface

03/11/12 Team meeting Niamh, Toine, Rishi, Aditya, Bruno, Phillipe

We have decided to use input streams.

3

API uses (generated) ID's or customer provided names? If names are used should we return IDs at all?

03/11/12 Team meeting notes - Niamh, Toine, Rishi, Aditya, Bruno, Phillipe
Pros:

  1. Using IDs would have some performance advantage
  2. Using the ID seems natural in some cases
  3. Using IDs would allow for 'renaming' where possible

Cons:

  1. Using ID would mean client has to get/cache ID's all the time.
  2. Supporting both names and ID will lead to 'duplicate' methods in Java API and REST API
  3. Using a meaningless ID for Module instead for namespace & revision could lead to issues when debugging (only logs with IDs available)

Other considerations:

  1. The Java API follow the REST API. If the rest API is using names then the java API should also use names.
  2. Create methods should return the (id of the) objects created. If the module already exists, an exception should be thrown.
  3. All ID's generated should be in the response. If we return the ID we also need methods to use the ID. If we update the java API to use ID, we should also update the REST API. 
  4. OSS RC does NOT use IDs for models
  5. OSS RC Does DB Generated ID for objects (fragments)
  6. Need separate decision for
    1. Dataspace
    2. Module Set
    3. Module
    4. Anchor
    5. Fragment  

4Should a user be able to delete a dataspace, module ( (of the same revision), module set?

Maybe only allow if no associated data exist e.g. all fragments using a module should be deleted before a module can be deleted


5Should a user be able to update/override (create again) dataspace, module (of the same revision), module set?
  1. Business logic to check on create if it already exists. If it exists we do not create it.
  2. If the module already exists, an exception should be thrown.





CPS provides the following interfaces:

Interface Name

Interface Definition

 Interface Capabilities

Consumed Models

Model InterfaceBehavior interface that represents cps modules.
  1. Create a module set
  2. Add modules to a module set
  3. Read all modules
  4. Validate modules
  5. Upgrade a module set (individual module upgrade)
  6. Create a module set and validate it against a module reference (using a separate SPI)
Yang models that are broken into fragments.
Data Interface

Behavior interface that represents CPS data.

  1. Create a node under an anchor.
  2. Delete a dataspace
  3. Create a dataspace
  4. Create an anchor
  5. Read an anchor of a particular node
  6. Read an anchor in a namespace and dataspace
  7. Read all anchors for one dataspace
  8. Delete an anchor for a namespace in a dataspace
  9. Associate an anchor to a module set
  10. Associate an dataspace to a anchor
  11. Read all dataspaces
  12. Create a node under another node.
  13. Associate an a node to a anchor

Query InterfaceProvides the capability to query CPS data using XPaths.
  1. Read the parent of a node that matches an xpath expression
  2. Read all nodes under an anchor point
  3. Read the anchor of a node
  4. Read all nodes that match a schema node identifier

Query Builder InterfaceProvides the capability to query CPS data using restrictions from a query builder (see open issue 1).


  • No labels