Open APIs

I am somewhat new to TMF and  was working on a design that seemed to fit well with TMF 652. I reviewed TMF 641 and initially felt that our non customer facing scenario fit better by leveraging 652. I have since met with others on the design and they suggest TM641 should be used. The two are close enough that allows us to easily switch, however, is there any literature that provides any better guidance of what scenarios 641 should be chosen over 652? Or am I missing something more fundamental :-)

------------------------------
Jay Hamilton
AT&T Inc.
------------------------------

Hi Jay

TM Forum (in line with general industry practice) makes a distinction between Service and Resource. This has been expressed in the Information Framework (SID) for many years already, and as a result is also reflected in the Open API model. We have the parallel API sets:

• Service Catalog (TMF633), Service Order (TMF641), Service Activation (TMF640), Service Inventory (TMF638)
• Resource Catalog (TMF634), Resource Order (TMF652), Resource Activation (TMF702), Resource Inventory (TMF639)

A very short explanation (bear in mind that I am not an OSS expert :) ):

• Service - is how the communication (or other) service is implemented in the network. For example, a Broadband product might be implemented for a customer in the network as a fiber connection between the home and the central office; this is the Service.
• Resource - is something that is used to implement the service; could be a physical resource (like the actual fiber cable, or the home router), or a logical resource (like a static IP address)

I hope this short explanation helps. You need to decide if your scenario involves services or resources (or perhaps both) and design your solution accordingly. You might want to share more details of your dilemma here (if you can do so without leaking intellectual property or private data), maybe the collective wisdom of the community can assist you.

------------------------------
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.
------------------------------

Hi Jay,

You can find examples of use cases (4, 7, 8, 11, 14) where those APIs are used in the IG1228 document. 

Hope it helps.

Regards,

------------------------------
Abel Ruiz Huerta
alvatross by SATEC
------------------------------

Original Message:
Sent: Jul 04, 2023 08:02
From: Jonathan Goldberg
Subject: Where can I find out more about how to think about TMF 641 vs 652?

Hi Jay

TM Forum (in line with general industry practice) makes a distinction between Service and Resource. This has been expressed in the Information Framework (SID) for many years already, and as a result is also reflected in the Open API model. We have the parallel API sets:

• Service Catalog (TMF633), Service Order (TMF641), Service Activation (TMF640), Service Inventory (TMF638)
• Resource Catalog (TMF634), Resource Order (TMF652), Resource Activation (TMF702), Resource Inventory (TMF639)

A very short explanation (bear in mind that I am not an OSS expert :) ):

• Service - is how the communication (or other) service is implemented in the network. For example, a Broadband product might be implemented for a customer in the network as a fiber connection between the home and the central office; this is the Service.
• Resource - is something that is used to implement the service; could be a physical resource (like the actual fiber cable, or the home router), or a logical resource (like a static IP address)

I hope this short explanation helps. You need to decide if your scenario involves services or resources (or perhaps both) and design your solution accordingly. You might want to share more details of your dilemma here (if you can do so without leaking intellectual property or private data), maybe the collective wisdom of the community can assist you.

------------------------------
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.
------------------------------