Open APIs

Dear All,

We are working on implementation of 638 and 639 for service and resource inventory respectively. Here in our requirement as per TMF Open API we are giving respective resource like circuit and all for given 638 service inventory API as a supporting resource. However similarly can we give service reference as a resource relationship say "serviceAssociatedwith" with service details as a resource object in 639 API. so that from 639 they can go to respective href of 638 service ID or something.

Following way of representing service details in the form of resource under 639 as resource relationship. Is it valid and compliance with TMF Open API?

Kindly advise/guide in this regard.

"resourceRelationship": [{
                            "relationshipType": "ServiceComposedOf",
                            "resource": {
                                "@type": "service",
                                "@baseType": "LogicalResource",
                                "@referredType": "service",
                                "name": "SVCXXXXX",
                                "id": "SVCXXXXX",
                                "href": "http://XX.XX.XX.XXX:61050/tmf-api/serviceInventoryManagement/v1/service?id=nsUKEVC10000396&systemName=system"
                            }
                        }]

@Mahesh Choudhari raises a question about navigating from a Resource in TMF639 to a Service in TMF638:

can we give service reference as a resource relationship

No, definitely not, because an entity with @type: Service is not a Resource and the resourceRelationship attribute provides (only) related Resource entities.  It may seem odd that TMF639 does not provide for navigation to Service however it is intentional. I am told that "domain driven design" principles do not allow the resulting circular relationships. 

You have two ways to go here:

1. query TMF638 to find related Service entities
2. implement a polymorphic extension

Both of these have their own issues.  The first option requires the advanced query syntax of TMF630 Part 6 JSONPath, which your TMF638 implementation may not support. The second option may be easier and more efficient but will be proprietary, however it can be seen as an optimization as other TMF639 consumers shall ignore the extension.

Here's an example of querying TMF638 for Services where supportingResource includes a reference to a Resource with id: 42:

GET /tmf-api/serviceInventory/v4/service?filter=supportingResource[?(@.id=='42')]

Dear All,

We are working on implementation of 638 and 639 for service and resource inventory respectively. Here in our requirement as per TMF Open API we are giving respective resource like circuit and all for given 638 service inventory API as a supporting resource. However similarly can we give service reference as a resource relationship say "serviceAssociatedwith" with service details as a resource object in 639 API. so that from 639 they can go to respective href of 638 service ID or something.

Following way of representing service details in the form of resource under 639 as resource relationship. Is it valid and compliance with TMF Open API?

Kindly advise/guide in this regard.

"resourceRelationship": [{
                            "relationshipType": "ServiceComposedOf",
                            "resource": {
                                "@type": "service",
                                "@baseType": "LogicalResource",
                                "@referredType": "service",
                                "name": "SVCXXXXX",
                                "id": "SVCXXXXX",
                                "href": "http://XX.XX.XX.XXX:61050/tmf-api/serviceInventoryManagement/v1/service?id=nsUKEVC10000396&systemName=system"
                            }
                        }]

Thanks @Vance Shipley for your inputs and advise. We are providing related resource reference using "supportingResource" under 638 so similar way our internal team was asking if we can give 638 service reference in 639 resource to traverse back.  As i understand we cannot give or define service as resource and give such reference. We will check on this how we can achieve it as per above suggestion.

@Mahesh Choudhari raises a question about navigating from a Resource in TMF639 to a Service in TMF638:

can we give service reference as a resource relationship

No, definitely not, because an entity with @type: Service is not a Resource and the resourceRelationship attribute provides (only) related Resource entities.  It may seem odd that TMF639 does not provide for navigation to Service however it is intentional. I am told that "domain driven design" principles do not allow the resulting circular relationships. 

You have two ways to go here:

1. query TMF638 to find related Service entities
2. implement a polymorphic extension

Both of these have their own issues.  The first option requires the advanced query syntax of TMF630 Part 6 JSONPath, which your TMF638 implementation may not support. The second option may be easier and more efficient but will be proprietary, however it can be seen as an optimization as other TMF639 consumers shall ignore the extension.

Here's an example of querying TMF638 for Services where supportingResource includes a reference to a Resource with id: 42:

GET /tmf-api/serviceInventory/v4/service?filter=supportingResource[?(@.id=='42')]

Dear All,

We are working on implementation of 638 and 639 for service and resource inventory respectively. Here in our requirement as per TMF Open API we are giving respective resource like circuit and all for given 638 service inventory API as a supporting resource. However similarly can we give service reference as a resource relationship say "serviceAssociatedwith" with service details as a resource object in 639 API. so that from 639 they can go to respective href of 638 service ID or something.

Following way of representing service details in the form of resource under 639 as resource relationship. Is it valid and compliance with TMF Open API?

Kindly advise/guide in this regard.

"resourceRelationship": [{
                            "relationshipType": "ServiceComposedOf",
                            "resource": {
                                "@type": "service",
                                "@baseType": "LogicalResource",
                                "@referredType": "service",
                                "name": "SVCXXXXX",
                                "id": "SVCXXXXX",
                                "href": "http://XX.XX.XX.XXX:61050/tmf-api/serviceInventoryManagement/v1/service?id=nsUKEVC10000396&systemName=system"
                            }
                        }]

@Mahesh Choudhari you may add an attribute, with name and value of your choice, to the JSON object representing the Resource in a TMF639 response. That was option 2 in my reply, which is a polymorphic extension (see  TMF730 Part 2). At SigScale we do exactly this, with the same motivation as you. Just realize that this is a proprietary extension of both the TMF639 producer and consumer. The interface remains TM Forum compliant however.

Thanks @Vance Shipley for your inputs and advise. We are providing related resource reference using "supportingResource" under 638 so similar way our internal team was asking if we can give 638 service reference in 639 resource to traverse back.  As i understand we cannot give or define service as resource and give such reference. We will check on this how we can achieve it as per above suggestion.

@Mahesh Choudhari raises a question about navigating from a Resource in TMF639 to a Service in TMF638:

can we give service reference as a resource relationship

No, definitely not, because an entity with @type: Service is not a Resource and the resourceRelationship attribute provides (only) related Resource entities.  It may seem odd that TMF639 does not provide for navigation to Service however it is intentional. I am told that "domain driven design" principles do not allow the resulting circular relationships. 

You have two ways to go here:

1. query TMF638 to find related Service entities
2. implement a polymorphic extension

Both of these have their own issues.  The first option requires the advanced query syntax of TMF630 Part 6 JSONPath, which your TMF638 implementation may not support. The second option may be easier and more efficient but will be proprietary, however it can be seen as an optimization as other TMF639 consumers shall ignore the extension.

Here's an example of querying TMF638 for Services where supportingResource includes a reference to a Resource with id: 42:

GET /tmf-api/serviceInventory/v4/service?filter=supportingResource[?(@.id=='42')]

Dear All,

We are working on implementation of 638 and 639 for service and resource inventory respectively. Here in our requirement as per TMF Open API we are giving respective resource like circuit and all for given 638 service inventory API as a supporting resource. However similarly can we give service reference as a resource relationship say "serviceAssociatedwith" with service details as a resource object in 639 API. so that from 639 they can go to respective href of 638 service ID or something.

Following way of representing service details in the form of resource under 639 as resource relationship. Is it valid and compliance with TMF Open API?

Kindly advise/guide in this regard.

"resourceRelationship": [{
                            "relationshipType": "ServiceComposedOf",
                            "resource": {
                                "@type": "service",
                                "@baseType": "LogicalResource",
                                "@referredType": "service",
                                "name": "SVCXXXXX",
                                "id": "SVCXXXXX",
                                "href": "http://XX.XX.XX.XXX:61050/tmf-api/serviceInventoryManagement/v1/service?id=nsUKEVC10000396&systemName=system"
                            }
                        }]

Thanks, you so much @Vance Shipley for your suggestion and inputs. indeed, we were also thinking of adding either new parameter under resource object or as characteristics name/value pair to avoid more complexity of polymorphic extension and impact on consumers about it. We will go ahead with new parameter only in this case to give service Id reference.

@Mahesh Choudhari you may add an attribute, with name and value of your choice, to the JSON object representing the Resource in a TMF639 response. That was option 2 in my reply, which is a polymorphic extension (see  TMF730 Part 2). At SigScale we do exactly this, with the same motivation as you. Just realize that this is a proprietary extension of both the TMF639 producer and consumer. The interface remains TM Forum compliant however.

Thanks @Vance Shipley for your inputs and advise. We are providing related resource reference using "supportingResource" under 638 so similar way our internal team was asking if we can give 638 service reference in 639 resource to traverse back.  As i understand we cannot give or define service as resource and give such reference. We will check on this how we can achieve it as per above suggestion.

@Mahesh Choudhari raises a question about navigating from a Resource in TMF639 to a Service in TMF638:

can we give service reference as a resource relationship

No, definitely not, because an entity with @type: Service is not a Resource and the resourceRelationship attribute provides (only) related Resource entities.  It may seem odd that TMF639 does not provide for navigation to Service however it is intentional. I am told that "domain driven design" principles do not allow the resulting circular relationships. 

You have two ways to go here:

1. query TMF638 to find related Service entities
2. implement a polymorphic extension

Both of these have their own issues.  The first option requires the advanced query syntax of TMF630 Part 6 JSONPath, which your TMF638 implementation may not support. The second option may be easier and more efficient but will be proprietary, however it can be seen as an optimization as other TMF639 consumers shall ignore the extension.

Here's an example of querying TMF638 for Services where supportingResource includes a reference to a Resource with id: 42:

GET /tmf-api/serviceInventory/v4/service?filter=supportingResource[?(@.id=='42')]

Dear All,

We are working on implementation of 638 and 639 for service and resource inventory respectively. Here in our requirement as per TMF Open API we are giving respective resource like circuit and all for given 638 service inventory API as a supporting resource. However similarly can we give service reference as a resource relationship say "serviceAssociatedwith" with service details as a resource object in 639 API. so that from 639 they can go to respective href of 638 service ID or something.

Following way of representing service details in the form of resource under 639 as resource relationship. Is it valid and compliance with TMF Open API?

Kindly advise/guide in this regard.

"resourceRelationship": [{
                            "relationshipType": "ServiceComposedOf",
                            "resource": {
                                "@type": "service",
                                "@baseType": "LogicalResource",
                                "@referredType": "service",
                                "name": "SVCXXXXX",
                                "id": "SVCXXXXX",
                                "href": "http://XX.XX.XX.XXX:61050/tmf-api/serviceInventoryManagement/v1/service?id=nsUKEVC10000396&systemName=system"
                            }
                        }]

Thanks Vance for your inputs. Indeed, the TMF Open APIs prefer not to have circular references (although I cannot promise that this guide is universally followed). I agree with Vance's suggestions for solving your issue - the TMF "by-the-book" method would be to query service by resource ID. Note that if you do extend the model to create a backward reference, you need to decide if it will be an array of Service or a single Service. If in your business situation a Resource can implement multiple Services, you'll need an array.

Hope it helps.

Thanks, you so much @Vance Shipley for your suggestion and inputs. indeed, we were also thinking of adding either new parameter under resource object or as characteristics name/value pair to avoid more complexity of polymorphic extension and impact on consumers about it. We will go ahead with new parameter only in this case to give service Id reference.

@Mahesh Choudhari you may add an attribute, with name and value of your choice, to the JSON object representing the Resource in a TMF639 response. That was option 2 in my reply, which is a polymorphic extension (see  TMF730 Part 2). At SigScale we do exactly this, with the same motivation as you. Just realize that this is a proprietary extension of both the TMF639 producer and consumer. The interface remains TM Forum compliant however.

Thanks @Vance Shipley for your inputs and advise. We are providing related resource reference using "supportingResource" under 638 so similar way our internal team was asking if we can give 638 service reference in 639 resource to traverse back.  As i understand we cannot give or define service as resource and give such reference. We will check on this how we can achieve it as per above suggestion.

@Mahesh Choudhari raises a question about navigating from a Resource in TMF639 to a Service in TMF638:

can we give service reference as a resource relationship

No, definitely not, because an entity with @type: Service is not a Resource and the resourceRelationship attribute provides (only) related Resource entities.  It may seem odd that TMF639 does not provide for navigation to Service however it is intentional. I am told that "domain driven design" principles do not allow the resulting circular relationships. 

You have two ways to go here:

1. query TMF638 to find related Service entities
2. implement a polymorphic extension

Both of these have their own issues.  The first option requires the advanced query syntax of TMF630 Part 6 JSONPath, which your TMF638 implementation may not support. The second option may be easier and more efficient but will be proprietary, however it can be seen as an optimization as other TMF639 consumers shall ignore the extension.

Here's an example of querying TMF638 for Services where supportingResource includes a reference to a Resource with id: 42:

GET /tmf-api/serviceInventory/v4/service?filter=supportingResource[?(@.id=='42')]

Dear All,

We are working on implementation of 638 and 639 for service and resource inventory respectively. Here in our requirement as per TMF Open API we are giving respective resource like circuit and all for given 638 service inventory API as a supporting resource. However similarly can we give service reference as a resource relationship say "serviceAssociatedwith" with service details as a resource object in 639 API. so that from 639 they can go to respective href of 638 service ID or something.

Following way of representing service details in the form of resource under 639 as resource relationship. Is it valid and compliance with TMF Open API?

Kindly advise/guide in this regard.

"resourceRelationship": [{
                            "relationshipType": "ServiceComposedOf",
                            "resource": {
                                "@type": "service",
                                "@baseType": "LogicalResource",
                                "@referredType": "service",
                                "name": "SVCXXXXX",
                                "id": "SVCXXXXX",
                                "href": "http://XX.XX.XX.XXX:61050/tmf-api/serviceInventoryManagement/v1/service?id=nsUKEVC10000396&systemName=system"
                            }
                        }]

Thanks @Jonathan Goldberg for your inputs/views as well and agree with that. As of now we have gone ahead by adding additional parameter under resource char as parentServiceId something like that under respective circuit or interface connection resource inventory. However as per suggestion from @Vance Shipley we were thinking of using polymorphic extension to show all services, if required under resources as below but we have dropped that idea as we were giving resource details specific to particular circuit. if it was overall resource like device or card/port level exposure then we can think of below to provide such details with list of services in array format under 639. Hope I am correct and in future we can do as per below method under resource object similar to relatedParty and all.

  "relatedServices": [
    {
      "@type": "Service",
      "id": "service456",
      "name": "Internet Connection",
      "type": "Broadband",
      "status": "Active"
    },
    {
      "@type": "Service",
      "id": "service789",
      "name": "Voice Service",
      "type": "Telephony",
      "status": "Suspended"
    }
  ]

Thanks Vance for your inputs. Indeed, the TMF Open APIs prefer not to have circular references (although I cannot promise that this guide is universally followed). I agree with Vance's suggestions for solving your issue - the TMF "by-the-book" method would be to query service by resource ID. Note that if you do extend the model to create a backward reference, you need to decide if it will be an array of Service or a single Service. If in your business situation a Resource can implement multiple Services, you'll need an array.

Hope it helps.

Thanks, you so much @Vance Shipley for your suggestion and inputs. indeed, we were also thinking of adding either new parameter under resource object or as characteristics name/value pair to avoid more complexity of polymorphic extension and impact on consumers about it. We will go ahead with new parameter only in this case to give service Id reference.

@Mahesh Choudhari you may add an attribute, with name and value of your choice, to the JSON object representing the Resource in a TMF639 response. That was option 2 in my reply, which is a polymorphic extension (see  TMF730 Part 2). At SigScale we do exactly this, with the same motivation as you. Just realize that this is a proprietary extension of both the TMF639 producer and consumer. The interface remains TM Forum compliant however.

Thanks @Vance Shipley for your inputs and advise. We are providing related resource reference using "supportingResource" under 638 so similar way our internal team was asking if we can give 638 service reference in 639 resource to traverse back.  As i understand we cannot give or define service as resource and give such reference. We will check on this how we can achieve it as per above suggestion.

@Mahesh Choudhari raises a question about navigating from a Resource in TMF639 to a Service in TMF638:

can we give service reference as a resource relationship

No, definitely not, because an entity with @type: Service is not a Resource and the resourceRelationship attribute provides (only) related Resource entities.  It may seem odd that TMF639 does not provide for navigation to Service however it is intentional. I am told that "domain driven design" principles do not allow the resulting circular relationships. 

You have two ways to go here:

1. query TMF638 to find related Service entities
2. implement a polymorphic extension

Both of these have their own issues.  The first option requires the advanced query syntax of TMF630 Part 6 JSONPath, which your TMF638 implementation may not support. The second option may be easier and more efficient but will be proprietary, however it can be seen as an optimization as other TMF639 consumers shall ignore the extension.

Here's an example of querying TMF638 for Services where supportingResource includes a reference to a Resource with id: 42:

GET /tmf-api/serviceInventory/v4/service?filter=supportingResource[?(@.id=='42')]

Dear All,

We are working on implementation of 638 and 639 for service and resource inventory respectively. Here in our requirement as per TMF Open API we are giving respective resource like circuit and all for given 638 service inventory API as a supporting resource. However similarly can we give service reference as a resource relationship say "serviceAssociatedwith" with service details as a resource object in 639 API. so that from 639 they can go to respective href of 638 service ID or something.

Following way of representing service details in the form of resource under 639 as resource relationship. Is it valid and compliance with TMF Open API?

Kindly advise/guide in this regard.

"resourceRelationship": [{
                            "relationshipType": "ServiceComposedOf",
                            "resource": {
                                "@type": "service",
                                "@baseType": "LogicalResource",
                                "@referredType": "service",
                                "name": "SVCXXXXX",
                                "id": "SVCXXXXX",
                                "href": "http://XX.XX.XX.XXX:61050/tmf-api/serviceInventoryManagement/v1/service?id=nsUKEVC10000396&systemName=system"
                            }
                        }]

Hi Mahesh

I'm not sure that I like the idea of "hiding" the parent service ID as a characteristic. In this way you are weakening the contract with your API consumers. The parent service ID is an input/output (depending on your business) but it is not apparent explicitly in your swagger/OAS file. Only by examining a resource specification can a consumer understand that this information is present. And if the characteristic is omitted by accident from one of the resource specifications, what then?

If you don't want to take the query route, then an array of ServiceRef makes most sense to me (you could also do ServiceRefOrValue, which will work better once we have moved to OAS 3 with support of oneOf).

Thanks @Jonathan Goldberg for your inputs/views as well and agree with that. As of now we have gone ahead by adding additional parameter under resource char as parentServiceId something like that under respective circuit or interface connection resource inventory. However as per suggestion from @Vance Shipley we were thinking of using polymorphic extension to show all services, if required under resources as below but we have dropped that idea as we were giving resource details specific to particular circuit. if it was overall resource like device or card/port level exposure then we can think of below to provide such details with list of services in array format under 639. Hope I am correct and in future we can do as per below method under resource object similar to relatedParty and all.

  "relatedServices": [
    {
      "@type": "Service",
      "id": "service456",
      "name": "Internet Connection",
      "type": "Broadband",
      "status": "Active"
    },
    {
      "@type": "Service",
      "id": "service789",
      "name": "Voice Service",
      "type": "Telephony",
      "status": "Suspended"
    }
  ]

Thanks Vance for your inputs. Indeed, the TMF Open APIs prefer not to have circular references (although I cannot promise that this guide is universally followed). I agree with Vance's suggestions for solving your issue - the TMF "by-the-book" method would be to query service by resource ID. Note that if you do extend the model to create a backward reference, you need to decide if it will be an array of Service or a single Service. If in your business situation a Resource can implement multiple Services, you'll need an array.

Hope it helps.

Thanks, you so much @Vance Shipley for your suggestion and inputs. indeed, we were also thinking of adding either new parameter under resource object or as characteristics name/value pair to avoid more complexity of polymorphic extension and impact on consumers about it. We will go ahead with new parameter only in this case to give service Id reference.

@Mahesh Choudhari you may add an attribute, with name and value of your choice, to the JSON object representing the Resource in a TMF639 response. That was option 2 in my reply, which is a polymorphic extension (see  TMF730 Part 2). At SigScale we do exactly this, with the same motivation as you. Just realize that this is a proprietary extension of both the TMF639 producer and consumer. The interface remains TM Forum compliant however.

Thanks @Vance Shipley for your inputs and advise. We are providing related resource reference using "supportingResource" under 638 so similar way our internal team was asking if we can give 638 service reference in 639 resource to traverse back.  As i understand we cannot give or define service as resource and give such reference. We will check on this how we can achieve it as per above suggestion.

@Mahesh Choudhari raises a question about navigating from a Resource in TMF639 to a Service in TMF638:

can we give service reference as a resource relationship

No, definitely not, because an entity with @type: Service is not a Resource and the resourceRelationship attribute provides (only) related Resource entities.  It may seem odd that TMF639 does not provide for navigation to Service however it is intentional. I am told that "domain driven design" principles do not allow the resulting circular relationships. 

You have two ways to go here:

1. query TMF638 to find related Service entities
2. implement a polymorphic extension

Both of these have their own issues.  The first option requires the advanced query syntax of TMF630 Part 6 JSONPath, which your TMF638 implementation may not support. The second option may be easier and more efficient but will be proprietary, however it can be seen as an optimization as other TMF639 consumers shall ignore the extension.

Here's an example of querying TMF638 for Services where supportingResource includes a reference to a Resource with id: 42:

GET /tmf-api/serviceInventory/v4/service?filter=supportingResource[?(@.id=='42')]

Dear All,

We are working on implementation of 638 and 639 for service and resource inventory respectively. Here in our requirement as per TMF Open API we are giving respective resource like circuit and all for given 638 service inventory API as a supporting resource. However similarly can we give service reference as a resource relationship say "serviceAssociatedwith" with service details as a resource object in 639 API. so that from 639 they can go to respective href of 638 service ID or something.

Following way of representing service details in the form of resource under 639 as resource relationship. Is it valid and compliance with TMF Open API?

Kindly advise/guide in this regard.

"resourceRelationship": [{
                            "relationshipType": "ServiceComposedOf",
                            "resource": {
                                "@type": "service",
                                "@baseType": "LogicalResource",
                                "@referredType": "service",
                                "name": "SVCXXXXX",
                                "id": "SVCXXXXX",
                                "href": "http://XX.XX.XX.XXX:61050/tmf-api/serviceInventoryManagement/v1/service?id=nsUKEVC10000396&systemName=system"
                            }
                        }]

Ok got it . Thanks for your suggestion but just to understand ServiceRef or ServiceRefOrValue would come as part of 638 ..right? for 639 we cannot use similar entity .. Correct? hence we were thinking of using relatedEntity like relatedService under 639 to represent any service for that resource in 639 as mentioned above however since there is only one service for a particular circuit /resource we thought to add parameter say parentServieId either under resource char or resource object as an optional for other consumers.  Later when we have multiple services then in 639 we can use it as below in 639 since serviceReforValue we cannot give directly in 639 as it comes as part of 638. Sorry for any gap in understanding and please correct.

  "relatedServices": [
    {
      "@type": "Service",
      "id": "service456",
      "name": "Internet Connection",
      "type": "Broadband",
      "status": "Active"
    },
    {
      "@type": "Service",
      "id": "service789",
      "name": "Voice Service",
      "type": "Telephony",
      "status": "Suspended"
    }
  ]

Hi Mahesh

I'm not sure that I like the idea of "hiding" the parent service ID as a characteristic. In this way you are weakening the contract with your API consumers. The parent service ID is an input/output (depending on your business) but it is not apparent explicitly in your swagger/OAS file. Only by examining a resource specification can a consumer understand that this information is present. And if the characteristic is omitted by accident from one of the resource specifications, what then?

If you don't want to take the query route, then an array of ServiceRef makes most sense to me (you could also do ServiceRefOrValue, which will work better once we have moved to OAS 3 with support of oneOf).

Thanks @Jonathan Goldberg for your inputs/views as well and agree with that. As of now we have gone ahead by adding additional parameter under resource char as parentServiceId something like that under respective circuit or interface connection resource inventory. However as per suggestion from @Vance Shipley we were thinking of using polymorphic extension to show all services, if required under resources as below but we have dropped that idea as we were giving resource details specific to particular circuit. if it was overall resource like device or card/port level exposure then we can think of below to provide such details with list of services in array format under 639. Hope I am correct and in future we can do as per below method under resource object similar to relatedParty and all.

  "relatedServices": [
    {
      "@type": "Service",
      "id": "service456",
      "name": "Internet Connection",
      "type": "Broadband",
      "status": "Active"
    },
    {
      "@type": "Service",
      "id": "service789",
      "name": "Voice Service",
      "type": "Telephony",
      "status": "Suspended"
    }
  ]

Thanks Vance for your inputs. Indeed, the TMF Open APIs prefer not to have circular references (although I cannot promise that this guide is universally followed). I agree with Vance's suggestions for solving your issue - the TMF "by-the-book" method would be to query service by resource ID. Note that if you do extend the model to create a backward reference, you need to decide if it will be an array of Service or a single Service. If in your business situation a Resource can implement multiple Services, you'll need an array.

Hope it helps.

Thanks, you so much @Vance Shipley for your suggestion and inputs. indeed, we were also thinking of adding either new parameter under resource object or as characteristics name/value pair to avoid more complexity of polymorphic extension and impact on consumers about it. We will go ahead with new parameter only in this case to give service Id reference.

@Mahesh Choudhari you may add an attribute, with name and value of your choice, to the JSON object representing the Resource in a TMF639 response. That was option 2 in my reply, which is a polymorphic extension (see  TMF730 Part 2). At SigScale we do exactly this, with the same motivation as you. Just realize that this is a proprietary extension of both the TMF639 producer and consumer. The interface remains TM Forum compliant however.

Thanks @Vance Shipley for your inputs and advise. We are providing related resource reference using "supportingResource" under 638 so similar way our internal team was asking if we can give 638 service reference in 639 resource to traverse back.  As i understand we cannot give or define service as resource and give such reference. We will check on this how we can achieve it as per above suggestion.

@Mahesh Choudhari raises a question about navigating from a Resource in TMF639 to a Service in TMF638:

can we give service reference as a resource relationship

No, definitely not, because an entity with @type: Service is not a Resource and the resourceRelationship attribute provides (only) related Resource entities.  It may seem odd that TMF639 does not provide for navigation to Service however it is intentional. I am told that "domain driven design" principles do not allow the resulting circular relationships. 

You have two ways to go here:

1. query TMF638 to find related Service entities
2. implement a polymorphic extension

Both of these have their own issues.  The first option requires the advanced query syntax of TMF630 Part 6 JSONPath, which your TMF638 implementation may not support. The second option may be easier and more efficient but will be proprietary, however it can be seen as an optimization as other TMF639 consumers shall ignore the extension.

Here's an example of querying TMF638 for Services where supportingResource includes a reference to a Resource with id: 42:

GET /tmf-api/serviceInventory/v4/service?filter=supportingResource[?(@.id=='42')]

Dear All,

We are working on implementation of 638 and 639 for service and resource inventory respectively. Here in our requirement as per TMF Open API we are giving respective resource like circuit and all for given 638 service inventory API as a supporting resource. However similarly can we give service reference as a resource relationship say "serviceAssociatedwith" with service details as a resource object in 639 API. so that from 639 they can go to respective href of 638 service ID or something.

Following way of representing service details in the form of resource under 639 as resource relationship. Is it valid and compliance with TMF Open API?

Kindly advise/guide in this regard.

"resourceRelationship": [{
                            "relationshipType": "ServiceComposedOf",
                            "resource": {
                                "@type": "service",
                                "@baseType": "LogicalResource",
                                "@referredType": "service",
                                "name": "SVCXXXXX",
                                "id": "SVCXXXXX",
                                "href": "http://XX.XX.XX.XXX:61050/tmf-api/serviceInventoryManagement/v1/service?id=nsUKEVC10000396&systemName=system"
                            }
                        }]