Andreas interesting and informative post.
In the ODA program we just published:
This was predicated on analysis of 5-6 5G and NaaS catalysts results. As part of this we developed an ODA Production Implementation Framework to place the functionality in the Catalysts projects. What we realised as we completed the work that this has much more general application than 5G and addresses your suggested comment '...… To standardize this would really mean to define an architecture which standardizes functional placement'
IG1167 ODA Functional Architecture R18.5.0 |
https://www.tmforum.org/resources/standard/ig1167-oda-functional-architecture-r18-5-0/ includes mapping the functional groups to Frameworx including TAM. However TAM has some historical limitations which we are planning to overcome in future releases of IG1167. This document also has some tables with placement of OPEN APIs within the ODA Functional Groupings.
For Release 19 we have agreed at AW Lisbon last week to change the title and scope of GB999 to be a complete ODA Production Implementation Framework covering multiple resource technologies - including 5G - and incorporate some additional functional elements including virtualisation and Lifecycle management functions . These later functionality updates will leverage prior work in
Plus new work on addressing the SID models to be used for each functional block within the ODA Production Implementation framework
The SID models turn out to be crucial to getting this right as each Open API points to specific parts of the SID model and stitching them together shows that there are some gaps and enhancements that need to be addressed together with practical best practices constraints to make implementation tractable.
These Models were discussed last week but time precluded us form discussing the full set of nine contributions at
2019-02-14 Thu Q1: ODA/FX - NaaS Connectivity Service Models (UML & NaaS API Data Models)Meeting are held Tuesdays currently at 11:00 and 13:00 GMT and recommence next week.
PS NTT Japan is involved in some of these discussions
Would be more than happy to set up a call to discuss if you are interested
------------------------------
Dave Milham
TM Forum Chief Architect, TM Forum
------------------------------
Original Message:
Sent: Feb 17, 2019 10:41
From: Andreas Schlueter
Subject: Resource Pool Management & Resource Inventory API
At TMForum Action Week I promised to have a look at the Resource Pool API.
I would like to post my initial view on the topic here to get some feedback whether my thoughts go in the right direction.
I also put them to the resource inventory API page as well since it is closely related and I think at least part of it also relates to discussions in this thread:
- First aspect: Resource Model
- To figure out the relationship between Inventory and Pools/Reservation, I looked it up in SID GB922_Logical_and_Compound Resource.
- There reservation and related processes are handled as specific types of ManagementInfo (Everything goes on ManagedEntity Level, so also for Services)
- Reservations are handled as ConfigurationInfo, but it is not spelled out there
- State is a separate piece of ManagementInfo
- The Resource resource () in ResourceInventory does not have ConfigurationInfo and only very weak "StateInfo" (either inconsistently described or I do not get the link between resource model and state machine.
- The Activation & Configuration API has some more state types which look better, but are unspecified and not yet schematized and inconsistent with the resource inventory
- My conclusion: It would be best to rework all these APIs (along with ResourcePoolAPI) to use a consistent resource model for resources spelling out ManagementInfo including state, configuration (and reservation, even if SID calls it a specific configuration) separately.
- Second aspect: API structure
- I think that by reworking ResourceInventory API as described above, all information pertaining to resources and pools, configuration and activation could be captured in a single API.
- Nevertheless, I think this would not be sufficient since doing direct manipulations of the ResourceInventory does not seem to be appropriate as part of e.g. order capture
- In a way this would be similar to replacing ProductOrdering with direct manipulation of the ProductInventory.
- This is not correct since these APIs expose different functions (from different TAM domains) and do not only manipulate data entities.
- So I think that a "Configuration and Activation" API as well as a "Reservation" API will be required in addition (I would keep them separate, for reasons as discussed above) whose implementations might then invoke the inventory API.
- I call it "Reservation API" since I think resource pools are only specific ManagementMethods for Reservations, so the name of the API should reflect the main entity to be handled.
Does this sound understandable and reasonable? If so, I would consider whether and how we could support an adaptation and schemification of these APIs in this direction, collaborating with their owner.
Andreas
P.S. The second aspect for me hints at a general question regarding APIs that is unclear: How do we describe which APIs are intended for which use cases (why cannot some frontend simply go ahead and modify the product inventory)? This topic came up in Frameworx and is very valid: A mapping between APIs and TAM Domains would be desirable, and actually I suspect an extension of these mappings to the ODA would lead to another level of (fruitful) discussion: Which APIs expose functionality of TAM blocks, which APIs expose the interface of ODA domain areas? To standardize this would really mean to define an architecture which standardizes functional placement
------------------------------
Andreas Schlueter
NTT DATA CORPORATION
------------------------------