Open APIs

 View Only
  • 1.  TMF640: Dynamic serviceCharacteristics

    Posted Jul 15, 2018 21:17
    Edited by Vikas Kumar Jul 15, 2018 22:50
    Hello

    As per the TMF 640: ServiceCharacteristics is defined as 
    A name/value pair list used to store instance specific values of attributes. the behavior is equivalent to a MAP data structure where only one entry for any given value of "name" can exist

    Questions:
    1/ Why cant we abstract the Instance specific values & type of attributes - to allow dynamic payload?
    example: use JSON object for instance specific values.

    2/ Why cant we reduce the complexity of parsing?
    example: Orchestrator will need to understand the instance specific attributes to parse the attributes before sending it to the network layer.
    Different domains might have different instance specification attributes. Parsing or understanding the complex service construct (instance) will NOT be efficient design when scaling up millions of service activations. Whilst, using JSON object - it can be a passthrough for most Orchestrator or gateways.

    Thanks
    Vikas Kumar
    vikkumar@ciena.com



    ------------------------------
    Vikas Kumar
    Blueplanet
    Ciena Corporation
    ------------------------------


  • 2.  RE: TMF640: Dynamic serviceCharacteristics

    Posted Jul 17, 2018 19:44
    Hi Vikas,

    With regards to your 1st question, it seems that there is some inconsistency in the way ServiceCharacteristics is represented in TMF640 & 641 - if you look at the example in 641 you will see that ServiceCharacteristics is shown with a Type & Value... in my opinion the way the service characteristics are shown across the two documents should be consistent.  

    I'm not 100% sure what you are referring to in your second question, but the way i understand service specifications is that you have a Customer Facing Specification (CFS) and Resource Facing Specification (RFS) that can contain the same details but can be translated or interpreted. In addition to this there is also a Configuration data structure (not in TMF640/641 but in the SID model) that will allow you to support specific configuration for your services.

    Hope this helps

    Pete

    ------------------------------
    Pete Bains
    ------------------------------



  • 3.  RE: TMF640: Dynamic serviceCharacteristics

    TM Forum Member
    Posted Jul 18, 2018 02:48
    Hi Vikas and Pete
    You may be interested to know that the Open API architecture team is working on revising and standardizing the characteristic pattern across all the places it is used in the API model. The enhancement is to allow declaration of characteristics with strongly-defined data types (string, integer, complex object, etc.). This is expected to be published in the design guidelines for release 18.5, but we cannot commit that all the API specs will be updated to the pattern in this release. You might want to reach out to @Mariano Belaunde to find more details and see if this helps answer the issues you raised.
    I didn't understand the point about the JSON payload - all the Open APIs have JSON payloads, and intermediate layers (such as API gateways, load balancers, etc.) would be expected to pass through untouched (apart from possible modifications to embedded URLs that might be needed).

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 4.  RE: TMF640: Dynamic serviceCharacteristics

    Posted Jul 18, 2018 04:07
    Hi Jonathan,

    That would really help heaps... what would be also good is if there are description on how these atttributes/values are used (maybe using practical examples).

    Pete

    ------------------------------
    Pete Bains
    ------------------------------



  • 5.  RE: TMF640: Dynamic serviceCharacteristics

    TM Forum Member
    Posted Jul 18, 2018 07:15
    I think what Vikas meant was "service type-specific set of attributes" passed in a defined JSON object for any given service type.
    Not the "instance specific values" because these are obvious.
    He seems to want to avoid declaring a "super-set" of all possible service attributes... then dealing with which attributes relate to which types etc...

    ------------------------------
    Sergey Zak
    Telstra Corporation
    ------------------------------



  • 6.  RE: TMF640: Dynamic serviceCharacteristics

    Posted Jul 18, 2018 22:17
    Edited by Vikas Kumar Jul 24, 2018 20:27
    Thanks Pete/Jon & Sergey

    There are 3 ways/options to store the KV pairs

    #1[{"key1": "value1"}, {"key2": "value2"}]

    Or:

    #2(Currently TMF usage) [{"Name": "key1", "Value": "value1"}, {"Name": "key2", "Value": "value2"}]

    Or:

    #3 (Recommendation) {"key1": "value1", "key2": "value2"}


    all three formats achieve the same result it's just a question of syntax.
    Whether you choose the first or the third option depends on the use case.

    IMHO the 3rd option suits better for TMF ServiceCharacteristics- reasons being

    If you are modeling many different instances of the same type of thing, choose the first. For example, you have a list of people.
    If you are modeling many different attributes of one thing, choose the third.
    You can have repeated keys in the first format, but not in the third.


    use #3: dictionary of key / value pairs.

    Structure #1 is just daft unless you need key / value pairs but also their order. Which you rarely do.



    ------------------------------
    Vikas Kumar
    Ciena Corporation
    ------------------------------