Open APIs

 View Only
  • 1.  External OSS/BSS integration

    Posted Dec 28, 2018 16:45
    Hi,

    Iam trying to understand the recommended way to implement a standard interface so that my NMS platform can integrate with external OSS/BSS systems.

    I see two standard interfaces MTOSI and OSS/J and then came across OpenAPIs. Though i understand the integration to OSS/BSS depends on specific OSS/BSS i would like to know if there is a recommendation to go with implementing standard REST based OpenAPIs compared to Java/XML/WS based OSS/J. Its not about comparing but trying to understand for smoother integration with external OSS/BSS systems (atleast majority ofn them).

    Regards

    ------------------------------
    Yugandhar Sarraju
    Alten Calsoft Labs India Pvt Ltd
    ------------------------------


  • 2.  RE: External OSS/BSS integration

    TM Forum Member
    Posted Dec 30, 2018 03:10
    Hi Yugandhar

    My understanding is that the software community in general is moving towards loose coupling for integration, and this is more easily achieved using text-based interfaces, as against Java and the like (where the consumer needs to be compiled against a client kit jar).

    Within the text-based family, it appears that REST is the format of choice.

    Therefore it would seem that TMF Open APIs (REST-based) is the way to go.

    Note: This is my personal opinion only, would be interesting to hear other people's viewpoints.


    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 3.  RE: External OSS/BSS integration

    Posted Dec 31, 2018 02:28
    Thank You Jonathan for sharing your view. It appears leaving legacy, most of them would go for REST integration.

    Regards

    ------------------------------
    Yugandhar Sarraju
    Alten Calsoft Labs India Pvt Ltd
    ------------------------------



  • 4.  RE: External OSS/BSS integration

    TM Forum Member
    Posted Jan 01, 2019 04:01
    Machine to machine dialog is evolving to track the evolution of human language.

    Our internal dialog within our heads, while it is informed by the home language we speak, is none the less private.  Our public voice is in a language, and the dominant characteristic of these shared languages is that they are a deep compromise to balance rich expression with ease of adoption - teaching if you will.

    And so it is with machine dialogue.  We are going to approach a means of communicating that is a compromise between expressiveness and adoption.  We need to get to the point where external integration can occur on first contact between machines, without intervention.  This implies much more than a shared information model or message format.  It also implies that this external language needs to be adoptable across a wide set of technologies.

    This is a different driver set than those for internal integration, where adoptability is less crucial as the scale of participants is far less.

    Right now REST is a good strategy to achieve this, but it does not go far enough.  The basic unit of machine communication is the message, and unless we use easily adoptable message standards, our competitors will outperform us in business agility and flexibility achieved through low cost partnering with external enterprises.

    ------------------------------
    Hugo Vaughan
    Crowd Frame Consulting Limited.
    ------------------------------



  • 5.  RE: External OSS/BSS integration

    TM Forum Member
    Posted Jan 01, 2019 18:49
    Its pretty clear that the integration technology is moving decisively towards use of REST technologies for the API integration . MTOSI MTNM and OSS/J were based on earlier IT integration technology choices such as Web Services / SOAP and JMS.
    However the original question as about external OSS/BSS integration which as Hugo remarked is more than the IT integration level technologies. There also has to be some semantic integration which is achieved in OPEN APIs by referencing core SID entities . However MTOSI MTNM went much further and described quite detailed information and data models for the API integration related to the actual network technologies being managed in their cases SDH, ATM, MPLS VPN etc.
    Work relevant to the original OSS  BSS integration question is taking place in several linked TM Forum activities .
    • The collection of Open APIs  needed for managing 'Network as a Service' ( a major part of the OSS integration challenge) is being developed in TMF 909 NaaS API component Suite within the API team. However this is a quite generic service model  aimed at the OSS to BSS interfaces 
    • Additional work on modelling connectivity services to extend the NaaS APIs s being developed in the ODA Service and resource management team. The goal is to create a technology neutral connectivity model for NaaS API that can be extended to specific technologies such as 5G.
      A snapshot of GB999 User guide for Network Slices has just been published for member comment . This has evolved from about four 5G catalysts and a couple of NaaS catalysts . This starts to address the specific connectivity models that are needed at the OSS BSS NaaS boundary  and we may break this into multiple parts a core connectivity service model and series of parts extending that model to specific technologies: e.g.for 5G, and possibly EDGE SD-WAN among others. 
    • Participation in either or both of these activities would be welcome


    ------------------------------
    Dave Milham
    TM Forum Chief Architect, TM Forum
    ------------------------------



  • 6.  RE: External OSS/BSS integration

    Posted Jan 07, 2019 04:11
    Thank you Dave and Hugo.
    I have noted your views and thanks for the wonderful pointers and information.

    ------------------------------
    Yugandhar Sarraju
    Alten Calsoft Labs India Pvt Ltd
    ------------------------------