Open APIs

Hello,
I studied implementation of TMF633 where Service Specification serves both for Customer Facing Service Specification and Resource Facing Service Specification scenarios.
Now, I'm checking TMF634 and I can see that we have the general Resource Specification and then, we have Logical Resource Specification (which is basically the same element as the Resource Specification one) and, Physical Resource Specification (which has 3-4 new elements on top of the general Resource Specification element.
My question is: Why can't we have on TMF634 a single element to address both physical and logical resources, being the @type element capable to
differentiate among them.?

------------------------------
Marcos Donato da Silva
Ericsson Inc.
------------------------------

Hi Marcos

There is nothing preventing you from creating your own ResourceSpecification sub-classes, bypassing Logical and Physical, and using the @type​ mechanism to subclass correctly.
But we felt that since there is a demonstrable difference between Logical and Physical (has extra attributes and relationships relating to the tangible nature of the instantiated resource) it would be helpful to have these sub-classes.

Although I am not an OSS expert, I am not sure that such a distinction can be made (at the model level) between CSF and RSF - happy to be corrected.

You could consider discussing with @Kamal Maghsoudlou from your own company Ericsson, the "father" of the catalog Open APIs :) , or with @Pierre Gauthier, Open API chief architect.

Hope it helps.​​

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------

Original Message:
Sent: Mar 26, 2020 13:28
From: Marcos Donato da Silva
Subject: TMF-634: Why can't we have only Resource Specification to address logical & physical ones

Hello,
I studied implementation of TMF633 where Service Specification serves both for Customer Facing Service Specification and Resource Facing Service Specification scenarios.
Now, I'm checking TMF634 and I can see that we have the general Resource Specification and then, we have Logical Resource Specification (which is basically the same element as the Resource Specification one) and, Physical Resource Specification (which has 3-4 new elements on top of the general Resource Specification element.
My question is: Why can't we have on TMF634 a single element to address both physical and logical resources, being the @type element capable to
differentiate among them.?

------------------------------
Marcos Donato da Silva
Ericsson Inc.
------------------------------

Marcos asks:  "Why can't we have on TMF634 a single element to address both physical and logical resources, being the @type element capable to
differentiate among them.?"

You can, and we do. Both LogicalResourceSpecification and PhysicalResourceSpecification are subtypes of ResourceSpecification.

I suspect what you are looking at is how the URIs are provided in the 17.0 version of TMF634 where we see:

        /catalogManagement/resourceSpec/
        /catalogManagement/logicalResourceSpec/
        /catalogManagement/physicalResourceSpec/

You won't find that in the new releases of TMF634 where we have a consistent use of:

        /resourceCatalogManagement/resourceSpecification/

So yes, LogicalResourceSpecificxcation and PhysicalResourceSpecification, as well as all polymorphic extensions of ResourceSpecification, are part of the same collection.

------------------------------
Vance Shipley
SigScale
------------------------------

Original Message:
Sent: Mar 26, 2020 13:28
From: Marcos Donato da Silva
Subject: TMF-634: Why can't we have only Resource Specification to address logical & physical ones

Hello,
I studied implementation of TMF633 where Service Specification serves both for Customer Facing Service Specification and Resource Facing Service Specification scenarios.
Now, I'm checking TMF634 and I can see that we have the general Resource Specification and then, we have Logical Resource Specification (which is basically the same element as the Resource Specification one) and, Physical Resource Specification (which has 3-4 new elements on top of the general Resource Specification element.
My question is: Why can't we have on TMF634 a single element to address both physical and logical resources, being the @type element capable to
differentiate among them.?

------------------------------
Marcos Donato da Silva
Ericsson Inc.
------------------------------

Hi @Jonathan Goldberg​, thanks for your attention and reply.
Yes. We're making extensive use of the @type in our implementations to especialize or enrich
out-of-the box resources provided in these APIs.
I'm also in contact with Kamal to discuss details around these Open APIs which we're implementing right
now in our products so that his help in conjunction with the answers I get here are indeed makes the 
difference.

Hi @Vance Shipley.
Your information around planned changes over the API endpoints along next release of TMF634 is indeed
what I was looking for. With that, I see a better alignment between TMF633 & TMF634 structures.
Many thanks.

Regards,
​​

------------------------------
Marcos Donato da Silva
Ericsson Inc.
------------------------------

Original Message:
Sent: Apr 03, 2020 03:59
From: Vance Shipley
Subject: TMF-634: Why can't we have only Resource Specification to address logical & physical ones

Marcos asks:  "Why can't we have on TMF634 a single element to address both physical and logical resources, being the @type element capable to
differentiate among them.?"

You can, and we do. Both LogicalResourceSpecification and PhysicalResourceSpecification are subtypes of ResourceSpecification.

I suspect what you are looking at is how the URIs are provided in the 17.0 version of TMF634 where we see:

        /catalogManagement/resourceSpec/
        /catalogManagement/logicalResourceSpec/
        /catalogManagement/physicalResourceSpec/

You won't find that in the new releases of TMF634 where we have a consistent use of:

        /resourceCatalogManagement/resourceSpecification/

So yes, LogicalResourceSpecificxcation and PhysicalResourceSpecification, as well as all polymorphic extensions of ResourceSpecification, are part of the same collection.

------------------------------
Vance Shipley
SigScale

Original Message:
Sent: Mar 26, 2020 13:28
From: Marcos Donato da Silva
Subject: TMF-634: Why can't we have only Resource Specification to address logical & physical ones

Hello,
I studied implementation of TMF633 where Service Specification serves both for Customer Facing Service Specification and Resource Facing Service Specification scenarios.
Now, I'm checking TMF634 and I can see that we have the general Resource Specification and then, we have Logical Resource Specification (which is basically the same element as the Resource Specification one) and, Physical Resource Specification (which has 3-4 new elements on top of the general Resource Specification element.
My question is: Why can't we have on TMF634 a single element to address both physical and logical resources, being the @type element capable to
differentiate among them.?

------------------------------
Marcos Donato da Silva
Ericsson Inc.
------------------------------