Client devices

Background

Over the years, the NAGRA OpenTV Platform head-end has evolved dramatically from a monolithic SOA approach to a more modular SOA approach. This evolution has been fairly organic and based mainly on the requirements of scaling, quality, and staying relevant in a competitive industry.

The Service Delivery Platform was once the only service accessed by clients, and it was responsible for consolidating all data, and communicating with any relevant external systems. Whilst it did (and still does) work, over time we found that this generalist approach did not work at scale, and was difficult to manage due to its size. It also made the system less flexible in deployments where NAGRA contributed to only part of the solution. The general approach today is to have multiple software modules, each with its own responsibilities, which each should excel at. This sometimes means using different technologies based on the supported use cases of that module.

Even though different technologies are used to implement the different modules, the aim is to provide a consistent API across modules where possible. For our next-gen modules, this means conforming to the REST standard, and re-using common variables, if appropriate. Legacy systems will continue to be REST-like for the time being.

Implementing generic and granular REST-based APIs has, however, meant an increase in communication between client and server for certain use cases (the benefit, again, being scalability). Because of this, we are in the process of implementing some additional facade services that aggregate the functionality of several services to reduce the number of calls required between client and server.

Purpose

The purpose of this documentation is to guide architects, software experts, and developers on the recommended use of the new OpenTV Platform that includes all of the latest modules as described above.

It will not delve too deep into specific APIs unless necessary; where possible an API reference page will be referenced instead.
The documentation will be structured from a use-case perspective.

This documentation is based on version 2.5.