Hi,
You may see (in R18.0 APIs) some mention of these three attributes in various entities across the API catalog:
- @baseType
- @type
- @schemaLocation
These are the basis of an extension mechanism called the "Polymorphic Pattern" and will be present in every relevant entity across TMF APIs going forward. These allow your API implementation to return extensions to the payload while remaining compliant to the core TMF specification (ie: "would still pass a formal TMF conformance check").
It is analogous to sub-classing: If you wanted to return a company-specific variation of (say)
Individual called "
Horse" (a
type-of Individual), you can implement the Party Management API, but your GET response payload might also include:
{
"id" : "..."
"birthDate" : "2018-09-21T09:13:16-07:00",
"countryOfBirth" : "USA",
"gender" : "male"
"@baseType" : "Individual",
"@type" : "Horse",
"@schemaLocation" : "http://schema.myCompany.com/Horse.schema.json",
"horseType" : "Mustang",
"speed" : "45",
"lifespan" : "25"
...
}
This allows a consumer of the API to see that you are returning a "Horse" which is a specific type of Party:: "Individual", and has additional, specific attributes (horseType, speed, lifespan) as described in the JSON schema file pointed to by "@schemaLocation". You must still remain compliant to the mandatory attributes and relationships of the "
Individual" super-class (to remain TMF compliant). If your API consumer were only expecting, or only wanted to treat the response as an
Individual - they they would see a valid
Individual payload (id, birthDate, gender etc), and can ignore all additional Horse-specific attributes (horseType, speed, lifespan...). If they suspect that some of your
Individual responses may be describing
Horses, they can look out for the (non-mandatory) "@type".
I have picked a "wacky" example so as to not get tied up in technical specifics, but you can imagine doing the same with a particular "
BroadbandServiceSpecification" or "
CloudProductOffering". This is a better, strongly-typed and dynamically-discoverable way of extending TMF entities than with characteristics (essentially a bag of name/value pairs with an unstated common-knowledge of "what is in the bag" between the consumer/producer).
Characteristics are not going away, but this Polymorphic Pattern will be present in every subclassable entity, in every TMF API released from this point on.
Hope that helps!
------------------------------
Stephen Harrop
Principal Enterprise Architect
Vodafone Group
------------------------------
Original Message:
Sent: Nov 28, 2018 15:57
From: Amol Mozarkar
Subject: Object model TMF APIs
We are migrating our monolithing soa service over to TMF based rest services. And at most places I see limitations with the SID object model, where it doesn't have name value pair generic objects in the model to allow any additional telecom specific elements to be added into the model.
I think a blank extension object should be added to every parent data object, so the SID model becomes more scalable and extendable.
For example:
TMF666 has PartyAccount object. It doesn't have some of the telecom specific account elements like CRD, CRDDDST, BAN etc. Also this object has no name-value pair generic object like characteristic where these additional details can be passed.
So Adding a PartyAccountExtension object within PatyAccount could solve this problem without corrupting the core TMF data model. And Every Telecom company can add their specific elements if any within the extension object instead of core SID model.
Any suggestions ?
------------------------------
Amol Mozarkar
Solution Architect
Member of Global Association of Enterprise Architects (globalaea.org)
Bell Canada
------------------------------