Blog Viewer

FAQ: Learning About JET Part 3--JET APIs

By Erdem posted 03-20-2017 08:34

  

JET

What is JET ?

Juniper Extension Toolkit (JET), an evolution of the Junos SDK,  provides a modern programmatic interface that makes programming simple, flexible, and extensible.

 

What frameworks does JET use?

gRPC: JET uses interface definition language (IDL)-based frameworks provided by GRPC, which is licensed under a three-clause BSD. By default, gRPC uses protocol buffers based on  the IDL used for serializing data. For a detailed overview, refer to the guide here.

 

MQTT: MQTT[1] (formerly, Message Queue Telemetry Transport) is a publish-subscribe-based “light-weight” messaging protocol for use on top of the TCP/IP protocol.

For more details, see http://mqtt.org/.

Multiple languages (Python, C, C++, Java, Ruby, GO, C#) are supported.

Mosquitto is an open source, BSD-licensed project, which implements MQTT protocol versions 3.1 and 3.1.1.

See http://mosquitto.org/ for more details about Mosquitto.

 

What are the advantages of JET over SDK ?

Ease of use

  • JET is language agnostic.
  • With JET, you get simple framework APIs with extensive documentation.
  • Application development can be done on any operating system (Linux, Windows, FreeBSD).
  • Application developers can use tools of their choice (IDE, frameworks like Twisted, etc.).

Support for various deployment models

  • APIs are consistent across different deployment models: application on-box, application on VM, application off-box.
  • Application developers can define their own APIs.

Junos OS release agnostic

  • APIs are decoupled from Junos OS releases.
  • Binary compatibility is possible across Junos OS releases.


Where can I find JET API documentation?

Extensive API documentation is provided in the Juniper TechLIbrary: 

 

JET Client Libraries (Valid Through Junos OS Release 16.1)


What does the JET client package contain?

The JET client package consists of Python APIs for different services such as Route, Interfaces, Firewall, and Notifications.

 

Can I use Thrift IDL Directly?

Yes. Application developers can choose to directly use Thrift IDL and develop the application in the required programing language that Thrift supports.

 

However, application developers will need to take care of:

  • Establishing a Thrift client session with a device running Junos OS
  • Establishing a secure channel

 

 

JET IDL Package


Where can I find a JET IDL package?

JET IDL packages can be found on the Juniper Software download page. On this page, choose the version from  the drop-down menu on the right.

 

How do I work with JET IDL files?

JET IDL files are proto definitions of various services that JET offers. Check the gRPC guide to learn more about proto IDLs. These IDLs can be used to generate Python or C++ code, which can be linked by the user to develop applicaitons.  More about the generation of applications are available in the videos on this website. More details on the entire workflow can be found here: API Guide.

 

 

JET Client APIs


Does JET provide any tracing in client libraries?
No. Application developers can choose to use the off-the-shelf Python tracing library for debugging purposes.

 

Why does JET not provide any event-based programing framework like Twisted in Python or libevent in C?
JET is meant to be simple and flexible and to provide the required APIs to program a Juniper Networks device. Application developers are free to choose the required framework for event-based programming.

  

Can I write my own service and deploy it on a Juniper Networks device?
Yes. The JET framework provides the flexibility to add new custom services. View the JET App Store for various examples. 

 

JET Application Build and Packaging


How do I build and package my JET application?

Details on the development environment and workflow are provided at the following links:

 

Do I need to sign my package to run it on Junos OS?

An app can be deployed either on a device running Juons (“on-box”) or on an external machine (“off-box”).

To package an app for off-box deployment, the user can use any packaging and installation procedure appropriate for the language used to create the app.  

 

To package an app for on-box deployment, if the app doesn’t have any dependency on C/C++ libraries and if the app need not be signed,use standard python distutils procedure. And it should be installed on Junos device using ‘request system software add <package-name>’ operational command.

 

Click Requesting Certificate Using the JET IDE for more information.

 

Can I build third-party code (C or C++) distributed using Autoconf-Automake for deploying on Junos OS?

Yes.

 

Security

 

Does JET provide security?

Yes.

 

For 16.1, JET provides APIs which utilize a secured transport channel by establishing an SSL channel between the host running a JET client application and the Juniper Networks device. User-based authentication and authorization are also implemented to invoke service APIs. Refer to the OpenRequestResponseSession API in the documentation to further understand the functionality.

 

For 16.2, the config to start JET on device, we need to mention the below

 

set system services extension-service request-response grpc ssl address 0.0.0.0
set system services extension-service request-response grpc ssl local-certificate mycert
set security certificates local mycert load-key-file <key-file-name>

 

From application side, use the secure channel with server authentication SSL/TLS as mentioned in this google guide: http://www.grpc.io/docs/guides/auth.html

 

How is authentication and authorization taken care of using JET?

JET client API – OpenRequestResponseSession provides the abstraction to take care of authentication and authorization. Authentication is ensured by securing the channel through SSL between the Juniper Networks device and the host where the application was run; a valid Junos user with the maintain level is allowed to execute JET APIs.  OpenRequestResponseSession is valid only for 16.1 release. From 16.2 release onwards, user will need to do everything from IDL.

 

Do I need to authenticate each and every time I invoke a JET API?

Not required. If the JET application developer wants to authenticate a user, the OpenRequestResponseSession API should be the first call with the JET handler created. When the OpenRequestResponseSession call is successful, any subsequent API invokation using that handler does not require any authentication.

Note: Performance of an API differs between a secure and insecure channel, with the latter giving better performance. It is the application developer’s discretion to choose between the two.

 

How can I authenticate and authorize if I use IDL?

For the 16.1 release, if you are using IDL-generated stubs directly for client language bindings other than Python, you should port the OpenRequestResponseSession Python API implementation to the required language bindings. The OpenRequestResponseSession API needs to do the following key processing internally:

  • Open a Thrift transport session with the device.
  • Invoke LoginCheck with username and password.

 For the 16.2 release we need to say the following:

  • Open a GRPC session with the Device
  • Invoke LoginCheck with username, password

Compatibility

 

What is the compatibility story of JET applications?

JET applications built on IDL packages from Junos OS Release 16.2R1 onward will continue to work on future releases unless the API signatures undergo critical changes. All these changes will be documented in subsequent IDL package releases.


#JETClientAPIs
#JunosOS
#JETClientLibraries
#JunosExtensionToolkit
#JET
#FAQ

Permalink