Interoperable Applications with LabVIEW and Actor Framework

Introduction

An actor framework is a programming paradigm designed for building scalable, concurrent systems by organizing code into independent entities, or «actors,» that communicate exclusively through messages. LabVIEW’s Actor Framework builds on this paradigm, providing a robust solution for developing scalable applications, ranging from small-scale systems to large-scale projects. However, as applications grow, the need for communication between actors operating in separate executables, or even on entirely different platforms, becomes increasingly important.

While existing solutions, such as NI Nested Endpoint Actors, offer a foundation for addressing these challenges, our approach takes it a step further. With a focus on maintaining the autonomy of the Actor, our solution ensures that the Actor remains independent from the networking code. This means it can seamlessly operate as a normal Actor, providing developers with a versatile and powerful tool that not only overcomes communication hurdles but also preserves the simplicity and flexibility of LabVIEW’s Actor Framework.

Basic Concept

For a detailed exploration of the architecture behind NI Nested Endpoint Actors, refer to this informative video: NI Nested Endpoint Actors – Exploring the Architecture.

Let us dive into the problem with a practical example illustrating the simplest scenario:

Simple Actor Framework based application

The image displays two Actors, Actor A and Actor B. Both are located within the same executable. We can readily utilize the Actor Framework as-is to implement this solution. Actor A launches Actor B and sends messages to it through the Enqueuer (LabVIEW queues).

However, for scenarios requiring Actor B to operate in a separate executable or on a different PC, the standard Actor Framework faces limitations due to the exclusive use of the Actor framework’s enqueuers and LabVIEW queues for messaging.

Service Client and Server Architecture

To overcome the communication limitation, we introduce two new Actors: ServiceClient and ServiceServer. The diagram below outlines the revised architecture:

Applications X and Y communicating with the Service Client and Server architecture

In this modified setup, Actor A launches the ServiceClient Actor (instead of Actor B). The ServiceServer Actor launches Actor B. Actor A and ServiceClient run within one executable, while the ServiceServer and Actor B operate in a separate executable. ServiceClient intercepts messages directed to Actor B, forwarding them to the ServiceServer Actor. The ServiceServer Actor, in turn, forwards the messages to Actor B.

With this mechanism, any existing actor can run in a separate executable on the same or different devices across the network. Importantly, no changes are required to the existing Actors, preserving a high level of reusability.

Implementation

To better understand how this mechanism functions, we will delve into its implementation with the help of a UML diagram.

Class diagram of the Service Client and Server architecture

In the diagram, both ServiceClient and ServiceServer inherit from the standard Actor. This allows Actor A to send messages to ServiceClient rather than directly to Actor B. The ServiceServer contains an additional Actor. This Actor is the one that the ServiceServer will launch and forward messages to – in our previous example, Actor B.

Both ServiceClient and ServiceServer utilize two interfaces: IMessageStream and IMessageSerializer. This concept is inspired by the one found in the NI Nested Endpoint Actors solution.

Implementing the IMessageStream interface provides flexibility for defining any communication mechanism between ServiceClient and ServiceServer – whether through Rabbitmq, MQTT, NI Network Streams, TCP/UDP etc. When implemented appropriately, communication can even occur between a real-time target and a PC. By implementing the IMessageSerializer interface, we can convert Actor Framework Messages into a format suitable for transmission. This involves converting messages into strings, which can be binary strings or more standardized formats like JSON or XML. By doing so, it enables technology-independent communication, facilitating seamless integration across diverse platforms and systems.

In a more concrete sense, the ServiceClient overrides the «Receive Message.vi» to intercept all Messages, utilizing the Message Serializer to convert them into a string. Subsequently, the Message Stream is employed to send that string to the ServiceServer. Meanwhile, the ServiceServer overrides the «Actor Core.vi,» implementing a helper loop. This loop continuously listens for incoming data through the Message Stream. Upon data reception, the Message Serializer transforms it into a Message, forwarding it to the target Actor. Special consideration is given to handling standard Actor Framework Messages like Stop Msg, Last Ack, and others.

Conclusion

In conclusion, the introduction of ServiceClient and ServiceServer actors seamlessly enables running actors in separate executables. The independence of the existing Actors from the networking code ensures high levels of reusability. Additionally, using the combination of a standard message format, such as JSON, with a popular message broker, like Rabbit MQ, enables seamless communication and compatibility between LabVIEW applications and other software and hardware platforms.