Tuesday, April 26, 2016

New SDK for Python Adapters

Our family of Adapter Development Kits has been further enriched with the Lightstreamer SDK For Python Adapters, which lets developers write Remote Adapter Sets exploiting the power and flexibility of Python, one of the most widely used general purpose high-level languages.

The new SDK has been developed keeping in mind the same principles and concepts which drove the design and implementation of the SDK for .NET Adapters, the "progenitor" of the successive SDKs for Java Remote Adapters and for Node.js Adapters, all already provided as part of the Lightstreamer distribution. Nevertheless, the Python Adapter SDK must not be considered as a "simple" port to the Python language; on the contrary, it is a brand new implementation, based on the best practices and widespread conventions promoted by the community around the language.

In this post we are going to show a general overview about the development of custom Python Remote Adapter Sets, which should sound quite familiar for those who have already experimented with the others Lightstreamer Adapter SDKs.

Setting Up the Development Environment

The Python Adapter SDK requires Python 3.4 or later and is currently available as a beta version. You can install the package from the PyPi repository, through the pip tool:

Now, we are ready to write a simple Adapter Set prototype, with the purpose to show the basics of Python Adapters development. 

A Simple Prototype

Let's start creating a new Python module and call it adapters.py, in which we first add the following code to import the classes required to create our Adapter Set:

As you can see, the library is structured into three core packages:
  • lightstreamer_adapter.server,  which contains the classes needed to configure and start the Remote Adapters
  • lightstreamer_adapter.interfaces.data, which exposes the ABC (Abstract Base Classes) and the exceptions needed to create and manage a Remote Data Adapter
  • lightstreamer_adapter.interfaces.metadata, which exposes the classes and the exceptions needed to create and manage a Remote Metadata Adapter.
 

Remote Data Adapter

Creating a Remote Data Adapter is a simple matter of extending the DataProvider class and implementing all its abstract methods: 


DataProvider is an Abstract Base Class equivalent to the homonymous interfaces already available in the Java Remote and .NET Adapters, as well as the ItemEventListener interface (actually an ABC too), whose instances are transparently injected through the set_listener method, and then used to send real-time updates or error notifications to the Lightstreamer Kernel.

Remote Metadata Adapter

To create a Remote Metadata Adapter you have to extend the MetadataProvider class, by providing an implementation to those methods you want to customize as per your requirements.

Once again, MetadataProvider is formally equivalent to the ones you can find in the Java Remote and .NET SDKs, even though it supplies a default implementation for all exposed methods, in order to facilitate the coding of new Remote Metadata Adapters.

For the sake of simplicity, in this example we show an extremely simple implementation in which only the notify_user_message method has been overridden:


For of all the details relative to the lightstreamer_adapter.interfaces package, take a look at the official API Specification on pythonhosted.org.

Putting It All Together

Now it's time to put the newly created Remote Adapters "on the road". The way to do that is by leveraging the DataProviderServer and MetadataProviderServer classes, which have the responsibility to oversee the execution of the Remote Adapter instances and connect them with the Proxy Adapters remotely running on Lightstreamer Server:


These instances require to be configured by supplying at least:
  1. the host address of the Server;
  2. the listening TCP ports for the request-reply and the notification channels of the Proxy Adapters;
but it is also possible to provide further configuration parameters, like "name" (useful for logging purpose) and "keep_alive" interval (to enable a liveness check over the connection): check out the official API Specification for more in-depth details on the lightstreamer_adapter.server module.

DataProviderServer and MetadataProviderServer have very similar duties of their counterparts in .NET and Java, though a slight difference exists, which leads to a further simplification: they contains all the low-level mechanisms needed to manage the communications over TCP/IP, therefore there is no need to manually handle any socket connection to provide the Remote Adapters with. From this perspective, the API supplied by the Python SDK hides a complexity level which, in some cases, might not be desirable.

Before running the module, it's necessary to properly configure the Lightsteamer Server, by deploying the Remote Adapter Set through the appropriate adapters.xml file, in which the Proxy Adapters need to be configured with the same TCP ports used to setup the connection in the sample code:

In this case we have chosen the Robust version of the Proxy Adapters, but you can modify it to your liking by using the generic templates you can find both under your Lightstreamer installation (DOCS-SDKs/adapter_remoting_infrastructure/doc) and at the following urls:

Other full code examples, along with complete instructions to deploy and start the Python Adapters against your local Lightstreamer Server installation, are available on GitHub:

Conclusion

With the availability of this new Adapter SDK, we have expanded the set of Lightstreamer enabled platforms to the expressiveness and power of Python, as another remarkable step toward the spread of the Lightstreamer technology across major mainstream languages and platforms, in order to offer wider support for back-end systems integration.

Furthermore, we have decided to release the library as an open-source project on GitHub, so we encourage developers to experiment with it and provide us with any feedback at support@lightstreamer.com.


No comments:

Post a Comment

Note: Only a member of this blog may post a comment.