The onePK Software Architecture

This post is about the onePK software architecture, and how it allows us to consistently expose network operating system (NOS) features to a wide variety of programming environments for IOS, IOS-XE, IOS-XR and NXOS.

For an overview of onePK in general, and some more context, see my October 2012 post and my slides in Slideshare.

The main elements of the onePK software architecture are illustrated in the diagram below.

The main elements, from top to bottom, are:

• Programs written in C, Java, or some other client side language that we may support in the future.
• The presentation layer, i.e. set of APIs, that exposes the onePK functions/structs/classes/methods in different languages.
• The communications channel, between the presentation layer and the infrastructure layer, for API calls.
• The infrastructure layer, a.k.a. the “abstraction” layer, which provides the framework code for NOS specific implementations.
• The NOS specific implementations of the infrastructure/abstraction layer.

Whilst this architectural pattern is very common, the way in which we have implemented it allows us to provide the same functions, in multiple language APIs, across all of our NOSs. Those APIs are implemented on the NOS itself, not by an intermediate EMS/NMS or other “off box” abstraction layer.

Developers can use the same APIs across the whole network, even when the devices in the network are running different NOSs. As the network evolves, this API consistency will be maintained so that different devices, with different NOSs, can be used as appropriate.

When thinking about API design for specific languages, we try to embody the principle of “least surprise”. This means that we aim to provide APIs that match the developer’s perspective and expectations for the language in question. Java developers get packages, classes and methods that (we hope) make sense in the general Java world, whilst C developers get appropriate structs and functions. We will apply the same principle to other languages also.

Whilst all client side APIs sets support the same logical functions, some languages have advantages over others for certain domains. We try to build those advantages in with the APIs and utilities that we create for specific languages. Since the same logical functions are supported in all languages, the developer tools and language capabilities can be chosen on the basis of what makes sense for the developer and the problem at hand.

With this architecture, supporting different languages, development tools and environments on the client side is quite straightforward. The result is a development experience that meets our customers’ needs better.

So, get your build on, in whatever language you like!

Share