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.
------------------------------
Original Message:
Sent: Dec 30, 2018 22:36
From: Yugandhar Sarraju
Subject: External OSS/BSS integration
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
Original Message:
Sent: Dec 30, 2018 02:43
From: Jonathan Goldberg
Subject: External OSS/BSS integration
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
Original Message:
Sent: Dec 28, 2018 05:10
From: Yugandhar Sarraju
Subject: External OSS/BSS integration
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
------------------------------