TM Forum Community

 View Only
  • 1.  Exposing and using ODA component capabilities

    TM Forum Member
    Posted Dec 16, 2021 11:23

    I would like to learn more about component "capabilities*".

    Key questions are:
    1. how does an ODA component "exposes its capabilities" (by what means)?
    2. what are the practical benefits of a having a "catalog" of capabilities?
    3. what's the relation between an ODA capability/function and an TMF Open API capability/function.
    They obviously intersect, both have "capabilities", both needs these capabilities to be registered in a catalogue.

    I understand 2 things so far:
    1. the component capabilities must be registered in a "catalog" of capabilities.
    2. The "catalog" makes all capabilities "discoverable" to other components.

    IG1171 says "The functions offered by an ODA component are exposed via "operations and notifications". I assume function = capability.
    Component anatomy doesn't have "operations and notifications" but has "Management Function" and "Reporting Function". Are both used to register a capability?

    "Capability" can have different meaning in different ODA documents. For this post I consider this definition:
    A component expose its capabilities. A capability means the ability to carry out a business process.
    source: ODA training, component module.

    Matthieu Hattab
    Altibox AS

  • 2.  RE: Exposing and using ODA component capabilities

    TM Forum Member
    Posted Dec 16, 2021 14:49
    Hi Matthieu
    The best thing might be for you to have a dialog with the principal architects of ODA, including @Sylvie Demarest, @Gaetano Biancardi, @Dave Milham, @Emmanuel A. Otchere.
    Hopefully they will be able to point you to the relevant concepts.
    Good luck in your ODA journey :)​​​​​​

    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.

  • 3.  RE: Exposing and using ODA component capabilities

    TM Forum Member
    Posted Dec 17, 2021 08:39
    May I give some comments to your questions.
    It's difficult to give a short answer, because there is no standardized language with well define names and concepts. I wrote the base document IG1171, and after that other members have contributed with their views. This means that not even within that document all concepts are consistent. After that the ODA Component Concept have started to be used by several projects. Some application oriented that tries to define components with rich application-like core functionality, disregarding the complementary functions as implicit the same way as in TAM, some implementation oriented that omitted the functional specifications, which is a vital part of an ODA Component. 
    To your questions. 
    1. The ODA Component is meant to be used throughout the lifecycle of the ODA Component. This means that a component 's "capabilities" will be exposed in different ways, as specifications, as services (exposed functions), as operations (methods) of protocols (APIs), depending on where in the architectural work the ODA Component is used.
    2. I can't recall that we have discussed a catalog of capabilities in regards to ODA Component definitions. We have the Functional Framework that can support the specification of the component's functionality and we have a project started to define component candidates. But you are right that it is needed in a component based architecture. Such architecture will need good modeling referring to "catalogs" of functions (e.g. the functional framework) and components.
    3. As for all of TMF's frameworks and "standards" they are created independent from each other. To make them fit together is a re-enginering  work. Implemented ODA Components need APIs to expose their functions (services), Open APIs supplies candidates for this.

    Kaj Jonasson

  • 4.  RE: Exposing and using ODA component capabilities

    TM Forum Member
    Posted Dec 21, 2021 11:12
    Great comments

    I think we are at the point with ODA components where we do need to improve the precision of our debate from the discussion of concepts in purely TMF terms  to terms we can easily relate to other activities within the  TM Forum and other SDO. Think we need to avoid unqualified terms like capabilities and services.
    See suggestions below.
    • Capabilities To the best of my knowledge we have defined the term Capabilities  in the context of the ODA business Architecture  and are called Business Capabilities.
    • Functions In the ODA Information  Systems Architecture  view we have used the term Application Framework Functions  GB929F  derived from the earlier work in TAM .
    • Component examples. In the ODA component examples ( ODA TAC team)  we are developing at  ODA Components (TAC-163) - Technical architecture and components to improve Specification of ODA Components
    • Issues. Currently, we are exposing ODA Component Service by direct reference to APIs  which  are really stage 3 realizations  of service. But without explicit links to the Functions they support. 
    Work in progress
    •  ODA component template:   We are currently discussing in the ODA TAC team an evolution of the specification of components which takes account of activities
    • Observations 
    • ETSI ZSM 002 models are useful as they and 3G 28.533  use the concept of Management Functions ( MnF) that exposed Management services (MnS). Management Functions can be considered as equivalent to ODA component but with out being well enabled with the ODA component complementary functions 
    • Diagram below gives some idea of relationships

    • Note that in ETSI NFV  Service's are broken in to finer grained Service Capabilities. And these are catalogued in ZSM002 whcih suggest that a Services Catalog is something we should consider for ODA Components - especially for what in IG1222 Tech Arc are called ODA System Services.
    • So back to your questions
      • assume capabilities as you defined them  are Functions  for which  we already have a catalogue of Functions in GB929F
      • What is missing is a possible register of ODA Component Services
      • Registration of Component Services is actual done in the ODA CA project by resolving API references at run time  and when registering ODA Component in the run time using metadata to describe what APIs they consume and expose. 
    • However all of this needs more discussion and review across ODA Components Team and ODA CA team.



    Dave Milham
    TM Forum, Chief Architect